Este artigo foi traduzido por máquina.

Prévisions : temps nuageux

Synchronisation de Branch-Node avec SQL Azure

Joseph Fultz

Dans Mes années avant de rejoindre Microsoft et pour les quelques premières années par la suite, j'ai été très impliqué dans le secteur de vente au détail. Pendant ce temps, j'ai trouvé presque humoristique pour voir combien de fois le problème de synchronisation du nœud de branche est résolu en avance de technologies.

Dans mon rôle actuel, j'ai eu une grande quantité de l'exposition pour le pétrole et gaz (O & G) industrie et moi avons trouvé qu'il a un problème similaire lors de la synchronisation des données entre les nœuds. Est très semblable au détail lié, O & G sociétés ont une large gamme de périphériques et les problèmes de connectivité. À partir d'une connexion satellite latente sur une plate-forme en mer d'huile à un ingénieur dans un champ d'huile, la configuration requise pour des données précises et opportunes ne change pas.

C'est le cas, avec la version commerciale et O & G à l'esprit, je suis étudier le défi, mais cette fois avec un peu d'aide à partir de SQL Azure et de la Sync Framework. Je vais expliquer comment le nuage peut aider à résoudre le problème de déplacement des données entre le centre de données (d'entreprise), les branches (par exemple, banque, plate-forme de test, concentrateur et ainsi de suite) et aux périphériques individuels (terminal de l'ordinateur de poche, partagée, des équipements spécifiques et bien plus encore).

Ce mois-ci, je me concentrerai un peu plus sur l'architecture générale et un peu moins sur la mise en œuvre. Je vais toujours donner quelques exemples de code pour la synchronisation entre les nœuds et SQL Azure et le filtrage de contenu comme un moyen de réduire le trafic et le temps requis pour la synchronisation. Dans la chronique du mois prochain, j'examinerai à l'aide d'une approche basée sur le service de synchronisation pour fournir une solution de synchronisation évolutive au-delà de fractionner des données entre bases de données SQL Azure en fonction de distribution de contenu ou géographique.

Alors que le problème principal n'a pas changé, ce qui ont été modifiés sont les exigences supplémentaires sont ajoutés à la combinaison comme technologie devient plus avancée. Au lieu de résoudre le problème de déplacement entre les nœuds de données simple, nous allons commencer à ajouter des choses que nous souhaitons avoir, par exemple augmenter le volume de données pour obtenir plus de détails, l'inclusion des dispositifs de collecte et affichage des données et les flux de plus près à temps réel.

Face Let’s, plus nous avons, plus nous voulons. Dans la plupart des cas, résolution des problèmes de flux de données à partir d'il y a dix ans est simple, mais aujourd'hui cette solution représente uniquement le substrat d'une solution plus robuste. Pour la vente au détail, le flux de données peut être assez facile, prenant la forme d'exécuter un push de type de catalogue de données (menu, magasin et ainsi de suite) vers le bas et de journaux de t sauvegarder — pour tout à fait complexe, en mettant à jour fréquemment des niveaux de stock et l'analyse en temps réel de prévention des fuites produit manuelle des entrées à partir de la succursale pour l'entreprise et entre les branches. La plupart du temps, O & G sociétés ont les mêmes modèles, mais elles ont certains complexités supplémentaires liées à l'opération, l'évaluation et adaptation du matériel en cours d'utilisation. Je pense que sur la synchronisation de la manière suivante pour obtenir une idée approximative du niveau de complexité (chacun d'eux est ensuite plus complexe à implémenter et prendre en charge) :

1. Exécute un push des données en lecture seule à partir de bureau de succursale et ultérieur.
2. Deux à sens unique exécute un push sur des données différentes ;dans le bureau de succursale (par exemple, le catalogue) et de la succursale à entreprise (par exemple, journaux de t et inventaire) ;Cela inclut la branche à branche, le focus se trouve sur le fait qu'il s'agit en fait deux ou plusieurs de synchronisation à sens unique.
3. Synchronisation de données bidirectionnelle entre entreprise et les nœuds (par exemple, une entrée ou de l'employé informations produit manuelle).
4. Homologue synchronisation entre les branches et entre les branches et d'entreprise.

Type 4 est de loin le problème plus complexe et généralement mène à de nombreux conflits. Par conséquent, j'essaie d'éviter ce modèle, et seulement deux critères qui forcerait l'il sont le besoin de mises à jour en temps réel entre les nœuds ou la possibilité de synchroniser les branches si le magasin de données d'entreprise n'est pas accessible. Dans la mesure où les mises à jour côté-en temps réel ou en temps réel entre trop de nœuds créeraient généralement trop de trafic et n'est pas généralement une solution raisonnable, le seul critère auquel j'ai vraiment prêter attention est la possibilité de synchroniser sans la forme de base. Dans certains cas, les informations en temps réel sont nécessaire entre les nœuds, mais ce n'est pas généralement le cas pour la synchronisation de données. Au lieu de cela, il s'agit d'un scénario de notification d'événement et une punaise différent est prise pour répondre au besoin.

Définition de l'architecture de solution

En règle générale, le modèle de catégories les plus fréquentes que je vois est envoyé des données directement à partir de la base d'entreprise (via un serveur de distribution d'un type) vers le bas pour les serveurs dans les succursales et aux utilisateurs mobiles. La distribution aux stations de travail, les terminaux de point de vente (POS) et les autres appareils est généralement effectuée à partir du serveur à l'emplacement de succursale (communément appelé “ serveurs back de maison ”), alors que la synchronisation pour les utilisateurs mobiles (par exemple, les ordinateurs portables) s'effectue directement à partir d'entreprise à l'ordinateur via un processus de synchronisation lancée par le client (voir la rubrique de la figure 1 ).

Figure 1 par défaut d'architecture pour la distribution des données

Certaines organisations cela via les fonctions de réplication intégrées du système de gestion de base de données relationnelle (SGBDR), tandis que d'autres processus pour gérer la distribution et la collecte de données de génération. Je vais maintenir le modèle, mais utilise une instance de SQL Azure à la place du serveur de distribution ;à la place de la réplication, je vais utiliser Sync Framework, qui prend en charge SQL Azure. Par conséquent, j'ajoute simplement une couche entre le serveur de distribution et les succursales (voir la rubrique de la figure 2 ).

La figure 2 à l'aide de l'architecture de Base Azure SQL et de la Sync Framework

Que puis-je en insérant SQL Azure ? Certains des avantages dans un nœud de branche de scénario sont les suivantes :

1. L'évolution du service de données sans avoir à l'encombrement du centre de données de croître.
2. Disponibilité des données sans coût supplémentaire et d'efforts.
3. Potentiellement plus la sensibilité de la sécurité, car il n'est pas le magasin de données maître.

Considérez que dans le premier scénario, si le magasin de données ou de la connexion d'entreprise est hors service, tous les clients devront conserver leurs transactions. Cela peut facilement provoquer de perte de données en raison de la perte de l'appareil lors de l'attente pour la connexion ou en raison de l'exécution simplement manque d'espace sur le périphérique pour stocker les transactions, comme indiqué plus haut. En outre, si les branches présentent des données communes (par exemple, données d'inventaire magasin), ils utiliserez hors des anciennes données jusqu'à ce que société soit vers le haut. Il n'existe aucune solution parfaite, SQL Azure répond à ce scénario en automatiquement la réalisation de copies des données et fournissant un basculement automatique. En outre, en segmentant le flux de données par le biais de plusieurs bases de données SQL Azure, je peux réduire le risque d'être arrêté et réduire l'exposition de la charge supplémentaire à l'aide non seulement une instance séparée mais aussi différents centres de données.

Comme point de conception, je dois prendre en compte l'impact de lancement de la synchronisation dans les succursales ou à partir du serveur. Si l'application est conçue pour la synchronisation entre la forme de base ou le distributeur et les nœuds, m'offre l'avantage de moins de points de gestion et de support ;sur l'inconvénient, elle place certaines souches techniques sur l'implémentation, nécessitant une :

1. Connaître les points de terminaison.
2. Permet de savoir les étendues appropriées pour chaque cible.
3. Complexité du processus de synchronisation afin de faire la synchronisation de plusieurs nœuds en parallèle ;la sémantique de l'API est vraiment une paire de points de terminaison et d'une étendue à la fois.

Par le lancement de la synchronisation de la cible (nœud ou une branche, par exemple) la complexité est diminuée pour le code de synchronisation, telle qu'elle :

• Pouvez vous concentrer sur les étendues pour le périphérique / d'application.
• Gère les plus facilement connectés occasionnellement.
• Doit seulement connaître et gérer les quelques points de terminaison à laquelle les données de distribution sont synchronisées.

Toutefois, il mettra un peu plus complexe dans les applications sur le périphérique cible et peut compliquer la prise en charge et la maintenance par potentiellement avoir à le déboguer le processus de synchronisation ou d'un agent sur chaque périphérique. Idéalement, si les données doivent être synchronisées pour différentes applications, un processus distinct doit être créé qui gère la synchronisation basée sur un fichier de configuration où les chaînes de connexion, fréquence et étendue sont définis pour un agent de synchronisation à exécuter. Cet agent de synchronisation existerait en externe pour les applications qui sont des consommateurs de données sur les périphériques, bien que le processus fournit un moyen d'une application donnée lancer la synchronisation de ses données. Cela donne l'avantage de lancement de la synchronisation à partir du nœud, mais il réduit également la prise en charge et la maintenance des aspects, car il est reportée dans un seul processus.

À l'aide de la Sync Framework, j'ai tendance à démarrer avec un modèle mixte de la synchronisation en lancer à partir du magasin de données de base pour SQL Azure, par la suite en lançant des nœuds pour une synchronisation entre le nœud et SQL Azure. Retraités, un peut indiquer que les données sont envoyées à partir de la forme de base et extraites les branches avec Azure SQL devient le concentrateur central hautement disponible entre la forme de base et les succursales. Selon les besoins et les contraintes de la solution envisagée, je pense que sur les coûts et les avantages de passer le contrôle de processus de synchronisation d'un point de la chaîne à un autre (par exemple, le périphérique pour le nuage ou d'entreprise à cloud). Quelques-unes de ces considérations sont des questions telles que :

• Existe-t-il un endroit pour héberger le processus de la forme de base ?
• Y a-t-il des stratégies de sécurité qui sont en conflit avec le processus de synchronisation dans SQL Azure d'hébergement ?
• Le nombre de nœuds à chaque niveau de synchronisation ?
• Le périphérique cible peut façon réaliste en charge un processus de synchronisation ?
• Quelle est l'exigence aux délais de synchronisation de données ?

Que se passe-t-il ’s plus, chacune de ces questions possède plusieurs couches qui doivent être pris en compte et par rapport à laquelle la conception des solutions possibles doit être validée. Il n'existe pas d'une conception à celui de tout, j'aime démarrer avec le modèle décrit plus haut et soit synchroniser plusieurs synchronisation à sens unique pour faire quelque chose de similaire à la synchronisation de données bidirectionnelle ou une synchronisation bidirectionnelle d'utilisation entre le périphérique / d'entreprise de la base de données et SQL Azure. Après quoi, je recherche des scénarios d'invalident et de forcer une modification apportée à la conception. En règle générale, le style de la synchronisation uniquement que je tente d'éviter les est égal à égal.

Configuration de synchronisation

Il existe deux méthodes pour configurer la synchronisation à l'aide de la Sync Framework 2.1 : client de la synchronisation dans le client de nuage et de synchronisation sur l'ordinateur local. Je me concentrerai sur ces dernières pour l'instant. À sa plus simple, voici la procédure pour configurer une relation de synchronisation :

1. Identifier les données puissent être synchronisées et la direction du flux de données. Ceci sera utilisé pour définir les étendues (SqlSyncScopeProvisioning) utilisés pour synchroniser les données.
2. Téléchargez et installez le 2.1 de Framework Sync (bit.ly/gKQODZ ). Remarque : Si x 64 est la plate-forme cible, une cible de génération pour x 64 s'il faut ajouter ou le SyncOrchestrator ne sera pas en mesure de résoudre ses dépendances .
3. Mise en service les bases de données et les tables pour la synchronisation ;la base de données entière peut être mis en service ou uniquement des tables spécifiques ou il peut être limitées à la donnée des colonnes.
4. Ajouter des filtres nécessaires. Dans le cas où il est souhaitable pour partitionner horizontalement ou sinon filtre les données, les filtres peuvent être utilisés.
5. Créer et exécuter le processus de synchronisation.

J'ai serez spécifique au lieu de cela dans cet exemple, tel qu'il vous permet de transmettre le message et je vais commencer par les bases de données en place deux extrémités. Créer une connexion à la base de données locale et de l'extraire d'une définition (DbSyncTableDescription) pour la table être synchronisé et ajoutez cette table à l'étendue (DbSyncScopeDescription). En outre, je vais spécifier les colonnes particuliers, mais ce n'est pas nécessaire si le désir est simplement de synchroniser la totalité du tableau. Limitation de la relation de synchronisation à des colonnes spécifiques est un bon moyen pour optimiser l'utilisation de la bande passante et à accélérer le processus (voir la rubrique de la figure 3 ).

La figure 3 Création d'une étendue de la synchronisation,

SqlConnection azureConn = new SqlConnection(AzureConnectionString);
SqlConnection onPremiseConn = new SqlConnection(LocalConnectionString);

// List of columns to include
Collection<string> columnsToInclude = new Collection<string>();
columnsToInclude.Add("au_id");
columnsToInclude.Add("au_lname");
columnsToInclude.Add("au_fname");
columnsToInclude.Add("phone");
columnsToInclude.Add("address");
columnsToInclude.Add("city");
columnsToInclude.Add("state");
columnsToInclude.Add("zip");
columnsToInclude.Add("contact");

// Definition for authors from local DB
DbSyncTableDescription authorsDescription =
  SqlSyncDescriptionBuilder.GetDescriptionForTable("authors", 
  columnsToInclude, onPremiseConn);

// Create a scope and add tables to it
DbSyncScopeDescription authorScopeDesc = new DbSyncScopeDescription(ScopeName);

// Add the authors table to the sync scope
authorsScopeDesc.Tables.Add(authorsDescription);

Pour chaque structure doit être synchronisé, un peu de code devra être ajouté pour obtenir la description ;Vous devez l'ajouter par la suite à l'étendue. L'étape suivante consiste à extraire un objet de mise en service de portée et l'utiliser pour configurer chaque base de données si l'étendue n'est pas déjà exister dans cette base de données, comme dans de la figure 4 .

La figure 4 mise en service de l'étendue de

// Create a provisioning object for "customers" and 
// apply it to the on-premises database
SqlSyncScopeProvisioning onPremScopeConfig = 
  new SqlSyncScopeProvisioning(onPremiseConn, authorsScopeDesc);
if (!(onPremScopeConfig.ScopeExists(authorsScopeDesc.ScopeName)))
{
  onPremScopeConfig.Apply():
}
// Provision the SQL Azure database from the on-premises SQL Server database
SqlSyncScopeProvisioning azureScopeConfig = 
  new SqlSyncScopeProvisioning(azureConn, authorsScopeDesc);
if (!(azureScopeConfig.ScopeExists(authorsScopeDesc.ScopeName)))
{
  azureScopeConfig.Apply();
}

Dans la mesure où il s'agit de la première fois que la portée a été mise en service dans la base de données, il y aura des nouvelles tables pour stocker les informations d'étendue et également une table en particulier pour le suivi de l'étendue d'auteurs qui a été mise en service dans les bases de données.Vous trouverez un bon exemple d'une application console à mise en service ou synchroniser une locale et la base de données SQL Azure sur le Blog de l'équipe Sync Framework à bit.ly/dCt6T0 de .

Encadré : Synchronisation des données Azure SQL

Synchronisation de données SQL Azure est un service basé sur le nuage, hébergé dans Azure Windows qui permet la synchronisation des bases de données complètes ou des tables spécifiques entre SQL Server et SQL Azure.À Microsoft Professional Developers Conference 2010, nous avons annoncé une mise à jour pour ce service appelé SQL Azure données Sync Community Technology Preview (CTP) 2.Cette mise à jour offre aux entreprises d'étendre facilement les bases de données sur les installations SQL Server pour le nuage, ce qui permet de migration par phases des applications pour le nuage.Solutions tirant parti de synchronisation de données SQL Azure permettra aux utilisateurs de continuer à accéder aux modifications de données et que locales en toute transparence synchronisées avec SQL Azure lorsqu'elles se produisent.De même, toutes les modifications apportées par les applications pour SQL Azure sont synchronisées au serveur sur les installations SQL Server.

Conserver les données en synchronisation

Synchronisation de données SQL Azure fournit un système de gestion centralisée de nuage pour toutes les relations de synchronisation.À partir de n'importe quel navigateur, les administrateurs peuvent se connecter au service public et de gérer et analyser les différents points de terminaison de base de données.En outre, la synchronisation de données SQL Azure fournit un service de planification qui permet la synchronisation puisse avoir lieu que souvent sous forme de toutes les cinq minutes ou moins fréquemment si l'option est d'exécuter la synchronisation aux heures creuses.

Dans la récente mise à jour SQL Azure Data Sync CTP 2, nous avons également introduit un nouveau composant appelé agent de synchronisation de données SQL Azure.Cet agent est un Service Windows qui a installé sur les lieux et lie les bases de données SQL Server locales pour la synchronisation de données SQL Azure via une connexion HTTPS sortante sécurisée, ce qui signifie qu'il n'y a aucune exigence d'un point de vue de pare-feu ou de la configuration de sécurité, qui rend le programme d'installation, un composant logiciel enfichable.Tâche de l'agent est de contrôler et consigner tâches ainsi que pour lancer des demandes de synchronisation à partir de la synchronisation de données SQL Azure.

Nouveaux scénarios

Avec la synchronisation de données SQL Azure, la synchronisation entre les bases de données SQL Server et SQL Azure prévoit un grand nombre de nouveaux scénarios qui, dans le passé étaient très difficiles à générer.Imaginez que vous souhaitez partager avec vos succursales des données ou le magasin de bases de données de détail.Avec la synchronisation de données SQL Azure, il est facile, car les administrateurs de créer “ Sync «groupes qui définissent des données à partager entre les bases de données».Ces groupes de synchronisation peut contenir un serveur SQL d'entreprise qui synchronise les données à un Azure SQL centralisée “ Hub Data. ” Puis, à partir de ce concentrateur de données, toutes les bases de données SQL Server distants ou régionales peuvent synchroniser les modifications de données, qui les autorise à importer des données de plus près les utilisateurs, tout en réduisant considérablement la bande passante et la configuration requise pour les réseaux privés virtuels ou VPN.

En outre, la possibilité de synchroniser entre plusieurs centres de données SQL Azure permet facilement d'évolution horizontale de charges dans le monde entier.Imaginez que vous disposez de rapports trimestrielle exigences placer une charge cyclique énorme sur votre base de données SQL Server.Pourquoi ne pas synchroniser certains de ces données pour vos bases de données SQL Azure dans le monde entier lorsque cela est nécessaire ?Puis les utilisateurs peuvent accéder les données le plus proche d'eux tout en réduisant les exigences d'évolutivité de votre serveur SQL Server local.

Pour plus d'informations et inscrivez-vous pour participer à la version CTP 2, visitez le site de microsoft.com/en-us/sqlazure/datasync.aspx.

— Liam Cavanagh, Senior Program Manager, SQL Data Azure Sync

Synchronisation des données

Une fois que les bases de données sont correctement mis en service, il est assez simple obtenir leur synchronisation.Elle nécessite la création d'un SqlSyncProvider pour chaque fin de l'activité avec la portée spécifiée.Ceci implique l'utilisation de l'objet SyncOrchestrator, qui est la magie derrière les rideaux qui identifie les modifications apportées et déplace les changements entre les deux.Ce code ressemble à quelque chose comme ceci :

SqlConnection LocalConnection = new SqlConnection(LocalConnectionString);
SqlConnection AzureConnection = new SqlConnection(AzureConnectionString);

SqlSyncProvider LocalProvider = new SqlSyncProvider(ScopeName, LocalConnection);
SqlSyncProvider AzureProvider = new SqlSyncProvider(ScopeName, AzureConnection);

SyncOrchestrator orch= new SynOrchestrator();
orch.LocalProvider = new SqlSyncProvider(ScopeName, LocalConnection);
orch.RemoteProvider = new SqlSyncProvder(ScopeName, AzureConnection);
orch.Direction = SyncDirectionOrder.DownloadAndUpload;
orch.Synchronize();

Données et la dispersion géographique

Avec une reproduction simple du traitement de données, je me concentrer sur l'optimisation du flux de données et de l'architecture de déploiement. À l'aide de la Sync Framework, je peux spécifier des filtres ;Ceci en combinaison avec SQL Azure peut être vraiment un avantage considérable dans les architectures de nœud de branche. À l'aide de la combinaison des deux, je peux placer les données de plus près le consommateur final et optimiser l'utilisation de la bande passante (et par conséquent, les frais) en se synchronisant uniquement les données pertinentes pour cette segmentation de données ou de région. Au lieu d'utiliser des serveurs de données dans différentes zones géographiques, simplement les données peuvent être synchronisées vers une instance de SQL Azure dans cette zone géographique, et ces clients dans cette zone peuvent synchroniser à celui-ci.

En répartissant les données autour de géographiquement et en implémentant des étendues de sens de la synchronisation des données avec une fréquence spécifique, un peut obtenir un contrôle précis sur quoi, comment, quand et quelle quantité de données transmise sur le réseau, l'amélioration de l'utilisateur confronté par rapport à la disponibilité des données et d'actualité. En outre, pour les utilisateurs qui peuvent se déplacent entre les emplacements où il serait intéressant de savoir à l'emplacement, l'agent de synchronisation pourrait trouver lui-même et en contact avec les données de synchronisation spécifiquement pour l'emplacement actuel. Deux des exemples sont en cours statistiques ou des alertes pour les travailleurs de marchant dans un environnement d'usine/et les ventes du jour courant pour les responsables régionaux des chaînes de magasins (voir la rubrique de la figure 5 ).

La figure 5 synchronisation des données avec les filtres

L'activation du filtrage est non plus difficile que la mise en service d'une étendue de la synchronisation. Par conséquent, il peut y avoir plusieurs étendues existantes qui ont différents filtres, ou n'ont aucune. Le changement nécessaire consiste simplement à ajouter les deux lignes de code pour chaque filtre est ajouté : une ligne pour ajouter une colonne de filtre à la table et la seconde pour ajouter la clause de filtre, qui est en fait une condition “ où ”. Pour mon exemple, j'ajoute un filtre reposant sur l'état et la synchronisation modifie uniquement pour l'état d'Utah, ou UT, comme suit :

onPremScopeConfig.Tables["authors"].AddFilterColumn("state");
onPremScopeConfig.Tables["authors"].FilterClause = "[authors].[state] = 'UT'";

Si je souhaite pouvoir les synchroniser dans les deux directions en fonction du filtre, elle devra être ajouté pour les deux étendues comme ils sont mis en service à chaque extrémité.

Forth de rendez-vous et les données de répartition par période

Ajout de SQL Azure à la combinaison, si une instance unique ou plusieurs autres, peut réellement améliorer la disponibilité des données et les performances globales du lors de la synchronisation pour les nœuds en ajoutant cette couche d'indirection jamais importante. Car il s'agit SQL Azure, une Obtient des performances, évolutivité et fiabilité sans tous les problèmes de conception, la mise en service et la gestion de l'infrastructure. Recherchez la chronique du mois prochain, où I vous développez sur la mise en œuvre et afficher la manière dont Windows Azure vous pouvez ajouter à la combinaison de synchronisation à l'aide de la CTP de 4.0 dernière Sync Framework, publiée en octobre (bit.ly/dpyMP8 ).

Joseph Fultz est architecte au Microsoft Technology Center de Dallas, où il travaille avec les clients d'entreprise et les éditeurs de logiciels prototypage et de concevoir des solutions logicielles pour répondre aux exigences métier et du marché. Il est parlé au niveau des événements tels que Tech·Ed et les événements de formation interne similaire.

Grâce à l'expert technique suivante pour la révision de cet article : David Browne