Consiglio per array RAID SAS. | Stampa

Ciao, stò configurando l'array dati di una DL380 G6 che servirà come server MS hyper-v R2.
Le istanze virtualizzate sulla macchina saranno un DC, una istanza servizi (consolle antivirus, MS SystemCenter, websense) e una istanza si sviluppo (Win2008-R2 con SQL2008 SP2 e MS TeamFoundation Server. In questa configurazione non verrà un missile ma va bene lo stesso).

Mi chiedevo quale sia la configurazione più idonea per il volume RAID su cui andrò ad appoggiare le vm.
Attualmente il sistema operativo è installato su un volume dedicato RAID1 da 146Gb con dischi SAS 10k rpm 2,5".
Per l'array dati ho a disposizione 7 hdd 15k rpm SAS 2,5" su controller P410 512Mb dedicato. Uno andrà sicuramente in "hot-spare" quindi ho sei dischi da utilizzare per l'array.
Inizialmente pensavo ad un RAID50 ma mi è venuto il dubbio che possa non essere la soluzione più performante. Avendo diverse istanze che lavorano sullo stesso volume, credo mi convenga puntare su alti valori di I/O piuttosto che magari su più alti valori di trasferimento sequenziale. Stò facendo alcuni test per vedere cosa salta fuori ma intanto volevo anche un parere motivato.

Inoltre in una configurazione RAID0/5 o superiore c'è da considerare anche l'influenza del valore dello stripe size. Non ho mai potuto fare test approfonditi sull'influenza di questo parametro... Qualcuno ha esperienze in merito??

Potresti fare 2 RAID 5 di 3 dischi ciascuno
Il primo dedicato al DC e Servizi
Il secondo per l'istanza di sviluppo, eventualmente in modalità pass, ovvero l'OS si attacca direttamente al volume, senza usare VHD.
Se invece se in ottica di scalare, fai un unico raid 5 con tutto. DC e servizi consumano relativamente poche risorse, TFS (sperando che sia l'ultima versione :D) è esoso solo se ha il build server, per l'I/O di sql dipende dal carico previsto.

Quindi secondo te è meglio il RAID5 piuttosto che il RAID50... Ma il RAID50, non dovrebbe beneficiare dello stripe tra i due parity group per recuperare in parte quello che il RAID5 perde nelle letture/scritture random? Dovrebbe quindi essere la soluzione ottimale per l'utilizzo su dbserver.
Oltre, credo, a garantire una maggiore sicurezza dei dati in quanto dovrebbe permettere di perdere due dischi dell'array (uno per parity group) prima di obbligare al disaster recovery (ma questo lo verifico domani!)

Stò facendo alcune misurazioni a spanne con HD Tune pro e mi sembra che i valori di IOPS ottenibili in configurazione RAID5 e RAID50 siano assolutamente allineate e comprese nel range dei 170-180 IOPS in lettura per i 4k. Si scende tra i 140-150 IOPS per i 64k. Anche le prestazioni sequenziali sono grosso modo allineate. Tra raid5 e raid50 ci saranno si e no 30mb/s a favore del RAID50, come best result, sul valore medio. Pensavo di più...

Per quanto riguarda i dischi pass, da quello che stò leggendo in giro in Windows 2008 R2 le prestazioni dei dischi dinamici e ad espansione fissa dovrebbero essere considerevolmente migliorate e quasi allineate.
L'uso dei dischi pass, come giustamente dici, dovrebbe essere ancora la soluzione più performante ma ha lo svantaggio di "limitare" la flessibilità della soluzione virtualizzata sia in termini di portabilità della vm che in termini di spazio occupato. Dedicare un array tramite pass significherebbe assegnare quasi 300Gb dello spazio disponibile alla vm di sviluppo che attualmente (tra Win2008r2, SQL2008 e TFS 2010) non arriva a 60Gb di spazio occupato e, per quanto i nostri sviluppatori facciano fuoco e fiamme sulla tastiera, dubito che potrà in tempi brevi superare i 150Gb... Per ora sarei quindi per scartare la soluzione con array pass.

Come non detto, i result sul RAID5 sono da rifare, devo aver sbagliato qualcosa.
La differenza tra RAID5 e RAID50 effettivamente c'è... Appena ho finito posto due results.

Alla fine mi sa che hai ragione: I result che riesco ad ottenere sul RAID50 sono strani ed incostanti...

Probabilmente un unico RAID5 sarà la scelta finale, con stripe a 64k (e quindi, praticamente con le impostazioni di default del controller).