Da RAID-6 a RAIDZ-2

[gandalf.co...@gmail.com]

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.

[Jack]

Il giorno lunedì 9 gennaio 2017 14:18:32 UTC+1, gandalf.co...@gmail.com ha scritto:
> 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

huh?

> Il problema è la sicurezza dei dati, come ormai è noto, ho avuto

eh. qui l'unica cosa e' BACKUP.
attaccaci (anche in rete) un disco bello capiente (anche lento) e snapshotta come se non ci fosse un domani (tanto con zfs send e recv puoi mandare i delta)

> 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?

mirror a tre dischi.
Nel server ti ci stanno 3 mirror piu' uno slot che puoi usare come hot spare (che se non ricordo se lo spare deve essere collegato al vdev o puo' essere collegato alla zpool, nel secondo caso sarebbe piu' comodo), o per il backup.

> Parto con RAIDZ-2 a 4dischi, affiancandone un altro in caso di necessità?
> Parto a 5 o 6 dischi ?

vedi sopra.
IMHO se ti serve sicurezza e espandibilita' i mirror sono la strada.

> 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.

ah ecco. nel 10mo slot ci metti un SSD piccolo con una camionata di IOPS e lo usi come L2ARC e ZIL.
Comunque un mirror e' piu' veloce in scrittura/lettura che un ZRAID, non deve perdere tempo a calcolare la parita'.

> Qualcuno qui dentro usa RAIDZ ? Quali sono i tempi di resilvering e con quale
> dimensione del pool ?

RAIDZ1, poll da 5 HD SATA da 3TB l'uno: resilvering ca. 1 ora/TB :D
Probabilmente con qualcosa di piu' performante di HP microserver ci metti qualcosa in meno.

> 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

eh dipende quanto vuoi essere sicuro di rimanere online, se un downtime di qualche ora e' accettabile allora uno stripe + un paio backup possono andare bene.
Se il downtime deve essere zero servono parecchi piu' dischi... (+ quelli di backup)

> 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.

mi pare che tu sia abbastanza sfigato :P

Ciao Jack

[gandalf.co...@gmail.com]

Il giorno lunedì 9 gennaio 2017 17:48:48 UTC+1, Jack ha scritto:
> huh?

Intendi la questione espandibilità?
ZFS non permette di aggiungere *un* disco ad un vdev con parità, tutto qui.

> eh. qui l'unica cosa e' BACKUP.
> attaccaci (anche in rete) un disco bello capiente (anche lento) e snapshotta come se non ci fosse un domani (tanto con zfs send e recv puoi mandare i delta)

Chiaro, ed è ciò che farò, usando proxmox, ci pensa già lui ad inviare snapshot incrementali in remoto.

Ma come puoi immaginare, un conto è avere un RAID con i controcazzi ed usare i
backup in caso di catastrofe, un altro è progettare il RAID alla pene di segugio
e dover far affidamento sui backup.

Non posso dire ai clienti: avete perso 1 giorno di dati perchè ho progettato male
la ridondanza del RAID.

Nel mio caso, il RAID deve essere online, sempre. Non posso far affidamento sul
backup per calcolare un livello RAID inferiore.

> mirror a tre dischi.
> Nel server ti ci stanno 3 mirror piu' uno slot che puoi usare come hot spare (che se non ricordo se lo spare deve essere collegato al vdev o puo' essere collegato alla zpool, nel secondo caso sarebbe piu' comodo), o per il backup.

Che costano molto di più di un RAIDZ2.
Gli hotspare, secondo me, non servono. Dato che il disco comunque lo devi
comprare, tanto vale tenerlo in funzione sempre pronto anzichè tenerlo
in standby (ma comunque alimentato, quindi prima o poi si spaccherà uguale e
stai pur certo che si spaccherà quando serve)

> vedi sopra.
> IMHO se ti serve sicurezza e espandibilita' i mirror sono la strada.

Espandibilità, si, ma sopratutto devo tenere bassi i costi.
Userò solo SSD, e buttarne via 2 alla volta (con un mirror a 3 vie) comincia
ad essere un po costoso.

> ah ecco. nel 10mo slot ci metti un SSD piccolo con una camionata di IOPS e lo usi come L2ARC e ZIL.
> Comunque un mirror e' piu' veloce in scrittura/lettura che un ZRAID, non deve perdere tempo a calcolare la parita'.

Su questa cosa ci sono molti pareri contrastanti.
A parte il calcolo della parità, che viene fatta dalla CPU (ed in questo caso ti
parlo di biprocessore esacore o superiore), la scrittura del dato in se per se,
su un RAIDZ dovrebbe essere più veloce, dovendo scrivere, in parallelo, 1/3

Se ho 30MB da scrivere, in un mirror a 3 vie ne devo scrivere 30+30+30 in parallelo.
Su un RAIDZ2 a 5 dischi, ne scrivo 10+10+10 (più parità negli altri due)

> RAIDZ1, poll da 5 HD SATA da 3TB l'uno: resilvering ca. 1 ora/TB :D
> Probabilmente con qualcosa di piu' performante di HP microserver ci metti qualcosa in meno.

Quanto pieno? Perchè il valore mi sembra spropositato.
Io ho impiegato 25 ore qualche giorno fa a ricostruire un RAID6 hardware
con dischi SAS da 600GB.

600GB in 25 ore.

no, non è un problema di server, *tutti* i miei server, configurazioni analoghe,
impiegano circa 24 ore a terminare il rebuild di un RAID-6

> eh dipende quanto vuoi essere sicuro di rimanere online, se un downtime di qualche ora e' accettabile allora uno stripe + un paio backup possono andare bene.
> Se il downtime deve essere zero servono parecchi piu' dischi... (+ quelli di backup)

Si tratta di VM e database, in questi casi il downtime può solo essere zero.
Non è un fileserver, dove in caso di guasto ripristino. Essendoci di mezzo
database e VM, il ripristino per aver perso l'intero pool deve essere considerata
"catastrofe", per questo ti ho scritto sopra che non posso considerare la ridondanza
in base al backup.

> mi pare che tu sia abbastanza sfigato :P

Si, molto. Per questo odio il raid hardware.

[Jack]

<gandalf.co...@gmail.com> wrote:

> Il giorno lunedì 9 gennaio 2017 17:48:48 UTC+1, Jack ha scritto: > huh?
>
> Intendi la questione espandibilità?

no, intendevo che non vedo l'utilita' di fare un RAIDZ2 con 4 dischi.

> ZFS non permette di aggiungere *un* disco ad un vdev con parità, tutto
> qui.
>
> > eh. qui l'unica cosa e' BACKUP. attaccaci (anche in rete) un disco bello
> > capiente (anche lento) e snapshotta come se non ci fosse un domani
> > (tanto con zfs send e recv puoi mandare i delta)
>
> Chiaro, ed è ciò che farò, usando proxmox, ci pensa già lui ad inviare
> snapshot incrementali in remoto.
>
> Ma come puoi immaginare, un conto è avere un RAID con i controcazzi ed
> usare i backup in caso di catastrofe, un altro è progettare il RAID alla
> pene di segugio e dover far affidamento sui backup.
>
> Non posso dire ai clienti: avete perso 1 giorno di dati perchè ho
> progettato male la ridondanza del RAID.
>
> Nel mio caso, il RAID deve essere online, sempre. Non posso far
> affidamento sul backup per calcolare un livello RAID inferiore.

non puoi neanche fare affidamento sul RAID per avere la sicurezza dei
dati. Se ai clienti non sta bene avere un buco di 1 giorno, allora si
fanno backup piu' frequenti, perche' non ci sono solo i dischi che si
possono rompere...

> > mirror a tre dischi. Nel server ti ci stanno 3 mirror piu' uno slot che
> > puoi usare come hot spare (che se non ricordo se lo spare deve essere
> > collegato al vdev o puo' essere collegato alla zpool, nel secondo caso
> > sarebbe piu' comodo), o per il backup.
>
> Che costano molto di più di un RAIDZ2.

huh? Un RAIDZ2 di 4 dischi ti costa esattamente uguale quanto un doppio
mirror.

> Gli hotspare, secondo me, non servono. Dato che il disco comunque lo devi
> comprare, tanto vale tenerlo in funzione sempre pronto anzichè tenerlo in
> standby (ma comunque alimentato, quindi prima o poi si spaccherà uguale e
> stai pur certo che si spaccherà quando serve)

anche quello che tieni nel cassetto pronto all'uso in caso si spacchi un
HD dei RAID :)

> > vedi sopra. IMHO se ti serve sicurezza e espandibilita' i mirror sono la
> > strada.
>
> Espandibilità, si, ma sopratutto devo tenere bassi i costi. Userò solo
> SSD, e buttarne via 2 alla volta (con un mirror a 3 vie) comincia ad
> essere un po costoso.
>
> > ah ecco. nel 10mo slot ci metti un SSD piccolo con una camionata di IOPS
> > e lo usi come L2ARC e ZIL. Comunque un mirror e' piu' veloce in
> > scrittura/lettura che un ZRAID, non deve perdere tempo a calcolare la
> > parita'.
>
> Su questa cosa ci sono molti pareri contrastanti. A parte il calcolo della
> parità, che viene fatta dalla CPU (ed in questo caso ti parlo di
> biprocessore esacore o superiore), la scrittura del dato in se per se, su
> un RAIDZ dovrebbe essere più veloce, dovendo scrivere, in parallelo, 1/3
>
> Se ho 30MB da scrivere, in un mirror a 3 vie ne devo scrivere 30+30+30 in

> Sparallelo. u un RAIDZ2 a 5 dischi, ne scrivo 10+10+10 (più parità negli
> Saltri due)

quindi sul mirror ci metti il tempo di scriverne 30 sul raidz2 il tempo
di scriverne 10 piu' il tempo per spezzare i dati e calcolarne la
parita'...mmh boh.

> > RAIDZ1, poll da 5 HD SATA da 3TB l'uno: resilvering ca. 1 ora/TB :D
> > Probabilmente con qualcosa di piu' performante di HP microserver ci
> > metti qualcosa in meno.
>
> Quanto pieno? Perchè il valore mi sembra spropositato.

mmhh, 80% forse.

> Io ho impiegato 25 ore qualche giorno fa a ricostruire un RAID6 hardware
> con dischi SAS da 600GB. 600GB in 25 ore.
>
> no, non è un problema di server, *tutti* i miei server, configurazioni
> analoghe, impiegano circa 24 ore a terminare il rebuild di un RAID-6

eh boh, magari ricordo male, ma non ci ha messo sicuramente piu' di 24h.
Pero' ha fatto solo quello, non aveva utenti collegati ecc.

> > eh dipende quanto vuoi essere sicuro di rimanere online, se un downtime
> > di qualche ora e' accettabile allora uno stripe + un paio backup possono
> > andare bene. Se il downtime deve essere zero servono parecchi piu'
> > dischi... (+ quelli di backup)
>
> Si tratta di VM e database, in questi casi il downtime può solo essere
> zero. Non è un fileserver, dove in caso di guasto ripristino. Essendoci di
> mezzo database e VM, il ripristino per aver perso l'intero pool deve
> essere considerata "catastrofe", per questo ti ho scritto sopra che non
> posso considerare la ridondanza in base al backup.

e allora duplica il server. perche' la donna delle pulizie che rovescia
per sbaglio il secchio dell'acqua sul server puo' sempre capitare ;) > >

> 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?

[BClaudio]

Il 09/01/2017 18:31, gandalf.co...@gmail.com ha scritto:
> Quanto pieno? Perchè il valore mi sembra spropositato.
> Io ho impiegato 25 ore qualche giorno fa a ricostruire un RAID6 hardware
> con dischi SAS da 600GB.
>
> 600GB in 25 ore.
>
> no, non è un problema di server, *tutti* i miei server, configurazioni analoghe,
> 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

[BClaudio]

> 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.

[Enrico Bianchi]

On 2017-01-09, gandalf.co...@gmail.com <gandalf.co...@gmail.com> wrote:

> 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?

zpool create tank raidz2 sdb sdc sdd sde
zpool add tank raidz2 sdf sdg sdh sdi
zpool status
pool: tank
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 0
sde ONLINE 0 0 0
raidz2-1 ONLINE 0 0 0
sdf ONLINE 0 0 0
sdg ONLINE 0 0 0
sdh ONLINE 0 0 0
sdi ONLINE 0 0 0

errors: No known data errors
zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 111G 262K 111G - 0% 0% 1.00x ONLINE -

Da sdb a a sde sono dischi da 8Gb, da sdf a sdi sono dischi da 20Gb

> Qualcuno qui dentro usa RAIDZ ? Quali sono i tempi di resilvering e con quale
> 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

[gandalf.co...@gmail.com]

Il giorno lunedì 9 gennaio 2017 23:02:48 UTC+1, Jack ha scritto:
> non puoi neanche fare affidamento sul RAID per avere la sicurezza dei
> dati. Se ai clienti non sta bene avere un buco di 1 giorno, allora si
> fanno backup piu' frequenti, perche' non ci sono solo i dischi che si
> possono rompere...

un conto è perdere dati, un altro è avere macchina ferma.
Se si rompe il server, lo si cambia, ma i dati son sempre li.
Se perdi l'intero volume raid, hai perso i dati, e devi ripristinare da backup.
Questa è la situazione che *DEVO* assolutamente evitare (come tutti, presumo)

> huh? Un RAIDZ2 di 4 dischi ti costa esattamente uguale quanto un doppio
> mirror.

Si, ma è più sicuro.

> anche quello che tieni nel cassetto pronto all'uso in caso si spacchi un
> HD dei RAID :)

Esatto. Per questo non mi piacciono gli spare.
Se il disco è già in casa (quindi l'hai già pagato), tanto vale usarlo.

> quindi sul mirror ci metti il tempo di scriverne 30 sul raidz2 il tempo
> di scriverne 10 piu' il tempo per spezzare i dati e calcolarne la
> parita'...mmh boh.

Quanto potrà mai impiegare una CPU moderna a calcolare la parità?
"spezzare" i dati lo fa in tempo zero, non ci sono strani calcoli da fare.

> > Quanto pieno? Perchè il valore mi sembra spropositato.
>
> mmhh, 80% forse.

Quindi sostanzialmente tu stai replicando l'80% di 4*3TB (RAID-5)
ovvero l'80% di 12TB ad 1TB ora ?

Mi sembra impossibile. La macchina è idle ?
Io non raggiungo tali valori (sono ben più lontano) nemmeno con dischi
molto più veloci e molto, molto più piccoli usando raid hardware con 1GB di cache.

> eh boh, magari ricordo male, ma non ci ha messo sicuramente piu' di 24h.
> Pero' ha fatto solo quello, non aveva utenti collegati ecc.

Ah grazie allora...........

[gandalf.co...@gmail.com]

Il giorno martedì 10 gennaio 2017 01:47:18 UTC+1, BClaudio ha scritto:
> 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.

Esatto.
Murphy ci vede benissimo, stai tranquillo che si romperà sempre la coppia.
Stesso costo, meno protezione, a 4 dischi un RAID10, salvo richieste di
performance stellari, non ha senso.

Su molti dischi non ha più senso un RAID-6, perchè aumenta la probabilità
che si possano rompere 3 dischi alla volta.

Quindi o RAID-6, o RAID-60, se si vuol dormire tranquilli.

> 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.

Non ne vedo il problema, anzi, è un plus, la gente paga per questo.
Hai un server con raffreddamento a liquido. Puoi farci i videogiochi.

[gandalf.co...@gmail.com]

Il giorno martedì 10 gennaio 2017 10:27:06 UTC+1, Enrico Bianchi ha scritto:
> zpool create tank raidz2 sdb sdc sdd sde
> 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.

[Enrico Bianchi]

On 2017-01-10, gandalf.co...@gmail.com <gandalf.co...@gmail.com> wrote:

> Ed in pratica hai fatto ciò che ho scritto: hai aggiunto un raid ad un raid.

Vero, non ci avevo fatto caso. Ma è la via corretta, in quanto, come dici anche
te, non c'è modo di espandere un pool RAIDZ (l'alternativa è cambiare i dischi
con modelli più capienti)

> Io intendevo aggiungere *UN* disco ad un raidz2 esistente, come si fa con
> mdadm

Sinceramente, nemmeno ricordavo che si potesse fare e, personalmente, non so
se sia una cosa buona

> Che poi mi sa di cazzata, perchè basterebbe non riallocare nulla
> (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

[gandalf.co...@gmail.com]

Il giorno martedì 10 gennaio 2017 16:53:07 UTC+1, Enrico Bianchi ha scritto:
> 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)

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

[Marco Gaiarin]

Mandi! gandalf.co...@gmail.com
In chel di` si favelave...

> 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

[Enrico Bianchi]

On 2017-01-10, gandalf.co...@gmail.com <gandalf.co...@gmail.com> wrote:

> Fermo? Su github vedo commit recenti. Probabilmente le nuove funzioni non
> sono più implementate,

Diciamo che stanno cercando di metterci una pezza (per intenderci, l'encryption
la stanno implementando in OpenZFS, ma sarà un bagno di sangue, soprattutto
per il fatto che non è multipiattaforma)

> ma i bugfix credo vengano risolti (me lo auguro)

Questi sicuramente

> Leggevo in giro che non è semplice implementare l'espansione di un RAIDZ
> 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

[gandalf.co...@gmail.com]

Il giorno martedì 10 gennaio 2017 23:20:02 UTC+1, Marco Gaiarin ha scritto:
> Cosa devi farci con questi server? Solo storage?

No storage, sono hypervisors.

> Pensa anche a una soluzione di 'Software Defined Storage', io ti consiglio
> 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.