Newsgroup: it.comp.os.linux.sys
Titolo: LVM su DRBD

Avete mai creato un volume LVM partendo
da alcuni device DRBD ?
Ad esempio, in un server con 6 dischi, si potrebbero
creare 6 device DRBD distinti, uno per disco, 
ed aggregarli con LVM
DRBD intercetta i guasti ai device, pertanto in caso di
disco rotto, DRBD lo sostituirà con la sua controparte
remota, ed abbinando il tutto ad LVM, si avrebbe una
sorta di RAID 10 via rete.
Avete mai fatto niente di simile? Qualche implicazione?
Al limite si potrebbe fare un raid5 su ambo i nodi
sprecando il solo disco di parità, ma mi pare superfluo,
se ho capito bene, ci pensa DRBD a rimpiazzare l'eventuale
disco rotto con il suo gemello remoto....

 SUSL di turno apra il portafogli ed investa in una bella NAS.
Non è un problema di soldi.
Un NAS costa *sicuramente* meno.
Inoltre, le due cose non sono rapportabili, visto che il NAS
solitamente non è ridondato. Il problema nasce proprio dal fatto
di voler implementare uno storage condiviso ma al suo tempo ridondato.
Il NAS non è la soluzione.
(e se non dovesse aprire il portafogli cosa fai, ti licenzi per
ripicca?)

 disco rotto con il suo gemello remoto....
Nello specifico come configureresti il tutto?
Vuoi fare una configurazione active-active?
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 Durante dei test.
No, ho sbagliato.
Non solo dei test: ho anche delle macchine in produzione con lvm su
drdb e anche lvm su drbd su lvm.


 Avete mai fatto niente di simile? Qualche implicazione?
Teoricamente si può fare.
Praticamente vai a mettere le palle tra l'incudine d il martello, molto 
tafazianamente.
Se succede qualcosa ho solo paura a capire dove sta il problema.
Io andrei su una SAN.

On 1 Nov, 21:04, Gandalf Corvotempesta

Attenzione perché non mi sembra che funzioni esattamente così.
Ho in produzione diversi sistemi con drbd, in alcuni casi anche con
sopra l'lvm ma non l'ho mai usato in questo modo.
Premetto che le versioni di drbd che uso Io non sono recentissime (la
base è una SLES 10) ma che io sappia drbd realizza un raid 1 via rete,
ma le due macchine coinvolte possono accedere al disco solamente una
alla volta e solo se sono il nodo attivo del cluster drbd.
Schematizziamo quindi lo scenario da Te proposto (ammesso che Io abbia
ben compreso cosa vuoi fare):
- 6 Dischi su 2 server distinti
- 6 device distinte gestite da drbd (/dev/drbd0-5)
- Tutte e 6 le device vengono "marcate" come PV da LVM
- LVM espone un metadevice con parità di tipo raid 5 formato dai 6 pv
gestiti dal drbd.
Questo è sircuramente possibile e tutto funzionante fintanto che tutto
gira su un solo nodo.
Nel momento in cui si rompe un disco che succede? Drbd switcherà
quella risorsa sull'altro nodo facendo passare da "stand-by" a
"master" ma (se non sbaglio) lo farà per quel singolo disco e non per
tutti e 6 quindi lo strato LVM sovrastante come la prenderà? Se invece
vengono switchate tutte e 6 le device drbd chi dice all'LVM come
comportarsi visto che improvvisamente non sarà più in grado di
accedere ai dischi?
Anche se pensi di gestire tutto con Heartbeat o peacemaker non credo
Tu riesca a far funzionare tutto correttamente.
Fermo restando che la soluzione della NAS è sicuramente un approccio
più stabile e sicuro (perché qualcuno diceva che le nas non sono
ridondate? Mai sentito parlare di NAS con doppia alimentazione, doppio
controller e raid 0+1?)
volendo percorrere la strada LVM+drbd Io farei così:
- Con il kernel raid creo una meta-device raid 5 con i 6 dischi
- La device creata la metto in raid 1 con drbd
- Sopra la device drbd uso LVM per affettarla come meglio mi occorre
In questo modo i 6 dischi sono gestiti ed accessibili da ognuno dei
nodi tramite l'interfaccia md-raid del kernel e la copia tra i due
gruppi raid è gestita dal drbd che in caso di fail sposterà da un nodo
all'altro l'intero gruppo raid con buona pace dell'eventuale lvm che
potrà essere gestito in modo migliore tramite HB o Peacemaker.

 Vuoi fare una configurazione active-active?
No, active-standby.
Vorrei però evitare di buttar via troppi dischi.
Già son necessari il doppio di dischi per via
di DRBD, se poi dovessi fare un ulteriore RAID
su ciascuna macchina, butterei via troppi dischi.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 Io andrei su una SAN.
Troppo costosa, troppo overkill.
Devo ridondare una manciata di VM non critiche. Posso
spegnerle in caso di necessità.


 spegnerle in caso di necessità.
Cosa usi per virtualizzare? Con xen ora puoi avere il device drbd: e si
occupa lui di passare da pri a sec quando necessario.


 su ciascuna macchina, butterei via troppi dischi.
Ma vuoi fare due raid0 ridondati via drbd?
Piuttosto farei un drbd su raid5.
Oppure vuoi fare 6 device drbd messi come pv di un lvm?
Così va sicuramente meglio, per avere un danno ti dovrebbero
saltare entrambi i dischi di un drbd.
In una macchina dove non importava lo spreco di risorse ho fatto
anche raid1 + drbd con sopra xen che virtualizza la macchina che
poi offre realmente il servizio, con heartbeat in modalità cluster
che si occupa del failover. Va che è una meraviglia.


 potrà essere gestito in modo migliore tramite HB o Peacemaker.
Si, era una delle possibilità. In tal caso perdo 2 dischi.
Ma ci sono reali vantaggi a fare ciò ?


 saltare entrambi i dischi di un drbd.
E' quello che volevo fare.
6 dischi sul server1, 6 dischi sul server2.
DRBD sincronizza i 6 dischi, tramite 6 device distinti.
In pratica:
dev0 = server1disco1 --> server2disco1
dev1 = server1disco2 --> server2disco2
e così via.
6 risorse indipendenti.
Poi sopra ci creo un volume logico.


 quel punto devi fare un bel resync di tutto. Quella è una bella rottura.
I collegamenti son doppi.
Dovrebbero saltare due schede per volta, o due switch per volta
o due cavi per volta.


 Poi sopra ci creo un volume logico.
Si può fare tranquillamente.
Ricorda di modificare lvm.conf per leggere solo dai /dev/drbd[0-5].
Se salta un disco sulla macchina active drbd va in Diskless/UpToDate
e usi la risorsa remota come disco locale.
Se salta sulla macchina standby te ne freghi, la spegni e cambi il disco.


 nulla.
Secondo me qui casca l'asino.
Se si interrompe il networking, DRBD switcha.
Se si rompe un disco, non ho mai provato a verificare quanto ci mette DRBD 
ad accorgersene.
E nelle configurazioni non mi sovvengono parametri particolari per 
impostare cosa succede quando si rompe un disco.
Secondo me DRBD non è fatto per questo, ovvero per accorgersi che un 
disco è rotto.

 Ma ci sono reali vantaggi a fare ciò ?
Beh tutto sommato in realtà no, sopratutto se il drbd attuale funziona
come hai detto Tu.
Ora mi hai incuriosito ........ vado a documentarmi!! ;-)

 disco è rotto.
Stando alla documentazione, però, sembra proprio il contrario.

 meccaniche dello storage.
Fai pure nomi, però come ho scritto, lo storage che sto cercando
di implementare deve essere lowcost e fatto con materiale di recupero.
le vm da ospitare non sono importanti, sono VM di sviluppo e testing,
però devo poter migrare il tutto tra i due nodi senza interruzione.

 disco � rotto.
Ok che non � fatto per questo, ma � fatto in modo da poter gestire i fail hw
e non potrebbe essere diversamente.


 sopra.
No no, � un eventuale sistema di HA che passa da primary a secondary
e viceversa.
Il drbd da solo non switcha nulla: se era primary resta primary, se era
secondary resta secondary.
Il problema si ha se hai una risorsa in Pri/Sec Diskless/UpToDate e si
interrompe la connettivit�: � come tirar via il cavo sata al disco da cui
stai leggendo i dati.
Per� puoi andare sul secondario, fare un fsck e ricominciare da l� :-)


 Per puoi andare sul secondario, fare un fsck e ricominciare da l :-)
Hai ragione è vero, io in effetti l'ho sempre implementato così però
siccome l'ho fatto un bel pò di tempo non mi ricordavo più
esattamente.
Verissimo il drbd non switcha nulla ma mantiene (per quello che può)
la consistenza, allo switch ci pensa lo strato di HA. E giustamente
ora tutto torna. Quindi pare che con le ultime release sia anche in
grado di porre rimedio ad eventuali fail dell'hw inoltrando le
chiamate di I/O via rete al "nodo buono".

 chiamate di I/O via rete al "nodo buono".
Esatto. Ma č leeeeeento. (eee eee eee eee eee a piacere)


 però devo poter migrare il tutto tra i due nodi senza interruzione.
Ok,
il low cost è cosa buona e giusta, sapessi quante volte per mettere in
piedi ambienti di test/sviluppo ho fatto il mc.gyver della situazione
andando a ravanare in quello che noi chiamiamo "il cimitero degli
elefanti" per recuperare robaccia dismessa e mettere in piedi dei veri
frankenstin server!
Quindi Tu hai due VHost tra cui poter migrare in caso di necessità i
vari guest-os e su queste stesse due macchine vorresti infilare i vari
dischi da usare come storage, oppure hai altre 2 macchine da dedicare
allo storage? No perché nel secondo caso potresti pensare ad una
soluzione alternativa che a mio avviso ti semplificherebbe di molto le
cose.

 però devo poter migrare il tutto tra i due nodi senza interruzione.
Ok,




debd serve per fare mirroring via rete, stando alla documentazione, non 
per sostituire un bel controller RAID (purtroppo).
Se devi usarlo in ambienti di poco conto puoi fare tutte le porcate che 
vuoi ma, secondo me, rischi di fare un gran bel casino di roba 
ingestibile.
Poi è lapalissiano che puoi fare tutte le cose che ti saltano in mente 
con la tua roba.

 cose.
Ho 4 macchine in tutto.
Due sono due nodi XenServer, e le altre due diventeranno lo storage.

 per sostituire un bel controller RAID (purtroppo).
E' esattamente quel che voglio fare.
Mirroring via rete. Proprio perchè c'è DRBD che mirrora
via rete mi stavo chiedendo se fosse possibile evitare
un ulteriore mirror (raid) locale che sembrerebbe superfluo.
Sarebbe come mettere in RAID1 due volumi già esportati in RAID1.

 Sarebbe come mettere in RAID1 due volumi già esportati in RAID1.
Col cacchio.
Se salta un disco locale, stai usando il corrispondente del nodo remoto;
se per funzionalità è "la stessa cosa", non lo è per svariati altri
fattori, primo tra tutti la prestazione.
Per funzionare non dubito che funzioni, ma mi allineo a Max nel
considerare la soluzione tafazziana.
Al limite, farei un bel volume RAID0 con tutti i dischi e metterei in
(unico) drbd quello.
Almeno ottieni un "tutto o nulla", ben meno problematico da gestire.
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 Almeno ottieni un "tutto o nulla", ben meno problematico da gestire.
Per� in caso di rottura di un disco devi sincronizzare tutto e in pi�
se si rompe un disco di qua e di l� sei a piedi.
Io pure ho in produzione dei raid0 sicronizzati con drbd, ma l'idea
di Gandalf non mi sembra poi male. Tu perch� la scarti?


 di Gandalf non mi sembra poi male. Tu perché la scarti?
Perchè vedo -di nuovo- piuttosto problematica da gestire una situazione
in cui un volume è composto di dischi assunti locali ma che in realtà
non si sa dove stanno.
IMHO, le cose che funzionano bene sono quelle semplici e lineari.
Fare i castelli ha sempre portato solo danni, prima o poi, a tutti
quelli cui l'ho visto fare...


 quelli cui l'ho visto fare...
Anche questo è vero :-)
Però nel caso esposto è proprio una cosa da due minuti (escludendo
il tempo di sincronia, ovvio). Qualche file in /etc/drbd.d da copiare
identico sull'altro server, un colpo di nano (non pensate male...) a
/etc/lvm/lvm.conf, 6 pvcreate e un vgcreate.
Se Gandalf ha un po' di tempo potrebbe provare a farlo e, a sincronia
terminata, fare qualche benchmark e qualche crash test, come
esperienza da condividere.
Poi pialla tutto e fa un raid5 :-)


 Poi pialla tutto e fa un raid5 :-)
Non ho modo, non da qui a breve.
I server di storage sono attualmente in uso, prima li
devo liberare e non è cosa semplice che posso fare entro breve.
Devo attendere la scadenza del contratto di alcuni clienti.

 Devo attendere la scadenza del contratto di alcuni clienti.
Casomai mi si dovessero liberare un po' di dischi faccio qualche
prova io e posto.
