Entrambe le macchine hanno  Apache2 installato, così come hanno pronta un'istanza Zope con ZEO. Heartbeat viene usato per verificare il normale funzionamento del cluster (ovvero verifica se il master è attivo). Entrambe hanno accesso ad internet con il proprio indirizzo IP, e con un indirizzo IP dinamico che deve puntare al master, o allo slave quando il primo è non attivo.

Per maggiori informazioni potete consultare il sito di  heartbeat.

La configurazione può essere rappresentata graficamente dal seguente schema:

La linea rossa indica l'itinerario che sarà attivo dopo il failover. Le linee nere indicano gli itinerari normali di funzionamento. Questo setup presuppone l'uso di Apache2 con mod_proxy_balancer

Il cluster viene contattato nel suo insieme con l'indirizzo IP dinamico, che normalmente è configurato sul master. Il server master riceve tutte le richieste sulla porta 80 ed usa il mod_proxy_balancer per distribuire le richieste sulle due macchine, o verso Squid o direttamente agli Zope. Il bilanciamento del carico non è una parte essenziale di questa configurazione, ma permette un uso più efficiente dell'hardware. Gli Zope client utilizzano uno ZEO server come backend. Lo ZEO server gira sul master ed è raggiunto con l'indirizzo IP dinamico dagli ZEO client. I dati del master (il Data.fs) sono sincronizzati con lo slave. Sullo slave lo ZEO server viene tenuto non attivo.

Nel caso di failover, heartbeat si prende cura del' assegnazione del indirizzo IP dinamico allo slave e ne avvia lo ZEO server. Da quel momento in poi sarà questo ZEO server quello utilizzato dagli ZEO client: il passaggio avverrà automaticamente. Se possibile, lo ZEO server sul master sarà bloccato ed il processo di sincronizzazione disattivato. Il recupero dal failover non è automatizzato a causa dell'alto rischio di errori in questa procedura.

Il recupero include:

• verifica dell'integrità dei dati sullo slave;

• copia dei dati modificati dallo slave al master;

• arresto dello ZEO server sullo slave;

• avvio dello ZEO server sul master;

• riattivazione della sincronizzazione sullo slave.

• riattivazione di  heartbeat sul master.

Se si desidera, si può automatizzare il recupero, ma abbiamo scelto di effettuare l'intervento manuale per assicurarci di poter verificare completamente la natura del guasto prima del recupero, nel corso del quale ci potrebbe essere un intervallo molto breve in cui gli utenti noteranno l'indisponibilità del servizio. Infatti ad un certo punto lo ZEO server della macchina slave deve essere interrotto prima della copiatura del Data.fs sul master. Si può studiare la possibilità di non arrestare lo ZEO server durante la copia, ma farlo soltanto dopo che il master ha ripreso il suo ruolo.