Partiamo dalla storia.
Gli array tradizionali implementato una tecnologia chiamata RAID (redundant array of inexpensive disks) questa tecnologia è stata brevettata da IBM nel 1978!!! e poi adottata successivamente da tutti.
Non penso che ci sia molto da aggiungere, tutti i possessori di un Array hanno a disposizione una implementazione RAID di un qualche tipo… simile a quella del 1978 di 30 anni fà!!!
ll problema del RAID è nell’organizzazione dei dischi all’interno dell’array (i Raid Group o Raid Set): molti vendor hanno dei limiti sulla dimensione del raid group, tipologie di raid utilizzabile in funzione del tipo di disco, “best practices” consolidate con raid group precisi per fare workload precisi, costrizioni di vario tipo/genere/natura.
In pratica quanto acquisto un Array di tipo tradizionale devo sempre analizzare bene le limitazioni imposte dal raid e dalla particolare implementazione… molto spesso devo aggiungere componenti esterne quali, ad esempio, Volume Manager per aggirare questi problemi.
Di per se non è sbagliato usare un VM anche se questo significa aumentare la complessità del sistema, aggiungere un altro strato di software, in alcuni casi anche costoso!
Devo fare un esempio pratico ?
Sono stato poco tempo fà da un cliente che ha un sistema tradizionale di fascia enterprise (non faccio nomi volutamente… spero di sostituirlo al più presto 😀 ). Il sistema è collegato ad una serie di server ma io ne prenderò solo uno ad esempio (questo server usa Solaris+VxVM).
Partiamo dall’array: questo sistema, per come è fatto, ha dei raid group “standard” (fortemente consigliati dal vendor!!) di 8 HD quindi 4+4 o 7+1P o 6+2P in funzione del tipo di RAID….
Significa che una LUN in RADI 1 è formata da 8 HD e che in scrittura o 4 testine disponibili (forse 8 in lettura se posso fare affidamento su un qualche meccanismo di round robin)… Risultato? ho, al massimo 708 i/o sec disponibili per un accesso tipico di database puramente randomico (un hd da 15K fà mediamente 177 i/o).
il DB non è esageratamente grande ma e molto acceduto avrei bisogno di almeno 7000 i/o e 708 i/o sono decisamente troppo poche… come faccio allora?
Le strade sono due (e veniamo al server):
La prima è quella di distribuire, a mano con tanto impegno e spesso pochi risultati, le i/o ipotetiche su un numero il più possibile ampio di LUN. Questo approccio rende più complicata la gestione a livello applicativo, di backup e di manutenzione. In particolare diventa complicata la pianificazione dello storage, il suo monitoraggio e la rimozione degli hotspot (picchi di i/o su una singola lun che affliggono poi tutte le performance del sistema).
La seconda possibilità (adottata dal cliente.. per la felicità di chi gli ha venduto il VM) è quella di dotarsi di un buon Volume Manager (VxVM di Symantec o ASM di Oracle) comunque la mettiamo un oggetto complicato per cui è necessario un addestramento, da gestire e manutenere, in alcuni casi, da pagare (salato, appunto)!
L’utilizzo che si fà del Volume Manager è quello di affettare i volumi ottenuti dai raid group in piccole LUN e organizzarle poi in stripe (raid 0) !
Esatto! avete comprato un array che fà il raid 1+0 e poi affidate ad uno strumento software la distribuzione delle i/o per migliorare le performace come fosse una specie di load balancer… non vi sembra allucinante ?
Nel caso del cliente citato abbiamo 10 lun per ogni path per un totale di 40 path per ogni lun al quale aggiungo i path virtualizzati dallo strato di software che fà il multipath (ovviamento non del sistema operativo visto che uso VxVM)…. il server ha molte lun e la moltiplicazione di lun x path rende quasi impossibile individuare le lun/path nuovi quando ne creo. 😀
Inoltre l’uso di un VM implica una serie di restrizioni sull’uso degli strumenti messi a disposizione dall’array… snapshot, clonazioni, copie remote, tuning manager vari, ecc., ecc.
ah! dimenticavo… 7000 i/o significano 80HD da 146 GB/15K! per un totale, in raid 1, di 5.8TB di spazio… ovviamente usato per il 30/40% e il resto sprecato!!!!!!!!!!!
Adesso veniamo al 2009 (30 anni dopo).
E
sistono dei vendor (esempio? Compellent 😀 ) che hanno rivisto il concetto di RAID e hanno ridisegnato da zero l’architettura permettendo di eliminare i limiti del RAID del 1978.
Il concetto è semplice e si tratta di portare a livello di singolo blocco le informazioni del RAID (insieme a queste anche un’altra serie di metadati molto utili per fare un sacco di altre cose!);
Il risultato è quello di avere un unico pool di dischi con tutti (e dico tutti: FC/SSD/SAS/SATA) che agiscono contemporaneamente per sprigionare tutte le i/o possibili e utilizzare al meglio lo spazio!
Il meccanismo di ripartizione del carico su tutti i dischi si chiama appunto wide striping!
Adottando questa architettura ogni server della SAN può godere delle performance necessarie alle proprie applicazioni semplificando di molto (diciamo annullando!) la complessità operativa e la scalabilità del sistema è lineare e semplificata (ogni disco aggiunto viene immediatamente coinvolto attraverso un meccanismo di restripe).
Aggiungo anche che non ho più bisogno di un Volume Manager e riseco ad utilizzare tutte le features software messe a disposizione, tante e facili da usare, thin provisioning, snapshot e repliche molto più efficienti, tiering del dato automatico ecc, ecc., proprio perchè non ci sono più le limitazioni degli storage tradizionali (o arcaici che dir si voglia. 😀 )
ES