Newsgroup: it.comp.os.linux.sys
Titolo: Virtualizzazione: SAN, iSCSI e XEN

Apro un altro thread rispetto all'originale di twistedbrain perchè
l'argomento è un po' diverso.
Considerando che sono un niubbo completo di SAN e virtualizzazione, volevo
fare un po' di prove a "basso costo", per cui pensavo di montare un SAN
iSCSI con OpenFiler da cui poi le macchine con Xen andrebbero a succhiare
le immagini delle VM.
Ora, un po' di domande: funziona bene sto SCSI su IP e ethernet? altre
soluzioni che non implichino l'uso di costosissima fibra che funzionino
bene con xen?
è vero che un LUN SCSI può essere montato solo da una macchina? come
funziona se ho più host xen che devono accedere alla stessa virtual machine
che quindi risiede sullo stesso LUN dello stesso SAN?
le performance su un ethernet gigabit sono accettabili?
altre soluzioni per montare il SAN che non sia Openfiler? se dovesse essere
qualcosa HW e *senza* fibra cosa consigliereste?
-- 
Vide
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

 le immagini delle VM.
Essendo prove a basso costo, perche' non metti tutto su NAS?

 qualcosa HW e *senza* fibra cosa consigliereste?
Parlano abbastanza bene di AoE (ATA over Ethernet). Il concetto è lo
stesso di iSCSI, più o meno, ma anzichè avere SCSI su TCP su IP si
Ethernet, hai ATA su Ethernet e fine.
Pro:
- è una cosa sufficientemente leggera da permettere prestazioni di tutto
rispetto senza l'uso di schede dedicate che si occupino
dell'encapsulation in HW
- il supporto al protocollo dovrebbe essere già presente nei kernel
vanilla da un po', e il produttore fornisce i driver per altri OS.
- costa molto poco, rispetto alle altre soluzioni
Contro:
- poichè non fa uso di protocollo L3, non è routabile, la SAN deve
quindi essere connessa a L2 con gli host
- a quanto ne so c'è un unico produttore: 
http://www.coraid.com/
- non ho idea di quali funzionalità permette 'sto oggetto, in
particolare per quanto riguarda il masking delle risorse (forse sulla
base del MAC può far qualcosa).
Se dovessi decidere di provare uno di 'sti cosi, ti pregherei di farmi
avere i tuoi feedback sull'oggetto...
-- 
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.

 Essendo prove a basso costo, perche' non metti tutto su NAS?
Perchè prima o poi dovrà andare in produzione :P e meno ho a che fare con
NFS meglio è...per passate esperienze.
Con qualcosa tipo questo
http://www.dell.com/content/products/productdetails.aspx/pvaul_ax150?c=us&cs=555&l=en&s=biz&~section=specs#tabtop
e OpenFiler dovrei tirare su tutto senza troppi problemi, mi immagino.
Restano però le domande del messaggio d'apertura...
Chiarificando: la gente che monta Xen con immagini su storage esterno, come
lo fanno? SAN? se sì, che problemi ci sono? NAS? e in questo caso che
problematiche esistono?
Insomma, mi sto guardando in giro e più o meno penso di aver capito come
funziona il tutto, però vorrei pareri di gente reale che già si sia
sporcata le mani con 'sti arnesi :P


 avere i tuoi feedback sull'oggetto...
Ci mancherebbe! A te oltre che feedback dovrei pagarti una notevole scorta
di caffè ;D


 di caffè ;D
Duh?!? O_o


 Duh?!? O_o
Nel senso che mi hai dato tanti aiuti utili fin'ora (e non solo in questo
thread/NG) che ci mancherebbe altro che non ti dessi feedback su una cosa
che ti interessa! :)


 sporcata le mani con 'sti arnesi :P
Per quanto riguarda Xen, nel giro di un paio di settimane mi ci devo 
sporcare pure io, quindi ti sapro' dire, e tali pareri fanno comodo 
anche a me ;)

 un NAS come suggeriva nemesis?
Tecnicamente credo di si, ma tecnologicamente NAS ha di solito limiti
(di prestazione, quando non di altro) nella gestione di file grossi (e
le immagini di cui sopra non sono piccole), e nelle latenze introdotte
dal filesystem di rete che sta tra l'applicazione (la VM, in questo
caso) e l'I/O sullo storage "vero"...
Non saprei se i limiti sono però significativi per l'utilizzo che ne
vorresti fare; l'unica è provarci...


 Sicuramente ti scordi il vmotion (migrazione a caldo di VMWare), poi
Mica vero:
xm common subcommands:
   [...]
   migrate <DomId> <Host>           Migrate a domain to another machine
Come detto in altro thread, attualmente "vale" solo per host
paravirtualized, ma dovrebbe essere imminente il rilascio del supporto
alla migrazione di domini HVM.


 le performance su un ethernet gigabit sono accettabili?
Bho, dipende dal tuo concetto di accettabile. Comunque in genere non molto,
considera che una macchina virtuale ha partizioni remote.
-- 
Per rispondermi, togli il nome del poeta

 obbligatoriamente, altrimenti LVM o EVMS sopra un file system non cluster.
EVMS è cluster aware.


 la mia politica, voi come vi comportate? (tanto per confrontarsi)
Il problema delle prestazioni ce l'hai in base a quanto spesso scrivi e
quanto scrivi. Piccole scritture frequenti richiedono SAN, poche scritture
grosse vanno bene con NAS. A parte le specificità applicative, il primo
scoglio diventa quindi l'update dei metadati, per cui se proprio uno deve
usare NAS per immagini virtuali ha senso che studi cosa succede con noatime
e dintorni.


 effettivamente girano i dati che devono essere manipolati.
Si, ma allora quelli (i "dischi dati", intendo) dove li metti?
Dischi locali? E la ridondanza?
SAN? Ma allora, se ne hai una, perchè non mettere tutto lì?
Torni punto e a capo...


 avere i tuoi feedback sull'oggetto...
Ci sminchiettai all'epoca.
Per tua info, sia con iSCSI che con AoE puoi usare via software sia
il "client" che il "server" (con i loro nomi, initiator, host .... blah
blah).
Max

 chip VT/V per le CPU).
Più semplice, con Xen dai l'accesso al volume LVM.


 puo' contro le decisioni alte, ma questo e' un altro discorso.
La virtualizzazione ti fa risparmiare, ma non se devi gestire un solo
server. In quel caso usi heartbeat o simili e ti basta ed avanza.


 alla migrazione di domini HVM.
Non mi sono spiegato bene, intendevo che, parlando della soluzione NAS, 
un contro e' che ti scordi Vmotion (VMWare), mentre Live migration (Xen) 
dovrebbe funzionare.

 Più semplice, con Xen dai l'accesso al volume LVM.
Genericamente, ad un block device di storage, quindi (se ti vuoi del
male) anche direttamente ad una partizione fisica...
Cmq, credo nemesis intendesse l'accesso a device HW generici, non
necessariamente storage (questo Xen lo fa, anche se IMHO in maniera
arzigigolata e scarsamente flessibile, e non ho mai provato ad utilizzarlo).
Così puoi ad esempio dedicare una periferica HW (ES: un HBA) alla
singola VM, che in tal modo gode di un accesso diretto allo storage, ad
essa dedicato, senza l'overhead dato dalla virtualizzazione dell'accesso
ai device[1].
Questo permette di elevare le prestazioni in I/O di architetture
pesantemente virtualizzate, e di slegare le risorse di I/O delle VM
dalla macchina reale.
Attualmente c'è infatti il limite che sistemi facilmente virtualizzabili
per via dello scarso uso di risorse CPU in realtà non li puoi
virtualizzare perchè l'aggregato di I/O generato dalle singole VM è
superiore alla banda disponibile in direzione dello storage.
Però non vedo come questa funzionalità possa in qualche modo ridurre il
costo dell'infrastruttura di storage, anzi...[2]
E' quindi la soluzione ad un altro problema, IMHO...
[1] L'accesso che Xen permette al block device consente un overhead
minore rispetto ai device loop, ma comunque un overhead c'è, paragonato
all'accesso diretto allo storage...
[2]Probabilmente, invece, sarebbe interessante sapere come si comportano
le VM nell'accesso a storage condiviso tramite AoE: lì non hai device HW
da esportare alla VM, dato che tutto viene fatto via software, quindi
dovrebbe essere possibile farlo già attualmente...


 blah).
Si, ho presente.
Più che un feedback su AoE, volevo feedback proprio su quell'oggettino
della Coraid...


 caso) e l'I/O sullo storage "vero"...
Ok, SAN allora, prima proverò con iSCSI e se va male allora AoE. Le aggiunte
hardware come HBA credo che saranno l'ultimo tentativo.


 dovrebbe essere possibile farlo già attualmente...
Hai un device, inteso come /dev/qualcosa, e su cui scrivi comunque come su
qualsiasi altro device, ovvero hypercall, quindi hai comunque un problema di
prestazioni.


 prestazioni.
Probabilmente un overhead si pone, ma le prestazioni IMHO dovrebbero
allinearsi in tutto e per tutto con quelle ottenibili dal dom0, dato che
non vi sarebbe alcuna differenza operativa tra il modo in cui si trovano
a gestire il device.
Viceversa, nel caso di LVM/block_device, ci sono operazioni di
"mascheramento" dell'hardware reale che Xen deve operare nel mezzo, e
che IMHO non possono che causare ulteriore overhead (con file/loop,
peggio ancora ovviamente).


 "mascheramento" dell'hardware reale che Xen deve operare nel mezzo
Accedere a /dev/mapper/nome è inefficiente quanto accedere a /dev/hda, non
cambia niente, perchè il mapper rimappa accessi ai suoi blocchi come accessi
ai device, non ci sono due operazioni di I/O invece di una. Altrimenti
sarebbe inefficiente usare i volumi su sistemi reali.


 sarebbe inefficiente usare i volumi su sistemi reali.
Non so, presumo tu conosca meglio di me i dettagli di xen al riguardo,
ma ho l'impressione che parliamo di due cose diverse.
Quello che intendo non è sottolineare una presunta inefficienza
nell'accesso ad un LVM rispetto alla partizione "secca".
Intendo sottolineare che se Xen deve mostrare una partizione (o un
volume logico, o peggio ancora un file) come se fosse un disco intero,
collegato per tramite di un controller che il domU non sa nemmeno
esistere, del lavoro di emulazione nei confronti del domU lo deve pur
fare, in particolare liddove l'OS in domU gira in HVM anzichè in
paravirtualizzazione, e quindi nulla sa o deve sapere riguardo
l'esistenza stessa di xen.
Se invece il domU "vede direttamente" il controller (o, ancor più, nel
caso di AoE,  non vi è alcun controller in quanto tutto è affidato ad un
driver, e quindi alla *CPU*, che non è emulata), questo strato
intermedio di cui xen si deve far carico non c'è, e le prestazioni
dell'I/O tra dom0 e domU (credo) si pareggiano.
Magari ci son dettagli che mi sfuggono, e che rendono ciò irrilevante in
termini numerici, ma questo probabilmente comporta delle differenze in
termini di prestazioni, tra l'uso diretto dello storage da parte di domU
e l'uso di storage esportato da dom0...


 dell'I/O tra dom0 e domU (credo) si pareggiano.
Questa linea di ragionamento è interessante, ma mi viene da pensare che un
driver opera spesso con istruzioni privilegiate, quindi non avresti perdite
di prestazioni con driver in userspace, ma solo perchè sarebbe lento anche
in un ambito non virtualizzato, quindi avresti livellato verso il basso.
