Mia mamma usa Linux! » LVS – Linux Virtual Server

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

Raoul Scarazzini — Mon, 13 Oct 2008 06:32:45 +0000

L’ultima fase del progetto prevede l’installazione di Postfix su tutti i real server ed il loro bilanciamento attraverso ldirectord. Postfix verrà configurato in modo che le caselle risiedano in un’area condivisa ed i profili dei domini e delle caselle vengano registrati in maniera centralizzata all’interno di un database MySQL. Il tutto verrà gestito dall’interfaccia web offerta dal programma postfixadmin.

Requisito essenziale per la riuscita di questa fase del progetto è la disponibilità di un server per lo storage e di un database che siano condivisi ed accessibili da tutti i real server, così come illustrato nello schema riassuntivo presentato nel primo articolo di questa serie.

Configurazione dello storage condiviso via NFS

Ai fini della buona riuscita del progetto è essenziale che le caselle di posta che verranno servite dalla batteria di server risiedano fisicamente nella stessa posizione. Questo significa che la directory nella quale il servizio postfix di ciascun real server scriverà i messaggi monterà uno storage comune. Questo potrà essere uno share NFS (Network File System), un NAS (Network Attached Storage) o un qualsiasi altro supporto di memorizzazione che sia condivisibile.

Nel caso in oggetto, lo storage comune è di tipo NFS e condivide una cartella nominata “mail” erogata dal server 192.168.0.150. La directory locale nella quale sarà montato tale share è /usr/local/virtual e quindi la riga da aggiungere in ciascun real server nel file /etc/fstab è:

192.168.0.150:/mail     /usr/local/virtual    nfs    rw,bg,vers=3    0 0

I questo modo ad ogni riavvio il filesystem NFS verrà automaticamente montato. Per effettuare il primo mount è sufficiente lanciare il comando come segue:

mount /usr/local/virtual

Configurazione del database condiviso con postfixadmin

Per fare in modo che tutti i real server possano leggere i profili in maniera centralizzata sarà necessario predisporre un database MySQL con una struttura adeguata a supportare la registrazione di tutti i dati relativi al server di posta. Tale server non potrà essere uno dei real server (così come per lo storage condiviso), in quanto una situazione simile annullerebbe la ridondanza implicita nella soluzione sviluppata sinora.

Esiste un progetto Open Source denominato postfixadmin che consente di creare e gestire il database relativo ad un server di posta Postfix attraverso un’intuitiva interfaccia web. Tale software è disponibile presso l’indirizzo http://postfixadmin.sourceforge.net/ e può essere installato su una qualsiasi macchina che possieda un webserver apache installato (ad esempio uno dei real server configurati nello scorso articolo). Una volta reperito il pacchetto sarà sufficiente decomprimerlo nella cartella relativa alla document root del sito erogato da apache:

cd /var/www
wget http://kent.dl.sourceforge.net/sourceforge/postfixadmin/postfixadmin-2.2.1.1.tar.gz
tar -xzvf postfixadmin_2.2.1.1.tar.gz
ln -s postfixadmin-2.2.1.1 postfixadmin

Sul server MySQL andrà creato il database relativo a postfix, attivando la console mysql:

mysql -u root -p

e lanciando i comandi SQL di creazione ed accesso relativi al database:

mysql> CREATE DATABASE postfix;
mysql> CREATE USER 'postfix'@'localhost' IDENTIFIED BY 'password_scelta';
mysql> GRANT ALL PRIVILEGES ON `postfix` . * TO 'postfix'@'192.168.0.50';
mysql> GRANT ALL PRIVILEGES ON `postfix` . * TO 'postfix'@'192.168.0.51';
mysql> GRANT ALL PRIVILEGES ON `postfix` . * TO 'postfix'@'192.168.0.52';
mysql> FLUSH PRIVILEGES;

Da notare come per l’accesso vengono configurati TUTTI i real server, in quanto ciascuno di questi dovrà poter accedere al database per la gestione delle informazioni dei profili. Nel file config.inc.php andranno quindi configurate le informazioni d’accesso al database modificando le seguenti righe:

$CONF['configured'] = true;
$CONF['database_type'] = 'mysql';
$CONF['database_host'] = 'localhost';
$CONF['database_user'] = 'postfix';
$CONF['database_password'] = 'chosen_password';
$CONF['database_name'] = 'postfix';

Collegandosi alla pagina di setup http://192.168.0.50/postfixadmin/setup.php verranno effettuati tutti i controlli sul sistema. Se questi avranno esito positivo, lo script creerà tutte le tabelle necessarie nel database postfix e consentirà di creare l’utente amministratore direttamente dall’interfaccia web. L’ultimo accorgimento necessario, prima di procedere con l’utilizzo dell’interfaccia, sarà quello di cancellare il file setup.php dalla directory di postfixadmin:

cd /var/www/postfixadmin
rm setup.php

La configurazione lato MySQL è così completa ed è accessibile attraverso l’interfaccia web. Da questa si potranno creare i domini, le caselle e gli alias che il server di posta dovrà gestire.

Installazione e configurazione di Postfix

L’installazione e la configurazione di Postfix deve essere effettuata su ciascuno dei server reali in maniera identica. Essa comprende il pacchetto base ed il modulo per l’integrazione con mysql:

apt-get install postfix postfix-mysql

La directory in cui i file di configurazione vengono registrati è /etc/postfix ed il file essenziale per il funzionamento di postfix è mail.cf. All’interno di questo file andrà definito il metodo di accesso ai profili ed alle risorse. Nel dettaglio i parametri essenziali da configurare riguardano quali reti fanno parte del sistema e quindi potranno sfruttare il mailserver per l’invio dei messaggi:

mynetworks = 127.0.0.0/8 192.168.0.0/24

Dove verranno archiviati i messaggini di posta ricevuti (mount NFS condiviso):

use_mbox = no
home_mailbox = /usr/local/virtual

E dove potranno essere reperite le informazioni relative ai profili:

virtual_alias_maps = mysql:/etc/postfix/mysql/virtual_alias_maps.cf
virtual_gid_maps = static:106
virtual_mailbox_base = /usr/local/virtual
virtual_mailbox_domains = mysql:/etc/postfix/mysql/virtual_domains_maps.cf
virtual_mailbox_limit = 1151200000
virtual_mailbox_maps = mysql:/etc/postfix/mysql/virtual_mailbox_maps.cf
virtual_minimum_uid = 105
virtual_transport = virtual
virtual_uid_maps = static:105

La dicitura mysql: indica che le informazioni relative al parametro sono contenute nel file con estensione cf indicato. Nel dettaglio i file indicati andranno creati nel path /etc/postfix/mysql come segue:

/etc/postfix/mysql/virtual_alias_maps.cf :

user = postfix
password = password_scelta
hosts = 192.168.0.200
dbname = postfix
table = alias
select_field = goto
where_field = address

/etc/postfix/mysql/virtual_domains_maps.cf :

user = postfix
password = password_scelta
hosts = 192.168.0.200
dbname = postfix
table = domain
select_field = description
where_field = domain
additional_conditions = and backupmx = '0' and active = '1'

/etc/postfix/mysql/virtual_mailbox_maps.cf :

user = postfix
password = password_scelta
hosts = 192.168.0.200
dbname = postfix
table = mailbox
select_field = maildir
where_field = username
additional_conditions = and active = '1'

Come è facilmente intuibile quanto indicato nei vari file sono i dati di accesso al database con i relativi nomi di tabella, di campo e le condizioni per estrapolare le informazioni relative ad alias, domini e mailbox servite da Postfix. Prima di avviare il servizio è necessaria un’ultima precisazione in merito ai permessi. Infatti Postfix scriverà nella cartella indicata nel parametro home_mailbox attraverso il suo utente, “postfix” appunto, che è stato creato durante l’installazione del pacchetto :

id postfix
uid=105(postfix) gid=106(postfix) gruppi=106(postfix),1(daemon)

Questo comporta che l’utente postfix ed il gruppo postfix devono avere lo stesso uid di sistema su tutti i real server, poiché ciascuno di questi si troverà nella condizione di scrivere nell’area condivisa. Essenziale sarà quindi assegnare la cartella /usr/local/virtual all’utente postfix:

chown postfix:postfix /usr/local/virtual

e che l’id dell’utente e del gruppo sia allineato su tutti i real server. Se le utenze hanno id disallineati è possibile correggere la situazione con i seguenti comandi:

groupmod -g 106 postfix
usermod -u 105 -g 106 postfix

Terminati questi ultimi controlli sarà possibile avviare il servizio postfix su ciascun real server:

/etc/init.d/postfix start

Aggiunta del servizio postfix ad ldirectord

A completamento del progetto l’attenzione viene spostata sui server nei quali è configurato il servizio di bilanciamento in alta affidabilità. All’interno del file /etc/ha.d/ldirectord.cf andranno così aggiunte le righe relative al servizio smtp:

virtual=192.168.0.100:25
real=192.168.0.50:25 gate
real=192.168.0.51:25 gate
real=192.168.0.52:25 gate
service=smtp
scheduler=wlc
persistent=600
protocol=tcp

Rimandando all’articolo precedente per i dettagli relativi a ciascun parametro dichiarato va solamente precisato che il tipo di scheduler selezionato è quello di default, “wlc”, ossia Weighted Least-Connection, che assegna più lavori ai server con minor numero di lavori attivi ed in base al peso che è stato loro assegnato. La configurazione verrà automaticamente attivata al salvataggio del file per via delle impostazioni illustrate nello scorso articolo e dopo alcuni secondi sarà possibile verificare come le nuove regole siano attive:

/sbin/ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.0.100:80 rr
-> 192.168.0.50:80              Route   1      0          0
-> 192.168.0.51:80              Route   1      0          0
-> 192.168.0.52:80              Route   1      0          0
TCP  192.168.0.100:25 wlc persistent 600
-> 192.168.0.50:25              Route   1      0          0
-> 192.168.0.51:25              Route   1      0          0
-> 192.168.0.52:25              Route   1      0          0

Quanto visualizzato conferma che il bilanciamento sta avvenendo per la porta 25 su tutti e tre i server reali configurati.

Test di funzionamento

Così come per il servizio apache, la prima verifica effettuabile sui server reali è quella di mettersi in ascolto sui log di postfix e controllare che le richieste pervenute all’indirizzo bilanciato siano correttamente distribuite:

tail -f /var/log/mail.info

Nei log scritti e visualizzati si dovranno distinguere due diverse tipologie di richieste pervenute, la prima rappresenta connessioni volte all’utilizzo del mail server per il ricevimento o la spedizione di un messaggio:

...
...
Oct  9 12:32:33 real-server-1 postfix/smtpd[30095]: 9325D106103: client=mail.xxxxxxxx.xxx[XX.XXX.XX.XXX]
Oct  9 12:32:33 real-server-1 postfix/cleanup[29792]: 9325D106103: message-id=<449745e7dc352554f0cc511e7cece2ce@localhost.localdomain>
Oct  9 12:32:33 real-server-1 postfix/qmgr[23253]: 9325D106103: from=<sender@xxxxxxxx.xxx>, size=1820, nrcpt=1 (queue active)
Oct  9 12:32:33 real-server-1 postfix/smtpd[30095]: disconnect from mail.xxxxxxxx.xxx[XX.XXX.XX.XXX]
...
...

La seconda tipologia rappresenta le connessioni effettuate dal bilanciatore volte a capire se il real server è responsivo e può ricevere lavori:

...
...
Oct  9 12:32:34 real-server-1 postfix/smtpd[30099]: connect from ha-balancer-1[192.168.0.1]
Oct  9 12:32:34 real-server-1  postfix/smtpd[30099]: disconnect from ha-balancer-1[192.168.0.1]
...
...

Chiaramente un ulteriore test consiste nello spedire dei messaggi attraverso il server e verificarne il corretto recapito.

Conclusioni

Il progetto presentato può chiaramente essere migliorato ed esteso attraverso l’introduzione di nuove funzionalità per Postfix come antispam e antivirus o con l’aggiunta di nuovi servizi bilanciati come pop3 e imap. Tali soluzioni non sono state descritte in questa serie in quanto oltre ad essere documentate in maniera esaustiva altrove non rappresentano l’obiettivo primario del progetto. La finalità primaria dei quattro articoli presentati è stata quella di dare una traccia piuttosto dettagliata di quelle che sono le potenzialità dei prodotti opensource nell’ambito di soluzioni in alta affidabilità.

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 nell’Ottobre 2008.

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

Raoul Scarazzini — Thu, 02 Oct 2008 07:05:12 +0000

La terza fase del progetto prevede la creazione di un servizio bilanciato su una batteria di real server. Verrà trattato il bilanciamento di un servizio di test (Apache 2) per verificare che il carico venga correttamente distribuito sui real server che fanno parte del Linux Virtual Server.

Bilanciamento con Linux

Il bilanciamento del carico con Linux è possibile attraverso Linux Virtual Server, l’insieme di moduli del Kernel progettato per adempiere a questo scopo. Sebbene vi sia la possibilità di configurare il funzionamento di tali moduli attraverso il comando ipvsadm, esiste un programma chiamato ldirectord che consente di impostare regole per il load balancing in maniera automatica partendo da un file di configurazione. Oltre a poter essere configurato affinché effettui il monitoring delle risorse configurate sui real server ldirectord possiede un enorme altro vantaggio: è completamente integrato con heartbeat come risorsa del cluster. Questo significa che associando la risorsa ldirectord all’indirizzo IP virtuale (configurato nella puntata precedente) si potrà avere il servizio di bilanciamento in alta affidabilità, eliminando di fatto lo SPOF (Single Point Of Failure) rappresentato dal bilanciatore operante su un singolo nodo.

Installazione di ldirectord e apache2

L’installazione del pacchetto ldirectord, che comprende tutti gli script necessari all’interfacciamento con heartbeat, può essere effettuata attraverso apt-get:

apt-get install ldirectord-2

tra i file installati insieme al pacchetto particolare attenzione va riservata allo script ldirectord nella cartella /etc/ha.d/resource.d/. Esso infatti è il fulcro dietro al quale opererà il bilanciamento software. Su ciascun real server invece andrà installato il pacchetto apache2 che servirà per i test di bilanciamento:

apt-get install apache2

L’installazione attiverà il demone apache che si metterà in ascolto sulla porta TCP 80.

Configurazione di ldirectord

La configurazione del servizio per convenzione è contenuta nel fie /etc/ha.d/ldirectord.cf ed un esempio della composizione dello stesso si trova nel file /usr/share/doc/ldirectord-2/ldirectord.cf.gz installato con il pacchetto. All’interno del file devono essere presenti un’area generale contenente le direttive globali ed un’area specifica relativa al servizio che si vuole bilanciare. L’area globale contiene le seguenti direttive:

checktimeout=3

Rappresenta i secondi dopo i quali la risorsa non rispondendo viene dichiarata morta.

checkinterval=1

Rappresenta i secondi tra un check e l’altro.

fallback=127.0.0.1:80

Valido solo per i servizi http, indica quale server funzionerà da fallback in caso tutti i server reali vengano dichiarati morti.

autoreload=yes

Stabilisce se ldirectord deve continuamente rileggere il file di configurazione dal disco. Se tale campo è valorizzato a “yes” allora le modifiche effettuate al file di configurazione verranno istantaneamente messe in atto dal demone.

logfile="/var/log/ldirectord.log"
#logfile="local0"

Indica dove verranno scritti i log, se in file predeterminato oppure nei log di sistema (syslog).

quiescent=yes

Permette di stabilire il comportamento di ldirectord di fronte ad un server dichiarato morto, se il valore è “yes” (che è il default), un real server morto non viene rimosso dalla tabella ipvs del kernel, ma il suo peso viene settato a zero, che comporta il non servire più le richieste pervenute al bilanciatore. Se il valore è “no” allora il real server morto viene completamente rimosso dalla tabella ipvs del kernel.

I parametri valorizzati rappresentano il dafult per i real server e possono essere modificati nelle singole dichiarazioni in modo da ottenere l’override degli stessi. Terminata la dichiarazione delle direttive globali l’attenzione è spostata sui servizi bilanciati, che sono dichiarati con una direttiva “virtual”:

virtual=192.168.0.100:80
real=192.168.0.50:80 gate
real=192.168.0.51:80 gate
real=192.168.0.52:80 gate
fallback=127.0.0.1:80 gate
service=http
request="index.html"
receive="It Works!”
virtualhost=www.esempio.com
scheduler=rr
protocol=tcp

Nell’esempio ad essere bilanciato è un servizio http. Questo come ogni virtuale ha tre aspetti essenziali: il metodo con cui le richieste vengono inviate ai real server (parametro real, che definisce il packet forwarding method), il tipo di servizio erogato (parametro service) e la tipologia di bilanciamento (parametro scheduler).

real

Ad un server reale corrisponde un indirizzo IP, una porta ed il metodo con cui i pacchetti passano dal virtuale ai reali. Può essere indicato anche il peso di ciascun real server nel caso in cui se ne possiedano con caratteristiche diverse, tale valore di default è 1 e salvo casi particolari può essere omesso. Essenziale però è il “packet forwarding method” che può essere uno di questi valori:

gate: che prevede l’utilizzo del direct routing in cui le richieste arrivano al server reale e questo risponde direttamente al client che ha contattato il servizio bilanciato.
masq: che prevede l’utilizzo della tecnica di masquerading (network address translation o NAT), dove le risposte dei server reali passano sempre dal bilanciatore che maschera il traffico in modo che appaia al client come proveniente da se stesso.
ipip: che prevede l’incapsulamento dei pacchetti arrivati al server bilanciato per la loro immissione all’interno di una sotto rete composta da interfacce virtuali.

La tipologia prevista nel progetto descritto si rifà al metodo gate in quanto i real server risiedono tutti sulla stessa rete (vedi prima puntata). masq è generalmente impiegato quando i real server ed il bilanciatore risiedono su reti differenti, mentre il metodo ipip è tra i tre il più particolare non verrà trattato in questa serie. Approfondimenti in merito agli argomenti descritti, che riguardano LVS nel dettaglio sono disponibili nell’LVS howto, in particolare ai seguenti link :

Direct routing (gate) : http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-DR.html

Tun (ipip) : http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-Tun.html

Masquerade (masq): http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-NAT.html

Service

Il tipo di servizio associato ad un servizio virtuale può essere uno fra ftp, smtp, http, pop, pops, nntp, imap, imaps, ldap, https, dns, mysql, pgsql, sip e none . Il nome di ogni servizio è autoesplicativo. Ldirectord come scritto in precedenza permette anche di effettuare il monitor dei servizi. Questo significa che un servizio oltre a rispondere alla porta associata (che nell’esempio illustrato è la 80) potrà essere interrogato per restituire dei risultati aspettati. Le quattro righe dell’esempio:

service=http
request="index.html"
receive="It Works!”
virtualhost=www.esempio.com

definiscono che il servizio è di tipo http (service), che per i check dovrà essere contattata la pagina index.html (request) e che all’interno di questa dovrà essere contenuto il testo “It Works!” (receive). Il tutto sarà associato al virtual host www.esempio.com. Se questa richiesta non verrà esaudita, il real server verrà dichiarato morto ed escluso quindi dal bilanciamento.

scheduler

L’ultimo parametro da comprendere è quello dello scheduler che rappresenta la tipologia di bilanciamento adottata dall’indirizzo virtuale. I valori possibili per il tipo di scheduler sono i seguenti:

rr – Robin Robin: Distribuisce i lavori equamente sui real server disponibili.

wrr – Weighted Round Robin: assegna i lavori ai real server in base al loro peso. Ad un peso maggiore da parte del real server corrisponderanno più lavori assegnati. Se i server hanno tutti lo stesso peso allora i lavori saranno distribuiti in forma equa.

lc – Least-Connection: assegna più lavori ai server con minor numero di lavori attivi.

wlc – Weighted Least-Connection: assegna più lavori ai server con minor numero di lavori attivi ed in base al peso che è stato loro assegnato. Questo è il default.

lblc – Locality-Based Least-Connection: assegna lavori destinati allo stesso indirizzo IP al medesimo server se questo non è sovraccarico ed è disponibile, in alternativa assegna i lavori ai real server scarichi, ricordando l’associazione nei futuri assegnamenti.

lblcr – Locality-Based Least-Connection with Replication: assegna i lavori destinati allo stesso indirizzo IP al nodo con il minor numero di lavori attivi nel gruppo di server creato per servire le richieste provenienti da questo. Se tutti i nodi del gruppo di server sono sovraccarichi, il lavoro viene accodato al nodo del cluster con il numero minore di lavori che diventa parte del gruppo di server. Se il gruppo di server non è stato modificato per un tempo specifico, allora il server più carico viene rimosso dal gruppo in modo che possa evadere le richieste in coda e garantire di essere replica alle future richieste.

dh – Destination Hashing: assegna i lavori ai real server basandosi sul controllo di un valore di hash assegnato staticamente in base all’indirizzo IP di destinazione.

sh – Source Hashing: assegna i lavori ai real server basandosi sul controllo di un valore di hash assegnato staticamente in base all’indirizzo IP sorgente.

sed – Shortest Expected Delay: assegna un lavoro entrante al real server dal quale si aspetta il minor tempo di attesa. Il tempo di attesa per un lavoro è calcolato con la formula (Ci + 1) / Ui dove Ci è il numero di lavori sul server stesso e Ui è il peso (weight) di questo definito in configurazione.

nq – Never Queue: assegna un lavoro entrante ad un real server inattivo (se c’è) anziché attendere per un real server veloce. Se tutti i real server sono occupati, adotta la tecnica “sed” (vedi sopra) per assegnare il lavoro.

La scelta del tipo di scheduler dipenderà quindi dalla tipologia di servizi impiegati e del tipo di real server dei quali si dispone. Nel caso illustrato lo scheduler è il più semplice, cioè il round robin che assegnerà le richieste in maniera equa su tutti i real server.

Aggiunta del servizio ldirectord a heartbeat

Per fare in modo che heartbeat gestisca la risorsa ldirectord all’interno del file /etc/ha.d/haresources basterà apportare le seguenti modifiche per entrambi i nodi del cluster:

ha-balancer-1 Ipaddr::192.168.0.100/24/eth0 ldirectord::/etc/ha.d/ldirectord.cf

Quanto aggiunto comprende la dichiarazione della risorsa ed il relativo file di configurazione. Per attivare la nuova configurazione sarà sufficiente effettuare il reload del servizio, sempre su entrambi i nodi del cluster:

/etc/init.d/heartbeat reload

La verifica della corretta aggiunta delle regole relative ad LVS è ottenibile attraverso il comando ipvsadm:

/sbin/ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-&gt; RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.0.100:80 rr
-&gt; 192.168.0.50:80              Route   1      0          0
-&gt; 192.168.0.51:80              Route   1      0          0
-&gt; 192.168.0.52:80              Route   1      0          0

Tale output conferma che esiste un indirizzo virtuale che bilancia su tre server reali alla porta 80. Tutti i server reali sono raggiungibili ed hanno perciò peso 1 (non avendo specificato preferenze di peso nella loro dichiarazione) che comporta un’eguale distribuzione dei lavori.

Abilitazione del packet forwarding

L’ultima operazione da svolgere sul bilanciatore è quella dell’abilitazione del packet forwarding, necessario affinché le richieste possano passare attraverso il server. Tale funzionalità si ottiene abilitando la seguente riga:

net.ipv4.conf.default.forwarding=1

nel file /etc/sysctl.conf e forzando un nuovo caricamento di questo file, che trasferirà nel kernel quanto dichiarato:

sysctl -p

Ovviamente le stesse operazioni dovranno essere effettuate sul nodo del cluster passivo.

Modifiche sui server reali

Prima di effettuare i test di funzionamento è necessario apportare le ultime modifiche ai server reali. Infatti questi devono essere configurati in modo da vedere il traffico diretto all’indirizzo virtuale come locale. Per fare ciò sarà necessario creare un alias dell’interfaccia di loopback che abbia l’indirizzo virtuale e che questo indirizzo non venga annunciato via ARP sulla rete. Per rendere possibile tutto questo nel file /etc/sysctl.conf è necessario aggiungere le seguenti righe:

net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.eth0.arp_announce = 2

Insieme alla dichiarazione della nuova interfaccia nel file /etc/network/interfaces:

auto lo:0
iface lo:0 inet static
address 192.168.0.100
netmask 255.255.255.255
pre-up sysctl -p > /dev/null

L’ultima riga, che effettua un nuovo caricamento delle regole relative a sysctl, attiva le variazioni sul comportamento ARP a livello di kernel. Tali regole saranno attivate con l’interfaccia, attraverso il comando ifup:

ifup lo:0

Il motivo di queste variazioni è insito nella struttura del progetto: quando una richiesta arriva all’indirizzo virtuale e questo la dirige su un real server sarà il real server stesso a rispondere, per via del fatto di possedere lo stesso indirizzo (nell’interfaccia loopback), questo indirizzo però non dovrà essere annunciato sulla rete in modo da non confondere gli switch ed i router implicati nello smistamento dei pacchetti. Va sottolineato che queste variazioni andranno apportate a tutti i real server facenti parte dell’LVS.

Maggiori dettagli su questo tema che può risultare ostico sono ottenibili ai seguenti link:
http://www.ultramonkey.org/3/topologies/hc-ha-lb-eg.html dove viene descritto un progetto simile.
http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP dove vengono descritte le configurazioni possibili per il comportamento degli annunci ARP.

Test di funzionamento

Il test di funzionamento dell’ambiente consiste nel controllo dei log del servizio apache2 su ciascun real server:

tail -f /var/log/apache2/access.log

Inviando poi richieste al sito a mano oppure attraverso software specifici per i test di carico, come http_load si potrà verificare come le richieste vengano correttamente distribuite sui tre server. Un’ulteriore verifica potrà essere effettuata sul bilanciatore dove l’output prodotto dal comando ipvsadm mostrerà per ciascun real server nei campi “ActiveConn” e “InActConn” un numero diverso da zero.

Conclusioni

Nel prossimo articolo, ultimo di questa serie, verrà infine trattata la configurazione di postfix sui real server e l’inclusione del servizio nel bilanciatore.

La serie comprende questi articoli :

Nota :

Questo articolo è originariamente apparso su Tux Journal nell’Ottobre 2008.

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

Raoul Scarazzini — Wed, 17 Sep 2008 07:26:04 +0000

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 è:

<nodo preferito> <risorsa 1> ... <risorsa n>

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 :

Nota :

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

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

Raoul Scarazzini — Fri, 12 Sep 2008 07:17:41 +0000

Postfix è uno fra i più diffusi software per la creazione di server di posta in ambito Linux. Sebbene le performance di questo software su carichi normali siano sempre rispettabili, nelle situazioni in cui è necessario gestire grandi quantitativi di caselle (ad esempio in server multi dominio) talvolta un solo server non basta ed è inoltre necessario garantire al sistema un’alta affidabilità, eliminando quelli che vengono definiti SPOF (Single Point Of Failure), componenti la cui rottura rende inusabile il sistema. Questa serie di articoli descrive una soluzione per creare una batteria di server di posta il cui carico viene distribuito via software attraverso un bilanciatore, il tutto in alta affidabilità.

Le componenti impiegate : LVS, heartbeat ed ldirectord

LVS

La definizione fornita dalla documentazione ufficiale di LVS è la seguente: un LVS è un gruppo di server che appaiono al client come un unico grande, veloce ed affidabile server (altamente disponibile).
Questa definizione si traduce nella pratica in una serie di moduli del Kernel Linux che agiscono a livello IP, in una via simile a quella di iptables, il firewall di Linux. Il comando ipvsadm, infatti, permette di inserire delle regole relative alle interfacce di rete del sistema specifiche per il bilanciamento. Queste regole vengono processate ad ogni richiesta pervenuta alla relativa interfaccia. Un funzionamento a così basso livello garantisce le massime performance ed una facilità implementativa notevole.
LVS agisce quindi da bilanciatore di carico (load balancer): rappresenta virtualmente tutti (uno o più) server in maniera trasparente all’utente che effettua le richieste, accogliendo le stesse e distribuendole attraverso i server reali.
La scalabilità di questa soluzione è evidente, infatti in presenza della necessità di aumentare performance, è sufficiente aumentare il numero di server reali senza cambiare il modo in cui l’utente effettua le richieste ai servizi erogati da LVS. In presenza di un numero maggiore di uno di server reali la soluzione è anche altamente affidabile, in quanto la perdita di un singolo nodo reale non comporta l’interruzione del servizio.

Heartbeat

Ciò che però appare altrettanto evidente è che il bilanciatore è un grosso SPOF. Se infatti lo strato virtuale rappresentato da questo dovesse crollare tutti i server reali sarebbero di fatto inutili.
Si rende necessario quindi rendere lo stesso bilanciatore altamente affidabile. Tutto questo è possibile attraverso heartbeat, il software prodotto dal gruppo Linux-HA. Heartbeat consente di configurare due macchine in modalità attiva-passiva che erogano risorse come l’indirizzo IP virtuale al quale vanno associate le regole LVS.
In caso di malfunzionamento della macchina attiva, la passiva in maniera automatica ne prenderà il posto.

Ldirectord

Pensare di gestire a mano la configurazione delle regole LVS attraverso il comando ipvsadm è certamente possibile, ma senza una buona conoscenza dell’ambiente potrebbe risultare problematico. Inoltre le regole relative ai server reali richiederebbero un costante monitoraggio per avere la certezza che tutti i servizi vengano erogati dalle relative macchine. Sarebbe impensabile infatti configurare un bilanciatore di servizi che distribuisca gli stessi su macchine che in realtà non rispondono a dovere, si creerebbe un disservizio. Per risolvere queste problematiche esiste un ottimo software chiamato ldirectord.
Ldirectord è un demone tipicamente usato come risorsa di heartbeat che si preoccupa di definire le regole LVS relative alle risorse impiegate ed effettuare il monitoraggio delle stesse.

Struttura del progetto

Quanto esposto sinora è riassumibile dal seguente schema:

Figura 1

Le regole per il bilanciamento sono dichiarate nelle due macchine 192.168.0.1 e 192.168.0.2 in alta affidabilità su cui è installato heartbeat con la risorsa ldirectord. Tale struttura eroga l’IP virtuale 192.168.0.100 che accoglie le richieste per i servizi dichiarati sui real server (nel nostro caso Postfix).

L’impiego o meno di uno storage comune è dipendente dal tipo di servizio che viene bilanciato. Postfix gestisce delle caselle di posta registrate su disco e per questo tutti i real server dovranno scrivere i dati relativi a queste, nello specifico i messaggi, nella stessa area. Nello schema riassuntivo tale storage è rappresentato da un filesystem NFS (erogato da un server Linux o da un NAS) ma questo potrebbe essere uno storage in fibra collegato o una qualsiasi altra soluzione che permetta di condividere lo spazio tra tutti i real server.
Sul database MySQL risiederanno i profili virtuali di tutte le utenze del server di posta.

Realizzazione del progetto

Definite le basi del progetto, la sua realizzazione si potrà strutturare in queste fasi:

Installazione di heartbeat e test di failover sull’indirizzo virtuale;
Installazione di ldirectord e test di bilanciamento su un servizio test;
Installazione di Postfix e prove di bilanciamento;

Conclusioni

Nel prossimo articolo verrà affrontata la prima fase del progetto comprendente l’installazione di heartbeat ed i primi test di failover sull’indirizzo bilanciato.

La serie comprende questi articoli :

Nota :

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