Quale livello RAID per un server?

01

Scrivi prima il requisito di ripristino

Definisci il modello di guasto in linguaggio semplice: un dispositivo, due dispositivi, un controller, cancellazione accidentale o l'intero server. RAID affronta solo alcuni guasti dei dispositivi. Imposta un obiettivo di tempo di ripristino per il ripristino del servizio e un obiettivo di punto di ripristino per la perdita di dati, quindi identifica quale requisito l'array locale può soddisfare e quale richiede replica o backup altrove.

Registra anche se il sistema deve continuare ad accettare scritture mentre è degradato. Un archivio prevalentemente in lettura, un database con molte scritture e spazio scratch usa e getta possono usare lo stesso numero di dischi ma richiedere layout diversi. L'efficienza della capacità è quindi un vincolo, non il verdetto.

02

Abbina il layout al carico di lavoro e al numero di dispositivi

I mirror sono semplici per un set di avvio o dati a due dispositivi e possono adattarsi a I/O casuali dove gruppi mirror indipendenti sono utili. I layout a parità scambiano lavoro di scrittura e complessità di ricostruzione con più capacità. La doppia parità può preservare un margine di guasto aggiuntivo in un ampio set HDD, mentre RAID 10 scambia metà della capacità grezza con coppie mirror. Queste sono tendenze di progettazione, non garanzie di prestazioni; controller, filesystem, profondità di coda, dimensione dei record e pattern applicativo contano tutti.

Usa la topologia effettiva del catalogo. I server di storage con 12 dischi e 24 dischi consentono scelte non disponibili su un server di calcolo con due NVMe. Non unire la coppia di avvio separata NVMe al calcolo dell'array dati e non presumere che un gruppo molto ampio sia preferibile a più gruppi senza modellare i domini di guasto e il comportamento I/O.

03

Scegli un livello per gestire la ridondanza

Decidi se un controller hardware, Linux MD o un filesystem come ZFS gestisce il layout. Evita di sovrapporre livelli RAID indipendenti senza un motivo documentato perché lo stato di salute e sostituzione può diventare ambiguo. La ridondanza ZFS è espressa tramite mirror o vdev RAIDZ e si basa sui checksum; un vdev di livello superiore perso può far perdere il pool, quindi aggiungere un singolo dispositivo non ridondante a un pool altrimenti ridondante cambia il modello di guasto.

Conferma l'identità dell'unità, la procedura di sostituzione, il comportamento di avvio e ciò che il sistema operativo può osservare prima di creare l'array. Cambiare la topologia in seguito può essere limitato o dirompente, in particolare per i layout di parità.

• ApriZFS struttura vdev ↗

04

Pianifica la finestra di degrado e ricostruzione

Il monitoraggio deve distinguere stati sani, degradati, di ricostruzione e di controllo di coerenza. Linux MD espone azioni come resync, recover, check e repair; raccogli progressi e discrepanze invece di segnalare solo che il volume è montato. Un RAID 5 o 6 sporco e degradato può presentare un rischio di corruzione, motivo per cui l'assemblaggio forzato non deve mai essere una scorciatoia di ripristino di routine.

Documenta l'instradamento degli avvisi, l'acquisizione di ricambi, l'identificazione della sostituzione, la limitazione del carico di lavoro e il punto in cui un ripristino è più sicuro che continuare. Non promettere mai una durata di ricostruzione senza misurare i dispositivi consegnati, il carico dell'array e il controller.

05

Registra la scelta e i suoi limiti

Il design completato dovrebbe nominare il layout, le ipotesi di unità uguali, la stima della capacità utilizzabile, i guasti tollerati, la fonte di monitoraggio e la posizione di ripristino. Mantieni i dati versionati in un altro dominio di guasto e testa un ripristino. Il risultato atteso non è un'affermazione che RAID prevenga la perdita; è un array il cui comportamento in caso di guasto e la responsabilità di ripristino sono compresi prima che arrivino i dati di produzione.