RAID0 invece di RAID1 o 5, è pazzo?

Sto pensando di utilizzare un'impostazione RAID0 per uno dei nostri cluster di SQL Server. Descriverò la situazione e cerco perché questa potrebbe essere una cattiva idea. Anche se qualcuno che hai casi d'uso, white paper o altra documentazione su cui puoi indicarmi su questo argomento, sarebbe fantastico.

Abbiamo 3 server in 2 datacenter che fanno parte di un cluster SQL. Stanno tutti eseguendo SQL Server in un gruppo di disponibilità. Il primario ha una replica proprio accanto ad essa e un'altra nell'altro datacenter. Stanno eseguendo la replica sincrona con failover automatico. Tutte le unità sono SSD di classe enterprise. Eseguiranno SQL Server 2017 o 2019.

Sto pensando che ci sarebbero molti vantaggi nell'eseguirli su array RAID0 rispetto ad altri metodi con pochi, se del caso, reali inconvenienti. L'unico aspetto negativo che sto vedendo attualmente è la mancanza di ridondanza sul server primario, quindi i guasti non aumentano. Come professionisti:

1. Se un'unità si guasta, invece di funzionare in uno stato rallentato e degradato fino a quando qualcuno riceve una notifica e agisce manualmente su di essa, il server fallirà immediatamente su un secondario mantenendo la piena funzionalità operativa. Ciò avrà un ulteriore vantaggio nel notificarci un failover, in modo che possiamo indagare prima sulla causa.

2. Riduce la possibilità di guasto complessivo per capacità TB. Poiché non abbiamo bisogno di unità di parità o mirror, riduciamo il numero di unità per array. Con un numero inferiore di unità, le possibilità totali di guasto dell'unità sono inferiori.

3. È più economico. La necessità di un numero inferiore di unità per la capacità richiesta costa ovviamente meno.

So che questo non è il pensiero aziendale convenzionale, ma c'è qualcosa che non sto prendendo in considerazione? Mi piacerebbe qualsiasi input sia pro che contro.

Non sto cercando di farlo per ottenere miglioramenti delle prestazioni della query, anche se se ci sono quelli significativi sentiti libero di indicarli. La mia preoccupazione principale è non riuscire a considerare o affrontare un problema di affidabilità o ridondanza a cui non avevo pensato.

Il sistema operativo si trova su un'unità con mirroring separata, quindi il server stesso dovrebbe rimanere attivo. Una di queste unità può essere sostituita e nuovamente replicata. È piccolo e non ci sono file di database diversi dai DB di sistema. Non riesco a immaginarlo impiegando più di minuti. Se uno degli array di dati fallisce, sostituiamo l'unità, ricostruiamo l'array, ripristiniamo e risincronizziamo con AG. Nella mia esperienza personale, il ripristino è stato MOLTO più veloce di una ricostruzione di unità RAID5. Non ho mai avuto un errore RAID1, quindi non so se quella ricostruzione sarebbe più veloce o meno. I ripristini provengono da un backup e vengono portati avanti in modo da corrispondere al primario, quindi l'aumento del carico sul server primario dovrebbe essere minimo, sincronizzando solo gli ultimi minuti dei registri con la replica recuperata.

C'è un aspetto molto importante che penso manchi nella tua valutazione:

Come pensi di recuperare?

Quando raid5 perde un'unità, verrà eseguita in uno stato degradato fino a quando non verrà ripristinata automaticamente. (Almeno se hai una scorta calda a portata di mano.)

Quando un raid0 perde un'unità, non può più recuperare. Ciò significa che hai perso la ridondanza e per ripristinarla devi ricostruire il tuo raid0 e copiare tutti i dati (non solo i dati sull'unità guasta) dal secondario che è ora sotto carico di produzione. Cioè, invece del singolo array raid5 degradato, è ora l'intera configurazione di produzione a ottenere il massimo delle prestazioni.

Se la penalità delle prestazioni dello stato degradata raid5 (o raid6) non è qualcosa che puoi affrontare, probabilmente dovresti fare invece raid 1 + 0 . Sì, costa di più, ma i prezzi del disco sono quelli che sono, saranno soldi ben spesi.

Forse "monitorare attivamente lo stato raid5 e trasferire il carico dal primario in caso di guasto di un'unità" è la soluzione che offre la maggior parte dei vantaggi senza inconvenienti? (A parte la perdita del fattore di raffreddamento nell'esecuzione senza ridondanza locale, ovviamente.) Se il ripristino dell'unità raid5 impiega molto più tempo di una sincronizzazione completa dei dati del database, il tuo software raid agisce in modo strano o hai dischi seriamente sovradimensionati, Io penso

Il guasto dell'unità deve essere preso in considerazione qui.

Immagina per un secondo che le nostre unità in un determinato giorno abbiano un tasso di guasto di 1/1000. Immagina quindi che abbiamo 20 unità in ciascuno dei nostri 3 array.

La possibilità di guasto di una singola unità in un array è quindi 20/1000 = 1/50. La possibilità che due unità si guastino nello stesso array è qualcosa di simile a 20/1000 * 20/1000 / 2 = 200/1000000 = 1/5000. Quindi passando da RAID 0 a RAID 5 abbiamo già significativamente meno probabilità di uccidere uno dei nostri array.

Quindi possiamo andare oltre - se la possibilità di un array che si guasta in un giorno è 1/50, allora la possibilità che due array si guastino in un giorno è 1 / (50 * 50) = 1/2500. La possibilità che due array RAID 0 identici si guastino è il doppio rispetto a un array RAID 5 che si guasta, assumendo lo stesso set di dischi. Questo aumento esponenziale delle possibilità di fallimento dovrebbe interessarti, poiché aumenta in modo massiccio la possibilità che più di un array fallisca contemporaneamente.

Poiché è probabile che questi dischi abbiano una lunga durata, è possibile eseguire i numeri come sopra e vedere direttamente l'effetto che ciò avrà sull'affidabilità: se è possibile pubblicare le specifiche dell'unità, è possibile aggiungere quel calcolo a questo post. Se il rischio sia quindi accettabile o meno è una decisione dell'organizzazione.

Un altro elemento da notare è che la probabilità di guasto dell'unità può essere aumentata utilizzando gli SSD prodotti nello stesso lotto (stesso stabilimento, stesso tempo). Se non stai attento, potresti finire con tutti e 3 i nodi a causa di questo problema.

Dichiarazione di non responsabilità: i calcoli di cui sopra sono stati semplificati - sono ancora relativamente precisi.

Sto pensando che ci sarebbero molti vantaggi nell'eseguirli su array RAID0 rispetto ad altri metodi con pochi, se del caso, reali inconvenienti.

Questa è una configurazione abbastanza comune quando si eseguono AG con unità di archiviazione interne / dirette. Soprattutto con NVMe o altri dispositivi di archiviazione flash basati su PCI.

Ciò equivale semplicemente a trattare un guasto dell'unità come un guasto del server. Con un numero limitato di unità a stato solido non si ha realmente un MTBF significativamente più basso per le unità rispetto agli altri componenti a stato solido del server, e quindi si considera semplicemente ogni unità come un punto di errore per il server e sostituire / ricostruire il server in caso di guasto dell'unità.

Sono incuriosito da ciò che stai cercando di ottenere? Ti accenni che non stai provando a ottenere miglioramenti delle prestazioni da questa configurazione, quindi quale guadagno stai cercando di ottenere?

Nota sul problema delle prestazioni: se si utilizzano SSD di classe Enterprise, il calcolo RAID è davvero un tale collo di bottiglia che è necessario per migliorarlo?

Prendendo i tuoi 3 professionisti, non credo che tu l'abbia pensato abbastanza:

1. Failover SQL subito? Cosa causerà l'attivazione automatica del failover? Il server porterà l'unità offline non appena qualcuno lo colpisce? E se fosse solo un settore danneggiato su un disco? Se SQL non colpisce il settore danneggiato, eseguirà il failover? Non ne sono sicuro al 100%.

2. Riduce la possibilità di guasto complessivo per capacità TB. Il tuo pensiero sembra essere il minor numero di dischi significa meno punti di errore, ma non penso che sia giusto. Le probabilità di guasto di 1 disco rimangono le stesse se si dispone di 1 disco o 10 dischi (o 100 dischi), ma con RAID 0 significa anche che si tratta di un errore catastrofico.

3. Un SSD in più ti costerà troppo per ottenere RAID5? Capisco come RAID1 O 1 + 0 potrebbe far saltare il budget, ma 1 disco aggiuntivo?

Senza ridondanza, se un disco si guasta e il RAID diventa offline, quel nodo sarà offline fino a quando non si ricostruisce il RAID e si ripristinano tutti i database da zero. Che processo hai intenzione di prendere per farlo accadere? Non è possibile rimuovere il database dal gruppo di disponibilità poiché ciò interromperà la replica su DR, ma se non si esegue alcuna azione, gli altri due server non saranno in grado di troncare i propri file di registro. È ok? Cosa succede se fallisce il venerdì sera di un lungo weekend? Va ancora bene? I tuoi secondari possono far fronte a quella quantità di dati accumulati?

Le mie ultime domande riguarderebbero il tempo di ricostruzione che lei menziona sarà più veloce. Sei sicuro al 100% che sarà più veloce? Quanto più veloce?

La configurazione del server Brent Ozar è ancora la mia guida per configurare nuove istanze SQL. Il primo punto della guida è la convalida che non stai usando RAID0 per nessuna unità.

==== ==== UPDATE

Un pensiero in più, cosa succede quando i tuoi server secondari non sono sincronizzati con il tuo primario? Anche con la replica sincrona, i tuoi secondari possono comunque tornare automaticamente in modalità asincrona e una volta persi la possibilità di eseguire il failover automatico poiché qualsiasi failover comporterà la perdita di dati. Un paio di esempi in cui ciò potrebbe accadere:

1. Ricostruzione di un indice molto ampio: la replica potrebbe rimanere indietro su uno o entrambi i secondari
2. Errore del disco su RAID0 durante l'applicazione di patch al secondario. Il server che stai patchare potrebbe non essere in grado di tornare online a causa del fatto che il primario è offline.

Sono casi limite, ma potrebbero essere catastrofici a seconda di ciò che si perde in quei tempi.