Vérification des référentiels HAE d' SUSE

1. Vérifiez que les référentiels de l'extension de haute disponibilité d' SUSELinux ® Enterprise sont activés en exécutant la commande suivante sur les deux nœuds.

   zypper repos --show-enabled-only | grep High
   

   Ignorez les étapes suivantes si le résultat inclut les référentiels SLE HAE pour Pool et Updates. Par exemple

   • SUSE_Linux_Enterprise_High_Availability_Extension_ppc64le:SLE-Product-HA15-SP6-Pool
   • SUSE_Linux_Enterprise_High_Availability_Extension_ppc64le:SLE-Product-HA15-SP6-Updates

2. Si les référentiels HAE ne figurent pas dans la liste, utilisez yast2 pour les activer.

   • Logiciel
   • Produits complémentaires
   • Ajouter
   • Extensions et modules du serveur d'enregistrement
     • Yast2 itère sur les deux référentiels Pool et Updates
     • Ajouter les deux référentiels
   • Quitter l'application yast2

3. Une fois cette opération terminée, réessayez la même commande sur les deux nœuds.

   zypper repos --show-enabled-only | grep High
   

Les deux référentiels SLE HAE sont répertoriés.

Installation des progiciels SLE HAE

Utilisez la commande suivante pour installer les progiciels requis.

Sur les deux nœuds, exécutez la commande suivante.

zypper install -t pattern ha_sles

Vérification de la configuration matérielle requise

Consultez la configuration matérielle requise ci-dessous pour configurer un cluster SLE à haute disponibilité.

Pour connaître la configuration matérielle requise en détail, consultez la documentation relative à la haute disponibilité d’ SUSELinux Enterprise dans la section Installation et configuration : guide de démarrage rapide.

• Deux serveurs virtuels ou partitions logiques servant de nœuds de cluster.
• Un deuxième canal de communication réseau ou une interface réseau agrégée pour Corosync.
• Un volume partagé destiné à être utilisé comme périphérique de bloc STONITH (SBD).
• Un temporisateur de surveillance matériel pour un cloisonnement fiable des nœuds.

Création de volumes de stockage partagés

Utilisez l'interface Web de l' IBM Cloud PowerVS pour créer un ou trois volumes partagés destinés à être utilisés comme périphériques SBD. SUSE Il est recommandé de créer trois volumes afin de garantir la redondance. Ces informations se poursuivent avec la création d'un disque SBD unique.

Si vous choisissez d'utiliser plusieurs disques, répétez les étapes suivantes pour chaque volume, selon les besoins.

1. Accéder à la page Power Virtual Server- Storage Volumes.

2. Cliquez sur Créer un volume.

3. Dans le formulaire Créer un volume de stockage, saisissez les informations suivantes.

   • Saisissez un nom pour le volume.
   • Définissez la taille (Go) sur 1 (valeur par défaut).
   • Activer le partage.
   • Acceptez les conditions générales en cochant la case correspondante.

4. Cliquez sur Créer un volume pour valider.

   Vous devez maintenant monter les volumes sur les deux nœuds du cluster.

5. Modifiez la partition logique du premier nœud du cluster.

6. Cliquez sur Attacher un volume existant pour attacher le volume partagé créé précédemment à ce nœud.

7. Répétez les mêmes étapes pour le deuxième nœud du cluster.

8. Sur n'importe quel nœud, exécutez la commande suivante pour identifier les noms de périphériques des volumes de 1 G.

   multipath -l | grep -B1 'size=1G'
   

   Si la sortie de la commande multipath -l est :

   36005076813810264e800000000006f10 dm-0 IBM,2145
   size=1G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
   

9. Pour vérifier le nom du périphérique associé au volume partagé, exécutez la commande suivante.

   ls /dev/disk/by-id/wwn-0x6005076813810264e800000000006f10
   

   Le périphérique SBD doit porter le même nom sur tous les nœuds du cluster afin de garantir le bon fonctionnement de ce dernier.

   Pour simplifier les étapes suivantes, exportez le chemin d'accès au périphérique SBD sous forme de variable d'environnement afin de l'utiliser lors de l'initialisation du cluster.

   export SBD_DEVICE=/dev/disk/by-id/wwn-0x6005076813810264e800000000006f10
   

Configuration du watchdog matériel

Le temporisateur de surveillance matériel est activé par défaut sur les partitions logiques d' Power10. Pour vérifier sa disponibilité, exécutez la commande suivante.

ls /dev/watchdog*

Le résultat répertorie deux appareils : et /dev/watchdog /dev/watchdog0.

Si aucun dispositif de surveillance n'est répertorié, exécutez la commande suivante pour vérifier que le mode de compatibilité du processeur est défini sur Power10.

LD_SHOW_AUXV=1 /bin/true | grep _PLATFORM

Recherchez les champs suivants dans le résultat.

• AT_BASE_PLATFORM – indique le type de processeur réel.
• AT_PLATFORM – indique le mode de compatibilité du processeur.

Le mode de compatibilité du processeur doit être défini sur Power10. S'il est configuré sur une version antérieure, le watchdog de l'hyperviseur n'est pas disponible.

Arbitre

Pour un cluster à deux nœuds, il est recommandé d'utiliser une troisième LPAR comme arbitre. L'arbitre est une partition logique qui ne fait pas partie du cluster. Il héberge le serveur QNetd en tant que troisième instance afin de permettre la détermination du quorum du cluster dans les scénarios de split brain. Lorsque le nombre de nœuds du cluster est pair, les arbitres sont indispensables car ils ajoutent une instance au quorum.

Pour plus d'informations, consultez la documentation d' SUSE, sections QDevice et QNetd.

L'arbitre est généralement configuré une fois que le cluster est en cours d'exécution. Suivez l'approche crm cluster init qdevice décrite dans la documentation SUSE.

Configuration de la synchronisation de l'heure

Les deux nœuds du cluster doivent être synchronisés dans le temps pour garantir un fonctionnement correct. Lorsque des partitions logiques s'exécutent sur l' PowerVS,, la synchronisation horaire est gérée automatiquement via l' Hardware Management Console (HMC). Dans cette configuration, le démon chrony n'est pas nécessaire.

Configuration du premier nœud du cluster

Les scripts d'installation de l'extension de haute disponibilité d' SUSELinux Enterprise configurent automatiquement de nombreux composants clés de l'environnement de cluster.

sudo crm cluster init --name "$CLUSTERNAME" --sbd-device "$SBD_DEVICE"

Appuyez sur Entrée pour accepter les valeurs par défaut, ou saisissez y et appuyez sur Entrée lorsque vous y êtes invité.

INFO: Loading "default" profile from /etc/crm/profiles.yml
WARNING: chronyd.service is not configured to start at system boot.
Do you want to continue anyway (y/n)? y
INFO: The user 'hacluster' will have the login shell configuration changed to /bin/bash
Continue (y/n)? y
INFO: A new ssh keypair is generated for user hacluster.
INFO: Configuring csync2
INFO: Starting csync2.socket service on ths-3
INFO: BEGIN csync2 checking files
INFO: END csync2 checking files
INFO: 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.51.0.84]
Port for ring0 [5405]
INFO: Initializing SBD
INFO: Hawk cluster interface is now running. To see cluster status, open:
INFO:   https://10.51.0.84:7630/
INFO: Log in with username 'hacluster', password 'linux'
WARNING: You should change the hacluster password to something more secure!
INFO: Starting pacemaker.service on ths-3
INFO: BEGIN Waiting for cluster
...........                                                                     INFO: END Waiting for cluster
INFO: Loading initial cluster configuration
WARNING: "stonith-enabled" in crm_config is set to true, it was false
INFO: 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.51.0.12
INFO: BEGIN Configuring virtual IP (10.51.0.12)
.                                                                               INFO: END Configuring virtual IP (10.51.0.12)
INFO: 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
INFO: Done (log saved to /var/log/crmsh/crmsh.log on ths-3)

Le cluster est désormais opérationnel avec un seul nœud.

Configuration du deuxième nœud du cluster

Utilisez les informations suivantes pour configurer le deuxième nœud du cluster.

1. Connectez-vous au deuxième nœud du cluster.

2. Pour intégrer le nœud au cluster existant, utilisez la commande ha-cluster-join. Cette commande nécessite un compte utilisateur et le nom d'hôte du premier nœud du cluster.

   sudo crm cluster join -u root -c $NODE1
   

3. Appuyez sur Entrée pour accepter les valeurs par défaut, ou saisissez y puis appuyez sur Entrée lorsque vous y êtes invité.

   WARNING: chronyd.service is not configured to start at system boot.
   Do you want to continue anyway (y/n)? y
   INFO: The user 'hacluster' will have the login shell configuration changed to /bin/bash
   Continue (y/n)? y
   INFO: A new ssh keypair is generated for user hacluster.
   INFO: Configuring csync2
   INFO: Starting csync2.socket service
   INFO: BEGIN csync2 syncing files in cluster
   INFO: END csync2 syncing files in cluster
   INFO: Merging known_hosts
   Warning: Permanently added 'ths-4' (ED25519) to the list of known hosts.
   INFO: BEGIN Probing for new partitions
   INFO: END Probing for new partitions
   Address for ring0 [10.51.0.230]
   INFO: Got SBD configuration
   INFO: Hawk cluster interface is now running. To see cluster status, open:
   INFO:   https://10.51.0.230:7630/
   INFO: Log in with username 'hacluster', password 'linux'
   WARNING: You should change the hacluster password to something more secure!
   INFO: Starting pacemaker.service on ths-4
   INFO: BEGIN Waiting for cluster
   ..                                                                              INFO: END Waiting for cluster
   INFO: BEGIN Adjusting sbd related timeout values
   WARNING: "stonith-timeout" in crm_config is set to 83, it was 43
   INFO: END Adjusting sbd related timeout values
   INFO: Set property "priority" in rsc_defaults to 1
   WARNING: "priority-fencing-delay" in crm_config is set to 60, it was 0
   INFO: BEGIN Reloading cluster configuration
   INFO: END Reloading cluster configuration
   INFO: Done (log saved to /var/log/crmsh/crmsh.log on ths-4)
   

4. Pour vérifier que le cluster SLE est en cours d’exécution, exécutez la commande suivante.

   sudo crm status
   

   Si aucune erreur ne s'est produite, la section Node List (Liste des nœuds de la zone de travail) de la sortie affiche les deux nœuds, répertoriés comme Online.

   Node List:
     * Online: [ ths-3 ths-4 ]
   

   La section Ressources répertorie deux ressources dont l'état est Démarré, ce qui indique qu'elles sont actives et fonctionnent correctement.

   Full List of Resources:
     * stonith-sbd	(stonith:external/sbd):	 Started ths-3
     * admin-ip	(ocf::heartbeat:IPaddr2):	 Started ths-3
   

Définition d'un mot de passe pour l'identifiant utilisateur hacluster

Sur les deux nœuds, exécutez la commande suivante pour définir le mot de passe du compte utilisateur hacluster.

passwd hacluster

Vérification de l'état du SBD

Utilisez les informations suivantes pour vérifier que la variable SBD_DEVICE est définie.

Pour vérifier l'état des emplacements SBD à partir de l'un des nœuds du cluster, exécutez la commande suivante.

sbd -d $SBD_DEVICE list

Le résultat répertorie les deux nœuds du cluster, chacun avec un statut de clean, indiquant que le mécanisme SBD fonctionne correctement et qu'aucune action de fencing n'est en attente.

Configurer l'action de fencing

Par défaut, le nœud isolé est automatiquement redémarré après un événement d'isolation.

Cependant, une autre approche consiste à mettre le nœud hors tension et à le redémarrer manuellement après avoir identifié la cause première de la panne.

L'activation manuelle du nœud présente plusieurs avantages.

• Cela évite les boucles de protection inutiles, qui peuvent se produire si le problème sous-jacent persiste.
• Cela garantit que chaque événement de fencing est détecté et traité, ce qui améliore la stabilité et la fiabilité du cluster.

Pour configurer l'action de fencing afin de mettre le nœud hors tension, utilisez la commande suivante.

sudo crm configure property stonith-action="off"

Vérifiez la configuration actuelle du cluster à l'aide de la commande suivante.

sudo crm configure show

Test des opérations de cloisonnement

Pour tester la configuration STONITH, vous devez déclencher manuellement une action de fencing sur l'un des nœuds.

1. Exécutez la commande suivante pour isoler manuellement NODE2.

   crm node fence ${NODE2}
   

2. Saisissez y et appuyez sur Entrée pour continuer lorsque le message suivant s'affiche, ce qui mettra fin à l' NODE2:

   Fencing ths-4 will shut down the node and migrate any resources that are running on it! Do you want to fence ths-4  (y/n)? y
   

3. Activez la fonction NODE2, attendez qu'il réintègre le cluster, puis testez le fencing dans le sens inverse.

   Sur NODE2, exécutez la commande suivante.

   crm status
   

4. Lorsque les deux nœuds apparaissent comme Online dans l'état du cluster, attendez environ une minute pour garantir la stabilité. Ensuite, depuis NODE2, lancez une opération de fencing sur NODE1 en exécutant la commande suivante, qui mettra hors service NODE1:

   crm node fence ${NODE1}
   

5. Activez NODE1, puis démarrez les services du cluster sur le nœud.