Drbd

Cette page a pour but d'expliquer entre autre la philosophie de drbd

Philosophie

Dans le cas d'un drbd en master / master, on va devoir avoir sur chaque noeud (on part ici du principe que l'on a 2 noeuds) un volume pour chaque noeud.
Si l'on utilise un DAS, il faudra le diviser en 2 afin que chaque noeud ait son volume avec la meme taille pour chaque lun). Sdb1 aura la meme taille sur les 2 noeuds, ainsi que sdb2

En master / master c'est le premier qui écrit qui gagne, on ne peut pas se permettre d'avoir des acces concurrentiels. On va sur chaque noeud découper l'espace dédié au drbd en deux.
Exemple :

Serveur 1 : 
 - drbd0 (sdb1) qui correspond au volume vol_kvm1 et qui contient les disques des VM tournant sur kvm1.metier.csn.notaires.fr
 - drbd1 (sdb2) qui correspond au volume vol_kvm2 et qui contient les disques des VM tourannt sur kvm2.metier.csn.notaires.fr 

Serveur 2 :
 - drbd0 (sdb1) qui correspond au volume vol_kvm1 et qui contient les disques des VM tournant sur kvm1.metier.csn.notaires.fr
 - drbd1 (sdb2) qui correspond au volume vol_kvm2 et qui contient les disques des VM tourannt sur kvm2.metier.csn.notaires.fr 

Drbd et LVM

Drbd est une couche en dessous de lvm, on peut très bien avoir la synchro drbd parfaite, mais avoir un soucis sur le lvm. Il faut s'assurer lors des différentes manipulations en cas 
de crash ci dessous que la commande lvs affiche bien les infos des vm sur chque noeud drbd (les services cman et clvmd doivent tourner).

On peut avoir des status lvdisplay en not available alors que la synchro drbd est bonne; drbd travaille une couche en dessous de lvm. (le /dev/volxxx des lv en not available n existe 
pas). Pour repasser les lv en available il suffit généralement de faire un vgchange -ayl /dev/vol_xxx (sur le serveur et sur le volume ou le lvdisplay marque des LV en not available. 
Si la synchro drbvd est bonne, alors les lv seront bien synchronisés aussi

Ajout de volumes / noeuds drdb

Si on rajoute des noeuds dans une conf drbd deja en prod (par exemple si on rajoute des disques, des lun ou un das), il vaut mieux ne pas reloader ou restarter le conf drbd. Mettre à jour le drbd.conf , puis faire les commandes classiques de mises en place drbd (elles vont lire le drbd.conf) : commandes ici

Lors de la synchro, au besoin on peut faire une pause avec la commande suivante : drbdadm pause-sync drbdX (à faire depuis le serveur qui "envoie" la synchro, c.a.d le maitre)

Crash Drbd

Diagnostique initial

Lors d'un problème sur le DRBD, il faut être très vigilant lors de la résolution afin de ne pas perdre de données. 

Différents cas sont possibles et il faut bien comprendre dans quel cas vous êtes pour résoudre le problème. 

Pour vérifier l'état des ressources DRBD, executer la commande 
# cat /proc/drbd ou drbd-overview

version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by root@node05.c01.cloud.agarik.com, 2013-04-16 14:08:38
 0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
    ns:151950816 nr:20 dw:47089820 dr:272460992 al:11509 bm:6401 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
    ns:1046619864 nr:20 dw:220831832 dr:857262116 al:39749 bm:50403 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 2: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
    ns:825788124 nr:196911072 dw:196911144 dr:830454444 al:1 bm:50403 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0


NB: si le fichier n'existe pas, c'est que le daemon ne tourne pas. Il faut le relancer.

Dans cet exemple, il y a 2 ressources DRBD 1 et 2 (cad 2 volumes synchronisés, le drbd0 contient des images pour le déploiement, il nous interesse moisn).
Les 3 informations importantes sont :
 * cs:Connected : Le daemon DRBD de chaque machine se voit bien et tout est ok. En cas de problème, l'état peut être "Standalone","WFConnection"
 * ro:Primary/Primary : La ressource est en mode Primary:Primary. Le 1er Primary correspond à l'état de la machine locale et le deuxième, l'état de la deuxième machine. 
 * ds:UpToDate/UpToDate: Les ressources sont à jour et correctement synchronisés.

Un problème de synchronisation va intervenir lors de la perte d'une des machines (reboot, crash) ou d'un coupure au niveau du réseau. DRBD intégre des mécanismes pour éviter cela
 mais il y a des cas où le daemon rend la main pour une résolution manuelle. C'est une protection afin d'éviter la corruption de donnée. 

Dans le cadre de notre exemple, il y a 2 ressources DRBD :
 * drbd1 qui correspond au volume volnode05 et qui contient les disques des VM tournant sur node05
 * drbd2 qui correspond au volume volnode06 et qui contient les disques des VM tourannt sur node06

La synchronisation se fait par l'intermédiaire de la carte réseau branchée sur les switchs de storages (eth1). 

Pour revenir à une synchronisation correcte, il est nécessaire de désigner un noeud qui sera sacrifié et le noeud qui servira de référence. L'ordre des commandes est importants pour 
faire la synchro dans le bon sens (du noeud de référence vers le noeud sacrifié). 

Pour faire repartir la synchro, il faut savoir la cause de la perte de synchro (reboot d'une machine ou perte du réseau de synchro) 
Au préalable, il est nécessaire de vérifier que le service drbd fonctionne correctement. 

Résolution crash machine

Dans le cas d'une machine qui a crashé ou rebootée, elle n'est donc pas à jour au niveau des données. Le cas est simple, c'est elle qui est sacrifiée. 

Il faut donc faire la synchro des 3 ressources drbd. A faire l'une après l'autre : 

 * Sur le noeud sacrifié (celui qui a crashé) : 
# drbdadm disconnect drbdX # Remplacer le X par le numéro de la ressource drbd sur laquelle intervenir. Si 2 ressources ont le problème, il faut refaire la procédure sur chacune des 
ressources
# drbdadm secondary drbdX
# drbdadm -- --discard-my-data connect drbdX

 * Sur le noeud survivant :
# drbdadm connect drbdX

 * Vérifier l'état du drbd via un 
# cat /proc/drbd 

 * Lorsque tout est revenu, il faut repassé la ressource en primary sur le noeud sacrifié 
# drbdadm primary drbdX

Une fois terminé, il faut relancer le cluster RH (qui ne se lance pas automatiquement pour éviter la corruption de VM à cause du DRBD). Voir ce lien

Exemple concret

Exemple d'utilisation dans le cas où node05 a plantée (ATTENTION au prompt pour voir sur quelle machine taper les commandes), à faire pour tous les drbdX

# pour drbd0
[root@node05.c01.cloud.agarik.com ~]# drbdadm disconnect drbd0
[root@node05.c01.cloud.agarik.com ~]# drbdadm secondary drbd0
[root@node05.c01.cloud.agarik.com ~]# drbdadm -- --discard-my-data connect drbd1

[root@node06.c01.cloud.agarik.com ~]# drbdadm connect drbd0

[root@node05.c01.cloud.agarik.com ~]# drbdadm primary drbd0

Résolution incident réseau (les machines n'ont pas rebootées)

Lors d'un incident réseau, la synchro n'a pas pu se faire mais les VM ont sûrement continuées à écrire sur leurs disques. Les VM sur node05 ont écrit sur le volume volnode05. les VM 
de node06 ont écrit sur le volume volnode06. 

 * Les données de node05 sur volnode05 sont donc la référence et node06 est le sacrifié
 * Les données de node06 sur volnode06 sont donc la référence et node05 est le sacrifié. 

Les données de volimages n'ont logiquement pas bougées donc vous pouvez sacrifier le noeud que vous voulez pour ce volume uniquement. 

Il arrive que le plantage fasse planter certains daemon du cluster et la synchro est un peu différentes. Il est impératif de vérifier dans la supervision le point "proc" si les 
daemon "corosync" et "fenced" tournent. 

??? Est-ce que les daemons "corosync" et "fenced" tournent ?
 > OUI  -> Résolution sans plantage cluster
 > NON -> Résolution avec plantage cluster 

Résolution sans plantage cluster

Les machines n'ayant pas rebootées, le cluster est en route et va empêcher de passer la ressource DRBD en secondary pour faire la synchro. C'est pour cette raison qu'il y a une 
commande supplémentaire à passer dans ce cas là : 

 * Sur le noeud sacrifié : 
# vgchange -anl /dev/volX # permet de désactiver le lock du cluster (mettre volnode05 si vous souhaitez resynchronisé drbd1).
# drbdadm disconnect drbdX # Remplacer le X par le numéro de la ressource drbd sur laquelle intervenir. Si 2 ressources ont le problème, il faut refaire la procédure sur chacune des 
ressources
# drbdadm secondary drbdX
# drbdadm -- --discard-my-data connect drbdX

 * Sur le noeud survivant :
# drbdadm connect drbdX

 * Vérifier l'état du drbd via un 
# cat /dev/drbd 

 * Lorsque tout est revenu, il faut repassé la ressource en primary sur le noeud sacrifié 
# drbdadm primary drbdX
# vgchange -ayl /dev/volX # permet de désactiver le lock du cluster 

Exemple concret

Exemple d'utilisation dans le cas d'une coupure réseau. Ici on va donc synchroniser le volnodeX du nodeX vers le volnodeX du nodeY

# pour drbd0
[root@node05.c01.cloud.agarik.com ~]# vgchange -anl /dev/volimages
[root@node05.c01.cloud.agarik.com ~]# drbdadm disconnect drbd0
[root@node05.c01.cloud.agarik.com ~]# drbdadm secondary drbd0
[root@node05.c01.cloud.agarik.com ~]# drbdadm -- --discard-my-data connect drbd0

[root@node06.c01.cloud.agarik.com ~]# drbdadm connect drbd0

[root@node05.c01.cloud.agarik.com ~]# drbdadm primary drbd0
[root@node05.c01.cloud.agarik.com ~]# vgchange -ayl /dev/volimages


# pour drbd1
[root@node06.c01.cloud.agarik.com ~]# vgchange -anl /dev/volnode05
[root@node06.c01.cloud.agarik.com ~]# drbdadm disconnect drbd1
[root@node06.c01.cloud.agarik.com ~]# drbdadm secondary drbd1
[root@node06.c01.cloud.agarik.com ~]# drbdadm -- --discard-my-data connect drbd1

[root@node05.c01.cloud.agarik.com ~]# drbdadm connect drbd1

[root@node06.c01.cloud.agarik.com ~]# drbdadm primary drbd1
[root@node06.c01.cloud.agarik.com ~]# vgchange -ayl /dev/volnode05


# pour drbd2
[root@node05.c01.cloud.agarik.com ~]# vgchange -anl /dev/volnode06
[root@node05.c01.cloud.agarik.com ~]# drbdadm disconnect drbd2
[root@node05.c01.cloud.agarik.com ~]# drbdadm secondary drbd2
[root@node05.c01.cloud.agarik.com ~]# drbdadm -- --discard-my-data connect drbd2

[root@node06.c01.cloud.agarik.com ~]# drbdadm connect drbd2

[root@node06.c01.cloud.agarik.com ~]# drbdadm primary drbd2
[root@node06.c01.cloud.agarik.com ~]# vgchange -ayl /dev/volnode06

Résolution avec plantage cluster

Le cluster n'aura planté que sur une seule machine. Il est alors nécessaire de reboot électriquement la machine impactée car des locks orphelin au niveau du kernel restent et bloque 
le reboot normal de la machine. 
Les étapes pour une bonne synchronisation sans perte de données et de services sont :
 * Resynchroniser le volume de la machine sur l'autre noeud (ex: si le cluster a planté sur node05, il faut resynchroniser le volume volnode05 sur node06) 
 * Migrer les VM tournant sur le noeud sur l'autre noeud (ex: basculer les VM de node06 vers node05). 
 * Reboot le noeud (via KVM ou APC)
 * Resynchroniser le volume de l'autre noeud sur la machine (ex: synchro de volnode06 sur node05). 
 * Rebasculer les VM sur le noeud d'origine

Exemple concret

Exemple dans le cas où le cluster a planté sur node06 :

# pour drbd0
[root@node05.c01.cloud.agarik.com ~]# vgchange -anl /dev/volimages
[root@node05.c01.cloud.agarik.com ~]# drbdadm disconnect drbd0
[root@node05.c01.cloud.agarik.com ~]# drbdadm secondary drbd0
[root@node05.c01.cloud.agarik.com ~]# drbdadm -- --discard-my-data connect drbd1

[root@node06.c01.cloud.agarik.com ~]# drbdadm connect drbd0

[root@node05.c01.cloud.agarik.com ~]# drbdadm primary drbd0
[root@node05.c01.cloud.agarik.com ~]# vgchange -ayl /dev/volimages

# pour drbd2
[root@node05.c01.cloud.agarik.com ~]# vgchange -anl /dev/volnode06
[root@node05.c01.cloud.agarik.com ~]# drbdadm disconnect drbd2
[root@node05.c01.cloud.agarik.com ~]# drbdadm secondary drbd2
[root@node05.c01.cloud.agarik.com ~]# drbdadm -- --discard-my-data connect drbd2

[root@node06.c01.cloud.agarik.com ~]# drbdadm connect drbd2

[root@node05.c01.cloud.agarik.com ~]# drbdadm primary drbd2
[root@node05.c01.cloud.agarik.com ~]# vgchange -ayl /dev/volnode06

# A partir de là, il est possible de basculer les VM de node06 sur node05 puisque les données DRBD sont à jour
# récupérer les ID des VMs 
[root@node06.c01.cloud.agarik.com ~]# virsh list 
# Pour chaque VM tournant faire :
[root@node06.c01.cloud.agarik.com ~]# virsh migrate --live X qemu+ssh://root@node05.c01.cloud.agarik.com/system

# FAIRE LE REBOOT ELECTRIQUE de node06
# Au retour de la machine, synchroniser drbd1 (la machine ayant rebooté le cluster ne tourne pas et les locks ont disparus):
[root@node06.c01.cloud.agarik.com ~]# drbdadm disconnect drbd1
[root@node06.c01.cloud.agarik.com ~]# drbdadm secondary drbd1
[root@node06.c01.cloud.agarik.com ~]# drbdadm -- --discard-my-data connect drbd1

[root@node05.c01.cloud.agarik.com ~]# drbdadm connect drbd1

# Relance du cluster 
[root@node02.c01.cloud.agarik.com ~]# service cman start
[root@node02.c01.cloud.agarik.com ~]# service clvmd start
[root@node02.c01.cloud.agarik.com ~]# service rgmanager start
[root@node02.c01.cloud.agarik.com ~]# service ricci start

# basculer les VM initialement sur node06 sur node06
[root@node05.c01.cloud.agarik.com ~]# virsh migrate --live X qemu+ssh://root@node02.c01.cloud.agarik.com

Précautions / infos sup

Si on a peur qu'une synchro se lance toute seule dans le mauvais sens, le mieux est de faire cela (sur le noeud sacrifié ou que l'on va rebooter :
 - drbdadm disconnect drbdX (Faire /etc/init.d/clvmd stop si on a une erreur) && drbdadm secondary drbdX , puis /etc/init.d/drbd stop
 - désactiver drbd au redémarrage
 - rebooter le serveur
 - relancer drbd, les "meta data" vont voir que c est ce noeud qui n'est pas à jour, donc la synchro se fera automatiquement et dans le bon sens
 - relancer les service pour le lvm cluster (cman et clvmd), puis s assurer que lvs affiche bien les infos des vm sur chque noeud drbd
 - et enfin relancer les autres serveices pour le kvm cluster :
      /etc/init.d/rgmanager start
      /etc/init.d/corosync start
      (fenced,dlm_controld et gfs_controld doit deja etre démarré)
      /usr/sbin/cimserver
      /usr/sbin/oddjobd
      /etc/init.d/saslauthd start
      /etc/init.d/ricci start

Il est possible de mettre en pause une synchro avec drbdadm pause-sync drbdX (et drbdadm resume-sync drbdX pour reprendre la synchro). Mais si l'on change le drbd.conf et que
l'on fait un restart de drbd, la pause de synchro va sauter et la synchro se relancer automatiquement

Vérification Daemon DRBD

Vérifier que le daemon DRBD est bien lancé.

Erreur Drbd

Device is held open by someone

Cela peut arriver lorsque l'on fait un drbdadm secondary, mais que les services clmvd et cman tourne, il faut les arreter. Voir si ce n'est pas qu'un problème de lock et qu'il peut
être résolu avec "vgchange -anl /dev/volX" # permet de désactiver le lock du cluster (voir plus haut)

"Can not open backing device" or # "open(/dev/sdc1) failed: Device or resource busy"

Il existe surement un device qui est défini dans le multipath qui est créé alors qu il ne devrait pas. Faire un "dmsetup ls" pour l'identifier, puis "dmsetup remove xxx"

[root@kvm1.metier.csn.notaires.fr modules]# drbdadm up drbd0
0: Failure: (104) Can not open backing device.
Command 'drbdsetup attach 0 /dev/sdc1 /dev/sdc1 internal --resync-rate=110M --on-io-error=detach --fencing=dont-care' terminated with exit code 10

[root@kvm1.metier.csn.notaires.fr modules]# drbdadm role drbd0
Unconfigured

[root@kvm1.metier.csn.notaires.fr modules]# dmesg
d-con drbd0: Starting worker thread (from drbdsetup [16779])
block drbd0: open("/dev/sdc1") failed with -16
d-con drbd0: Terminating worker thread
d-con drbd0: Starting worker thread (from drbdsetup [16796])
block drbd0: open("/dev/sdc1") failed with -16
d-con drbd0: Terminating worker thread

[root@kvm1.metier.csn.notaires.fr modules]# dmsetup ls
das_kvm1        (253:0)
das_kvm1p2      (253:2)
das_kvm1p1      (253:1)

[root@kvm1.metier.csn.notaires.fr modules]# dmsetup remove das_kvm1p1
[root@kvm1.metier.csn.notaires.fr modules]# dmsetup remove das_kvm1p2
[root@kvm1.metier.csn.notaires.fr modules]# dmsetup ls
das_kvm1        (253:0)
[root@kvm1.metier.csn.notaires.fr modules]# dmsetup remove das_kvm1

[root@kvm1.metier.csn.notaires.fr modules]# dmsetup ls
No devices found

[root@kvm1.metier.csn.notaires.fr modules]# drbdadm up drbd0

[root@kvm1.metier.csn.notaires.fr modules]# cat /proc/drbd
version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by root@kvm1.metier.csn.notaires.fr, 2012-11-07 18:02:08
 0: cs:WFConnection ro:Secondary/Unknown ds:Inconsistent/DUnknown C r----s
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:1073703568
 1: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
[root@kvm1.metier.csn.notaires.fr modules]#