Synchronize Azure Data Today in Production–Synchroniser des données Azure aujourd’hui en production

 

English	Français
A common requirement for Azure is the ability to replicate and/or synchronize data between SQL Azure and Windows Azure storages in different datacenters, but also with on premises SQL Server databases and files.	Une besoin classique pour Azure est la possibilité de répliquer et/ou de synchroniser des données entre SQL Azure et des stockages Windows Azure dans différents centres de calculs, mais aussi avec les bases de données SQL Server et fichiers à demeure.
The difference I make here between synchronization and replication is that synchronization is asynchronous (sic!) and it is done by batch while replication is done on the fly.	La différence que je fais ici entre synchronisation et réplication est que la synchronisation est asynchrone (sic!) et qu’elle est faite par lot alors que la réplication est faite à la volée.
Here are a few scenarios where this may be necessary: - have an application running in different datacenters around the world for global presence (Windows Azure Traffic manager will also help routing users to the right datacenter in the future) - have an application running in Azure and get data on premises for Business Intelligence (BI) consumption - have back office tools running against an on premises database while front office Web site is hosted in Azure with its own database	Voici quelques scénarios où cela est nécessaire: - Avoir une application qui tourne dans différents centres de calculs autour du globe pour une présence mondiale (Windows Azure Traffic manager aidera d’ailleurs à router les utilisateurs vers le bon centre de calcul dans le futur) - Avoir une application qui tourne dans Azure et récupérer les données à demeure pour une consommation en mode Business Intelligence (BI) - Avoir des outils de back office qui s’exécutent sur une base de données à demeure alors que le site front office est hébergé dans Azure avec sa popre base de données.
NB: A disaster recovery plans is beyond the scope of this article; SQL Azure and Windows Azure storage (blobs, non relationnal tables, queues) are highly available services but that’s not the whole disaster recovery story that includes the ability to come back in time, or survive a datacenter disaster.	NB: La notion de DRP (disaster recovery plan) va au delà de la portée de cet article; SQL Azure et le stockage Windows Azure (les blobs, tables non relationnelles, queues) sont des services hautement disponibles mais cela ne suffit pas et n’inclut pas par exemple des notions de retour arrière ou de reprise sur désastre dans un centre de calcul entier.
Before going forward with synchronization and replication, I just wanted to make sure you are aware of a powerful tool that helps migrating a SQL Server database to a SQL Azure database. It is called SQL Azure Migration Wizard. I’ve done a short screencast that shows how to create a SQL Azure database from a SQL Server database. SQL Azure Migration Wizard can be downloaded from https://sqlazuremw.codeplex.com/	Avant d’avancer sur la synchronisation et la réplication, j’aimerais mentionner l’existence d’un outil assez puissant pour migrer une base de données SQL Server vers une base SQL Azure. Il s’appelle l’assistant de migration SQL Azure (SQL Azure Migration Wizard). J’ai fait une une petite vidéo qui montre comment créer un base SQL Azure à partir d'une base SQL Server.   L’outil peut être téléchargé à l’adresse https://sqlazuremw.codeplex.com/
Let’s now come back to synchronization and replication.	Revenons à la synchronisation et à la réplication.
SQL Azure Data Sync will do a great job for SQL Server and SQL Azure synchronizations. It can be tested today between SQL Azure databases in the labs environment. But it is not available yet and there are scenarios that SQL Azure Data Sync will not cover in the first place.	SQL Azure Data Sync sera un service très utile et pratique pour les synchronisations SQL Server et SQL Azure. On peut le tester aujourd’hui entre bases SQL Azure dans l’environnement de labs. Mais il n’est pas encore disponible et il reste des scénarios que SQL Azure Data Sync ne couvrira pas dans sa première version.
SQL Server has great replication features like log shipping (cf https://mission-critical.archims.fr for additional information) that SQL Azure does not have (yet ?).	SQL Server a d’excellentes fonctionnalités comme le log shipping (cf https://mission-critical.archims.fr pour plus d’information) que SQL Azure n’a pas (encore ?).
So which production ready technologies can one rely on today to achieve synchronization or replication for Azure data?	Ainsi, quelles technologies prêtes en production peuvent être utilisées pour mettre en oeuvre la synchronisation ou la réplication pour des données Azure?
The following is considered here. An application lives in two different Azure datacenters (ex: US and Europe) and two on-premises datacenters. In Azure, data is stored in SQL Azure and Windows Azure storage (blobs and tables). On premises, data is stored in SQL Server and NTFS files. All these data stores need to synchronize or replicate.	On suppose le cas suivant. Une application est hébergée dans deux centres de calculs Azure (ex: USA et Europe) et deux centre de calculs à demeure. Dans Azure, les données sont stockées dans SQL Azure et dans du stockage Windows Azure (blobs et tables). A demeure, les données sont stockées dans SQL Server et des fichiers NTFS. Toutes ces entrepôts de données ont besoin d’être synchronisés ou répliqués.

One option is to have the application calling other data stores when a local write is done so that it is also done elsewhere. For instance if application in location A creates a new customer, it can write it locally, but also to SQL Azure in location B, and SQL Server in location C and SQL Server in location D. This approach has a few drawbacks: - You better have the application handling all the additional writes asynchronously so that user does not have the latency penalties from A to the other locations - if the application is an existing application with thousands of lines of code, changing that amount of code may not be a good choice.	Une des options est de faire en sorte que l’application appelle les autres entrepôts de données quand une écriture locale est faite, de façon à ce qu’elle soit aussi effectuée ailleurs. Par exemple, si l’application située en A crée un nouveau client, elle peut l’écrire localement, mais aussi dans SQL Azure en B, SQL Server en C et SQL Server en D. Cette approche a quelques inconvénients: - il est nécessaire de faire en sorte que l’application effectue ses écritures complémentaires de façon asynchrone de façon à ce que l’utilisateur ne soit pas pénalisé par les latences entre A et les autres lieux - Si l’application est une application existante avec des dizaines de milliers de lignes de code, changer tout ce code peut ne pas être une bonne option.
Note that an instance of the application on premises may have access to SQL Azure in the cloud provided that it has the right connection string, it has an outbound connection to the Internet that uses port 1433, and that the SQL Azure firewall has been setup to accept calls from that IP address.	Il est à noter qu’une instance de l’application à demeure peut accéder à SQL Azure dans le nuage pour peu qu’elle ait la bonne chaîne de connexion, qu’elle ait une connexion sortante sur Internet qui utilise le port 1433, et que le pare-feu SQL Azure ait été configuré pour recevoir des appels depuis cette adresse IP.
On the other side, an instance of the application in Azure may have access to SQL Server on premises thru web services that can be exposed to the Internet by classical means or thru Azure AppFabric Service Bus & Access Control (it enables exposing a privately hosted web service to the Internet with access control). Also note that Azure Connect (still in beta for now) leverages IPSec to connect Azure roles with on premise servers; it will also be an option when it becomes available in a production ready version.	A l’inverse, une instance de l’application dans Azure peut accéder à SQL Server à demeure via des services web qui peuvent être exposés sur Internet par des moyens classiques, ou via Azure Service Bus & Access Control (qui permet d’exposer des services web hébergés de façon privée sur Internet avec un contrôle d’accès). Il est également à noter qu’Azure Connect (toujours en bêta pour l’instant) s’appuie sur IPSec pour connecter des rôles Azure à des serveurs à demeure; ce sera également une option quand cela deviendra disponible dans sa version de production.
Another approach is to have each data store remember what it changes then synchronize. This is vastly automated by the Sync Framework which enables that scenario for different kinds of data stores. The latest production ready release in 2.1. Next version is 4.0 but it is still in CTP and mainly adds synchronization over OData protocol in order to help synchronizing with other devices like mobile phones; this is not what this article is looking for. Moreover, the Sync Framework 4.0 release has been postponed (the team is focusing on SQL Azure Data Sync).	Une autre approche est de faire en sorte que chaque entrepôt de données se souvienne de ce qu’il a changé puis synchroniser ensuite. Cela est très grandement automatisé par le Sync Framework qui permet cela pour différents type d’entrepôts de données. La dernière version de production est la 2.1. La version suivante, 4.0, est toujours en CTP et a pour principal but d’ajouter la synchronisation à travers le protocole OData de façon à permettre la synchronisation avec d’autres appareils tels que les téléphones portables; cela ne correspond pas à l’objet de cet article. De plus, la sortie du Sync Framework 4.0 a été reportée (l’équipe est concentrée sur SQL Azure Data Sync).
So Sync Framework 2.1 is considered here. Its documentation can be found in MSDN library. It is instrumented for SQL Server and SQL Azure as shown in the following blog post by the Sync Framework team:	On considère donc l’utilisation du Sync Framework 2.1. Sa documentation est disponible dans la librairie MSDN. Il fonctionne en particulier pour SQL Server et SQL Azure comme le montre le billet suivant de l’équipe du Sync Framework:

SQL Server to SQL Azure Synchronization using Sync Framework 2.1 (webcast)

Please also make sure to read these additional blog posts, as well as comments that are also interesting:

Voir aussi les billets suivants qui sont également intéressants:

How to Sync Large SQL Server Databases to SQL Azure

Walkthrough of Windows Azure Sync Service Sample

Sync Framework: SQL Server to SQL Azure Synchronization

 

Sync Framework is compared to replication mechanisms in SQL Server 2008 R2 documentation. Note that one advantage of Sync Framework is that it can also synchronize other types of storage like files (on premises) and blobs (in the cloud) as shown in this sample code: https://code.msdn.microsoft.com/Synchronizing-Files-to-a14ecf57 It is also possible to synchronize with other data stores like Oracle databases, PostgreSQL databases, or even Amazon S3 storage service!

Dans cette page de l'a documentation s’SQL Server, le Sync Framework est comparé à des mécanismes de réplication. Il est à noter qu’un des avantages complémentaires du Sync Framework est qu’il peut aussi synchroniser d’autres types de stockages tels que des fichiers (à demeure) ou des blobs (dans les nuages) comme on peut le voir dans l’exemple de code suivant: https://code.msdn.microsoft.com/Synchronizing-Files-to-a14ecf57 Il est aussi possible de se synchroniser avec d’autres entrepôts de données comme des bases de données Oracle, PostgreSQL, ou même le service de stockage Amazon S3!

 

Of course, between SQL Server databases (locations C and D) replication mechanisms like log shipping can still be used.

Bien sûr, entre les bases de données SQL Server à demeure (lieux C et D) des mécanismes de réplication comme le log shipping restent possibles.

 

Summary Contrary to SQL Server, SQL Azure has no replication mechanism. Today, SQL Azure does not have a Synchronization mechanism either, but it is in its roadmap with SQL Azure Data Sync. An application in a datacenter could write to alternate locations in an asynchronous way, but that would be difficult and costly to code, and less efficient than asynchronous synchronization. Sync Framework V2.1 is a good way to develop synchronization between different data stores, should they be relational or non relational (ex: files). Between SQL Server servers, usual ways like log shipping are also still valid.

Résumé Contrairement à SQL Server, SQL Azure n’a pas de mécasnisme de réplication. Aujourd’hui, SQL Azure n’a pas non plus de mécanisme de sycnhronisation, mais c’est dans sa feuille de route avec SQL Azure Data Sync. Une application dans un centre de calcul peut écrire dans d’autres centre de calculs de façon asynchrone, mais cela amènerait à du code complexe et coûteux, et sans doute moins efficace que de la synchronisation asynchrone. Le Sync Framework V2.1 est un bon moyen de développer cette synchronisation entre différents entrepôts de données, qu’ils soient relationnels ou pas (ex: fichiers). Entre serveur SQL Server, les moyens classiques tels que le log shipping restent également valables.

Benjamin