Newsgroup: it.comp.os.linux.sys
Titolo: Da RAID-6 a RAIDZ-2

Devo rimpiazzare, pian piano, dei server.
Sono *tutti* con RAID-6 hardware (6x SAS 15K 300GB), 
li farò tutti con RAIDZ-2 (SSD 400GB/480GB), per vari motivi.
 
Lo spazio non è un problema, posso, tecnicamente, passare da
6x300GB a 4x400GB passando di fatto da 1200GB a 800GB usabili.
 
I nuovi server avranno 10 slot per dischi, quindi oltre a poter
rimpiazzare, in futuro, i dischi 1 ad 1 nel caso servisse più
spazio, potrò comunque aggiungere altri 4 dischi in RAIDZ-2
 
Il problema è la sicurezza dei dati, come ormai è noto, ho avuto
non pochi problemi con controller hardware con conseguente perdite
di dati a ripetazione (vuoi per dischi RAID-1/RAID-10 con entrambi
i dischi del mirror rotti a breve distanza (ore se non minuti), vuoi
per controller che sgancia 4 dischi su 6 in un RAID-6 in meno di 1 ora, etc)
pertanto non prendo minimamente in considerazione tutto ciò che ha 1 solo
disco come ridondanza (RAID-1, RAID-5, RAID-10, RAID-50, ...)
 
Visto che con ZFS non è possibile variare la geometria di un RAIDZ, ovvero
se parto a 4 dischi, resto a 4 dischi (salvo aggiungere ulteriori RAID ad
al pool), come suggerite di procedere?
 
Parto con RAIDZ-2 a 4dischi, affiancandone un altro in caso di necessità?
Parto a 5 o 6 dischi ?
 
Performance: appurato che i server attuali sono RAID6 con SAS 15k e le
performance attuali sono accettabili, qualunque sia la configurazione
finale tramite SSD, non potrà mai essere più lenta di quella attuale, quindi
una configurazione vale l'altra. Volendo potrei anche azzardare un RAIDZ-3,
sarebbe comunque più veloce del RAID6 hardware attuale, in termini di IOPS
 
Vorrei solo tenere bassi i costi senza pregiudicare troppo l'espandibilità.
Un mirror a 3 dischi con ZFS è fattibile, ma costa molto più di un RAIDZ-2, anche
se mi permette di partire con soli 3 dischi ed espanderlo al bisogno, ma dovrebbe
essere anche più lento, obbligando 3 scritture complete su tutti i dischi anzichè
1/3 su 3 dischi più le due parità (tutto in parallelo) come nel caso di RAIDZ-2 a 5 dischi.
Gli SSD non avendo praticamente latenza e testine da spostare dovrebbero riuscire
a scrivere più velocemente 10MB rispetto a 30MB (per rendere l'idea)
 
Qualcuno qui dentro usa RAIDZ ? Quali sono i tempi di resilvering e con quale 
dimensione del pool ?
 
P.S: c'è da valutare un altra cosa: usare molti dischi mi obbliga ad usare
chassis con parecchi slot. Mi è capitato, l'ultima volta proprio il 28 dicembre,
di dover sostituire brutalmente un server che non si è più riacceso dopo un
reboot di routine. Grazie a dio aveva solo 1 mirror (software) a 3 vie, quindi 3 
dischi, e son riuscito a rimetterlo su un server da 4 slot, unico che avevo in
casa. (il 29 son riuscito partito per le ferie)
 
P.P.S: con il tempo ho imparato, nel peggiore dei modi, che avere slot liberi
per aggiungere i dischi è sempre un bene. Sempre. 
Partire con 10 dischi su un server a 10 slot è una cazzata stratosferica, al minimo
problema, e me ne son capitati di parecchi tutti in successione, son fottuto.
 

 problema, e me ne son capitati di parecchi tutti in successione, son fottuto.
 
mi pare che tu sia abbastanza sfigato :P
 
Ciao Jack

 mi pare che tu sia abbastanza sfigato :P
 
Si, molto. Per questo odio il raid hardware.

 mi pare che tu sia abbastanza sfigato :P > > Si, molto. Per questo odio il
raid hardware.
 
Ciao Jack -- Yoda of Borg am I! Assimilated shall you be! Futile
resistance is, hmm?

 impiegano circa 24 ore a terminare il rebuild di un RAID-6
 
Penso che tu stia parlando di un rebuild con filesystem in uso (anche 
perchè dal resto del post mi pare chiaro che non puoi spegnere database 
e vm). Immagino quindi che il tempo sia fortemente dipendente dal carico 
di lavoro (o da eventuali limiti di velocità sul rebuild).
 
Dico questo perchè sul mio raid6 casalingo si è appena rotto un disco 
(raid6 software con mdadm su 6*4TB sata3) messi in rebuild alla notte li 
ho trovati completati al ritorno dal lavoro la sera dopo. Non ho 
guardato il tempo esatto, ma certamente meno di 15 ore (a filesystem 
smontato e dopo aver avuto cura di eliminare il limite di velocità sul 
resync).
L'unico motivo che ti può fare impiegare così tanto per sincronizzare 
dischi più piccoli ma più veloci su un hardware nettamente migliore del 
mio e che i dischi stanno facendo anche altro oppure hai un limite di 
velocità attivo.
 
Nel mio caso credo in realtà che abbia impiegato attorno alle 6 ore. 
però la sera dopo quando ho controllato ero troppo stanco per aver 
passato parte della notte a svuotare un disco da 4TB per utilizzarlo 
come rimpiazzo e ho i ricordi confusi.
 
Secondo me il tempo di resync dovrebbe essere inferiore al tempo di 
scrittura di un singolo intero disco per raid6-mdadm. Mentre per raidz2
dovrebbe essere inferiore perchè non viene sincronizzato tutto ma solo 
lo spazio utilizzato. Quindi ipotizzando un fs pieno al 50% dovrebbe 
essere inferiore alla scrittura di metà di un singolo disco
 
Sto pensando di passare anche io a zfs in raidz2. Però ho notato che non 
segue bene la regola: (dischi-2)*spazio.
un raidz2 su 8*4TB perde 1.8TB rispetto alla configurazione 
raid6(mdadm)+btrfs che voglio sostituire perche btrfs mi ha dato qualche 
problema di troppo.
 
rispetto allo spazio la configurazione migliore è: raid6(mdadm)+btrfs
 
BESTSPACE        = raid6(mdadm)+btrfs
raid6(mdadm)+zfs = BESTSPACE -0.7TB
raidz2           = BESTSPACE -1.8TB
valutazione fatta con ashift=9 e non 12 per guadagnare un po' di spazio.
la velocità rimane spettacolare nonostante ashift=9

 > huh? Un RAIDZ2 di 4 dischi ti costa esattamente uguale quanto un doppio
 > mirror.
 
Volendo costa anche meno perché rispetto a raidz2 ha una resa migliore 
nell'utilizzo dello spazio e ti garantisce qualche mega in più.
Però:
A+B raid0\
C+D raid0 \Il tutto in raid1
Se si rompe (A e B) oppure (C e D) Ti salvi
Ma se si rompe (A e C) oppure (B e D) devi contare sul backup
 
mentre A+B+C+D in Raidz2 (o raid6) ti salvi qualsiasi sia la coppia di 
dischi che si rompe.
 
 > e allora duplica il server. perche' la donna delle pulizie che rovescia
 > per sbaglio il secchio dell'acqua sul server puo' sempre capitare ;)
 
sgrat sgrat :-)
 
Comunque mi è capitato uno scaldabagno rapido montato sopra un server 
perchè all'idraulico deve essere sembrato il posto più adatto. A parte 
la posizione molto discutibile, non deve aver fatto nemmeno un ottimo 
lavoro visto che dopo appena una settimana da un raccordo partiva uno 
spruzzo d'acqua.
Fortuna a voluto che lo spruzzo fosse diretto contro dei cavi di rete e 
l'acqua li ha seguiti fino ad uno switch e ha reso instabile la rete. 
Quando ho suggerito all'impiegata di andare a vedere se la luce 
corrispondente alla sua presa era accesa il danno è stato scoperto prima 
che facesse un disastro.
Comunque anche se si è rotto solo uno switch c'è stato una giornata di 
fermo per reintestare alcuni cavi di rete, sostituirne altri, ma 
soprattutto per asciugare la scheda madre del server.
Ha bassa tensione le schede per un po' riescono a funzionare anche se 
sono bagnate. Purchè sia pulita la conduttività dell'acqua è piuttosto 
bassa, però se una scheda bagnata rimane in tensione si ha una 
migrazione del rame (elettrolisi) fra le zone a polarità opposta. Il 
rame e le altre impurità che si sciolgono in acqua e ne aumentano la 
conduttività fino a far saltare qualcosa.
 
Sono passati 2 anni dal disastro e il server funziona ancora però alcuni 
mesi dopo abbiamo dovuto aggiungere una scheda di rete perchè la sua si 
è guastata. Il fatto che l'acqua fosse entrata sulla scheda madre 
seguendo il cavo di rete potrebbe aver favorito il guasto.
 

 dimensione del pool ?
 
Uso un RAIDZ1 a casa, su dischi da 1Tb, i tempi sono di circa 5 ore, ma non
penso che sia molto attendibile (è un HP MicroServer Gen8) :)
 
Enrico

 Pero' ha fatto solo quello, non aveva utenti collegati ecc.
 
Ah grazie allora...........

 seguendo il cavo di rete potrebbe aver favorito il guasto.
 
Non ne vedo il problema, anzi, è un plus, la gente paga per questo.
Hai un server con raffreddamento a liquido. Puoi farci i videogiochi.

 zpool add tank raidz2 sdf sdg sdh sdi
 
Ed in pratica hai fatto ciò che ho scritto: hai aggiunto un raid ad un raid.
Essendo entrambi raidz2, la tua seconda aggiunta ti è costata 4 dischi per
averne usabili solo 2.
 
Io intendevo aggiungere *UN* disco ad un raidz2 esistente, come si fa con mdadm,
ma non si può fare su ZFS causa COW, dicono, perchè dovrebbero riallocare i dati
riscrivendoli, cosa non prevista dal filesystem. 
 
Che poi mi sa di cazzata, perchè basterebbe non riallocare nulla 
(salvo sovrascritture) e variare la geometria solo dei nuovi dati
 
In pratica ciò che esiste, resta splittato su 2 dischi con 2 parità (A1, A2, AP1, AP2),
i nuovi file vengono splittati su 3 dischi con due parità (A1, A2, A3, AP1, AP2)
 
Quando un vecchio file viene sovrascritto, lo si salva a 3 dischi.
 
 

 (salvo sovrascritture) e variare la geometria solo dei nuovi dati
 
Praticamente quello che fa ora quando espandi il pool con altri vdev ;)
Il problema è che probabilmente sarebbe pure facile implementare la cosa,
ma per ora lo sviluppo di ZFS è fermo ed incerto (l'unica cosa di certa è
che già così è talmente avanti che prima che venga creato un altro sistema che
può veramente soppiantarlo ci vorranno ancora parecchi anni)
 
Enrico

 può veramente soppiantarlo ci vorranno ancora parecchi anni)
 
Fermo? Su github vedo commit recenti. Probabilmente le nuove funzioni non sono più implementate, ma i bugfix credo vengano risolti (me lo auguro)
 
Leggevo in giro che non è semplice implementare l'espansione di un RAIDZ proprio a causa del COW caratteristico di ZFS

 Devo rimpiazzare, pian piano, dei server.
 
Cosa devi farci con questi server? Solo storage?
 
Pensa anche a una soluzione di 'Software Defined Storage', io ti consiglio
Ceph...
 
-- 
  Documentation is like sex: when it is good, it is very, very good; and
  when it is bad, it is better than nothing.
  (from texinfo documentation)				Dick Brandon

 proprio a causa del COW caratteristico di ZFS
 
Beh, l'attività di reshaping di mdadm presumo che consista nel ripartizionare i
blocchi dell'array in tutti i dischi che ne fanno parte, in ZFS è un po'
differente perché non ragiona totalmente a blocchi
 
Enrico

 Ceph...
 
L'SDS, nel mio caso Gluster, è un progetto a parte.
I server in questione saranno, in futuro, collegati a Gluster e le VM migrate
su tale storage, ma non è un progetto a breve termine e fino ad allora devo
configurarmi un buon RAID.