linux user group brescia

immagine del castello

Archivio della mailing list

[LugBS] Xen: virtual storage per le virtual machines

Luca Coianiz luca a coianiz.it
Sab 16 Ott 2010 15:17:24 UTC
On Fri, 15 Oct 2010, Stefano Pedretti wrote:
> Credo tu abbia bisogno di tutti i layer, in quanto ognuno fornisce
> diverse funzionalita'. Non penso tu possa espandere (in ogni caso, hw
> o sw) lo spazio di un array raid 5 aggiungendo un disco senza
> ricostruire il tutto.

  Ahhhhh... gentilissimo!!! pensavo che la mia mail fosse caduta in /dev/null ed invece... :)

  Ti dirò... assemblando logicamente il tutto era parso anche a me che tutta quella robaccia ci volesse, per i vari motivi di 
espandibilità _E_ di indipendenza dei due livelli di storage (fisico e virtuale).
  Poi però, a "stack" assemblato, m'è un pò parso di star costruendo il duomo di Milano... o una torre di Pisa, moooolto 
pendente, e siccome l'aggeggio dovrebbe fornire prestazioni, magari non buone, ma soprattutto stabili per i prossimi 10 anni 
(almeno: l'altro server è ancora qui acceso, dal '98), volevo evitare "inutili colli di bottiglia" proprio perchè, avendo 
scelto Xen per il basso overhead, mi sembrava assurdo inserire qualcosa che _generasse_ overhead, se inutile.
  La tua conferma è un toccasana in questo senso: anch'io non vedevo molte alternative, ma non sono così esperto della cosa da 
poter dare un giudizio definitivo.

> L'unico spassionato consiglio che ti do e' quello di usare RAID
> hardware. Un controller 3ware entry level, ad esempio ti leva dagli
> impicci e ti impenna le prestazioni.

  Ecco... il fatto è che sto "fuggendo" dal RAID hardware: qualche anno fa avevo i dischi (stessa macchina) proprio su un 
controller 3ware e... mi si sono "distrutti" ben DUE dischi del RAID5 in contemporanea, rendendo inutilizzabile l'intero server.
(peraltro in un momentaccio: avevo bisogno estremo di quella macchina proprio quella sera e... ehm... credo che le bestemmie 
si siano sentite ben lontano)
  Peraltro i dischi andati erano quelli più pregiati (Seagate) e se ho recuperato qualcosa (praticamente tutto :)) lo devo 
invece a quelli meno pregiati (Maxtor) che avevo usato come backup (mount -> backup -> umount).

  Oltre al disegnone che hai visto, che tratta alla fine del solo storage principale (quello "operativo"), userò comunque 
ancora la 3ware per soli fini di backup, inserendo 4 dischi reduci dalla precedente esperienza (2 Seagate da 200 GB e 2 
Maxtor da 300 GB in RAID0/JBOD per un totale di 1 TB di backup[1]) secondo il principio che "non è possibile che mi si 
distrugga lo storage principale _E_ quello di backup nello stesso momento" (spero almeno).

> Per concludere, ci sono un sacco di FS (bizzarri come direbbe il
> gelma) un po' immaturi ma molto promettenti. Ad esempio la
> compressione trasparente (i.e. reiser4?) ti permetterebbe di fare
> quello che fai con gli sparse file in modo piu' efficacie.

  Vero. Mettila così: io sono per le cose "lente e stabili" piuttosto che per quelle "smart" ma che ti lasciano con il 
groviera in mano, nè mi diverto, una volta che l'installazione è stabile, a reinstallare e reinstallare (ad libitum). ;)
  Se dovessi scegliere un FS "un pò immaturo" in questo momento punterei verso Ext4. Il fatto di essere su Ext3 peraltro, se 
le cose funzionano come ai tempi di Ext2, potrebbe permettermi di passare ad Ext4 nel momento in cui sarà meno immaturo senza 
dover rifare tutto.
  Al di là di tutto: Ext3, pur con la limitazione della massima lunghezza dei file, mi ha permesso di gestire gli sparsefile 
senza problemi, quindi tecnicamente sono a posto _E_ con un FS di lungo corso (la limitazione nella lunghezza la gestisco via 
LVM, che dovrei comunque usare, per cui... ;)).

  Al momento mi sono un pò piantato sulla "necessità" di usare BLKTAP invece dei loop (per il mount dei file del disco 
virtuale come fossero dischi fisici) per questioni di performances: l'uso di BLKTAP riesce, ma solo nel senso che il sistema 
(1) non dà erorri e (2) Xen vede i dischi "assegnati" a BLKTAP... però poi non mi vengono creati i corrispondenti 
/dev/xda1..n da poter gestire via LVM (e _questo_ è un problema).
  Scorrendo la rete mi pare d'aver capito che il problema sia il mancato utilizzo di BLKTAP2 con Xen3.3... speriamo.

  Grazie comunque ancora per il supporto: in queste aree semi-sperimentali le conferme non sono mai abbastanza. :)

     LC


[1] peraltro devo ancora capire come 'sta scheda del demonio riesca ad assemblare 200+200+300+300 GB in un disco da... 780 GB 
-__-"  JBOD eh: mi aspettavo c.ca 1 TB ed invece... boh... ed il bello è che dice (suo BIOS) che tutti i dischi "stanno 
bene"... mah. Ora capisci perchè non mi fido del RAID hardware. ;)


Maggiori informazioni sulla lista Lug