Cluster di tre server in HA + LB con drbd

Recentemente ho dovuto configurare tre server per implementare un sistema cluster in HA (High Availability) e LB (Load Balancing). Lo scopo del cluster è di avere un server, che chiamerò balancer, che effettui lo smistamento del traffico sui due server, che chiamerò relay, in modo da bilanciare il traffico in ingresso sul balancer e distribuirlo sui due relay.
I due relay, ovviamente, devono condividere lo stesso pool di dati in modo da utilizzare gli stessi file sia per la parte web, quindi php nel caso specifico, sia per la parte database, quindi mysql, sia per le email, quindi dovecot e postfix, indifferentemente da dove il balancer decide di inviare la richiesta.
I due relay devono essere quindi sincronizzati tra loro per poter lavorare senza problemi sugli stessi dati. Esistono svariate soluzioni a questo problema, alcune semplici, altre più professionali e quindi più elaborate e complesse.

Cercando con Google però il più delle volte si viene rimandati a guide e tutorial che spiegano come implementare un sistema di HA di tipo fail over. In breve il fail over è come fosse un RAID di livello 1 in cui i dati sono replicati sulle istanze del cluster, e quindi risultano sincronizzati, ma solo un relay può (e deve) essere attivo, gli altri devono essere spenti. Un programma installato sui relay, che si chiama heartbeat, si occupa di capire quando il relay master, o primario, “cade” e si occupa quindi di attivare il relay slave, o secondario, in modo che il cluster possa continuare a servire le richieste. Quando e se il master torna attivo, l’heartbeat se ne accorge, attiva nuovamente il master e spegne lo slave.

Questo sistema è efficiente perchè se il relay master cade (rottura del disco, problema di rete, eccetera) viene attivato lo slave istantaneamente (o quasi, di solito c’è un vuoto di pochissimi secondi, spesso di pochi decimi) e l’utente non si accorge di nulla potendo quindi continuare il proprio lavoro senza interruzioni. Inoltre con questo sistema i dati restano sincronizzati tra i relay e non c’è perdita di informazioni.

Il grosso svantaggio è che almeno uno dei relay rimane in standby, risultando di fatto inutilizzato per la maggior parte del tempo. Un’altra pecca di questo sistema è che non c’è un bilanciamento del carico, una distribuzione del lavoro sui vari relay del cluster. Se un relay può servire, per esempio, 200 clienti, e il cluster è formato da 2 relay, sempre e solo 200 clienti potranno essere serviti.

Una soluzione alternativa e, secondo me, decisamente più efficiente, è l’abbinamento tra un sistema HA e un sistema LB. In questo modo avremo sia l’alta affidabilità data dalla ridondanza dei dati, sia lo sfruttamento totale dei relay del cluster dato dal load balancing. Un sistema così composto, ipotizzando che ogni relay sia in grado di servire 200 clienti e di avere 2 relay, ci permette di servire contemporaneamente 400 clienti. Sarà compito del balancer smistare le richieste su un relay o sull’altro, in base a regole che possiamo stabilire, e i relay, avendo i dati condivisi e sincronizzati, potranno soddisfare in modo identico ogni richiesta.

Questa soluzione è quella che ho scelto per il cliente e che spiegherò in questo tutorial.

Introduzione: Cluster in High Availability e Load Balancing (concetti di base)
Parte uno: Cluster in High Availability e Load Balancing – parte 1 (DRBD)
Parte due: Cluster in High Availability e Load Balancing – parte 2 (ocfs2)
Parte tre: Cluster in High Availability e Load Balancing – parte 3 (cosa e come condividere)