Newsgroup: it.comp.os.linux.sys
Titolo: Storage per KVM

Buonasera,
 
gradirei un vostro aiuto di massima su alcuni aspetti relativi al 
storage provisioning per KVM.
 
Fin'ora qui le cose funzionano così:
- server fisici in produzione senza alcuna virtualizzazione basati su 
normali server 2U (per la precisione Dell Poweredge, dai vetusti 2850 
agli attuali R730)
- quando lo spazio sta per terminare affianco dei NAS (sempre Dell 
Poweredge magari con dischi NLSAS) che esportano share NFS
- copia/spostamento dello storico dati sul NAS
 
Questa procedura, seppur macchinosa e del tutto manuale, mi permette di 
usare hw comune, e di tenere i dati vivi sul server principale (con 
buone/ottime prestazioni) ed avere lo storico online su hw meno 
prestante. In caso di guasto dei NAS non c'è nessun blocco del servizio 
sui dati "vivi". Posso agire con tempi più laschi per ripristinare lo 
storico. Alla fine della fiera i dati si trovano sempre su un ext3/4 e, 
sebbene si potrebbe opinare, mi sento relativamente al sicuro (evito le 
complicazioni di un DRBD, GlutserFS, Cepth et similia).
 
Ed ora introduciamo la virtualizzazione sui server principali, KVM per 
l'appunto su base RHEL/Centos 7.x
 
Come storage opto per lvm, poiché dovrebbe offrire prestazioni migliori 
e posso creare le partizioni dati (quelle prive di MBR/GPT) 
direttamente su lv dedicati. Semmai (o meglio quando) il guest dovesse 
perdere il senno, posso sempre montare, come estrema ratio, il fs 
(ext3/4 forse XFS) direttamente dall'host (senza giocare con kpartx, 
offset, ecc ...). Non mi serve e non è applicabile per altri fattori la 
live migration.
 
Riguardo ai NAS che faccio? Un vocina nella mia testa mi dice di 
continuare con export NFS verso, in questo caso, i guest per quanto 
detto sopra.
 
In alternativa potrei istanziare dei target ISCSI, trasformando di 
fatto i NAS in delle economiche SAN, ma non vi trovo particolari 
vantaggi nello scenario specifico. Potrei ad esempio esportare block 
device per estendere gli lv dell'host principale, ma mi sembra di 
"mettere il culo nelle pedate".
 
Qualche consiglio in merito? Dovrei valutare altri sistemi di tiered 
storage? Non dispongo di FC ne di 10G.
 
Grazie.
 
 
-- 
Gabriele
 

 (evito le complicazioni di un DRBD, GlutserFS, Cepth et similia).
 
Stop: GlusterFS, salvo sharding, gestisce i file "in chiaro", tolto la configurazione inizile, se tutto dovesse andare a puttane, i file sul server li leggi normalmente come se niente fosse. Si configura in 4-5 minuti (non scherzo) partendo da zero. Non lo classificherei come "complicazione", a differenza di Ceph.

 storage? Non dispongo di FC ne di 10G.
 
hai fatto le domande, ma ti sei anche dato parecchie risposte (non ti 
serve la live migration, non ti piace ceph, una vocina ti dice di usare 
NFS, esportare i block device ti sembra come esportare il culo sulle 
pedate, secondo te il NAS è più fragile di un server qualsiasi) e così 
diventa difficile risponderti. 
 
In sostanza stai dicendo che hai quel che hai, ma che non la cambieresti 
per nulla al mondo. Se per te il downtime non è un problema, se per te va 
bene spegnere 30 server virtuali per cambiare una RAM, se a te stanno bene 
le prestazioni che hai... be, tieniti tutto così com'è :) 
 
Forse varrebbe la pena di descrivere un attimo il tuo ambiente. 
una cinquantina di server? Un migliaio? Se parliamo di migliaio, consiglio 
di partire innanzitutto con un framewaork per la virtualizzazione (sotto 
avrai sempre kvm, xen...), tipo openstack, cloudtack, con i tool di 
orchestration, cloud formation. Poi ti guardi la documentazione e vedi 
cosa suggeriscono per lo storage (ceph è molto trend in questo momento). 
 
-- 
Massimiliano Adamo

 una cinquantina di server? Un migliaio?
 
Hai perfettamente ragione. No i miei numeri sono molto più bassi, 
attualmente il prodotto è composto da alcuni (pochi) componenti:
- application server
- db server
- file server (con eventuali nas)
- alcuni server di "acquisizione dati"
 
Come vedi si parla di neanche una decina di funzionalità, che a seconda 
del carico di lavoro possono colassare su un'unico server, o nel caso 
peggiore, hanno il loro host dedicato. Questa soluzione viene poi 
replicata indipendentemente per qualche decina di volte su vari clienti.
I server di acquisizione dati, fanno uso di schede proprietarie, 
pertanto, almeno per loro non è possibile fisicamente la live migration.
Da una decina di anni il prodotto dal punto di vista sistemistico non 
ha subito grossi stravolgimenti, e si è dimostrato sufficientemente 
stabile e semplice da gestire (pregio non da poco).
In questo lasso di tempo ci sono stati ovviamente vari quasti, quelli 
gravi sono stati sempre risolti con un politica di ridondanza nodo 
attivo - nodo in standby di tipo manuale (vedi sempre la presenza delle 
schede di acquiszione dati). Si riesce a gestire la cosa con fermi che 
vanno da pochi minuti a qualche ora nei casi più impervi.
Avessi adoperato un teconologia di clustering, avrei dovuto usare 
almeno un server in più per db/application/file server (3 nodi per un 
quorum affidabile) più altri due per ridondare anche i server di 
acquisizione. Insomma sarei dovuto passare da 2 a 5 server, onestamente 
impensabile.
 
Ora stiamo introducendo KVM, anche per mantenere con semplicità 
prodotti legacy, che non girerebbero nativamente sull'hardware oggi 
dispobiile sul mercato.
 
Ma ritorando al mio post iniziale, mi stavo chiedendo quale fosse il 
modo milgliore per etsendere lo sapzio utilizzato essenzialmente dal 
file server e gestire un tiering dei dati più vecchi. IMHO la soluzione 
migliore sarebbe la gestione a livello applicativo, ma oramai ho perso 
le speranze. Quindi rimane la via sistemistica.
 
 
 
-- 
Gabriele
 

 "complicazione", a differenza di Ceph.
 
Non metto mano su GlusterFS da almeno un anno o due. Dovrei riprenderlo 
e valutare bene la gestione delle situazioni di split brain.
 
Le prove all'epoca non mi lasciarono del tutto soddisfatto. Ricordo 
vagamente che per gestire, con perfomance soddisfacenti file piccoli, 
adottava una specie di db interno e questo non mi piacque affatto. 
Aveva poi dei problemi di locking per file grandi (in proposito ci 
scambiammo proprio qui qualche info in merito).
Probabilmente al giorno d'oggi sarà migliorato notevolmente, ed 
l'acquisizione da parte di RedHat penso non gli abbia fatto male ;).
 
Reindagherò nuovamente.
 
-- 
Gabriele
 

 ha 
scritto:
