Terminata l’introduzione al progetto le attenzioni vengono dirette alla messa in pratica, partendo dall’installazione di heartbeat che si occuperà di gestire in alta affidabilità l’indirizzo virtuale sul quale poi andrà bilanciato il servizio Postfix. I passi che verranno descritti fanno riferimento alla distribuzione Debian Etch e, fatta eccezione per la parti relative alle installazioni dei software che dipendono dal sistema di gestione pacchetti utilizzato, sono adattabili a tutte le maggiori distribuzioni.

Requisiti hardware

Il requisito minimo per avere un servizio in alta affidabilità è quello di due macchine, specularmente configurate e collegate l’una all’altra tramite una scheda di rete dedicata attraverso un cavo incrociato, definito “cross”. Le schede di rete dovranno quindi essere due per ciascuna macchina. Le prime collegate agli switch della LAN si occuperanno di erogare l’indirizzo virtuale, mentre le schede di rete secondarie saranno necessarie per comunicare il battito cardiaco (heartbeat, appunto) tra una macchina e l’altra. Questa struttura consente a ciascuna componente di carpire dati fondamentali sullo stato del sistema: se c’è comunicazione con la rete esterna e se c’è connettività tra le due macchine che compongono il cluster.

Configurazione dei sistemi

Presupponendo che in ciascuno dei sistemi scelti esista già un’interfaccia collegata alla rete locale, andrà configurata l’interfaccia per l’heartbeat, aggiungendo al file /etc/network/interfaces le seguenti linee :

auto eth1
iface eth1 inet static
address 10.0.0.1
netmask 255.255.255.0

Sul nodo secondario del cluster l’indirizzo dovrà ovviamente essere 10.0.0.2. Dopo aver attivato l’interfaccia attraverso il comando :

ifup eth1

sarà possibile testare la connettività attraverso un semplice ping :

ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.145 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.101 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.102 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.102 ms

A titolo preventivo è bene inserire nel file /etc/hosts di ciascuna macchina le corrispondenze IP nome host relative ai server di modo che queste siano indipendenti dal DNS :

192.168.0.1	ha-balancer-1.pgol.com	ha-balancer-1
192.168.0.2	ha-balancer-2.pgol.com	ha-balancer-2

Il sistema è quindi predisposto a procedere con l’installazione del pacchetto heartbeat :

apt-get install heartbeat-2

I file essenziali per la configurazione di heartbeat sono essenzialmente tre : ha.cf, haresources ed authkeys e si trovano nella directory /etc/ha.d/.

ha.cf

In ha.cf è necessario includere la configurazione relativa alla struttura del cluster per definire quali sono le sue componenti e come calcolare lo stato di salute del sistema. Ecco come viene compilato il file relativo al progetto, che per le ragioni che verranno spiegate avanti potrà essere identico su entrambe le macchine. Per ciascuna opzione è indicata la descrizione :

keepalive 1

Indica l’intervallo tra un heartbeat e l’altro (1 secondo).

deadtime 14

Indica il numero di secondi dopo i quali heartbeat considererà un nodo morto (14 secondi).

warntime 7

Indica il numero di secondi dopo i quali heartbeat allerterà per un ritardo nella comunicazione con un nodo (7 secondi).

initdead 120

Si riferisce al primo avvio e considera il numero di secondi dopo i quali heartbeat considererà un nodo morto (120 secondi, due minuti).

udpport 694

Indica la porta UDP utilizzata per gli scambi heartbeat.

ucast eth1 10.0.0.1
ucast eth1 10.0.0.2
ucast eth0 192.168.0.1
ucast eth0 192.168.0.2

Le quattro righe relative ad ucast indicano le interfacce locali e gli ip di destinazione che devono essere utilizzate per lo scambio di heartbeat. Nei controlli le interfacce locali ignorate, per questa ragione è possibile avere un file identico per entrambi i nodi specificando tutte le interfacce (ed i relativi ip da contattare) di entrambi i sistemi. In questo caso sono state configurate le interfacce collegate via cavo cross e quelle collegate alla LAN.

auto_failback off

Il parametro determina se una risorsa che è stata presa in carico da un nodo secondario (in seguito alla perdita del nodo primario) debba ritornare sul nodo originario una volta che questo torna attivo.

node    ha-balancer-1
node    ha-balancer-2

Le due righe rappresentano l’elenco delle macchine che fanno parte del cluster, identificate come nodi.

ping_group dmz 192.168.0.50 192.168.0.51 192.168.0.52

Questa opzione è necessaria al cluster per capire se è collegato alla rete locale. La connettività da parte del cluster ad almeno una delle macchine facenti parte del gruppo comporta la conferma che il cluster sia connesso alla rete locale.

respawn hacluster /usr/lib/heartbeat/ipfail

Indica il programma che lancia e controlla lo stato delle interfacce (ipfail è il default).

apiauth ipfail gid=haclient uid=hacluster

Specifica quali utenze possono collegarsi a quali API (in questo caso rimane ancora il default relativo ad ipfail, l’unico ad interessare il progetto in corso. Tali utenze sono create automaticamente dall’installazione di heartbeat.

deadping 30

Specifica il numero di secondi dopo i quali il gruppo di ping (definito dmz) verrà ritenuto morto e quindi assumerà la condizione disconnessa per il cluster.

use_logd off

logfile /var/log/ha.log

Per facilità di debug e ordine nei log viene disabilitato l’utilizzo di logd (che avrebbe riempito i log di sistema) e dirottata la scrittura dei log nel file /var/log/ha.log. Chiaramente esistono numerose altre opzioni disponibili per la configurazione del cluster e sono tutte illustrate all’indirizzo http://www.linux-ha.org/ha.cf.

haresources

Il secondo file che completa la configurazione di heartbeat è quello relativo alle risorse, haresources. Ciascuna riga contenuta in questo file rappresenta una risorsa ed il formato della stessa è:

  ... 

nel caso relativo al nostro progetto durante la fase iniziale utilizzeremo solo la risorsa “IpAddr” che controllerà l’attivazione di un indirizzo virtuale associato ad un interfaccia reale (con la relativa classe), che nel proseguo diventerà l’indirizzo bilanciato del servizio Postfix :

ha-balancer-1 IPaddr::192.168.0.100/24/eth0

authkeys

Prima di avviare il servizio cluster è necessario effettuare un ultimo ulteriore passo che consiste nella creazione della chiave che verrà utilizzata da heartbeat per autenticare i nodi che faranno parte del cluster. Le informazioni relative alla chiave sono contenute nel file authkeys, la chiave è ottenibile attraverso questo comando (che sfrutta il generatore casuale di numeri del kernel ed il comando md5sum):

dd if=/dev/urandom count=4 2 > /dev/null | md5sum | cut -c1-32
aea572119260bbe6b87c0386c3cc0f75

tale valore va posto nel file authkeys in questa forma :

auth 1
1 sha1 aea572119260bbe6b87c0386c3cc0f75

La prima riga indica l’identificativo della chiave utilizzata, mentre nella seconda questa viene definita attraverso l’identificativo, il tipo (sha1) ed il valore. Questo file deve essere leggibile dal solo utente di root :

chmod 600 /etc/ha.d/authkeys
chown root:root /etc/ha.d/authkeys

Avvio dei servizi

Terminata la configurazione dei tre file, che dovranno essere identici su ciascuno dei due nodi, è possibile avviare il servizio heartbeat :

/etc/init.d/heartbeat start

è possibile seguire l’evoluzione dell’avvio monitorando il file di log ha.log al cui interno, se i file sono stati compilati a dovere, verranno scritte righe come questa :

heartbeat[4271]: 2008/09/01_09:50:37 info: **************************
heartbeat[4271]: 2008/09/01_09:50:37 info: Configuration validated. Starting heartbeat 2.0.7
...

In breve, dopo i controlli sullo stato dei nodi e la loro connettività, si arriverà all’avvio della risorsa definita :

ResourceManager[4445]:  2008/09/01_09:50:53 info: Running /etc/ha.d/resource.d/IPaddr 192.168.0.100/24/eth0 start
IPaddr[4663]:   2008/09/01_09:50:53 INFO: eval /sbin/ifconfig eth0:0 192.168.0.100 netmask 255.255.255.224 broadcast 192.168.0.255
IPaddr[4663]:   2008/09/01_09:50:53 INFO: Sending Gratuitous Arp for 192.168.0.100 on eth0:0 [eth0]
IPaddr[4663]:   2008/09/01_09:50:53 INFO: /usr/lib/heartbeat/send_arp -i 500 -r 10 -p /var/run/heartbeat/rsctmp/send_arp/send_arp-192.168.0.100 eth0 192.168.0.100 auto 192.168.0.100 ffffffffffff
IPaddr[4581]:   2008/09/01_09:50:53 INFO: IPaddr Success

Il riscontro dell’effettivo funzionamento può essere effettuato sul nodo master relativo al servizio tramite il comando ifconfig :

...
eth0:0    Link encap:Ethernet  HWaddr 00:0F:1F:67:CF:C1
inet addr:192.168.0.100  Bcast:212.48.3.255  Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
Interrupt:177
...

che conferma come l’indirizzo virtuale sia correttamente attivo. Effettuando dei ping sull’indirizzo virtuale da macchine diverse dal nodo master si otterrà un’ulteriore conferma dell’effettivo funzionamento del sistema.

Test di failover

Per controllare l’effettivo funzionamento della struttura del cluster andranno effettuati tre diversi test.

Primo test

Il primo test consiste nell’acquisizione da parte delle risorse da parte del secondo nodo attraverso il seguente comando, da eseguire appunto sul nodo che non detiene la risorsa:

/usr/lib/heartbeat/hb_takeover foreign

questo provocherà lo switch della risorsa sul secondo nodo in maniera trasparente per il sistema:

heartbeat: 2008/09/15_10:38:27 info: acquire foreign HA resources (standby).
...
...
heartbeat: 2008/09/15_10:38:31 info: foreign HA resource acquisition completed (standby).
heartbeat: 2008/09/15_10:38:31 info: Standby resource acquisition done [local].
heartbeat: 2008/09/15_10:38:31 info: remote resource transition completed.

I log dimostrano come la risorsa risieda ora sul nodo secondario.

Secondo test

Il secondo test consiste nel restart del servizio heartbeat sulla macchina in cui è attivo il servizio e la verifica che questo sia correttamente acquisito dal nodo ancora attivo:

/etc/init.d/heartbeat restart

Ancora una volta, attraverso i log si ottiene conferma della corretta esecuzione delle operazioni:

heartbeat: 2008/09/15_10:44:16 info: Received shutdown notice from 'ha-balancer-2'.
heartbeat: 2008/09/15_10:44:16 info: Resources being acquired from 'ha-balancer-2'.
heartbeat: 2008/09/15_10:44:16 info: acquire all HA resources (standby).
heartbeat: 2008/09/15_10:44:16 info: Acquiring resource group: from 'ha-balancer-1'
....
....
heartbeat: 2008/09/15_10:44:43 info: remote resource transition completed.

Terzo test

Il terzo test consiste nello spegnimento improvviso della macchina su cui risiede la risorsa e la verifica che l’unico nodo attivo acquisisca la risorsa. Il comportamento dovrebbe risultare del tutto simile a quello degli altri test, con l’identificazione all’interno dei log delle notifica sulla perdita del nodo che deteneva la risorsa:

heartbeat: 2008/09/15_10:48:31 WARN: node ha-balancer-1: is dead

Conclusioni

Il prossimo articolo tratterà dell’implementazione del servizio di bilanciamento via LVS gestito dalla risorsa ldirectord.

La serie comprende questi articoli :

Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (1 di 4)
Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (2 di 4)
Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (3 di 4)
Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (4 di 4)

Nota :

Questo articolo è originariamente apparso su Tux Journal nel Settembre 2008.