Vérification des dépôts SUSE HAE

1. Vérifiez que les référentiels SUSE Linux (R) Enterprise High Availability Extension sont activés en exécutant la commande suivante sur les deux noeuds.

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

   Sautez les étapes suivantes si le résultat comprend les référentiels SLE HAE pour le pool et les mises à jour. 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 dépôts HAE ne sont pas répertoriés, utilisez yast2 pour les activer.

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

3. Lorsque vous avez terminé, essayez à nouveau la même commande sur les deux nœuds.

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

Les deux dépôts SLE HAE sont répertoriés.

Installation des logiciels SLE HAE

Utilisez la commande suivante pour installer les logiciels 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 les exigences matérielles suivantes pour configurer un cluster SLE à haute disponibilité.

Pour connaître la configuration matérielle requise, reportez-vous à la documentation de SUSE Linux Enterprise High Availability dans la section Installation et configuration - Démarrage rapide.

• Deux serveurs virtuels ou partitions logiques pour servir de nœuds de cluster.
• Un deuxième canal de communication réseau ou une interface réseau liée pour Corosync.
• Un volume partagé à utiliser comme périphérique STONITH Block Device (SBD).
• Une minuterie de surveillance matérielle pour une clôture fiable des nœuds.

Création de volumes de stockage partagés

Utilisez l'interface web IBM Cloud PowerVS pour créer un ou trois volumes partagés à utiliser comme périphériques SBD. SUSE recommande de créer trois volumes pour assurer la redondance. Ces informations se poursuivent lors de la création d'un seul disque SBD.

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

1. Allez à la page Serveur virtuel de puissance - Volumes de stockage.

2. Cliquez sur Créer un volume.

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

   • Entrez un nom pour le volume.
   • Réglez la taille (GB) sur 1 (valeur par défaut).
   • Activer la fonction Partageable.
   • Accepter les conditions générales en cochant la case correspondante.

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

   Vous devez maintenant attacher les volumes aux deux nœuds du cluster.

5. Modifier la partition logique du premier nœud de cluster.

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

7. Répétez les mêmes étapes pour le deuxième nœud de 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 confirmer 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 avoir le même nom sur tous les nœuds du cluster afin de garantir le bon fonctionnement du cluster.

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

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

Configuration du chien de garde matériel

La minuterie de surveillance matérielle est activée par défaut sur les partitions logiques Power10. Pour vérifier sa disponibilité, exécutez la commande suivante.

ls /dev/watchdog*

Le résultat indique deux dispositifs : /dev/watchdog et /dev/watchdog0.

Si aucun dispositif de chien de garde 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 actuel.
• AT_PLATFORM - indique le mode de compatibilité du processeur.

Le mode de compatibilité du processeur doit être réglé sur Power10. S'il est réglé sur une version antérieure, le chien de garde de l'hyperviseur n'est pas disponible.

Arbitre

Pour un cluster à deux nœuds, il est recommandé d'utiliser un 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 pour aider à trouver le quorum de la grappe dans les scénarios de cerveau divisé. Avec un nombre pair de nœuds de cluster, les arbitres sont essentiels car ils ajoutent une instance au quorum.

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

L'arbitre est généralement mis en place après le démarrage du cluster. Utilisez l'approche crm cluster init qdevice telle que décrite dans la documentation SUSE.

Configuration de la synchronisation temporelle

Les deux nœuds du cluster ont besoin d'une synchronisation temporelle pour assurer leur bon fonctionnement. Lorsque les partitions logiques fonctionnent sur PowerVS,, la synchronisation temporelle est gérée automatiquement par l'intermédiaire de Hardware Management Console (HMC). Dans cette configuration, le démon chrony n'est pas nécessaire.

Configuration du premier nœud de cluster

Les scripts d'installation de SUSE Linux Enterprise High Availability Extension configurent automatiquement de nombreux composants clés de l'environnement de grappe.

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

Appuyez sur Entrée pour accepter les valeurs par défaut, ou entrez 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 maintenant opérationnel avec un seul nœud.

Configuration du deuxième nœud de cluster

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

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

2. Pour intégrer le nœud dans le 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 tapez y et appuyez sur Entrée à l'invite.

   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 fonctionne, exécutez la commande suivante.

   sudo crm status
   

   Si aucune erreur ne s'est produite, la section Node List de la sortie montre les deux nœuds et ils sont répertoriés comme Online.

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

   La section Ressources répertorie deux ressources qui sont dans l'état 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'ID utilisateur du 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 SMD

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 de la grappe, exécutez la commande suivante.

sbd -d $SBD_DEVICE list

La sortie répertorie les deux nœuds de cluster, chacun avec un état de clean, ce qui indique que le mécanisme SBD fonctionne correctement et qu'aucune action de clôture n'est en attente.

Configurer l'action de clôture

Par défaut, le nœud clôturé est automatiquement redémarré après un événement de clôture.

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

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

• Cela permet d'éviter les boucles de clôture inutiles, qui peuvent se produire si le problème de fond persiste.
• Il permet de s'assurer que chaque événement d'escrime est remarqué et pris en compte, ce qui améliore la stabilité et la fiabilité du groupe.

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

sudo crm configure set cib-bootstrap-options.stonith-action off

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

sudo crm configure show

Essai des opérations de clôture

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

1. Exécutez la commande suivante pour clôturer manuellement NODE2.

   crm node fence ${NODE2}
   

2. Saisissez y et appuyez sur Entrée pour continuer lorsque le message suivant s'affiche et s'arrête 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 NODE2, attendez qu'il rejoigne le cluster et testez la clôture dans la direction opposée.

   Sur NODE2, exécutez la commande suivante.

   crm status
   

4. Lorsque les deux nœuds apparaissent comme Online dans l'état de la grappe, attendez environ une minute pour garantir la stabilité. Ensuite, à partir de NODE2, lancez une action de clôture sur NODE1 en exécutant la commande suivante qui arrêtera NODE1:

   crm node fence ${NODE1}
   

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