DUE SERVER DI RETE CON CLUSTER HIGH AVAILABILITY

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 di high availability, 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.

SERVER 1	SERVER 2
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 mail Postfix, per la gestione della posta interna ed esterna; Sistema antivirus Amavis, integrato al mail server; Filtro antispam Spamassassin integrato al mail server; Server imap/pop3 Imap2000, per le caselle e-mail degli utenti; Samba server, per la condivisione di cartelle comuni e come controller primario di dominio, in sostituzione di un precedente Windows NT

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.

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 UNITA' RIMOVIBILE

I due server hanno anche un'unità IDE a cassetto rimovibile. Su questa possono essere 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 del 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.