Scenari di perdita di dati ZFS


27

Sto cercando di costruire un pool ZFS di grandi dimensioni (150 TB +) e mi piacerebbe ascoltare le esperienze delle persone sugli scenari di perdita di dati a causa di un hardware guasto, in particolare, distinguendo tra i casi in cui si perdono solo alcuni dati rispetto all'intero filesystem ( di se esiste persino una tale distinzione in ZFS).

Ad esempio: supponiamo che un vdev venga perso a causa di un guasto come un contenitore di unità esterno che perde energia o un guasto della scheda controller. Da quello che ho letto il pool dovrebbe andare in modalità difettosa, ma se viene restituito il vdev il pool dovrebbe recuperare? o no? o se il vdev è parzialmente danneggiato, si perde l'intero pool, alcuni file, ecc.?

Cosa succede se un dispositivo ZIL si guasta? O solo uno dei tanti ZIL?

Veramente tutti gli aneddoti o scenari ipotetici supportati da una profonda conoscenza tecnica sono apprezzati!

Grazie!

Aggiornare:

Lo stiamo facendo a buon mercato poiché siamo una piccola impresa (circa 9 persone) ma generiamo una discreta quantità di dati di imaging.

I dati sono per lo più file di piccole dimensioni, dal mio conteggio circa 500k file per TB.

I dati sono importanti ma non estremamente critici. Stiamo pianificando di utilizzare il pool ZFS per eseguire il mirroring dell'array di dati "live" da 48 TB (in uso per circa 3 anni) e di utilizzare il resto della memoria per i dati "archiviati".

Il pool verrà condiviso utilizzando NFS.

Il rack è presumibilmente su una linea di generatore di backup dell'edificio e abbiamo due UPS APC in grado di alimentare il rack a pieno carico per circa 5 minuti.


2
Se non sai già cosa stai facendo, chiama un consulente e / o segui alcuni corsi. Dubito che tutte le specifiche di cui hai bisogno possano essere trattate in una semplice risposta.
Lucas Kauffman,

3
Quindi hai ancora intenzione di utilizzare SATA 7.2 di consumo cheapo allora? sospiro
Chopper3

@ Chopper3 In realtà, non ho detto intenzionalmente che ... sto prendendo in seria considerazione l'acquisto di unità SAS da 2 TB anziché unità SATA da 3 TB. Anche se ho visto molte persone dire che stanno usando bene le unità SATA ....
Cyclone

1
I dischi SATA per ZFS non sono davvero un buon mix. Al giorno d'oggi non troverai molte persone che raccomandano questa configurazione. Alla scala di cui stai parlando (150 TB), è un errore costoso e inutile. Dai un'occhiata a questo, però .
ewwhite,

Risposte:


22

Progetta nel modo giusto e minimizzerai le possibilità di perdita di dati di ZFS. Tuttavia, non hai spiegato cosa stai memorizzando nel pool. Nelle mie applicazioni, serve principalmente VMWK di VMWare ed esporta zvol su iSCSI. 150 TB non è un importo insignificante, quindi mi affiderei a un professionista per i consigli di ridimensionamento.

Non ho mai perso i dati con ZFS.

Io ho vissuto tutto il resto:

Ma attraverso tutto ciò, non c'è mai stata una perdita sensibile di dati. Solo tempi di inattività. Per VMWare VMDK è in cima a questo archivio, spesso è stato necessario un fsck o un riavvio a seguito di un evento, ma non peggio di qualsiasi altro arresto anomalo del server.

Per quanto riguarda la perdita di un dispositivo ZIL, ciò dipende dal design, da ciò che stai memorizzando, dal tuo I / O e dai pattern di scrittura. I dispositivi ZIL che utilizzo sono relativamente piccoli (4 GB-8 GB) e funzionano come una cache di scrittura. Alcune persone eseguono il mirroring dei propri dispositivi ZIL. L'uso dei dispositivi SSD di fascia alta STEC rende il mirroring proibitivo. Uso invece singole schede PCIe DDRDrive . Pianificare la protezione della batteria / UPS e utilizzare schede SSD o PCIe con un backup di supercondensatori (simile alle implementazioni del controller RAID BBWC e FBWC ).

Gran parte della mia esperienza è stata sul lato Solaris / OpenSolaris e NexentaStor . So che le persone usano ZFS su FreeBSD, ma non sono sicuro di quanto siano lontane le versioni di zpool e altre funzionalità. Per le distribuzioni pure di storage, consiglierei di seguire la rotta Nexentastor (e parlare con un partner esperto ), poiché è un sistema operativo appositamente progettato e ci sono distribuzioni più critiche in esecuzione su derivati ​​Solaris rispetto a FreeBSD.


Ho aggiornato la mia domanda con qualche informazione in più, ma sono particolarmente interessato a conoscere maggiori dettagli riguardanti: "mai una perdita di dati apprezzabile" e cosa ciò significhi / coinvolga. Interessato anche a saperne di più sul recupero di quelle zpools difettose, sulla gestione delle schede NIC difettose e persino sui problemi con le unità SATA e il passaggio a SAS (anche se sarai felice di sapere, probabilmente andrò con SAS da 2 TB su SATA da 3 TB , su tua raccomandazione).
Ciclone,

Perdita non apprezzabile == pochi secondi di dati transazionali o uno stato coerente con crash . E le schede di rete danneggiate sono state isolate in un singolo host VMWare e hanno comportato problemi a livello di VM. Non lo spazio di archiviazione ZFS sottostante.
ewwhite,

Il design the right waycollegamento ora è interrotto.
Saurabh Nanda,

11

Ho sovrascritto accidentalmente entrambi gli ZIL sull'ultima versione di OpenSolaris, causando la perdita irrevocabile dell'intero pool. (Davvero un brutto errore da parte mia! Non capivo che perdere lo ZIL avrebbe significato perdere il pool. Fortunatamente recuperato dal backup con tempi di inattività.)

Tuttavia, dalla versione 151a (non so con certezza cosa significhi la versione di ZPool), questo problema è stato risolto. E posso testimoniare che funziona.

Oltre a ciò, ho perso i dati ZERO su un server da 20 TB, anche a causa di numerosi altri casi di errore dell'utente, più interruzioni di corrente, cattiva gestione del disco, configurazioni errate, numerosi dischi guasti, ecc. Anche se la gestione e le interfacce di configurazione su Solaris cambiano frequentemente e in modo esasperante da una versione all'altra e presentano un obiettivo di competenze in costante mutamento, è ancora l'opzione migliore per ZFS.

Non solo non ho perso i dati su ZFS (dopo il mio terribile errore), ma mi protegge costantemente. Non subisco più la corruzione dei dati, che mi ha tormentato negli ultimi 20 anni su qualsiasi numero di server e workstation, con quello che faccio. Il danneggiamento dei dati silenzioso (o semplicemente "abbastanza silenzioso") mi ha ucciso numerose volte, quando i dati rotolano fuori dalla rotazione del backup, ma in realtà è diventato corrotto su disco. O altri scenari in cui i backup hanno eseguito il backup delle versioni corrotte. Questo è stato un problema molto più grande della semplice perdita di dati in una sola volta, il che è quasi sempre eseguito il backup. Per questo motivo, adoro ZFS e non riesco a capire perché il checksum e la guarigione automatica non siano state funzionalità standard nei file system per un decennio. (Concesso, i sistemi veramente vita o morte di solito hanno altri modi per assicurare l'integrità,

In parole povere, se non vuoi scendere all'inferno ACL, non usare il server CIFS integrato in ZFS. Usa Samba. (Hai detto che usi NFS però.)

Non sono d'accordo con l'argomento SAS vs. SATA, almeno il suggerimento che SAS sia sempre preferito su SATA, per ZFS. Non so se quel commento si riferisse alla velocità di rotazione del piatto, alla presunta affidabilità, alla velocità dell'interfaccia o ad altri attributi. (O forse solo "costano di più e non sono generalmente utilizzati dai consumatori, quindi sono superiori". Un sondaggio di settore recentemente pubblicato (ancora nelle notizie ne sono sicuro), ha rivelato che SATA sopravvive in media a SAS, almeno con le dimensioni significative del campione del sondaggio. (Mi ha scioccato, questo è certo.) Non ricordo se si trattasse di versioni "enterprise" di SATA, o consumer, o di quali velocità - ma nella mia considerevole esperienza, i modelli enterprise e consumer falliscono tassi statisticamente significativi. (Tuttavia, c'è il problema delle unità consumer che impiegano troppo tempo per il timeout in caso di errore, il che è sicuramente importante nell'azienda - ma questo non mi ha morso, e penso che sia più rilevante per i controller hardware che potrebbero richiedere l'intero volume off-line in questi casi, ma questo non è un problema SAS vs SATA, e ZFS non mi ha mai deluso. Come risultato di quell'esperienza, ora uso un mix di unità SATA 1/3 enterprise e 2/3 consumer .) Inoltre, non ho riscontrato alcun impatto significativo sulle prestazioni con questo mix di SATA, se configurato correttamente (ad esempio una serie di mirror a tre vie), ma poi ho una bassa richiesta di IOPS, quindi a seconda di quanto è grande il tuo negozio e casi d'uso tipici, YMMV. Ho sicuramente notato che la dimensione della cache integrata per disco è più importante per i problemi di latenza rispetto alla velocità di rotazione del piatto, nei miei casi d'uso.

In altre parole, è una busta con più parametri: costo, throughput, IOPS, tipo di dati, numero di utenti, larghezza di banda amministrativa e casi d'uso comuni. Dire che SAS è sempre la soluzione giusta è ignorare un vasto universo di permutazioni di quei fattori.

Ma in entrambi i casi, ZFS è assolutamente incredibile.


3
Grazie per il tempo dedicato a rispondere. La tua esperienza con ZFS è coerente con la mia. I miei commenti sulla selezione dell'unità riguardavano in particolare i dischi SAS nearline e SATA. La differenza principale è l'interfaccia. Sono meccanicamente equivalenti. La best practice in ZFS-land ora è quella di evitare SATA a causa della necessità di interfacce a doppia porta, migliore correzione degli errori e timeout gestibili offerti da SAS.
ewwhite,

Ho finito con i dischi SAS da 3 TB, ma ... prima di farlo ho messo insieme 30 dischi così misti (5 SATA da 400 GB, 12 SATS da 750 GB, SAS da 1 TB da 14) che ho inserito nello stesso enclosure espanso SAS. Davvero uno scenario peggiore secondo. Queste unità avevano già ~ 2-3 anni di autonomia. Ho quindi scritto un programma che eseguiva 8 thread leggendo casualmente la scrittura e l'eliminazione di file nel pool. L'ho fatto funzionare per oltre una settimana. Leggere e scrivere> 100 TB nel pool ... nessun problema. AVG R / W 100-400 MB / sec. Sospetto che gli avvisi SATA su SAS potrebbero essere una vecchia notizia ora.
Ciclone,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.