In questi anni si è verificato un incremento verticale delle strutture ad alta efficacia, sia in termini di performance che di affidabilità, intesa come raggiungibilità del servizio, anche per le piccole infrastrutture. Così come si continua a lavorare per diminuire i tempi di caricamento e risposta, eliminare i downtime ed i single point of failure è altrettanto importante.
La High Availability è una qualità che possiamo attribuire alle infrastrutture che scalano efficacemente per rispondere proprio a queste necessità e non solo. Vediamo insieme cosa significa e in cosa consiste, e soprattutto come possiamo migliorare anche la piccola infrastruttura.
Che cos’è la High Availability?
Partiamo dal concetto di availability, cioè di disponibilità: quanto un servizio è attivo e raggiungibile e quanto esso impiega a rispondere alla nostra richiesta. Alta affidabilità, o High Availability (HA) è un termine che indica un’infrastruttura informatica, connessa in una rete, che fornisca il massimo del potenziale uptime e accessibilità ai dati contenuti nel sistema.
La High Availability è proprio questo: la capacità di un sistema o di un componente di assicurare una performance alta senza interruzioni in un dato periodo di tempo. In due parole, un servizio sempre attivo, senza interruzioni.
Nonostante un sistema tradizionale possa essere perfettamente in grado di servire quantità di utenti elevate, potrebbe contenere al suo interno quello che viene comunemente chiamato single point of failure ossia un componente del sistema stesso il cui malfunzionamento compromette l’intera infrastruttura, al punto di mandarla in down.
Come funziona l’high availability
Per creare un sistema ad alta affidabilità, devono essere presenti tre caratteristiche:
- Ridondanza
- Monitoraggio
- Failover
In generale, un sistema ad alta affidabilità funziona avendo a disposizione più componenti di quelle strettamente necessarie, eseguendo continui check dello stato generale del sistema, e, nel caso una di queste componenti vada offline, sostituendola con un’altra funzionante.
Ridondanza
In informatica, ridondanza sta ad indicare la presenza di più componenti adatte ad eseguire lo stesso compito. Questo elimina il problema del single point of failure permettendo ad un secondo server, ad esempio, di prendere il controllo nel caso quello principale vada offline o venga disabilitato.
In un sistema tradizionale, l’intera infrastruttura verrebbe invece compromessa.
Un aspetto importante di questa tecnica è la replicazione: per far si che tutte le componenti ridondanti siano pronte in qualsiasi momento a subentrare nel caso di malfunzionamenti, i dati devono essere continuamente sincronizzati fra loro, in maniera che dispongano sempre delle stesse informazioni.
Monitoraggio e failover
In un high availability setup, il sistema deve essere in grado di monitorare sé stesso per identificare eventuali malfunzionamenti. Questo comporta check periodici per assicurare che tutti i componenti lavorino correttamente.
Per failover si intende, invece, il processo per il quale un componente secondario diventa primario quando il monitoraggio rileva che un componente primario è inattivo o compromesso.
In un sistema tradizionale, nel quale ad esempio sia presente un sito web, quando il server principale smette di funzionare il sito web risulterà non più raggiungibile. In un sistema ad alta affidabilità, grazie al monitoraggio continuo, il sistema rileverà la non disponibilità della risorsa primaria e automaticamente effettuerà il failover alla componente secondaria, mantenendo il sito web raggiungibile.
Com’è fatto un sistema High Availability?
Come accennato, uno degli obiettivi della High Availability è rimuovere, per quanto possibile, i single point of failure, ossia gli anelli deboli della catena. In linea generale, qualsiasi componente strategico per il sistema che non ha ridondanza è considerabile come un single point of failure.
Quindi, quando progettiamo la nostra infrastruttura, la prima regola è che ogni singolo livello deve essere implementato in modo ridondante, banalmente ogni sistema deve avere un gemello.
La ridondanza in sé, però, non può garantire la High Availability. È necessario mettere in pratica un meccanismo che si accorga del failure ed intervenga automaticamente quando uno dei componenti dell’infrastruttura diventa indisponibile.
La failure detection ed il recovery automatico possono essere implementati usando un approccio top-down: i livelli più in alto diventano responsabili del monitoraggio dei livelli immediatamente sotto.
Nel caso in cui sia proprio il load balancer a non funzionare, affiancargli un secondo load balancer non risolverebbe del tutto il problema: se creassimo, ancora prima dei load balancer, un server di controllo avremmo creato un nuovo single point of failure.
In questo scenario, è necessario un approccio distribuito. Più nodi (ovvero server) ridondanti devono essere connessi insieme per creare dei cluster dove ogni punto deve essere capace di intervenire in caso di failure detection.
Per il caso dei load balancer, poi, c’è un ulteriore complicazione, data dal come i DNS funzionano. Fare il recover di un load balancer significherebbe cambiare il record DNS per far puntare lo stesso dominio ad un nuovo IP, quello del secondo load balancer. Un cambio del genere comporta l’attesa della propagazione a livello mondiale dei DNS, provocando un downtime considerevole.
Le moderne infrastrutture cloud offrono un sistema affidabile che offre la flessibilità di rimappare gli indirizzi IP istantaneamente puntandoli verso diversi servizi. Con l’utilizzo di questi IP flessibili, semplicemente, lo stesso indirizzo IP viene puntato verso il servizio (il web server rimasto in piedi) ridondante. Il dominio sarà sempre associato a questo IP, che “si muoverà” tra i servizi. AWS Elastic IP, Microsoft Azure Load Balancer e Google Cloud Floating IP fanno proprio questo.
Un fattore importante, poi, è la geografia: cioè in quale datacenter o zona del mondo girano i nostri servizi. Amazon Web Services, ad esempio, ha fatto scuola con i suoi servizi Multi-AZ, ovvero la possibilità di distribuire sistemi gemelli (e non solo) in giro per tutti i suoi datacenter nel mondo. Senza andare troppo nello specifico, ciò ci protegge dai failure che potrebbero capitare all’intero datacenter. Sembra una eventualità remota ma, ad esempio, nel 2017 il datacenter Ovh di Strasburgo venne tirato giù completamente per un problema al sistema di raffreddamento per quasi 3 giorni.
La soluzione potrebbe essere quella di replicare i servizi in zone differenziate.
Perchè scegliere un sistema ad alta affidabilità
Nel mondo business, i periodi nei quali la struttura informatica è inattiva corrispondono spesso a perdite economiche, a volte anche rilevanti. Affidarsi ad un sistema ad alta affidabilità equivale dunque alla sicurezza di avere sempre le risorse a disposizione, e di conseguenza di poter proseguire il proprio business a prescindere da malfunzionamenti e down di rete.
Per spiegare la disponibilità, un buon modo è usare le percentuali: spesso infatti ci troviamo davanti alle percentuali di uptime di un sistema rispetto ad un periodo di tempo, dove un valore del 100% significa che il sistema non fallisce mai. Generalmente questa percentuale viene calcolata su base annua, e ciò significa che se qualcuno vi garantisce il 99% di uptime, vi sta dicendo anche che potrebbero esserci 3,65 giorni di downtime in un anno (ovvero l’1%). Dato che quasi quattro giorni di servizio interrotto sono un’enormità, è per questo che spesso sentirete parlare di “nines”. Cioè di quanti “nove” dopo la virgola del 99% ci sono.
Questi numeri tengono conto di tutti i fattori, inclusa, ad esempio, la manutenzione programmata e quella non programmata.
Quali sono i componenti da tenere in considerazione?
Ci sono vari componenti che possono essere tenuti in considerazione per creare un’infrastruttura considerabile High Availability. Più che sul software, essa dipende da fattori come:
- Provider: utilizzare tutti i servizi dello stesso provider, problemi legati a quest’ultimo potrebbero oscurare l’intero servizio.
- Ambiente: se tutti i server sono locati nella stessa area geografica, qualche condizione ambientale (terremoto, allagamento, etc.) potrebbe portare tutti i sistemi giù. Avere server in datacenter indipendenti geograficamente incrementerà la disponibilità.
- Hardware: affidarsi a server che sono ridondanti a livello hardware tiene coperti rispetto a failure che possono riguardare i dischi, l’alimentazione, etc.
- Dati: anche se i dati seguono le regole generali, è bene creare grande ridondanza sia per il database che lo storage di oggetti statici semplici (immagini, etc.).
- Network: anche se rare, le indisponibilità di rete rappresentano ancora un possibile point o failure.
Conclusioni
Quando si crea un’infrastruttura robusta, minimizzare il downtime e le interruzioni dovrebbe essere sempre una priorità. Per quanto possiamo scrivere del buon codice e fare un buon setup dell’infrastruttura, però gli imprevisti si verificano: come si dice, shit happens. Implementare un sistema ad Alta Disponibilità per un’infrastruttura è una strategia ottimale per ridurre l’impatto delle interruzioni. I sistemi High Availability, inoltre, dovrebbero reagire automaticamente alle interruzioni.
L’High Availability è un fattore strategico fondamentale nell’implementazione di un servizio, per assicurare agli utenti la sua continuità e disponibilità nel tempo. Anche se la sua implementazione può sembrare complessa, porterà sicuramente grandi benefici, anche alle piccole infrastrutture. Il cloud moderno, attraverso i grandi provider ci permette di costruire un’infrastruttura di grande qualità anche con budget ridotti, per poi scalare in modo omogeneo con il crescere degli utenti del nostro servizio.
