Partager via

Tutoriel : configurer des groupes de disponibilité pour SQL Server sur des machines virtuelles SLES dans Azure

  • Article

S’applique à : SQL Server sur machine virtuelle Azure

Remarque

Nous utilisons SQL Server 2022 (16.x) avec SUSE Linux Enterprise Server (SLES) v15 dans ce tutoriel. Toutefois, il est possible d'utiliser SQL Server 2019 (15.x) avec SLES v12 ou SLES v15, pour configurer la haute disponibilité.

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 SLES
  • 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

  • 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. Ce didacticiel utilise 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 un réseau virtuel et un sous-réseau

  1. Créez un sous-réseau nommé avec une plage d’adresses IP prédéfinie. Remplacez ces valeurs dans la commande suivante :

    • <resourceGroupName>
    • <vNetName>
    • <subnetName>
    az network vnet create \
    --resource-group <resourceGroupName> \
    --name <vNetName> \
    --address-prefix 10.1.0.0/16 \
    --subnet-name <subnetName> \
    --subnet-prefix 10.1.1.0/24

    La commande précédente crée un réseau virtuel et un sous-réseau contenant une plage d’adresses IP personnalisée.

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

  1. Obtenez la liste des images de machine virtuelle qui offrent SLES v15 SP4 avec BYOS (apportez votre propre abonnement). Vous pouvez également utiliser la machine virtuelle SUSE Enterprise Linux 15 SP4 + Patching (sles-15-sp4-basic).

    az vm image list --all --offer "sles-15-sp3-byos"
# if you want to search the basic offers you could search using the command below
az vm image list --all --offer "sles-15-sp3-basic"

    Vous devez voir les résultats suivants lorsque vous recherchez les images BYOS :

    [
   {
      "offer": "sles-15-sp3-byos",
      "publisher": "SUSE",
      "sku": "gen1",
      "urn": "SUSE:sles-15-sp3-byos:gen1:2022.05.05",
      "version": "2022.05.05"
   },
   {
      "offer": "sles-15-sp3-byos",
      "publisher": "SUSE",
      "sku": "gen1",
      "urn": "SUSE:sles-15-sp3-byos:gen1:2022.07.19",
      "version": "2022.07.19"
   },
   {
      "offer": "sles-15-sp3-byos",
      "publisher": "SUSE",
      "sku": "gen1",
      "urn": "SUSE:sles-15-sp3-byos:gen1:2022.11.10",
      "version": "2022.11.10"
   },
   {
      "offer": "sles-15-sp3-byos",
      "publisher": "SUSE",
      "sku": "gen2",
      "urn": "SUSE:sles-15-sp3-byos:gen2:2022.05.05",
      "version": "2022.05.05"
   },
   {
      "offer": "sles-15-sp3-byos",
      "publisher": "SUSE",
      "sku": "gen2",
      "urn": "SUSE:sles-15-sp3-byos:gen2:2022.07.19",
      "version": "2022.07.19"
   },
   {
      "offer": "sles-15-sp3-byos",
      "publisher": "SUSE",
      "sku": "gen2",
      "urn": "SUSE:sles-15-sp3-byos:gen2:2022.11.10",
      "version": "2022.11.10"
   }
]

    Ce didacticiel utilise SUSE:sles-15-sp3-byos:gen1:2022.11.10.

    Important

    Pour la configuration du groupe de disponibilité, les noms de machines doivent comporter moins de 15 caractères. Les noms d'utilisateur ne peuvent pas contenir de caractères en majuscules et les mots de passe doivent comporter entre 12 et 72 caractères.

  2. Créez trois machines virtuelles dans le groupe à haute disponibilité. Remplacez ces valeurs dans la commande suivante :

    • <resourceGroupName>
    • <VM-basename>
    • <availabilitySetName>
    • <VM-Size> - Par exemple, « Standard_D16s_v3 »
    • <username>
    • <adminPassword>
    • <vNetName>
    • <subnetName>
    for i in `seq 1 3`; do
    az vm create \
       --resource-group <resourceGroupName> \
       --name <VM-basename>$i \
       --availability-set <availabilitySetName> \
       --size "<VM-Size>" \
       --os-disk-size-gb 128 \
       --image "SUSE:sles-15-sp3-byos:gen1:2022.11.10" \
       --admin-username "<username>" \
       --admin-password "<adminPassword>" \
       --authentication-type all \
       --generate-ssh-keys \
       --vnet-name "<vNetName>" \
       --subnet "<subnetName>" \
       --public-ip-sku Standard \
       --public-ip-address ""
    done

La commande précédente crée les machines virtuelles à l’aide du réseau virtuel défini précédemment. Pour plus d’informations sur les différentes configurations, consultez l’article az vm create.

La commande inclut également le paramètre --os-disk-size-gb permettant de créer une taille de lecteur de système d’exploitation personnalisée de 128 Go. Si vous augmentez cette taille ultérieurement, développez les volumes de dossiers appropriés pour prendre en charge votre installation, configurez le Gestionnaire de volumes logiques (LVM).

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/sles1",
  "location": "westus",
  "macAddress": "<Some MAC address>",
  "powerState": "VM running",
  "privateIpAddress": "<IP1>",
  "resourceGroup": "<resourceGroupName>",
  "zones": ""
}

Tester la connexion aux machines virtuelles créées

Connectez-vous à chaque machine virtuelle à 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>@sles1 ~]$

Tapez exit pour quitter la session SSH.

S’inscrire auprès de SUSEConnect et installer des packages à haute disponibilité

Pour suivre ce tutoriel, vos machines virtuelles doivent être inscrites auprès de SUSEConnect pour recevoir des mises à jour et un support. Vous pouvez ensuite installer le module d’extension de haute disponibilité ou le modèle, qui est un ensemble de packages qui active la haute disponibilité.

Il est plus facile d'ouvrir simultanément une session SSH sur chacune des machines virtuelles (nœuds), car dans cet article, les mêmes commandes doivent être exécutées sur toutes les machines virtuelles.

Si vous copiez-collez plusieurs commandes sudo et êtes invité à entrer un mot de passe, seule une commande sera exécutée. Vous devez exécuter chaque commande séparément.

Connectez-vous à chaque nœud de machine virtuelle pour exécuter les étapes suivantes.

Inscrire la machine virtuelle auprès de SUSEConnect

Pour inscrire votre nœud de machine virtuelle auprès de SUSEConnect, remplacez ces valeurs dans la commande suivante, sur tous les nœuds :

  • <subscriptionEmailAddress>
  • <registrationCode>
sudo SUSEConnect
    --url=https://scc.suse.com
    -e <subscriptionEmailAddress> \
    -r <registrationCode>

Installer l’extension de haute disponibilité

Pour installer l’extension haute disponibilité, exécutez la commande suivante sur tous les nœuds :

sudo SUSEConnect -p sle-ha/15.3/x86_64 -r <registration code for Partner Subscription for High Availability Extension>

Configurer l’accès SSH sans mot de passe entre les nœuds

L’accès SSH sans mot de passe permet à vos machines virtuelles de communiquer entre elles à l’aide de clés publiques SSH. Vous devez configurer des clés SSH sur chaque nœud et copier ces clés sur chaque nœud.

Générer de nouvelles clés SSH

La taille de clé SSH requise est de 4 096 bits. Sur chaque machine virtuelle, accédez au dossier /root/.ssh et exécutez la commande suivante :

ssh-keygen -t rsa -b 4096

Au cours de cette étape, vous pourriez être invité à remplacer un fichier SSH existant. Vous devez accepter cette invite. Vous n’avez pas besoin d’entrer une phrase secrète.

Copiez les clés SSH publiques

Sur chaque nœud managé, vous devez copier la clé publique à partir du nœud que vous venez de créer, à l’aide de la commande ssh-copy-id. Si vous souhaitez spécifier le répertoire cible sur le nœud managé, vous pouvez utiliser le paramètre -i.

Dans la commande suivante, le compte <username> peut être le même que celui que vous avez configuré pour chaque nœud lors de la création de la machine virtuelle. Vous pouvez également utiliser le compte root, mais cela n’est pas recommandé dans un environnement de production.

sudo ssh-copy-id <username>@sles1
sudo ssh-copy-id <username>@sles2
sudo ssh-copy-id <username>@sles3

Vérifier l’accès sans mot de passe à partir de chaque nœud

Pour vérifier que la clé publique SSH a été copiée sur chaque nœud, utilisez la commande ssh à partir du nœud de contrôleur. Si vous avez copié correctement les clés, vous ne serez pas invité à entrer de mot de passe et la connexion aboutira.

Dans cet exemple, nous nous connectons aux deuxième et troisième nœuds à partir de la première machine virtuelle (sles1). De nouveau, le compte <username> peut être le même que celui que vous avez configuré pour chaque nœud lors de la création de la machine virtuelle

ssh <username>@sles2
ssh <username>@sles3

Répétez ce processus à partir des trois nœuds, afin que chaque nœud puisse communiquer avec les autres sans nécessiter de mots de passe.

Configurer la résolution de noms

Vous pouvez configurer la résolution de noms à l’aide de DNS ou en modifiant manuellement le fichier etc/hosts sur chaque nœud.

Pour plus d’informations sur DNS et Active Directory, consultez Joindre SQL Server sur un hôte Linux à un domaine Active Directory.

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 et exposera votre machine virtuelle à des réseaux externes.

Les machines virtuelles et leur adresse IP utilisées dans cet exemple sont répertoriées comme suit :

  • sles1 : 10.0.0.85
  • sles2 : 10.0.0.86
  • sles3 : 10.0.0.87

Configurer le cluster

Pour ce tutoriel, votre première machine virtuelle (sles1) est nœud 1, votre deuxième machine virtuelle (sles2) est nœud 2 et votre troisième machine virtuelle (sles3) est nœud 3. Pour plus d’informations sur l’installation de clusters, consultez Configurer Pacemaker sur SUSE Linux Enterprise Server dans Azure.

Installation du cluster

  1. Exécutez la commande suivante pour installer le package ha-cluster-bootstrap sur le nœud 1, puis redémarrez le nœud. Dans cet exemple, il s'agit de la machine virtuelle sles1.

    sudo zypper install ha-cluster-bootstrap

    Une fois le nœud redémarré, exécutez la commande suivante pour déployer le cluster :

    sudo crm cluster init --name sqlcluster

    Vous verrez un résultat similaire à ce qui suit :

    Do you want to continue anyway (y/n)? y
  Generating SSH key for root
  The user 'hacluster' will have the login shell configuration changed to /bin/bash
Continue (y/n)? y
  Generating SSH key for hacluster
  Configuring csync2
  Generating csync2 shared key (this may take a while)...done
  csync2 checking files...done
  Detected cloud platform: microsoft-azure

Configure Corosync (unicast):
  This will configure the cluster messaging layer.  You will need
  to specify a network address over which to communicate (default
  is eth0's network, but you can use the network address of any
  active interface).

  Address for ring0 [10.0.0.85]
  Port for ring0 [5405]

Configure SBD:
  If you have shared storage, for example a SAN or iSCSI target,
  you can use it avoid split-brain scenarios by configuring SBD.
  This requires a 1 MB partition, accessible to all nodes in the
  cluster.  The device path must be persistent and consistent
  across all nodes in the cluster, so /dev/disk/by-id/* devices
  are a good choice.  Note that all data on the partition you
  specify here will be destroyed.

Do you wish to use SBD (y/n)? n
WARNING: Not configuring SBD - STONITH will be disabled.
  Hawk cluster interface is now running. To see cluster status, open:
    https://10.0.0.85:7630/
  Log in with username 'hacluster', password 'linux'
WARNING: You should change the hacluster password to something more secure!
  Waiting for cluster..............done
  Loading initial cluster configuration

Configure Administration IP Address:
  Optionally configure an administration virtual IP
  address. The purpose of this IP address is to
  provide a single IP that can be used to interact
  with the cluster, rather than using the IP address
  of any specific cluster node.

Do you wish to configure a virtual IP address (y/n)? y
  Virtual IP []10.0.0.89
  Configuring virtual IP (10.0.0.89)....done

Configure Qdevice/Qnetd:
  QDevice participates in quorum decisions. With the assistance of
  a third-party arbitrator Qnetd, it provides votes so that a cluster
  is able to sustain more node failures than standard quorum rules
  allow. It is recommended for clusters with an even number of nodes
  and highly recommended for 2 node clusters.

Do you want to configure QDevice (y/n)? n
Done (log saved to /var/log/crmsh/ha-cluster-bootstrap.log)

  2. Vérifiez l’état du cluster sur le nœud 1 à l’aide de la commande suivante :

    sudo crm status

    Votre sortie doit inclure le texte suivant s’il a réussi :

    1 node configured
1 resource instance configured

  3. Sur tous les nœuds, remplacez le mot de passe pour hacluster par quelque chose de plus sécurisé à l’aide de la commande suivante. Vous devez également modifier votre mot de passe utilisateur root :

    sudo passwd hacluster

    sudo passwd root

  4. Exécutez la commande suivante sur les nœud 2 et nœud 3 pour d’abord installer le package crmsh :

    sudo zypper install crmsh

    À présent, exécutez la commande pour rejoindre le cluster :

    sudo crm cluster join

    Voici quelques-unes des interactions à attendre :

    Join This Node to Cluster:
You will be asked for the IP address of an existing node, from which
configuration will be copied.  If you have not already configured
passwordless ssh between nodes, you will be prompted for the root
password of the existing node.

  IP address or hostname of existing node (e.g.: 192.168.1.1) []10.0.0.85
  Configuring SSH passwordless with root@10.0.0.85
  root@10.0.0.85's password:
  Configuring SSH passwordless with hacluster@10.0.0.85
  Configuring csync2...done
Merging known_hosts
WARNING: scp to sles2 failed (Exited with error code 1, Error output: The authenticity of host 'sles2 (10.1.1.5)' can't be established.
ECDSA key fingerprint is SHA256:UI0iyfL5N6X1ZahxntrScxyiamtzsDZ9Ftmeg8rSBFI.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
lost connection
), known_hosts update may be incomplete
Probing for new partitions...done
  Address for ring0 [10.0.0.86]

Hawk cluster interface is now running. To see cluster status, open:
    https://10.0.0.86:7630/
  Log in with username 'hacluster', password 'linux'
WARNING: You should change the hacluster password to something more secure!
Waiting for cluster.....done
Reloading cluster configuration...done
  Done (log saved to /var/log/crmsh/ha-cluster-bootstrap.log)

  5. Une fois que vous avez joint toutes les machines au cluster, vérifiez votre ressource pour voir si toutes les machines virtuelles sont en ligne :

    sudo crm status

    Vous devez normalement voir la sortie suivante.

    Stack: corosync
 Current DC: sles1 (version 2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712) - partition with quorum
 Last updated: Mon Mar  6 18:01:17 2023
 Last change:  Mon Mar  6 17:10:09 2023 by root via cibadmin on sles1

3 nodes configured
1 resource instance configured

Online: [ sles1 sles2 sles3 ]

Full list of resources:

 admin-ip       (ocf::heartbeat:IPaddr2):       Started sles1

  6. Installez le composant de ressources de cluster. Exécutez la commande suivante sur tous les nœuds.

    sudo zypper in socat

  7. Installez le composant azure-lb. Exécutez la commande suivante sur tous les nœuds.

    sudo zypper in resource-agents

  8. Configurez le système d’exploitation. Suivez les étapes suivantes sur tous les nœuds.

    1. Modifiez le fichier config :

      sudo vi /etc/systemd/system.conf

    2. Remplacez la valeur DefaultTasksMax par 4096 :

      #DefaultTasksMax=512
DefaultTasksMax=4096

    3. Enregistrez et quittez l’éditeur vi.

    4. Pour activer ce paramètre, exécutez la commande suivante :

      sudo systemctl daemon-reload

    5. Testez si la modification a réussi :

      sudo systemctl --no-pager show | grep DefaultTasksMax

  9. Réduisez la taille du cache d’intégrité. Suivez les étapes suivantes sur tous les nœuds.

    1. Modifiez le fichier config du contrôle système :

      sudo vi /etc/sysctl.conf

    2. Ajoutez les deux lignes suivantes au fichier :

      vm.dirty_bytes = 629145600
vm.dirty_background_bytes = 314572800

    3. Enregistrez et quittez l’éditeur vi.

  10. Installez le Kit de développement logiciel (SDK) Azure Python sur tous les nœuds avec les commandes suivantes :

    sudo zypper install fence-agents
# Install the Azure Python SDK on SLES 15 or later:
# You might need to activate the public cloud extension first. In this example, the SUSEConnect command is for SLES 15 SP1
SUSEConnect -p sle-module-public-cloud/15.1/x86_64
sudo zypper install python3-azure-mgmt-compute
sudo zypper install python3-azure-identity

Configurer l’agent d’isolation

Un appareil STONITH fournit un agent d’isolation. Les instructions ci-dessous ont été modifiées pour ce tutoriel. Pour plus d’informations, consultez Créer un appareil STONITH de l’agent de clôture Azure.

Vérifiez la version de l’agent de clôture Azure pour vous assurer qu’il a été mis à jour. Utilisez la commande suivante :

sudo zypper info resource-agents

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

Information for package resource-agents:
----------------------------------------
Repository     : SLE-Product-HA15-SP3-Updates
Name           : resource-agents
Version        : 4.8.0+git30.d0077df0-150300.8.37.1
Arch           : x86_64
Vendor         : SUSE LLC <https://www.suse.com/>
Support Level  : Level 3
Installed Size : 2.5 MiB
Installed      : Yes (automatically)
Status         : up-to-date
Source package : resource-agents-4.8.0+git30.d0077df0-150300.8.37.1.src
Upstream URL   : http://linux-ha.org/
Summary        : HA Reusable Cluster Resource Scripts
Description    : A set of scripts to interface with several services
                 to operate in a High Availability environment for both
                 Pacemaker and rgmanager service managers.

Inscrivez une nouvelle application dans Microsoft Entra ID

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

  1. Accédez à https://portal.azure.com.
  2. Ouvrez le volet des propriétés de Microsoft Entra ID et relevez le Tenant ID.
  3. Sélectionnez Inscriptions d’applications.
  4. Sélectionnez Nouvelle inscription.
  5. 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).
  6. Sélectionnez Web pour l’URI de redirection, puis entrez 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.
  7. Sélectionnez Certificats et secrets pour votre nouvelle inscription d’application, puis sélectionnez Nouvelle clé secrète client.
  8. Entrez une description pour la nouvelle clé (clé secrète client), puis sélectionnez Ajouter.
  9. Notez la valeur du secret. Elle est utilisée comme mot de passe du principal de service.
  10. Sélectionnez Vue d’ensemble. Notez l’ID de l’application. Cet identifiant est utilisé en tant que nom d'utilisateur (ID de connexion dans les étapes ci-dessous) du principal de service.

Créer un rôle personnalisé pour l’agent de clôture

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"
}

Attribuer le rôle personnalisé au principal de service

Attribuez au principal de service le rôle personnalisé Linux Fence Agent Role-<username> qui a été créé à l’étape précédente. Répétez ces étapes pour tous les nœuds.

Avertissement

N’utilisez pas le rôle Propriétaire à partir de là.

  1. Accédez à https://portal.azure.com
  2. Ouvrez le volet Toutes les ressources
  3. Sélectionnez la machine virtuelle du premier nœud de cluster.
  4. Sélectionnez Contrôle d’accès (IAM)
  5. Sélectionnez Ajouter des attributions de rôle.
  6. Sélectionnez le rôle Linux Fence Agent Role-<username> dans la liste Rôle.
  7. Laissez Attribuer l’accès à comme valeur par défaut Users, group, or service principal.
  8. Dans la liste Sélectionner, entrez le nom de l’application que vous avez créée précédemment, par exemple <resourceGroupName>-app.
  9. Sélectionnez Enregistrer.

Créer les appareils STONITH

  1. 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.

  2. Exécutez crm configure pour ouvrir l’invite crm :

    sudo crm configure

  3. Dans l’invite crm, exécutez la commande suivante pour configurer les propriétés de la ressource, ce qui crée la ressource appelée rsc_st_azure comme indiqué dans l’exemple suivant :

    primitive rsc_st_azure stonith:fence_azure_arm params subscriptionId="subscriptionID" resourceGroup="ResourceGroup_Name" tenantId="TenantID" login="ApplicationID" passwd="servicePrincipalPassword" pcmk_monitor_retries=4 pcmk_action_limit=3 power_timeout=240 pcmk_reboot_timeout=900 pcmk_host_map="sles1:sles1;sles2:sles2;sles3:sles3" op monitor interval=3600 timeout=120
commit
quit

  4. Exécutez les commandes suivantes pour configurer l’agent de clôture :

    sudo crm configure property stonith-timeout=900
sudo crm configure property stonith-enabled=true
sudo crm configure property concurrent-fencing=true

  5. Vérifiez l’état de votre cluster pour voir que STONITH a été activé :

    sudo crm status

    Vous devez obtenir une sortie similaire à la suivante :

    Stack: corosync
 Current DC: sles1 (version 2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712) - partition with quorum
 Last updated: Mon Mar  6 18:20:17 2023
 Last change:  Mon Mar  6 18:10:09 2023 by root via cibadmin on sles1

3 nodes configured
2 resource instances configured

Online: [ sles1 sles2 sles3 ]

Full list of resources:

admin-ip       (ocf::heartbeat:IPaddr2):       Started sles1
rsc_st_azure   (stonith:fence_azure_arm):      Started sles2

Installer SQL Server et mssql-tools

Utilisez la section ci-dessous pour installer SQL Server et mssql-tools. Pour plus d’informations, consultez Installer SQL Server sur SUSE Linux Enterprise Server.

Effectuez ces étapes sur tous les nœuds de cette section.

Installer SQL Server sur des machines virtuelles

Exécutez les commandes suivantes pour installer SQL Server :

  1. Téléchargez le fichier config du référentiel Microsoft SQL Server 2019 SLES :

    sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/15/mssql-server-2022.repo

  2. Actualisez vos référentiels.

    sudo zypper --gpg-auto-import-keys refresh

    Pour vous assurer que la clé de signature du package Microsoft est installée sur votre système, utilisez la commande suivante pour importer la clé :

    sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc

  3. Exécutez les commandes suivantes pour installer SQL Server :

    sudo zypper install -y mssql-server

  4. Une fois l'installation du package terminée, lancez mssql-conf setup et suivez les invites pour définir le mot de passe AS et choisir votre édition.

    sudo /opt/mssql/bin/mssql-conf setup

    Notes

    Assurez-vous de spécifier un mot de passe fort pour le compte AS (longueur minimale de 8 caractères, lettres majuscules et minuscules comprises, chiffres de la base 10 et/ou symboles non alphanumériques).

  5. Une fois la configuration terminée, vérifiez que le service est en cours d'exécution :

    systemctl status mssql-server

Installer des outils de ligne de commande SQL Server

Les étapes suivantes installent les outils de ligne de commande SQL Server, nommés sqlcmd et bcp.

  1. Ajoutez le référentiel Microsoft SQL Server à Zypper.

    sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/15/prod.repo

  2. Actualisez vos référentiels.

    sudo zypper --gpg-auto-import-keys refresh

  3. Installez mssql-tools avec le package pour développeur unixODBC. Pour plus d’informations, consultez Installer le pilote Microsoft ODBC pour SQL Server (Linux).

    sudo zypper install -y mssql-tools unixODBC-devel

Par commodité, vous pouvez ajouter /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

Installer l’agent à haute disponibilité de SQL Server

Exécutez la commande suivante sur tous les nœuds pour installer le package d’agent à haute disponibilité pour SQL Server :

sudo zypper install mssql-server-ha

Ouvrir des ports pour les services à haute disponibilité

  1. Vous pouvez ouvrir les ports de pare-feu suivants sur tous les nœuds pour les services de SQL Server et haute disponibilité : 1433, 2224, 3121, 5022, 5405, 21064.

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

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é AlwaysOn SQL Server pour la haute disponibilité sur Linux.

Activer les groupes de disponibilité et redémarrer SQL Server

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

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

sudo systemctl restart mssql-server

Créer un certificat

Microsoft ne prend pas en charge l’authentification Active Directory 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é.

  1. 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 <MasterKeyPassword> par votre propre mot de passe.
    ALTER EVENT SESSION AlwaysOn_health ON SERVER
    WITH (STARTUP_STATE = ON);
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<MasterKeyPassword>';
GO

  2. Connectez-vous au réplica principal à l’aide de SSMS ou de sqlcmd. Les commandes ci-dessous 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 <PrivateKeyPassword> 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 = '<PrivateKeyPassword>'
        );
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

  1. 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 sles2 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 exécuter la commande sudo devant chaque commande à la place.

    # The below command allows you to run commands in the root environment
sudo -i

    scp /var/opt/mssql/data/dbm_certificate.* <username>@sles2:/home/<username>

  2. 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.*

  3. 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 = '<PrivateKeyPassword>'
);
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 désiré pour votre groupe de disponibilité.
  • Remplacez les valeurs sles1, sles2 et sles3 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'sles1'
WITH (
        ENDPOINT_URL = N'tcp://sles1:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC
        ),
    N'sles2'
WITH (
        ENDPOINT_URL = N'tcp://sles2:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC
        ),
    N'sles3'
WITH (
        ENDPOINT_URL = N'tcp://sles3:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC
        );
GO

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

Créer une connexion SQL Server pour Pacemaker

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.

  1. Créez le fichier :

    sudo vi /var/opt/mssql/secrets/passwd

  2. Ajoutez les deux 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.

  3. 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é

  1. 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

  2. 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

  3. 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 :

    La capture d’écran présente les réplicas de disponibilité principaux et secondaires.

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

Cette section suit l’article relatif à l’ajout d’une base de données à un groupe de disponibilité.

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;
GO

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

Notes

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.

Cet article fait référence au guide permettant de créer les ressources de groupe de disponibilité dans le cluster Pacemaker.

Activer Pacemaker

Activez Pacemaker afin qu’il démarre automatiquement.

Exécutez la commande suivante sur tous les nœuds dans le cluster.

sudo systemctl enable pacemaker

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

  1. Exécutez crm configure pour ouvrir l’invite crm :

    sudo crm configure

  2. Dans l’invite crm, exécutez la commande suivante pour configurer les propriétés de la ressource. Les commandes suivantes créent la ressource ag_cluster dans le groupe de disponibilité ag1.

    primitive ag_cluster ocf:mssql:ag params ag_name="ag1" 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 interval=11s role="Master" op monitor timeout=60s interval=12s role="Slave" op notify timeout=60s ms ms-ag_cluster ag_cluster meta master-max="1" master-node-max="1" clone-max="3" clone-node-max="1" notify="true"
commit
quit

    Conseil

    Tapez quit pour quitter l’invite crm.

  3. Définissez la contrainte de co-localisation pour l’adresse IP virtuelle afin d’exécuter le même nœud comme nœud principal :

    sudo crm configure
colocation vip_on_master inf: admin-ip ms-ag_cluster: Master
commit
quit

  4. Ajoutez la contrainte de tri pour empêcher l’adresse IP de pointer temporairement vers le nœud avec le secondaire antérieur au basculement. Exécutez la commande suivante pour créer une contrainte de tri :

    sudo crm configure
order ag_first inf: ms-ag_cluster:promote admin-ip:start
commit
quit

  5. Vérifiez l’état du cluster à l’aide de la commande :

    sudo crm status

    La sortie doit ressembler à celle de l’exemple suivant :

    Cluster Summary:
  * Stack: corosync
  * Current DC: sles1 (version 2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712) - partition with quorum
  * Last updated: Mon Mar  6 18:38:17 2023
  * Last change:  Mon Mar  6 18:38:09 2023 by root via cibadmin on sles1
  * 3 nodes configured
  * 5 resource instances configured

Node List:
  * Online: [ sles1 sles2 sles3 ]

Full List of Resources:
  * admin-ip    (ocf::heartbeat:IPaddr2):                Started sles1
  * rsc_st_azure        (stonith:fence_azure_arm):       Started sles2
  * Clone Set: ms-ag_cluster [ag_cluster] (promotable):
    * Masters: [ sles1 ]
    * Slaves: [ sles2 sles3 ]

  6. Exécutez la commande suivante pour passer en revue les contraintes :

    sudo crm configure show

    La sortie doit ressembler à celle de l’exemple suivant :

    node 1: sles1
node 2: sles2
node 3: sles3
primitive admin-ip IPaddr2 \
        params ip=10.0.0.93 \
        op monitor interval=10 timeout=20
primitive ag_cluster ocf:mssql:ag \
        params ag_name=ag1 \
        meta failure-timeout=60s \
        op start timeout=60s interval=0 \
        op stop timeout=60s interval=0 \
        op promote timeout=60s interval=0 \
        op demote timeout=10s interval=0 \
        op monitor timeout=60s interval=10s \
        op monitor timeout=60s interval=11s role=Master \
        op monitor timeout=60s interval=12s role=Slave \
        op notify timeout=60s interval=0
primitive rsc_st_azure stonith:fence_azure_arm \
        params subscriptionId=xxxxxxx resourceGroup=amvindomain tenantId=xxxxxxx login=xxxxxxx passwd="******" cmk_monitor_retries=4 pcmk_action_limit=3 power_timeout=240 pcmk_reboot_timeout=900 pcmk_host_map="sles1:sles1;les2:sles2;sles3:sles3" \
        op monitor interval=3600 timeout=120
ms ms-ag_cluster ag_cluster \
        meta master-max=1 master-node-max=1 clone-max=3 clone-node-max=1 notify=true
order ag_first Mandatory: ms-ag_cluster:promote admin-ip:start
colocation vip_on_master inf: admin-ip ms-ag_cluster:Master
property cib-bootstrap-options: \
        have-watchdog=false \
        dc-version="2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712" \
        cluster-infrastructure=corosync \
        cluster-name=sqlcluster \
        stonith-enabled=true \
        concurrent-fencing=true \
        stonith-timeout=900
rsc_defaults rsc-options: \
        resource-stickiness=1 \
        migration-threshold=3
op_defaults op-options: \
        timeout=600 \
        record-pending=true

Test de basculement

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

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

    sudo crm resource move ag_cluster sles2

    La sortie doit ressembler à celle de l’exemple suivant :

    INFO: Move constraint created for ms-ag_cluster to sles2
INFO: Use `crm resource clear ms-ag_cluster` to remove this constraint

  2. Vérifiez l’état du cluster :

    sudo crm status

    La sortie doit ressembler à celle de l’exemple suivant :

    Cluster Summary:
  * Stack: corosync
  * Current DC: sles1 (version 2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712) - partition with quorum
  * Last updated: Mon Mar  6 18:40:02 2023
  * Last change:  Mon Mar  6 18:39:53 2023 by root via crm_resource on sles1
  * 3 nodes configured
  * 5 resource instances configured

Node List:
  * Online: [ sles1 sles2 sles3 ]

Full List of Resources:
  * admin-ip    (ocf::heartbeat:IPaddr2):                Stopped
  * rsc_st_azure        (stonith:fence_azure_arm):       Started sles2
  * Clone Set: ms-ag_cluster [ag_cluster] (promotable):
    * Slaves: [ sles1 sles2 sles3 ]

  3. Après un certain temps, la machine virtuelle sles2 est désormais la machine virtuelle principale et les deux autres machines virtuelles sont secondaires. Réexécutez sudo crm status et évaluez la sortie, qui est similaire à l’exemple suivant :

    Cluster Summary:
  * Stack: corosync
  * Current DC: sles1 (version 2.0.5+20201202.ba59be712-150300.4.30.3-2.0.5+20201202.ba59be712) - partition with quorum
  * Last updated: Tue Mar  6 22:00:44 2023
  * Last change:  Mon Mar  6 18:42:59 2023 by root via cibadmin on sles1
  * 3 nodes configured
  * 5 resource instances configured

Node List:
  * Online: [ sles1 sles2 sles3 ]

Full List of Resources:
  * admin-ip    (ocf::heartbeat:IPaddr2):                Started sles2
  * rsc_st_azure        (stonith:fence_azure_arm):       Started sles2
  * Clone Set: ms-ag_cluster [ag_cluster] (promotable):
    * Masters: [ sles2 ]
    * Slaves: [ sles1 sles3 ]

  4. Vérifiez à nouveau vos contraintes à l’aide de crm config show. Notez qu’une autre contrainte a été ajoutée en raison du basculement manuel.

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

    crm configure
delete cli-prefer-ms-ag_cluster
commit

Tester l’isolation

Vous pouvez tester STONITH en exécutant la commande suivante. Essayez d’exécuter la commande ci-dessous à partir de sles1 pour sles3.

sudo crm node fence sles3

Étape suivante

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