Cette page a été traduite par l'API Cloud Translation.

Configurer un cluster SQL Server sur Linux avec des groupes de disponibilité Always On et Pacemaker

Ce tutoriel explique comment déployer un système de base de données Microsoft SQL Server sur Linux à l'aide d'un groupe de disponibilité Always On (AOAG) et de Pacemaker en tant que solution de haute disponibilité (HD) et de reprise après sinistre (DR). Dans ce document, un sinistre est un événement qui entraîne l'échec ou l'indisponibilité d'une base de données principale.

Une base de données principale peut échouer lorsque la région dans laquelle elle se trouve devient défaillante ou inaccessible. Même si une région est disponible et fonctionne normalement, une base de données principale peut échouer en raison d'une erreur système. Dans ce cas, la reprise après sinistre consiste à mettre une base de données secondaire à la disposition des clients, afin qu'ils puissent poursuivre leur traitement.

Ce tutoriel est destiné aux architectes, aux administrateurs et aux ingénieurs de bases de données.

Objectifs

Déployer SQL Server sur Linux
Créer un groupe de disponibilité Always On pour la haute disponibilité et la reprise après sinistre
Installer et configurer Pacemaker pour gérer le basculement du cluster SQL Server
Configurer un équilibreur de charge pour acheminer le trafic vers votre groupe de disponibilité avec SQL Server
Configurez un couloir STONITH (Shoot The Other Node In The Head) pour garantir l'intégrité de la haute disponibilité.
Effectuer un test de basculement pour vous assurer que le cluster SQL Server fonctionne comme prévu

Coûts

Ce tutoriel utilise des composants facturables de Google Cloud, dont :

Utilisez le Simulateur de coût pour générer une estimation des coûts en fonction de votre utilisation prévue.

Avant de commencer

Pour ce tutoriel, vous avez besoin d'un projet Google Cloud. Vous pouvez en créer un ou sélectionner un projet existant :

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.
Assurez-vous que l'API NetApp Cloud Volumes est activée pour votre projet Google Cloud.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

Préparer le projet et le réseau

Pour préparer votre projet Google Cloud et votre VPC pour le déploiement de groupes de disponibilité AlwaysOn SQL Server, procédez comme suit :

Dans la console Google Cloud, ouvrez Cloud Shell en cliquant sur le bouton Activer Cloud Shell .

Accédez à la console Google Cloud.
Définissez votre ID de projet par défaut :
```
gcloud config set project PROJECT_ID
```
Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.
Définissez votre région par défaut :
```
gcloud config set compute/region REGION
```
Remplacez REGION par l'ID de la région dans laquelle vous souhaitez effectuer le déploiement.
Définissez votre zone par défaut :
```
gcloud config set compute/zone ZONE
```
Remplacez ZONE par l'ID de la zone dans laquelle vous souhaitez effectuer le déploiement. Il doit s'agir d'une zone valide dans la région spécifiée à l'étape précédente.

Créer des VM Linux

Pour obtenir la haute disponibilité et le quorum pour le cluster SQL Server, déployez trois machines virtuelles (VM) Linux pour héberger le cluster SQL Server.

Initialisez les variables suivantes :
```
PD_SIZE=30
MACHINE_TYPE=n2-standard-8
```

Créez les VM Linux :

gcloud compute instances create node-1 \
--project=PROJECT_ID \
--zone REGION-a \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-2 \
--project=PROJECT_ID \
--zone REGION-b \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-2,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-3 \
--project=PROJECT_ID \
--zone REGION-c \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-3,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

Remplacez le sous-réseau SUBNET_NAME par le nom de votre sous-réseau VPC.

Mettez à jour le fichier hosts sur node-1, node-2 et node-3 :

Remarque : Pour une utilisation en production, la résolution de domaine doit être gérée par un serveur DNS (Domain Name System) dédié.
1. Connectez-vous à chacune de vos VM à l'aide de SSH. Pour en savoir plus, consultez la documentation sur la connexion aux VM Linux.
2. Ouvrez le fichier hosts pour le modifier.
```
sudo vi /etc/hosts
```
3. Recherchez l'adresse IP interne de chaque VM Linux, puis ajoutez les entrées d'hôtes au bas du fichier.
  
  Accéder à Compute Engine
```
NODE1_INTERNAL_IP node-1
NODE2_INTERNAL_IP node-2
NODE3_INTERNAL_IP node-3
```
  Remplacez NODE1_INTERNAL_IP, NODE2_INTERNAL_IP et NODE3_INTERNAL_IP par l'adresse IP interne de chaque VM Linux.
Vérifiez la communication entre vos VM. Toutes les VM participant au groupe de disponibilité Always On doivent pouvoir communiquer avec d'autres VM :
1. Revenez à chaque VM Linux, exécutez les commandes sur chaque VM et vérifiez que toutes les VM peuvent communiquer entre elles.
```
ping -c 4 node-1
ping -c 4 node-2
ping -c 4 node-3
```

Installer et configurer SQL Server

Téléchargez, installez et configurez le moteur SQL Server sur les trois VM Linux qui participeront au groupe de disponibilité Always On.

Connectez-vous à node-1, node-2 et node-3 via SSH, puis procédez comme suit :

Importez les clés publiques du dépôt.

wget -qO- https://packages.microsoft.com/keys/microsoft.asc \
| sudo tee /etc/apt/trusted.gpg.d/microsoft.asc

Enregistrez le dépôt Ubuntu SQL Server.

sudo add-apt-repository \
"$(wget -qO- https://packages.microsoft.com/config/ubuntu/20.04/mssql-server-2019.list)"

Mettez à jour les fichiers d'index des packages et installez SQL Server.
```
sudo apt-get update
sudo apt-get install -y mssql-server
```

Configurer SQL Server :
1. Exécutez l'outil mssql-conf.
```
sudo /opt/mssql/bin/mssql-conf setup
```
2. Sélectionnez l'édition Developer (Développeur) pour l'édition SQL Server, puis acceptez le contrat de licence.
  
  L'édition pour développeur inclut toutes les fonctionnalités pour les entreprises, mais vous ne pouvez l'utiliser que pour les environnements hors production. Pour en savoir plus sur les éditions SQL Server et les licences Microsoft, consultez les pages correspondantes.
  
  Remarque : Une licence SQL Server est requise pour chaque instance de VM. Si vous exécutez des serveurs d'applications Microsoft, la mobilité des licences via la Software Assurance vous aide à effectuer la transition vers Google Cloud. Pour en savoir plus, consultez Utiliser License Mobility avec les applications serveur Microsoft. Si vous n'apportez pas votre propre licence et que vous devez en acheter une via Google (PAYG), suivez la procédure décrite dans la section Ajouter une licence SQL Server à un disque de démarrage pour vous assurer d'acheter une licence pour chaque instance de VM.
3. Spécifiez un mot de passe pour le compte SA.
4. Vérifiez que le service mssql-server est en cours d'exécution.
```
systemctl status mssql-server --no-pager
```
Si un pare-feu est activé sur vos VM, ouvrez-le pour SQL Server :
1. Vérifiez si Uncomplicated Firewall est installé et activé en exécutant la commande suivante.
```
sudo ufw status
```
2. Si l'état est "active", exécutez les commandes suivantes pour ouvrir les ports.
```
sudo ufw allow 1433
sudo ufw allow 5022
sudo ufw reload
```
  Remarque : Si vous utilisez d'autres ports pour SQL Server ou pour votre point de terminaison de groupe de disponibilité, modifiez les règles de pare-feu en conséquence.

Se connecter à SQL Server

À ce stade, SQL Server est installé. Pour vous y connecter, créez une machine Windows dans le même VPC, puis installez SQL Server Management Studio (SSMS) pour vous connecter à votre instance SQL Server nouvellement créée sur vos VM :

Créez une VM Windows :

Revenez dans Cloud Shell et exécutez les commandes suivantes.

gcloud compute instances create node4 \
--project=PROJECT_ID \
--zone ZONE \
--subnet SUBNET_NAME \
--machine-type=n2-standard-4 \
--create-disk=auto-delete=yes,boot=yes,device-name=node4,image=projects/windows-cloud/global/images/windows-server-2022-dc-v20240415,mode=rw,size=50,type=projects/p3rf-sqlserver/zones/ZONE/diskTypes/pd-balanced

Connectez-vous à la VM Windows sur node-4 à l'aide du Bureau à distance :
Mettez à jour le fichier hosts sur node-4 :
1. Ouvrez le Bloc-notes en mode administrateur.
2. Cliquez sur File > Open (Fichier > Ouvrir), puis ouvrez le fichier hosts.
```
c:\Windows\System32\drivers\etc\hosts
```
3. Ajoutez les entrées d'hôtes en bas du fichier.
```
NODE1_INTERNAL_IP node-1
NODE2_INTERNAL_IP node-2
NODE3_INTERNAL_IP node-3
```
  Remplacez NODE1_INTERNAL_IP, NODE2_INTERNAL_IP et NODE3_INTERNAL_IP par l'adresse IP interne respective de chaque VM.
4. Enregistrez la modification et quittez l'éditeur.
Vérifiez la connectivité aux VM Linux :
1. Se connecter à la VM Windows sur node-4
2. Cliquez sur le bouton Démarrer, puis saisissez powershell dans la barre de recherche.
3. Cliquez pour ouvrir l'application Windows PowerShell ISE.
4. Teste la connectivité en exécutant les commandes suivantes.
```
ping node-1
ping node-2
ping node-3
```
Installez Microsoft SQL Server Management Studio (SSMS) en procédant comme suit :
1. Connectez-vous à la VM Windows sur node-4 à l'aide du Bureau à distance.
2. Dans votre session RDP, réduisez toutes les fenêtres et démarrez l'application Windows PowerShell ISE.
3. Lorsque l'invite PowerShell s'affiche, téléchargez et exécutez le programme d'installation de SSMS :
```
Start-BitsTransfer `
-Source "https://aka.ms/ssmsfullsetup" `
-Destination "$env:Temp\ssms-setup.exe"
& $env:Temp\ssms-setup.exe
```
4. Dans le programme d'installation SSMS, cliquez sur Installer.
5. Acceptez l'invite pour autoriser les modifications.
6. Une fois l'installation terminée, cliquez sur Redémarrer pour redémarrer l'ordinateur distant. Cette action ferme la session RDP.
Connectez-vous à l'instance SQL Server sur le nœud 1 :
1. Revenez à la VM node-4 à l'aide de RDP.
2. Ouvrez SSMS et connectez-vous à node-1 à l'aide des paramètres suivants.
```
Server name: node-1
Authentication: SQL Server Authentication
Login: sa
```
  Pour en savoir plus, consultez la section Se connecter à une instance SQL Server à l'aide de la documentation SQL Server Management Studio.
3. Saisissez le mot de passe du compte SA créé lors de l'installation.
4. Sélectionnez Approuver le certificat du serveur.
5. Cliquez sur Se connecter.

Activer le groupe de disponibilité Always On

Sous Linux, vous devez d'abord créer un groupe de disponibilité avant de pouvoir l'ajouter en tant que ressource gérée par Pacemaker :

Activez la fonctionnalité de groupe de disponibilité Always On pour chaque instance SQL Server participant au groupe de disponibilité. Exécutez les commandes suivantes sur node-1, node-2 et node-3 :

Remarque : Redémarrez le service mssql-server pour que les modifications prennent effet.
```
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server
```
Connectez-vous à l'instance qui est l'hôte principal du groupe de disponibilité à l'aide de SSMS :

Conseil : Nous vous recommandons de choisir node-1 comme hôte principal.
1. Ouvrez une nouvelle fenêtre de requête.
2. Exécutez l'extrait de code suivant pour créer une clé de chiffrement, un certificat et une clé privée.
  
  Conseil : Choisissez des mots de passe sécurisés pour la clé de chiffrement et la clé privée. N'oubliez pas ces mots de passe, car vous en aurez besoin plus tard.
  Remarque : Le mot de passe doit comporter au moins huit caractères et contenir des caractères issus de trois des quatre ensembles suivants : lettres majuscules, lettres minuscules, chiffres et symboles.
```
USE MASTER;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD';
CREATE CERTIFICATE my_ag_certificate WITH SUBJECT = 'my_ag_cert';
BACKUP CERTIFICATE my_ag_certificate
TO FILE = '/var/opt/mssql/data/my_ag_certificate.cer'
WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/my_ag_certificate.pvk',
    ENCRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD'
);
```
  Remplacez ENCRYPTION_KEY_PASSWORD et PRIVATE_KEY_PASSWORD par les mots de passe de la clé de chiffrement et de la clé privée.

Transférer les fichiers de certificat et de clé

Les fichiers de certificat et de clé créés aux étapes précédentes doivent être déplacés vers les nœuds secondaires de SQL Server. Il existe plusieurs méthodes pour déplacer les fichiers de certificat et de clé vers les nœuds secondaires sur node-2 et node-3.

Pour découvrir d'autres options de transfert, consultez la section Transférer des fichiers vers des VM Linux.

Transférer les fichiers de certificat et de clé à l'aide de Cloud Storage

Créez un bucket Cloud Storage pour transférer des fichiers du nœud principal vers les nœuds secondaires du cluster.

Créez un bucket Cloud Storage :
1. Revenez à Cloud Shell et exécutez la commande suivante :
```
gcloud storage buckets create gs://BUCKET_NAME \
--project=PROJECT_ID \
--location=REGION \
--public-access-prevention
```
  Remplacez BUCKET_NAME par le nom du bucket à créer. Remplacez PROJECT_ID par l'ID de votre projet Google Cloud et REGION par l'ID de la région dans laquelle vous souhaitez déployer le bucket.
Pour en savoir plus, consultez la page Créer des buckets.
Revenez à SSH sur node-1, node-2 et node-3 pour initialiser Google Cloud CLI :
1. Exécutez la commande suivante pour initialiser Google Cloud CLI.
```
gcloud init
```
2. Choisissez option [1] pour utiliser le compte de service préinstallé.
3. Entrez le nom de votre projet.
4. Saisissez n pour configurer la région et la zone par défaut.
Revenez à node-1 pour copier les fichiers dans Cloud Storage :
1. Importez les deux fichiers nouvellement créés dans votre Cloud Storage à l'aide des commandes suivantes.
```
sudo gcloud storage cp /var/opt/mssql/data/my_ag_certificate.cer gs://BUCKET_NAME/
sudo gcloud storage cp /var/opt/mssql/data/my_ag_certificate.pvk gs://BUCKET_NAME/
```
  Remplacez BUCKET_NAME par le nom du bucket.
Revenez à node-2 et node-3 pour copier les fichiers depuis Cloud Storage :
1. Téléchargez les deux fichiers de votre Cloud Storage vers node-2.
```
sudo gcloud storage cp gs://BUCKET_NAME/my_ag_certificate.cer /var/opt/mssql/data/
sudo gcloud storage cp gs://BUCKET_NAME/my_ag_certificate.pvk /var/opt/mssql/data/
```
  Remplacez BUCKET_NAME par le nom du bucket.
2. Modifiez la propriété des fichiers sur node-2 et node-3 en exécutant la commande dans un shell racine.
```
chown mssql:mssql /var/opt/mssql/data/my_ag_certificate.*
chmod 660 /var/opt/mssql/data/my_ag_certificate.*
```
  Conseil : N'oubliez pas de quitter l'interface système racine après avoir exécuté les commandes.

Configurer le point de terminaison de la mise en miroir de la base de données

Dans cette section, vous allez créer le point de terminaison de la base de données à l'aide d'une clé de chiffrement et d'un certificat partagés par chaque nœud du cluster SQL Server pour assurer la réplication sécurisée des données.

Revenez à la VM Windows sur node-4 pour créer les points de terminaison de mise en miroir de la base de données :
1. Connectez-vous aux bases de données SQL Server sur node-1, node-2 et node-3 à l'aide de SSMS. Suivez la procédure de la section Se connecter à SQL Server en utilisant node-1, node-2 et node-3 comme nom de serveur et les mots de passe respectifs que vous avez définis pour le compte SA.
2. Créez le certificat sur les VM secondaires node-2 et node-3 à partir des fichiers copiés. Utilisez les mots de passe que vous avez fournis lorsque vous avez créé le certificat et la clé sur le nœud principal.
```
USE MASTER;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD';
CREATE CERTIFICATE my_ag_certificate
FROM FILE = '/var/opt/mssql/data/my_ag_certificate.cer'
WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/my_ag_certificate.pvk',
    DECRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD'
);
```
  Remplacez ENCRYPTION_KEY_PASSWORD et PRIVATE_KEY_PASSWORD par les mots de passe de la clé de chiffrement et de la clé privée.
3. Revenez à SSMS pour créer des points de terminaison de miroir de base de données en exécutant la commande T-SQL pour node-1, node-2 et node-3.
  
  Conseil : Le port d'écoute par défaut est 5022, mais vous pouvez utiliser n'importe quel autre port disponible.
```
CREATE ENDPOINT [my_ag_endpoint]
    AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE my_ag_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
    );

ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED;
```

Créer et configurer le groupe de disponibilité Always On

Créez ensuite le groupe de disponibilité Always On SQL Server à l'aide de SQL Server Management Studio et utilisez les points de terminaison créés précédemment pour la réplication.

Revenez à la VM Windows et ouvrez SSMS :
1. Connectez-vous au moteur de base de données SQL Server sur node-1 et ouvrez une nouvelle fenêtre de requête.

Créez une base de données et sauvegardez-la en vue de la réplication :

USE MASTER;

CREATE DATABASE [bookshelf];
ALTER DATABASE [bookshelf] SET RECOVERY FULL;
BACKUP DATABASE [bookshelf]
TO DISK = N'/var/opt/mssql/data/bookshelf.bak';

Créez le groupe de disponibilité Always On :

Exécutez la commande T-SQL suivante dans SSMS sur node-1, node-2 et node-3. Vous vous assurez ainsi que les points de terminaison sont activés et que SQL Server sur chaque nœud est prêt à répliquer les données.

IF (SELECT state FROM sys.endpoints WHERE name = N'my_ag_endpoint') <> 0
BEGIN
    ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED
END
GO

IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

Exécutez la commande T-SQL suivante sur node-1 pour créer l'AOAG.

USE [master]
GO

CREATE AVAILABILITY GROUP [aoag1]
WITH (
    AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
    DB_FAILOVER = OFF,
    DTC_SUPPORT = NONE,
    CLUSTER_TYPE = EXTERNAL,
    REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0
)
FOR DATABASE [bookshelf]
REPLICA ON N'node-1' WITH (
    ENDPOINT_URL = N'TCP://node-1:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    N'node-2' WITH (ENDPOINT_URL = N'TCP://node-2:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    N'node-3' WITH (ENDPOINT_URL = N'TCP://node-3:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)
);
GO

Exécutez la commande T-SQL suivante sur node-2 et node-3 pour chaque instance SQL Server afin de rejoindre le nouveau groupe de disponibilité.
```
ALTER AVAILABILITY GROUP [aoag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [aoag1] GRANT CREATE ANY DATABASE;
GO
```

Vous avez créé une base de données appelée bookshelf et l'avez ajoutée à un nouveau groupe de disponibilité nommé aoag1 sur une instance SQL Server exécutée sur node-1. Node-2 et node-3 ont été ajoutés au groupe de disponibilité, et les données de la base de données bookshelf seront répliquées de manière synchrone sur les instances SQL Server des trois nœuds.

Installer et configurer Pacemaker

Pacemaker est un logiciel de gestion des ressources à haute disponibilité Open Source, utilisé avec le moteur de cluster Corosync. Dans cette section, vous allez installer et configurer Pacemaker sur chacune de vos VM.

Créer une connexion SQL Server pour le gestionnaire de cluster Pacemaker

Dans cette section, vous allez créer un compte SQL Server que Pacemaker utilisera pour se connecter à chaque instance SQL Server et gérer le groupe de disponibilité.

Exécutez la commande T-SQL suivante sur node-1, node-2 et node-3 :
```
USE [master];

CREATE LOGIN [pacemaker] with PASSWORD= N'PACEMAKER_LOGIN_PASSWORD';
GO
```
Remplacez PACEMAKER_LOGIN_PASSWORD par un mot de passe pour le compte de Pacemaker.

Exécutez la commande T-SQL pour accorder les autorisations de connexion à pacemaker au groupe de disponibilité :

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::[aoag1] TO [pacemaker];
GRANT VIEW SERVER STATE TO [pacemaker];
GO

Revenez à SSH sur node-1, node-2 et node-3 pour exécuter les commandes permettant d'enregistrer les identifiants de connexion et le mot de passe de Pacemaker dans le dossier des secrets SQL Server :
```
echo 'pacemaker' >> ~/pacemaker-passwd
echo 'PACEMAKER_LOGIN_PASSWORD' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd
```
Remplacez PACEMAKER_LOGIN_PASSWORD par le mot de passe du compte de Pacemaker.

Installer Pacemaker

Installez ensuite Pacemaker et configurez un compte de connexion sur toutes les VM Linux pour la gestion des ressources.

Ouvrir les ports de pare-feu pour Pacemaker :
1. Vérifiez si Uncomplicated Firewall est installé et activé en exécutant la commande suivante sur node-1, node-2 et node-3.
```
sudo ufw status
```
2. Si le pare-feu UFW est activé, ouvrez les ports de pare-feu sur node-1, node-2 et node-3.
```
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 5405/udp
sudo ufw allow 21064/tcp
sudo ufw allow 1433/tcp
sudo ufw allow 5022/tcp
sudo ufw reload
```
  Remarque : Si vous utilisez d'autres ports pour SQL Server ou pour votre point de terminaison de groupe de disponibilité, modifiez les règles de pare-feu en conséquence.

Installez Pacemaker sur node-1, node-2 et node-3 :

sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents  fence-agents corosync python3-azure pcs

Définissez un nouveau mot de passe pour l'utilisateur hacluster sur node-1, node-2 et node-3 :

Remarque : Définissez le même mot de passe sur les trois nœuds. Ce mot de passe vous sera utile pour le reste de la configuration.
```
sudo passwd hacluster
```

Configurer Corosync

Vous allez maintenant configurer Corosync pour gérer l'appartenance au cluster et la messagerie au sein du cluster.

Créez une clé d'authentification pour Corosync sur node-1 :
```
sudo corosync-keygen
```

Modifiez le fichier de configuration Corosync :

Revenez à node-1 et modifiez le fichier corosync.conf.
```
sudo vi /etc/corosync/corosync.conf
```

Mettez à jour les sections en surbrillance. Après modification, le fichier doit se présenter comme suit.

# Please read the corosync.conf.5 manual page
totem {
    version: 2

    # Corosync itself works without a cluster name, but DLM needs one.
    # The cluster name is also written into the VG metadata of newly
    # created shared LVM volume groups, if lvmlockd uses DLM locking.
    cluster_name: my_agcluster

    # crypto_cipher and crypto_hash: Used for mutual node authentication.
    # If you choose to enable this, then do remember to create a shared
    # secret with "corosync-keygen".
    # enabling crypto_cipher, requires also enabling of crypto_hash.
    # crypto works only with knet transport
    transport: udpu
    crypto_cipher: none
    crypto_hash: none
}

logging {
    # Log the source file and line where messages are being
    # generated. When in doubt, leave off. Potentially useful for
    # debugging.
    fileline: off
    # Log to standard error. When in doubt, set to yes. Useful when
    # running in the foreground (when invoking "corosync -f")
    to_stderr: yes
    # Log to a log file. When set to "no", the "logfile" option
    # must not be set.
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    # Log to the system log daemon. When in doubt, set to yes.
    to_syslog: yes
    # Log debug messages (very verbose). When in doubt, leave off.
    debug: off
    # Log messages with time stamps. When in doubt, set to hires (or on)
    #timestamp: hires
    logger_subsys {
        subsys: QUORUM
        debug: off
    }
}
quorum {
    # Enable and configure quorum subsystem (default: off)
    # see also corosync.conf.5 and votequorum.5
    provider: corosync_votequorum
}
nodelist {
    # Change/uncomment/add node sections to match cluster configuration

    node {
        # Hostname of the node
        name: node-1
        # Cluster membership node identifier
        nodeid: 1
        # Address of first link
        ring0_addr: NODE1_INTERNAL_IP
        # When knet transport is used it's possible to define up to 8 links
        #ring1_addr: 192.168.1.1
    }
    node {
        name: node-2
        nodeid: 2
        ring0_addr: NODE2_INTERNAL_IP
    }
    node {
        name: node-3
        nodeid: 3
        ring0_addr: NODE3_INTERNAL_IP
    }
    # ...
}

Remplacez NODE1_INTERNAL_IP, NODE2_INTERNAL_IP et NODE3_INTERNAL_IP par les adresses IP internes de chaque nœud.

Transférer les fichiers de configuration à l'aide de Cloud Storage

Importez la clé d'authentification générée et les fichiers de configuration corosync depuis node-1 vers votre bucket Cloud Storage :
```
sudo gcloud storage cp /etc/corosync/authkey gs://BUCKET_NAME/
sudo gcloud storage cp  /etc/corosync/corosync.conf gs://BUCKET_NAME/
```
Remplacez BUCKET_NAME par le nom du bucket créé précédemment.
Téléchargez les fichiers Authkey et de configuration dans node-2 et node-3 :
```
sudo gcloud storage cp gs://BUCKET_NAME/authkey /etc/corosync/
sudo gcloud storage cp gs://BUCKET_NAME/corosync.conf /etc/corosync/
```
Remplacez BUCKET_NAME par le nom du bucket dans lequel les fichiers de configuration Corosync ont été transférés.

Mettez à jour les autorisations des fichiers sur node-2 et node-3 :

sudo chmod 400 /etc/corosync/authkey
sudo chmod 400 /etc/corosync/corosync.conf

Redémarrer et vérifier la communication du cluster

Redémarrez les services Pacemaker et Corosync sur node-1, node-2 et node-3 :
```
sudo systemctl restart pacemaker corosync
```
Confirmez l'état du cluster en exécutant la commande sur node-1 :
```
sudo crm status
```
Les trois nœuds doivent être en ligne.

Configurer le cluster

Vous allez ensuite configurer le cluster Pacemaker en créant une ressource pour le groupe de disponibilité Always On SQL Server.

Exécutez la commande suivante sur node-1 pour définir les propriétés du cluster :

sudo crm configure property stonith-enabled=false
sudo crm configure property cluster-recheck-interval=2min
sudo crm configure property start-failure-is-fatal=true

Pour en savoir plus, consultez la section Options du cluster.

Autorisez les nœuds du cluster en exécutant la commande sur node-1. Utilisez le mot de passe défini précédemment pour le compte hacluster :
```
sudo pcs cluster auth -u hacluster
```
Les trois nœuds doivent être autorisés.
Installez l'agent de ressources SQL Server pour l'intégration avec Pacemaker sur node-1, node-2 et node-3 :
```
sudo apt-get install mssql-server-ha
```
Revenez à node-1 et créez une ressource de groupe de disponibilité dans le cluster :
1. Exécutez le gestionnaire de ressources de cluster.
```
sudo crm
```
2. Saisissez configure pour accéder au menu de configuration.
3. Saisissez la configuration suivante.
```
primitive aoag1-cluster \
ocf:mssql:ag \
params ag_name="aoag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s on-fail=demote interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag1 aoag1-cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true"
```
4. Saisissez commit pour valider les modifications.
  
  Remarque : Vous recevrez un avertissement indiquant qu'aucune règle de mise en quarantaine n'a été configurée. Ignorez ce message. Une règle de mise en quarantaine sera configurée à une étape ultérieure.
5. Saisissez exit pour quitter le gestionnaire de ressources du cluster.
6. Vérifiez la configuration.
```
sudo crm status
```
  Vous devriez voir que node-1 est devenu le nœud principal. Node-2 et node-3 doivent être définis comme nœuds secondaires.

Configurer l'équilibreur de charge et l'écouteur de groupe de disponibilité

Dans cette section, vous allez créer une adresse IP virtuelle et une ressource de vérification de l'état de l'état dans le cluster à l'aide d'un équilibreur de charge TCP passthrough interne qui achemine le trafic vers le groupe de disponibilité.

Revenez à Cloud Shell et réservez une adresse IP statique que vous utiliserez comme adresse IP de cluster :
```
gcloud compute addresses create aoag1-cluster \
--region REGION \
--subnet SUBNET_NAME
CLUSTER_ADDRESS=$(gcloud compute addresses describe aoag1-cluster \
--region $(gcloud config get-value compute/region) \
--format=value$address$) && \
echo "Cluster IP address: $CLUSTER_ADDRESS"
```
Remplacez REGION et SUBNET_NAME par la région et le sous-réseau où les VM Linux sont déployées.

Remarque : Enregistrez l'adresse IP réservée. Vous en aurez besoin à l'étape suivante.

Créez des groupes d'instances non gérés pour chacun de vos nœuds de cluster, puis attribuez-les au groupe d'instances nouvellement créé. Exécutez les commandes suivantes dans Cloud Shell :

gcloud compute instance-groups unmanaged create node-1-uig \
--zone=REGION-a
gcloud compute instance-groups unmanaged add-instances node-1-uig \
--zone=REGION-a \
--instances=node-1

gcloud compute instance-groups unmanaged create node-2-uig \
--zone=REGION-b
gcloud compute instance-groups unmanaged add-instances node-2-uig \
--zone=REGION-b \
--instances=node-2

gcloud compute instance-groups unmanaged create node-3-uig \
--zone=REGION-c
gcloud compute instance-groups unmanaged add-instances node-3-uig \
--zone=REGION-c \
--instances=node-3

Remplacez REGION par la région où les VM Linux sont déployées.

Créer une vérification d'état TCP Les équilibreurs de charge utilisent des vérifications de l'état pour déterminer quelles instances backend répondent correctement au trafic.
```
gcloud compute health-checks create tcp aoag1-healthcheck \
--port=HEALTH_CHECK_PORT --proxy-header=NONE \
--check-interval=10 --timeout=10 --unhealthy-threshold=2 \
--healthy-threshold=2
```
Choisissez un port libre et situé dans la plage privée 49152-65535, puis remplacez HEALTH_CHECK_PORT par sa valeur . Par exemple : 60 000.

Pour en savoir plus, consultez la page Présentation des vérifications d'état.

Ajoutez des tags réseau aux nœuds de votre cluster. Le tag réseau est utilisé par la règle de pare-feu pour la vérification d'état :

gcloud compute instances add-tags node-1 \
--tags NETWORK_TAG_NAME \
--zone REGION-a
gcloud compute instances add-tags node-2 \
--tags NETWORK_TAG_NAME \
--zone REGION-b
gcloud compute instances add-tags node-3 \
--tags NETWORK_TAG_NAME \
--zone REGION-c

Remplacez NETWORK_TAG_NAME par le nom du rattachement de réseau.

Créez une règle de pare-feu pour permettre aux vérifications d'état d'atteindre les nœuds du cluster en fonction du nom du tag :

gcloud compute firewall-rules create mssql-aoag1-fw-rule \
--network VPC_NAME \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags NETWORK_TAG_NAME \
--rules tcp:HEALTH_CHECK_PORT

Pour en savoir plus, consultez la section Règles de pare-feu pour les vérifications d'état.

Créez le service de backend de l'équilibreur de charge :

gcloud compute backend-services create aoag1-backend \
--load-balancing-scheme internal \
--health-checks aoag1-healthcheck \
--no-connection-drain-on-failover \
--drop-traffic-if-unhealthy \
--failover-ratio 1.0 \
--region REGION \
--global-health-checks

Ajoutez les trois groupes d'instances non gérés au service de backend :

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-1-uig \
--instance-group-zone REGION-a \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-2-uig \
--instance-group-zone REGION-b \
--failover \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-3-uig \
--instance-group-zone REGION-c \
--failover \
--region REGION

Définissez une règle de transfert pour votre équilibreur de charge. Une règle de transfert spécifie le protocole et les ports sur lesquels l'équilibreur de charge accepte le trafic :
```
gcloud compute forwarding-rules create aoag1-fwd-rule \
--load-balancing-scheme internal \
--address CLUSTER_ADDRESS \
--subnet SUBNET_NAME \
--region REGION \
--backend-service aoag1-backend \
--ports ALL
```
Remplacez CLUSTER_ADDRESS par l'adresse IP réservée précédemment.

Conseil : Si vous souhaitez que votre cluster soit accessible aux clients de n'importe quelle région du réseau VPC ou d'un réseau connecté, vous devez inclure --allow-global-access dans la définition de la règle de transfert.

Pour en savoir plus, consultez la section Règles de transfert.
Pour terminer la configuration et vérifier si votre équilibreur de charge réseau est correctement configuré, installez et configurez HAProxy tcp listener sur node-1, node-2 et node-3 :
1. Installez HAProxy.
```
sudo apt-get install haproxy
```
2. Sélectionnez Y pour terminer l'installation.
3. Modifiez le fichier haproxy.cfg.
```
sudo vi /etc/haproxy/haproxy.cfg
```
4. Dans la section defaults du fichier haproxy.cfg file, remplacez le mode par tcp.
5. Ajoutez la section suivante à la fin du fichier haproxy.cfg.
```
#---------------------------------------------------------------
# Set up health check listener for SQL Server Availability Group
#---------------------------------------------------------------
listen healthcheck
bind *:HEALTH_CHECK_PORT
```
  Remplacez HEALTH_CHECK_PORT par le port de vérification de l'état;état précédemment sélectionné. Par exemple : 6 000.
6. Démarrez le service pour vérifier qu'il est correctement configuré :
```
sudo systemctl start haproxy.service
sudo systemctl enable haproxy.service
sudo systemctl restart haproxy.service
```
7. Accédez à la page "Équilibrage de charge", puis cliquez sur votre équilibreur de charge. Examinez vos trois groupes d'instances non gérés. Ils devraient maintenant être signalés comme opérationnels.
  
  Accéder à la page "Équilibrage de charge"
  - Vous pouvez également exécuter la commande suivante dans Cloud Shell pour afficher l'état du service de backend.
```
gcloud compute backend-services get-health aoag1-backend \
--region REGION
```
    Remplacez REGION par la région où les VM Linux sont déployées.
8. Une fois que les trois groupes d'instances non gérés indiquent qu'ils sont opérationnels, passez à l'étape suivante.
  
  Remarque : Si le groupe d'instances non géré ne signale pas qu'il est opérationnel, vous devrez peut-être redémarrer le haproxy.service à partir du nœud en question.
```
sudo systemctl restart haproxy.service
```
Créez la ressource de vérification de l'état dans Pacemaker :
1. Connectez-vous à node-1 via SSH et créez une ressource de vérification de l'état pour le service HAProxy dans votre cluster pacemaker :
```
sudo pcs resource create aoag1-healthcheck \
service:haproxy \
op monitor interval=10s timeout=20s
```
2. Vérifiez que la ressource relative à l'état est démarrée sur le nœud principal node-1 :
```
sudo crm status
```
3. Si la ressource de vérification de l'état n'est pas démarrée sur le nœud principal, déplacez-la à l'aide des commandes suivantes :
```
sudo pcs resource move aoag1-healthcheck node-1
sudo pcs resource clear aoag1-healthcheck
```
  Vous verrez que la vérification de l'état de l'équilibreur de charge n'est opérationnelle que pour node-1.
  
  Accéder à la page "Équilibrage de charge"
Créez une ressource d'adresse IP virtuelle dans votre cluster Pacemaker :
1. Revenez sur node-1 via SSH et recherchez le nom de l'interface réseau de votre nœud. Vous en aurez besoin à l'étape suivante.
```
ip -c link
```
2. Créez la ressource d'adresse IP virtuelle.
```
sudo pcs resource create aoag1-vip ocf:heartbeat:IPaddr2 \
ip="CLUSTER_ADDRESS" nic=NIC_NAME cidr_netmask=32 \
op monitor interval=3600s timeout=60s
```
  Remplacez NIC_NAME par le nom de l'interface réseau de l'étape précédente et CLUSTER_ADDRESS par l'adresse IP réservée.
3. Vérifiez que la ressource d'adresse IP virtuelle est démarrée sur l'hôte principal.
```
sudo crm status
```
4. Si la ressource d'adresse IP virtuelle n'est pas démarrée sur le nœud principal, déplacez-la à l'aide des commandes suivantes.
```
sudo pcs resource move aoag1-vip node-1
```
5. Regroupez les ressources de vérification de l'état et d'adresse IP virtuelle.
```
sudo pcs resource group add aoag1-group \
aoag1-healthcheck aoag1-vip
```
6. Créez une contrainte qui situe le nouveau groupe sur le même nœud que le principal.
```
sudo pcs constraint colocation add master aoag1-group with master ms-ag1 score=INFINITY
```

Créer un écouteur pour votre groupe de disponibilité SQL Server

Les connexions à SQL Server avec des groupes de disponibilité doivent utiliser un nom d'écouteur de groupe de disponibilité au lieu du nom du serveur. En cas de basculement, l'écouteur redirige automatiquement les connexions vers le nouveau nœud principal du cluster.

Revenez à SSMS et connectez-vous à la base de données node-1.

Exécutez la requête suivante :

ALTER AVAILABILITY GROUP aoag1
ADD LISTENER 'aoag1-listener' (
    WITH IP (('CLUSTER_ADDRESS','255.255.255.0')), PORT=1433
);
GO

Remplacez CLUSTER_ADDRESS par l'adresse IP réservée.

Configurer une clôture STONITH

STONITH est une stratégie de cloisonnement permettant de maintenir l'intégrité des nœuds d'un cluster HA. Le service STONITH fonctionne au niveau du nœud et protège le cluster contre les nœuds qui ne répondent pas ou dont l'état est inconnu. Nous vous recommandons d'utiliser le dispositif de clôture fence_gce spécialisé pour Compute Engine sur Google Cloud.

Configurer des appareils de cloisonnement

Vérifiez si l'agent de cloisonnement fence_gce pour Compute Engine est installé sur node1 :
```
sudo pcs stonith list | grep fence_gce
```
Pour en savoir plus, consultez les pages suivantes :
- Agent de cloisonnement pour Google Compute Engine
- Pour afficher les paramètres associés à l'exécution de l'agent.
```
sudo pcs stonith describe fence_gce
```

Sur node-1, créez les ressources de type clôture fence_gce pour chacun des nœuds participants :

sudo pcs stonith create node-1-fence fence_gce \
plug=node-1 \
zone=REGION-a \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-2-fence fence_gce \
plug=node-2 \
zone=REGION-b \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-3-fence fence_gce \
plug=node-3 \
zone=REGION-c \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

Remplacez REGION par la région dans laquelle les VM Linux sont déployées et PROJECT_ID par l'ID de votre projet.

Vous pouvez tester l'état des agents de mise en quarantaine en exécutant la commande status :

sudo fence_gce -o status -n node-1 --zone=REGION-a
sudo fence_gce -o status -n node-2 --zone=REGION-b
sudo fence_gce -o status -n node-3 --zone=REGION-c

Créez des contraintes d'emplacement pour vos appareils de cloisonnement afin de vous assurer qu'ils ne s'exécutent que sur les instances prévues :

sudo pcs constraint location node-1-fence avoids node-1
sudo pcs constraint location node-2-fence avoids node-2
sudo pcs constraint location node-3-fence avoids node-3

Activez le cloisonnement dans votre cluster pacemaker et définissez le délai avant cloisonnement du cluster :
```
sudo pcs -f stonith_cfg property set stonith-enabled=true
sudo pcs property set stonith-timeout="300s"
```
Vérifiez l'état du cluster :
```
sudo crm status
```

Tester les appareils de cloisonnement

Une fois les appareils de cloisonnement configurés, nous vous recommandons de les tester en suivant la procédure ci-dessous.

Arrêtez le cloisonnement sur node-2 :
1. Connectez-vous à node-1 et exécutez la commande suivante pour tester l'appareil de cloisonnement associé à node-2 à partir de votre cluster.
```
fence_gce -o off -n node-2 --zone=REGION-b
```
2. Vérifiez l'état du cluster.
```
sudo crm status
```
3. Vous verrez également que node-2 est désactivé dans Compute Engine.
  
  Accéder à Compute Engine
Redémarrez le cloisonnement sur node-2 :
1. Revenez à node-1 et redémarrez l'instance en exécutant la commande suivante.
```
fence_gce -o on -n node-2 --zone=REGION-b
```
2. Vérifiez l'état du cluster dans Pacemaker et Compute Engine. Au bout d'un court moment, node-2 sera de nouveau en ligne.
```
sudo crm status
```

Configurer Corosync pour un redémarrage différé

Pour éviter les problèmes de synchronisation et garantir l'ordre correct des opérations effectuées en cas d'action de cloisonnement, nous vous recommandons de retarder le redémarrage du service Corosync pendant 60 secondes.

Pour en savoir plus, consultez l'article de la base de connaissances Red Hat.

Créez un fichier de dépôt systemd qui définit un délai de démarrage du service Corosync sur node-1, node-2 et node-3 :
1. Ouvrez le fichier corosync.service pour le modifier.
```
sudo systemctl edit corosync.service
```
2. Ajoutez les lignes suivantes, enregistrez le fichier et quittez l'éditeur.
```
[Service]
ExecStartPre=/bin/sleep 60
```
3. Rechargez le gestionnaire de services et vérifiez si la configuration est prise en compte.
```
sudo systemctl daemon-reload
systemctl status corosync.service --no-pager
```
  Si la section "Module complémentaire" s'affiche, cela signifie que les paramètres de votre fichier de module complémentaire ont bien été pris en compte.

Tester le basculement

Vous êtes maintenant prêt à tester si le basculement fonctionne comme prévu.

Connectez-vous à la VM Windows sur node-4 via le bureau à distance :
Ouvrez une session PowerShell :

Exécutez le script suivant :

while ($True){
  $Conn = New-Object System.Data.SqlClient.SqlConnection
  $Conn.ConnectionString = "Server=CLUSTER_ADDRESS;User ID=sa;Password=SA_PASSWORD;Initial Catalog=master"
  $Conn.Open()

  $Cmd = New-Object System.Data.SqlClient.SqlCommand
  $Cmd.Connection = $Conn
  $Cmd.CommandText = "SELECT @@SERVERNAME"

  $Adapter = New-Object System.Data.SqlClient.SqlDataAdapter $Cmd
  $Data = New-Object System.Data.DataSet
  $Adapter.Fill($Data) | Out-Null
  $Data.Tables[0] + (Get-Date -Format "MM/dd/yyyy HH:mm:ss")

  Start-Sleep -Seconds 2
}

Remplacez CLUSTER_ADDRESS par l'adresse IP de l'écouteur et SA_PASSWORD par le mot de passe du compte SA sur SQL Server.

Toutes les 2 secondes, le script se connecte à SQL Server à l'aide de l'écouteur du groupe de disponibilité ou de l'écouteur DNN, et interroge le nom du serveur.

Laissez le script s'exécuter.

Revenez sur node-1 via SSH et exécutez les commandes pour déclencher un basculement vers node-2 :

sudo pcs resource move ms-ag1 node-2 --master
sudo pcs resource move aoag1-group  node-2
sudo pcs resource move aoag1-vip node-2

Revenez à la session PowerShell sur node-4 :
1. Observez la sortie du script en cours d'exécution et notez que le nom du serveur passe de node-1 à node-2 suite au basculement.

Revenez à node-1 et lancez un retour à l'état antérieur vers node-1 :

sudo pcs resource move ms-ag1 node-1 --master
sudo pcs resource move aoag1-group  node-1
sudo pcs resource move aoag1-vip node-1

Revenez à Powershell sur node-4 et arrêtez le script en appuyant sur Ctrl+C.

Effectuer un nettoyage

Une fois le tutoriel terminé, vous pouvez procéder au nettoyage des ressources que vous avez créées afin qu'elles ne soient plus comptabilisées dans votre quota et qu'elles ne vous soient plus facturées. Dans les sections suivantes, nous allons voir comment supprimer ou désactiver ces ressources.

Supprimer le projet

Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.

Pour supprimer le projet :

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :

Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.