Se hai due unità fisiche:
RAID0: veloce ma senza ridondanza. Qualsiasi errore dell'unità ucciderà l'intero array. Alcune persone mettono l'archiviazione temporanea su RAID0 (ovvero tempdb sotto MSSQL) ma lo considererei comunque pericoloso poiché mentre non perderai alcun dato significativo se l'array che cade su di te avrà un'interruzione del server fino a quando la situazione non viene riparata.
RAID1: scegli se hai due unità. Non vi è alcun vantaggio in termini di prestazioni di scrittura sebbene si possa vedere un aumento delle prestazioni di lettura con un buon controller. La caratteristica chiave di RAID1 sta sopravvivendo a una delle unità che muoiono.
Se hai tre unità fisiche:
Le opzioni disponibili sono RAID5, il RAID10 non standard a 3 unità (o RAID1E come indicato dai controller IBM) se supportato. Ovviamente potresti usare RAID1 e mantenere l'unità extra come riserva quando uno degli altri si guasta, ma dovresti comunque conservare i pezzi di ricambio in un ambiente mission-critical, quindi è ovvio.
RAID5 offre più spazio di RAID10 (vale la pena due unità invece di una e mezza) ma presenta un potenziale problema di prestazioni di scrittura poiché per ogni blocco scritto il controller deve leggere il blocco di parità, aggiornarlo e riscriverlo. Questo problema di prestazioni di scrittura può essere raddoppiato per le scritture del database in quanto vi sono almeno due scritture per ogni aggiornamento: una nel registro delle transazioni e una nelle aree dati effettive. Poiché lo spazio è poco costoso in questi giorni, consiglierei RAID10 a 3 unità se supportato per le migliori prestazioni di scrittura. Il software RAID di Linux offre questo, così come molti controller IBM (lo chiamano RAID1E). Potresti trovarlo anche con altri nomi in quanto non è considerato un accordo standard, quindi non ha un nome standard.
Sia R5 che R10-over-three offrono la stessa ridondanza (ogni unità può guastarsi alla volta e l'array sopravvivrà) e metriche di prestazioni di lettura simili (simili a un array RAID0 a due unità).
Se hai quattro unità fisiche:
Se si crea un solo array, sono disponibili due opzioni (ignorando le varianti "con hot spare"): RAID6 e RAID10 "tradizionale" (un RAID0 di RAID1).
Entrambi danno lo stesso spazio (due unità dei quattro). RAID6 offre una ridondanza migliore in quanto due unità possono guastarsi in un momento in cui RAID10 può sopravvivere solo a quattro delle sei possibili situazioni sparite da due unità. Entrambi offrono prestazioni di lettura simili ma RAID6 ha un problema di prestazioni di scrittura simile a RAID5 (lo stesso su un buon controller, anche se può essere più lento di RAID5 su un controller difettoso o con RAID software a seconda del sistema operativo e delle capacità di controllo I / O. RAID10 è di solito preferito per i database per motivi di prestazioni: se è necessaria la ridondanza aggiuntiva, è possibile utilizzare sei unità e disporre di un RAID0 o 2 RAID1 a 3 unità.
Una volta che hai quattro o più unità anche se le cose diventano più interessanti in quanto potresti avere una coppia separata di array RAID1. Ciò può offrire significativi vantaggi in termini di prestazioni con i dischi rotanti mantenendo i tuoi archivi di dati su un array e i registri delle transazioni su un altro - questo può ridurre considerevolmente i movimenti della testa in alcuni casi e i tempi di ricerca dovuti all'accesso "casuale" sono un vero killer delle prestazioni. Per un data warehouse, supponendo che ciò significhi che vedrà pochissime scritture relativamente parlando, dividere i log delle transazioni dai file di dati potrebbe essere di beneficio più limitato, ma potresti comunque voler considerare più array e invece suddividere i dati su di essi per prestazioni di lettura potenzialmente migliori .
Se hai più di quattro unità:
Le opzioni si spalancano qui e dipende davvero da quali sono i tuoi dati e quali sono i tuoi aggiornamenti / carichi previsti / modelli previsti. Ad esempio, una volta che i nostri servizi vengono eseguiti su unità da 12 ~ 70 Gb:
- 4x come RAID10 per le aree di sistema (sistema operativo, SQL Server (nel nostro caso MSSQL), swap, tempdb).
- 4x come RAID10 per i file di dati
- 4x come RAID10 per i registri delle transazioni
Tempdb viene mantenuto sull'array di sistema. Potremmo spostarlo negli altri due array ed eseguire l'array di sistema come 2 unità in RAID1 poiché la velocità extra non è molto necessaria per i blocchi di sistema (poiché ciò è veramente significativo solo durante l'avvio o lo scambio e ci assicuriamo che ci sia abbastanza RAM per non dover mai scambiare), ma con il modo in cui paghiamo il provider di hosting per quel set di macchine non ci costerebbe meno far cadere le due unità. I backup vanno anche nell'array di sistema, prima di essere copiati nelle posizioni di backup off-server, off-site e off-line.
Naturalmente questo è gravemente eccessivo per alcuni database (non avrebbe senso eseguire un piccolo blog server in questo modo!) Ma la nostra app principale funziona molto bene con questa disposizione.
Se si dispone di sei unità, è possibile prendere in considerazione tre array RAID1 o due array RAID10 a tre unità.
Generalmente
Sfortunatamente non esiste una vera "best practice" semplice in quanto dipende molto dalle dimensioni del sistema e dai modelli di utilizzo. Le uniche regole generali che posso pensare o sono:
- evitare RAID5 e 6 a meno che non si sappia che il problema delle prestazioni di scrittura non influirà in modo significativo
- con quattro o più unità basate su disco rotante, considera la possibilità di dividere le cose su più array per ridurre i movimenti della testa (il pieno vantaggio di più array non si applicherà ai buoni SSD in quanto non ci sono movimenti fisici della testa da considerare, anche se potresti vedere qualche differenza a seconda di la scrittura del controller degli SSD che combina strategia e così via)
- prova, prova e riprova: è sempre bene provare a trovare il tempo per verificare che la disposizione scelta sia davvero ottimale
RAID hardware o software?
In passato le prestazioni del RAID software erano inferiori a quelle dell'hardware RAID per RAID 5 a causa dei calcoli di parità e di tutte le disposizioni dovute a interfacce lente tra le unità e la CPU. Con le CPU moderne il problema di parità calc non è davvero un problema, ma se si dispone di unità molto veloci RAID hardware può ancora vincere se la velocità totale delle unità può venire da nessuna partevicino (entro un ordine di grandezza, a indovinare) a quanto velocemente la macchina può parlare con il controller del disco. Se si dispone di un array RAID1 a quattro unità (ovvero quattro copie degli stessi dati per molta ridondanza) con RAID software ogni operazione di scrittura comporterà l'invio da parte del sistema operativo di quattro lotti di dati al controller I / O, possibilmente in sequenza - con un hardware controller il sistema operativo invia solo una richiesta di scrittura e il controller invia quella alle quattro unità, probabilmente in parallelo.
Un buon RAID hardware può offrire anche altri vantaggi: alcuni controller ad alta specifica hanno cache di scrittura con backup della batteria in modo che le scritture in sospeso non vengano perse in un'interruzione di corrente anche se l'UPS si guasta, ad esempio.
Il software RAID è ovviamente più economico e più portatile, quindi non sei legato a un controller particolare se devi spostare gli array a causa di un errore del controller / macchina.
Il RAID hardware economico solitamente combina gli aspetti negativi del software e del RAID hardware con pochi (o nessuno) dei vantaggi di entrambi, quindi è meglio evitare.
Tendo a utilizzare il software RAID sui nostri server dev, test e UAT e un buon RAID hardware per server che eseguono servizi live rivolti ai clienti / al pubblico.