Avant d’étudier les solutions envisageables pour répondre à la problématique posée, faisons un petit rappel de ce qu’est Azure Sql.
Azure SQL est un service Azure pour les bases de données. Un service PaaS (Platform as a Service) complètement managé qui prend en charge la plupart des fonctions de gestion de base de données telles que la mise à niveau, la mise à jour corrective, les sauvegardes et la surveillance.
Ce service Azure SQL repose sur un serveur encore appelé moteur de base de données. Pour déployer le service Azure SQL j’ai nécessairement besoin d’un serveur sql (une ou plusieurs VM dédiée pour avoir l’équivalent d’un SQL serveur déployé on-premise ou soit des ressources de calcul, de mémoire et de stockage en mode PaaS dédié ou à la demande en serverless). Pour savoir quel Azure SQL répondrait à vos attentes une première petite qualification sera nécessaire et pour vous aider faites un tour sur le lien ci-après:SQL Azure | Microsoft Azure
La base de données à créer pour un service Azure SQL Database peut être:
- Unique! pour une base de données isolée et autonome avec des ressources dédiées et scalables
- un niveau de service « à usage général/Standard » pour de 1 à 80 vCores, ou de 32 Go à 4 To
- un niveau de service « Critique pour l’entreprise/Premium » adapté aux applications nécessitant des débits de transactions élevés et la latence des E/S la plus faible
- un niveau de service « hyperscale » pour avoir une mise à l’échelle jusqu’à 100 To adapté aux bases de données très volumineuse.
- Pool élastique pour une ou plusieurs bases de données partageant les mêmes ressources.
Le rappel étant fait revenons maintenant à notre problématique, Comment copier une base de données Azure SQL Database entre abonnements ?
1 serveur SQL nommé « avbsqlserver », nom complet « avbsqlserver.database.windows.net »
Ce serveur « avsqlserver » contient 1 pool élastique (un pool de ressources qui peuvent être partagées par plusieurs bases de données) utilisé par 1 seule base de donnée dans notre cas, « AvbElasticPoolDatabase », affectée au pool, le serveur contient aussi 1 base de donnée « AvbHyperscaleDatabase » avec Niveau de service Hyperscale et une troisième base de donnée « AvbSingleDatabase » qui est un single Azure Sql Database.
Si la mission était de déplacer tout le serveur avec donc les 3 bases de données de la souscription source à une souscription cible, la tache serait très simple en utilisant Move. Il suffirait d’aller sur la ressource « avsqlserver » et d’utiliser la fonction Move qui peut bien sûr se faire avec API REST, PowerShell ou encore Azure CLI.
La demande ne consiste par à déplacer le serveur ni les toutes bases de données qu’il contient mais de disposer de la copie d’une seule des 3 bases de données du serveur « avsqlserver » dans une autre souscription.
Alors, faisons l’exercice avec « AvbHyperscaleDatabase » de la souscription PROD vers la souscription HPROD par exemple.
Essayons malgré tout Move pour voir si nous pouvons atteindre l’objectif qui nous est assigné sans oublié:
1- nous sommes sur une souscription en PROD (Production)
2- « AvbHyperscaleDatabase » partage un même serveur avec d’autres bases de données qui elles ne sont pas concernées par le projet.
3- La cible c’est la souscription HPROD donc une souscription différente de la PROD.
Premier réflexe: Si j’utilisais les sauvegardes automatisées de SQL Database pour faire une restauration ?
Pour SQL Database, cette opération crée une nouvelle base de données sur le même serveur que la base de données d’origine, mais sous un nom différent pour éviter de remplacer la base de données d’origine.
Zut alors! Si je ne peux pas restaurer SQL Database sur un nouveau serveur à créer lors de la restauration ou un serveur différent je ne peux donc pas utiliser la solution Move qui rappelons le, déplace tout le serveur d’un environnement à un autre et ce n’est pas notre objectif.
Deuxième réflexe: Si je me connectais à SQL Database avec Azure Data Studio ou Visual Studio ou encore SSMS (SQL Server Management Studio) ? Je peux faire un backup (créer un fichier BACPAC) puis récupérer le fichier pour créer la nouvelle base de donnée dans une autre souscription ?
Je peux beau voir « Backup » mais Azure Data Studio ne permet pas encore de faire le backup et la restauration de SQL Database. Je vais donc voir coté SSMS (SQL Server Management Studio).
J’ai donc pu, avec SSMS, créer un fichier BACPAC (par un Export Data-Tier Apllication) de ma SQL Database. Ce fichier je l’ai stocké en local comme vous pouvez le constater mais vous pouvez aussi le stocker directement dans un Azure Storage Account. Je vais donc pouvoir maintenant faire un IMPORT du fichier BACPAC pour créer une nouvelle base de données SQL Azure dans le nouveau serveur créé préalablement dans la souscription cible en utilisant le portail Azure, PowerShell, Azure CLI, SSMS ou SqlPackage.
Alors toujours avec SSMS, je me connecte cette fois au serveur cible de la souscription HPROD. En faisant bouton droit sur « Databases » du SQL Serveur cible (tesdelabaz.database.windows.net) je choisis de faire « Import Data-Tier Application ». Attention, il faudra choisir le niveau de service dans mon cas « Hyperscale » comme la source.
Résultat : j’ai pu répondre à la demande en utilisant SSMS.
Toutefois cette méthode peut être fastidieuse si la volumétrie de la base de donnée est élevée comme souvent le cas avec les SQL Database Hyperscale qui peuvent contenir jusu’aà 100 To. Alors nous allons essayer une autre piste.
Troisième réflexe: Pourquoi ne pas simplement utiliser la fonction « COPY » de Sql Database pour répondre au besoin ?
Quand on regarde sur le portal.azure.com en allant sur la ressource serveur SQL nommé « avbsqlserver » puis en choisissant l’une des 3 bases de données qu’il contient, pour ce qui nous concerne « AvbHyperscaleDatabase »
En activant la copie depuis la base de donnée « AvbHyperscaleDatabase » pour en faire une copie
2 observations majeures:
1- La partie Souscription est grisée ce qui veut dire que je ne peux pas faire cette copie d’une souscription source vers une souscription cible. Alors ma copie peut se faire dans la même souscription et prendra évidemment un autre nom donc « AvbHyperscaleDatabase_Copy » dans ce cas.
2- Par défaut, la copie se fera sur le même serveur « avbsqlserver » mais je peux choisir un autre ou créer un nouveau dans la même souscription alors que j’aurais préféré en créer dans ma souscription cible.
Alors comment pouvoir répondre à la problématique: copier une base de donnée SQL Database d’une souscription à l’autre en utilisant la fonction COPY de SQL Database ?
Il faudra dans ce cas utiliser la fonction COPY en prévoyant la création d’un nouveau serveur dans le processus ou avant puis en utilisant MOVE pour déplacer le nouveau serveur créé contenant la copie de la SQL Database vers la souscription cible.
Résultat des courses:
- Utiliser la fonction COPY de Azure SQL Database pour créer une copie de la base de donnée source
- Créer un nouveau SQL Serveur lors de la Copie de SQL Database ou avant dans la même souscription source et le choisir pour contenir la SQL Database copiée.
- Utiliser la fonction MOVE depuis le nouveau SQL Serveur pour le déplacer vers la souscription cible.
Nous avons comme résultat 2 Serveurs SQL, le premier « avbsqlserver » qui est le serveur source rappelez vous contient 3 Azure SQL Database dont « AvbHyperscaleDatabase » que nous avons copié en « AvbHyperscaleDatabase_Copy » en le mettant dans le nouveau serveur « avdsqlservercible » qui est déplacé de la souscription « Source PROD » vers la Souscription « Cible HPROD »
Nous pouvons aussi envisager d’autres scénarios de copie avec Azure Data Factory (articles en cours) pour répondre à cette problématique.
Vous devez être connecté pour poster un commentaire.