Newsgroup: it.comp.os.linux.sys
Titolo: xen, LVM e SAN.

Vorrei configurare un sistema a bilanciamento di carico tra due server 
per delle virtual machines xen memorizzare in uno storage condiviso, 
nello specifico abbiamo una SAN.
Prima pero' vorrei avere un chiarimento:
i due server, che ospitano la dom0, condividono una stessa LUN da 1T.
Su tale LUN ho creato un Physical Volume, quindi un Volume Group e 
all'interno del VG diversi Logical Volumes, tanti quanti sono le 
macchine virtuali, ognuna, appunto, associata ad un LV.
Ogni server gestisce le proprie macchine virtuali, quindi server1 
gestisce xen1, xen2, e xen3, server2 gestisce xen4, e xen5.
Essendo la LUN condivisa tra i due server, con questa configurazione, 
potrei avere dei problemi?
E' vero che ogni server gestisce la proprie VM, ciascuna delle quali ha 
un suo LV, ma e' anche vero che ad una stessa LUN accedono due macchine 
diverse.
Grazie.


In linea teorica essendo i metadati lvm condivisi tra piu' nodi potresti 
avere problemi di corruzione.
In questi casi ( 1 lun lvm condivisa da piu' host) si usa clvm (cluster 
logical volume) per gestire il locking lvm.
In pratica, visto che lo hai fatto, sembrerebbe che non ci siano 
problemi, l'importante e' non avviare la stessa vm su ambedue i nodi.
Con questa configurazione dovrebbe funzionarti anche la live migration.
Ciao.


Non l'ho ancora fatto proprio perche' ho il dubbio che condividendo la 
stessa LUN lvm tra piu' nodi possa avere dei problemi.

 logical volume) per gestire il locking lvm.
Stavo legendo qualcosa su clvm, non lo avevo mai utilizzato.
Se non ho capito male pero' e' utile nel caso i vari LV debbano essere 
accessibili a entrambi i server.
Nel mio caso e' diverso, forse ho spiegato male.
Ho la LUN condivisa.
In essa ho diversi LV, uno per macchina virtuale e ciascun server 
gestisce le proprie VM.
Quindi non ci sono LV condivisi, e' solo la LUN, quindi il PV e quindi 
il VG ad essere condiviso tra i due server.

 il VG ad essere condiviso tra i due server.
Ad ogni modo ambedue i nodi vedono gli lv no ? indipendentemente dal 
fatto  che tu li usi o meno , se condividono lo stesso vg 
automaticamente gli lv in esso condivisi sono visti da entrambi i nodi, 
e quindi i metadati
lvm sono condivisi da entrambi i nodi.
Cmq una live migration di test puoi sempre farla :)
ciao.

 il VG ad essere condiviso tra i due server.
Il problema è un po' diverso.
Non c'è nessun problema ad usare LVM in ambiente clustered, finchè la
situazione dei volumi è completamente statica. L'accesso concorrente al
singolo PV/VG/LV è irrilevante.
Il problema è che quando uno dei nodi crea un nuovo LV, gli altri non ne
sanno nulla fino al successivo lvscan, perchè il nuovo LV /è scritto
"solamente sul disco"/.
Se hai già la LUN condivisa, lo vedi facile perchè, se sul primo nodo
esegui un lvcreate e sul secondo un lvdisplay, il secondo *non* ti
riporterà il LV appena creato sul primo.
Lo farà, se esegui un lvscan.
Se dal secondo nodo, però,  crei un secondo LV prima che il nodo sia
stato edotto dell'esistenza del LV creato dal primo nodo, accade che
probabilmente creerà un volume che "passa sopra" al primo LV, e ti
demolirà tutto.
CLVM ti serve per questo.
Potenzialmente, la puoi gestire comunque avendo l'accortezza di creare i
nuovi volumi sempre e solo da un nodo ben preciso (in modo da evitare
problematiche di concorrenzialità tra i nodi nella creazione di volumi)
e "sincronizzando" gli altri manualmente dopo ogni creazione, eseguendo
i relativi rescan.
Ma se i nodi fisici diventano molti diviene una pigna, e la cazzata è
sempre dietro l'angolo...
-- 
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/

Skull wrote:

I nodi che devo gestire sono due, al massimo diventeranno 3, avro' 
l'accortezza di creare tutti gli LV sempre dallo stesso nodo.
Intanto pero' mi documento su CLVM non lo avevo mai utilizzato prima.
Un software per cluster tipo heartbeat o pacemaker se non sbaglio non 
mi occorre nella mia situazione.
Avendo due nodi con Xen ciascuno dei quali gestisce le proprie VM, in 
entrambe i nodi ci copio le configurazioni di tutte le VM, se un nodo 
va giu' manualmente tiro' giu le VM da lui gestite e le faccio 
ripartire sull'altro nodo.
Il punto e' che se un nodo va giu' come faccio a stoppare le VM da lui 
gestite?
Resteranno per cosi' dire, appese?

 Resteranno per cosi' dire, appese?
Cosa intendi per 'va gi�'?
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
Napoli - appartamento in vendita: 
http://www.quisicasa.com
 


Nel senso se ha un problema, software o hardware per cui non e' 
possibile utilizzarlo.

 possibile utilizzarlo.
Se ha un problema di connettività all'esterno, ma continua a vedere
ed utilizzare i suoi dischi, non puoi toccare nulla.
Se invece la macchina crasha e smette di utilizzare i dischi dal punto
di vista della vm è come se l'avessi spenta di colpo, quindi quando
riparte ti serve un check dei dischi, dei db, di quel che è.


 Resteranno per cosi' dire, appese?
Se hai uno storage condiviso io tenderei ad usare un software di clustering.
La mia preferenza va su redhat cluster suite (free in centos ...)
con cui hai il supporto xen builtin.
Le conf che puoi fare sono 2, la prima, quella valida con la tua
conf (1 lun , 1vg, n lv tanti quanti sono le vm) e' la seguente:
1) usi clvm per gestire il lock degli lv
2) le vm sono risorse del cluster, e come tali possono essere live 
migrate, e riavviate in automatico a seguito di problemi su uno dei nodi.
Con questa conf ho avuto problemi, non so' se a causa dello storage
farlocco (era un sas) o per problemi di clvm.
Alla fine ho optato per questa conf:
1) 1 lun per ogni vm, con relativo vg + lv
2) halvm come risorsa del cluster per gestire la lun della vm
3) la solita risorsa vm
Con questa conf NON hai live migration, ma hai il vg lockato dal nodo 
xen che e' l'owner della vm.
Hai pero' la protezione ha.
A te la scelta.
ciao

Davide Bozzelli wrote:

Persona l'ignoranza ma se non posso migrare una VM su uno dei nodi a 
seguito di problemi nell'altro com'e' che ho l'HA.


Stavo per fare la stessa domanda.