DRBD et Pacemaker sous Rocky Linux 9 : STONITH et haute disponibilité à deux nœuds

EdwardMoon

DRBD réplique des périphériques blocs entre deux serveurs. Pacemaker et Corosync décident quel nœud porte le rôle Primary, le système de fichiers, l'IP virtuelle et le service. Promouvoir les deux nœuds en Primary ou monter XFS simultanément des deux côtés peut corrompre les données. Respectez une conception actif/passif imposant un seul écrivain.

N'appliquez pas directement l'ancien exemple CentOS 7.9 à une nouvelle production : il reposait sur un système en fin de vie, l'ancienne terminologie Master/Slave et omettait le fencing. Ce guide utilise Rocky Linux 9, DRBD 9 et le modèle actuel Promoted/Unpromoted de Pacemaker. Revérifiez les versions et combinaisons prises en charge dans la documentation de la distribution et de LINBIT.

HA DRBD/Pacemaker à deux nœuds : un Primary, réplication de blocs, témoin de quorum et fencing STONITH — Conception actif/passif avec un seul montage, et chemins distincts de réplication, quorum et STONITH pour prévenir le split-brain

Architecture et domaines de panne

Couche	Rôle	Protection en cas de panne
DRBD 9	Réplication synchrone de blocs	Protocole C, un Primary et contrôle de la réplication
Corosync	Appartenance au cluster, messages et quorum	Réseau dédié ou redondant ; envisager un qdevice
Pacemaker	Placement, ordre et récupération des ressources	Rôles Promoted et contraintes d'ordre/colocation
STONITH	Coupe l'alimentation ou l'accès d'un nœud impossible à isoler autrement	Réseau d'administration indépendant et tests réels de fencing
Filesystem	XFS à écrivain unique sur DRBD	Montage uniquement sur le nœud Promoted
VIP et service	Point d'accès client et application	Démarrer après Filesystem ; arrêter dans l'ordre inverse
Backup	Récupération après suppression, corruption ou rançongiciel	Sauvegardes versionnées et tests de restauration indépendants de DRBD

Désactiver STONITH dans un cluster Pacemaker en production est dangereux. Sans preuve qu'un nœud déconnecté est arrêté, les deux nœuds peuvent revendiquer les mêmes données. Configurez et testez le fencing avant de démarrer les ressources de données.

Prérequis

Fixer des versions compatibles du système, du module noyau et des outils DRBD, de Pacemaker, Corosync, pcs et des agents sur les deux nœuds.
Vérifier la résolution directe et inverse des noms et la synchronisation NTP.
Séparer autant que possible les domaines de panne de la réplication, de Corosync, du trafic de service et de l'administration BMC/fencing.
Vérifier les tailles et secteurs des périphériques sous-jacents et l'absence de signatures de systèmes de fichiers ou LVM sur les partitions.
Préparer un agent de fencing adapté, les identifiants BMC et un qdevice ou autre troisième point d'arbitrage.
Documenter RPO/RTO et les récupérations manuelles après corruption, split-brain ou panne de site.

Vérifications préalables des nœuds et du stockage

hostnamectl --static
timedatectl status
chronyc tracking
getent hosts ha1.example.com ha2.example.com

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
sudo blkid /dev/vdb1
sudo wipefs --no-act /dev/vdb1

L'exemple utilise /dev/vdb1 ; identifiez les véritables couches WWID, multipath et LVM. Confirmez que l'identité du périphérique reste stable après redémarrage et interrompez la procédure si des signatures existent. wipefs --no-act ne fait que les examiner ; ce guide n'automatise pas leur suppression.

Vérifier les paquets et agents de ressources

sudo dnf repolist
sudo dnf --showduplicates list   drbd-utils kmod-drbd pacemaker corosync pcs resource-agents fence-agents-all

rpm -q drbd-utils pacemaker corosync pcs resource-agents
modinfo drbd | head
drbdadm --version
pcs --version

pcs resource standards
pcs resource providers ocf
pcs resource agents ocf:linbit

Les noms des paquets DRBD et la fourniture des kmod dépendent du dépôt. Vérifiez la compatibilité RHEL, les signatures Secure Boot, la politique de mise à jour du noyau et le support, puis utilisez uniquement des dépôts validés. Ne créez pas de ressources avant l'installation effective de ocf:linbit:drbd.

Configurer la ressource de réplication DRBD

Le protocole C confirme l'opération après acquittement de l'écriture par le disque distant, ce qui convient à la réplication synchrone. Il ne garantit pas automatiquement le comportement fsync de l'application ou la politique des caches de stockage. Testez séparément les chemins de données des deux nœuds et la persistance après coupure électrique.

Générer un secret partagé DRBD

umask 077
openssl rand -base64 32

# Conserver la sortie dans un gestionnaire de secrets approuvé
# et déployer le même secret dans la configuration DRBD des deux nœuds.

Exemple /etc/drbd.d/r0.res

resource r0 {
  protocol C;
  device /dev/drbd0;
  disk /dev/vdb1;
  meta-disk internal;

  net {
    cram-hmac-alg sha256;
    shared-secret "REPLACE_WITH_GENERATED_SECRET";
  }

  on ha1.example.com {
    node-id 0;
    address ipv4 10.10.10.11:7789;
  }

  on ha2.example.com {
    node-id 1;
    address ipv4 10.10.10.12:7789;
  }
}

Limitez le fichier au mode 0600 pour que seul root puisse le lire et empêchez la gestion de configuration de journaliser le secret en clair. Remplacez REPLACE par un vrai secret avant de poursuivre. Autorisez TCP 7789 uniquement depuis le pair de réplication et conservez SELinux et firewalld.

Créer les métadonnées et activer le périphérique

sudo chown root:root /etc/drbd.d/r0.res
sudo chmod 0600 /etc/drbd.d/r0.res
sudo drbdadm dump r0
sudo drbdadm create-md r0
sudo drbdadm up r0

sudo drbdadm status r0 --verbose
sudo cat /proc/drbd

create-md écrit les métadonnées DRBD sur le périphérique sous-jacent. Vérifiez de nouveau le périphérique choisi et les sauvegardes avant de l'exécuter sur les deux nœuds. La conversion d'un volume contenant des données exige une procédure de migration distincte.

Synchronisation initiale et création du système de fichiers

# Uniquement sur des volumes neufs et vides : exécuter sur ha1 seul pendant une maintenance autorisée
sudo drbdadm primary --force r0
watch -n 2 sudo drbdadm status r0

# Créer XFS uniquement après confirmation de l'état UpToDate des deux pairs
sudo mkfs.xfs -L ha_data /dev/drbd0
sudo mkdir -p /srv/ha-data
sudo mount /dev/drbd0 /srv/ha-data
sudo touch /srv/ha-data/cluster-marker
sudo umount /srv/ha-data
sudo drbdadm secondary r0

mkfs.xfs détruit le contenu existant. Ne l'exécutez pas sur un volume réutilisé ou si l'un des côtés contient des données à conserver. Inverser la source et la cible de synchronisation initiale peut écraser des données valides par des blocs vides. Confirmez que les deux périphériques sont neufs et vides, puis attendez UpToDate/UpToDate.

Créer le cluster et configurer STONITH

Authentifier pcs et créer le cluster Corosync

# Définir interactivement le mot de passe hacluster sur les deux nœuds
sudo passwd hacluster

# Exécuter sur un nœud et saisir le mot de passe à l'invite
sudo pcs host auth ha1.example.com ha2.example.com -u hacluster
sudo pcs cluster setup ha-drbd ha1.example.com ha2.example.com --start
sudo pcs cluster enable --all

sudo pcs cluster status
sudo pcs quorum status
sudo corosync-cfgtool -s

Lors d'une rupture de communication, deux nœuds ne peuvent pas déterminer seuls si le pair est encore actif. Envisagez un qdevice Corosync comme troisième vote, sans oublier qu'il ne remplace pas STONITH. Avec le quorum interne DRBD et un arbitre sans disque, choisissez une conception cohérente prise en charge plutôt que d'empiler arbitrairement fencing Pacemaker et fencing au niveau ressource DRBD.

Trouver l'agent de fencing et le tester

sudo pcs stonith list
sudo pcs stonith describe fence_ipmilan
sudo pcs stonith config
sudo pcs property config --all

# Créer et vérifier le fencing avec l'agent et les paramètres réels du BMC, PDU ou cloud
sudo pcs stonith config --full
sudo pcs stonith status

fence_ipmilan n'est qu'un exemple. Choisissez l'agent, pcmk_host_map, l'adresse d'administration indépendante et le compte au moindre privilège adaptés au matériel ou à la plateforme. Excluez les mots de passe de l'historique et utilisez la méthode sécurisée de transmission de secrets de l'agent.

# Exécuter en maintenance après double vérification de l'impact et du nœud cible
sudo pcs stonith fence ha2.example.com

sudo pcs status --full
sudo journalctl -u pacemaker -u corosync --since '-10 min'

Pendant un test de fencing, vérifiez concrètement que la cible s'éteint ou perd son accès au stockage. Un message de réussite ne prouve pas la sécurité. Ne démarrez pas les ressources de données tant que STONITH échoue.

Utilisez le mode maintenance pour empêcher le démarrage automatique lors de la création des ressources et contraintes suivantes dans un cluster neuf et vide. Ne copiez pas cette commande de laboratoire dans une production active : elle modifie l'état de gestion de toutes les ressources.

sudo pcs property set maintenance-mode=true
sudo pcs property config

Créer la ressource DRBD promotable

Agent DRBD et rôle Promoted

sudo pcs resource create drbd_r0 ocf:linbit:drbd   drbd_resource=r0   op monitor interval=15s role=Promoted   op monitor interval=30s role=Unpromoted

sudo pcs resource promotable drbd_r0   promoted-max=1 promoted-node-max=1   clone-max=2 clone-node-max=1   notify=true

sudo pcs resource config drbd_r0
sudo pcs status --full

Pacemaker utilise désormais Promoted/Unpromoted à la place de Master/Slave. promoted-max=1 limite le cluster à un Primary à la fois. Vérifiez les noms de ressources et clones générés par votre version de pcs et utilisez-les exactement dans les contraintes suivantes.

Grouper le système de fichiers, la VIP et le service

sudo pcs resource create fs_data ocf:heartbeat:Filesystem   device=/dev/drbd0 directory=/srv/ha-data fstype=xfs   op monitor interval=20s timeout=40s

sudo pcs resource create vip_app ocf:heartbeat:IPaddr2   ip=192.0.2.50 cidr_netmask=24   op monitor interval=20s

sudo pcs resource create app_service systemd:myapp   op monitor interval=20s timeout=40s

sudo pcs resource group add app_group fs_data vip_app app_service

Adaptez l'activation systemd sur les deux nœuds pour que myapp ne démarre pas automatiquement hors cluster. Ajustez l'IP, l'interface, les options de l'agent Filesystem et les délais du service. XFS est un système de fichiers à écrivain unique, monté sur un seul nœud : ne transformez pas cet exemple en dual-primary.

Contraintes d'ordre et de colocation

# Utiliser le véritable nom du clone promotable indiqué par pcs status/config
sudo pcs constraint order   promote drbd_r0-clone then start app_group

sudo pcs constraint colocation add   app_group with promoted drbd_r0-clone INFINITY

sudo pcs constraint config --full
sudo pcs status --full

La contrainte d'ordre démarre le groupe après la promotion de DRBD ; la colocation le place sur ce même nœud Promoted. Dans le groupe, les ressources démarrent dans l'ordre Filesystem, VIP, service et s'arrêtent en sens inverse. Vérifiez les noms et la syntaxe des rôles dans l'aide pcs installée et le CIB généré.

Valider l'état du cluster et des données

Examinez toutes les ressources, contraintes d'ordre et de colocation et paramètres de fencing avant de quitter le mode maintenance du nouveau laboratoire et de confirmer le démarrage de la gestion.

sudo pcs constraint config --full
sudo pcs stonith status
sudo pcs property set maintenance-mode=false
sudo pcs status --full

Vérifier l'état nominal

sudo pcs status --full
sudo crm_mon -1Arf
sudo pcs resource config
sudo pcs constraint config --full
sudo drbdadm status r0 --verbose

findmnt /srv/ha-data
ip -brief address | grep '192.0.2.50'
curl --fail --silent --show-error http://192.0.2.50/healthz

Contrôle	État nominal	Première vérification en cas d'anomalie
DRBD role	Un nœud Promoted/Primary et un Unpromoted/Secondary	Historique des promotions manuelles, contraintes et journaux d'agent
disk state	Deux côtés UpToDate	Réseau de réplication, périphériques et progression de resynchronisation
Filesystem	Montage uniquement sur le nœud Promoted	Contraintes et montages systemd automatiques
STONITH	Chaque nœud peut réellement isoler l'autre	Alimentation BMC, droits, réseau d'administration et délais d'agent
quorum	Votes attendus et qdevice sain	Liens Corosync, wait_for_all et troisième vote
Service	La VIP et le point de contrôle de santé répondent	Système de fichiers prêt, journaux applicatifs et pare-feu

Tester la bascule

Commencez par un passage normal en standby pour valider les contraintes et l'application avant de débrancher des câbles. Suivez ensuite un plan approuvé pour tester séparément la panne du processus applicatif, l'arrêt d'un nœud, la perte du lien Corosync, celle de la réplication et la panne BMC.

sudo pcs node standby ha1.example.com
watch -n 2 sudo pcs status --full

curl --fail --silent --show-error http://192.0.2.50/healthz
ssh ha2.example.com 'findmnt /srv/ha-data; sudo drbdadm status r0'

sudo pcs node unstandby ha1.example.com
sudo pcs status --full

Dès que Pacemaker gère les ressources, ne modifiez pas leur état manuellement avec drbdadm primary, mount ou systemctl start. Cela sépare l'état réel de celui attendu par le CIB. Utilisez les procédures standby ou maintenance-mode, puis revérifiez la gestion de toutes les ressources.

Réagir à un split-brain

Arrêter le service et la récupération automatique, puis isoler physiquement les nœuds pour empêcher les écritures simultanées.
Conserver les rôles DRBD et états disques, les journaux Pacemaker/Corosync/fencing et la date de la dernière sauvegarde saine.
Identifier avec le responsable applicatif les données faisant autorité à partir de preuves transactionnelles.
Faire vérifier à deux personnes le nœud dont les données seront abandonnées avant la procédure officielle LINBIT.
Après resynchronisation, vérifier le système de fichiers, la cohérence, le service et les sauvegardes.
Corriger la cause dans la réplication, le quorum, STONITH ou les contraintes, puis répéter le même test de panne.

La commande de récupération après split-brain discard-my-data peut supprimer toutes les données d'un côté ; aucun exemple prêt à exécuter n'est donc fourni ici. Ne poursuivez pas avant d'avoir choisi la copie faisant autorité et sécurisé les sauvegardes ; suivez la documentation et la procédure d'assistance de votre version de DRBD 9.

Commandes de collecte des éléments de diagnostic

sudo drbdadm status r0 --verbose
sudo drbdsetup status --statistics
sudo pcs status --full
sudo crm_mon -1Arf
sudo corosync-cfgtool -s
sudo pcs quorum status

sudo journalctl -u drbd -u pacemaker -u corosync   --since '-30 min' --no-pager

Points à vérifier en exploitation

Remplacer l'exemple CentOS 7 par une combinaison système/DRBD/Pacemaker fixée et prise en charge.
Identifier les périphériques par numéro de série ou WWID et faire vérifier les initialisations destructrices.
Séparer les domaines de panne des réseaux de réplication, Corosync, service et BMC/fencing.
Tester STONITH concrètement et conserver stonith-enabled actif.
Définir promoted-max=1 et monter XFS uniquement sur l'unique nœud Promoted.
Valider l'ordre et la colocation du groupe Filesystem/VIP/service.
Consigner les résultats attendus et le RTO pour standby, arrêt de nœud, perte de lien et échec de fencing.
Créer des sauvegardes versionnées indépendantes de DRBD et les restaurer en environnement isolé.

Documentation officielle et articles associés

Conclusion

La HA à deux nœuds doit garantir l'isolement réel de l'ancien propriétaire avant qu'un autre nœud écrive les bonnes données, au-delà d'un redémarrage rapide. Validez ensemble le protocole C, l'unique rôle Promoted, STONITH fonctionnel, le quorum et les contraintes Filesystem/VIP/service. La réplication ne remplace pas la sauvegarde : les tests de panne et de restauration indépendante font partie de la mise en exploitation.