Configurazione di un cluster con Linux High Availability

Per il CED di un'amministrazione comunale ho installato un doppio nodo di server Linux con un meccanismo di High Availabity.

Si tratta di un sistema composto da due server Linux, identici dal punto di vista hardware e software, in cui però i servizi realmente attivi sono suddivisi tra le due macchine.
In condizioni normali, una delle due funziona come web server (pubblicato esternamente), application server ed SQL server; l'altra come controller primario di dominio (in sostituzione di un precedente Windows NT), come file server per le condivisioni e come mail server (sia locale che pubblico).
Tra le due macchine è attivo un sistema che monitorizza costantemente lo stato dei servizi su entrambi i nodi. In caso di caduta di uno dei server, il sistema provvede a lanciare tutti i servizi inattivi sull'altra macchina, assumendone anche il nome e l'IP, in modo che entrambi i nodi siano sempre visti come un unico nodo dall'esterno.

I servizi attivati sono:
- Server 1
- Apache HTTPD web server, per la pubblicazione all'esterno del sito;
- PHP per un'eventuale contenuto dinamico del sito;
- ProFTPD ftp server, per la manutenzione del sito stesso da remoto;
- Apache Tomcat servlet container, come application server per i gestionali da utilizzare internamente;
- MySQL database server, come base dati per Tomcat.

Server 2
- Server mail Postfix, per la gestione della posta interna ed esterna;
- Server imap/pop3 Imap2000, per le caselle e-mail degli utenti;
- Filtro antispam Spamassassin associato al mail server;
- Samba server, per la condivisione di cartelle comuni e come controller primario di dominio, in sostituzione di un precedente Windows NT

Ovviamente, tutti i servizi sono installati in entrambe le macchine, ma solo quelli indicati sono normalmente attivi.

Sincronizzazione dei dati
Entrambe le macchine hanno i dischi suddivisi in tre partizioni (oltre alla swap):
- /dev/hda1 con il sistema di base, gli applicativi e le necessarie librerie;
- /dev/hda2 con tutte le cartelle necessarie agli applicativi funzionanti sul server 1, dove per cartelle necessarie si intendono quelle in cui può risiedere qualsiasi dato modificabile relativo a quegli applicativi (pagine del sito, basi di dati, files di configurazione specifici, logs ecc.);
- /dev/hda3, analogamente, con tutte le cartelle necessarie agli applicativi funzionanti sul server 2 (account utente, home directories, shares, cartelle di posta, logs ecc.).

Le partizioni dati /dev/hda2 e /dev/hda3 sono esportate via NFS tra le due macchine, e vengono montate in rispettive sottocartelle di /mnt all'avvio in entrambi i sistemi. Tramite questa condivisione, i dati modificati dalle applicazioni di un server vengono replicati sulle corrispondenti partizioni dell'altro server. Si viene così a creare un mirror virtuale, in modo che i due sistemi risultino costantemente sincronizzati sia come dati che come configurazioni. La replica viene effettuata con uno script in cron che esegue una copia incrementale ogni 5 minuti tra i due nodi.

Alternativa: mirror virtuale con drbd
Un'alternativa alla soluzione precedente avrebbe potuto essere quella di utilizzare drbd (Distributed Replicated Block Device), un sistema che consente la replica istantanea tra un nodo master ed uno slave; in pratica, l'equivalente di un RAID 1 (mirror), ma con i dischi separati su due macchine diverse collegate in rete. Questo non è stato fatto per precise scelte progettuali: in drbd si prevede che vi sia un nodo master ed uno slave, in cui i servizi sono effettivamente attivi solo sul master; lo slave entra in funzione solo quando il master cade.
Nel caso in questione, invece, la richiesta precisa dell'amministrazione comunale era di bilanciare il carico di lavoro tra i due nodi, seperando i servizi attivi; la soluzione drbd non sarebbe quindi stata valida. E' comunque una via praticabile e molto efficace quando si vuole che uno dei due nodi sia effettivamente solo un server di backup.

CONTROLLO DI FAILOVER
In entrambe le macchine è installato il servizio Heartbeat. Questo demone comunica tra le due macchine tramite una sottorete dedicata, come nello schema sottostante,


Oltre alle schede di rete (eth0) che comunicano con la rete locale e con l'esterno, tra i due server è attiva una sottorete basata su altre due schede (eth1) collegate da un cross cable. Tramite questa sottorete avviene la replicazione dei dati di cui al punto precedente.
Un cavo seriale null modem è collegato alle porte /dev/ttyS0 di entrambe i server. Tramite questo, Heartbeat controlla 'il battito del cuore' (da cui il nome) dei due server, ad intervalli di due secondi. Appena uno dei due cessa di 'battere', Heartbeat sul server rimanente esegue un IP takeover, ovvero si assume gli indirizzi IP ed il nome macchine del server defunto, rilancia il servizio di rete ed attiva su di sè i servizi che erano presenti sull'altro sistema.
Il tocco finale di questa installazione prevede una seconda seriale (qui /dev/ttyS1) su entrambe le macchine, collegata ad incrocio ad un gruppo di continuità alimentante l'altro server. Mediante l'aggiunta dell'utility STONITH (shoot the other node in the head!) presente nel pacchetto di Heartbeat, è possibile, in caso di failover, far sì che il server rimasto tolga letteralmente la corrente all'altro, dopo averne preso in carico i servizi. Questo evita un eventuale ed inatteso 'ritorno in vita' del server defunto con conseguente conflitto di IP e di porte (almeno, fino a che un amministratore non provvede a ripristinare la situazione iniziale).

Backup periodico su unità rimovibile
Come dettaglio finale, i due server hanno anche un'unità IDE a cassetto rimovibile. Su questa vanno montati hard disk identici a quelli presenti nelle due macchine, con lo stesso partizionamento. Ad intervalli prefissati, uno script controllato da cron su entrambi i server, verifica la presenza dell'hard disk nel cassetto, e se presente, provvede a montarne le partizioni ed eseguire un backup incrementale dell'intero sistema e dei dati. Il cassetto può essere montato indifferentemente sull'una o sull'altra macchina, o anche su entrambe, essendo i dati comunque replicati costantemente.

Privacy Policy