Riprendo un post fatto ieri da StorageBod sulla tripla parità che si rifà ad un nuovo annuncio di Sun sull’implementazione del raidz von tripla parità (cioè un livello di raid con tripla parità).
A parte che per il momento è assolutamente inutile c’è chi sostiene che con l’aumentare della densità dei dischi, soprattutto quelli SATA, i tempi di ricostruzione stanno diventando abnormi e pericolosi…. allora qualcuno pensa ad aumentare i dischi di parità! ma la risposta più semplice (aumentare le parità) è quella meno intelligente (IMHO).
Aumentare i dischi di parità ha diversi difetti legati soprattutto alla maggior necessità di CPU e alla quantità di dati da gestire nel backend dei sistemi RAID compromettendo ulteriormente le performance dei sistemi!
Quindi? quale può essere una soluzione più efficace?
Prima di tutto la soluzione deve essere legata all’architettura dei sistemi e partire da due concetti fondamentali:
- il wide striping aumenta le performance anche riguardo ai tempi di ricostruzione.
- servono algoritmi di ricostruzione più furbi più legati alle singole LUN piuttosto che al raid group: definiamolo QoS per lo spare.
prima di tutto il wide striping (ultimamente ne abbiamo parlato spesso): il wide striping permette di aver un pool di dischi unico su cui distribuire il carico di lavoro, quindi se ho molti dischi, le performance (di tutte le LUN) aumentano linearmente. Ne consegue che i tempi di ricostruzione di uno spare sono più rapidi!!!
Un esempio?
se ho un raid group configurato in 6+2P avrò un grosso problema in fase di ricostruzione perchè, nel caso di una rottura, mi troverò nella spiacevole situazione di dover servire le richieste di i/o, leggere da 6/7 testine, ricostruire la parità e scrivere nel disco di spare! risultato? poche performance e tempi lunghi!
se ho un wide stripe fatto di un 48 dischi (4 tray con 4 spare), organizzato con LUN di RAID diversi, avrò 44 dischi in lettura (più performance), calcolo della parità solo nelle LUN in RAID 5 o 6, tempi di risposta molto più brevi e prestazioni accettabili durante la ricostruzione!
Distribuendo il carico su tutto il sistema ottengo risultati di eccellenza, un disco SATA da 1TB (utilizzato oltre il 80%) ha un tempo di ricostruzione dell’ordine delle 16 ore (visto sul campo con un Compellent con un controller serie 20 in produzione da un cliente), circa la metà di quello che ci mette un array paragonabile HDS AMS1000 (2 controller RAID-6 12D+2P)!!!
Abbattere i tempi di ricostruzione diminuisce la possibilità di perdita di dati dovuta a più rotture in poco tempo.
Perchè tempi così diversi?
- Compelent non ricostruisce il disco ma le LUN! quindi se ho il disco occupato per un 50% ho un tempo di ricostruzione del 50% mentre un raid group tradizionale viene ricostruito comunque al 100%.
- leggendo da tutti i dischi e organizzando le scritture in modo opportuno, saturo sicuramente il disco di spare senza saturare la capacità del singolo raid group o, ancora peggio, il back-end del singolo cassetto/loop coinvolto nella ricostruzione.
- se all’interno dell’array ho LUN di livello raid diverso mi troverò una ricostruzione molto più rapida per le LUN raid 1 seguite poi dal raid 5 e 6!
E’ difficile paragonare sistemi così diversi ma il cliente in questione è rimasto piacevolmente colpito quando l’ha scoperto, 😉
Anche in questo caso ho dei vantaggi non indifferenti: se la ricostruzione avviene per LUN, ho una alta probabilità che più rotture non influiscano su tutti i dati/LUN ma solo su parte di essi, in ogni caso solo su quelle LUN coinvolte dal particolare fail e non tutto il raid group…. statisticamente parlando il wide striping è più sicuro.
E il QoS per lo spare?
Non tutte le LUN dovrebbero avere le stesse priorità di ricostruzione: nei sistemi attuali la ricostruzione avviene per RAID group senza guardare cosa c’è dentro… questo è sbagliato e non tiene conto dei dati che ci sono dentro le LUN!!! 🙁
La ricostruzione dovrebbe essere fatta dando priorità a chi ne ha più bisogno: le snapshot o le clonazioni vengono dopo le LUN di produzione, il RAID 6 viene dopo il RAID 1, ecc. , ecc. , ecc. (ovviamente sono tutti esempi)
In questo modo si potrà avere una ricostruzione più rapida delle LUN critiche e quindi più importanti per poi occuparsi di quelle meno sensibili per la vita dell’azienda. Si potrebbe anche modificare la quantità di CPU dedicate dai controller in funzione di quanto è critica la singola LUN!
Un sistema moderno dovrebbe prevedere questa possibilità… ma oggi non penso che lo faccia nessuno!
il discorso è lungo e complesso, questo è solo l’inizio 😉
ES