Reprise du message précédent :
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é.

Bon je crois que je vais demander au gars de chez DRBD cette histoire de bloc pas repliqué avec LVM. Ça me démange trop.

Si j'ai la réponse, j'ai la solution à mon problème

edit : quand même, ça aurait de la gueule un multipath round-robin avec du Xen sur du DRBD dual primary

Salut,
 
J'ai pas tout suivi.
 
Par ici je monte à la chaine des clusters DRBD/HeartBeat/[Openvz|KVM] avec du LVM par dessus le DRBD
 
T'en es ou ?

J'en suis que je passe pour un glandu sur la ML de DRBD, car les gusses là bas ne lisent qu'en travers mon - soit, long - mail, et pense que c'est juste du Nested LVM "classique" sur le serveur DRBD, alors que je parle d'un problème LVM sur des clients iSCSI, qui EUX ont LVM.  
 
Je vais essayer d'exporter un volume physique avec DRBD (sans LVM), pour simplifier l'explication : ce sont les LVM des clients qui chient.  
 
Je vais en salle serveur pour tester tout ça, d'ici midi j'aurai une réponse !

On peut pas leur en vouloir vu le mal qu'on a eu à comprendre

 
Oui, je sais pas, je me sens seul dans l'univers à jouer avec LVM sur un client iSCSI

Non
 
Par contre avec un client LVM sur du iSCSI, sur du DRBD en multi-actif, possible

 
Voilà    
Pourtant je trouve que ça poutre tout cette conf, c'est la plus élégante : pas de heartbeat, rien, juste DRBD et du fencing en cas de pb sur le lien de réplication, et point barre !

Bah non pas point barre, pont de suspension

 
 
Remarque, ta pas tort  

Bon, ça avance.
J'ai décidé, pour simplifier la chose de  répliquer un disque ENTIER avec DRBD. Plus de LVM sur les hosts DRBD.
J'exporte donc en iSCSI le /dev/drbd0, qui est tout simplement /dev/sdb.

Maintenant, voyons sur mes clients :
CLIENT1 est connecté sur DRBD1. Un fdisk -l donne donc, sur lui :
Disk /dev/sdb: 2998.9 GB, 2998960914432 bytes

CLIENT2 est connecté sur DRBD2. Fdisk :
Disk /dev/sdb: 2998.9 GB, 2998960914432 bytes

Tout va bien pour l'instant. Maintenant, mettons que sur CLIENT1 je crée un VG qui contient un LV. Lvscan, je le vois, très bien.

Mais, sur CLIENT2, rien nada : pas de vg, ni de lv (pvscan, vgscan, lvscan = RIEN). Par contre, accrochez vous, si sur DRBD2 je fais :
drbdadm disconnect resource && drbdadm connect resource

Cette fois, CLIENT2 voit bien le vg et les lv (inactif - normal - mais bien présents !)

Mais pourquoi ??????

Ben c'est pareil qu'avant non

 
Oui, mais ça me plait pas.  
 
Comme dirais Lars :

 
Mais ça m'intrigue un peu

Bon, ben voilà, j'ai essayé cLVM. Et ben suspense...  
 

 
En effet, mon cluster sous OpenAIS fonctionne, les hôtes se voient, cLVMd mon montre bien une activité des deux côtés quand je fais une opération avec LVM, sauf que...  
 
CLIENT1 connecté sur DRBD1 fait un pvcreate, puis vgcreate.  
 
CLIENT1:~# vgcreate /dev/vg_xen /dev/dm-0
  Clustered volume group "vg_xen" successfully created
 
Ça cause :  
CLVMD[40a33950]: Mar  9 15:13:16 LVM thread waiting for work
CLVMD[e28d5770]: Mar  9 15:13:16 181631075 got message from nodeid 181631075 for 181631076. len 1
 
CLIENT2:~# vgscan  
  Reading all physical volumes.  This may take a while...
 
Oups, rien du tout.. Bon allez, je vais créer un LV sur CLIENT1, on va bien voir !
 
CLIENT1:~# lvcreate -L82M -n xena3vol vg_xen
  Rounding up size to full physical extent 84,00 MB
  Error locking on node ad37864: Volume group for uuid not found: 1xgSmqky8beMkIQSGqYQ0fSC6IdOBOJEg46qEeWY9eV9njYJ2B9zxJwyXIaSHs3h
  Aborting. Failed to activate new LV to wipe the start of it.
 
PATATRA !  
Et bien sûr, pas de problème si CLIENT1 et CLIENT2 sont sur le même DRBD...
 
 

Ça y est ! Résolu ! Enfin §§§§§§§§§§§§!!

Bon, de suite là comme ça, ça n'avait RIEN A VOIR avec cLVM, ni même LVM, ni non plus DRBD, ni le cache de mes baies de disques.

En fait, la solution est très simple ! Sur mes hosts DRBD, sur lesquels j'exporte en iSCSI mes disques, voici mon ancienne conf :

Eh oui, de base, iSCSI a un système de cache, sur les fichiers. Autrement dit, quand je crée un volume LVM, cela n'engendre pas de création de blocks au niveau disque, d'où "l'invisibilité" pour DRBD, qui ne réplique pas sur le deuxième nœud.

La solution est de mettre :

Et oh ! Magie

Tout marche !

edit : merci à Dan pour la réponse sur la ML DRBD

 
 
le iSCSI ça a toujours été du mode bloc au niveau des i/os, contrairement à de l'IP (NFS) qui est du fichier ...

Sauf dans la conf en fileio

Ah dit comme ça c'est plus simple ! (enfin à comprendre).

Cool que ca marche

ps : désolé chuis en retard xD

Pour être exact, du LVM multiple (cLVM fonctionne) sur du iSCSI sur du LVM sur du DRBD en multi-primary

Et essayer GlusterFS ca serait pas plus simple ici ?
Ca a l'air de bieng poutrer et c'est plus souple que drdb.

Peut être plus souple, mais je doute niveau perfs qu'on puisse faire mieux ou jeu égal vs du block...

Normalement gluster supportera le block à la prochaine release.

Sauf que je suis en pré-prod là
 
Ça risque d'être un peu chaud les marrons

ouais c sur
Je vais attendre un peu de mon coté, car je cherche une solution la plus simple possible sans usine à gaz (KISS )

Et c'est pas évident : mélanger haute dispo et sécurité des données + performances + KISS, c'est même très chaud...

Si gluster tient la route je pense que ca sera gagné pour moi. Mes vm (xen!SERVER!) n'utilisent pas des i/o de manière très intensive (pas de serveur de mail par exemple). En attendant je pense faire qqu essais avec gluster en NFS, mais niveau perfs    
 
Sinon openfiler supporte le block je crois. Ensuite pour la HA, je ne sais pas si c'est integré dedans.