Load Balancer per Cluster Email: LVS vs. HAProxy (e la scelta di Qboxmail)
Si è svolto nei giorni scorsi a Bologna la terza edizione dell’Incontro DevOps. L’occasione è stata buona anche per incontrare vecchi amici ed ex colleghi. Parlando con alcuni di loro, che hanno a che fare con grandi infrastrutture email, è riemerso il tema di cosa sia meglio utilizzare come bilanciatore di carico per i servizi POP/IMAP ed SMTP.
Il bilanciatore di carico, per chi non lo sapesse, è quel componente (di frontend) che prende in carico le connessioni in ingresso (quelle degli utenti per gli accessi POP/IMAP ad esempio) e le smista verso i server (backend) veri e propri che erogano i servizi. E’ sempre il bilanciatore che interviene quando un server di backend viene rimosso dal cluster, per manutenzione o interruzione, a dirottare il traffico verso i server rimasti attivi.
La scelta ricade quasi sempre fra LVS ed HAProxy (salvo per chi ha soldi in eccesso da spendere e sceglie F5). Personalmente sono un sostenitore di LVS, che in Qboxmail usiamo da sempre con soddisfazione. Vediamo quali sono le differenze principali fra questi due prodotti e poi proviamo a decidere quale dei sue sia migliore per un cluster di server email.
LVS lavora in kernel-space (disponibile quindi solo per Linux) il che lo rende estremamente leggero e veloce, anche se limitato in termini di funzionalità. Haproxy è invece un software che gira in user-space, sicuramente più portabile (gira praticamente su qualsiasi Linux/Unix) ma anche più costoso in termini di risorse.
Per darvi un idea di quante poche risorse usa LVS, considerate che ogni connessione attiva occupa solo 128 bytes di memoria (nella tabella dove queste vengono memorizzate). Con circa 4GB di RAM sarete in grado di smistare qualcosa tipo 500.000 connessioni simultanee ognuna delle quali può rimanere aperta per quasi 50 secondi (http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.ipvsadm.html#memory_requirements).
LVS lavora al layer 4, mentre haproxy lavora al layer 7 della pila OSI. Se questo da una parte è un vantaggio per haproxy, che può ispezionare anche il contenuto del pacchetto, di fatto si traduce in un maggiore carico a livello di CPU e quindi minore scalabilità. Certo, se dobbiamo fare da proxy ad un sito web questa funzionalità ci è utile ma per bilanciare dei servizi email è del tutto inutile e consuma solo risorse CPU. In un bilanciatore di carico con LVS il carico del server sarà quasi sempre pari a 0.00, mentre con haproxy si manterrà intorno allo 0.50.
Sempre con LVS è possibile ottimizzare il consumo di banda dei singoli server che compongono il cluster. Se configurato in modalità “Direct Routing” (o LVS-TUN) il bilanciatore si farà carico solo del traffico in ingresso mentre saranno i singoli server di backend ad inviare il traffico di risposta ai client remoti. Con haproxy (o LVS configurato come NAT) tutto il traffico IN/OUT passa dal bilanciatore il che lo tiene maggiormente sotto stress e vi constringe a dimensionarlo in modo da poter sostenere un traffico di rete pari alla somma totale del traffico diretta verso l’intero cluster.
Infine di LVS apprezzo molto il tool ipvsadm (… used to set up, maintain or inspect the virtual server table in the Linux kernel). Praticamente un bilanciatore di carico con LVS lo potete accendere, configurare e dimenticarvelo per anni.
Per la mia esperienza LVS è quindi la scelta migliore quando si parla di infrastrutture email. L’architettura consigliata (e quella che abbiamo implementato in Qboxmail) prevede questi componenti:
LVS (x2) -> Dovecot Director (x2) -> Dovecot POP/IMAP (x4)
L’uso di Dovecot Director è “obbligatorio” per mantenere l’associazione username/server di destinazione in modo da ottimizzare le risorse e gli indici di dovecot (specie se si usa uno storage via NFS).