Cluster HA concetti di base —
Un cluster ad alta disponibilità (HA), in ambito informatico, è un insieme di due o più server (o altri componenti hardware) che lavorano insieme per garantire la continuità dei servizi, anche in caso di guasto di uno dei componenti. In sostanza, se un server fallisce, un altro prende il suo posto, evitando interruzioni del servizio.
In dettaglio, un cluster HA tipicamente include:
Server master/primario (o attivo): Esegue i servizi e gestisce il carico di lavoro principale.
Server slave/secondario (o di backup): Resta in standby, pronto a subentrare in caso di guasto del server primario.
Meccanismo di monitoraggio: Rileva il guasto del server primario e avvia il processo di failover.
Indirizzo IP virtuale: Un indirizzo IP condiviso dai server del cluster, che rimane attivo anche in caso di failover, garantendo la continuità dell’accesso ai servizi.
I cluster HA sono fondamentali per applicazioni critiche dove l’interruzione del servizio non è accettabile, come ad esempio database, server web, applicazioni aziendali e altro. L’obiettivo è ridurre al minimo i tempi di inattività e garantire la disponibilità continua dei servizi.
In sintesi, i cluster HA sono una soluzione efficace per aumentare la resilienza dei sistemi informatici e ridurre il rischio di perdite dovute a interruzioni del servizio.
Questa è una buona definizione di un cluster HA, nel nostro caso il discorso è lievemente diverso, parliamo di un sistema a due nodi che sono contemporaneamente attivo e passivo, e che possono diventare contemporaneamente master per il tempo necessario a compiere delle determinate operazioni.
Tutta la struttura si appoggia essenzialmente a due software dedicati, DRBD ed Heartbeat il primo è sostanzialmente un RAID1 over tcp un mirroring via rete in parole ancora più semplici, il secondo svolge funzioni di monitoraggio e in caso di necessità compie le azioni adeguate.
Normalmente al nostro interno si ha una situazione di questo tipo:
Quindi come si vede dati due nodi A e B e due volumi DRBD r0 ed r1 si avrà sul nodo A r0 master r1 slave e sul nodo B r0 slave ed r1 master.
Heartbeat monitora istante per istante la situazione e decide alla bisogna, in caso di emergenza ipotizzando che il nodo A vada offline heartbeat con le sue librerie di sistema provvede a fare lo switch dello stato DRBD facendo diventare r0 master e acquisisce (takeover) le risorse dell’altro nodo.
Questo stesso concetto viene usato anche per fare manutenzione ai nodi, infatti ipotizzando di dover aggiornare il firmware ai server che hostano il sistema si mette in slave un nodo, si fanno tutte le operazioni che sono necessarie, si riavvia il nodo e una volta online in automatico si sincronizza col nodo attivo, prende la parte master di sua competenza e migra le VM al proprio posto in modo praticamente trasparente all’utenza (un rallentamento durante la migrazione è inevitabile), una volta allineati i due nodi si compiono le stesse operazioni nello stesso ordine sull’altro nodo in modo che a fine lavori i due server avranno il firmware aggiornato.
Visto quanto sopra è intuitivo che i due nodi devono essere pensati a livello HW con risorse sufficienti (RAM, spazio, capacità di calcolo) a lavorare da soli alla bisogna e al 50% circa in condizioni normali.
Questo modo di lavorare oltre a sfruttare i due nodi contemporaneamente e non uno alla volta come in modo master/slave bilancia anche il carico di lavoro in modo da allungare la vita dei server.
Categorised as: Cluster | Linux | LVM2 | Work
Comments are disabled on this post