High Availability Cluster

Un cluster di “alta affidabilità” è una coppia di server identici che agiscono come un singolo server per garantire la totale continuità in caso di guasto. Con un solo server tipicamente sono ridondati i dischi e gli alimentatori, ma gli altri componenti vitali (mainboard, processore o schede integrate) rimangono con un unico esemplare. Il cluster ci protegge dai disastri e permette al business di continuare, in modo trasparente, anche se uno dei due server è andato KO.

La virtualizzazione ha reso il clustering una pratica sempre meno diffusa: oggi un server virtuale può essere spostato a caldo (cioè senza mai essere spento) da un nodo fisico ad un altro, sfruttando le funzionalità di failover integrate, ad esempio, in VMware.

Ma c’è almeno un caso in cui il clustering è ancora indispensabile: lo storage.

I server che controllano lo storage hanno direttamente collegati i dischi dati, spesso decine o centinaia di dischi. A differenza dei server virtuali, che “girano” proprio dentro questi dischi, i server dello storage non possono spostare loro stessi. La protezione migliore dai guasti è quindi il cluster. Potendo inoltre collegare due server a grande distanza, le soluzioni di geo-cluster sono le più affidabili, garantendo un rapido ripristino anche in caso di crash ambientale di uno dei due siti.

Il cluster dello storage è una funzionalità normalmente presente nei dispositivi SAN / NAS di fascia alta. Si acquistano due apparati identici, si collegano tra di loro e dopo la configurazione iniziano ad agire come se fossero uno solo.

Se però la nostra soluzione di storage è basata su Linux / DRBD / iSCSI / NFS oppure ci troviamo in uno scenario iper-convergente (nodi di elaborazione misti a nodi di storage) potremmo avere la necessità di configurare direttamente il clustering nel sistema operativo.

Alcuni appunti di come si fa in CentOS versione 7.

Per prima cosa installiamo i pacchetti di supporto al cluster e abilitiamo i relativi servizi (su entrambi i nodi):

L’installazione creerà l’utente “hacluster”, impostiamo la stessa password (su entrambi i nodi):

Da uno dei due nodi autorizziamo i server l’un l’altro:

Creiamo quindi il cluster (da uno dei due nodi, nell’esempio il cluster si chiama “cl1”):

Senza configurare lo “stonith” o “fence” il cluster si rifiuterà di partire. Per i test dobbiamo quindi disabilitare questa funzione ma in produzione assolutamente dovremo riabilitarla. Cosa è lo “stonith”? “Shoot The Other Node In The Head” letteralmente “uccidi l’altro nodo!”. Può accadere infatti che il collegamento tra i nodi venga interrotto per qualche motivo; il sistema di heartbeat comunicherà ad entrambi che il cluster si è interrotto. Ma se ad interrompersi è solo il collegamento ed entrambi i nodi sono in salute, ognuno penserà che l’altro si è guastato, promuovendosi a “master” della situazione.

In gergo siamo in un caso di “split brain” ovvero due nodi pensanti, attivi e master. Un disastro! Alcuni utenti collegati su uno, altri sull’altro, dati che avanzano a destra e sinistra senza più essere allineati. L’incubo di qualsiasi sistemista, una situazione spesso irreparabile se non con gravi danni. Il primo consiglio è quello di affidare l’heartbeat ad un cavo diretto evitando di passare da switch o altri dispositivi che potrebbero spegnersi.

Lo “stonith” ci protegge dallo “split brain” spegnendo l’altro nodo. In questo modo, anche se entrambi i nodi diventano master, cercheranno di uccidersi a vicenda. Come? Ci sono diversi modi: innescando lo shutdown del gruppo di continuità (e quindi togliendo fisicamente corrente) oppure forzando l’arresto dell’hardware tramite IPMI (esempio schede iLO o DRAC).

Avviamo quindi il cluster (da uno dei due nodi):

Se tutto è andato a buon fine e i due nodi si parlano correttamente, il cluster è avviato e possiamo controllarne lo stato:

Un cluster senza risorse però non serve a nulla, così sono solo due server che si parlano.

Come fanno i client a raggiungere uno dei due server del cluster? E soprattutto come fanno a sapere quale dei due server contattare quando l’altro è guasto? Semplice, perché il cluster assume un indirizzo IP virtuale! Questo terzo indirizzo (rispetto ai due dei server) viene spostato automaticamente dal software del cluster da un server all’altro.

Creiamo quindi l’IP virtuale (“clusterIP” è il nome arbitrario che diamo a questa risorsa; “ocf:heartbeat:IPaddr2″ è invece la tipologia specifica di risorsa cluster che stiamo creando, ogni servizio disponibile al cluster ha il suo nome di sistema”):

Lo stato del cluster è cambiato e ora ci mostra la prima risorsa condivisa:

Il nuovo indirizzo risponde e provando ad entrare in SSH saremo reindirizzati su uno dei due server. Per simulare un fail basta stoppare il cluster su uno dei due nodi e vedremo l’IP spostarsi automaticamente senza neanche perdere un PING:

Continuiamo ad aggiungere risorse e, visto che parlavamo di storage, aggiungiamo DRBD. Diamo per scontato che DRBD sia già configurato (ne parleremo in un futuro articolo, è un potente software di replica dello storage per Linux).

Una volta che il cluster è attivo, non vorremo modificare la configurazione durante il suo funzionamento né potremo arrestarlo. Ecco quindi che è consigliabile fare tutte le impostazioni in un file temporaneo per poi applicarlo alla fine.

Creiamo il file temporaneo (nell’esempio “drbd_cfg”):

Aggiungiamo la risorsa DRBD (nell’esempio “drbdData” è il nome da noi attribuito e “array1” è il nome della risorsa DRBD):

Poiché DRBD deve girare su entrambi i nodi (a differenza dell’IP di prima che invece viene spostato) dobbiamo “clonare” la risorsa (nell’esempio “drbdDataClone” è il nome della risorsa clonata):

Siamo quindi pronti per applicare le modifiche:

Adesso, ripetendo i test di prima, non solo si sposterà automaticamente l’indirizzo IP ma anche il ruolo di primary di DRBD!

Spostare DRBD però non è sufficiente, dobbiamo anche montare il filesystem sul nodo che è rimasto superstite. Magari perché questo filesystem è esportato in NFS o iSCSI. Creiamo quindi la risorsa filesystem (nell’esempio il nome è “drbdFS”):

Impostiamo quindi le relazioni tra i servizi e la priorità. Il filesystem dipende da DRBD e quest’ultimo deve essere avviato prima del filesystem (notare i nomi arbitrari precedentemente impostati, es “drbdDataClone”):

Applichiamo, et voilà il cluster DRBD è pronto!

Ultimo esempio, la configurazione dei servizi NFS se il volume DRBD è esposto tramite questo protocollo:

 

Chiama subito per maggiori informazioni +39 0113473770
oppure lasciaci i tuoi recapiti e sarai contattato il prima possibile:



 

Lascia un commento