si, il software di gestione Synology consente la migrazione indolore da RAID-1 a RAID-5:
https://help.synology.com/dsm/?secti...raid_type.html
si; nell'ottica della miglior salvaguardia dei dati la tipologia 5 del RAID è quella che conviene
con un numero di dischi fino a cinque.
Da sei unità in poi si potrebbe anche prendere in considerazione un RAID-6.
a ottimo mi spaventava l'idea di dover poi sistemare il tutto nuovamente tra pochi mesi.
per ora punto al Raid-5, per ottenere 12tb di spazio con 5 HDD da 3tb, e direi che mi basta per il momento.
Poi ho scoperto che il software Synology mi permetterebbe anche di passare istantaneamente le foto scattate sui dispositivi mobili connessi alla rete, ottima cosa se durante uno shooting ho clienti che vogliono vedere in diretta il lavoro o voglio usare l'ipad di fianco alla fotocamera.
Non sono sicuro di aver capito bene la domanda. Mantenere la conformazione del RAID-6 o del RAIDZ-2 dovrebbe rendere disponibile la doppia parità indipendentemente dal numero di drive. Poi è questione di statistica, ovviamente più aumenta il numero di dischi, maggiori sono le probabilità di un guasto... Se non ricordo male, la doppia parità era consigliata fino a 12 dischi.
Se poi si parla del discorso prestazioni, avevo letto un blog in cui spiegavano quale è la proporzione ottimale per ogni geometria.
Esiste poi anche il RAIDZ-3, con la tripla parità, ma non ho approfondito.
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
Considera che la trasformazione da RAID1 a RAID5 non è "gratis" nel senso che il lavoro di trasformazione dell'array potrebbe richiedere anche qualche giorno alla cpu del NAS, dipende da diversi fattori. I dati rimangono disponibili ed accessibili ma le prestazioni saranno degradate fino al completamento della trasformazione.
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
forse mi sono espresso non perfettamente.
Quindi la metto così.
A quanto mi è dato sapere:
soluzione di un classico RAID-6
1) uso un qualsiasi filesystem e decido di metter su un RAID-6 di sei dischi da 2TB ciascuno, per un totale usufruibile di 8TB
2) giungo a riempirlo fino a ~7TB di dati
3) decido che è arrivato il tempo di effettuare un upgrade e ricontatto il commerciale chiedendogli se posso aggiungere un solo disco da 2TB
4) il commerciale mi risponde che non vede il problema e posso certamente farlo, come si è sempre fatto con tutti i RAID hardware
5) comunico al capo che abbiamo speso solo il costo di un nuovo hd.
soluzione ZFS con RAIDZ-2
1) uso ZFS e decido di metter su un RAIDZ-2 di sei dischi da 2TB ciascuno (n.1 VDEV e n.1 Pool) per un totale usufruibile di 8TB
2) giungo a riempirlo fino a ~7TB di dati
3) decido che è giunto il momento di effettuare un upgrade e ricontatto il commerciale chiedendogli se posso aggiungere un solo disco da 2TB
4) il commerciale mi risponde che non posso farlo: bisogna aggiungere altri sei dischi, da almeno 2TB ciascuno
5) ci resto leggermente male ma non posso far altro che comunicare al capo l'assoluta necessità d spendere nuovamente la somma iniziale degli hd
per ora non supero i 4tb di dati quindi credo non duri tantissimo, in ogni caso è gia tanto per me che riesca a farlo in autonomia e pochi click
Non mi risulta... I pool ZFS sono espandibili, non è possibile ridurli ma questo non lo è praticamente in nessun caso.
Sempre dal blog riportato prima:
Some zpool caveats
I would be amiss if I didn't meantion some of the caveats that come with ZFS:
- Once a device is added to a VDEV, it cannot be removed.
- You cannot shrink a zpool, only grow it.
- RAID-0 is faster than RAID-1, which is faster than RAIDZ-1, which is faster than RAIDZ-2, which is faster than RAIDZ-3.
- Hot spares are not dynamically added unless you enable the setting, which is off by default.
- A zpool will not dynamically rezise when larger disks fill the pool unless you enable the setting BEFORE your first disk replacement, which is off by default.
- A zpool will know about "advanced format" 4K sector drives IF AND ONLY IF the drive reports such.
- Deduplication is EXTREMELY EXPENSIVE, will cause performance degredation if not enough RAM is installed, and is pool-wide, not local to filesystems.
- On the other hand, compression is EXTREMELY CHEAP on the CPU, yet it is disabled by default.
- ZFS suffers a great deal from fragmentation, and full zpools will "feel" the performance degredation.
- ZFS suports encryption natively, but it is NOT Free Software. It is proprietary copyrighted by Oracle.
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
scusa Matteo, non te la prendere mi raccomando, ma credo di parlare e scrivere in italiano:
dove avresti letto che io abbia indicato il contrario e/o parlato di una riduzione dell'array
o del pool o che questi non siano espandibili?
Saresti così gentile di quotare la frase che lo indicherebbe e postarla nel tuo reply?
Grazie
Per ciò che mi riguarda ho semplicemente asserito che, alle mie attuali conoscenze, al momento
di dover espandere il pool di un RAIDZ-2 e continuare a mantenere le sue complete funzionalità
(double parity su ogni singolo vdev) ZFS ha bisogno di un numero di dischi uguale a quelli che già
compongono il vdev stesso:
da 6 (sei) dischi il vdev dovrà passare a 12 (dodici) dischi; pertanto sarà necessario aggiungere
obbligatoriamente ulteriori 6 (sei) dischi.
https://forums.freebsd.org/threads/e...-raidz2.37113/
https://bramley.gen.cam.ac.uk/groups..._too_full.html
Questa mancanza, sostanzialmente del "block pointer rewrite", porta alla circostanza che per poter
aggiungere un solo nuovo hd è necessario creare un altro e differente vdev e solo successivamente
aggiungerlo al pool, vanificando così una parte dei vantaggi funzionali di questo complesso e sofisticato
filesystem.
Aggiungere un vdev non-ridondante al pool può portare alla compromissione dell'integrità dell'intero
pool, coinvolgendo nella compromissione anche eventuali ed ulteriori vdev.
Gli sviluppatori ci stanno lavorando da tanto tempo, ma sembrerebbe che la soluzione della faccenda
sia più complessa di quanto possa superficialmente sembrare.
forse in inglese sarò più fortunato
You cannot extend a raidz vdev (ie change a 6-drive raidz vdev to an 8-drive).
However, you can replace the drives in a raidz vdev with larger drives, to expand the total size
of a raidz vdev. You have to replace each drive individually. Once all the drives in the raidz vdev
have been replaced, you export the pool, and import the pool, and all the extra space becomes
available.
No, che non me la prendo. Perchè dovrei?
Come ho detto, per me ZFS è una tecnologia completamente nuova e me ne sto interessando solo da poco. Inoltre a breve mi troverò a dover gestire una macchina che la adotta quindi se c'è qualche aspetto che non mi è del tutto chiaro, o che ho completamente travisato, il fatto che tu me lo faccia notare mi è solo utile e anzi te ne ringrazio.
Probabilmente ho fatto confusione con qualche termine/concetto nella documentazione che ho guardato oppure ho letto troppo superficialmente i tuoi post. Mi vado a rileggere meglio un po' di roba e vedo di chiarirmi le idee.
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
Ok, ora ho capito dove è il punto della questione.
Nella prima parte del post #29 hai genericamente parlato di espandere il pool, aggiungendo ulteriori dischi:
E io non avevo letto con attenzione questa parte in cui suggerivi dove è il vero problema:
Ho ragionato sempre parallelizzando il RAIDZ-2 ad un RAID6 senza tenere conto delle peculiarità di ZFS e del fatto che il RAIDZ-2 non è un RAID6 anche se è funzionalmente equivalente (limitatamente al discorso della doppia parità).
[OT: ] Stiamo inquinando un po' il thread di Dante ma visto che abbiamo iniziato a parlarne qui, tanto vale chiudere il cerchio.
Chiariamo alcuni termini:
- Pool => Insieme di dispositivi virtuali (vdev) che concorrono a formare lo spazio di archiviazione.
- vdev => Virtual device. Combinazione di device fisici (un vdev può essere costituito da un solo disco come da una combinazione di più dispositivi, a seconda di quello che si vuole ottenere). Il modo in cui i device fisici sono combinati all'interno del virtual device ne determina le caratteristiche di gestione del dato (stripe, mirroring, RAIDZ-{1,2,3} o combinazioni delle precedenti, ad esempio uno stripe di RAIDZ-n) e di resistenza alla avarie.
Uno o più vdev possono essere aggregati tra loro per formare un "pool" che avrà capacità totale pari alla somma delle capacità messe a disposizione dal singolo vdev che lo compone. Giusto?
[EDIT: Questo forse non è del tutto vero, ci posso essere problemi se i vdev hanno dimensioni diverse]
Prendiamo ora in esame il caso espresso da Toto: Abbiamo 6 dischi di capacità X combinati in un vdev RAIDZ-2 oppure in un array RAID6, quindi quattro dischi dati (D1, D2, D3 e D4) e due di parità (P1, P2).
- Combinando questi dischi in un RAID6 otteniamo un volume di archiviazione composto (a titolo esplicativo) da un array di questo tipo: RAID6 = array(D1+D2+D3+D4&P1&P2)
- Realizzando una analoga combinazione in RAIDZ-2 otteniamo un pool composto da un vdev di questo tipo: POOL = vdev1(D1+D2+D3+D4&P1&P2)
Assumiamo di voler aggiungere un ulteriore disco (D5) per aumentare la capacità complessiva del nostro volume di archiviazione.
- In RAID6 il volume di archiviazione diventa questo: RAID6 = array(D1+D2+D3+D4&P1&P2+D5)
- In RAIDZ-2 il pool di archiviazione diventa invece questo: POOL = vdev1(D1+D2+D3+D4&P1&P2)+vdev2(D5)
In entrambi i casi otteniamo il medesimo incremento di capacità ma si evince ora quello che cercava di farmi capire Toto: In questo caso, la porzione di dati che verrebbero scritti fisicamente sul vdev2 non sarebbero soggetti ad alcuna parità, mettendo quindi a rischio l'integrità dell'intero pool. Per ottenere lo stesso livello di sicurezza del dato disponibile per il vdev1 dovrei aggiungere un maggior numero di dischi invece di uno solo, realizzando ad esempio questa configurazione (o un suo multiplo): POOL = vdev1(D1+D2+D3+D4&P1&P2)+vdev2(D5+D6+D7+D8&P3&P4)
In realtà, quest'ultima configurazione del pool diventa funzionalmente equivalente ad un RAID60 (uno stripe di RAID6) invece che ad un RAID6...
Il problema non si presenta in configurazione RAID6 perchè quando viene aggiunto un nuovo device all'array tutto il contenuto del volume viene completamente riscritto (anche in maniera trasparente all'utente) per spalmare tutti i dati in modo omogeneo su tutti i dischi che compongono l'array, ricalcolando anche le informazioni di parità.
ZFS invece non tocca mai i "live data" (quindi quello che è già presente nel pool) fino a quando il dato non viene riscritto quindi i dati già esistenti non vengono "spalmati" sul nuovo D5 senza un'azione esplicita dell'utente. Tale azione può essere solo una sequenza di [backup dei dati, eliminazione e rigenerazione del pool e dei vdev, ripristino dei dati] oppure un giro di snapshot e copia del dato su se stesso (comunque da verificare se funziona, l'ho intravisto in un blog) che richiede comunque di riscrivere tutti i dati.
Il discorso di supportare o meno il "block pointer rewrite" a quanto ho capito, è leggermente diverso: Non è che la cosa non si possa fare ma a quanto ho capito il gruppo di sviluppo non ha ancora deciso se vuole o meno implementare questa funzionalità perchè si porta dietro i suoi pro ed i suoi contro, tenendo conto di quelli che sono i reali use-case in quella che è la destinazione d'uso per cui è stato creato ZFS.
E' corretto quanto sopra?
Ultima modifica di frakka : 10-01-2015 a 05:00
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando
