Exercice - Groupes de basculement automatique géodistribués en échelle lecture

  • 10 minutes

Vous avez découvert la géoréplication et les groupes de basculement automatique dans l’unité précédente. Dans cet exercice, vous allez configurer des groupes de basculement automatique pour votre base de données Azure SQL. Vous lancerez un basculement et afficherez les résultats.

Groupes de basculement automatique dans Azure SQL

Pour configurer des groupes de basculement automatique pour une ou plusieurs bases de données et afficher les résultats, vous devez effectuer les étapes suivantes :

  1. configurer l’environnement
  2. créer un serveur Azure SQL Database vide dans la région de basculement
  3. créer un groupe de basculement entre les serveurs
  4. configurer le réseau
  5. ajouter une ou plusieurs bases de données au groupe de basculement
  6. configurer vos applications d’invite de commandes
  7. comprendre les applications en cours d’exécution
  8. lancer un basculement
  9. restaurer automatiquement.

Cet exercice va vous guider tout au long de la configuration des groupes de basculement automatique pour votre base de données AdventureWorks. Vous allez ensuite utiliser une application en ligne de commande simple pour comprendre où les lectures et les écritures se produisent et l’importance de la logique de nouvelle tentative dans vos applications. Enfin, vous allez effectuer un exercice amusant pour déterminer combien de réplicas en lecture sont associés à une base de données Critique pour l’entreprise qui a également un groupe de basculement automatique.

Configurer l’environnement

  1. Copiez le code suivant dans le bloc-notes ou dans un autre éditeur de texte. Fournissez vos informations. Ajoutez votre mot de passe d’authentification SQL. Pour $drLocation, fournissez la région dans laquelle vous voulez placer votre groupe de basculement. Dans l’idéal, choisissez une région couplée à la région de votre serveur actuel. Vous pouvez vérifier la liste des régions couplées. Au minimum, il ne peut pas s’agir de la même région que celle où se trouve votre base de données d’origine. Enfin, ajoutez l’adresse IP de votre ordinateur local. Si vous devez déterminer l’adresse IP, ouvrez PowerShell sur l’ordinateur local et exécutez (Invoke-WebRequest -Uri "https://ipinfo.io/ip").Content.

    # Add your info
$password = "password"
$drLocation = "westus2"
$ipAddress = "xx.xx.xx.xx"

  2. Exécutez la commande mise à jour dans Azure Cloud Shell (à droite de cette page).

  3. Exécutez ce script dans Azure Cloud Shell afin de configurer vos variables pour les étapes qui suivent :

    $admin = "cloudadmin"
$resourceGroup = Get-AzResourceGroup | Where ResourceGroupName -like <rgn>Sandbox resource group name</rgn>
$location = $resourceGroup.Location
$resourceGroup = $resourceGroup.ResourceGroupName
$database = "AdventureWorks"
$server = Get-AzureRmSqlServer -ResourceGroupName $resourceGroup
$server = $server.ServerName
$drServer = "$($server)-dr"
$failoverGroup = "$($server)-fg"
$firewallRule = "AllowMyIp"
Write-Host "Variables Received"

  4. Créez un serveur Azure SQL Database vide dans la région de basculement en exécutant ce script dans Azure Cloud Shell :

    # Create a backup server in the failover region
New-AzSqlServer -ResourceGroupName $resourceGroup `
    -ServerName $drServer `
    -Location $drLocation `
    -SqlAdministratorCredentials $(New-Object -TypeName System.Management.Automation.PSCredential `
    -ArgumentList $admin, $(ConvertTo-SecureString -String $password -AsPlainText -Force))
Write-Host "New Azure SQL Database logical server Created in different region"

  5. Créez un groupe de basculement entre les serveurs en exécutant ce script dans Azure Cloud Shell :

    # Create a failover group between the servers
New-AzSqlDatabaseFailoverGroup -ResourceGroupName $resourceGroup `
    -ServerName $server `
    -PartnerServerName $drServer `
    -FailoverGroupName $failoverGroup 
Write-Host "New auto-failover group created between the two Azure SQL Database logical servers"

  6. Configurez le réseau en exécutant ce script dans Azure Cloud Shell :

    # Add a firewall rule that gives your VM access to the new server
New-AzSqlServerFirewallRule -ResourceGroupName $resourceGroup `
    -ServerName $drServer `
    -FirewallRuleName $firewallRule `
    -StartIpAddress $ipAddress `
    -EndIpAddress $ipAddress;

    Pour illustrer les groupes de basculement automatique, cette configuration réseau est suffisante. Cela diffère légèrement de ce que vous feriez dans un environnement d’entreprise. Dans un environnement d’entreprise, votre machine qui a besoin d’un accès sera probablement un ensemble de ressources constituant un certain type d’application. Si votre base de données bascule, vous pouvez également souhaiter basculer votre application, vos machines virtuelles ou d’autres ressources vers la nouvelle région. Les deux ensembles de ressources auront besoin d’accéder aux ressources, serveurs et bases de données dans l’autre région. Pour cela, vous pouvez utiliser un appairage de réseaux virtuels, des connexions de réseau virtuel à réseau virtuel ou éventuellement autre chose (par exemple Azure ExpressRoute). Cela dépend de votre scénario.

  7. Ajoutez une ou plusieurs bases de données au groupe de basculement en exécutant ce script dans Azure Cloud Shell :

    # Add the database or databases to the failover group
Get-AzSqlDatabase -ResourceGroupName $resourceGroup `
    -ServerName $server -DatabaseName $database | `
    Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $resourceGroup `
    -ServerName $server `
    -FailoverGroupName $failoverGroup
Write-Host "AdventureWorks database added to the auto-failover group"

    L’exécution de ce script peut prendre un certain temps. Vous restaurez la base de données dans l’autre région, ce qui implique de copier les données de la région d’origine vers la région de récupération d'urgence. Vous pouvez travailler sur les étapes de la section suivante, puis revenir en arrière pour vérifier si ce script est terminé.

Vous venez donc de déployer et de configurer un groupe de basculement automatique pour votre base de données AdventureWorks.

Configurer vos applications d’invite de commandes

Dans cette section, vous allez utiliser deux charges de travail ostress pour vérifier la Updateability (si une base de données est dans un état ReadWrite ou ReadOnly) de vos serveur principal et secondaire dans votre groupe de basculement. Ce scénario est destiné à simuler une application où vous avez des charges de travail de lecture et d’écriture.

  1. Ouvrez deux fenêtres d’invite de commandes distinctes. Configurez les fenêtres afin de pouvoir voir cette fenêtre (le navigateur) et les deux fenêtres d’invite de commandes.

  2. Dans les deux fenêtres d'invite de commandes, accédez au dossier Disponibilité comme vous l’avez fait dans les exercices précédents. Par exemple, vous pouvez utiliser cette commande :

    cd C:\Users\username\mslearn-azure-sql-fundamentals\05-Availability

  3. La première fenêtre d’invite de commandes sera utilisée pour vérifier l’état de votre serveur principal dans le groupe de basculement que vous avez créé. Exécutez cette commande en utilisant le nom et le mot de passe de votre serveur :

    .\ostress.exe -S"<server-name>-fg.database.windows.net" -Q"SELECT DATABASEPROPERTYEX(DB_NAME(),'Updateability')" -U"cloudadmin" -d"AdventureWorks" -P"password" -n1 -r5000 -oprimary

    Notes

    Avec les groupes de basculement automatique, vous vous connectez au nom du groupe de basculement, qui est l’abstraction de la base de données.

  4. Utilisez la deuxième fenêtre d’invite de commandes pour vérifier l’état de votre serveur secondaire dans le groupe de basculement que vous avez créé. Exécutez cette commande en utilisant le nom et le mot de passe de votre serveur :

    ostress.exe -S"<server-name>-fg.secondary.database.windows.net" -Q"SELECT DATABASEPROPERTYEX(DB_NAME(),'Updateability')" -U"cloudadmin" -d"AdventureWorks" -P"password" -n1 -r5000 -osecondary

Le résultat de la première commande doit être READ_WRITE, car elle vérifie le serveur du groupe de basculement principal et vous n’avez pas lancé de basculement.

Le résultat de la deuxième commande doit être READ_ONLY, car elle vérifie la récupération d'urgence ou le serveur secondaire que vous avez configuré. Normalement, vous pouvez écrire seulement depuis un des serveurs à un moment donné.

Dans les étapes suivantes, vous allez examiner ce qui se passe sur les deux serveurs quand un basculement se produit.

Lancer un basculement et afficher les résultats

  1. Utilisez le terminal Azure Cloud Shell, à droite de cette page, pour vérifier l’état du serveur secondaire :

    (Get-AzSqlDatabaseFailoverGroup -FailoverGroupName $failoverGroup `
    -ResourceGroupName $resourceGroup -ServerName $drServer).ReplicationRole

    Le résultat vous indique si le serveur secondaire dans le groupe de basculement automatique est utilisé comme base de données primaire ou secondaire.

  2. Vous pouvez maintenant voir ce qui se passe lorsqu’un basculement se produit. Lancez un basculement manuel en entrant ces commandes Azure PowerShell dans le terminal Azure Cloud Shell :

    Switch-AzSqlDatabaseFailoverGroup -ResourceGroupName $resourceGroup `
 -ServerName $drServer -FailoverGroupName $failoverGroup

    Lorsque le basculement se produit, vous remarquerez peut-être que la suppression temporaire des connexions, mais l’application n’échoue pas car elle continue de lancer de nouvelles tentatives. Une fois le basculement terminé, vous remarquerez que les résultats READ_WRITE et READ_ONLY reprennent et qu’ils ne sont pas modifiés.

    Un des avantages des groupes de basculement automatique dans Azure SQL Database et Azure SQL Managed Instance est que vous n’avez pas besoin de mettre à jour les chaînes de connexion après un basculement. Vous continuez à vous connecter au principal (<failover-group>.database.windows.net) pour les charges de travail en écriture et au secondaire (<failover-group>.secondary.database.windows.net) pour les charges de travail en lecture. Azure s’occupe de vous acheminer vers la base de données appropriée dans la région/le serveur correspondant.

  3. Vérifiez l’état du serveur secondaire en exécutant ce script dans Azure Cloud Shell :

    (Get-AzSqlDatabaseFailoverGroup -FailoverGroupName $failoverGroup `
    -ResourceGroupName $resourceGroup -ServerName $drServer).ReplicationRole

    Ce serveur doit maintenant être dans le rôle principal.

  4. Effectuez la restauration automatique en exécutant ce script dans Azure Cloud Shell :

    Switch-AzSqlDatabaseFailoverGroup -ResourceGroupName $resourceGroup `
 -ServerName $server -FailoverGroupName $failoverGroup

  5. Enfin, vous pouvez vérifier l’état du serveur secondaire encore. Exécutez ce script dans Azure Cloud Shell :

    (Get-AzSqlDatabaseFailoverGroup -FailoverGroupName $failoverGroup `
    -ResourceGroupName $resourceGroup -ServerName $drServer).ReplicationRole

  6. Vous pouvez maintenant fermer les deux fenêtres d'invite de commandes et agrandir la fenêtre du navigateur Microsoft Learn.

Dans cet exercice, vous avez appris à déployer et à configurer des groupes de basculement automatique. Vous avez également appris ce que cela signifie du point de vue d’une application. Les groupes de basculement automatique vous permettent d’aller plus loin dans la disponibilité et l’échelle en lecture dans Azure SQL.