Tutoriel : Configurer des groupes de disponibilité pour SQL Server sur des machines virtuelles RHEL dans Azure

Article
12/06/2023

S’applique à : SQL Server sur machine virtuelle Azure

Remarque

Dans ce tutoriel, nous utilisons SQL Server 2017 (14.x) avec RHEL 7.6. Cependant, il est possible d'utiliser SQL Server 2019 (15.x) dans RHEL 7 ou RHEL 8 pour configurer la haute disponibilité. Les commandes permettant de configurer les ressources du groupement pacemaker et de groupe de disponibilité ont changé dans RHEL 8. Il est donc recommandé de consulter l'article Créer une ressource de groupe de disponibilité et d'étudier les ressources RHEL 8 pour obtenir des informations sur les commandes appropriées.

Dans ce tutoriel, vous allez apprendre à :

Créer un groupe de ressources, un groupe à haute disponibilité et des machines virtuelles Linux
Activer la haute disponibilité
Créez un cluster Pacemaker
Configurer un agent d’isolation en créant un appareil STONITH
Installer SQL Server et mssql-tools sur RHEL
Configurer un groupe de disponibilité SQL Server AlwaysOn
Configurer les ressources de groupe de disponibilité dans le cluster Pacemaker
Tester un basculement et l’agent d’isolation

Ce tutoriel utilise Azure CLI pour déployer des ressources dans Azure.

Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.

Prérequis

Utilisez l’environnement Bash dans Azure Cloud Shell. Pour plus d’informations, consultez Démarrage rapide pour Bash dans Azure Cloud Shell.
Si vous préférez exécuter les commandes de référence de l’interface de ligne de commande localement, installez l’interface Azure CLI. Si vous exécutez sur Windows ou macOS, envisagez d’exécuter Azure CLI dans un conteneur Docker. Pour plus d’informations, consultez Guide pratique pour exécuter Azure CLI dans un conteneur Docker.
- Si vous utilisez une installation locale, connectez-vous à Azure CLI à l’aide de la commande az login. Pour finir le processus d’authentification, suivez les étapes affichées dans votre terminal. Pour connaître les autres options de connexion, consultez Se connecter avec Azure CLI.
- Lorsque vous y êtes invité, installez l’extension Azure CLI lors de la première utilisation. Pour plus d’informations sur les extensions, consultez Utiliser des extensions avec Azure CLI.
- Exécutez az version pour rechercher la version et les bibliothèques dépendantes installées. Pour effectuer une mise à niveau vers la dernière version, exécutez az upgrade.

Cet article nécessite la version 2.0.30 ou ultérieure de l’interface Azure CLI. Si vous utilisez Azure Cloud Shell, la version la plus récente est déjà installée.

Créer un groupe de ressources

Si vous avez plusieurs abonnements, sélectionnez l’abonnement dans lequel vous souhaitez déployer ces ressources.

Utilisez la commande suivante pour créer un groupe de ressources <resourceGroupName> dans une région. Remplacez <resourceGroupName> par le nom de votre choix. Pour ce tutoriel, nous utilisons East US 2. Pour plus d’informations, consultez ce guide de démarrage rapide.

az group create --name <resourceGroupName> --location eastus2

Créer un groupe à haute disponibilité

L’étape suivante consiste à créer un groupe à haute disponibilité. Exécutez la commande suivante dans Azure Cloud Shell et remplacez <resourceGroupName> par le nom de votre groupe de ressources. Choisissez un nom pour <availabilitySetName>.

az vm availability-set create \
    --resource-group <resourceGroupName> \
    --name <availabilitySetName> \
    --platform-fault-domain-count 2 \
    --platform-update-domain-count 2

Une fois l’exécution de la commande terminée, vous devez obtenir les résultats suivants :

{
  "id": "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/availabilitySets/<availabilitySetName>",
  "location": "eastus2",
  "name": "<availabilitySetName>",
  "platformFaultDomainCount": 2,
  "platformUpdateDomainCount": 2,
  "proximityPlacementGroup": null,
  "resourceGroup": "<resourceGroupName>",
  "sku": {
    "capacity": null,
    "name": "Aligned",
    "tier": null
  },
  "statuses": null,
  "tags": {},
  "type": "Microsoft.Compute/availabilitySets",
  "virtualMachines": []
}

Créer des machines virtuelles RHEL dans le groupe à haute disponibilité

Avertissement

Si vous choisissez une image RHEL avec paiement à l'utilisation (PAYG) et que vous configurez la haute disponibilité (HA), vous devrez peut-être enregistrer votre abonnement. Cela peut vous obliger à payer deux fois l'abonnement, car vous devrez payer à la fois l'abonnement RHEL Microsoft Azure de la machine virtuelle et l'abonnement à Red Hat. Pour plus d’informations, consultez https://access.redhat.com/solutions/2458541.

Pour éviter cette « double facturation », utilisez une image de haute disponibilité RHEL lors de la création de la machine virtuelle Azure. Les images proposées en tant qu’images RHEL de haute disponibilité sont également des images avec paiement à l’utilisation pour lesquelles est préactivé un dépôt de haute disponibilité.

Obtenez la liste des images de machines virtuelles qui proposent RHEL avec une haute disponibilité :

az vm image list --all --offer "RHEL-HA"

Les résultats suivants doivent s’afficher :

[
  {
"offer": "RHEL-HA",
"publisher": "RedHat",
"sku": "7.4",
"urn": "RedHat:RHEL-HA:7.4:7.4.2019062021",
"version": "7.4.2019062021"
   },
   {
"offer": "RHEL-HA",
"publisher": "RedHat",
"sku": "7.5",
"urn": "RedHat:RHEL-HA:7.5:7.5.2019062021",
"version": "7.5.2019062021"
    },
    {
"offer": "RHEL-HA",
"publisher": "RedHat",
"sku": "7.6",
"urn": "RedHat:RHEL-HA:7.6:7.6.2019062019",
"version": "7.6.2019062019"
     },
     {
"offer": "RHEL-HA",
"publisher": "RedHat",
"sku": "8.0",
"urn": "RedHat:RHEL-HA:8.0:8.0.2020021914",
"version": "8.0.2020021914"
     },
     {
"offer": "RHEL-HA",
"publisher": "RedHat",
"sku": "8.1",
"urn": "RedHat:RHEL-HA:8.1:8.1.2020021914",
"version": "8.1.2020021914"
      },
      {
"offer": "RHEL-HA",
"publisher": "RedHat",
"sku": "80-gen2",
"urn": "RedHat:RHEL-HA:80-gen2:8.0.2020021915",
"version": "8.0.2020021915"
       },
       {
"offer": "RHEL-HA",
"publisher": "RedHat",
"sku": "81_gen2",
"urn": "RedHat:RHEL-HA:81_gen2:8.1.2020021915",
"version": "8.1.2020021915"
       }
]

Pour ce tutoriel, nous choisissons l’image RedHat:RHEL-HA:7.6:7.6.2019062019 pour l’exemple RHEL 7 et RedHat:RHEL-HA:8.1:8.1.2020021914 pour l’exemple RHEL 8.

Vous pouvez également choisir SQL Server 2019 (15.x) préinstallé sur les images RHEL8-HA. Pour afficher la liste de ces images, exécutez la commande suivante :

az vm image list --all --offer "sql2019-rhel8"

Les résultats suivants doivent s’afficher :

[
   {
      "offer": "sql2019-rhel8",
      "publisher": "MicrosoftSQLServer",
      "sku": "enterprise",
      "urn": "MicrosoftSQLServer:sql2019-rhel8:enterprise:15.0.200317",
      "version": "15.0.200317"
   },
   {
      "offer": "sql2019-rhel8",
      "publisher": "MicrosoftSQLServer",
      "sku": "enterprise",
      "urn": "MicrosoftSQLServer:sql2019-rhel8:enterprise:15.0.200512",
      "version": "15.0.200512"
   },
   {
      "offer": "sql2019-rhel8",
      "publisher": "MicrosoftSQLServer",
      "sku": "sqldev",
      "urn": "MicrosoftSQLServer:sql2019-rhel8:sqldev:15.0.200317",
      "version": "15.0.200317"
   },
   {
      "offer": "sql2019-rhel8",
      "publisher": "MicrosoftSQLServer",
      "sku": "sqldev",
      "urn": "MicrosoftSQLServer:sql2019-rhel8:sqldev:15.0.200512",
      "version": "15.0.200512"
   },
   {
      "offer": "sql2019-rhel8",
      "publisher": "MicrosoftSQLServer",
      "sku": "standard",
      "urn": "MicrosoftSQLServer:sql2019-rhel8:standard:15.0.200317",
      "version": "15.0.200317"
   },
   {
      "offer": "sql2019-rhel8",
      "publisher": "MicrosoftSQLServer",
      "sku": "standard",
      "urn": "MicrosoftSQLServer:sql2019-rhel8:standard:15.0.200512",
      "version": "15.0.200512"
   }
]

Si vous utilisez l'une des images ci-dessus pour créer les machines virtuelles, c'est que SQL Server 2019 (15.x) est préinstallé. Ignorez la section Installer SQL Server et mssql-tools comme décrit dans cet article.

Important

Pour la configuration du groupe de disponibilité, les noms de machines doivent comporter moins de 15 caractères. Le nom d'utilisateur ne peut pas contenir de caractères majuscules, et les mots de passe doivent comporter plus de 12 caractères.

Nous voulons créer 3 machines virtuelles dans le groupe à haute disponibilité. Remplacez ces valeurs dans la commande suivante :

<resourceGroupName>
<VM-basename>
<availabilitySetName>
<VM-Size> - Par exemple, « Standard_D16_v3 »
<username>
<adminPassword>

for i in `seq 1 3`; do
       az vm create \
         --resource-group <resourceGroupName> \
         --name <VM-basename>$i \
         --availability-set <availabilitySetName> \
         --size "<VM-Size>"  \
         --image "RedHat:RHEL-HA:7.6:7.6.2019062019" \
         --admin-username "<username>" \
         --admin-password "<adminPassword>" \
         --authentication-type all \
         --generate-ssh-keys
done

La commande ci-dessus crée les machines virtuelles, ainsi qu'un réseau virtuel par défaut pour celles-ci. Pour plus d’informations sur les différentes configurations, consultez l’article az vm create.

Une fois la commande exécutée sur chaque machine virtuelle, vous devez obtenir des résultats similaires à ce qui suit :

{
  "fqdns": "",
  "id": "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/virtualMachines/<VM1>",
  "location": "eastus2",
  "macAddress": "<Some MAC address>",
  "powerState": "VM running",
  "privateIpAddress": "<IP1>",
  "publicIpAddress": "",
  "resourceGroup": "<resourceGroupName>",
  "zones": ""
}

Important

L’image par défaut créée à l’aide de la commande ci-dessus crée un disque de système d’exploitation de 32 Go par défaut. Vous risquez de manquer d’espace avec cette installation par défaut. Vous pouvez ajouter le paramètre suivant à la commande az vm create ci-dessus pour créer un disque de système d’exploitation avec 128 Go, par exemple : --os-disk-size-gb 128.

Vous pouvez ensuite configurer le gestionnaire de volumes logiques si vous devez développer des volumes de dossiers pour votre installation.

Tester la connexion aux machines virtuelles créées

Connectez-vous à VM1 ou à d’autres machines virtuelles à l’aide de la commande suivante dans Azure Cloud Shell. Si vous ne parvenez pas à trouver les adresses IP de vos machines virtuelles, suivez ce Démarrage rapide sur Azure Cloud Shell.

ssh <username>@publicipaddress

Si la connexion a réussi, vous devez voir la sortie suivante qui représente le terminal Linux :

[<username>@<VM1> ~]$

Tapez exit pour quitter la session SSH.

Activer la haute disponibilité

Important

Pour effectuer cette partie du tutoriel, vous devez disposer d’un abonnement RHEL et du module complémentaire Haute disponibilité. Si vous utilisez une image recommandée dans la section précédente, vous n'avez pas à enregistrer un autre abonnement.

Connectez-vous à chaque nœud de machine virtuelle et suivez ce guide pour activer la haute disponibilité. Pour plus d’informations, consultez Activer l’abonnement haute disponibilité pour RHEL.

Conseil

Vous pouvez vous faciliter la tâche en ouvrant simultanément une session SSH sur chacune des machines virtuelles, car dans cet article, les mêmes commandes devront être exécutées sur toutes les machines virtuelles.

Si vous copiez-collez plusieurs commandes sudo et êtes invité à entrer un mot de passe, les commandes supplémentaires seront exécutées. Vous devez exécuter chaque commande séparément.

Pour ouvrir les ports du pare-feu de Pacemaker, exécutez les commandes suivantes sur chaque machine virtuelle :
```
sudo firewall-cmd --permanent --add-service=high-availability
sudo firewall-cmd --reload
```
Mettez à jour et installez les packages Pacemaker sur tous les nœuds à l’aide des commandes suivantes :

Notes

nmap est installé dans le cadre de ce bloc de commandes comme un outil permettant de rechercher des adresses IP disponibles dans votre réseau. L'installation de nmap n'est pas obligatoire. Toutefois, cet outil vous sera utile plus tard dans ce tutoriel.
```
sudo yum update -y
sudo yum install -y pacemaker pcs fence-agents-all resource-agents fence-agents-azure-arm nmap
sudo reboot
```
Définissez le mot de passe pour l’utilisateur par défaut qui est créé pendant l’installation des packages Pacemaker. Utilisez le même mot de passe sur tous les nœuds.
```
sudo passwd hacluster
```
Utilisez la commande suivante pour ouvrir le fichier HOSTS et configurer la résolution des noms d’hôtes. Pour plus d’informations, consultez Configurer le groupe de disponibilité qui aborde la configuration du fichier HOSTS.
```
sudo vi /etc/hosts
```
Dans l’éditeur vi, entrez i pour insérer du texte, puis, sur une ligne vide, ajoutez l’adresse IP privée de la machine virtuelle correspondante. Ajoutez ensuite le nom de la machine virtuelle après un espace, à côté de l’adresse IP. Chaque ligne doit avoir une entrée distincte.
```
<IP1> <VM1>
<IP2> <VM2>
<IP3> <VM3>
```
Important

Nous vous recommandons d'utiliser votre adresse IP privée dans l'exemple précédent. L’utilisation de l’adresse IP publique dans cette configuration entraînera l’échec de l’installation. En outre, nous vous déconseillons d’exposer votre machine virtuelle à des réseaux externes.

Pour quitter l’éditeur vi, appuyez d’abord sur la touche Echap, puis entrez la commande :wq pour écrire le fichier et quitter.

Créez le cluster Pacemaker

Dans cette section, vous activez et démarrez le service PCSD, puis configurez le cluster. Pour SQL Server sur Linux, la création des ressources de cluster ne fait pas automatiquement. Vous devez activer et créer manuellement les ressources Pacemaker. Pour plus d'informations, consultez l'article sur la configuration d'une instance de cluster de basculement pour RHEL.

Activer et démarrer le service pcsd et Pacemaker

Exécutez les commandes sur tous les nœuds. Ces commandes permettent aux nœuds de rejoindre le cluster après leur redémarrage.
```
sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker
```
Supprimez toutes les configurations de cluster existantes de tous les nœuds. Exécutez la commande suivante :
```
sudo pcs cluster destroy
sudo systemctl enable pacemaker
```
Sur le nœud principal, exécutez les commandes suivantes pour configurer le cluster.
- Lors de l'exécution de la commande pcs cluster auth pour authentifier les nœuds de cluster, vous êtes invité à saisir un mot de passe. Entrez le mot de passe de l’utilisateur hacluster créé précédemment.
RHEL7
```
sudo pcs cluster auth <VM1> <VM2> <VM3> -u hacluster
sudo pcs cluster setup --name az-hacluster <VM1> <VM2> <VM3> --token 30000
sudo pcs cluster start --all
sudo pcs cluster enable --all
```
RHEL8

Pour RHEL 8, vous devez authentifier séparément les nodes. Quand vous y êtes invité, entrez manuellement le nom d’utilisateur et le mot de passe pour hacluster.
```
sudo pcs host auth <node1> <node2> <node3>
sudo pcs cluster setup <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
```

Exécutez la commande suivante pour vérifier que tous les nœuds sont en ligne.

sudo pcs status

RHEL 7

Si tous les nœuds sont connectés, vous voyez une sortie similaire à celle de l'exemple suivant :

Cluster name: az-hacluster

WARNINGS:
No stonith devices and stonith-enabled is not false

Stack: corosync
Current DC: <VM2> (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
Last updated: Fri Aug 23 18:27:57 2019
Last change: Fri Aug 23 18:27:56 2019 by hacluster via crmd on <VM2>

3 nodes configured
0 resources configured

Online: [ <VM1> <VM2> <VM3> ]

No resources

Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled

RHEL 8

Cluster name: az-hacluster

WARNINGS:
No stonith devices and stonith-enabled is not false

Cluster Summary:
  * Stack: corosync
  * Current DC: <VM2> (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
  * Last updated: Fri Aug 23 18:27:57 2019
  * Last change: Fri Aug 23 18:27:56 2019 by hacluster via crmd on <VM2>
  * 3 nodes configured
  * 0 resource instances configured

Node List:
  * Online: [ <VM1> <VM2> <VM3> ]

Full List of Resources:
  * No resources

Daemon Status:
  * corosync: active/enabled
  * pacemaker: active/enabled
  * pcsd: active/enabled

Attribuez la valeur 3 aux votes attendus dans le cluster actif. Cette commande affecte uniquement le groupement actif et ne change pas les fichiers de configuration.

Sur tous les nœuds, définissez les votes attendus avec la commande suivante :
```
sudo pcs quorum expected-votes 3
```

Configurer l’agent d’isolation

Pour configurer un agent d'isolation, les instructions suivantes sont modifiées pour ce tutoriel. Pour plus d’informations, consultez Créer un appareil STONITH.

Vérifiez la version de l'agent d'isolation Azure pour vous assurer que l'agent a été mis à jour. Utilisez la commande suivante :

sudo yum info fence-agents-azure-arm

Vous devez voir une sortie similaire à celle de l’exemple ci-dessous.

Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Installed Packages
Name        : fence-agents-azure-arm
Arch        : x86_64
Version     : 4.2.1
Release     : 11.el7_6.8
Size        : 28 k
Repo        : installed
From repo   : rhel-ha-for-rhel-7-server-eus-rhui-rpms
Summary     : Fence agent for Azure Resource Manager
URL         : https://github.com/ClusterLabs/fence-agents
License     : GPLv2+ and LGPLv2+
Description : The fence-agents-azure-arm package contains a fence agent for Azure instances.

Inscrire une nouvelle application dans Microsoft Entra ID

Pour inscrire une nouvelle application dans Microsoft Entra ID (anciennement Azure Active Directory), procédez comme suit :

Accédez à https://portal.azure.com.
Ouvrez le volet des propriétés de Microsoft Entra ID et relevez le Tenant ID.
Sélectionnez Inscriptions d’applications.
Sélectionnez Nouvelle inscription.
Entrez un Nom tel que <resourceGroupName>-app. Concernant les Types de compte pris en charge, sélectionnez Comptes dans cet annuaire d’organisation uniquement (Microsoft uniquement : locataire unique).
Sélectionnez Web pour l'URI de redirection, puis saisissez une URL (par example, http://localhost), puis sélectionnez Ajouter. L’URL de connexion peut être n’importe quelle URL valide. Une fois terminé, sélectionnez Inscrire.
Sélectionnez Certificats et secrets pour votre nouvelle inscription d’application, puis sélectionnez Nouvelle clé secrète client.
Entrez une description pour la nouvelle clé (clé secrète client), puis sélectionnez Ajouter.
Notez la valeur du secret. Elle est utilisée comme mot de passe du principal de service.
Sélectionnez Vue d’ensemble. Notez l’ID de l’application. Cet identifiant est utilisé comme nom d'utilisateur (ID de connexion dans les étapes suivantes) du principal de service.

Créer un rôle personnalisé pour l’agent d’isolation

Suivez le tutoriel Créer un rôle personnalisé Azure à l’aide d’Azure CLI.

Votre fichier JSON doit être semblable à l'exemple suivant :

Remplacez <username> par un nom de votre choix. Cela permet d’éviter toute duplication lors de la création de cette définition de rôle.
Remplacez <subscriptionId> par l’identifiant de votre abonnement Azure.

{
  "Name": "Linux Fence Agent Role-<username>",
  "Id": null,
  "IsCustom": true,
  "Description": "Allows to power-off and start virtual machines",
  "Actions": [
    "Microsoft.Compute/*/read",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/start/action"
  ],
  "NotActions": [
  ],
  "AssignableScopes": [
    "/subscriptions/<subscriptionId>"
  ]
}

Pour ajouter le rôle, exécutez la commande suivante :

Remplacez <filename> par le nom du fichier.
Si vous exécutez la commande à partir d’un chemin autre que celui du dossier dans lequel est enregistré le fichier, incluez dans la commande le chemin du dossier où se trouve le fichier.

az role definition create --role-definition "<filename>.json"

Vous devez normalement voir la sortie suivante.

{
  "assignableScopes": [
    "/subscriptions/<subscriptionId>"
  ],
  "description": "Allows to power-off and start virtual machines",
  "id": "/subscriptions/<subscriptionId>/providers/Microsoft.Authorization/roleDefinitions/<roleNameId>",
  "name": "<roleNameId>",
  "permissions": [
    {
      "actions": [
        "Microsoft.Compute/*/read",
        "Microsoft.Compute/virtualMachines/powerOff/action",
        "Microsoft.Compute/virtualMachines/start/action"
      ],
      "dataActions": [],
      "notActions": [],
      "notDataActions": []
    }
  ],
  "roleName": "Linux Fence Agent Role-<username>",
  "roleType": "CustomRole",
  "type": "Microsoft.Authorization/roleDefinitions"
}

Affecter le rôle personnalisé au principal de service

Affectez au principal de service le rôle personnalisé Linux Fence Agent Role-<username> qui a été créé à l’étape précédente. N'utilisez plus le rôle Propriétaire !

Accédez à https://portal.azure.com
Ouvrez le volet Toutes les ressources
Sélectionnez la machine virtuelle du premier nœud de cluster.
Sélectionnez Contrôle d’accès (IAM)
Sélectionnez Ajouter une attribution de rôle.
Sélectionnez le rôle Linux Fence Agent Role-<username> dans la liste Rôle.
Dans la liste Sélectionner, saisissez le nom de l'application que vous avez créée précédemment, <resourceGroupName>-app.
Cliquez sur Enregistrer
Répétez ces étapes pour tous les nœuds de groupement.

Créer les appareils STONITH

Exécutez les commandes suivantes sur le nœud 1 :

Remplacez <ApplicationID> par la valeur d’ID obtenue lors de l’inscription de votre application.
Remplacez <servicePrincipalPassword> par la valeur du secret client.
Remplacez <resourceGroupName> par le groupe de ressources de l’abonnement que vous utilisez pour ce tutoriel.
Remplacez <tenantID> et <subscriptionId> par ceux de votre abonnement Azure.

sudo pcs property set stonith-timeout=900
sudo pcs stonith create rsc_st_azure fence_azure_arm login="<ApplicationID>" passwd="<servicePrincipalPassword>" resourceGroup="<resourceGroupName>" tenantId="<tenantID>" subscriptionId="<subscriptionId>" power_timeout=240 pcmk_reboot_timeout=900

Étant donné que nous avons déjà ajouté une règle à notre pare-feu pour autoriser le service de haute disponibilité (--add-service=high-availability), il n’est pas nécessaire d’ouvrir les ports de pare-feu suivants sur tous les nœuds : 2224, 3121, 21064, 5405. Toutefois, si vous rencontrez des problèmes de connexion avec la haute disponibilité, utilisez la commande suivante pour ouvrir les ports qui sont associés à la haute disponibilité.

Conseil

Si vous le souhaitez, vous pouvez ajouter simultanément tous les ports de ce tutoriel pour gagner du temps. Les ports qui doivent être ouverts sont indiqués dans les sections pertinentes qui suivent. Si vous souhaitez ajouter tous les ports maintenant, ajoutez également les ports suivants : 1433 et 5022.

sudo firewall-cmd --zone=public --add-port=2224/tcp --add-port=3121/tcp --add-port=21064/tcp --add-port=5405/tcp --permanent
sudo firewall-cmd --reload

Installer SQL Server et mssql-tools

Remarque

Si vous avez créé les machines virtuelles avec l'instance de SQL Server 2019 (15.x) préinstallée sur RHEL8-HA, vous pouvez ignorer les étapes ci-dessous destinées à installer SQL Server et mssql-tools et commencer la section Configurer un groupe de disponibilité après avoir configuré le mot de passe AS sur toutes les machines virtuelles en exécutant la commande sudo /opt/mssql/bin/mssql-conf set-sa-password sur toutes les machines virtuelles.

Utilisez la section ci-dessous pour installer SQL Server et mssql-tools sur les machines virtuelles. Vous pouvez choisir l'un des échantillons ci-dessous pour installer SQL Server 2017 (14.x) sur RHEL 7 ou SQL Server 2019 (15.x) sur RHEL 8. Effectuez chacune de ces actions sur tous les nœuds. Pour plus d’informations, consultez Installer SQL Server sur une machine virtuelle Red Hat.

Installer SQL Server sur des machines virtuelles

Exécutez les commandes suivantes pour installer SQL Server :

RHEL 7 avec SQL Server 2017

sudo curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/7/mssql-server-2017.repo
sudo yum install -y mssql-server
sudo /opt/mssql/bin/mssql-conf setup
sudo yum install mssql-server-ha

RHEL 8 avec SQL Server 2019

sudo curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/8/mssql-server-2019.repo
sudo yum install -y mssql-server
sudo /opt/mssql/bin/mssql-conf setup
sudo yum install mssql-server-ha

Ouvrir le port de pare-feu 1433 pour les connexions distantes

Vous devez ouvrir le port 1433 sur la machine virtuelle pour vous connecter à distance. Utilisez les commandes suivantes pour ouvrir le port 1433 dans le pare-feu de chaque machine virtuelle :

sudo firewall-cmd --zone=public --add-port=1433/tcp --permanent
sudo firewall-cmd --reload

Installer des outils de ligne de commande SQL Server

Exécutez les commandes suivantes pour installer les outils en ligne de commande SQL Server : Pour plus d’informations, consultez Installer les outils en ligne de commande SQL Server.

RHEL 7

sudo curl -o /etc/yum.repos.d/msprod.repo https://packages.microsoft.com/config/rhel/7/prod.repo
sudo yum install -y mssql-tools unixODBC-devel

RHEL 8

sudo curl -o /etc/yum.repos.d/msprod.repo https://packages.microsoft.com/config/rhel/8/prod.repo
sudo yum install -y mssql-tools unixODBC-devel

Notes

Par souci pratique, ajoutez /opt/mssql-tools/bin/ à votre variable d’environnement PATH. Vous pourrez ainsi exécuter les outils sans spécifier le chemin complet. Exécutez les commandes suivantes afin de modifier la variable PATH pour les sessions de connexion et les sessions interactives ou sans connexion :

echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bash_profile
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bashrc
source ~/.bashrc

Vérifier l’état de SQL Server

Une fois que vous avez terminé la configuration, vous pouvez vérifier le status de SQL Server et vérifier qu'il est bien en cours d'exécution :

systemctl status mssql-server --no-pager

Vous devez normalement voir la sortie suivante.

● mssql-server.service - Microsoft SQL Server Database Engine
   Loaded: loaded (/usr/lib/systemd/system/mssql-server.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2019-12-05 17:30:55 UTC; 20min ago
     Docs: https://learn.microsoft.com/sql/linux
 Main PID: 11612 (sqlservr)
   CGroup: /system.slice/mssql-server.service
           ├─11612 /opt/mssql/bin/sqlservr
           └─11640 /opt/mssql/bin/sqlservr

Configurer un groupe de disponibilité

Effectuez les étapes suivantes pour configurer un groupe de disponibilité AlwaysOn SQL Server sur vos machines virtuelles. Pour plus d'informations, consultez Configurer des groupes de disponibilité Always On SQL Server pour la haute disponibilité sur Linux.

Activer les groupes de disponibilité AlwaysOn et redémarrer mssql-server

Activez les groupes de disponibilité AlwaysOn sur chaque nœud qui héberge une instance SQL Server. Ensuite, redémarrez mssql-server. Exécutez le script suivant :

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server

Créer un certificat

L’authentification Active Directory n’est pas prise en charge sur le point de terminaison du groupe de disponibilité. Par conséquent, nous devons utiliser un certificat pour le chiffrement du point de terminaison du groupe de disponibilité.

Connectez-vous à tous les nœuds à l’aide de SQL Server Management Studio (SSMS) ou de sqlcmd. Exécutez les commandes suivantes pour activer une session AlwaysOn_health et créer une clé principale :

Important

Si vous vous connectez à distance à votre instance SQL Server, le port 1433 doit être ouvert dans votre pare-feu. Vous devez également autoriser les connexions entrantes sur le port 1433 de votre groupe de sécurité réseau pour chaque machine virtuelle. Pour plus d’informations sur la création d’une règle de sécurité de trafic entrant, consultez Créer une règle de sécurité.
- Remplacez <Master_Key_Password> par votre propre mot de passe.
```
ALTER EVENT SESSION  AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Master_Key_Password>';
```
Connectez-vous au réplica principal à l’aide de SSMS ou de sqlcmd. Les commandes suivantes créent un certificat dans /var/opt/mssql/data/dbm_certificate.cer et une clé privée dans var/opt/mssql/data/dbm_certificate.pvk sur votre réplica de SQL Server principal :
- Remplacez <Private_Key_Password> par votre propre mot de passe.
```
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
GO

BACKUP CERTIFICATE dbm_certificate
   TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
   WITH PRIVATE KEY (
           FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
           ENCRYPTION BY PASSWORD = '<Private_Key_Password>'
       );
GO
```

Quittez la session sqlcmd en exécutant la commande exit, puis revenez à votre session SSH.

Copier le certificat sur les réplicas secondaires et créer les certificats sur le serveur

Copiez les deux fichiers qui ont été créés au même emplacement sur tous les serveurs qui hébergeront les réplicas de disponibilité.

Sur le serveur principal, exécutez la commande scp suivante pour copier le certificat sur les serveurs cibles :
- Remplacez <username> et <VM2> par le nom d’utilisateur et le nom de la machine virtuelle cible que vous utilisez.
- Exécutez cette commande pour tous les réplicas secondaires.
Notes

Vous n’êtes pas obligé d’exécuter sudo -i, qui vous indique l’environnement racine. Vous pouvez simplement exécuter la commande sudo devant chaque commande, comme nous l’avons fait précédemment dans ce tutoriel.
```
# The below command allows you to run commands in the root environment
sudo -i
```
```
scp /var/opt/mssql/data/dbm_certificate.* <username>@<VM2>:/home/<username>
```
Sur le serveur cible, exécutez la commande suivante :
- Remplacez <username> par votre ID d’utilisateur.
- La commande mv permet de déplacer les fichiers ou le répertoire.
- La commande chown est utilisée pour modifier le propriétaire ainsi que le groupe de fichiers, de répertoires ou de liens.
- Exécutez ces commandes pour tous les réplicas secondaires.
```
sudo -i
mv /home/<username>/dbm_certificate.* /var/opt/mssql/data/
cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*
```
Le script Transact-SQL suivant crée un certificat à partir de la sauvegarde que vous avez créée sur le réplica SQL Server principal. Mettez à jour le script avec des mots de passe forts. Le mot de passe de déchiffrement est le même que celui que vous avez utilisé pour créer le fichier .pvk à l’étape précédente. Pour créer le certificat, exécutez le script suivant à l’aide de sqlcmd ou de SSMS sur tous les serveurs secondaires :
```
CREATE CERTIFICATE dbm_certificate
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
    DECRYPTION BY PASSWORD = '<Private_Key_Password>'
            );
GO
```

Créer les points de terminaison de mise en miroir de bases de données sur tous les réplicas

Exécutez le script suivant sur toutes les instances SQL à l’aide de sqlcmd ou de SSMS :

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (
    ROLE = ALL,
    AUTHENTICATION = CERTIFICATE dbm_certificate,
ENCRYPTION = REQUIRED ALGORITHM AES
);
GO

ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
GO

Créez le groupe de disponibilité

Connectez-vous à l’instance SQL qui héberge le réplica principal à l’aide de sqlcmd ou de SSMS. Exécutez la commande suivante pour créer le groupe de disponibilité :

Remplacez ag1 par le nom de groupe de disponibilité de votre choix.
Remplacez les valeurs <VM1>, <VM2> et <VM3> par les noms des instances SQL Server qui hébergent les réplicas.

CREATE AVAILABILITY GROUP [ag1]
     WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
     FOR REPLICA ON
         N'<VM1>'
          WITH (
             ENDPOINT_URL = N'tcp://<VM1>:5022',
             AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
             FAILOVER_MODE = EXTERNAL,
             SEEDING_MODE = AUTOMATIC
             ),
         N'<VM2>'
          WITH (
             ENDPOINT_URL = N'tcp://<VM2>:5022',
             AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
             FAILOVER_MODE = EXTERNAL,
             SEEDING_MODE = AUTOMATIC
             ),
         N'<VM3>'
         WITH(
            ENDPOINT_URL = N'tcp://<VM3>:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
GO

Sur toutes les instances SQL Server, créez un compte de connexion SQL Server pour Pacemaker. Le code Transact-SQL ci-dessous a pour effet de créer un compte de connexion.

Remplacez <password> par votre propre mot de passe complexe.

USE [master]
GO

CREATE LOGIN [pacemakerLogin] with PASSWORD= N'<password>';
GO

ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
GO

Sur toutes les instances SQL Server, enregistrez les informations d’identification utilisées pour le compte de connexion SQL Server.

Créez le fichier :
```
sudo vi /var/opt/mssql/secrets/passwd
```
Ajoutez les lignes suivantes au fichier :
```
pacemakerLogin
<password>
```
Pour quitter l’éditeur vi, appuyez d’abord sur la touche Echap, puis entrez la commande :wq pour écrire le fichier et quitter.

Rendez le fichier lisible uniquement par la racine :

sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd

Joindre les réplicas secondaires au groupe de disponibilité

Pour joindre les réplicas secondaires au groupe de disponibilité, vous devez ouvrir le port 5022 du pare-feu pour tous les serveurs. Exécutez la commande suivante dans votre session SSH :
```
sudo firewall-cmd --zone=public --add-port=5022/tcp --permanent
sudo firewall-cmd --reload
```

Sur vos réplicas secondaires, exécutez les commandes suivantes pour les joindre au groupe de disponibilité :

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
GO

Exécutez le script Transact-SQL suivant sur le réplica principal et sur chaque réplica secondaire :

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO pacemakerLogin;
GO

GRANT VIEW SERVER STATE TO pacemakerLogin;
GO

Une fois les réplicas secondaires joints, vous pouvez les afficher dans l’Explorateur d’objets de SSMS en développant le nœud Haute disponibilité Always On :

Ajouter une base de données au groupe de disponibilité

Nous suivons les instructions de l'article concernant la configuration d'un groupe de disponibilité lors de l'ajout d'une de base de données.

Les commandes Transact-SQL suivantes sont utilisées dans cette étape. Exécutez les commandes suivantes sur le réplica principal :

CREATE DATABASE [db1]; -- creates a database named db1
GO

ALTER DATABASE [db1] SET RECOVERY FULL; -- set the database in full recovery model
GO

BACKUP DATABASE [db1] -- backs up the database to disk
   TO DISK = N'/var/opt/mssql/data/db1.bak';
GO

ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1]; -- adds the database db1 to the AG
GO

Vérifier que la base de données est créée sur les serveurs secondaires

Sur chaque réplica SQL Server secondaire, exécutez la requête suivante pour déterminer si la base de données db1 a été créée et si son état indique « SYNCHRONIZED » :

SELECT * FROM sys.databases WHERE name = 'db1';
GO
SELECT DB_NAME(database_id) AS 'database', synchronization_state_desc FROM sys.dm_hadr_database_replica_states;

Si synchronization_state_desc indique SYNCHRONIZED pour db1, cela signifie que les réplicas sont synchronisés. Les réplicas secondaires indiquent db1 dans le réplica principal.

Créer les ressources de groupe de disponibilité dans le cluster Pacemaker

Nous suivons le guide permettant de créer les ressources de groupe de disponibilité dans le groupement Pacemaker.

Remarque

Communication sans stéréotype

Cet article contient des références au terme esclave, un terme que Microsoft considère comme choquant lorsqu’il est utilisé dans ce contexte. Le terme apparaît dans cet article, car il apparaît actuellement dans le logiciel. Lorsque le terme sera supprimé du logiciel, nous le supprimerons de l’article.

Créer la ressource de cluster du groupe de disponibilité

Utilisez l’une des commandes suivantes en fonction de l’environnement choisi précédemment pour créer la ressource ag_cluster dans le groupe de disponibilité ag1.

RHEL 7

sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=30s master notify=true

RHEL 8

sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=30s promotable notify=true

Vérifiez que vos ressources sont bien connectées avant d'exécuter la commande suivante :

sudo pcs resource

Vous devez normalement voir la sortie suivante.

RHEL 7

[<username>@VM1 ~]$ sudo pcs resource
Master/Slave Set: ag_cluster-master [ag_cluster]
Masters: [ <VM1> ]
Slaves: [ <VM2> <VM3> ]

RHEL 8

[<username>@VM1 ~]$ sudo pcs resource
* Clone Set: ag_cluster-clone [ag_cluster] (promotable):
* ag_cluster             (ocf::mssql:ag) :            Slave VMrhel3 (Monitoring)
* ag_cluster             (ocf::mssql:ag) :            Master VMrhel1 (Monitoring)
* ag_cluster             (ocf::mssql:ag) :            Slave VMrhel2 (Monitoring)

Créer une ressource d’adresse IP virtuelle

Pour créer une ressource d’adresse IP virtuelle, utilisez une adresse IP statique disponible dans votre réseau. Vous pouvez en trouver une à l’aide de l’outil de commande nmap.
```
nmap -sP <IPRange>
# For example: nmap -sP 10.0.0.*
# The above will scan for all IP addresses that are already occupied in the 10.0.0.x space.
```
Affectez la valeur false à la propriété stonith-enabled :
```
sudo pcs property set stonith-enabled=false
```
Créez la ressource d'adresse IP virtuelle à l'aide de la commande suivante : Remplacez la valeur <availableIP> par une adresse IP inutilisée.
```
sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=<availableIP>
```

Ajouter des contraintes

Pour vous assurer que l’adresse IP et la ressource de disponibilité de groupe s’exécutent sur le même nœud, une contrainte de colocalisation doit être configurée. Exécutez la commande suivante :

RHEL 7
```
sudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master
```
RHEL 8
```
 sudo pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY with-rsc-role=Master
```
Créez une contrainte de classement pour vous assurer que la ressource de groupe de disponibilité est active et en cours d’exécution avant l’adresse IP. Alors que la contrainte de colocalisation implique une contrainte de classement, elle l’applique.

RHEL 7
```
sudo pcs constraint order promote ag_cluster-master then start virtualip
```
RHEL 8
```
sudo pcs constraint order promote ag_cluster-clone then start virtualip
```

Pour vérifier les contraintes, exécutez la commande suivante :

sudo pcs constraint list --full

Vous devez normalement voir la sortie suivante.

RHEL 7

Location Constraints:
Ordering Constraints:
      promote ag_cluster-master then start virtualip (kind:Mandatory) (id:order-ag_cluster-master-virtualip-mandatory)
Colocation Constraints:
      virtualip with ag_cluster-master (score:INFINITY) (with-rsc-role:Master) (id:colocation-virtualip-ag_cluster-master-INFINITY)
Ticket Constraints:

RHEL 8

Location Constraints:
Ordering Constraints:
        promote ag_cluster-clone then start virtualip (kind:Mandatory) (id:order-ag_cluster-clone-virtualip-mandatory)
Colocation Constraints:
        virtualip with ag_cluster-clone (score:INFINITY) (with-rsc-role:Master) (id:colocation-virtualip-ag_cluster-clone-INFINITY)
Ticket Constraints:

Réactiver stonith

Nous sommes prêts pour le test. Réactivez stonith dans le cluster en exécutant la commande suivante sur le nœud 1 :

sudo pcs property set stonith-enabled=true

Vérification du statut du cluster

Vous pouvez vérifier l’état de vos ressources de cluster à l’aide de la commande suivante :

[<username>@VM1 ~]$ sudo pcs status
Cluster name: az-hacluster
Stack: corosync
Current DC: <VM3> (version 1.1.19-8.el7_6.5-c3c624ea3d) - partition with quorum
Last updated: Sat Dec  7 00:18:38 2019
Last change: Sat Dec  7 00:18:02 2019 by root via cibadmin on VM1

3 nodes configured
5 resources configured

Online: [ <VM1> <VM2> <VM3> ]

Full list of resources:

 Master/Slave Set: ag_cluster-master [ag_cluster]
     Masters: [ <VM2> ]
     Slaves: [ <VM1> <VM3> ]
 virtualip      (ocf::heartbeat:IPaddr2):       Started <VM2>
 rsc_st_azure   (stonith:fence_azure_arm):      Started <VM1>

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Test de basculement

Pour vérifier que la configuration a réussi, nous testons un basculement. Pour plus d’informations, consultez Basculement du groupe de disponibilité AlwaysOn sur Linux.

Exécutez la commande suivante pour basculer manuellement le réplica principal vers <VM2>. Remplacez <VM2> par le nom du serveur.

RHEL 7
```
sudo pcs resource move ag_cluster-master <VM2> --master
```
RHEL 8
```
sudo pcs resource move ag_cluster-clone <VM2> --master
```
Vous pouvez également spécifier une option supplémentaire afin que la contrainte temporaire créée pour déplacer la ressource vers un nœud souhaité soit désactivée automatiquement, et que vous n'ayez pas à effectuer les étapes 2 et 3 des instructions suivantes.

RHEL 7
```
sudo pcs resource move ag_cluster-master <VM2> --master lifetime=30S
```
RHEL 8
```
sudo pcs resource move ag_cluster-clone <VM2> --master lifetime=30S
```
Pour automatiser les étapes 2 et 3 qui éliminent la contrainte temporaire de la commande de déplacement de ressource, vous pouvez aussi combiner plusieurs commandes sur une même ligne.

RHEL 7
```
sudo pcs resource move ag_cluster-master <VM2> --master && sleep 30 && pcs resource clear ag_cluster-master
```
RHEL 8
```
sudo pcs resource move ag_cluster-clone <VM2> --master && sleep 30 && pcs resource clear ag_cluster-clone
```

Si vous vérifiez à nouveau vos contraintes, vous constatez qu'une autre contrainte a été ajoutée en raison du basculement manuel :

RHEL 7

[<username>@VM1 ~]$ sudo pcs constraint list --full
Location Constraints:
      Resource: ag_cluster-master
        Enabled on: VM2 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)
Ordering Constraints:
        promote ag_cluster-master then start virtualip (kind:Mandatory) (id:order-ag_cluster-master-virtualip-mandatory)
Colocation Constraints:
        virtualip with ag_cluster-master (score:INFINITY) (with-rsc-role:Master) (id:colocation-virtualip-ag_cluster-master-INFINITY)
Ticket Constraints:

RHEL 8

[<username>@VM1 ~]$ sudo pcs constraint list --full
Location Constraints:
      Resource: ag_cluster-master
        Enabled on: VM2 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-clone)
Ordering Constraints:
        promote ag_cluster-clone then start virtualip (kind:Mandatory) (id:order-ag_cluster-clone-virtualip-mandatory)
Colocation Constraints:
        virtualip with ag_cluster-clone (score:INFINITY) (with-rsc-role:Master) (id:colocation-virtualip-ag_cluster-clone-INFINITY)
Ticket Constraints:

Supprimez la contrainte avec l’ID cli-prefer-ag_cluster-master à l’aide de la commande suivante :

RHEL 7

sudo pcs constraint remove cli-prefer-ag_cluster-master

RHEL 8

sudo pcs constraint remove cli-prefer-ag_cluster-clone

Vérifiez vos ressources de cluster à l’aide de la commande sudo pcs resource. Vous devriez voir que l’instance principale est désormais <VM2>.

[<username>@<VM1> ~]$ sudo pcs resource
Master/Slave Set: ag_cluster-master [ag_cluster]
     ag_cluster (ocf::mssql:ag):        FAILED <VM1> (Monitoring)
     Masters: [ <VM2> ]
     Slaves: [ <VM3> ]
virtualip      (ocf::heartbeat:IPaddr2):       Started <VM2>
[<username>@<VM1> ~]$ sudo pcs resource
Master/Slave Set: ag_cluster-master [ag_cluster]
     Masters: [ <VM2> ]
     Slaves: [ <VM1> <VM3> ]
virtualip      (ocf::heartbeat:IPaddr2):       Started <VM2>

Tester l’isolation

Vous pouvez tester l'isolation en exécutant la commande suivante. Essayez d’exécuter la commande ci-dessous à partir de <VM1> pour <VM3>.

sudo pcs stonith fence <VM3> --debug

Notes

Par défaut, l’action d’isolation déconnecte puis reconnecte le nœud. Si vous souhaitez uniquement déconnecter le nœud, utilisez l’option --off dans la commande.

Vous devez obtenir la sortie suivante :

[<username>@<VM1> ~]$ sudo pcs stonith fence <VM3> --debug
Running: stonith_admin -B <VM3>
Return Value: 0
--Debug Output Start--
--Debug Output End--

Node: <VM3> fenced

Pour plus d’informations sur le test d’un appareil d’isolation, consultez l’article Red Hat suivant.

Étape suivante

Tutoriel : Configurer un écouteur de groupe de disponibilité sur les machines virtuelles Linux

Partager via

Tutoriel : Configurer des groupes de disponibilité pour SQL Server sur des machines virtuelles RHEL dans Azure

Prérequis

Créer un groupe de ressources

Créer un groupe à haute disponibilité

Créer des machines virtuelles RHEL dans le groupe à haute disponibilité

Tester la connexion aux machines virtuelles créées

Activer la haute disponibilité

Créez le cluster Pacemaker

Activer et démarrer le service pcsd et Pacemaker

Configurer l’agent d’isolation

Inscrire une nouvelle application dans Microsoft Entra ID

Créer un rôle personnalisé pour l’agent d’isolation

Affecter le rôle personnalisé au principal de service

Créer les appareils STONITH

Installer SQL Server et mssql-tools

Installer SQL Server sur des machines virtuelles

Ouvrir le port de pare-feu 1433 pour les connexions distantes

Installer des outils de ligne de commande SQL Server

Vérifier l’état de SQL Server

Configurer un groupe de disponibilité

Activer les groupes de disponibilité AlwaysOn et redémarrer mssql-server

Créer un certificat

Copier le certificat sur les réplicas secondaires et créer les certificats sur le serveur

Créer les points de terminaison de mise en miroir de bases de données sur tous les réplicas

Créez le groupe de disponibilité

Joindre les réplicas secondaires au groupe de disponibilité

Ajouter une base de données au groupe de disponibilité

Vérifier que la base de données est créée sur les serveurs secondaires

Créer les ressources de groupe de disponibilité dans le cluster Pacemaker

Créer la ressource de cluster du groupe de disponibilité

Créer une ressource d’adresse IP virtuelle

Ajouter des contraintes

Réactiver stonith

Vérification du statut du cluster

Test de basculement

Tester l’isolation

Étape suivante

Commentaires

Ressources supplémentaires

Partager via

Tutoriel : Configurer des groupes de disponibilité pour SQL Server sur des machines virtuelles RHEL dans Azure

Prérequis

Créer un groupe de ressources

Créer un groupe à haute disponibilité

Créer des machines virtuelles RHEL dans le groupe à haute disponibilité

Tester la connexion aux machines virtuelles créées

Activer la haute disponibilité

Créez le cluster Pacemaker

Activer et démarrer le service pcsd et Pacemaker

Configurer l’agent d’isolation

Inscrire une nouvelle application dans Microsoft Entra ID

Créer un rôle personnalisé pour l’agent d’isolation

Affecter le rôle personnalisé au principal de service

Créer les appareils STONITH

Installer SQL Server et mssql-tools

Installer SQL Server sur des machines virtuelles

Ouvrir le port de pare-feu 1433 pour les connexions distantes

Installer des outils de ligne de commande SQL Server

Vérifier l’état de SQL Server

Configurer un groupe de disponibilité

Activer les groupes de disponibilité AlwaysOn et redémarrer mssql-server

Créer un certificat

Copier le certificat sur les réplicas secondaires et créer les certificats sur le serveur

Créer les points de terminaison de mise en miroir de bases de données sur tous les réplicas

Créez le groupe de disponibilité

Créer une connexion SQL Server pour Pacemaker

Joindre les réplicas secondaires au groupe de disponibilité

Ajouter une base de données au groupe de disponibilité

Vérifier que la base de données est créée sur les serveurs secondaires

Créer les ressources de groupe de disponibilité dans le cluster Pacemaker

Créer la ressource de cluster du groupe de disponibilité

Créer une ressource d’adresse IP virtuelle

Ajouter des contraintes

Réactiver stonith

Vérification du statut du cluster

Test de basculement

Tester l’isolation

Étape suivante

Commentaires

Ressources supplémentaires