In questo capitolo vedremo quanti nodi deve avere un cluster, cosa è il quorum e cosa succede nel dettaglio quando si verifica un fault di uno o più nodi.

Il quorum nell’iperconvergenza è un concetto chiave per garantire la coerenza e l’affidabilità del sistema. In un cluster iperconvergente, il quorum è definito come il numero minimo di nodi funzionanti richiesti per permettere al Cluster di prendere decisioni e gestire operazioni critiche. Il quorum evita situazioni di partizione del cluster (Split Brain), in cui i nodi perdono la connettività tra loro e operano indipendentemente, mettendo a rischio la coerenza dei dati e la continuità del servizio.

Il meccanismo di voto basato su nodi è il più utilizzato. I nodi all’interno del cluster comunicano tra loro e partecipano a processi di voto per raggiungere una maggioranza e permettere al sistema di prendere decisioni consensuali al manifestarsi di eventi critici. Ad esempio, al verificarsi di un fail, i nodi votano per determinare quale gruppo di nodi assumerà il ruolo di “master” e gestirà il servizio o il carico di lavoro precedentemente gestito dal nodo o nodi falliti.

L’heartbeat è un meccanismo mediante il quale i nodi di un cluster comunicano tra loro in modo regolare e periodico per segnalare la loro disponibilità e lo stato operativo. In pratica, ogni nodo invia segnali di “vivo” (heartbeat) agli altri nodi del cluster, indicando che è attivo e funzionante. Se un nodo smette di inviare gli “heartbeat” o non risponde, gli altri nodi possono rilevare un guasto e intraprendere azioni appropriate.

Ogni tecnologia iperconvergente integra un proprio sistema di calcolo del quorum all’interno del software di gestione del cluster.

Ad ogni nodo del cluster è assegnato un peso al voto che può dare. Tipicamente il peso del voto è 1, ma è possibile (anche se sconsigliato in quanto è una tecnica pericolosa) assegnare pesi differenti.

È fondamentale avere almeno 3 nodi nel cluster per diversi motivi:

Garantire la maggioranza: Con 3 nodi, anche se si verifica una perdita di connettività tra due di essi, rimangono comunque almeno 2 nodi funzionanti che costituiscono la maggioranza (il 66,66%). Questo assicura che il cluster possa continuare a prendere decisioni consensuali e a mantenere la coerenza dei dati.

Con un numero dispari di nodi, si evitano situazioni di stallo in cui i nodi non riescono a raggiungere un consenso. Per questa ragione è preferibile avere cluster con un numero dispari di nodi.

Prevenire la divisione (o Split Brain) del cluster: Con solo due nodi, la perdita di connettività tra loro potrebbe portare a una divisione del cluster in due partizioni. In questa situazione, entrambi i nodi non avrebbero la maggioranza, impedendo al cluster di prendere decisioni. Si verificherebbe così una situazione di stallo. Per questo motivo non sono realizzabili Cluster a 2 nodi. Con almeno 3 nodi, è impossibile avere una partizione in cui entrambe le parti abbiano la maggioranza.

Affidabilità e tolleranza ai guasti: Avendo almeno 3 nodi, il cluster può sopportare la perdita di un nodo senza compromettere la disponibilità e la coerenza dei dati. Inoltre, con 3 o più nodi, è possibile implementare strategie di replica dei dati e ridondanza, garantendo un ambiente resiliente.

6.1 Utilizzo di nodi testimone

Il nodo testimone ha il compito di fornire un punto di “voto” aggiuntivo in decisioni che riguardano il quorum, specialmente in configurazioni che hanno un numero pari di nodi. In caso di perdita di connettività tra i nodi del cluster, il nodo testimone aiuta a stabilire quale sottoinsieme di nodi detiene la maggioranza e, quindi, può operare come cluster.

Ad esempio, in un cluster di 2 nodi (una configurazione tipicamente problematica per la gestione del quorum), l’aggiunta di un nodo testimone fornisce un terzo punto di “voto”, permettendo di evitare situazioni di stallo. Se uno dei nodi principali va offline o perde la connettività, il nodo testimone fornisce il voto decisivo che permette all’altro nodo di continuare a funzionare, assumendo che esso stesso sia in uno stato operativo e connesso al nodo testimone.

Si differenzia con gli altri nodi in quanto non dispone di risorse di calcolo, storage e networking in grado di eseguire VM o CT, ma solo di fornire il voto indispensabile a garantire il meccanismo del quorum.

Si noti che a seconda del vendor che lo implementa può assumere nomi differenti. In VmWare viene chiamato nodo witness, mentre in Proxmox viene chiamato “Quorum Disk” o “QDevice”.

Nel caso in cui il quorum non funzionasse correttamente in concomitanza ad una situazione di fault, potrebbe verificarsi una situazione detta Split Brain. Questa situazione è piuttosto remota, data la maturità della tecnologia, tuttavia è interessante analizzare questa situazione tecnicamente per comprendere in profondità alcuni importanti meccanismi.

6.2 Split Brain del Cluster

Seppur sia molto difficile che si verifichi in quanto ogni Cluster Maker è molto attento a non ricadere in questa situazione, qualora il meccanismo del quorum non funzionasse correttamente in caso di fault potrebbe verificarsi uno split brain.

Lo “split brain” è una situazione indesiderata che può verificarsi in un cluster iperconvergente quando i nodi perdono la connettività tra loro, ma continuano a operare indipendentemente come se fossero due cluster separati. Questa condizione può verificarsi a causa di problemi di rete o di guasti nei sistemi di comunicazione tra i nodi.

6.3 Descrizione tecnica dello split brain in un cluster iperconvergente

In un cluster iperconvergente, i nodi lavorano insieme per garantire la coerenza dei dati e la gestione condivisa delle risorse. Comunicano tra loro attraverso una rete interna per prendere decisioni consensuali, distribuire i carichi di lavoro e garantire l’affidabilità del sistema.

Quando si verifica uno split brain, alcuni nodi del cluster perdono la connettività con gli altri nodi, ma continuano a essere operativi. Questo può accadere, ad esempio, a causa di un problema di rete che isola temporaneamente alcuni nodi dal resto del cluster. I nodi isolati, anche senza maggioranza (no quorum) continuano a ricevere richieste di calcolo e accesso ai dati (di fatto continuano ad eseguire VM e CT), ma non sono in grado di comunicare con gli altri nodi per prendere decisioni condivise.

Facciamo un esempio: immaginiamo un cluster iperconvergente composto da quattro nodi. Normalmente, i nodi comunicano tra di loro e condividono dati e informazioni per fornire servizi di calcolo, storage e rete in modo coerente.

A causa di un problema di rete, la comunicazione tra due coppie di nodi si interrompe. Ad esempio, i nodi 1 e 2 non riescono a comunicare con i nodi 3 e 4. In questa situazione, i nodi 1 e 2 possono ancora vedere l’uno l’altro e considerarsi “attivi” insieme, mentre i nodi 3 e 4 si considerano anch’essi attivi l’uno con l’altro. Questo crea due gruppi di nodi “attivi” che si considerano il centro del cluster, ognuno pensando di avere il controllo. Si noti che in questa situazione, essendo pari il numero di nodi, in una situazione normale, i 2 “pezzi” del cluster dovrebbero decidere di mettersi in una situazione di fencing e bloccare l’erogazione di tutti i servizi per evitare i seguenti problemi:

Decisioni divergenti: I nodi isolati possono prendere decisioni divergenti riguardo la gestione dei carichi di lavoro o dei dati, causando gravi inconsistenze e perdita di coerenza all’interno del cluster.

Duplicazione dei dati: Se i nodi isolati continuano a scrivere sui dati, potrebbe verificarsi una duplicazione delle informazioni tra i nodi del cluster. Questo può portare a conflitti di dati e perdita di integrità.

Guasti a cascata: Se i nodi isolati si riconnettono al cluster in seguito, la riunificazione dei dati potrebbe causare guasti a cascata, con conseguente instabilità e problemi di prestazioni.

6.4 Comportamento normale di un Cluster iperconvergente in una situazione di fault

Esistono svariati scenari che si possono verificare. Iniziamo analizzando il caso dell’esempio precedente ed il comportamento corretto:

Abbiamo un Cluster composto da 4 nodi, in cui la comunicazione si interrompe e 2 di questi vengono isolati. Le 2 parti del Cluster si metteranno così in una situazione di fencing ovvero una situazione di sicurezza utilizzata per garantire la consistenza e l’integrità del cluster in presenza di un guasto o di un nodo (o gruppo di nodi) inattivo.

Quando un nodo in un cluster iperconvergente diventa inattivo o smette di rispondere, potrebbe sorgere il rischio di “brain-split”. Per evitare questo problema, il fencing è utilizzato per “isolare” il nodo inattivo o problematico, interrompendo la sua connettività o alimentazione in modo che non possa né interagire con gli altri nodi del cluster. Nel caso in cui il nodo “isolato” non riuscisse più a raggiungere il resto del cluster ma risultasse attivo e funzionante, sarebbe lui stesso a mettersi in fencing. Ciò assicura che solo i nodi “sani” e “attivi” continuino a operare nel cluster continuando ad erogare servizi.

Nel nostro esempio a 4 nodi, il comportamento corretto sarebbe che entrambe le due parti del cluster si mettano nello stato di fencing. Ovvero tutto il cluster dovrebbe smettere di funzionare.

Adesso che abbiamo definito chi e come vengono prese le decisioni all’interno di un cluster vediamo cosa succede ai dati, VM e CT presenti sui nodi del Cluster.

6.5 Regole di HA

le regole di HA (High Availability) in un cluster iperconvergente mirano a garantire la disponibilità continua dei servizi, attivando il failover quando necessario. Vengono configurate con l’obiettivo di massimizzare la resilienza e ridurre al minimo il downtime dei carichi di lavoro, consentendo al cluster di fornire alta affidabilità per le applicazioni ospitate.

Esse rappresentano le istruzioni che il Cluster seguirà al verificarsi di eventi come il fault di un nodo. Tipicamente si occupano di:

• Attivazione del failover: Dopo aver rilevato un guasto o un problema, le regole di HA attivano il failover, che è il processo di ripristino delle risorse e dei servizi su un altro nodo funzionante. Ad esempio, le macchine virtuali o i container possono essere migrati automaticamente su un nodo sano e funzionante del cluster.
• Ridistribuzione del carico: Se il failover coinvolge il movimento delle risorse, le regole di HA assicurano che il carico di lavoro venga distribuito in modo bilanciato tra i nodi disponibili. Ciò aiuta a evitare il sovraccarico dei nodi e a garantire prestazioni ottimali.
• Garanzia di quorum: prima di prendere decisioni critiche come, per esempio, la migrazione delle risorse, viene verificato il “quorum” del cluster.
• Gestione delle priorità: Le regole di HA possono anche gestire le priorità delle risorse e dei servizi per garantire che le risorse più critiche vengano ripristinate prima in caso di failover.

È utile notare che le politiche di failover possono essere estremamente personalizzate. Ad esempio, in alcune implementazioni, è possibile impostare livelli di priorità per le macchine virtuali o i servizi, in modo che in caso di guasto, i servizi più critici vengano migrati per primi.