Exercice - Haute disponibilité de niveau Critique pour l’entreprise

10 minutes

Dans cet exercice, vous allez mettre à niveau votre base de données vers le niveau Critique pour l’entreprise. Vous verrez comment il fournit des réplicas de lecture et des performances accrues.

Vous utiliserez l’outil ostress que vous avez utilisé dans l’exercice précédent pour créer une charge de travail. Vous allez ensuite lancer un basculement à l’aide du module Azure PowerShell dans Azure Cloud Shell. Enfin, vous allez constater l’effet du basculement sur la charge de travail ostress.

Haute disponibilité De base dans le niveau de service Critique pour l’entreprise Azure SQL

Dans cet exercice, vous allez effectuer les étapes suivantes :

déployer la base de données de l’exercice précédent dans le niveau Critique pour l’entreprise
exécuter la charge de travail ostress
utiliser PowerShell pour lancer un basculement
afficher les résultats dans ostress
vous connecter à un secondaire accessible en lecture.

Déployer la même base de données au niveau Critique pour l’entreprise

Dans un module précédent, vous avez découvert comment mettre à l’échelle une base de données en utilisant T-SQL. L’objectif de cet exercice est de mettre à niveau la base de données que vous avez utilisée au cours de l’exercice précédent du niveau Usage général à Critique pour l’entreprise. Vous utiliserez Azure Cloud Shell pour mettre à niveau la base de données. Étant donné qu’il y a une limite de fréquence des basculements, vous utiliserez le même exemple de base de données, mais en le nommant AdventureWorks-bc.

Dans le terminal Azure Cloud Shell, sur la droite de cette page, exécutez le script PowerShell suivant pour configurer votre environnement :

$resourceGroup = "<rgn>Sandbox resource group name</rgn>"
$database = "AdventureWorks-bc"
$server = Get-AzureRmSqlServer -ResourceGroupName $resourceGroup
$server = $server.ServerName

# Specify your default resource group and Azure SQL Database logical server
az configure --defaults group=$resourceGroup sql-server=$server

# Confirm the defaults are set
az configure --list-defaults

Exécutez cette commande pour créer une base de données dans le niveau de service Critique pour l’entreprise :
```
az sql db create --name $database `
--edition BusinessCritical `
--family Gen5 `
--capacity 2 `
--sample-name AdventureWorksLT `
--read-scale Enabled `
--zone-redundant false
```
Cette commande prend du temps à s’exécuter. Pendant ce temps, vous pouvez évaluer certains des paramètres utilisés :
- family : Ce paramètre spécifie la génération du matériel. Pour être cohérent avec l’exercice précédent, Gen5 est utilisé.
- capacity : Le paramètre spécifie le nombre d’unités de transaction de base de données et de mémoires à tores magnétiques virtuelles. Pour être cohérent avec l’exercice précédent, les vCores 2 sont utilisés.
- sample-name : Pour être cohérent avec l’exercice précédent, l’échantillon de base de données AdventureWorksLT est utilisé.
- edition : Ce nom de paramètre est un peu trompeur. Il fait vraiment référence au niveau de service, qui n’est pas le même que l’édition utilisée dans SQL Server.
- read-scale : Cette option n’est pas activée par défaut, mais aucun coût supplémentaire n’y est associé. En l’activant, vous autorisez l’utilisation d’un de vos réplicas secondaires comme réplica secondaire accessible en lecture.
- zone-redundant : Par défaut, ce paramètre est défini sur false. Vous pouvez le définir sur false si vous souhaitez un déploiement « Plusieurs zones de disponibilité », sans coût supplémentaire. Vous en saurez plus sur les zones de disponibilité dans l’unité suivante.
  
  Notes
  
  Les Zones de disponibilité sont disponibles uniquement dans certaines régions. Elles ne sont pas actuellement disponibles dans Azure SQL Managed Instance.
Une fois la base de données créée, vous devez voir des informations détaillées sur les mises à jour dans la sortie d’Azure Cloud Shell. Vous verrez deux catégories principales (vous verrez également des indicateurs sous plusieurs autres propriétés) :
- currentServiceObjectiveName : doit être BC_Gen5_2. BC signifie Critique pour l'entreprise
- currentSku :
  - name : doit être BC_Gen5.
  - tier : doit être BusinessCritical.
Pour vérifier le niveau de service, vous pouvez également accéder à votre base de données dans le Portail Azure. Sous l’onglet Vue d’ensemble, consultez le Niveau tarifaire.

Conseil

Il existe de nombreuses autres façons d’afficher ces mises à jour. Une autre méthode consiste à utiliser SSMS. Si vous cliquez avec le bouton de droite sur votre base de données et que vous sélectionnez Propriétés>Configurer SLO, vous pouvez également afficher les modifications.

Exécuter la charge de travail ostress

Tout comme dans l’exercice précédent, vous allez utiliser ostress pour interroger votre base de données Azure SQL de façon répétée.

Si vous avez fermé l’invite de commandes que vous avez utilisée dans l’exercice précédent, ouvrez une nouvelle fenêtre d’invite de commandes sur votre ordinateur local. Utilisez cd pour accéder au répertoire dans le référentiel que vous avez cloné ou téléchargé précédemment, dans lequel se trouve le module de disponibilité. Par exemple, vous pouvez utiliser cette commande :
```
cd C:\Users\username\mslearn-azure-sql-fundamentals\05-Availability
```
La charge de travail ostress se connecte et exécute une requête simple 50 000 fois.
Utilisez le script ostress suivant pour exécuter la charge de travail. Remplacez serverName par le nom de votre serveur logique Azure SQL Database. Remplacez password par votre mot de passe. Cette commande est légèrement différente de celle de l’exercice précédent. Le nom de la base de données est à présent AdventureWorks-bc.
```
.\ostress.exe -S"serverName.database.windows.net" -Q"SELECT COUNT(*) FROM SalesLT.Customer" -U"cloudadmin" -d"AdventureWorks-bc" -P"password" -n1 -r50000
```
Si votre charge de travail s’exécute correctement, vous devez voir le résultat de la requête, 847, s’afficher de façon répétée dans la fenêtre d'invite de commandes.

Si vous souhaitez arrêter l’exécution de la charge de travail ostress avant de l’effectuer, vous pouvez sélectionner Ctrl + C dans le terminal.

Si vous voulez réexécuter la charge de travail, vous pouvez réexécuter la commande.

Lancer un basculement et afficher les résultats

Configurez vos fenêtres afin de voir ce navigateur et la fenêtre d'invite de commandes en même temps.

Exécutez le code suivant dans le terminal Azure Cloud Shell. Cette commande est la même que celle utilisée dans l’exercice précédent.

# create a failover
Invoke-AzSqlDatabaseFailover -ResourceGroupName $resourceGroup `
    -ServerName $server `
    -DatabaseName $database

Pendant l’exécution de cette commande, vous pouvez observer les modifications qui apparaissent dans le terminal. Vous remarquerez que pendant le basculement, vous ne pouvez pas accéder à la base de données. Cette durée est très brève. Après être déconnecté, vous devriez être reconnecté après environ 5 secondes ! Ce basculement est plus de six fois plus rapide que celui du niveau Usage général.

N’oubliez pas que les bases de données ou les instances managées du niveau de service Critique pour l’entreprise disposent essentiellement d’un groupe de disponibilité Always On déployé en arrière-plan. Par conséquent, lorsque vous basculez, tout ce qui se produit est un changement dans les pointeurs du back end, car Azure vous redirige vers l’un des secondaires. C’est pourquoi le basculement est tellement plus rapide que dans le niveau Usage général.

Se connecter au réplica en lecture seule

Étant donné que vous avez activé le paramètre read-scale, vous avez la possibilité d’utiliser un des réplicas secondaires pour les charges de travail en lecture seule. Pour pouvoir accéder au réplica en lecture seule dans les applications, il vous suffit d’ajouter ce paramètre à votre chaîne de connexion pour une base de données :

ApplicationIntent=ReadOnly;

Dans SSMS, créez une nouvelle connexion à la requête. (Sélectionnez Fichier>Nouvelle>Requête du moteur de base de données.)
Dans la boîte de dialogue Se connecter au serveur, utilisez la configuration que vous avez utilisée pour vous connecter à votre serveur logique Azure SQL Database. (C’est-à-dire, utilisez Authentification SQL Server.) Sélectionnez Options.
Sélectionnez Propriétés de connexion, puis sélectionnez Réinitialiser tout. Sous Se connecter à la base de données, sélectionnez Parcourir le serveur, puis sélectionnez votre base de données AdventureWorks-bc. Cliquez sur OK.
Sélectionnez Paramètres de connexion supplémentaires, puis copiez ce qui suit dans la zone de texte. Sélectionnez Se connecter.
```
ApplicationIntent=ReadOnly;
```
Avec SSMS, vous devez spécifier le serveur et la base de données auxquels vous souhaitez vous connecter en lecture seule. Ceci parce qu’il peut y avoir plusieurs bases de données dans un serveur qui ont des fonctionnalités différentes pour les bases de données secondaires accessibles en lecture.
Pour effectuer un test, essayez la requête suivante sur la nouvelle requête du moteur de base de données. Observez les résultats. S’agit-il de ce que vous attendiez ?
```
SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability')
```
Vous pouvez éventuellement vous reconnecter et mettre à jour les paramètres de connexion supplémentaires. (Remplacer ReadOnly par ReadWrite.) Confirmez que vous accédez au réplica principal en lecture/écriture. ReadWrite est la valeur par défaut, ainsi, si vous ne sélectionnez rien, ce sera donc votre mode d’accès :