Quando Prendere in Considerazione l'Alta Disponibilità?

“L'Alta Disponibilità non è qualcosa che si compra, è qualcosa che si fa.” – John Nicholson

Poche cose sono universalmente desiderate nell'IT quanto le soluzioni di Alta Disponibilità (HA). Voglio dire, davvero: pronuncia quelle parole e qualsiasi professionista IT dirà immediatamente di volerla. HA per i loro server, le loro app, il loro storage e, naturalmente, persino i loro desktop. Se ci fosse una casella di spunta accanto a un qualsiasi sistema che dicesse semplicemente “HA”, perché non dovremmo spuntarla? Lo faremmo, ovviamente. Nessuno desidera volontariamente un sistema che si guasta spesso. Guasto male, successo bene.

Prima, però, dobbiamo definire l'HA. HA può significare molte cose. Come minimo, HA deve significare che la disponibilità del sistema in questione deve essere superiore alla “norma”. Che cos'è la norma? Già questo da solo è abbastanza difficile da definire. HA è un termine vago, nella migliore delle ipotesi. Nel contesto del suo utilizzo più comune, però, ovvero applicazioni comuni in esecuzione su hardware enterprise normale, proporrei questo punto di partenza per le discussioni sull'HA:

La Disponibilità Normale o Standard (SA) sarebbe definita come la disponibilità di un comune server di fascia principale che esegue un comune sistema operativo enterprise che esegue una comune applicazione enterprise in un ambiente conforme alle best practice con supporto enterprise. Buoni esempi di questo potrebbero includere Exchange in esecuzione su Windows Server in esecuzione su HP Proliant DL380 (il server commodity di fascia principale più comune). Oppure BIND (il server DNS) in esecuzione su Red Hat Enterprise Linux su Dell PowerEdge R730. Questi sono solo esempi da utilizzare per stabilire un riferimento approssimativo. Non esiste un modo eccellente per misurarlo, ma con un buon contratto di supporto e una riparazione o sostituzione rapida nel mondo reale, si ritiene che l'affidabilità di un sistema di questa natura sia tra i quattro e i cinque nove di affidabilità (99,99% di uptime o superiore) quando non si include il fattore umano.

L'Alta Disponibilità (HA) dovrebbe essere comunemente definita come l'avere una disponibilità significativamente superiore a quella della Disponibilità Standard. Significativamente superiore dovrebbe corrispondere a un aumento minimo di un ordine di grandezza. Quindi almeno cinque nove di affidabilità e più probabilmente sei nove. (99,9999% di uptime.)

La Bassa Disponibilità (LA) sarebbe comunemente definita come l'avere una disponibilità significativamente inferiore a quella della Disponibilità Standard, dove significativamente, ancora una volta, indica almeno un ordine di grandezza. Quindi la LA si presumerebbe tipicamente attorno a una disponibilità del 99% fino al 99,9% o inferiore.

La misurazione qui è molto difficile, poiché i fattori umani, ambientali e altri giocano un ruolo enorme nel determinare l'uptime delle diverse configurazioni. Lo stesso apparato utilizzato in un ruolo potrebbe raggiungere cinque nove mentre in un altro non riuscire a raggiungerne nemmeno uno. La qualità del datacenter, la competenza del personale di supporto, la rapidità della sostituzione dei componenti, la granularità del monitoraggio e una moltitudine di altri fattori influiranno significativamente sull'affidabilità complessiva. Questo non è necessariamente un problema per noi, tuttavia. Nella maggior parte dei casi possiamo valutare le porzioni di un progetto di sistema che controlliamo in modo tale da poter determinare l'affidabilità relativa, così da poter almeno dimostrare che un approccio sarà superiore a un altro, al fine di poter poi sfruttare un processo decisionale ben informato anche quando non sia possibile costruire facilmente modelli accurati del tasso di guasto.

È importante notare che, a parte fornire un insieme campione di esempi di riferimento da cui partire, non c'è nulla nelle definizioni di alta disponibilità o bassa disponibilità che parli di come questi livelli debbano essere raggiunti – non è questo ciò che i termini significano. I termini sono insiemi risultanti di affidabilità in relazione al riferimento e nient'altro. Esistono molti modi per raggiungere l'alta disponibilità senza utilizzare gli approcci comunemente presunti e modi praticamente illimitati per raggiungere la bassa disponibilità.

Naturalmente l'HA può essere definita a ogni livello. Possiamo avere piattaforme o sistemi operativi HA ma avere applicazioni fragili al di sopra. Quindi è molto importante capire a quale livello stiamo parlando in un dato momento. In definitiva, un'azienda si preoccuperà soltanto dell'erogazione dei servizi in alta disponibilità, indipendentemente da come o dove venga raggiunta. Ciò che conta è il risultato finale, non i dettagli “sotto il cofano” di come è stato realizzato o, come sempre, il fine giustifica i mezzi.

È estremamente comune oggi che i reparti IT si lascino distrarre da strumenti HA nuovi e appariscenti a livello di piattaforma e si dimentichino di cercare l'HA più in alto e più in basso nello stack per garantire di fornire servizi ad alta disponibilità all'azienda; anziché guardare a un solo livello lasciando l'azienda altrettanto vulnerabile, o di più, di prima.

Nel mondo reale, però, l'HA non è sempre un'opzione e, quando lo è, ha un costo. Quel costo è quasi sempre monetario e generalmente comporta anche una complessità aggiuntiva. E come sappiamo bene, qualsiasi complessità comporta anch'essa un rischio aggiuntivo, e quel rischio potrebbe, se non si presta attenzione, far sì che un tentativo di raggiungere l'HA in realtà fallisca e potrebbe persino lasciarci con la LA, ovvero la Bassa Disponibilità.

Una volta compreso questo linguaggio necessario per descrivere ciò che intendiamo, possiamo iniziare a parlare di quando l'alta disponibilità, la disponibilità standard e persino la bassa disponibilità possano essere adatte a noi. Utilizziamo questo livello elevato di granularità perché è così difficile misurare l'affidabilità dei sistemi che scendere troppo nel dettaglio diventa privo di valore.

Concettualmente, tutti i sistemi comportano un rischio di downtime e nulla può essere sempre attivo, è impossibile. L'affidabilità costa denaro, in genere, a parità di tutte le altre condizioni. Quindi, per determinare quale livello di disponibilità sia più appropriato per un carico di lavoro, dobbiamo determinare il costo della mitigazione del rischio (la quantità di denaro necessaria per modificare la quantità media di downtime) e confrontarlo con il costo del downtime stesso.

Questo diventa delicato e complicato perché determinare il costo del downtime è già abbastanza difficile, e poi determinare il rischio di downtime è ancora più difficile. In molti casi, il downtime non è un numero fisso, ma potrebbe esserlo. Questo costo potrebbe essere espresso come 5 $/minuto o 20.000 $/giorno o simili. Ma uno strumento ancora migliore sarebbe creare una “curva di impatto della perdita” che mostri come il denaro viene perso nel tempo (entro un intervallo ragionevole).

Per esempio, un'azienda potrebbe facilmente non affrontare alcuna perdita nei primi cinque minuti, con perdite lentamente crescenti, ma piccole, fino a circa quattro ore, quando il lavoro si ferma perché le persone non possono più ricorrere alla carta o quant'altro, e a quel punto le perdite passano da quasi zero a piuttosto ingenti. Oppure alcune aziende potrebbero subire una perdita enorme nel momento stesso in cui i sistemi vanno giù, ma le perdite si dissipano lentamente nel tempo. La perdita potrebbe essere rilevante solo in determinati momenti della giornata. Forse le interruzioni di notte o durante il pranzo sono trascurabili, ma a metà mattina o a metà pomeriggio sono gravi. L'impatto, il rischio e la capacità di mitigare tale rischio di ogni azienda sono diversi, spesso in modo drammatico.

A volte si riduce alle persone che lavorano in azienda. Faranno tutte volentieri le pause necessarie per il bagno, il caffè, lo spuntino o persino il pranzo nel momento in cui un sistema si guasta, così da poter tornare al lavoro quando è riparato? Le persone andranno a casa prima e arriveranno prima domani per recuperare un'interruzione importante? Ci sono macchinari che resteranno inattivi? La capacità di rispondere ai clienti sarà compromessa? I sistemi di supporto vitale si guasteranno? Ci sono innumerevoli impatti potenziali e innumerevoli modi potenziali di mitigare diversi tipi di guasti. Tutto questo deve essere preso in considerazione. Il costo del downtime potrebbe essere una frazione dei ricavi aziendali su base minuto per minuto, oppure il downtime potrebbe causare una perdita di clienti o di fiducia più impattante dei ricavi generati minuto per minuto.

Una volta che abbiamo alcuni numeri di perdita approssimativi con cui lavorare, abbiamo almeno un punto di partenza. Anche se sappiamo soltanto che i ricavi sono ~10 $/minuto e che le perdite previste si aggirano attorno a ~5 $/minuto, abbiamo una sorta di punto di partenza. Se disponiamo di una curva completa o di uno studio condotto con numeri più dettagliati, tanto meglio. Ora dobbiamo capire all'incirca quale sarà il nostro riferimento. Un server ben mantenuto, in esecuzione on-premises, con un buon contratto di supporto e buone procedure di backup e ripristino, può raggiungere abbastanza facilmente quattro nove di affidabilità. Ciò significa che subiremmo circa cinque ore di downtime ogni cinque anni. Questo è in realtà inferiore al downtime generalmente atteso della SA nella maggior parte degli ambienti e potenzialmente molto inferiore ai livelli attesi in ambienti eccellenti come datacenter di alta qualità con componenti e assistenza nelle vicinanze.

Quindi, basandoci sul nostro esempio di riferimento di circa cinque ore ogni cinque anni, possiamo calcolare il nostro rischio potenziale. Se perdiamo circa ~5 $/minuto e prevediamo all'incirca 300 minuti di downtime ogni cinque anni, ci troviamo di fronte a una perdita potenziale di 1.500 $ ogni mezzo decennio.

Ciò significa che, al massimo, non potremmo mai spendere 1.500 $ per mitigare quel rischio: sarebbe finanziariamente assurdo. Questo accade per diverse ragioni. Una delle più grandi è che si tratta soltanto di un rischio; spendere 1.500 $ per proteggersi dalla perdita di 1.500 $ ha poco senso, ma è un errore molto comune da commettere quando le persone non analizzano attentamente questi numeri.

Il fattore più importante è che nessuna tecnica di mitigazione è completamente efficace. Se riusciamo a portare il nostro sistema da quattro nove a un sistema a cinque nove, ridurremmo solo il 90% del downtime medio, portandoci da 1.500 $ di perdita a 150 $ di perdita. Se spendessimo 1.500 $ per quella riduzione, la “perdita” totale sarebbe comunque di 1.650 $ (il costo della protezione è una forma di perdita finanziaria). Il costo della mitigazione del rischio combinato con l'impatto residuo previsto, presi insieme, deve comunque essere inferiore al costo previsto del rischio senza mitigazione, altrimenti la mitigazione stessa è inutile o attivamente dannosa.

Molti potrebbero chiedersi perché il costo totale della mitigazione del rischio debba essere inferiore e non semplicemente pari, dato che ciò dovrebbe sicuramente significare che ci troviamo a un punto di “pareggio del rischio”? Questo sembra vero in superficie, ma poiché abbiamo a che fare con il rischio, non è così. La mitigazione del rischio è un costo certo: un danno finanziario che ci assumiamo anticipatamente nella speranza di ridurre le perdite di domani. Ma il rischio per domani è un'ipotesi, si spera ben fondata, ma comunque solo un'ipotesi. Il costo di oggi è certo. Assumersi un danno certo oggi nella speranza di ridurre un possibile danno domani ha senso solo quando il danno di oggi è piccolo, il danno previsto o possibile di domani è molto grande e l'efficacia della mitigazione è significativa.

Nell'idea di “costo certo anticipato” per ridurre il “possibile costo di domani” è incluso il concetto del valore temporale del denaro. Anche se un'interruzione fosse di dimensioni e durata note, non spenderemmo lo stesso denaro oggi per mitigarla domani, perché il nostro denaro vale di più oggi.

Nei casi più eclatanti, vediamo talvolta reparti IT esigere che vengano spesi decine o centinaia di migliaia di dollari anticipatamente per evitare di perdere qualche migliaio di dollari, forse, in qualche momento, magari tra molti anni nel futuro. Una strategia che possiamo definire come “spararci in faccia oggi per evitare di prenderci forse un mal di testa domani.”

È compreso nel concetto di valutazione della mitigazione del rischio, ma va menzionato specificamente che nel caso delle apparecchiature IT ci sono molti esempi di tentativi di mitigazione del rischio che potrebbero non essere efficaci quanto si crede. Per esempio, avere due server collocati nello stesso rack sarà potenzialmente molto efficace per mitigare il rischio di guasto dell'hardware dell'host, ma non mitigherà contro disastri naturali, perdita del sito, incendio, la maggior parte dei casi di scarica elettrica, attivazione dell'impianto antincendio, interruzioni di rete, la maggior parte dei guasti applicativi, attacchi ransomware o altri disastri ragionevolmente possibili.

È comune che i dispositivi di storage siano dotati di “controller doppi”, il che dà una forte impressione di elevata affidabilità, ma generalmente questi controller si trovano all'interno di un unico chassis con componenti condivisi e, anche quando i componenti non sono condivisi, spesso il firmware è condiviso e le comunicazioni tra i componenti sono complesse; ciò porta spesso a guasti in cui il guasto di un componente innesca il guasto di un altro – rendendoli abbastanza frequentemente dispositivi LA anziché SA o l'HA che le persone si aspettavano al momento dell'acquisto. Quindi è molto importante considerare se la strategia di mitigazione del rischio mitigherà quali rischi e se la tecnica di mitigazione sarà probabilmente efficace. Nessuna tecnica è completamente efficace, c'è sempre una possibilità di guasto, ma alcune strategie e tecniche sono più ampiamente efficaci di altre e alcune sono semplicemente fuorvianti o addirittura controproducenti. Se non prestiamo attenzione, potremmo implementare prodotti o tecniche costosi che minano attivamente i nostri obiettivi.

Alcune tecniche e prodotti utilizzati nella ricerca dell'alta disponibilità sono piuttosto costosi, il che potrebbe includere l'acquisto di hardware ridondante, l'affitto di un altro edificio, l'installazione di costosi generatori o l'acquisto di licenze per software speciali. Esistono anche tecniche e software a basso costo, ma nella maggior parte dei casi qualsiasi movimento verso l'alta disponibilità comporterà un esborso rispettivamente elevato di capitale di investimento per poterla raggiungere. È assolutamente fondamentale tenere a mente che l'alta disponibilità è un processo: non c'è modo di acquistare semplicemente l'alta disponibilità. Raggiungere l'HA richiede buona documentazione, procedure, pianificazione, supporto, attrezzature, ingegnerizzazione e altro ancora. Nel mondo dei sistemi, l'HA viene normalmente affrontata prima da una prospettiva ambientale con generatori elettrici di failover, sistemi HVAC ridondanti, condizionamento dell'alimentazione, filtrazione dell'aria, sistemi antincendio e altro ancora per garantire che l'ambiente per la disponibilità sia presente. Questo da solo può spesso rendere superfluo qualsiasi ulteriore investimento, poiché può offrire risultati incredibili. Poi viene la progettazione del sistema HA, che garantisce che non solo un livello dello stack tecnologico sia ad alta disponibilità, ma che l'intero stack consenta alle applicazioni, ai dati o ai servizi critici di rimanere funzionanti per la maggior parte del tempo possibile. Poi si guarda alla ridondanza da sito a sito per poter resistere ad alluvioni, uragani, bufere di neve, ecc. Naturalmente esistono tecniche completamente diverse, come l'utilizzo di servizi di cloud computing ospitati in remoto per nostro conto. Ciò che conta è che l'alta disponibilità richiede un pensiero e una pianificazione ad ampio respiro, non può essere semplicemente acquistata come voce di spesa ed è valutata in base alla capacità di restituire un fattore di rischio che fornisca un uptime risultante, o una probabilità di uptime, molto più elevato di quanto fornirebbe un progetto di sistema “standard”.

Ciò che spesso sorprende, quasi sconvolge, molte aziende e specialmente i professionisti IT, che raramente intraprendono un'analisi finanziaria del rischio e a cui viene costantemente detto che l'HA è una necessità per qualsiasi azienda e che acquistare gli ultimi prodotti HA è indiscutibilmente il modo in cui dovrebbero essere spesi i loro budget, è che quando i numeri vengono elaborati e si considera la realtà dei costi e dell'efficacia delle strategie di mitigazione del rischio, l'alta disponibilità ha pochissimo spazio in qualsiasi organizzazione, specialmente in quelle piccole o con carichi di lavoro molto eterogenei. Nel mercato delle piccole e medie imprese è quasi universale scoprire che il costo e la complessità (che a loro volta comportano un rischio, per lo più sotto forma di mancanza di esperienza riguardo alle tecniche e alla valutazione del rischio) degli approcci di alta disponibilità sono di gran lunga troppo onerosi per compensare mai il danno potenziale dell'interruzione da cui si spera che la mitigazione protegga. Ci sono eccezioni, ovviamente, e ci sono molte aziende per le quali le soluzioni di alta disponibilità sono assolutamente sensate, ma queste sono l'eccezione e molto lontane dall'essere la norma.

È anche sensato pensare alle esigenze di alta disponibilità su base di singolo carico di lavoro e non a livello di reparto, azienda o tecnologia. In una piccola impresa è comune che tutti i carichi di lavoro condividano una piattaforma comune e l'esigenza di alta disponibilità di un singolo carico di lavoro può trascinare con sé altri carichi di lavoro meno critici. Questo va perfettamente bene ed è un ottimo modo per compensare il costo della mitigazione del rischio del carico di lavoro critico attraverso un beneficio accessorio per i carichi di lavoro meno critici. In un'organizzazione più grande in cui si utilizza una pletora di approcci di piattaforma per carichi di lavoro differenti, è comune che solo a certi carichi di lavoro che sono sia altamente critici (in termini di rischio derivante dall'impatto del downtime) sia praticamente mitigabili dal rischio (la capacità di mitigare il rischio può variare drammaticamente tra diversi tipi di carichi di lavoro) venga applicata l'alta disponibilità, mentre altri carichi di lavoro vengono lasciati a tecniche standard.

Esempi di carichi di lavoro che possono essere critici e affrontabili efficacemente con l'alta disponibilità potrebbero essere un sistema di ordini online in cui la latenza creata dalla replica multi-regionale ha un impatto modesto sul sistema complessivo, ma in cui la perdita di ordini potrebbe avere un impatto finanziario molto rilevante in caso di guasto del sistema. Un esempio di carico di lavoro in cui l'alta disponibilità potrebbe essere facile da implementare ma inefficace sarebbe un sito intranet interno che risponde alle domande comuni sulle risorse umane; semplicemente non sarebbe economicamente conveniente evitare piccole quantità di downtime occasionale per un sistema come questo. Un esempio di sistema in cui il rischio è elevato ma il costo o l'efficacia della mitigazione del rischio la rendono impraticabile o persino impossibile potrebbe essere un database finanziario di “tick” che richiede l'ingestione di enormi quantità di dati a bassa latenza, e in cui la capacità di mantenere una replica non solo sarebbe incredibilmente costosa ma potrebbe introdurre una latenza tale da compromettere la capacità del sistema di funzionare adeguatamente. Ogni azienda e ogni carico di lavoro sono unici e dovrebbero essere valutati con attenzione.

Naturalmente le tecniche di alta disponibilità possono essere attuate per fasi; non è un'impresa del tipo tutto o niente. Potrebbe essere pratico mitigare il rischio di guasto a livello di sistema disponendo di tolleranza ai guasti a livello applicativo per proteggersi dal guasto dell'hardware del sistema, della piattaforma di virtualizzazione o dello storage. Ma per lo stesso carico di lavoro potrebbe non essere utile proteggersi dalla perdita di un singolo sito. Se un carico di lavoro serve solo un sito particolare o semplicemente non è abbastanza prezioso da giustificare il grande investimento necessario per farlo eseguire il failover tra siti, potrebbe facilmente collocarsi “a metà strada.” È molto comune che i carichi di lavoro implementino solo soluzioni di alta disponibilità parziali, spesso perché un reparto IT potrebbe essere responsabile solo di una porzione di esse e non avere voce in capitolo su aspetti come il supporto elettrico e l'HVAC, ma probabilmente più comunemente perché alcune tecniche di alta disponibilità sono viste come molto visibili e facili da proporre alla direzione, mentre altre, come l'alimentazione e il condizionamento dell'aria di alta qualità, spesso non lo sono, anche se potrebbero facilmente offrire un miglior rapporto qualità-prezzo. Ci sono buone ragioni per cui certe tecniche possono essere scelte e altre no, poiché incidono su componenti di rischio differenti e alcuni rischi possono avere un impatto diverso su una singola azienda o carico di lavoro.

L'alta disponibilità richiede un'attenta riflessione sul fatto che valga la pena prenderla in considerazione e una riflessione ancora più attenta sull'implementazione. Costruire veri sistemi HA richiede una quantità significativa di impegno e competenza e generalmente un costo sostanziale. Comprendere quali componenti dell'HA siano preziosi e quali no richiede non solo una vasta competenza tecnica, ma anche competenze finanziarie e manageriali. I reparti devono collaborare ampiamente per comprendere veramente come l'HA impatterà su un'organizzazione e quando varrà l'investimento. È fondamentale ricordare che la necessità di alta disponibilità in un'organizzazione o per un carico di lavoro è tutt'altro che una conclusione scontata e non dovrebbe sorprendere minimamente scoprire che pratiche estensive di alta disponibilità, o persino pratiche occasionali di alta disponibilità, si rivelano economicamente impraticabili.

In molti modi questo è dovuto al fatto che la disponibilità standard ha raggiunto uno stato tale che c'è sempre meno rischio da mitigare. I componenti tecnologici utilizzati in un'infrastruttura aziendale, in particolare server, apparati di rete e storage, sono diventati così affidabili che la quantità di downtime contro cui dobbiamo proteggerci è piuttosto bassa. Gran parte della convinzione nella necessità di un'alta disponibilità d'istinto proviene da un'epoca diversa, in cui l'hardware affidabile era inaccessibile e persino le apparecchiature più costose erano piuttosto inaffidabili secondo gli standard moderni. Questa sensazione di catastrofe imminente per cui qualsiasi dispositivo potrebbe guastarsi in qualsiasi momento proviene da un'epoca più antica, non da quella attuale. Le apparecchiature moderne, pur comportando ovviamente ancora dei rischi, sono straordinariamente affidabili.

Oltre ad altri rischi, investire eccessivamente in soluzioni di alta disponibilità comporta rischi finanziari e aziendali che possono essere sostanziali. Aumenta il debito tecnico a fronte dell'incertezza aziendale. E se l'azienda cresce improvvisamente o, peggio, se si contrae improvvisamente, cambia direzione, viene acquistata o cessa completamente l'attività? L'investimento nell'alta disponibilità è già stato speso anche se l'esigenza della sua protezione scompare. E se la tecnologia o l'ubicazione cambiano? Parte o tutto l'investimento in alta disponibilità potrebbe andare perduto prima di quanto sarebbe accaduto al termine del suo previsto ciclo di vita.

Come professionisti IT, valutare i benefici, i rischi e i costi delle soluzioni tecnologiche è al centro di ciò che facciamo. Come tutto il resto nell'infrastruttura aziendale, determinare il tipo di mitigazione del rischio, il valore della protezione e quanto sia finanziariamente corretto è la nostra responsabilità fondamentale e non può essere trascurato o ignorato. Non possiamo mai semplicemente presumere che l'alta disponibilità sia necessaria, né che possa essere semplicemente saltata. È in un'analisi di questa natura che l'IT apporta alcuni dei suoi maggiori valori alle organizzazioni. È qui che abbiamo il potenziale di brillare di più.