Bonjour,
 
J'ai un soucis avec DRBD, LVM et Multipath. Après avoir fouillé sur google, j'ai pas tellement trouvé de solution.  
Voici rapidement le schéma déjà :  

 
Ensuite, il faut savoir que j'exporte un volume groupe de mes serveurs DRBD, en iSCSI.  
Donc sur mes serveurs Xen, je suis soit connecté à DRBD1 ou DRBD2. A noter qu'il n'y a PAS d'accès concurentiel direct, puisque j'utilise des Logical Volume sur mes Xen, donc je n'écris à AUCUN moment sur le même Logical Volume (au même endroit quoi). Pour éviter que pendant que le lien de réplication se casse la gueule, chacun écrive sur les deux DRBD (là ça serait le bordel), j'ai un script de priorité de multipath.  
Bref, le soucis n'est pas là.  
Le soucis, c'est quand je crée sur un Xen attaché à DRBD2, un logical volume, il n'est pas vu par les autres Xen attachés à DRBD1, pourtant le lien de réplication fonctionne parfaitement. Est-ce normal ?
 
edit : je vois bien le lien de réplication travailler quand j'écris sur un LV tout neuf, mais de l'autre côté, il n'apparait pas..

regardes du coté des réservations et des locks ... c'est juste une piste, hein, j'ai pas de certitudes.

tu penses niveau DRBD donc ?

ouais

Je lis la doc, mais je trouve rien de très pertinant là dedans. Je continue à fouiller. Le plus étrange c'est que je trouve pas des "collègues de problème"

Je tiens à préciser que les disques répliqués sont sur une baie Dell MD1000 (avec mass cache etc.) relié en SAS

Bon j'ai désactivé toutes les writes barriers, on va voir ce que ça donne.

edit : pareil, c'est le bordel. Je crée ou supprime des LV sur l'export iSCSI (donc sur les Xen) attaché sur un DRBD, sur l'autre il ne "voit" rien tant que je fais pas un "disconnect" et "connect" DRBD. Là après ça "apparait". Je pige pas

Le pire, c'est que si je remove ou add un LV, je vois de l'activité réseau sur le lien de réplication, donc ya bien quelque chose qui est copié, mais ce n'est pas "suffisant" pour LVM..

te faut une version cluster de LVM => cLVM

Théoriquement non. J'ai peut être mal exprimé mon bordel :
Sur les DRBD :
Baie relié en SAS à une Debian -> Vg avec deux LV -> LV répliqués via DRBD et exporté en iSCSI.

Par exemple, mon lv Xen fait 500Go.

Sur mes clients iSCSI, mes machines Xen donc :
Elles voient l'export iSCSI comme un device block, bref un /dev/sdx.
Ce dev block est lvmisé à son tour, et possède des LV. Un LV = Une machine virtuelle.

Si les Xen sont sur le même DRBD : quand je crée un LV sur un Xen, il est AUTOMATIQUEMENT détécté sur les autre Xen (mais pas activé oui, certes puisque je n'ai pas cLVM ! mais ce n'est pas bien grave, car j'en crée pas tous les quatres matin, et ça risque pas de me faire foirer mes données).

Si un des Xen est sur l'autre DRBD, pourtant répliqué en mode bloc (donc censé être identique), la création d'un LV n'est pas retransmise sur l'autre DRBD, ALORS que le lien de réplication indique une activité !

Or, si c'est répliqué, pourquoi il n'est pas detecté sur les Xen "pointant" vers l'autre DRBD ? ... Il devrait être "inactive" mais au moins visible !

Parce que c'est comme ça que fonctionne LVM, t'es pa censé faire des modifs "en dehors", donc il rescanne pas ses données
C'est à ça que sert cLVM ! il notifie tous les noeuds qu'il y a eu un changement, et il "re-scanne" les infos afin d'être à jour
 
Y a peut-être moyen de faire rescanner par LVM sans rebooter, regarde de ce coté : http://www.drbd.org/users-guide/s-nested-lvm.html

Je ne cherche pas à "rescanner", peu m'importe que le volume soit inactif. D'ailleurs, même en rebootant mes Xen, en restant sur le 2ème DRBD, j'ai toujours les volumes qui ne sont pas à jour.

Là, on parle bien d'un "différent" plus profond, LVM à beau reboot, vgchange, rien n'y fait : il n'y a une différence, qui est uniquement "comblée" (LV à jour, sans rien refresh d'ailleurs) UNIQUEMENT quand je force le DRBD2 à se déconnecter et reconnecter à la ressource sur le 1 !

J'ai pas compris ton problème en fait...
Quand tu parles de Xen, tu parles de tes VMs en fait ?

Non, mes Xen ce sont mes Dom0 ; Les VM tournent dans des LV crées sur le Dom0, ces LV venant d'un device block, lui même étant un export iSCSI d'un LV sur les serveurs DRBD.

En gros :

_____________
Device "normal" pour une VM (mais cet étage on s'en fou)
_____________
LV sur le Dom0
_____________
Device Block sur le dom0
_____________
iSCSI sur le LAN
_____________
LV sur DRBD
_____________
Device SAS

edit 2 : en rouge la couche qui merde, enfin ne se met pas à jour (pas en terme "ACTIVE/Inactive", juste Visible !) si je fait pas un déco/reco des ressources DRBD. A noter que le problème n'a PAS lieu sur mes serveurs Xen pointent vers le MÊME drbd : ceux là pas de soucis, le LV apparaît, même si inactive (ça je sais, car j'utilise pas cLVM)

Oulah, refais ton schéma c'est pas clair du tout ton explication là.
 
DRBD1 stocké où ? sur quoi ?
DRBD2 stocké où ? sur quoi ?
DRBD1 et 2, c'est deux DRBD différents, ou les deux composantes de ton DRBD ?

 
Plus clair ? C'est chaud à expliquer quand les couches s'entassent
 
Admettons que je parte de 0, je crée un LV sur un PC client, qui se connecte juste en iSCSI sur DRBD1 pour faire un "lvcreate TOTO".
- Cela donnerai sur le client lui même :  
ACTIVE /dev/vg_xen/TOTO
 
- Dom0 Alpha en iSCSI sur DRBD 1 :
inactive /dev/vg_xen/TOTO
 
- Dom0 Beta en iSCSI sur DRBD 2 :
RIEN
 
Par contre, si je déconnecte et reconnecter la ressource sur DRBD2, Dom0 Beta aura bien :
- Dom0 Beta en iSCSI sur DRBD 2 :
inactive /dev/vg_xen/TOTO

Super, avec google, quand je chercher "drbd lvm locks" je tombe ici
http://www.google.fr/search?hl=fr& [...] =&aq=f&oq=

C'est beaucoup plus clair
 
Je pense que c'est parce que t'es en actif/actif au niveau DRBD, et je ne suis pas certain que le LVM standard
gère ça très bien, c'est un peu pour ça que clvm a été créé (pas forcément pour DRBD, mais par exemple pour du iSCSI/FC
ou ton "disque" - ou LUN - est accessible depuis plusieurs noeuds).
 
Si tu déconnectes / reconnecte ta ressource sur DRBD2, ca revient "un peu" à ce qui est indiqué dans la doc
dont j'ai donné le lien plus haut où ils font :

Sauf que dans leur exemple, c'est du Primary/Secondary
 
Donc à mon avis ton salut est dans cLVM

Oui, je suis en train de l'installer. On va bien voir

Ptin j'en chie, pour installer cLVM.  
 
J'ai installé OpenAIS (donc cLVM w/o GFS) comme décris ici :  
http://h2o.glou.fr/
 
Par contre, les deux nœuds du cluster n'ont pas l'air de se voir (il y a l'air de bien avoir le multicast entre les deux, mais comme eth1 est ponté en peth1, je sais pas si ça pose soucis).
 
J'ai vraiment pas d'expérience dans cLVM, si y'a des gens avec un peu plus de bouteille je veux bien

Mais t'as vraiment besoin de l'actif/actif sinon ?
 
En terme de perfs, c'est vraiment au-dessus ?

Disons que niveau perfs je suis au dessus d'un SAN proprio (Datacore), et qu'en cas de perte d'un DRBD, c'est totalement transparent, sans besoin d'un heartbeat derrière..
 
edit : le multipath permet la HA, et le multimaître la transparence en cas de loss d'un serveur drbd.
 
Avec OpenAIS, j'en suis là :

 
Pareil sur l'autre nœud :  

 
Pas de join

 
en même temps, si le serveur de virtu qui supporte datacore est mal sizé (proc/ram + hba), ça fait goulot d'étranglement, hein
si tu size correctement normalement les perfs doivent pas etre impactés ... sinon, juste par curiosité t'as quoi derriere le datacore

Le datacore est sur un serveur full à lui, Windows 2003 server, 8 coeur 16gig de ram, en SAS sur une MD1000.

edit : mais on a eu des gag dessus, le truc bizarre, genre qui ressemble vaguement à ce qu'il m'arrive là en DRBD. Mon taff c'est d'avoir une archi libre et stable, pour pas dépendre que de datacore.

D'ailleurs, sans être multi-maître, si mes LV ne sont pas correctement repliqué sur le 2ème DRBD, imaginez la cata si je passe sur le 2 à cause d'un coupure du 1.  
Les nouveaux volumes serait non détecté.
 
La SEULE solution que je vois (sauf si j'arrive à faire marcher cLVM, mais c'est pas gagné avec OpenAIS qui voit aucun autre nœud que lui même), c'est de régulièrement (via CRON), déconnecter/reconnecter un des DRBD à l'autre.
 
C'est moche, mais au moins je suis sûr d'avoir les LV. Mais bon, si ça réplique à moitié, et qu'il manque des trucs, bonjour la cohérence des données.  
 
Je vais continuer des tests en attendant.

Bon, quelques conclusion : au niveau bloc, DRBD à l'air de faire son taff.  
 
Pourquoi ? Car par exemple, je lance une VM de test (donc sur un LV qui existe BIEN sur les deux DRBD).
Cette VM de test est lancé sur un Xen relié à DRBD1. J'écris des fichiers (touch toto.txt).
Je halt la VM.
 
Je lance la même VM sur un autre Xen relié à DRBD2. Je vois bien le fichier.
 
Donc je pense que LVM, quand on modifie un VG (ajout ou suppression de LV), il doit utiliser des blocs spéciaux, ou pas reconnu comme changés par DRBD, tant que je refais pas une "vrai" synchro (déco/reco).
 
J'aurai bien aimé parvenir à faire marcher OpenAIS+cLVM, j'ai bien suivi la doc, c'est censé marché tout seul, sauf que les nodes OpenAIS ne se voyent pas (je soupçonne, peut être à tort) que c'est que mes Dom0 Xen font un bridge sur l'interface eth. Peut être que ça merde avec le multicast, je n'en sais rien. Peut être faire un autre topic ?

Ben c'est heartbeat qui s'occupe de ça en faisant un vgchange -machin truc bidule

Très mauvaise idée ça

 
une fois n'est pas coutume, j'ai beau faire vgchange -machine truc bidule, ça ne change RIEN !
 
Toute modification de métadonnées LVM (lvcreate, lvremove) ne sont PAS visible sur le deuxième DRBD, TANT QUE il n'y a pas eu de déco/reco de la ressource.
Par contre, pour les LV existants, aucun soucis : la réplication de bloc se fait bien, juste que les opérations LV sur le VG qui merdent.  
 
A noter que je viens de tester même la live migration entre deux xen, branché CHACUN sur un DRBD différent, AUCUN problème.
 
C'est donc bien que créer un LV doit engendrer un truc spécial au niveau bloc que DRBD n'est pas capable de répérer, tant qu'on ne refait pas une synchro manuelle.
 
Exemple concret sur mes Dom0 :
Celui sur lequel je viens de détruire un LV relié à DRBD1:
# vgchange -ay
  47 logical volume(s) in volume group "vg_xen" now active
  2 logical volume(s) in volume group "vg_samba" now active
 
L'autre dom0, relié à DRBD2:
# vgchange -ay
  48 logical volume(s) in volume group "vg_xen" now active
  2 logical volume(s) in volume group "vg_samba" now active
 
 
On voit bien le volume en plus, qui n'a pas disparu..

Mais c'est heartbeat qui le fait ça
 
heartbeat detecte que DRBD1 est parti (ou bien tu force la migration du service DRBD), il entreprends :
- le passage en primary sur le second noeud (qui etait secondary jusque là), ce qui revient à ton deco/reco
- il fait le vgchange -truc machin chose
 

Bon je check ça.

edit : euh, passer le DRBD2 en primaire et faire un vgchange sur les Dom0, c'est possible avec heartbeat ?

pas sur les dom0, puisque le heartbeat serait entre DRBD1 et DRBD2
 
Mais il suffit de pas de le faire sur DRBD2 pour que ça fonctionne ?

Oulà, non ! Les DRBD exportent que deux "gros" LV de 500Gig, qui sont eux mêmes LVMisés (je découpe le disque de 500Gig en LV de 10 ou 20gig) sur les Dom0 ! Et c'est sur les Dom0 que je crée et modifie les LV qui sont en gros les disque des DomUs (les VM quoi).

La partie LVM de DRBD on s'en tape ! C'est juste pour ma simplifier la vie. Là ou je dis que ça chie, c'est LVM au niveau Dom0. (vais-je réussir à être clair, telle est la question)

N'oublie pas, iSCSI fait que je les vois comme des périph "block". Même si j'exporte un gros LV, il est vu à l'arrivé comme un device block de 500Go. Et sur les Dom0, je créer un vg, puis des LV à l'intérieur !

edit : par contre, je dis déco/reco la ressource sur les DRBD, en effet, ça remet tout d'applomb chez mes Dom0. C'est ça que je trouve étrange..... Sans faire le moindre vgchange...

Moi j'aime pas LVM de toutes façons

 
farpaitement

moi j'aime pas l'artisanat

En fait, ce que tu tentes de réaliser, ça me fait beaucoup beaucoup penser à ce que fait openfiler : http://www.openfiler.com

Sauf que eux ne proposent que le haute disponibilité en actif/passif.

A mon avis c'est pas un choix qu'ils ont fait comme ça au pif, c'est parce que ça doit pas être super gérable autrement

Ouais, y mangent le pain des grosses boites

openfiler, ça marche nickel

Je plussoie, c'est que j'utilisais pour faire du maquettage avant qu'on achète notre SAN
 
Et un collègue l'utilise toujours, à priori ça a bien avancé.