Musa, quell'uom di multiforme ingegno   Dimmi, che molto errò, poich'ebbe a terra Gittate d'Ilïòn le sacre torri; Che città vide molte, e delle genti L'indol conobbe; che sovr'esso il mare Molti dentro del cor sofferse affanni, Mentre a guardar la cara vita intende, E i suoi compagni a ricondur: ma indarno Ricondur desïava i suoi compagni, Ché delle colpe lor tutti periro. (Omero, I Libro Odissea)

Internetworking

Server in Alta Affidabilità

L'articolo descrive una soluzione adottata per erogare servizi in alta affidabilità utilizzando piattaforme open source. La realizzazione non consente di implementare in alta affidabilità qualsiasi tipologia di servizio a causa dei particolari vincoli che caso per caso possono presentarsi, ma offre una metodologia utile per approcciare il problema, rimandando alla letteratura specifica quando siano documentati accorgimenti specifici. Ad esempio sistemi quali database server, DNS server o VMware server dispongono di meccanismi propri di alta affidabilità e pertanto è assolutamente conveniente prevedere la loro implementazione piuttosto che meccanismi generici.

La soluzione è stata utilizzata per implementare i server Internet attestati in DMZ come relay di posta, server web e server DNS. L'obiettivo che ci si proponeva era quello di disporre di due server distinti in grado di erogare i servizi in bilanciamento di carico per sfruttare tutte le risorse hardware disponibili, con la garanzia della continuità di servizio in caso di malfunzionamento dell'hardware di uno dei due sistemi.

Inoltre, poiché per garantire la continuità di servizio è stata ridondata la componentistica di rete, la configurazione dei due server prevedeva la possibilità di sfruttare le risorse hardware dei due nodi, qualora uno degli apparati di rete o delle schede di rete dei server subisse un guasto. Lo schema rappresentato in seguito descrive lo scenario sul quale si lavora.

Per descrivere gli accorgimenti utilizzati è opportuno suddividere i problemi e quindi affrontarli singolarmente; ricapitolando gli obiettivi della realizzazione possono riassumersi in:

1. continuità di funzionamento per i servizi ospitati sui due server, attraverso la possibilità di migrare l'indirizzo IP al quale i client fanno rifeimento tramite la traduzione via DNS di un hostname (ad esempio: www.dominio.it) da un server all'altro a seconda del loro stato di funzionamento;
2. allineamento dei dati presenti sui due server;
3. bilanciamento di carico tra i due server;
4. utilizzo delle risorse del server che subisce la rottura della scheda o dell'apparato di rete.

Continuità di servizio

Per garantire la raggiungibilità dei servizi erogati da parte dei client è necessario che l'indirizzo al quale si fà riferimento per il servizio sia sempre attivo e per implementare questa funzionalità è stato scelto il meccanismo dell'heartbeat, non solo per la sua affidabilità, consentendo di verificare lo stato dell'apparato principale sia via rete che porta seriale, ma soprattutto per la sua flessibilità, potendo attivare localmente script di sistema all'insorgere di un evento quale, ad esempio, l'irraggiungibilità del secondo server.

Questa pecularietà del meccanismo consentirà di riprogrammare i sistemi nel loro funzionamento per l'implementazione delle funzioni individuate dai punti 3 e 4 precedentemente descritti.

Heartbeat definisce uno dei due server come primario e configura su questo l'indirizzo IP condiviso associato al servizio, quindi controlla costantemente lo stato di funzionamento e di raggiungibilità del server primario dall'istanza attiva sul server secondario e non attiva nessuna funzione fintanto che il server principale funziona correttamente. Qualora rilevasse l'irraggiungibilità del server primario, l'istanza hearbeat sul secondario acquisirebbe l'indirizzo IP del servizio e attiverebbe gli script previsti per lanciare le applicazioni necessarie a seconda dei casi, come si vedrà in seguito.

In questa fase il server secondario potrà rispondere alla richieste dei client al posto del server primario, isolato o non funzionante.

Allineamento dei dati sui due server

Nella realizzazione che si sta descrivendo i dati da allineare tra i due nodi del cluster erano i contenuti dei siti e la configurazione dei server DNS, dal momento che i server di posta, funzionando da relay non erano soggetti a modifiche. In questo caso la semplicità dei contenuti favoriva la soluzione ipotizzata, dal momento che le applicazioni utilizzavano dati statici e sopportavano bene un allineamento dei dati in forma di copia.

Per realizzare questa funzionalità è stato scelto il software "rsync" attivato da uno script, controllato da cron, con le procedure di riavvio per i processi DNS che devono rileggere la configurazione per attivare le nuove configurazioni. Poiché rsync prevede la copia delle sole modifiche introdotte dopo l'ultimo allineamento, la sua attività può essere schedulata abbastanza frequentemente, in quanto senza caricare il server di ripetuti e pesanti trasferimenti di dati.

Preme sottolineare che non sempre, in funzione del particolare prodotto, è possibile implementare un cluster che sia in grado di implementare le funzioni ai punti 3 e 4 precedentemente indicati; spesso è possibile prevedere due nodi per garantire la continuità di servizio, ma per peculari esigenze dell'applicazione potrebbe risultare necessario rinunciare al bilanciamento di carico tra i nodi. Un esempio può essere l'implementazione di un server DB in alta affidabilità; poiché è il server applicativo che realizza la memorizzazione dei dati nel DB, non è possibile aggiornarli in tempo reale con meccanismi esterni e quindi possono essere proposte due alternative:

1. si attiva il server DB su uno solo dei nodi, salvando sul secondo i dati periodicamente e nel rispetto degli allineamenti previsti dal DB;
2. si implementano i meccanismi di distribuzione di carico forniti dal server DB nativamente, quando previsti.

Nel primo caso una valida alternativa al software rsync può essere "drbd", pacchetto in grado di simulare un meccanismo di allineamento RAID 1, duplicando un intero dispositivo a blocchi via rete tra due server. In questo caso è consigliabile realizzare il collegamento di rete tra i due server mediante due schede di rete tra loro aggregate, per massimizzare le prestazioni e la continuità di servizio.

Bilanciamento di carico

Quando le applicazioni, come nel caso che si sta descrivendo, consentono di inserire un meccanismo di bilanciamento esterno, è possibile integrare ad heartbeat il software "ldirectord" che fornisce un'interfaccia trasparente ai client utilizzatori di servizi erogati da diversi server. Il software intercetta le richieste di connessione nei confronti dei server applicativi e le redireziona verso i nodi attivi, verificando l'effettivo stato di funzionamento di ogni nodo e garantendo bilanciamento di carico e quindi continuità di servizio.

La configurazione tipica di ldirectord prevede un server configurato come sistema bilanciatore di carico che accede sulla stessa LAN, o su una rete di backend, ai server che erogano di fatto i servizi, redirezionando richieste di connessioni e risposte dei sistemi. La soluzione consente di sfruttare le risorse hardware di un insieme di server, virtualizzando i servizi sul bilanciatore.

Sfruttamento delle risorse hardware in presenza di guasto sulla rete

Nella soluzione che si sta descrivendo il sistema si riduce ad un cluster di due nodi che garantiscono le caratteristiche indicate precedentemente dal punto 4 attraverso l'integrazione di heartbeat e ldirectord e un collegamento di rete diretto tra i due nodi, che dispongono ciascuno di almeno due interfacce di rete, una attestata sulla LAN e la seconda privata e, come già detto, collegata direttamente.

Heartbeat gestisce la virtualizzazione dell'indirizzo IP associato ad uno o più servizi, consentendo l'attivazione di risorse software sui nodi che ereditano l'IP virtuale o che sono designati come nodo primario del cluster. Il servizio ldirectord viene attivato da heartbeat sul nodo che detiene l'IP virtuale, associato all'interfaccia di rete principale e risponde di fatto alle richieste di connessione ai servizi, inoltrandole sia ai processi locali che al server secondario, attraverso l'interfaccia di rete privata, mascherando con l'indirizzo IP privato quelli di provenienza.

Il server secondario instrada tutto il traffico sull'interfaccia principale, tranne le risposte alle connessioni attivate da ldirectord attraverso l'interfaccia privata, alle quali risponde direttamente tramite la stessa interfaccia, con instradamento diretto verso la sottorete IP condivisa dalle interfacce private. In questa situazione si sfruttano le risorse hardware dei due server, bilanciando il carico tra i servizi ospitati dai due nodi.

Descrizione dei meccanismi di continuità di servizio

Qualora dovesse presentarsi un guasto su uno dei due nodi, quello attivo continuerebbe ad erogare il servizio.

Nel caso in cui il guasto dovesse presentarsi sull'interfaccia principale del nodo primario o sullo switch al quale risulta attestato il nodo primario, heartbeat trasferirebbe l'indirizzo virtuale sul nodo secondario, sul quale attiverebbe ldirectord che, rispondendo alle connessioni dei client, le inoltrerebbe ai servizi locali e a quelli del nodo primario, isolato attraverso l'interfaccia di rete principale, ma raggiungibile attraverso l'interfaccia privata.

In questa situazione si ripropone lo stato iniziale, con una configurazione simmetrica in cui si invertono il ruolo del nodo primario con il secondario, che però ripropone le stesse modalità di funzionamento e di sfruttamento delle risorse hardware anche in presenza di un guasto, realizzando il punto 4, introdotto all'inizio dell'articolo.