Dischi del SO Lenti, Dischi dei Dati Veloci

Nel corso degli anni ho riscontrato che le persone spesso propendono per uno storage ad alte prestazioni e altamente affidabile per la partizione del sistema operativo, ma scelgono storage lento e “conveniente” per archivi di dati critici. Mi stupisce quanto spesso mi capiti di riscontrarlo e ora, con l'avvento degli hypervisor, vedo lo stesso comportamento ripetersi anche lì – aggravando le problematiche già esistenti.

In molti sistemi odierni abbiamo a che fare con un solo array di storage condiviso da tutti i componenti del sistema. In questi casi non affrontiamo il problema dello sbilanciamento delle prestazioni del nostro sistema di storage. Questo è uno dei grandi vantaggi di questo approccio e una delle ragioni principali per cui è così fortemente raccomandato. Tutte le prestazioni risiedono in un pool condiviso e i componenti che necessitano delle prestazioni vi hanno accesso.

In molti casi, sia nel tentativo di una progettazione orientata a maggiori prestazioni o affidabilità, sia per necessità tecnica, riscontro che le persone separano i propri array di storage, mettendo hypervisor e sistemi operativi su un array e i dati su un altro. Ma ciò che trovo sconvolgente è che gli array dedicati all'hypervisor o al sistema operativo hanno spesso una capacità incredibilmente grande e prestazioni estremamente elevate – coinvolgendo spesso dischi a 15.000 RPM o persino dischi a stato solido con grande dispendio. Quasi sempre in RAID 1 (secondo gli standard comuni del 1998).

Ciò che bisogna comprendere qui è che i sistemi operativi in sé non hanno praticamente alcun requisito di IO di storage. Ce n'è una piccola quantità, principalmente per il logging di sistema, ma è più o meno tutto ciò che serve. Le partizioni del sistema operativo sono quasi completamente statiche. I componenti richiesti vengono caricati in memoria, per lo più all'avvio, e non vengono più acceduti. Anche nei casi in cui il logging è necessario, molte volte questi log vengono inviati a un sistema di logging centralizzato e non all'area di storage del sistema, riducendo o persino eliminando anche quella esigenza.

Con gli hypervisor questo effetto è ancora più estremo. Poiché gli hypervisor sono molto più leggeri e meno robusti dei sistemi operativi tradizionali, si comportano più come sistemi embedded e, per molti versi, in molti casi sono effettivamente sistemi embedded. Gli hypervisor vengono caricati in memoria all'avvio del sistema e il loro supporto non viene quasi mai più necessario mentre un sistema è in esecuzione, tranne che per il logging in alcune occasioni. Poiché gli hypervisor sono di piccole dimensioni fisiche, persino il tempo totale necessario per leggere completamente un intero hypervisor dallo storage è molto ridotto, anche su supporti molto lenti, perché la dimensione totale è molto piccola.

Per queste ragioni, le prestazioni dello storage hanno scarsa o nessuna rilevanza per i sistemi operativi e specialmente per gli hypervisor. La differenza tra storage veloce e storage lento incide realmente solo sul tempo di avvio del sistema, dove la differenza tra un secondo e trenta secondi raramente verrebbe notata, se mai lo fosse. Quando mai qualcuno percepirebbe anche solo diversi secondi in più durante l'avvio di un sistema e, nella maggior parte dei casi, gli avvii sono eventi rari che si verificano al massimo una volta a settimana durante un riavvio di sistema automatizzato e di routine in una finestra di manutenzione pianificata o molto raramente, talvolta solo una volta ogni diversi anni, per sistemi che vengono messi offline solo in caso di emergenza. Persino il sistema di storage più lento concepibile è di gran lunga più veloce del necessario per questo ruolo.

Persino lo storage lento è generalmente molte volte più veloce di quanto sia necessario per le attività di logging di sistema. In quei rari casi in cui il logging è molto intenso, abbiamo molte scelte su come affrontare questo problema. La soluzione più ovvia e comune qui è inviare i log a un array di dischi diverso da quello utilizzato dal sistema operativo o dall'hypervisor. Questa è una soluzione molto semplice e in definitiva molto pratica nei casi in cui sia giustificata. L'altra soluzione comune e altamente utile è semplicemente astenersi dal conservare i log sul dispositivo locale e inviarli a un'utility di raccolta log remota come Splunk, Loggly o ELK.

L'altra grande preoccupazione che la maggior parte delle persone ha riguardo ai propri sistemi operativi e hypervisor è l'affidabilità. È comune concentrare maggiori sforzi nel proteggere questi aspetti relativamente poco importanti di un sistema piuttosto che i dati, spesso insostituibili. Tuttavia, i sistemi operativi e gli hypervisor sono facilmente ricostruibili da zero quando necessario, utilizzando installazioni pulite e una riconfigurazione manuale quando occorre. I dettagli che potrebbero andare persi sono generalmente relativamente banali da ricreare.

Questo non significa che questi filesystem di sistema non debbano essere sottoposti a backup, naturalmente devono esserlo (nella maggior parte dei casi). Ma anche nel caso in cui falliscano pure i backup, è raro che la perdita di una partizione o di un filesystem del SO rappresenti davvero una tragedia, bensì solo un inconveniente. Esistono modi per recuperare in quasi tutti i casi senza accesso ai dati originali, purché il filesystem dei “dati” sia separato. E a causa della natura dei sistemi operativi e degli hypervisor, il cambiamento è raro, quindi i backup possono generalmente essere meno frequenti, possibilmente attivati manualmente solo quando vengono applicati gli aggiornamenti!

Con molti sistemi moderni negli ambiti DevOps e Cloud computing è diventato molto comune considerare i sistemi operativi e i filesystem degli hypervisor come del tutto sacrificabili, dal momento che sono definiti in remoto tramite un'immagine di sistema o da un sistema di gestione della configurazione. In questi casi, che stanno diventando sempre più comuni, non c'è alcuna necessità di protezione dei dati o di backup, poiché l'intero sistema è progettato per essere ricreato, in modo quasi istantaneo, senza alcuna interazione particolare. Il sistema è interamente auto-replicante. Ciò banalizza ulteriormente la necessità di protezione del filesystem di sistema.

Nel complesso, l'assenza di necessità riguardo alle prestazioni e l'assenza di necessità riguardo alla protezione e all'affidabilità, gestita principalmente attraverso la semplice ricreazione, e ciò che abbiamo è un filesystem di sistema con esigenze molto diverse da quelle che comunemente assumiamo. Questo non significa che dovremmo essere avventati con il nostro storage: vogliamo comunque evitare un guasto dello storage mentre un sistema è in esecuzione, e ricostruire inutilmente è uno spreco di tempo e risorse anche se non si rivela disastroso. Quindi è importante trovare un attento equilibrio.

È, naturalmente, per queste ragioni che includere il sistema operativo o l'hypervisor sullo stesso array di storage dei dati è ora una pratica comune – perché c'è poca o nessuna necessità di accesso allo storage per i file di sistema nello stesso momento in cui c'è accesso ai file di dati, quindi otteniamo una grande sinergia ottenendo tempi di avvio veloci per il SO e nessun impatto negativo sui tempi di accesso ai dati una volta che il sistema è online. Questo è il mezzo principale con cui i progettisti di sistema affrontano oggi la necessità di un uso efficiente dello storage.

Quando il sistema operativo o l'hypervisor deve essere separato dagli array che contengono i dati, cosa che può comunque accadere per innumerevoli ragioni, generalmente cerchiamo di ottenere un'affidabilità ragionevole a basso costo. Quando si utilizza lo storage tradizionale (dischi locali) questo significa usare dischi rotanti piccoli, lenti e a basso costo per lo storage del sistema operativo, generalmente in una semplice configurazione RAID 1. Un esempio del mondo reale è l'uso di dischi SATA “eco-friendly” a 5400 RPM nelle dimensioni più piccole possibili. Questi assorbono poca energia e sono molto economici da acquistare. Gli SSD e i dischi SAS ad alta velocità andrebbero evitati, poiché hanno un costo aggiuntivo per una protezione che è irrilevante e prestazioni che sono completamente sprecate.

Nello storage meno tradizionale è comune utilizzare una SAN a basso costo e alta densità, consolidando lo storage a bassa priorità di molti sistemi su array condivisi e lenti che non vengono replicati. Questo è efficace solo in ambienti più grandi che possono giustificare la progettazione architetturale aggiuntiva e che possono raggiungere una densità sufficiente nel processo di consolidamento dello storage per generare i necessari risparmi sui costi, ma negli ambienti più grandi ciò è relativamente facile. I dispositivi di boot SAN possono sfruttare array a costo molto basso su molti server per risparmiare sui costi. Nello spazio virtuale ciò potrebbe significare un datastore a basse prestazioni utilizzato per i dischi virtuali del SO e un altro pool ad alte prestazioni per i dischi virtuali dei dati. Questo avrebbe lo stesso effetto della strategia di boot SAN, ma in un contesto più moderno e potrebbe facilmente sfruttare l'architettura SAN sottostante per realizzarlo.

Infine, e in modo più clamoroso, è una regola pratica generale con gli hypervisor installarli su schede SD o chiavette USB anziché su storage tradizionale, dato che le loro esigenze di prestazioni e affidabilità sono molto inferiori persino a quelle dei sistemi operativi tradizionali. Normalmente, se un disco di questo tipo si guastasse mentre un sistema è in esecuzione, esso continuerebbe di fatto a funzionare senza alcun problema, poiché il disco non viene mai utilizzato una volta che il sistema è stato avviato inizialmente. Sarebbe solo durante un riavvio che si riscontrerebbe un problema e, in quel momento, si potrebbe usare un dispositivo di boot di riserva, come una seconda scheda SD o una chiavetta USB. Questa è la raccomandazione ufficiale per VMware vSphere, è spesso raccomandata dai rappresentanti Microsoft per HyperV ed è ufficialmente supportata tramite i fornitori OEM di HyperV ed è spesso raccomandata, ma non così ampiamente supportata, per i sistemi Xen, XenServer e KVM. L'uso di schede SD o dischi USB per lo storage dell'hypervisor trasforma di fatto un server di virtualizzazione in un sistema embedded. Sebbene ciò possa sembrare innaturale agli amministratori di sistema abituati a pensare ai dischi tradizionali come a una necessità per i server, è importante ricordare che sistemi di classe enterprise altamente critici, come router e switch, durano decenni e utilizzano esattamente questa stessa strategia per esattamente le stesse ragioni.

Una strategia comune per gli hypervisor in questa modalità di tipo embedded con schede SD o dischi USB è avere due di tali dispositivi, che possono in realtà essere una scheda SD e un disco USB, ciascuno con una copia dell'hypervisor. Se un dispositivo si guasta, avviare dal secondo dispositivo è quasi altrettanto efficace di un sistema RAID 1 tradizionale. Ma a differenza della maggior parte delle configurazioni RAID 1 tradizionali, abbiamo anche un mezzo relativamente facile per testare gli aggiornamenti di sistema, aggiornando un solo dispositivo di boot alla volta e collaudando il processo prima di aggiornare il secondo dispositivo di boot, lasciandoci con un fallback affidabile e ben collaudato nel caso in cui un aggiornamento di versione vada storto. Questo processo era in realtà comune sui grandi sistemi UNIX RISC, dove i dispositivi di boot erano spesso set RAID 1 software locali che supportavano una pratica simile, particolarmente comune negli ambienti AIX e Solaris.

Va inoltre notato che, sebbene questo approccio sia la best practice per la maggior parte degli scenari con hypervisor, non c'è in realtà alcun motivo per cui non possa essere applicato anche ai filesystem completi dei sistemi operativi, se non che spesso comporta più lavoro. Alcuni SO, specialmente Linux e BSD, sono molto abili nell'essere installati in modalità embedded e possono facilmente essere adattati per l'installazione su scheda SD o disco USB con un po' di pianificazione. Questo approccio non è affatto comune, ma non c'è alcun motivo tecnico per cui, nelle giuste circostanze, non sarebbe un approccio eccellente, se non per il fatto che quasi mai un SO dovrebbe essere installato su hardware fisico anziché sopra un hypervisor. In quei casi in cui le installazioni fisiche sono necessarie, allora questo approccio è estremamente valido.

Quando progetti e pianifichi i sistemi di storage, ricordati di prestare attenzione a come si presenteranno realmente i pattern di lettura e scrittura quando un sistema è in esecuzione. E ricorda che lo storage è cambiato in modo piuttosto drastico da quando sono state sviluppate molte linee guida tradizionali e che non tutta la conoscenza utilizzata per svilupparle si applica ancora oggi o si applica in egual misura. Pensa non solo a quali sottosistemi di storage tenteranno di utilizzare le prestazioni dello storage, ma anche a come interagiranno tra loro (ad esempio, due sistemi non richiedono mai l'accesso allo storage nello stesso momento o entreranno regolarmente in conflitto) e se le loro prestazioni di accesso siano importanti. Le funzioni generali del sistema operativo possono essere estremamente lente su un server di database senza alcun impatto negativo; tutto ciò che conta è la velocità con cui è possibile accedere a un database. Persino l'accesso ai binari delle applicazioni è spesso irrilevante, poiché anch'essi, una volta caricati in memoria, vi rimangono e solo la velocità della memoria incide sulle prestazioni continuative.

Nulla di tutto questo intende suggerire che separare i sottosistemi di storage del SO e dei dati l'uno dall'altro sia consigliabile, spesso non lo è. Ho scritto in passato di come consolidare questi sottosistemi sia molto frequentemente la linea d'azione migliore, e ciò rimane vero anche ora. Ma ci sono anche molti casi ragionevoli in cui ha senso separare determinate esigenze di storage l'una dall'altra, spesso quando si ha a che fare con sistemi su larga scala in cui possiamo abbassare i costi dedicando storage ad alto costo a determinate esigenze e storage a basso costo ad altre esigenze, ed è in quei casi che voglio dimostrare che i sistemi operativi e gli hypervisor dovrebbero essere considerati la priorità più bassa in termini sia di prestazioni che di affidabilità, tranne nei casi più estremi.