Alcune considerazioni sulle configurazioni dei dischi per il DAG
Questo post nasce da alcune considerazioni che qualche giorno fa si facevano con Marco (sempre ricche di spunti le chiacchierate con lui…) in merito a quale configurazione disco usare per i server del DAG. In effetti, ragionandoci un po’ su, sono uscite fuori delle cose piuttosto inaspettate e che hanno portato ad una considerazione sorprendente.
Ovviamente, la troverete alla fine del post… :-)
Come saprete il DAG è un sistema di alta affidabilità che consiste nel mantenere una o più copie dei database di Exchange 2010 su più server tenendone attiva solo una per volta. In genere i dischi usati per i DB vengono configurati come RAID di vario genere a seconda delle performance e dei livelli di ridondanza che si vogliono ottenere.
Iniziamo con alcune considerazioni riguardanti i dischi del nostro DAG, tenendo sempre in mente che tutte le scelte dovranno necessariamente rispettare i requisiti di spazio disponibile, performace ed affidabilità.
· RAID5: grande spazio a disposizione, e affidabilità al guasto del singolo disco. Per contro performance non ottimali e si rinuncia alla capacità di un disco che va usata per la parità. Considerando una configurazione con 3 dischi di capacità X avremo a disposizione una capacità complessiva di 2x per ogni singolo nodo del DAG. Se il DAG è formato da 3 nodi, significa 9 dischi di cui 3 non utilizzabili per i dati. In termini economici significa aver dedicato 1 disco per ogni RAID che dovrà essere creato all’affidabilità.
· RAID1: ci sono vantaggi marginali sulle prestazioni complessive, mentre il beneficio evidente è in termini di affidabilità. In questa configurazione viene sprecata la metà dello spazio disponibile. Considerando una configurazione con 2 dischi di capacità X avremo a disposizione una capacità pari a X. Se il DAG è costituito da 3 nodi, avremo 3 dischi non utilizzabili come capacità disponibile. In termini economici significa aver dedicato la metà dell’investimento sui dischi all’affidabilità.
· RAID1+0: è la configurazione che assicura le migliori performance in assoluto e garantisce nello stesso tempo l’affidabilità del sistema. E’ più oneroso del RAID 1 in quanto richiede la presenza di almeno 4 dischi, di cui 2 utilizzati per la ridondanza, su ciascun server. Nel caso di un DAG con 3 nodi, avremo bisogno di 12 dischi di cui 6 non utilizzabili per i dati. In termini economici significa aver dedicato la metà dell’investimento sui dischi all’affidabilità, ma con un impegno economico maggiore rispetto alla configurazione RAID 1.
Nelle valutazioni che ci porteranno alla scelta della tipologia di dischi ed evenutale RAID vanno aggiunti altre due importanti variabili
MTBF (mean time between failures) è un parametro con il quale viene valuta la qualità dei dispositivi, in sostanza indica il tempo che intercorre fra un guasto e l’altro (http://it.wikipedia.org/wiki/MTBF). Sui sitemi RAID questo valore cambia in funzione del numero di dischi
System MTBF = Component MTBF / N
e questo vuol dire che il singolo MTBF viene diviso per il numero fisico dei dischi che costituiscono il RAID
Il numero massimo di dischi è teoricamente illimitato, ma una pratica comune è di mantenere il numero massimo di dischi a 14 o meno per le implementazioni che hanno solo un blocco di parità per stripe. Le ragioni per questo limite sono che la probabilità che due dischi del sistema si rompano in successione cresce con il crescere del numero di dischi. Quando il numero di dischi in un sistema RAID-5 cresce, il MTBF del sistema nel suo complesso può persino diventare minore di quello di un singolo disco. Questo succede quando la probabilità che si rompa un secondo disco degli (N - 1) rimanenti, tra il tempo di accorgersi, sostituire e ricreare il primo disco guasto, diventi maggiore della probabilità che un singolo disco si guasti
RAID Rebuild Overhead è la quantità di IOPS (input output operation second) che devono essere aggiunti al carico previsto nel caso in cui si rompa un disco. Questi valori consigliati da MS sono:
che in pratica porta ad un calcolo tipo
SAN IOPS / (1 – 35% RAID 10 rebuild overhead) = Required RAID 10 SAN IOPS with RAID Rebuild Overhead
Applicata ad un ipotetico scenario in cui la richiesta è intorno ai 700 IOPS il risultato sarebbe 700 / (1- 35%) = 1078
Questo che vuol dire? Che in caso di fault di un disco le procedure di ripristino del RAID comporteranno un carico di lavoro che si somma al normale utilizzo della vostra SAN.
Facciamo degli esempi pratici tramite l’utilizzo dello storage calculator (http://msexchangeteam.com/archive/2009/11/09/453117.aspx). Ipotizziamo questo scenario
· DAG a 2 nodi
· 2 repliche di ogni DB
· 3000 Mailbox con 2gb di spazio
· Hard Disk da 1TB a 7.2K
Seguendo questi dati per rispondere ai requisiti di spazio, performace e affidabilità il numero di dischi necessario sarebbe
Per un totale di 29 dischi per server e 58 dischi per tutto il DAG
Cambiamo ora l’approccio… e se rinunciassimo all’affidabilità dei RAID e sfruttassimo, invece, il DAG per garantirla?
Lo scenario rimane lo stesso, ma cambiano i nodi del DAG ed il numero dele repliche
· DAG a 3 nodi
· 3 repliche di ogni DB
· 3000 Mailbox con 2gb di spazio
· Hard Disk da 1TB a 7.2K
e questa volta i dischi saranno 16 per ogni server e 48 per tutto il DAG
la differenza fra le due configurazioni, è legata all’assenza del RAID ed all’utilizzo di soluzioni JBOD.
In exchange 2010 è stato infatto introdotto il pieno supporto a soluzioni RAIDLESS, quindi dischi semplici, assenza di controller RAID o di specifiche conoscenze. Il prezzo da pagare è la necessita di avere almeno un numero superiore od uguale a 3 copie per ogni database.
A cosa porta tutto questa chiacchierata:
paradossalmente una configurazione sicura e performante per il nostro DAG si realizza usando dei singoli splindle, senza alcun tipo di RAID, avendo, però, l’accortezza di attestare su ciascuno di questi un numero di DB compatibile con il numero di I/O richiesti rispetto a quelli erogabili.
Alla prossima…
Marco & Antonio
P.S.
Per chi fosse interessato c’è un’interessante trattazione dell’argomento RAID su Wikipedia (http://it.wikipedia.org/wiki/RAID).