Réplication de données vers Azure SQL Databases

SQL Server 2016 est disponible depuis quelques semaines. De part les missions de consulting que j’effectue, je suis en contact avec un certain nombre de sociétés (un peu plus de 120 à ce jour). Cela me permet d’avoir un éventail relativement représentatif de secteurs d’activité, de taille de structure, de niveau de maturité pour la virtualisation ou le cloud, de niveau de compétence des personnes (et de confiance dans les personnes) en charge des serveurs SQL (le DBA par accident n’est pas un mythe …), de configuration matérielle, de niveau de performance attendu, de taille de bases, de RPO ou RTO …

Attention : ne vous méprenez pas, ne voyez aucune connotation négative sur le point relatif à la compétence du DBA. Mais imaginez un parc informatique de 500PCs, 25 serveurs et seulement 2 personnes pour tout gérer, du changement de toner dans l’imprimante au patch d’un serveur RDS, de la téléphonie au serveur de base de données, ou du WiFi à la messagerie. Difficile de trouver du temps pour se former, difficile également de faire valoir à son Boss le bien fondé d’une formation SQL Server représentant 5 ou 10% de son activité.

Bref, j’ai la chance d’avoir un panel large extrêmement intéressant quand il s’agit d’analyser le marché, de voir son évolution, autrement que par l’approche purement technique des fonctionnalités offertes par chaque version de SQL Server.

L’arrivée d’une nouvelle version de SQL suscite généralement des réactions du style : “Déjà, cela va trop vite, impossible de suivre le rythme.”, ou “Excellent ces nouvelles fonctionnalités, on migre quand ?”, ou encore “Moi, de toute manière, je ne l’installerai que lorsque le SP1 sera sorti, cela évite les bugs !”.

J’aurais tendance à éluder la dernière remarque. La stratégie de Microsoft est relativement claire depuis quelques temps : Cloud first, mobile first. Et le cloud pour SQL Server c’est tout simplement Azure SQL Databases, la base de donnée en version PaaS. Les fonctionnalités sont d’abord mises en production sur SQL Azure avant d’être “packagées” dans la version OnPremise que vous et moi installons. Difficile de dire alors que le produit n’est pas testé lorsqu’il y a déjà plusieurs millions de bases en production sur cette version ! Sans compter avec le programme TAP où Microsoft accompagne des clients sur des mises en production alors que el produit n’est pas finalisé.

A présent, il faut se rendre à l’évidence. La virtualisation est monnaie courante pour les bases de données. Même pour des serveurs de type “Tier 1”, fortement sollicités. Attention, toutefois, il faut faire les choses dans les règles de l’art. N’hésitez pas à me contacter le cas échéant.

L’étape suivante, pourrait tout a fait consister à déplacer l’infrastructure sur un cloud public (IaaS) pour bénéficier facilement de redondance (géographique), de services ou de ressources  supplémentaires, etc … J’accompagne également mes clients dans cette démarche, que ce soit sur plateforme Azure, Amazon ou autre. Les VMs chez voter hosteur favori sont à classer dans cette catégorie.

Au bout de la chaine, pour éviter les phases fastidieuses d’installation de l’OS, de SQL Server, le paramétrage ou les sauvegardes des bases de données, il est possible d’opter pour le PaaS, Azure SQL Database.

Pour être tout a fait honnête, cela fonctionne. Plutôt bien même. Le service est rendu, avec un très bon taux de disponibilité. Mais attention à la performance ! Le développement de l’application doit être adapté pour éviter les allers-retours enter le client et le serveur. La latence réseau peut être problématique.

Et puis il reste la phase de migration vers cette base dans le nuages. C’est souvent le point le plus problématique. On ne peut pas faire de restaure database (SVP Microsoft, autorisez au moins le restaure depuis un compte de stockage Azure …).

Il y a la possibilité d’utiliser les BacPacs. Un fichier Zip qui contient a la fois les données et la structure de la base. On peut ensuite déployer ce fichier pour créer la base sur Azure. Fonctionnel, mais j’avoue en pas être fan de cette solution. Imaginez juste ce que cela pourrait donner avec une base de 250 Gb !

Il reste la possibilité de créer le schéma des objets manuellement et de procéder au transfert des données via SSIS ou BCP. Fastidieux. Heureusement que des outils comme SQL Database Migration Wizard (SQLAzureMW) automatisent avec succès ces tâches. Encore une fois pour des très grosses bases, cela peut être loooong (SVP Microsoft, autorisez au moins le restaure depuis un compte de stockage Azure …).

Avec SQL Server 2016, mais la solution set rétro compatibles avec des versions plus anciennes munies du dernier service pack, il est également possible de déplacer des données via la réplication. Principe relativement ancien sur des serveur OnPremise, il est à présent possible d’ajouter en abonné une base SQL Azure. Le champs de possibilités est assez intéressant : de la recopie des données pour du ScaleOut au un portail sur internet pour présenter quelques infos à des clients/partenaires. Le principe peut également être utilisé pour migrer progressivement une base dans le cloud.

La mise en place est plutôt simple, comme on va le voir.

Etape 1 : création de la base sur un serveur dans Azure, via le portail :

image

Si vous n’avez pas encore de serveur, il faut en créer un, ou sinon, aller directement sur Bases de données SQL pour créer l’abonné.

image

Donnez un nom à votre base et sélectionnez le niveau tarifaire correspondant en fait aux performances attendues (pour ce test, le niveau basique est largement suffisant).

image

Cliquer ensuite sur le bouton créer et après quelques secondes la base de donnée est opérationnelle.

image

Il set à présent possible de se connecter à cette base de donnée vie SSMS (vérifiez quand même que le firewall Azure ait bien autorisé votre IP sur le serveur SQL).

image

image

Notez au passage que SQL Azure possède déjà un numéro de version plus élevé que mon serveur SQL 2016 RTM. La notion de mise à jour “continue” est assez intéressante, et pourrait tout a fait être portée sur al version OnPremise, comme Windows en fait.

Il reste à présent à configurer la réplication, d’abord le distributeur et l’éditeur. Ces deux fonctions seront supportées par le serveur SQL 2016. Je ne détaille pas les écrans car il y a rien de nouveau dans el fait de créer une réplication transactionnelle.

image

Il faut à présent configurer l’abonné. En abonnement poussé car il n’y a pas d’agent sur SQL Azure.

imageimageimageimageimageimageimageimageimageimageimageimage

Une fois l’agent de snapshot exécuté, et après quelques secondes, les tables et les données doivent apparaitre sur SQL Azure

image

Les donnes sont visibles dans SSMS

image

et le portail Azure permet de suivre la consommation de ressources.

image

Parfaitement opérationnel et semblable en tous points à un abonnement sur un serveur OnPrem, cette fonctionnalité offre de nouveaux cas d’usage pour SQL Azure.

Il reste qu’Azure SQL Databases est un service managé. Vos bases, elles, ne le sont pas.

Ma société est aujourd’hui en mesure de vous offrir non seulement l’hébergement de vos bases de données, mais aussi leur gestion au quotidien. La puissance du  Cloud associée au service d’un DBA, expert SQL Server. Ni vous avez des questions, contactez moi.

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM SQL Server 2008
Cet article, publié dans SQL Azure, SQL Server, est tagué , , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s