Attention

Il s'agit d'C'est un sujet avancé. Utilisez-le à vos propres risques et périls et TOUJOURS sauvegarder sauvegardez vos données avant.

Commandes utiles

Voir le statut de DRBD - DRBD 7

cat /proc/drbd

Voir le statut de DRBD - DRBD 9

statut drbdadm

Recharger tous les paramètres

drbdadm adjust jtelshared

Déconnecter l'action (utile pour la maintenance planifiée)

drbdadm disconnect jtelshared

Réduction de l'action (utile pour la maintenance planifiée)

drbdadm down jtelshared

Augmenter la part

drbdadm up jtelshared

Régler le nœud sur le primaire

drbdadm primary jtelshared

Connectez le partage

drbdadm connect jtelshared

Commandes des clusters PCS (CentOS 8)

pcs cluster stop acd-store2 pcs cluster start acd-store2 pcs node standby acd-store2 pcs node unstandby acd-store2

Cerveau fendu

Contexte

Voir ici:

https://docs.linbit.com/doc/users-guide-84/s-resolve-split-brain/

Symptômes - CentOS 7 et antérieurs

cat /proc/drbd --> GIT-hash: a4d5de01fffd7e4cde48a080e2c686f9e8cebf4c build by mockbuild@, 2017-09-15 14:23:22 1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown r----- ns:0 nr:119823323 dw:119823323 dr:2128 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

cs:StandAlone signifie que le nœud n'est pas connecté. 

Cela devrait être visible des deux côtés.

Symptômes - CentOS 8 et antérieurs

drbdadm status --> jtelshared role:Primary disk:UpToDate tdm-jtel-lb-2-pn-1 connection:Connecting drbdadm status --> # No currently configured DRBD found.

La première commande montre que la DRBD est active sur le premier nœud, mais pas sur le second.

Remarque : cela peut être dû au fait que le deuxième nœud est arrêté ou en attente.

Découvrez quel nœud est actif dans le cluster PCS - CentOS 7

pcs status --> Cluster name: portal Stack: corosync Current DC: acd-store1 (version 1.1.16-12.el7_4.7-94ff4df) - partition with quorum Last updated: Dim 18 Mar 18:05:32 2018 Dernier changement: Ven 16 Feb 00:07:51 2018 par root via cibadmin sur acd-store2 2 nœuds configurés 3 ressources configurées Nœud acd-store1: standby En ligne: [acd-store2] Liste complète des ressources: Groupe de ressources: haproxy_group ClusterDataJTELSharedMount (ocf::heartbeat:Filesystem): Started acd-store2 ClusterIP (ocf::heartbeat:IPaddr2): Started acd-store2 samba (systemd:smb): Started acd-store2 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled

Dans l'exemple ci-dessus, le premier nœud est en attenteveille. La chose la plus importante à vérifier , c' est de savoir sur quel serveur les ressources sont démarréeslancées. 

Dans ce cas, les ressources sont mises en place sur acd-store2.

Il sera donc défini comme le nœud NON brisé .

Découvrez quel nœud est actif dans le cluster PCS - CentOS 8

pcs status --> Cluster name: jtel_cluster Cluster Summary: * Stack: corosync * Current DC: acd-lb1 (version 2.0.3-5.el8_2.1-4b1f869f0f) - partition with quorum * Last updated: Sam 3 Oct 12:39:22 2020 * Dernier changement: Sam 3 Oct 12:31:22 2020 par root via cibadmin sur acd-lb2 * 2 nœuds configurés * 5 instances de ressources configurées Liste des nœuds: * En ligne: [acd-lb1 acd-lb2] Liste complète des ressources: * Ensemble de clones: DRBDClusterMount-clone [DRBDClusterMount] (promotable): * Masters: [ acd-lb1 ] * Stopped: [ acd-lb2 ] * DRBDClusterFilesystem (ocf::heartbeat:Filesystem): Started acd-lb1 * Samba (systemd:smb): Started acd-lb1 * ClusterIP (ocf::heartbeat:IPaddr2): Started acd-lb1 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled

Dans l'exemple ci-dessus, le deuxième nœud est hors ligne. La chose la plus importante à vérifier , c' est de savoir sur quel serveur les ressources sont démarréeslancées. 

Dans ce cas, les ressources sont démarrées sur acd-lb1.

Il sera donc défini comme le nœud NON brisé .

Mettez en veille le nœud rompu dans le cluster PCS (si nécessaire)

Cette commande peut être exécutée sur n'importe quelle machine.

CentOS 7

pcs cluster standby acd-lb-broken   --> Vérifiez cela avec pcs status

CentOS 8

pcs node standby acd-lb-broken   --> Vérifiez cela avec  pcs status

Sur un nœud brisé

Note : la première commande lancera probablement une erreur. De plus, il se peut que l'action ne soit pas montée. Cela ne pose pas de problème.

umount /srv/jtel/shared drbdadm disconnect jtelshared drbdadm secondary jtelshared drbdadm connect --discard-my-data jtelshared

Sur le nœud sain

drbdadm primary jtelshared drbdadm connect jtelshared

Vérifier l'activité de re-sync

La re-synchronisation pourrait prendre beaucoup de temps. 

Surveillez l'état de cette utilisation :

cat /proc/drbd

Exemple de sortie :

[root@storage01 ~]# cat /proc/drbd version: 8.4.10-1 (api:1/proto:86-101) GIT-hash: a4d5de01fffd7e4cde48a080e2c686f9e8cebf4c build by mockbuild@, 2017-09-15 14:23:22 1: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r----- ns:0 nr:1411538 dw:121234862 dr:2128 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:184698664 [>....................] sync'ed: 0.8% (180368/181744)M finish: 26:12:15 speed: 1,940 (2,760) want: 2,120 K/sec

Régler le transfert (deuxième nœud) - uniquement CentOS 7.x

Actuellement, il n'existe pas de procédure pour régler le transfert sur CentOS 8.x

Si le transfert doit prendre du temps, il faut alors le régler sur le nœud rompu :

drbdadm disk-options --c-plan-ahead=0 --resync-rate=110M jtelshared

Remettre le nœud rompu en position primaire - CentOS 7.x ONLY

drbdadm primary jtelshared -->Vérifiez cela avec cat /proc/drbd

Redémarrer le nœud PCS

pcs cluster unstandby acd-lb-broken   --> Vérifiez cela avec   pcs status

pcs cluster start acd-lb-broken pcs node unstandby acd-lb-broken   --> Vérifiez cela avec   pcs status

Désactiver le transfert (deuxième nœud) - CentOS 7x seulement

Si le transfert a été accordé, il faut le désaccorder (sur le nœud rompu).

Note : de toute façon, cela ne fera pas de mal d'exécuter cette commande.

drbdadm adjust jtelshared

Tout vérifier

pcs status # CentOS 7.x cat /proc/drbd # CentOS 8.x drbdadm status # On some other linux machines ls /home/jtel/shared # Windows dir //acd-store/shared

Système de fichiers corrompu

Parfois, lorsque le DRBD échoue, le système de fichiers devient également corrompu.

Dans ce cas, les deux nœuds peuvent être primaires, mais la part ne sera pas montée non plus. 

La commande mount /srv/jtel/shared échouera.

Dans ce cas, il peut être nécessaire de réparer le système de fichiers.

Symptômes

[17354513.483526] XFS (drbd1): log mount/recovery failed: error -22 [17354513.483569] XFS (drbd1): log mount failed [17355040.104433] XFS (drbd1): Mounting V5 Filesystem [17355040.122234] XFS (drbd1): Avertissement de corruption: Metadata has LSN (56:112832) ahead of current LSN (56:112733). Please unmount and run xfs_repair (>= v4.3) to resolve. [17355040.122239] XFS (drbd1): log mount/recovery failed: error -22 [17355040.122322] XFS (drbd1): log mount failed

Réparation

Un des nœuds (il faut en choisir un pour devenir primaire) :

xfs_repair /dev/drbd/by-res/jtelshared/0 pcs resource cleanup

Celui-ci devrait ensuite monter et démarrer les ressources sur ce nœud.

Ensuite, continuez avec l'autre nœud comme " brisé" dans la situation du cerveau divisé.

Resync bloquée

Si la resynchronisation du DRBD est bloquée - la sortie sera "bloquée" lorsque cat /proc/drbd est exécuté - alors il peut être nécessaire de redémarrer la machine. 

Cela a été observé une fois, et le fait de recommencer a permis de résoudre redémarrage a résolu la situation. Cependant, on ne n'en sait pas grand-chose de beaucoup plus sur cet état, ni sur sa cause, à l'heure actuelle.

Échec de la connexion (données non pertinentes, abandon)

Lorsqu'il a été demandé au secondaire de rejeter ses données, et que toutes les commandes pour lancer la synchronisation ont été entrées sur le nœud sain et le nœud cassé, il arrive que cat /proc/drbd ne signale pas de connexion.

Vérifier /var/log/messages

Si vous voyez une sortie comme celle-ci :

kernel: block drbd0: uuid_compare()=-1000 by rule 100 kernel: block drbd0: Données non liées, abandon !

Alors les métadonnées sont devenues corrompues.

Cela exige que les métadonnées soient complètement reconstruites sur le mauvais nœud.

Utilisez les commandes suivantes pour recréer les données sur le nœud cassé :

drbdadm down jtelshared drbdadm wipe-md jtelshared drbdadm create-md jtelshared

Ensuite, procédez à la re-synchronisation comme ci-dessus (commencez par la partie "Sur le noeud cassé" avec les commandes pour placer celui-ci en secondaire et supprimer les données.