Aggiornamento della dimensione ZFS Pool con dischi di size diverse

Ho attualmente una configuration in cui sto utilizzando un vecchio desktop come server multimediale, ma non ho tolleranza agli errori e la quantità di supporti è troppo grande per me per ragionevolmente riprendere tutto. Non sono terribilmente preoccupato di perdermi in caso di guasti del disco, dato che sono solo i film e gli spettacoli televisivi e simili (molti dei quali ancora ho i DVD, imballati da qualche parte), ma sto attualmente aggiornando il mio sistema e vorrei aggiungere qualche tolleranza agli errori qui.

Attualmente, ho un drive da 1TB, 2TB e 3TB, con probabilmente circa 5,5TB, e penso di comprare altri due drive 4TB e di creare un arrays RAIDZ 4TB x 4TB x 3TB.

Le mie domande sono:

  1. La mia comprensione è che per gli arrays di dischi eterogenei come questo, la dimensione del pool sarà limitata alla dimensione del disco più piccolo , il che significa che sarei guardando un 3 x 3 x 3 TB RAIDZ con spazio usabile 6TB e 2TB di non – spazio-tollerante – è vero? *
  2. Supponendo che il numero # 1 sia vero, quando ho finalmente bisogno di più spazio, se aggiungo un singolo disco 4TB o 6TB all'arrays, sarà una semplice questione per estendere la piscina a diventare un arrays di 4 x 4 x 4 TB è necessario trovare un posto per archiviare i 6TB di dati durante l'aggiornamento dell'arrays?

* Il 2TB di spazio non tollerante ai guasti non è un grosso affare, perché stavo progettando di mettere da parte 2TB circa per "cose ​​che necessitano di un backup appropriato" (foto personali, istantanee di computer, ecc.) Che mi sarei riflettuto rimanente disco 2TB e un'altra unità 2TB esterna che manterrò da qualche altra parte.

Attualmente, ho un drive da 1TB, 2TB e 3TB, con probabilmente circa 5,5TB, e penso di comprare altri due drive 4TB e di creare un arrays RAIDZ 4TB x 4TB x 3TB.

Con i drive da 4 TB, non si dovrebbe guardare RAIDZ singolo ridondanza. Vorrei raccomandare RAIDZ2 a causa della protezione aggiuntiva che offre nel caso in cui un disco interrompa in qualche modo o altrimenti sviluppa problemi.

Ricorda che le unità consumer sono di solito specificate ad un tasso URE di un settore fallito per 10 ^ 14 bit letto. 1 TB (produttore di unità disco fisso terabyte, cioè) è 10 ^ 12 byte o vicino a 10 ^ 13 bit, dare o prendere una piccola modifica. Un passaggio completo di lettura dell'arrays che hai in mente è statisticamente probabile che incontri un problema e nella pratica i problemi di lettura tendono a svilupparsi in batch.

Non so perché ti stai suggerendo RAIDZ2. È più probabile che svilupperò due errori di unità simultanei se utilizzo RAIDZ1 se non usi RAID? Voglio un certo miglioramento alla tolleranza agli errori del mio sistema. Nulla di recuperabile esisterà in un solo posto, quindi il RAID, arrays è solo una questione di convenienza.

RAIDZ1 utilizza un singolo disco per fornire la ridondanza in un vdev, mentre RAIDZ2 utilizza due (e alcuni calcoli più complessi, ma è improbabile che il calcolo RAIDZ sia limitato in each caso). Il vantaggio di un secondo disco ridondante è nel caso in cui il primo fallisce o altrimenti diventa non disponibile. Con solo valore di ridondanza di un disco, gli errori aggiuntivi sono ormai critici. Con 4 + 4 + 3 TB, si dispone di 11 TB di immagazzinamento grezzo, inizialmente 6 TB di cui potrebbe essere necessario leggere per ribuild un disco perduto (8 TB dopo aver aggiornato quello 3 TB a 4 TB e espandere la piscina per abbinare). Per le stime dell'ordine di grandezza, che gira piacevolmente da qualche parte tra 10 ^ 13 e 10 ^ 14 bit. Statisticamente, hai qualcosa come una probabilità del 50% al 100% di colpire un errore di lettura irrecuperabile durante la resilvering quando si utilizza la ridondanza singola con una matrix di tale grandezza di ordine di grandezza. Certo, si può molto bene fuori, ma improvvisamente significa che non avete accanto a nessuna protezione in caso di guasti di unità.

La mia comprensione è che per gli arrays di dischi eterogenei come questo, la dimensione del pool sarà limitata alla dimensione del disco più piccolo, il che significa che sarei guardando un 3 x 3 x 3 TB RAIDZ con spazio usabile 6TB e 2TB di non – lo spazio tollerante – è vero?

Quasi. ZFS limiterà il vdev alla dimensione del più piccolo dispositivo costitutivo, in modo da get la capacità effettiva di un RAIDZ vdev da tre dispositivi costituito da dispositivi da 3 TB, quindi 6 TB di archiviazione accessibile all'utente (dare o prendere metadati). La restante 2 TB di spazio di stoccaggio grezzo viene sprecato; non è disponibile per l'uso anche senza ridondanza. (Verranno visualizzati nella colonna EXPANDSZ zpool list , ma non vengono utilizzati.)

Una volta sostituito l'unità da 3 TB con un'unità da 4 TB e espandere il vdev (entrambe le operazioni in linea in ZFS), la piscina può utilizzare lo spazio di archiviazione aggiuntivo.

Ci sono modi in questo ambito – per esempio, è ansible suddividere le unità per presentare tre dispositivi da 3 TB e due dispositivi da 1 TB (restanti dei due drive da 4 TB) a ZFS – ma sta complicando seriamente la configuration e non è improbabile per lavorare come si pianifica. Vi consiglio vivamente.

Il 2 TB di spazio non tollerante ai guasti non sarebbe stato supportto da ZFS ai dischi offline, scusi se questo non era chiaro. Stavo suggerendo che avrei fatto il backup da normali operazioni di sincronizzazione dei dischi come rsync .

Ciò implica che ZFS non ha alcuna conoscenza di questi 2 x 1TB e che stai creando un altro file system nello spazio. Sì, puoi farlo, ma ancora, sta andando a complicare seriamente il tuo setup per, francamente, quello che sembra essere un po 'di guadagno.

Supponendo che il numero # 1 sia vero, quando ho finalmente bisogno di più spazio, se aggiungo un singolo disco 4TB o 6TB all'arrays, sarà una semplice questione per estendere la piscina per diventare una matrix 4 x 4 x 4 TB è necessario trovare un posto per archiviare i 6TB di dati durante l'aggiornamento dell'arrays?

Come ho detto sopra, i vdevs e pool di ZFS possono essere coltivati ​​come operazioni online, se lo fai sostituendo gradualmente i dispositivi. (Non è tuttavia ansible ridurre un pool ZFS o un vdev.) Quello che tuttavia non è ansible è aggiungere dispositivi aggiuntivi a un vdev esistente (ad esempio, il vdev RAIDZ da tre dispositivi che prevedi la creazione); deve essere aggiunto un vdev completamente nuovo alla piscina e i dati che vengono successivamente scritti vengono quindi tracciati tra i due vdevs presenti nel pool. Ogni vdev possiede propri requisiti di ridondanza, ma può condividere i ricambi caldi. Inoltre, non è ansible rimuovere i dispositivi da un vdev, tranne nel caso degli specchi (in cui la rimozione di un solo dispositivo riduce il livello di ridondanza di quel particolare mirror vdev e non influisce sulla quantità di spazio di archiviazione accessibile dall'utente) e non è ansible rimuovere vdevs da una piscina. L'unico modo per eseguire quest'ultimo (e per conseguenza l'unico modo per risolvere alcuni problemi di configuration della piscina) è ricreare la piscina e trasferire i dati dalla vecchia piscina, eventualmente tramite backup, alla nuova piscina.

Il 2TB di spazio non tollerante agli errori non è un grosso affare, perché stavo pensando di mettere da parte 2TB circa per "cose ​​che necessitano di un backup appropriato" (foto personali, istantanee di computer, ecc.) Che mi sarei riflettuto sul rimanente 2TB e una seconda unità 2TB esterna che manterrò da qualche altra parte.

La ridondanza ZFS non è realmente progettata per il caso di utilità off-site-backup-drive principalmente offline. Lo discuto in una certa profondità in uno specchio ZFS con un disco per lo più offline lavoro? , ma il pane e il burro sono che è meglio utilizzare zfs send / zfs receive per copiare il contenuto di un file system ZFS (incluse istantanee e altre periferiche) o rsync semplice se non ti interessa gli snapshot utilizzare gli specchi in una configuration prevalentemente offline.

Se utilizzo metà dei miei dischi per la tolleranza agli errori, potrei anche utilizzare i backup tradizionali offline.

Questo dipende certamente dalla tua situazione. Quali sono i tuoi tempi di recupero in situazioni diverse? RAID riguarda l'impiego e il tempo per il recupero, non per salvaguardare i dati; è comunque necessario eseguire il backup .

La mia comprensione è che per gli arrays di dischi eterogenei come questo, la dimensione del pool sarà limitata alla dimensione del disco più piccolo, il che significa che sarei guardando un 3 x 3 x 3 TB RAIDZ con spazio usabile 6TB e 2TB di non – spazio-tollerante – è vero? *

Sì.

Supponendo che il numero # 1 sia vero, quando ho finalmente bisogno di più spazio, se aggiungo un singolo disco 4TB o 6TB all'arrays, sarà una semplice questione per estendere la piscina per diventare una matrix 4 x 4 x 4 TB è necessario trovare un posto per archiviare i 6TB di dati durante l'aggiornamento dell'arrays?

Sì, questo è ansible.

Puoi sostituire tutti i tuoi dischi all'interno di un vdev Z1 / Z2 / Z3 uno per volta, where la tua capacità sarà uguale al disco più piccolo attualmente in uso nel vdev (puoi anche impostare la properties; autoexpand on per farlo automaticamente anziché manualmente).

D'altra parte, non è ansible aggiungere (anziché sostituire) un'unità a un vdev esistente Z1 / Z2 / Z3 senza distruggere completamente e ricreare la piscina (perdendo tutti i tuoi dati nel process). Su specchi e vdevs di base, è ansible aggiungere più unità per creare uno specchio a 2 specchio, a 3 specchi, a 4 specchi, ecc., Ma solo aumenta l'affidabilità, non utilizzabile.