Come distribuire un cluster tollerante ai guasti con disponibilità continua o alta

Alcune aziende non possono permettersi di avere i propri servizi inattivi. In caso di un’interruzione del server, un operatore cellulare potrebbe subire un’interruzione del sistema di fatturazione causando la perdita di connessione per tutti i suoi clienti. L’ammissione dell’impatto potenziale di tali situazioni porta all’idea di avere sempre un piano B.

In questo articolo faremo luce su diversi modi di protezione contro i guasti del server, così come sulle architetture utilizzate per la distribuzione di VMmanager Cloud, un pannello di controllo per costruire un cluster ad alta disponibilità.

Prefazione

La terminologia nell’area della tolleranza ai guasti differisce da sito a sito. Per evitare di mescolare diversi termini e definizioni, delineiamo quelli che saranno utilizzati nel presente articolo:

Tolleranza ai guasti (FT) è la capacità di un sistema di continuare la propria operazione dopo il guasto di uno dei suoi componenti.
Cluster è un gruppo di server (nodi del cluster) connessi tramite canali di comunicazione.
Cluster Tollerante ai Guasti (FTC) è un cluster in cui il guasto di un server non comporta la completa indisponibilità dell’intero cluster. Le funzioni del nodo guasto vengono automaticamente riassegnate tra i nodi rimanenti.
Disponibilità Continua (CA) significa che un utente può utilizzare il servizio senza subire alcun timeout. Non importa quanto tempo sia passato dall’interruzione del nodo.
Alta Disponibilità (HA) significa che un utente potrebbe subire timeout del servizio nel caso in cui uno dei nodi vada giù; tuttavia, il sistema verrà ripristinato automaticamente con un minimo di inattività.
Cluster CA è un cluster di Disponibilità Continua.
Cluster HA è un cluster di Alta Disponibilità.

Supponiamo sia necessario distribuire un cluster composto da 10 nodi con macchine virtuali in esecuzione su ciascun nodo. L’obiettivo è proteggere le macchine virtuali dopo il guasto del server. Vengono utilizzati server a doppio CPU per massimizzare la densità di calcolo dei rack.

A prima vista, l’opzione più attraente per un’azienda è distribuire un cluster di Disponibilità Continua quando un servizio è ancora fornito dopo il guasto dell’attrezzatura. Infatti, la Disponibilità Continua è un must se è necessario mantenere in funzione un sistema di fatturazione o automatizzare un processo di produzione continuo. Tuttavia, questo approccio ha anche le sue trappole e insidie che verranno trattate di seguito.

Disponibilità Continua

La continuità di un servizio è realizzabile solo se viene creata una copia esatta di una macchina fisica o virtuale con questo servizio, che è disponibile in qualsiasi momento. Tale modello di ridondanza è chiamato 2N. Creare una copia del server dopo il guasto dell’attrezzatura richiederebbe tempo, causando un timeout del servizio. Inoltre, in questo caso, non sarebbe possibile recuperare il dump della RAM dal server guasto, il che significa che tutte le informazioni contenute lì andrebbero perse.

Ci sono due metodi utilizzati per fornire CA: a livello hardware e a livello software. Concentrati su ciascuno di essi in maggiore dettaglio.

Il metodo hardware rappresenta un server doppio in cui tutti i componenti sono duplicati e i calcoli vengono eseguiti simultaneamente e in modo indipendente. La sincronizzazione viene raggiunta utilizzando un nodo dedicato che controlla i risultati provenienti da entrambe le parti. Se il nodo rileva una discrepanza, cerca di definire il problema e correggere gli errori. Se l’errore non può essere corretto, il sistema disattiva il modulo guasto.

Stratus, un produttore di server CA, garantisce che il tempo di inattività complessivo del sistema non superi i 32 secondi all’anno. Tali risultati possono essere ottenuti utilizzando attrezzature speciali. Secondo i rappresentanti di Stratus, il costo di un server CA con CPU duali per ciascun modulo sincronizzato è di circa $160.000 a seconda delle specifiche. Il prezzo esteso per l’intero cluster CA in questo caso sarebbe di $1.600.000.

Il metodo software

Lo strumento software più popolare per la distribuzione di un cluster di Disponibilità Continua al momento dell’articolo è VMware vSphere. La tecnologia di Disponibilità Continua di questo prodotto è chiamata Tolleranza ai Guasti.

A differenza del metodo hardware, questa tecnologia ha requisiti specifici, come i seguenti:

CPU sull’host fisico: - Intel con architettura Sandy Bridge (o più recente). Avoton non è supportato.
AMD Bulldozer (o più recente).
Le macchine con Tolleranza ai Guasti devono essere collegate a una rete da 10 Gb con bassa latenza. VMware raccomanda vivamente di utilizzare una rete dedicata.
Non più di 4 CPU virtuali per VM.
Non più di 8 CPU virtuali per host fisico.
Non più di 4 macchine virtuali per host fisico.
Gli snapshot delle macchine virtuali non sono disponibili.
Storage vMotion non è disponibile.

L’elenco completo delle limitazioni e delle incompatibilità può essere trovato nella documentazione ufficiale.

La licenza di vSphere si basa sulle CPU fisiche. Il prezzo parte da $1750 per licenza + $550 per abbonamento annuale e supporto. L’automazione della gestione del cluster richiede anche VMware vCenter Server che costa oltre $8000. Il modello 2N è utilizzato per fornire Disponibilità Continua, quindi è necessario acquistare 10 server replicati con licenze per ciascuno di essi per costruire un cluster con 10 nodi con macchine virtuali.

Il costo complessivo del software sarebbe 2[ Numero di CPU per server ](10[ Numero di nodi con macchine virtuali ]+10[ Numero di nodi replicati ])(1750+550)[ Costo della licenza per ciascuna CPU ]+8000[ Costo di VMware vCenter Server ]=$100.000. Tutti i prezzi sono arrotondati.

Le configurazioni specifiche dei nodi non sono descritte in questo articolo poiché i componenti del server differiscono sempre a seconda dello scopo del cluster. Anche l’attrezzatura di rete non è descritta poiché dovrebbe essere identica in ogni caso. Questo articolo si concentra su quei componenti che variano sicuramente, che è il costo della licenza.

È anche importante menzionare i prodotti che non sono più sviluppati e supportati.

Il prodotto chiamato Remus è basato sulla virtualizzazione Xen. È una soluzione open source gratuita che utilizza la tecnologia dei micro snapshot. Sfortunatamente, la sua documentazione non è stata aggiornata da molto tempo: la guida all’installazione fornisce istruzioni per Ubuntu 12.10, la cui fine vita è stata annunciata nel 2014. Anche la ricerca su Google non ha trovato alcuna azienda che utilizzasse Remus per le proprie operazioni.

Sono stati fatti tentativi per modificare QEMU per costruire cluster di Disponibilità Continua su questa tecnologia. Ci sono due progetti che hanno annunciato il loro lavoro in questa direzione.

Il primo è Kemari, un prodotto open source guidato da Yoshiaki Tamura. Questo progetto intendeva utilizzare la migrazione live di QEMU. L’ultimo commit è stato effettuato a febbraio 2011, il che suggerisce che lo sviluppo ha raggiunto un vicolo cieco e non sarà continuato.

Il secondo prodotto è Micro Checkpointing, un progetto open source fondato da Michael Hines. Non è stata trovata alcuna attività nel suo changelog nell’ultimo anno, il che assomiglia al progetto Kemari.

Questi fatti ci permettono di concludere che semplicemente non esiste la possibilità di Disponibilità Continua sulla virtualizzazione KVM fino ad oggi.

Nonostante tutti i vantaggi dei sistemi di Disponibilità Continua, ci sono molti ostacoli sulla strada per distribuire e operare tali soluzioni. Tuttavia, in alcuni casi, la Tolleranza ai Guasti potrebbe essere necessaria ma senza la necessità di essere continuamente disponibile. Tali scenari consentono di utilizzare cluster con Alta Disponibilità.

Alta Disponibilità

Un cluster di Alta Disponibilità fornisce Tolleranza ai Guasti rilevando automaticamente se l’hardware è inattivo e successivamente avviando il servizio sul nodo disponibile.

L’Alta Disponibilità non supporta la sincronizzazione delle CPU avviate sui nodi e non sempre consente di sincronizzare i dischi locali. Tenendo presente ciò, è consigliabile posizionare i dischi utilizzati dai nodi in uno storage indipendente separato, come lo storage di rete.

Il motivo è chiaro: il nodo non può essere raggiunto dopo il suo guasto e le informazioni dal suo dispositivo di archiviazione non possono essere recuperate. Anche il sistema di archiviazione dei dati dovrebbe essere tollerante ai guasti, altrimenti non c’è possibilità di Alta Disponibilità. Di conseguenza, il cluster di Alta Disponibilità è composto da due sub-cluster:

Cluster di calcolo composto da nodi con macchine virtuali
Cluster di archiviazione con dischi utilizzati dai nodi di calcolo.

Al momento ci sono le seguenti soluzioni utilizzate per implementare cluster di Alta Disponibilità con macchine virtuali sui nodi del cluster:

Heartbeat, versione 1.? con DRBD;
Pacemaker;
VMware vSphere;
Proxmox VE;
XenServer;
OpenStack;
oVirt;
Red Hat Enterprise Virtualization;
Windows Server Failover Clustering con ruolo server Hyper-V;
VMmanager Cloud.

Diamo un’occhiata più da vicino a VMmanager Cloud.

VMmanager Cloud

VMmanager Cloud è un prodotto che consente di distribuire cluster di Alta Disponibilità e utilizza la virtualizzazione QEMU-KVM. Questa tecnologia è stata selezionata perché è attivamente sviluppata e supportata e consente di installare qualsiasi sistema operativo su una macchina virtuale. Il prodotto utilizza Corosync per rilevare la disponibilità del cluster. Se uno dei server è inattivo, VMmanager distribuisce le sue macchine virtuali tra i nodi rimanenti una alla volta.

In forma semplificata, questo meccanismo funziona come segue:

Il sistema identifica il nodo del cluster con il minor numero di macchine virtuali.
Controlla se c’è abbastanza RAM per posizionare la macchina.
Se c’è abbastanza memoria su un nodo per la macchina pertinente, VMmanager crea una nuova macchina virtuale su questo nodo.
Se non c’è abbastanza memoria, il sistema controlla gli altri nodi con più macchine virtuali.

Testando alcune configurazioni hardware e interrogando molti utenti attuali di VMmanager Cloud, è stato identificato che normalmente ci vogliono 45-90 secondi per distribuire e ripristinare il funzionamento di tutte le VM dal nodo guasto, a seconda delle prestazioni dell’attrezzatura.

Si consiglia di dedicare uno o più nodi come protezione contro situazioni di emergenza e di non distribuire VM su questi nodi durante il funzionamento di routine. Ciò riduce le possibilità di mancanza di risorse sui nodi del cluster attivo per aggiungere macchine virtuali dal nodo guasto. Nel caso in cui venga utilizzato solo un nodo di backup, tale modello di sicurezza è chiamato N+1.

VMmanager Cloud supporta i seguenti tipi di archiviazione: file system, LVM, Network LVM, iSCSI e Ceph [in particolare RBD (RADOS Block Device), una delle implementazioni di Ceph]. Gli ultimi tre sono utilizzati per Alta Disponibilità.

Una licenza a vita per dieci nodi operativi e un nodo di backup costa €3520, ovvero $3865 a oggi (una licenza costa €320 per nodo indipendentemente dal numero di CPU). La licenza include un anno di aggiornamenti gratuiti; a partire dal secondo anno, gli aggiornamenti vengono forniti secondo un modello di abbonamento al prezzo di €880 all’anno per l’intero cluster.

Controlliamo come VMmanager Cloud è già stato utilizzato per la distribuzione di cluster di Alta Disponibilità.

FirstByte

FirstByte ha iniziato a fornire hosting cloud a febbraio 2016. Inizialmente, il loro cluster era costruito su OpenStack; tuttavia, la mancanza di specialisti per questo sistema in termini di disponibilità e costo li ha spinti a cercare una soluzione alternativa. Il nuovo sistema per costruire un cluster di Alta Disponibilità doveva soddisfare i seguenti requisiti:

Capacità di distribuire macchine virtuali KVM.
Integrazione con Ceph.
Integrazione con un sistema di fatturazione per offrire i servizi esistenti.
Costo della licenza accessibile.
Supporto da parte dello sviluppatore software.

VMmanager Cloud soddisfaceva tutti i requisiti.

Caratteristiche distintive del cluster di FirstByte:

Il trasferimento dei dati si basa sulla tecnologia Ethernet e sull’attrezzatura Cisco.
Il routing viene eseguito utilizzando Cisco ASR9001. Il cluster utilizza circa 50000 indirizzi IPv6.
La velocità di collegamento tra i nodi di calcolo e gli switch è di 10 Gbps.
La velocità di trasferimento dei dati tra switch e nodi di archiviazione è di 20 Gbps, con due canali combinati a 10 Gbps ciascuno.
Un collegamento separato da 20 Gbps è utilizzato tra i rack con nodi di archiviazione per la replicazione.
Dischi SAS in combinazione con SSD sono installati su tutti i nodi di archiviazione.
Il tipo di archiviazione è RBD.

Il layout del sistema è presentato di seguito:

Tale configurazione funziona per l’hosting di siti web popolari, server di gioco e database con un carico superiore alla media.

FirstVDS

FirstVDS fornisce i servizi di un cluster tollerante ai guasti che è stato avviato a settembre 2015.

VMmanager Cloud è stato scelto per questo cluster a causa dei seguenti fattori:

Solida esperienza nell’uso dei pannelli di controllo ISPsystem.
Integrazione con BILLmanager per impostazione predefinita.
Alta qualità del supporto tecnico.
Integrazione con Ceph.

Il loro cluster ha le seguenti caratteristiche:

Il trasferimento dei dati si basa su una rete Infiniband con velocità di connessione di 56 Gbps;
La rete Infiniband è costruita su attrezzatura Mellanox;
I nodi di archiviazione hanno dischi SSD;
Il tipo di archiviazione è RBD.

Il sistema può essere disposto nel seguente modo:

In caso di guasto della rete Infiniband, la connessione tra l’archiviazione dei dischi VM e i server di calcolo viene stabilita tramite rete Ethernet distribuita su attrezzatura Juniper. La nuova connessione viene impostata automaticamente.

Grazie all’alta velocità di comunicazione con l’archiviazione, questo cluster funziona perfettamente per l’hosting di siti web con traffico ultralto, streaming video e contenuti, così come big data.

Conclusione

Riepiloghiamo i punti chiave dell’articolo.

Il cluster di Disponibilità Continua è un must quando ogni secondo di inattività comporta perdite sostanziali. Se è consentito avere un’interruzione di 5 minuti mentre le macchine virtuali vengono distribuite su un nodo di backup, il cluster di Alta Disponibilità può essere una buona opzione per ridurre i costi hardware e software.

È anche importante ricordare che l’unico modo per raggiungere la Tolleranza ai Guasti è l’eccesso. Assicurati di replicare i tuoi server, l’attrezzatura di comunicazione dati e i collegamenti, i canali di accesso a Internet e l’alimentazione. Replica tutto ciò che puoi. Tali misure rendono possibile eliminare i colli di bottiglia e i potenziali punti di guasto che possono causare l’inattività dell’intero sistema. Prendendo le misure sopra indicate, puoi essere sicuro di avere un cluster tollerante ai guasti resistente ai guasti.

Se pensi che il modello di Alta Disponibilità soddisfi le tue esigenze e che VMmanager Cloud sia un buon strumento per realizzarlo, ti preghiamo di fare riferimento al manuale di installazione e alla documentazione per saperne di più sul sistema. Ti auguro operazioni senza guasti e continue!**