Newsgroup: it.comp.os.linux.sys
Titolo: Xen Cluster con drbd e heartbeat

Ho diverse domande.
La prima, i 2 nodi sono Dell PE 6950 (4 processori dual core AMD
Opteron, 8 GB RAM),
Le macchine fisiche non arriveranno mai ad avere piu` di 16 GB e le
macchine virtuali contenute (indicativamente 3-4 Windows server e un
paio Linux) non arriveranno mai ad avere piu` di 4 GB di RAM l'una.
Per il sistema host mi conviene usare un'installazione di Linux a 64 o
32 bit? Per le VM 32 o 64?
Seconda. Per l'HA pensavo di usare drbd ed heartbeat con array raid10
di dischi delle 2 macchine SAS a 15000 rpm (fra parentesi sapete dove
se ne trovano nuovi a buon prezzo da 450 GB, hot swap?).
La domanda e` questa, con una distribuzione di Linux (magari SUSE, ma
anche altre) usare drbd con Xen non dovrebbe essere un problema, ma
con Xen di Citrix e` possibile o  ci sono altri modi (non Marathon,
troppo costoso) per raggiungere lo stesso risultato (HA)?
Dovendo usare Xen non Citrix esistono degli strumenti di
amministrazione di Xen (magari anche della parte HA) abbastabza user
friendly, flessibili, potenti e scriptabili?
Infine terza. Quando avevo visto queste cose (HA Linux) qualche anno
fa, heartbeat con
drbd per evitare situazioni splitted brain (quando i nodi del cluster
non riescono piu` a comunicare tra loro sulle eth tramite cui funziona
drbd) si sparavano in testa (uno all'altro) finche' non ne rimaneva
uno solo con stonith per
evitare il rischio di corrompere dei dati con 2 nodi attivi
contemporaneamente o di arrivare comunque a situazioni inconsistenti
con un po' di dati scritti di qua e un po' di la`. Per fare questo si
poteva
usare la comunicazione alternativa di heartbeat fra gli host (o
seriale o eth dedicata).
Ora il mio problema e` che i due nodi risiederebbero a circa 200 metri
uno dall'altro con possibilita` che una ruspa scriteriatamente guidata
tranci tutte le comunicazioni fra i due. A questo punto mi sembra
impossibile che heartbeat possa riuscire a spegnere uno dei due nodi
perche' non c'e` piu` nessuna comunicazione fra i due. Esistono dei
filesystem distribuiti stabili a livello di produzione per Linux che
permettano di gestire situazioni del genere risincronizzando
correttamente i dati fra i due nodi al ripristinarsi della connessione
fra di loro? So che e` possibile usare il dispositivo o device di
stonith meatware (ovvero intervento umano, che lascia la situazione
dei
nodi immutata per cui il secondario non diverrebbe primario alla
mancanza di comunicazione fra i due, ma resterebbe in attesa fino alla
risposta umana), pero` a questo punto mi sembra ridursi l'utilita` di
un
cluster HA. Inoltre, per dare la possibilita` di live migration di
macchine virtuali da un nodo all'altro, quando uno fallisce, credo che
drbd debba essere definito primary/primary su entrambi e in questa
situazione comunque la possibilita` di corruzione dei dati (scritti
contemporaneamente dati diversi sui 2 nodi, attivi e scollegati) ci
sarebbe. Qualcuno ha idea se sia possibile usare qualche meccanismo o
un
qualche tipo di filesystem in grado di rimediare a situazioni di
questo
tipo?

 tipo?
1. Heartbeat non supporta DRBD atcive/active (almeno fino alla 2.1.4, la 
3.0 non so)
2. Come già detto il problema non lo risolvi cambiando filesystem anche 
se ovviamente te ne serve uno cluster-aware, come GFS o Lustre
Quindi viste le tue necessità, se proprio vuoi la live migration ti 
consiglio di orientarti verso uno storage condiviso, magari ISCSI. Se 
puoi rinunciarci vai su Heartbeat che tanto in Xenserver non riuscirai 
mai a far fungere drbd.

 mai a far fungere drbd.
Sembra che non sia necessario rinunciarvi. La LINBIT commercializza
una soluzione
tutta basata su sw opensource (in primis drbd) che lo consente anche
se si fanno
pagare per l'installazione di 1 cluster 2 nodi di un giorno 10000 EUR
+ spese di
trasferta da Vienna.
Per i backup e` possibile fare snapshot consistenti tramite LVM?
Andrea

 Per i backup e` possibile fare snapshot consistenti tramite LVM?
Mettere LVM sopra DRBD è una procedura un pò laboriosa ma funziona, 
anche se non so in che termini impatti sulle performance.

 anche se non so in che termini impatti sulle performance.
Ed e` possibile mettere DRBD su LVM?
Insomma, prima di decidermi per quale soluzione scegliere credo che
dovro`
studiarmi un po' di documentazione sia di Xen Citrix (e in particolare
il pacchetto
Essential) e di drbd e del sito della LINBIT.
Certo che se per avere la soluzione basata su drbd dovessi pagare
10000 EUR
di consulenza, senza dubbio mi converrebbe quella di Citrix, se mi
garantisce
caratteristiche analoghe.
Andrea

 caratteristiche analoghe.
OK. La soluzione Citrix si basa su uno storage condiviso hw e quindi
non
e` solo il costo degli Essential, ma anche del box hw di storage
condiviso.
A questo punto direi che valga la pena di approfondire la soluzione
basata
su drbd e Xen magari con Debian o RedHat, dato che CentOS o
ScientificLinux
presentano dei vantaggi competitivi (prezzo) notevoli rispetto a RHE o
SUSE
Enterprise.
Andrea

 
Si, ed è decisamente più semplice che mettere LVM sopra drbd. 
Addirittura potresti fare (anche se non ha molto senso) LVM over DRBD 
over LVM.
 > Certo che se per avere la soluzione basata su drbd dovessi pagare
 > 10000 EUR
 > di consulenza, senza dubbio mi converrebbe quella di Citrix, se mi
 > garantisce
 > caratteristiche analoghe.
Il vantaggio della soluzione DRBD+HA è che non ti serve uno storage 
condiviso, anche se 10k E non sono pochi IMHO.
Se dovessi scegliere io restringerei a queste 2 opzioni:
1) Usi Citrix Xenserver col pacchetto Essential ma investi in una 
storage condiviso
2) Lasci perdere DRBD Active Active e fai una soluzione a 4 macchine:
2 con molta cpu e molta ram con l'Hypervisor e 2 di backend con molti 
dischi che esportano via NFS lo storage per le VM. Le 2 macchine di 
backend le metti in HA e replichi lo storage con DRBD A/P. Le altre 2 le 
ridondi con Heartbeat. In quel modo hai live migration e tutto il resto.

 Enterprise.
Dai anche un occhio a ganeti (
http://code.google.com/p/ganeti/
). Mai 
usato ma da quello che ho letto supporta DRBD, live-migration, ha e 
failover. Penso che vada usato al posto di heartbeat, ma hai il 
vantaggio di una soluzione integrata che gestisce tutte le feature.
Ciao

 10-15 K EUR di spesa
Si trovano anche a meno: se non sbaglio Hitachi fa SAN che costano anche 
6k.
Se poi hai una macchina vecchiotta, potresti provare a trasformarla in 
una SAN con Openfiler: so che non è una soluzione enterprise, ma so di 
gente che lo usa in produzione da diverso tempo senza grossi problemi.
-- 
"Le opinioni dei fanatici prescindono dai fatti"
python -c "print 'bG9ybWF5bmFAZ21haWwuY29t'.decode('base64')"
Linux Registered User: 461615

 gente che lo usa in produzione da diverso tempo senza grossi problemi.
2 Openfiler in HA con drbd e heartbeat su macchine con doppio
alimentatore e
memorie ECC mi sembrerebbero enterprise come livello di affidabilita`
e probabilmente quasi anche di prestazioni, ma i costi, dati i tipi di
macchine da
usare, i dischi (SAS 15000 rpm), controller, almeno 3 NIC GB (meglio
5: 2 bounded per
drbd fra i 2 nodi, 2 bounded per comunicare con i nodi di calcolo e 1
di heartbeat)  non
sarebbero cosi bassi. Diciamo che probabilmente riusciresti ad avere
un box esterno
di storage ridondato al prezzo di uno 
p.es
. della NetApp.
Comunque tutta roba che consuma, costa, si puo` rompere e deve essere
amministrata
in piu`.
Credo che cercero` di concentrarmi sulla soluzione a 2 nodi
comprensiva di
storage interno
Andrea

 storage interno
Valuta anche un DAS come il dell MD1000 a doppio controller in modalità
split. L'apparato è ridondato e puoi connettere due serverini openfiler.
ridondati con drbd. Se hai già due server in casa, non devi puntare a
macchine con grosse capacità di dischi interni, basta che abbiano
qualche giga disponibile per installare openfiler, i dati poi li metti
sul DAS...

 sul DAS...
Grazie

 Grazie
Prego.

 nodi attivi come master.... Brrrrr rabbrividisco...
Non era quello che intendevo, anche se venuta giu` la connessione
drbd,
heartbeat sull'altro canale, quello a lui esclusivamente dedicato,
dovrebbe
riuscire tramite stonith a freddare uno dei due nodi, evitando quindi
lo
splitted brain. Volevo solo dire che per la mia tranquilllita` vorrei
comunque usare
un canale di comunicazione diverso e indipendente, dedicato, per
heartbeat (non solo
quello, ma in piu`, in modo da averne sempre 2).
Andrea

 Si, ed � decisamente pi� semplice che mettere LVM sopra drbd.
Perch�?
Alla fine lvm su drbd � semplicemente un
drbdadm primary drbd0; lvscan; vgchange -a foo
Non mi pare mica problematico...
-- 
ValeRyo
CBR600F "Cerbero" - 
http://www.slimmit.com/go.asp?6YT
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 Non mi pare mica problematico...
Perchï¿œ 9 su 10 (almeno su debian e rhel) devi barbatruccare gli script 
di init per farsi i cazzi propri, sennï¿œ trovano comunque la signature 
LVM sul raw device del drbd e tentano di tirare su il volume.
Poi devi risbarbatruccare la conf di lvm con una regexp che gli dice di 
fare lo scan anche del device drbd.
Non ï¿œ problematico, ma di certo non ï¿œ immediato.

 di fare lo scan anche del device drbd.
Vero, per� poi posso avere uno/due/tre volumi drbd e non duemila
(uno per device lvm).
