Accéder au contenu
documentation.suse.com / Démarrage rapide de l'installation et de la configuration
SUSE Linux Enterprise High Availability 15 SP6

Démarrage rapide de l'installation et de la configuration

Date de publication : 29 septembre 2024

Le présent document explique comment configurer une grappe très basique de deux noeuds à l'aide des scripts d'amorçage fournis par le shell crm. Ce processus inclut la configuration d'une adresse IP virtuelle en tant que ressource de grappe et l'utilisation d'un détecteur de vues de grappe divergentes (SBD pour Split Brain Detector) sur un stockage partagé en tant que mécanisme d'isolation de noeud.

Copyright © 2006–2024 SUSE LLC et contributeurs. Tous droits réservés.

Il est autorisé de copier, distribuer et/ou modifier ce document conformément aux conditions de la licence de documentation libre GNU version 1.2 ou (à votre discrétion) 1.3, avec la section permanente qu'est cette mention de copyright et la licence. Une copie de la version de licence 1.2 est incluse dans la section intitulée « Licence de documentation libre GNU ».

Pour les marques commerciales SUSE, consultez le site Web https://www.suse.com/company/legal/. Toutes les marques commerciales de fabricants tiers appartiennent à leur propriétaire respectif. Les symboles de marque (®, ™, etc.) désignent des marques commerciales de SUSE et de ses sociétés affiliées. Des astérisques (*) désignent des marques commerciales de fabricants tiers.

Toutes les informations de cet ouvrage ont été regroupées avec le plus grand soin. Cela ne garantit cependant pas sa complète exactitude. Ni SUSE LLC, ni les sociétés affiliées, ni les auteurs, ni les traducteurs ne peuvent être tenus responsables des erreurs possibles ou des conséquences qu'elles peuvent entraîner.

1 Scénario d'utilisation

Les procédures décrites dans le présent document permettent de configurer une grappe de base à deux noeuds présentant les caractéristiques suivantes :

  • Deux noeuds : alice (adresse IP : 192.168.1.1) et bob (adresse IP : 192.168.1.2), connectés entre eux via le réseau.

  • Une adresse IP virtuelle flottante (192.168.1.10), qui permet aux clients de se connecter au service quel que soit le noeud physique sur lequel il s'exécute. Cette adresse IP est utilisée pour se connecter à l'outil de gestion graphique Hawk2.

  • Un périphérique de stockage partagé, utilisé comme mécanisme d'isolation SBD. Cela évite les scénarios de grappes divergentes.

  • Un système de basculement des ressources d'un noeud vers l'autre en cas de défaillance de l'hôte actif (configuration active/passive).

La grappe à deux noeuds peut être utilisée à des fins de test ou comme une configuration de grappe minimale que vous pouvez étendre par la suite. Avant d'utiliser la grappe dans un environnement de production, consultez le Book “Administration Guide” pour la modifier celle-ci en fonction de vos besoins.

2 Configuration système requise

Cette section décrit la configuration système minimale requise pour le scénario présenté dans la Section 1. Pour que la grappe puisse être utilisée dans un environnement de production, reportez-vous à la liste complète dans le Book “Administration Guide”, Chapter 2 “System requirements and recommendations”.

2.1 Configuration matérielle requise

Serveurs

Deux serveurs exécutant les logiciels spécifiés à la Section 2.2, « Configuration logicielle requise ».

Ces serveurs peuvent être des machines virtuelles ou sans système d'exploitation. Ils ne nécessitent pas une configuration matérielle identique (mémoire, espace disque, etc.), mais doivent avoir la même architecture. Les grappes multi plate-forme ne sont pas prises en charge.

Canaux de communication

Au moins deux médias de communication TCP/IP par noeud de grappe. L'équipement réseau doit prendre en charge le moyen de communication que vous souhaitez utiliser pour les communications au sein de la grappe, à savoir la multidiffusion ou la monodiffusion. Les médias de communication doivent prendre en charge un débit de données de 100 Mbit/s ou plus. La prise en charge d'une grappe requiert au moins deux chemins de communication redondants. Cette configuration peut être obtenue via :

  • une liaison de périphérique réseau (de préférence) ;

  • un deuxième canal de communication dans Corosync.

Isolation de noeud/STONITH

Périphérique d'isolation de noeuds (STONITH) pour éviter les scénarios de grappes divergentes. Il peut s'agir d'un périphérique physique (un bouton marche/arrêt) ou d'un mécanisme de type SBD associé à un système de surveillance (watchdog). Le mécanisme SBD peut être utilisé avec un stockage partagé ou en mode sans disque. Ce document décrit l'utilisation de SBD avec un stockage partagé. Les conditions suivantes doivent être remplies :

  • Un périphérique de stockage partagé. Pour plus d'informations sur la configuration du stockage partagé, reportez-vous au document Storage Administration Guide for SUSE Linux Enterprise Server. Si vous avez uniquement besoin d'un stockage partagé de base à des fins de test, reportez-vous à l'Annexe A, Stockage iSCSI de base pour SBD.

  • Le chemin d'accès au périphérique de stockage partagé doit être persistant et cohérent sur tous les noeuds de la grappe. Utilisez des noms de périphériques stables, tels que /dev/disk/by-id/dm-uuid-part1-mpath-abcedf12345.

  • Le périphérique SBD ne doit pas utiliser de RAID, LVM ou DRBD* basé sur l'hôte.

Pour plus d'informations sur STONITH, reportez-vous au Book “Administration Guide”, Chapter 12 “Fencing and STONITH”. Pour plus d'informations sur SBD, reportez-vous au Book “Administration Guide”, Chapter 13 “Storage protection and SBD”.

2.2 Configuration logicielle requise

Tous les noeuds nécessitent au moins les modules et extensions suivants :

  • Basesystem Module 15 SP6

  • Server Applications Module 15 SP6

  • SUSE Linux Enterprise High Availability 15 SP6

2.3 Autres conditions requises et recommandations

Synchronisation horaire

Les noeuds de la grappe doivent se synchroniser avec un serveur NTP situé en dehors de la grappe. Depuis SUSE Linux Enterprise High Availability 15, chrony est l'implémentation par défaut du protocole NTP. Pour plus d'informations, reportez-vous au manuel Administration Guide for SUSE Linux Enterprise Server 15 SP6.

La grappe peut ne pas fonctionner correctement si les noeuds ne sont pas synchronisés, ou même s'ils sont synchronisés mais présentent des fuseaux horaires différents. En outre, les fichiers journaux et les rapports de grappe sont très difficiles à analyser en l'absence de synchronisation. Si vous utilisez les scripts d'amorçage, le système vous avertira si un service NTP n'est pas encore configuré.

Nom d'hôte et adresse IP
  • Utilisez des adresses IP statiques.

  • Seule l'adresse IP principale est prise en charge.

  • Répertoriez tous les noeuds de la grappe, avec leur nom d'hôte complet et leur nom d'hôte abrégé, dans le fichier /etc/hosts. Il est essentiel que les membres de la grappe puissent se trouver sur la base de leurs noms. Si les noms ne sont pas disponibles, la communication interne au sein de la grappe ne fonctionnera pas.

SSH

Tous les noeuds de la grappe doivent pouvoir accéder les uns aux autres via le protocole SSH. Des outils tels que crm report (pour le dépannage) et l'explorateur d'historique de Hawk2 requièrent un accès SSH sans mot de passe entre les noeuds, faute de quoi ils peuvent uniquement collecter des données du noeud actif.

Si vous utilisez les scripts d'amorçage pour configurer la grappe, les clés SSH sont automatiquement créées et copiées.

3 Présentation des scripts d'amorçage

Les commandes suivantes exécutent des scripts d'amorçage qui ne nécessitent qu'un minimum de temps et d'effort manuel.

  • Le script crm cluster init permet de définir les paramètres de base nécessaires pour la communication au sein de la grappe. À ce moment-là, vous disposez d'une grappe opérationnelle comportant un seul noeud.

  • Le script crm cluster join vous permet d'ajouter des noeuds à votre grappe.

  • Le script crm cluster remove vous permet de supprimer des noeuds de votre grappe.

Les options définies par les scripts d'amorçage peuvent ne pas être les mêmes que les paramètres par défaut de Pacemaker. Vous pouvez vérifier les paramètres modifiés par les scripts d'amorçage dans /var/log/crmsh/crmsh.log. Toutes les options définies au cours du processus d'amorçage peuvent être modifiées ultérieurement à l'aide du module de cluster YaST. Pour plus de détails, reportez-vous au Book “Administration Guide”, Chapter 4 “Using the YaST cluster module”.

Le script d'amorçage crm cluster init vérifie et configure les composants suivants :

NTP

Vérifie si NTP est configuré pour se lancer au moment du démarrage. Si ce n'est pas le cas, un message apparaît.

SSH

Crée les clés SSH nécessaires pour que les noeuds de la grappe puissent accéder les uns aux autres sans mot de passe.

Csync2

Configure Csync2 de manière à répliquer les fichiers de configuration sur tous les noeuds d'une grappe.

Corosync

Configure le système de communication de la grappe.

SBD/surveillance

Vérifie si un système de surveillance existe et vous demande si vous souhaitez configurer SBD comme mécanisme d'isolation de noeud.

Adresse IP virtuelle flottante

Vous demande si vous souhaitez configurer une adresse IP virtuelle pour l'administration de la grappe à l'aide de Hawk2.

Pare-feu

Ouvre les ports du pare-feu qui sont nécessaires pour les communications de grappe.

Nom de la grappe

Définit un nom pour la grappe. Par défaut, il s'agit de hacluster. Ce nom est facultatif et principalement utile pour les grappes géographiques. En règle générale, le nom de la grappe reflète l'emplacement géographique et facilite la distinction d'un site à l'intérieur d'une grappe Geo.

QDevice/QNetd

Vous demande si vous souhaitez configurer QDevice/QNetd pour participer aux décisions de quorum. Nous vous recommandons d'utiliser QDevice et QNetd pour les grappes avec un nombre pair de noeuds, et en particulier pour les grappes à deux noeuds.

Cette configuration n'est pas abordée ici, mais vous pouvez la définir ultérieurement comme décrit dans le Book “Administration Guide”, Chapter 14 “QDevice and QNetd”.

Note
Note : configuration de grappe pour différentes plates-formes

Le script crm cluster init détecte l'environnement système (par exemple, Microsoft Azure) et ajuste certains paramètres de grappe en fonction du profil de cet environnement. Pour plus d'informations, reportez-vous au fichier /etc/crm/profiles.yml.

4 Installation des paquets Haute disponibilité

Les paquet de configuration et de gestion d'une grappe sont inclus dans le modèle d'installation High Availability. Ce modèle n'est disponible qu'après l'installation de SUSE Linux Enterprise High Availability.

Vous pouvez vous enregistrer auprès du SUSE Customer Center et installer SUSE Linux Enterprise High Availability lors de l'installation de SUSE Linux Enterprise Server ou après l'installation. Pour plus d'informations, reportez-vous au manuel Deployment Guide pour SUSE Linux Enterprise Server.

Procédure 1 : Installation du modèle Haute disponibilité
  1. Installez le modèle Haute disponibilité à partir de la ligne de commandes :

    # zypper install -t pattern ha_sles
  2. Installez le modèle Haute disponibilité sur toutes les machines qui feront partie de votre grappe.

    Note
    Note : installation des paquets logiciels sur tous les noeuds

    Pour procéder à une installation automatisée de SUSE Linux Enterprise Server 15 SP6 et de SUSE Linux Enterprise High Availability 15 SP6, utilisez AutoYaST pour cloner des noeuds existants. Pour plus d'informations, reportez-vous au Book “Administration Guide”, Chapter 3 “Installing SUSE Linux Enterprise High Availability”, Section 3.2 “Mass installation and deployment with AutoYaST”.

5 Utilisation de SBD pour l'isolation des noeuds

Avant de pouvoir configurer SBD avec le script d'amorçage, vous devez activer une surveillance (watchdog) sur chaque noeud. SUSE Linux Enterprise Server est livré avec plusieurs modules de noyau qui fournissent des pilotes de surveillance spécifiques au matériel. SUSE Linux Enterprise High Availability utilise le daemon SBD comme composant logiciel pour « alimenter » le système de surveillance.

La procédure suivante utilise la surveillance softdog.

Important
Important : limites de la surveillance softdog

Le pilote softdog part du principe qu'au moins un processeur est toujours en cours d'exécution. Si tous les processeurs sont bloqués, le code dans le pilote softdog qui devrait redémarrer le système ne sera jamais exécuté. En revanche, les systèmes de surveillance matérielle continuent à travailler même si tous les processeurs sont bloqués.

Avant d'utiliser la grappe dans un environnement de production, il est vivement recommandé de remplacer le module softdog par le module matériel qui correspond le mieux à votre matériel.

Toutefois, si aucun système de surveillance ne correspond à votre matériel, softdog peut être utilisé en tant que module de surveillance de noyau.

Procédure 2 : Activation de la surveillance softdog pour SBD
  1. Sur chaque noeud, activez la surveillance logicielle (softdog) :

    # echo softdog > /etc/modules-load.d/watchdog.conf
    # systemctl restart systemd-modules-load
  2. Vérifiez si le module de surveillance logicielle est chargé correctement :

    # lsmod | grep dog
    softdog           16384  1

6 Configuration du premier noeud

Configurez le premier noeud à l'aide du script crm cluster init. Cette opération ne nécessite qu'un minimum de temps et d'effort manuel.

Procédure 3 : Configuration du premier noeud (alice) à l'aide du script crm cluster init
  1. Connectez-vous au premier noeud de la grappe en tant qu'utilisateur root ou en tant qu'utilisateur disposant de privilèges sudo.

    Important
    Important : accès à la clé SSH

    La grappe utilise un accès SSH sans mot de passe pour la communication entre les noeuds. Le script crm cluster init vérifie les clés SSH et les génère si elles n'existent pas déjà.

    Dans la plupart des cas, les clés SSH de l'utilisateur root ou sudo doivent exister (ou être générées) sur le noeud.

    Les clés SSH d'un utilisateur sudo peuvent également exister sur une machine locale et être transmises au noeud via le réacheminement de l'agent SSH. Cela nécessite une configuration supplémentaire qui n'est pas décrite pour cette configuration minimale. Pour plus d'informations, reportez-vous au Book “Administration Guide”, Chapter 5 “Configuration and administration basics”, Section 5.5.1 “Logging in”.

  2. Lancez le script d'amorçage :

    # crm cluster init --name CLUSTERNAME

    Remplacez la marque de réservation CLUSTERNAME par un nom pertinent, comme l'emplacement géographique de votre grappe (par exemple, amsterdam). Cela est particulièrement utile pour créer un Geo Cluster ultérieurement, car cela simplifie l'identification d'un site.

    Si vous avez besoin de la multidiffusion plutôt que la monodiffusion (par défaut) pour la communication de votre grappe, utilisez l'option --multicast (ou -U).

    Le script vérifie la configuration NTP et la présence d'un service de surveillance matérielle. Le cas échéant, il génère les clés SSH publiques et privées utilisées pour l'accès SSH et la synchronisation Csync2, et démarre les services respectifs.

  3. Configurez la couche de communication de grappe (Corosync) :

    1. Spécifiez une adresse réseau pour la liaison. Par défaut, le script propose l'adresse réseau de eth0. Vous pouvez également spécifier une autre adresse réseau, par exemple bond0.

    2. Acceptez le port proposé (5405) ou entrez-en un autre.

  4. Configurez SBD comme mécanisme d'isolation de noeud :

    1. Spécifiez y pour confirmer que vous souhaitez utiliser le SBD.

    2. Entrez un chemin d'accès persistant à la partition du périphérique de blocs pour lequel vous souhaitez utiliser SBD. Le chemin doit être cohérent sur tous les noeuds de la grappe.

      Le script crée une petite partition sur le périphérique à utiliser pour SBD.

  5. Configurez une adresse IP virtuelle pour l'administration de la grappe avec Hawk2 :

    1. Spécifiez y pour confirmer que vous souhaitez configurer une adresse IP virtuelle.

    2. Spécifiez une adresse IP inutilisée que vous souhaitez employer comme adresse IP d'administration pour Hawk2 : 192.168.1.10.

      Au lieu de vous connecter à un noeud de grappe individuel avec Hawk2, vous pouvez vous connecter à l'adresse IP virtuelle.

  6. Choisissez de configurer QDevice et QNetd. Pour la configuration minimale décrite dans ce document, refusez pour le moment avec l'option n. Vous pouvez configurer QDevice et QNetd ultérieurement, comme décrit dans le Book “Administration Guide”, Chapter 14 “QDevice and QNetd”.

Enfin, le script démarre les services de grappe pour mettre en ligne la grappe et activer Hawk2. L'URL à utiliser pour Hawk2 apparaît à l'écran.

Vous disposez maintenant d'une grappe opérationnelle comportant un seul noeud. Pour visualiser son état, procédez comme suit :

Procédure 4 : Connexion à l'interface Web de Hawk2
  1. Sur une machine, démarrez un navigateur Web et assurez-vous que JavaScript et les cookies sont activés.

  2. En tant qu'URL, entrez l'adresse IP virtuelle que vous avez configurée avec le script d'amorçage :

    https://192.168.1.10:7630/
    Note
    Note : avertissement de certificat

    Si un avertissement de certificat s'affiche la première fois que vous tentez d'accéder à l'URL, un certificat auto-signé est utilisé. Par défaut, les certificats auto-signés ne sont pas considérés comme fiables.

    Demandez à votre opérateur de grappe de vous fournir les informations relatives au certificat afin de vérifier ce dernier.

    Pour continuer, vous pouvez ajouter une exception dans le navigateur afin d'ignorer l'avertissement.

  3. Dans l'écran de connexion de Hawk2, spécifiez le Nom d'utilisateur et le Mot de passe de l'utilisateur qui a été créé par le script d'amorçage (utilisateur hacluster, mot de passe linux).

    Important
    Important : mot de passe sécurisé

    Remplacez dès que possible le mot de passe par défaut par un mot de passe sécurisé :

    # passwd hacluster
  4. Cliquez sur Se connecter. L'interface Web Hawk2 affiche l'écran État par défaut :

    état de la grappe à un noeud dans Hawk2
    Figure 1 : état de la grappe à un noeud dans Hawk2

7 Ajout du deuxième noeud

Ajoutez un deuxième noeud à la grappe avec le script d'amorçage crm cluster join. Le script nécessite uniquement un accès à un noeud de grappe existant et procède automatiquement à la configuration de base sur la machine actuelle.

Pour plus d'informations, reportez-vous à la commande crm cluster join --help.

Procédure 5 : ajout du deuxième noeud (bob) à l'aide du script crm cluster join
  1. Connectez-vous au second noeud en tant qu'utilisateur root ou en tant qu'utilisateur disposant de privilèges sudo.

  2. Lancez le script d'amorçage :

    Si vous configurez le premier noeud en tant qu'utilisateur root, vous pouvez exécuter cette commande sans paramètres supplémentaires :

    # crm cluster join

    Si vous configurez le premier noeud en tant qu'utilisateur sudo, vous devez spécifier cet utilisateur avec l'option -c :

    > sudo crm cluster join -c USER@alice

    Si NTP n'est pas configuré pour se lancer au moment du démarrage, un message s'affiche. Le script recherche également un périphérique de surveillance matériel. Vous êtes averti si aucun n'est présent.

  3. Si vous n'avez pas encore spécifié alice avec -c, vous êtes invité à saisir l'adresse IP du premier noeud.

  4. Si vous n'aviez pas encore configuré d'accès SSH sans mot de passe entre les deux machines, le système vous invite à spécifier le mot de passe du premier noeud.

    Une fois connecté au noeud spécifié, le script copie la configuration Corosync, configure SSH et Csync2, met la machine actuelle en ligne en tant que nouveau noeud de grappe et démarre le service requis pour Hawk2.

Vérifiez l'état de la grappe dans Hawk2. Dans État › Noeuds, vous devriez voir deux noeuds présentant un état vert :

état de la grappe à deux noeuds
Figure 2 : état de la grappe à deux noeuds

8 Test de la grappe

Les tests suivants peuvent vous aider à identifier les problèmes liés à la configuration de la grappe. Cependant, un test réaliste implique des cas d'utilisation et des scénarios spécifiques. Avant d'utiliser la grappe dans un environnement de production, testez-la scrupuleusement en fonction de l'utilisation que vous comptez en faire.

8.1 Test du basculement des ressources

La procédure ci-après permet d'effectuer un test rapide du basculement des ressources :

Procédure 6 : test du basculement des ressources
  1. Ouvrez un terminal et exécutez une commande ping sur l'adresse 192.168.1.10, autrement dit votre adresse IP virtuelle :

    # ping 192.168.1.10
  2. Connectez-vous à Hawk2.

  3. Dans État › Ressources, vérifiez sur quel noeud s'exécute l'adresse IP virtuelle (ressource admin_addr). Cette procédure suppose que la ressource s'exécute sur alice.

  4. Mettez alice en mode Veille :

    noeud alice en mode veille
    Figure 3 : noeud alice en mode veille
  5. Cliquez sur État › Ressources. La ressource admin_addr a été migrée vers bob.

Pendant la migration, vous devriez normalement voir un flux continu de requêtes ping envoyées à l'adresse IP virtuelle. Cela montre que la configuration de grappe et l'adresse IP flottante fonctionnent correctement. Annulez la commande ping en appuyant sur Ctrl C.

8.2 Test à l'aide de la commande crm cluster crash_test

La commande crm cluster crash_test déclenche les dysfonctionnements de grappe afin de repérer les problèmes. Avant d'utiliser la grappe en production, il est recommandé d'appliquer cette commande pour vous assurer que tout fonctionne comme prévu.

La commande prend en charge les contrôles suivants :

--split-brain-iptables

Ce test simule un scénario de grappes divergentes en bloquant le port Corosync. Il vérifie si un noeud peut être délimité comme prévu.

--kill-sbd/--kill-corosync/ --kill-pacemakerd

Supprime les daemons pour SBD, Corosync et Pacemaker. Après avoir exécuté l'un de ces tests, vous pouvez trouver un rapport dans le répertoire /var/lib/crmsh/crash_test/. Le rapport comprend une description de cas de test, une consignation des opérations et une explication des résultats possibles.

--fence-node NODE

Ce test isole le noeud spécifique transmis par la ligne de commandes.

Pour plus d'informations, reportez-vous à la commande crm cluster crash_test --help.

Exemple 1 : Test de la grappe : isolation des noeuds
# crm_mon -1
Stack: corosync
Current DC: alice (version ...) - partition with quorum
Last updated: Fri Mar 03 14:40:21 2020
Last change: Fri Mar 03 14:35:07 2020 by root via cibadmin on alice

2 nodes configured
1 resource configured

Online: [ alice bob ]
Active resources:

 stonith-sbd    (stonith:external/sbd): Started alice

# crm cluster crash_test --fence-node bob

==============================================
Testcase:          Fence node bob
Fence action:      reboot
Fence timeout:     60

!!! WARNING WARNING WARNING !!!
THIS CASE MAY LEAD TO NODE BE FENCED.
TYPE Yes TO CONTINUE, OTHER INPUTS WILL CANCEL THIS CASE [Yes/No](No): Yes
INFO: Trying to fence node "bob"
INFO: Waiting 60s for node "bob" reboot...
INFO: Node "bob" will be fenced by "alice"!
INFO: Node "bob" was successfully fenced by "alice"

Pour surveiller le changement d'état de bob au cours du test, connectez-vous à Hawk2 et accédez à État › Noeuds.

9 Étapes suivantes

Les scripts d'amorçage constituent un moyen rapide pour configurer une grappe Haute disponibilité de base qui peut être utilisée à des fins de test. Toutefois, pour la développer en grappe Haute disponibilité fonctionnelle utilisable dans des environnements de production, d'autres étapes sont recommandées.

Étapes recommandées pour réaliser la configuration de la grappe Haute disponibilité
Ajout de noeuds supplémentaires

Ajoutez d'autres noeuds à la grappe à l'aide de l'une des méthodes suivantes :

  • Pour les noeuds individuels, utilisez le script crm cluster join comme décrit à la Section 7, « Ajout du deuxième noeud ».

  • Pour l'installation en masse de plusieurs noeuds, utilisez AutoYaST comme décrit dans le Book “Administration Guide”, Chapter 3 “Installing SUSE Linux Enterprise High Availability”, Section 3.2 “Mass installation and deployment with AutoYaST”.

Une grappe normale peut contenir jusqu'à 32 noeuds. Avec le service pacemaker_remote, il est possible d'étendre les grappes Haute disponibilité pour inclure des noeuds supplémentaires au-delà de cette limite. Reportez-vous à l'Article “Pacemaker Remote Quick Start” pour plus de détails.

Configuration de QDevice

Si la grappe comporte un nombre pair de noeuds, configurez QDevice et QNetd pour participer aux décisions de quorum. QDevice fournit un nombre configurable de votes, ce qui permet à une grappe de supporter plus de défaillances de noeuds que ne le permettent les règles de quorum standard. Pour plus de détails, reportez-vous au Book “Administration Guide”, Chapter 14 “QDevice and QNetd”.

Activation d'une surveillance (watchdog) matérielle

Avant d'utiliser la grappe dans un environnement de production, remplacez le module softdog par le module matériel qui correspond le mieux à votre matériel. Pour plus de détails, reportez-vous au Book “Administration Guide”, Chapter 13 “Storage protection and SBD”, Section 13.6 “Setting up the watchdog”.

10 Pour plus d'informations

Pour plus de documentation sur ce produit, rendez-vous à l'adresse https://documentation.suse.com/sle-ha/. Pour des informations concernant d'autres tâches de configuration et d'administration, reportez-vous au manuel Administration Guide.

A Stockage iSCSI de base pour SBD

Utilisez les procédures suivantes pour configurer le stockage iSCSI de base à employer avec SBD. Ces procédures ne sont recommandées qu'à des fins de test. Avant d'utiliser iSCSI dans un environnement de production, reportez-vous au document Storage Administration Guide for SUSE Linux Enterprise Server.

Configuration requise
  • Une machine virtuelle SUSE Linux Enterprise Server faisant office de cible iSCSI. Cette machine virtuelle ne fait pas partie de la grappe.

  • Deux périphériques de stockage virtuels sur la machine virtuelle : un périphérique de 20 Go pour le système et un périphérique de 1 Go pour SBD.

  • Deux noeuds SUSE Linux Enterprise Server qui n'ont pas encore été ajoutés à une grappe Haute disponibilité.

Commencez par configurer une cible iSCSI sur la machine virtuelle :

Procédure A..1 : Configuration d'une cible iSCSI
  1. Installez le paquet yast2-iscsi-lio-server :

    # zypper install yast2-iscsi-lio-server
  2. Démarrez le module iscsi-lio-server dans YaST :

    # yast2 iscsi-lio-server
  3. Dans l'onglet Service, sous Après redémarrage, sélectionnez Démarrer au démarrage du système.

  4. Activez l'option Ouvrir le port dans le pare-feu.

  5. Dans l'onglet Découverte, activez l'option Authentification de la découverte.

  6. Sous Authentification par les cibles, entrez un Nom d'utilisateur et un Mot de passe.

  7. Sous Authentification par les initiateurs, entrez un Nom d'utilisateur commun et un Mot de passe commun. Ce mot de passe doit être différent du mot de passe Authentification par cibles.

  8. Dans l'onglet Cible, sélectionnez Ajouter.

  9. Modifiez le nom de la Cible en remplaçant .com.example.

  10. Ajoutez l'Adresse IP du serveur.

  11. Sélectionnez Ajouter.

  12. Dans la fenêtre Détails de LUN, entrez le Chemin de LUN vers le périphérique de stockage de 1 Go (par exemple, /dev/vbd).

  13. Sélectionnez OK.

  14. Cliquez sur Suivant.

  15. Sélectionnez Terminer pour fermer YaST.

  16. Pour vérifier la configuration cible, basculez vers la CLI cible :

    # targetcli

    Affichez la configuration :

    /> ls

Ensuite, configurez les initiateurs iSCSI sur les noeuds. Répétez cette procédure sur les deux noeuds :

Procédure A..2 : configuration d'un initiateur iSCSI
  1. Installez le paquet yast2-iscsi-client :

    # zypper install yast2-iscsi-client
  2. Démarrez le service iscsid :

    # systemctl start iscsid
  3. Ouvrez le module iscsi-client dans YaST :

    # yast2 iscsi-client
  4. Dans l'onglet Cibles découvertes, sélectionnez Découverte.

  5. Entrez l'adresse IP de la cible iSCSI.

  6. Désélectionnez l'option Pas d'authentification de la découverte.

  7. Sous Authentification par l'initiateur, entrez le Nom d'utilisateur et le Mot de passe de l'initiateur.

  8. Sous Authentification par les cibles, entrez le Nom d'utilisateur et le Mot de passe de la cible.

  9. Cliquez sur Suivant.

  10. Une fois que YaST a découvert la cible iSCSI, sélectionnez Connecter.

  11. Sous Démarrage, sélectionnez au démarrage.

  12. Cliquez sur Suivant.

  13. Sélectionnez OK pour fermer YaST.

  14. Vérifiez l'initiateur iSCSI :

    # lsscsi
    [0:0:1:0] cd/dvd QEMU QEMU DVD-ROM 2.5+ /dev/sr0
    [2:0:0:0] disk LIO-ORG IBLOCK 4.0 /dev/sda

    Recherchez une ligne contenant IBLOCK. Dans cet exemple, le périphérique iSCSI est /dev/sda.

  15. Vérifiez l'état du service iscsid :

    # systemctl status iscsid

Vous pouvez trouver le nom du périphérique stable dans /dev/disk/by-id/. Généralement, un périphérique iSCSI commence par scsi-SLIO-ORG_IBLOCK.

Si vous avez plusieurs disques, vous pouvez exécuter la commande lsblk -o name,serial pour vérifier quel nom de périphérique stable correspond à quel nom abrégé (par exemple, /dev/sda).

Lorsque vous configurez la grappe, spécifiez le nom du périphérique stable à l'aide de l'une des méthodes suivantes :

  • Lorsque vous exécutez crm cluster init, entrez le nom du périphérique stable quand vous y êtes invité.

  • Avant d'exécuter crm cluster init, ajoutez le nom du périphérique stable à /etc/sysconfig/sbd :

    SBD_DEVICE=/dev/disk/by-id/scsi-SLIO-ORG_IBLOCK_DEVICE_ID_STRING

    Lorsque vous exécutez crm cluster init, répondez n à cette question :

    SBD is already configured to use /dev/disk/by-id/scsi-SLIO-ORG_IBLOCK_... - overwrite (y/n)?