Alta disponibilità: cosa c'è da sapere

Ciao, sono Mike, ingegnere delle soluzioni di Linode. Se siete curiosi di conoscere l'High Availability, questo post dovrebbe aiutarvi a fare chiarezza. Buon divertimento!

Nel mondo iperconnesso di oggi, i consumatori si aspettano di avere accesso ai servizi istantaneamente, in qualsiasi momento e da qualsiasi luogo. Inoltre, è necessario pensare ai tempi di attenzione: sapevate che avete circa 30 secondi per catturare l'attenzione di un consumatore prima che passi ad altro? Per questo motivo, è fondamentale implementare l'alta disponibilità (HA) sulle vostre applicazioni. In questo post definirò l'HA, spiegherò i vari componenti che compongono un'architettura HA di base ed esaminerò come costruire una semplice infrastruttura HA per un'applicazione web.

Che cos'è l'alta disponibilità?

Innanzitutto, definiamo la disponibilità: la percentuale di tempo totale in cui un sistema informatico è accessibile per un uso normale. In altre parole, la disponibilità descrive in che misura un sistema è online e accessibile. Si potrebbe pensare che la disponibilità ottimale sia del 100%, ma è impossibile. 

È qui che entra in gioco l'alta disponibilità. I sistemi HA sono quelli con una disponibilità online che va dal 99,9 al 99,999% del tempo (vedi Tabella 1). L'HA ideale è del 99,999% - "cinque nove" - che corrisponde a circa cinque minuti di inattività all'anno.

High Availability in cifre

I progettisti di sistemi cercano di ottenere la massima HA possibile. L'HA può essere aumentata attraverso la tolleranza ai guasti. Ciò implica la creazione di diverse funzionalità di sistema che consentano il funzionamento continuo in caso di guasto del sistema. Esempi di funzionalità di tolleranza ai guasti sono la ridondanza e la replica, di cui parleremo più avanti.

Come funziona l'alta disponibilità?

Sono molte le caratteristiche che possono contribuire alla costruzione di un sistema HA ideale. Questi componenti devono essere integrati tra loro, costantemente monitorati e in grado di ripristinare rapidamente la situazione. Queste includono:

• ridondanza dell'istanza,
• bilanciamento del carico,
• failover hardware e software tra componenti diversi,
• replica dei dati e
• scalatura automatica.

Queste caratteristiche sono ulteriormente spiegate nel diagramma seguente:

Come valutare la disponibilità del vostro sistema

Volete determinare la disponibilità dell'infrastruttura del vostro cloud? Si basa su tre criteri:

• le sue dimensioni e la sua portata
• inclusione di componenti hardware
• scalabilità prevista per soddisfare la domanda futura

Dopo la valutazione, potete decidere di rivedere la vostra infrastruttura. Vi consiglio di rivedere prima ogni criterio separatamente e poi collettivamente. La revisione dell'architettura può includere strumenti virtuali, quali:

• nuovi server secondari e componenti aggiuntivi
• Utility software per l'abilitazione all'HA
• hardware supplementare

In che modo il bilanciamento del carico influisce sull'HA?

Il bilanciamento del carico distribuisce in modo intelligente il traffico in entrata su uno o più server. Questi strumenti, come NodeBalancers di Linode, sono progettati per essere "impostati e dimenticati". Consentono di aggiungere o rimuovere senza problemi i server di backend senza che gli utenti finali debbano affrontare tempi di inattività.

Un tipico bilanciatore di carico monitora un indirizzo IP per le richieste in arrivo e lo analizza per individuare eventuali sovraccarichi o guasti. In caso di rilevamento, segue le regole configurate (compreso l'IP Failover assegnato) per inviare il traffico a un nodo più facilmente disponibile. In questo modo, il traffico viene distribuito in modo uniforme e gli utenti finali non subiscono interruzioni del servizio.

Quasi tutte le applicazioni possono beneficiare del bilanciamento del carico. È un componente chiave per scalare gli utenti e ottenere al contempo la ridondanza.

Che cos'è esattamente il Failover?

Il failover è la pietra miliare dei sistemi HA. Con il failover, le attività vengono automaticamente reindirizzate a un server secondario o terziario in caso di downtime pianificato o accidentale. 

Il failover comprende soluzioni sia hardware che software, come l'aggiunta di server di database in mirroring a un cluster o la configurazione di un indirizzo IP in modo da instradare il traffico verso il server più disponibile. 

Come funziona la replica dei file system?

In un cluster HA, ogni server (ad esempio, app, database, file system) sarà configurato per eseguire il mirroring di altri server, con la replica automatica dei dati memorizzati tra tutti gli altri server dell'architettura. Le richieste in arrivo saranno in grado di accedere ai dati, indipendentemente dal server su cui risiedono. Ciò si traduce in un'esperienza senza soluzione di continuità per l'utente finale. 

I software NFS (Network File System) come GlusterFS, LizardFS e HDFS possono aggregare vari tipi di server in un unico file system di rete parallelo. In caso di guasto di un server, il software NFS reindirizza automaticamente le richieste dirette a un server online, i cui file e dati sono stati sottoposti a mirroring e sincronizzazione.

E il database?

L'obiettivo è ottenere una replica sincrona: i dati vengono copiati continuamente da un server di database all'altro. In questo modo si ottiene una distribuzione uniforme dei dati agli utenti finali, senza interruzioni. È possibile ottenere questo risultato attraverso le seguenti piattaforme software, in qualsiasi combinazione:

• HAProxy
• Percona XtraDB
• Galera

Dove si colloca il Seamless Scaling?

Il sistema deve crescere e rispondere agli utenti finali. Ogni sistema è diverso dall'altro, quindi non esiste una piattaforma unica, adatta a tutti, per scalare un sistema mantenendo l'HA. È necessario scegliere la piattaforma di distribuzione distribuita più adatta alle proprie esigenze. Alcuni esempi sono:

• SaltStack: una piattaforma di gestione della configurazione scalabile e flessibile per l'automazione del cloud basata sugli eventi
• Chef: software che scrive ricette di configurazione del sistema in Erlang o Ruby.
• Puppet: software che gestisce la configurazione di sistemi Unix-like e Microsoft Windows.

Vediamo un esempio

Per mettere le cose in prospettiva, abbiamo messo insieme un elenco di passi da compiere per raggiungere l'HA. Si tratta di progettare un sistema con un singolo bilanciatore di carico, tre server web/applicazioni e tre server di database. Nota bene: per stabilire il quorum dei dati nelle architetture HA sono necessari almeno tre server DB.

1. Una volta assemblato il cluster, configurare i server web/app per replicare i dati del sito utilizzando l'NFS scelto.
   1. In questo modo si attiverà il bilanciatore di carico e si assegnerà il traffico tra i tre nodi web/app, rimuovendo automaticamente i nodi che si sono guastati.
2. Creare una configurazione MySQL Master-Master utilizzando Percona XtraDB.
   1. Designare un IP privato flottante, gestito da Keepalived, per funzionare come failover .
3. Puntare tutti i server web/app all'IP privato fluttuante, in modo da spostarsi automaticamente su un nodo di database online nel caso in cui un server DB si guasti.

Voilà! Il risultato sarà un'interruzione minima per gli utenti finali, perché l'accesso al server rimane disponibile, nonostante qualsiasi punto di guasto.

Conclusione

Volete quindi creare un sistema HA?

È importante sapere che ciò richiede un'attenta pianificazione. Innanzitutto, è necessario calcolare il costo reale dei tempi di inattività. Questo dato varia a seconda dell'organizzazione e gioca un ruolo fondamentale nel determinare la quantità di tempi di inattività accettabili in un determinato anno. Queste informazioni sono fondamentali per determinare la giusta combinazione di configurazione hardware, strumenti software e manutenzione del sistema.

L'aggiunta di componenti hardware a un sistema può ostacolare l'HA. L'aggiunta di un server al cluster aumenta il rischio di guasti, quindi deve essere fatta bene. 

È vero, un'architettura di sistema semplificata è, beh, più semplice. Ma non è priva di compromessi. Questo tipo di sistema deve essere messo offline per ogni patch o aggiornamento del sistema operativo. Questa interruzione sporadica indebolisce la disponibilità del sistema. Lo stesso vale per il software. Un singolo errore, come uno stupido refuso o una cattiva installazione, comprometterà l'HA.

Il sistema HA ideale, che rimane online per oltre il 99,999% del tempo, integra ridondanza, failover e monitoraggio, adattando al contempo patch e aggiornamenti di hardware, rete, sistema operativo, middleware e applicazioni online, in tempo reale, senza interruzioni per gli utenti finali.