La storia della suddivisione degli array

Gran parte delle conoscenze mnemoniche del campo dell'IT, in particolare quelle del settore SMB, è nata alla fine degli anni '90 sulla base di una serie di fattori. I fattori principali furono che improvvisamente aziende sempre più piccole si precipitavano a informatizzarsi, Microsoft aveva reso Windows NT 4 così stabile che esisteva una base standard attorno a cui far ruotare tutto l'IT delle SMB, l'era di Internet aveva finalmente preso piede e Microsoft introdusse i propri programmi di certificazione e formazione che rimodellarono la diffusione delle conoscenze nel settore. Messi insieme, questi elementi crearono sia la necessità di nuova formazione e di buone pratiche sia un'enorme esplosione di nuovo pensiero, scrittura, documentazione, formazione, buone pratiche, regole empiriche e così via.

Per alcuni anni quasi l'intero settore venne formato sullo stesso ristretto insieme di conoscenze e molte regole empiriche divennero standard di fatto, e gran parte delle conoscenze dell'epoca venne appresa a memoria e tramandata da mentore a tirocinante in un ciclo che traghettò gran parte delle conoscenze tecniche del 1998 nei processi indiscussi e immutabili del 2012. All'epoca questo era efficace perché le pratiche erano pertinenti, ma erano passati quindici anni; tecnologia, economia, casi d'uso e conoscenze sono cambiati in modo significativo da allora.

Uno dei migliori esempi di ciò fu la celebre raccomandazione di Microsoft per SQL Server: RAID 1 per il sistema operativo, RAID 5 per i file di database e un altro RAID 1 per i log. Questa configurazione è perdurata per quasi l'intera vita del prodotto ed è stata promossa così bene da essersi diffusa in quasi tutti gli aspetti della progettazione dei server nello spazio SMB. L'uso del RAID 1 per il sistema operativo e del RAID 5 per i dati è così pervasivo che viene spesso semplicemente dato per scontato senza alcuna considerazione del perché ciò fosse raccomandato all'epoca.

Esaminiamo la storia e vediamo perché R1/5/1 fosse valido nel 1998 e perché non dovrebbe esistere oggi. Teniamo presente una certa prospettiva: il divario tra il momento in cui queste raccomandazioni comparvero per la prima volta (già nel 1995) e oggi è immenso. Tornate, mentalmente, al 1995 e pensate al divario equivalente di allora. Sarebbe stato come usare raccomandazioni nei primi tempi di Internet basate sulle esigenze informatiche domestiche della prima generazione di possessori di Apple ][! L'era dei computer domestici a 8 bit era appena agli inizi nel 1978. Commodore era ancora a due anni dal rilascio del suo primo computer domestico (il VIC-20) e avrebbe attraversato l'intera era Commodore e Commodore Amiga, sarebbe fallita e svanita, tutto prima del 1995. L'Apple ][+ era ancora a un anno di distanza. Le persone stavano giusto per iniziare a usare unità a cassetta analogiche come supporto di memorizzazione. COBOL e Fortran erano gli unici linguaggi gestionali seri in uso. Sostanzialmente, il divario è incredibile. Le cose cambiano.

Per prima cosa, dobbiamo esaminare i fattori che esistevano alla fine degli anni '90 e che crearono la necessità della nostra configurazione storica.

1. I dischi erano piccoli, molto piccoli. Un grande array di database poteva essere costituito da quattro dischi SCSI da 2,1 GB in un array R5 per appena ~6 GB di spazio di archiviazione utilizzabile su un singolo array. Il dominio di guasto per il fallimento del RAID a parità era minuscolo (rispetto a cose come i tassi di guasto URE).
2. Le tecnologie di connessione dei dischi erano parallele e lente. I dischi rigidi dell'epoca erano solo leggermente più lenti di quelli odierni, ma le tecnologie di connessione rappresentavano un collo di bottiglia considerevole. Era comune suddividere il traffico per ridurre i colli di bottiglia del bus.
3. La tecnologia dei dischi SCSI era l'unica usata per i server. L'uso di un PATA (allora chiamato IDE) in un server era impensabile.
4. I dischi erano costosi per gigabyte, quindi il risparmio sui costi era la questione chiave, mantenendo al contempo la capacità, per praticamente tutte le aziende.
5. I filesystem erano fragili e si guastavano più spesso dei dischi.
6. Il RAID hardware era obbligatorio e solo i livelli RAID di base 1 e 5 erano comunemente disponibili. Il RAID 6 e il RAID 10 erano lontani anni dall'essere accessibili alla maggior parte delle aziende. Il RAID 0 è escluso poiché non ha ridondanza.
7. I sistemi di archiviazione erano raramente, se non mai, condivisi tra server, quindi l'accesso era quasi sempre dedicato a una singola coda di richieste.
8. Le cache di archiviazione erano minuscole o inesistenti, facendo ricadere le limitazioni di accesso ai dischi direttamente sul sistema operativo. Questo significava avere array diversi con caratteristiche diverse per gestire diversi mix di accesso in lettura/scrittura o casuale/sequenziale.
9. Il guasto dei dischi era comune e la preoccupazione principale nella progettazione dei sistemi di archiviazione.
10. Spesso la dimensione dell'array di dischi era limitata da vincoli fisici, quindi spesso le decisioni di suddivisione degli array venivano prese per necessità, non per scelta.
11. Una combinazione dei fattori di cui sopra faceva sì che il RAID 1 fosse il migliore per alcune parti del sistema, dove le piccole dimensioni erano accettabili e l'accesso era altamente sequenziale o ad alta intensità di scrittura, e il RAID 5 fosse il migliore per altre, dove la capacità prevaleva sull'affidabilità e dove l'accesso era altamente casuale e ad alta intensità di lettura.

Nei quasi due decenni trascorsi dalla pubblicazione delle raccomandazioni originali, tutti questi fattori sono cambiati. In alcuni casi i cambiamenti sono a cascata, dove il passaggio dal RAID 5 di uso generale al RAID 10 di uso generale ha poi fatto sì che quelli che sarebbero stati i due tipi comuni di array, RAID 1 e RAID 10, condividessero le caratteristiche di accesso, cosicché la necessità o il desiderio di usare l'uno o l'altro a seconda del tipo di carico è venuto meno.

1. I dischi sono ora enormi. Anziché faticare per stiparci ciò che ci serve, abbiamo generalmente capacità in eccesso. Singoli dischi superiori a un terabyte sono comuni, persino nei server. I domini di guasto per la parità sono enormi (rispetto a cose come i tassi di guasto URE).
2. Le connessioni dei dischi sono seriali e veloci. Le connessioni dei dischi non sono più un collo di bottiglia.
3. Il SATA è ora comune sui server, distorcendo i potenziali rischi di URE in un modo che prima non esisteva.
4. La capacità è ora economica, ma le prestazioni e l'affidabilità sono ora le preoccupazioni chiave per il denaro speso.
5. I filesystem sono oggi altamente robusti e i guasti dei filesystem sono “rumore di fondo” nel quadro più ampio dell'affidabilità degli array.
6. Il RAID hardware e il RAID software sono entrambi opzioni oggi e i livelli RAID disponibili includono molte opzioni ma, cosa più importante, il RAID 10 è disponibile ovunque.
7. I sistemi di archiviazione sono comunemente condivisi, rendendo l'accesso sequenziale ancora meno comune.
8. Le cache di archiviazione sono comuni e spesso molto grandi. Cache da 512 MB e 1 GB sono considerate normali oggi, facendo sì che molti array del 1995 entrino oggi interamente nella memoria del controller RAID. Con le cache che crescono rapidamente rispetto alla capacità di archiviazione e con la recente aggiunta delle unità a stato solido come cache L2 nello storage negli ultimi due anni, non è da escludere che persino una piccola azienda abbia database e altre applicazioni sensibili alle prestazioni che girano completamente dalla cache.
9. Il guasto dei dischi è raro e di banale rilevanza per la progettazione dei sistemi di archiviazione (rispetto ad altri tipi di guasto).
10. La dimensione dell'array di dischi è raramente limitata da vincoli fisici.
11. L'uso del RAID 1 e del RAID 10 come tipi di array principali oggi significa che non c'è alcun vantaggio nell'usare livelli di array diversi per l'ottimizzazione delle prestazioni.

Questi fattori evidenziano perché il sistema di array suddivisi del 1995 avesse perfettamente senso all'epoca e perché non abbia senso oggi. OBR10, lo standard odierno, non era disponibile all'epoca ed era proibitivo per costi. Il RAID 5 era relativamente sicuro nel 1995, ma non oggi. Quasi ogni fattore coinvolto nel processo decisionale è cambiato drasticamente negli ultimi diciassette anni e continuerà a cambiare man mano che gli SSD diventeranno più comuni, insieme all'auto-tiering, a cache ancora più grandi e a sistemi di archiviazione interamente SSD.

Il cambiamento nella progettazione dello storage nell'ultimo paio di decenni evidenzia anche i pericoli che l'IT affronta dato che gran parte del settore apprende, come è comune nell'ingegneria, le “regole empiriche” o “buone pratiche” di base senza necessariamente comprendere i principi sottostanti che guidano quelle decisioni, rendendo difficile sapere quando non applicare quelle buone pratiche o, cosa ancora più importante, quando riconoscere che la regola non è più valida. A differenza dell'ingegneria meccanica o civile tradizionale, dove nuovi progressi e cambiamenti significativi dei fattori possono verificarsi una volta sola o forse mai nel corso di una carriera, l'IT cambia ancora abbastanza in fretta da rendere necessari completi “ripensamenti” delle regole empiriche di base più volte nell'arco di una carriera. Forse non ogni anno, ma una volta per decennio o più è quasi sempre necessario.

L'attuale passaggio dall'elaborazione a processore singolo alle architetture multithread è un altro cambiamento simile e significativo che richiede al settore dell'IT di modificare completamente il modo in cui viene gestita la progettazione dei sistemi.