Déverrouiller Azure : comment créer une infrastructure de base de données SQL hautement flexible

Ce n'est un secret pour personne que ces dernières années, l'Infrastructure as a Service et la Platform as a Service sont devenues de plus en plus répandues dans divers projets en raison de leurs capacités, notamment de l'efficacité des ressources et de la flexibilité. En conséquence, Microsoft a consacré beaucoup de temps et d’efforts à créer un environnement convivial dans lequel SQL peut être utilisé.

L'équipe de Social Discovery Group utilise une variété de bases de données, notamment SQL, pour alimenter nos produits. Avec un portefeuille de plus de 40 services mondiaux qui aident à se rencontrer et à se connecter dans le monde entier, notre base d'utilisateurs comprend plus de 250 millions de personnes à travers le monde. Pour garantir la fiabilité de nos produits aux utilisateurs, nous conservons une partie de l'infrastructure clé dans le cloud. Cela contribue à améliorer sa résilience, sa sécurité et sa flexibilité.

Nous sommes très expérimentés dans le déploiement de bases de données de serveurs et de services sur diverses plates-formes, y compris les clusters Kubernetes. Cependant, nous avons été confrontés à la nécessité de rendre une partie de l’infrastructure des bases de données SQL associée dans le cloud Azure aussi flexible, efficace et fiable que possible. Il existe 3 façons d'utiliser SQL dans le cloud Microsoft Azure :

• Base de données Azure SQL
• Instance gérée Azure SQL
• SQL Server sur les machines virtuelles Azure

Après la recherche, nous avons décidé d'utiliser des bases de données Azure SQL. Juste pour clarifier pour ceux qui n’ont jamais entendu parler des bases de données dites Azure SQL, il s’agit de bases de données cloud gérées fournies dans le cadre de Microsoft Azure.

J'ai souligné les avantages suivants :

• Vous n'avez pas à vous soucier des mises à jour ou du support en fin de vie ;
• Configuration et déploiement faciles ;
• Rapidité de déploiement (et donc de développement) et d’évolutivité ;
• La haute disponibilité;
• Tolérance aux pannes ;
• Facilité de sauvegarde ;
• Optimisation des coûts ;
• Un système de surveillance Microsoft Azure intégré.

Parlons maintenant des choses étape par étape et examinons le processus de déploiement et de création d'une base de données. Cela peut être fait à l'aide d'un script Power Shell ou d'Azure CLI, mais par souci de clarté, j'examine le processus à l'aide de l'interface graphique du portail. Pour ce faire, accédez à Azure SQL, cliquez sur « Créer » et sélectionnez « Bases de données SQL ».

Nous spécifions le groupe de ressources, sélectionnons s'il existe un serveur existant ou en créons un nouveau (en indiquant le nom et les données de l'administrateur) et trouvons un nom pour la base de données. Je recommanderais de choisir des packages groupés basés sur DTU (unité de transaction de base de données) avec une combinaison équilibrée de ressources de calcul et de stockage pour nos charges de travail courantes.

Il existe également quelques onglets pour les paramètres : Réseau, Sécurité, Paramètres supplémentaires et Balises ; pour une configuration standard minimale, ceux-ci peuvent rester inchangés par défaut. Ensuite, nous attendons que la base de données soit créée. Ceci termine la configuration minimale et la base est terminée.

La taille des ressources de la base de données peut être modifiée très facilement, littéralement en un clic, et en cas de ressources insuffisantes, nous pouvons définir les paramètres dont nous avons besoin en termes de taille et de performances.

Vous pourrez ensuite vous connecter à votre base de données de la manière que vous préférez depuis l'extérieur, sans oublier d'ajouter votre adresse IP ou votre sous-réseau, ou d'autoriser toutes les connexions dans le pare-feu du serveur sur lequel cette base de données est hébergée.

Il est pratique de se connecter et de gérer davantage via SQL Server Management Studio (SSMS), mais il est également possible de le faire via d'autres outils et le portail Azure lui-même.

En plus d'un point de connexion public, vous pouvez également en créer un privé en ajoutant un serveur au sous-réseau requis et en configurant des zones DNS privées.

En parlant de tolérance aux pannes, nous voyons ici une implémentation très pratique et intuitive du basculement, un groupe de serveurs protecteurs basés dans différentes régions.

Dans Azure, il est possible d'ajouter et de supprimer des bases de données sur des serveurs dans un groupe de basculement, un basculement forcé et un mode de basculement automatique.

Vous pouvez le voir dans la capture d'écran ci-dessous. Trouvons un nom pour le groupe de basculement et mettons le serveur en basculement. La synchronisation des bases de données spécifiées démarrera automatiquement. Le deuxième serveur sera en mode lecture seule. En cas de panne, le trafic est automatiquement basculé vers la deuxième région et les serveurs principal et secondaire changent automatiquement de place.

Mais le basculement n’aidera pas s’il existe un problème au niveau des données dans les bases de données elles-mêmes. Bien sûr, dans ce cas, vous devez créer des sauvegardes. Il est possible de configurer des sauvegardes à la fois au sein du portail et via des outils tiers ou, par exemple, Azure DevOps (dans le pipeline, vous pouvez utiliser la tâche SqlAzureDacpacDeployment + AzureFileCopy). Au sein du portail, les sauvegardes sont configurées dans l'onglet Sauvegardes et les politiques de stockage nécessaires sont définies.

Si vous préférez utiliser des outils de sauvegarde tiers, je vous recommande d’envisager les outils de package Azure DevOps ou SQL.

Le processus de récupération sur le portail lui-même n'est pas très pratique à mon avis. La première chose que vous remarquez est le long temps de récupération des bases de données de test simples. Par exemple, il m'a fallu plus d'une demi-heure pour restaurer une base de données de taille de base de 30 Mo à partir de la sauvegarde d'hier ! Après avoir contacté le support Microsoft Azure, on m'a conseillé d'utiliser des scripts PowerShell pour la récupération et j'ai été informé que la taille de la base de données devait être d'au moins S3 pour le processus de récupération, et que plus tard, la taille pourrait être réduite. Ci-dessous je vais présenter certains de mes scripts et développements sur ce sujet, ils peuvent être améliorés et enrichis mais je suis sûr que beaucoup d'entre vous pourront les trouver utiles.

Je vais vous guider étape par étape :

1. Si PowerShell ISE n'est pas installé sur Windows, téléchargez-le ici : https://github.com/PowerShell/Pohell/releases/download/v7.3.0/PowerShell-7.3.0-win-x64.msi
   https://github.com/PowerShell/PowerShell/releases/download/v7.3.0/PowerShell-7.3.0-win-x86.msi
2. Ensuite, vous devez installer le module Azure : Install-Module Az
3. Après avoir installé le module AZ, importez le module AZ : Import-Module Az
4. Une fois importé, vous pouvez vous connecter à votre compte Azure : Connect-AzAccount. Une fenêtre contextuelle apparaîtra pour vous connecter à votre compte Azure, puis vous serez connecté
5. Exécutez le script PowerShell lui-même.

 “ #Variables in use $Database = Get-AzSqlDatabase -ResourceGroupName "Test" -ServerName "test-serv1" -DatabaseName "dbforscript" $TargetDB = "dbforscript_new" $PITRtimedate = "2022-12-02 10:00:00Z" ##вам нужно увидеть действительную дату и время на портале $PITRSLO = "S3" $PITRNEWSLO = "S0" $PITRedition = "Standard" $failoverGroupRG = "Test" $failoverGroupS = "test-serv1" $failoverGroupDB = "dbforscript" $removedbfromfgRG = "Test" $removedbfromfgS = "test-serv1" $removedbfromfgDB = "XXXXX" $dropreplicaRG = "Test" $dropreplicaS = "test-serv2" $dropreplicaDB = "dbforscript" $sourcedbRG = "Test" $sourcedbS = "test-serv1" $sourcedbDBname = "dbforscript" $sourcedbDBNEWname = "dbforscript_old" $TargetDBNEWname = "dbforscript" “

1 - Ce code lance une restauration de base de données avec un nom différent. Si le nom d'origine de la base de données en cours de restauration est « dbforscript », alors le nom de la base de données restaurée sera dbforscript_new. La base de données restaurée sera SLO version S3 ou supérieure, ce qui est la méthode recommandée pour effectuer cette action, la variable pour cela est $PITRSLO = "S3", vous pouvez utiliser S3 ou supérieure. Après cela, nous réinitialiserons le niveau SLO à celui d'origine, ceci uniquement à des fins de récupération.

 “Restore-AzSqlDatabase -FromPointInTimeBackup -PointInTime $PITRtimedate -ResourceGroupName $Database.ResourceGroupName -ServerName $Database.ServerName -TargetDatabaseName $TargetDB -ResourceId $Database.ResourceID -Edition $PITRedition -ServiceObjectiveName $PITRSLO”

2 - Ce code supprimera la base de données source du groupe de basculement : base de données source : dbforscript.

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $failoverGroupdb | Remove-AzSqlDatabaseFromFailoverGroup -ResourceGroupName $removedbfromfgRG -ServerName $removedbfromfgS -FailoverGroupName $removedbfromfgDB”

3 - Ce code supprimera la base de données réplica du serveur où elle se trouve : dbforscript sur le serveur test-serv2.

 “Remove-AzSqlDatabase -ResourceGroupName $dropreplicaRG -ServerName $dropreplicaS -DatabaseName $dropreplicaDB”

4 - Ce code renommera la base de données d'origine sous un nom différent : après le changement de nom, dbforscript sera dbforscript_old.

 “Set-AzSqlDatabase -ResourceGroupName $sourcedbRG -DatabaseName $sourcedbDBname -ServerName $sourcedbS -NewName $sourcedbDBNEWname”

5 - Ce code renommera la base de données restaurée avec le nom de la base de données d'origine, en renommant dbforscript_new en dbforscript.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDB -ServerName $Database.ServerName -NewName $TargetDBNEWname”

6 - Ce code ramènera le niveau SLO de votre base de données à la valeur S0 précédente (originale). si votre base de données est basique, vous pouvez passer de S0 à basic après avoir accédé au portail.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDBNEWname -ServerName $Database.ServerName -Edition $PITRedition -RequestedServiceObjectiveName $PITRNEWSLO -MaxSizeBytes 10737418240”

7 - Le dernier code ajoute la base de données restaurée au groupe de basculement, qui porte déjà le nom d'origine (puisque nous l'avons modifié dans le code précédent).

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $TargetDBNEWname | Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -FailoverGroupName $removedbfromfgDB”

Vous pouvez envisager d'ajouter le paramètre -ErrorAction Stop après la commande. Cela empêchera l’exécution des commandes suivantes en cas d’erreur et il n’y aura pas de boule de neige.

Vous pouvez également ajouter Get-Date au début et à la fin du script pour calculer le temps d'exécution. Dans mon cas, une base de données d'environ 3,3 Go a été restaurée par un tel script en moins de 6 minutes.

Si vous le souhaitez, vous pouvez sûrement optimiser le script, l'ajouter via Azure DevOps, réduire le nombre de variables ou coder en dur quelque chose, mais j'ai essayé de le décrire de la manière la plus détaillée possible et d'une manière que tout le monde puisse comprendre.

La surveillance des bases de données sur Azure et la possibilité d'intégration avec divers systèmes, tels que Datadog, méritent une attention particulière. La surveillance est assez pratique, mais non sans nuances (au moment de la rédaction, par exemple, les utilisateurs en lecture seule ne pouvaient voir la surveillance que d'une seule base de données, pas toutes en même temps... eh bien, voici les nuances).

En conclusion, notre équipe a réussi à optimiser les dépenses tout en répondant aux préoccupations liées aux mises à jour et à l'arrêt du support. Nous avons obtenu des améliorations en termes de performances, de résilience, de vitesse de développement et de flexibilité. De plus, la mise en œuvre de scripts a considérablement amélioré notre capacité à récupérer rapidement en cas de besoin.

Écrit par Pavel Shapurau, ingénieur DevOps principal chez Social Discovery Group.