Uova virtuali e cesti

Parlando con i professionisti IT delle piccole imprese, uno dei fattori chiave dell'esitazione nell'adottare la virtualizzazione nasce da ciò che viene descritto come “non mettere tutte le uova nello stesso cesto”.

Posso capire da dove nasca questa preoccupazione. La virtualizzazione consente di contenere molti sistemi operativi guest in un singolo sistema fisico che, in caso di guasto hardware, fa sì che tutti i sistemi guest che vi risiedono si guastino insieme, tutti in una volta. Questo suona male, ma forse non è così grave come potremmo presumere a prima vista.

L'idea del modo di dire delle uova e dei cesti è che non dovremmo mettere a rischio tutte le nostre risorse contemporaneamente. Questo viene generalmente applicato agli investimenti, incoraggiando gli investitori a diversificare e a investire in molte aziende e tipologie di titoli diverse, come obbligazioni, azioni, fondi e materie prime. Nel caso delle uova (o del denaro) stiamo parlando di una merce intercambiabile. Un uovo vale l'altro. Un insieme di uova è naturalmente ridondante.

Se abbiamo una dozzina di uova e ne rompiamo sei, possiamo comunque preparare una frittata, magari più piccola, ma possiamo comunque mangiare. Mangiare una frittata più piccola sarà probabilmente quasi soddisfacente quanto una più grande – in ogni caso non rimaniamo a digiuno. Mettere le nostre uova, già ridondanti, in più cesti ci permette di ridurre i rischi. Sì, portare due cesti significa che abbiamo meno tempo da dedicare a ciascuno di essi, quindi aumenta il rischio di perdere alcune delle uova, ma riduce le probabilità di perderle tutte. Nel caso delle uova, una proposta saggia in effetti. Allo stesso modo, un modo intelligente per prepararsi alla pensione.

Questa teoria, poiché viene ripetuta come un modo di dire senza un'analisi attenta o una corretta comprensione, viene poi applicata ad ambiti non correlati come la virtualizzazione dei server. I server, tuttavia, non sono come le uova. I server, specialmente nelle imprese più piccole, sono raramente merci intercambiabili in cui averne sei funzionanti, invece dei soliti dodici, è abbastanza buono. Tipicamente ogni server svolge un ruolo unico e tutti sono relativamente critici per il funzionamento dell'azienda. Se un server non è critico, è improbabile che possa giustificare il costo di acquisirlo e mantenerlo in primo luogo, e quindi probabilmente non esisterebbe. Quando i server sono intercambiabili, come in una grande web farm stateless o in un cluster di calcolo, sono configurati come tali come mezzo per espandere la capacità oltre i confini di un singolo box fisico e quindi esulano dall'ambito di questa discussione.

I servizi IT in un'azienda sono di solito, almeno in una certa misura, una “dipendenza a catena”. Vale a dire, sono interdipendenti e la perdita di un singolo servizio può avere un impatto su altri servizi, sia perché sono tecnicamente interdipendenti (come un'applicazione gestionale dipendente da un database) sia perché sono interdipendenti a livello di flusso di lavoro (come un impiegato d'ufficio che ha bisogno che il file server funzioni per poter fornire un file che deve modificare con informazioni provenienti da un'e-mail, mentre discute le modifiche al telefono o tramite messaggistica istantanea). In questi casi, la perdita di un singolo servizio chiave come l'e-mail, l'autenticazione di rete o i servizi di file può creare una perdita sproporzionata della capacità lavorativa. Se vi sono dieci servizi chiave e uno va in down, la produttività aziendale dal punto di vista dei servizi IT probabilmente cala di molto più del dieci percento, avvicinandosi forse al cento percento nei casi estremi. Questo non è sempre vero: in alcuni casi particolari i lavoratori sono in grado di “aggirare” efficacemente un servizio perduto, ma ciò è molto raro. Anche se le persone riescono a continuare a lavorare, è probabile che siano molto meno produttive del solito.

Quando si ha a che fare con server fisici, ogni server rappresenta il proprio punto di guasto. Quindi, se abbiamo dieci server, abbiamo dieci volte la probabilità di un'interruzione rispetto a quando avevamo uno solo di quegli stessi server. Ogni server che aggiungiamo porta con sé il proprio rischio. Se ogni guasto ha un fattore di interruzione di 2,5 – cioè impatta finanziariamente l'azienda per il venticinque percento del fatturato per, diciamo, un giorno, allora il nostro impatto medio totale nell'arco di un decennio equivale a due interruzioni totali del sito e mezza. Uso qui il concetto di fattori e medie per semplificare le cose: non è necessario determinare la durata di un'interruzione media o l'impatto di un'interruzione media, poiché in questo caso dobbiamo solo determinare l'impatto relativo per confrontare gli scenari. È semplicemente un modo per confrontare l'impatto finanziario cumulativo delle interruzioni di un tipo di evento rispetto a un altro, senza bisogno di cifre specifiche – questo non vi aiuta a determinare quanto dovreste spendere, solo l'affidabilità relativa.

Con la virtualizzazione abbiamo l'ovvia capacità di consolidare. In questo esempio assumeremo di poter comprimere tutti e dieci questi server esistenti in un singolo server. Quando lo facciamo, spesso scatta la reazione “tutte le nostre uova in un solo cesto”. Ma se eseguiamo un'analisi del rischio vedremo che di solito si tratta solo di paura e incertezza e non di un rischio supportato matematicamente. Se assumiamo gli stessi rischi dell'esempio precedente, il nostro singolo server subirà, in media, solo una singola interruzione totale del sito, una volta per decennio.

Confrontate questo con il primo esempio, che causava un danno equivalente a due interruzioni totali del sito e mezza – il rischio della soluzione virtualizzata e consolidata è solo il quaranta percento di quello della soluzione tradizionale.

Ora, tenete presente che ciò si basa sull'assunto che perdere alcuni servizi comporti una perdita finanziaria maggiore del valore stretto del servizio perduto, il che è quasi sempre il caso. Anche se il servizio perduto non è superiore alla perdita di un singolo servizio, siamo solo al punto di pareggio e non dobbiamo preoccuparci. In rari casi l'impatto della perdita di un singolo sistema può essere inferiore alla sua “fetta della torta”, normalmente perché le persone sono flessibili e possono aggirare il sistema guasto – come se la messaggistica istantanea si guastasse e le persone passassero semplicemente all'uso dell'e-mail finché la messaggistica istantanea non viene ripristinata, ma questi casi sono rari e sono normalmente isolati a pochi sistemi su molti, con la maggior parte dei sistemi, ad esempio ERP, CRM ed e-mail, che hanno impatti sproporzionatamente grandi in caso di interruzione.

Quindi quello che vediamo qui è che, in circostanze normali, spostare dieci servizi da dieci server a dieci servizi su un solo server generalmente abbasserà il nostro rischio, non lo aumenterà – in diretto contrasto con la teoria delle “uova in un cesto”. E questo è puramente dal punto di vista del guasto hardware. Il consolidamento offre però diversi altri importanti fattori di affidabilità che possono avere un impatto significativo sul nostro caso di studio.

Con il consolidamento riduciamo la quantità di hardware che deve essere monitorata e gestita dal reparto IT. Meno server significa che è possibile dedicare più tempo e attenzione a quelli che rimangono. Più attenzione significa una migliore possibilità di individuare i problemi tempestivamente e maggiori opportunità di tenere a disposizione i pezzi di ricambio. Un migliore monitoraggio e una migliore manutenzione portano a una migliore affidabilità.

Possibilmente il fattore più importante, tuttavia, con il consolidamento è che vi è un significativo risparmio sui costi e questo, se affrontato correttamente, può offrire opportunità per una migliore affidabilità. Con la drastica riduzione del costo totale dei server può essere allettante continuare a mantenere i budget contenuti e tentare di sfruttare puramente e direttamente i risparmi sui costi. Comprensibile e, per alcune aziende, questo può essere l'approccio corretto. Ma non è l'approccio che raccomanderei quando si lotta contro la nozione delle uova e dei cesti.

Invece, applicando un approccio più moderato, mantenendo significativi risparmi sui costi ma spendendo comunque di più, relativamente parlando, su un singolo server, è possibile acquisire un server di fascia più alta (leggi: più affidabile), utilizzare componenti migliori, avere ricambi in loco, ecc. I risparmi sui costi della virtualizzazione possono spesso essere trasformati direttamente in maggiore affidabilità, spostando ulteriormente l'equazione a favore dell'approccio a server singolo.

Come ho affermato in un altro articolo, è più probabile che una casa di mattoni sopravviva a una tempesta di vento rispetto a una o due case di paglia. Avere di più di qualcosa non lo rende necessariamente la scelta più affidabile.

Questi benefici derivano puramente dall'aspetto del consolidamento della virtualizzazione e non dalla virtualizzazione stessa. La virtualizzazione offre separatamente anche funzionalità estese di mitigazione del rischio. L'imaging del sistema e i ripristini rapidi, così come i ripristini su hardware diverso, sono vantaggi importanti di quasi qualsiasi piattaforma di virtualizzazione. Questo può svolgere un ruolo importante in una strategia di disaster recovery.

Naturalmente, tutti questi concetti servono puramente a dimostrare che la virtualizzazione e il consolidamento su singolo box possono battere il vecchio approccio “un'applicazione per un server” e far comunque risparmiare denaro – mostrando che l'esempio delle uova e dei cesti è fuorviante e non si applica in questo scenario. Dovrebbe esserci poca trepidazione nel passare da un ambiente tradizionale direttamente a uno virtualizzato sulla base di questi fattori.

Va notato che la virtualizzazione può poi estendere l'affidabilità del tradizionale hardware commodity, fornendo funzionalità di failover di tipo mainframe che vanno ben oltre ciò che le piattaforme non virtualizzate sono in grado di offrire. Questo allinea più saldamente l'hardware commodity alle piattaforme RISC più grandi e costose. Queste funzionalità possono apportare un livello estremo di protezione, ma sono spesso ben oltre ciò che è appropriato per i reparti IT che migrano inizialmente da un ambiente server con hardware tradizionale e privo di failover. L'alta disponibilità è una funzionalità eccellente, ma è spesso costosa e molto spesso non necessaria, specialmente man mano che le aziende passano, come abbiamo visto, da ambienti relativamente inaffidabili del passato ad ambienti più affidabili di oggi. Dato che abbiamo già aumentato l'affidabilità rispetto a ciò che era considerato necessario in passato, vi è un'ottima probabilità che un salto estremo di affidabilità non sia necessario ora ma, a causa del forte calo del costo dell'alta disponibilità, è del tutto possibile che esso risulti giustificato in termini di costi laddove in precedenza non poteva esserlo.

Nello stesso filone, la virtualizzazione è spesso temuta perché è vista come una tecnologia nuova e non comprovata. Questo è certamente falso, ma vi è un'impressione di ciò nel settore delle piccole imprese e dei server commodity. In realtà, però, la virtualizzazione fu introdotta per la prima volta da IBM negli anni '60 e da allora è stata un pilastro dei mainframe e dei server RISC di fascia alta – quei sistemi che esigono la migliore affidabilità. Nel settore dei server commodity la virtualizzazione costituiva una sfida tecnica maggiore e ci volle moltissimo tempo prima che potesse essere implementata in modo abbastanza efficiente da renderne efficace l'uso nel mondo reale. Ma anche nel settore dei server commodity la virtualizzazione è disponibile dalla fine degli anni '90 e quindi ha oggi circa quindici anni, il che è ben oltre il punto di essere una tecnologia nascente – nel mondo dell'IT è positivamente venerabile. La virtualizzazione su piattaforma commodity è un campo maturo con diversi fornitori e prodotti molto rispettati ed estremamente avanzati. L'uso della virtualizzazione come standard per tutte o quasi tutte le applicazioni server è un “modello enterprise” consolidato e accettato da tempo, e che ora può essere facilmente adottato da aziende di qualsiasi e ogni dimensione.

La virtualizzazione, forse controintuitivamente, è in realtà una componente molto critica di una strategia di affidabilità. Invece di aggiungere rischio, la virtualizzazione può quasi essere affrontata come una piattaforma di mitigazione del rischio – un kit di strumenti per aumentare l'affidabilità delle vostre piattaforme informatiche attraverso molteplici vie.