Configurazione Server · 6 min read · Oct 08, 2025

Il Cluster Web Perfettamente Bilanciato e ad Alta Disponibilità Con 2 Server Che Eseguono Xen Su Ubuntu 8.04 Hardy Heron - Pagina 6

12. Configurazione dei bilanciatori di carico (lb1, lb2)

12.1 Abilitare IPVS sui Bilanciatori di Carico

Prima di tutto dobbiamo abilitare IPVS sui nostri bilanciatori di carico. IPVS (IP Virtual Server) implementa il bilanciamento del carico a livello di trasporto all’interno del kernel Linux, noto come switching di livello 4.

echo ip_vs_dh >> /etc/modules
echo ip_vs_ftp >> /etc/modules
echo ip_vs >> /etc/modules
echo ip_vs_lblc >> /etc/modules
echo ip_vs_lblcr >> /etc/modules
echo ip_vs_lc >> /etc/modules
echo ip_vs_nq >> /etc/modules
echo ip_vs_rr >> /etc/modules
echo ip_vs_sed >> /etc/modules
echo ip_vs_sh >> /etc/modules
echo ip_vs_wlc >> /etc/modules
echo ip_vs_wrr >> /etc/modules

Poi facciamo questo:

modprobe ip_vs_dh
modprobe ip_vs_ftp
modprobe ip_vs
modprobe ip_vs_lblc
modprobe ip_vs_lblcr
modprobe ip_vs_lc
modprobe ip_vs_nq
modprobe ip_vs_rr
modprobe ip_vs_sed
modprobe ip_vs_sh
modprobe ip_vs_wlc
modprobe ip_vs_wrr

12.2 Installare Ultra Monkey (pacchetti) sui Bilanciatori di Carico

Installa Ultra Monkey (pacchetti) sui bilanciatori di carico eseguendo quanto segue:

apt-get install ipvsadm ldirectord heartbeat

12.3 Abilitare l’Inoltro dei Pacchetti sui Bilanciatori di Carico

I bilanciatori di carico devono essere in grado di instradare il traffico verso i nodi Apache. Pertanto, dobbiamo abilitare l’inoltro dei pacchetti sui bilanciatori di carico. Aggiungi le seguenti righe a /etc/sysctl.conf:

vi /etc/sysctl.conf

# Abilita l'inoltro dei pacchetti
net.ipv4.ip_forward = 1

Poi fai questo:

sysctl -p

12.4 Configurare heartbeat e ldirectord

Ora dobbiamo creare tre file di configurazione per heartbeat (fai attenzione agli spazi e alle tabulazioni se modifichi in alcuni editor di testo, ldirectord è molto esigente!) :

su lb1 e lb2

vi /etc/ha.d/ha.cf

logfacility local0
bcast eth0 # Linux
mcast eth0 225.0.0.1 694 1 0
auto_failback on
node lb1.example.com
node lb2.example.com
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster

Importante: Come nomi dei nodi dobbiamo usare l’output di entrambi :

uname -n

vi /etc/ha.d/haresources

lb1.example.com \
 ldirectord::ldirectord.cf \
 LVSSyncDaemonSwap::master \
 IPaddr2::192.168.1.106/24/eth0/192.168.1.255 \
 IPaddr2::192.168.1.107/24/eth0/192.168.1.255

Gli IP 192.168.1.106 e 107 saranno utilizzati in seguito per i siti web (example.com e yoursite.com).

Questo file dovrebbe essere lo stesso su entrambi i nodi, indipendentemente dal fatto che tu inizi a creare il file su lb1 o lb2!

vi /etc/ha.d/authkeys

auth 3 3 md5 somerandomstring

somerandomstring è una password che i due demoni heartbeat su lb1 e lb2 usano per autenticarsi l’uno contro l’altro. Usa la tua stringa qui. Hai la scelta tra tre meccanismi di autenticazione. Io uso md5 poiché credo sia il più sicuro.

/etc/ha.d/authkeys dovrebbe essere leggibile solo da root, quindi facciamo questo:

chmod 600 /etc/ha.d/authkeys

ldirectord è il vero bilanciatore di carico. Configureremo i nostri due bilanciatori di carico (lb1.example.com e lb2.example.com) in una configurazione attiva/passiva, il che significa che abbiamo un bilanciatore di carico attivo e l’altro è un hot-standby e diventa attivo se quello attivo fallisce. Per farlo funzionare, dobbiamo creare il file di configurazione ldirectord /etc/ha.d/ldirectord.cf che deve essere identico su lb1 e lb2.

vi /etc/ha.d/ldirectord.cf

checktimeout=5
checkinterval=5
autoreload=no
logfile="/var/log/ldirectord.log"
quiescent=no
#fork=yes

#PER SMTP
virtual=192.168.1.106:25
        real=192.168.1.104:25 gate
        fallback=192.168.1.105:25 gate
        service=none
        scheduler=wlc
        protocol=tcp
        checktype=connect
virtual=192.168.1.107:25
        real=192.168.1.104:25 gate
        fallback=192.168.1.105:25 gate
        service=none
        scheduler=wlc
        protocol=tcp
        checktype=connect

#PER DNS - CONNECT NON FUNZIONA, DEVE ESSERE PATCHATO MA PING È OK
virtual=192.168.1.106:53
        real=192.168.1.104:53 gate
        fallback=192.168.1.105:53 gate
        service=none
        scheduler=wlc
        checktype=ping
        protocol=udp
virtual=192.168.1.106:53
        real=192.168.1.104:53 gate
        fallback=192.168.1.105:53 gate
        service=dns
        scheduler=wlc
        checktype=ping
        protocol=tcp
#PER HTTP
virtual=192.168.1.106:80
        real=192.168.1.104:80 gate
        real=192.168.1.105:80 gate
        service=http
        request="ldirectord.php"
        receive="Connesso a MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
        persistent=28800
virtual=192.168.1.107:80
        real=192.168.1.104:80 gate
        real=192.168.1.105:80 gate
        service=http
        request="ldirectord.php"
        receive="Connesso a MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
        persistent=28800

#PER WEBMAIL
virtual=192.168.1.106:81
        real=192.168.1.104:81 gate
        fallback=192.168.1.105:81 gate
        service=http
        request="ldirectord.php"
        receive="Connesso a MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
virtual=192.168.1.107:81
        real=192.168.1.104:81 gate
        fallback=192.168.1.105:81 gate
        service=http
        request="ldirectord.php"
        receive="Connesso a MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
#PER POP3
virtual=192.168.1.106:110
        real=192.168.1.104:110 gate
        fallback=192.168.1.105:110 gate
        service=pop
        checktype = connect
        scheduler=wlc
        protocol=tcp
#PER IMAP
virtual=192.168.1.106:143
        real=192.168.1.104:143 gate
        fallback=192.168.1.105:143 gate
        service=imap
        scheduler=wlc
        protocol=tcp
#PER HTTPS
###Decommenta questa parte se utilizzerai HTTPS
#virtual=192.168.1.106:443
#        real=192.168.1.104:443 gate
#        real=192.168.1.105:443 gate 2
#        service=http
#        request="ldirectord.php"
#        receive="Connesso a MySQL"
#        scheduler=wlc
#        protocol=tcp
#        checktype=negotiate
#        persistent=28800
#
#virtual=192.168.1.107:443
#        real=192.168.1.104:443 gate
#        real=192.168.1.105:443 gate 2
#        service=http
#        request="ldirector.html"
#        receive="Pagina di Test"
#        scheduler=wlc
#        protocol=tcp
#        checktype=negotiate
#        persistent=28800
#PER IMAP SSL
virtual=192.168.1.106:993
        real=192.168.1.104:993 gate
        fallback=192.168.1.105:993 gate
        service=imaps
        scheduler=wlc
        protocol=tcp
#PER POP3 SSL
virtual=192.168.1.106:995
        real=192.168.1.104:995 gate
        fallback=192.168.1.105:995 gate
        service=pops
        checktype = ping
        scheduler=wlc
        protocol=tcp
#PER MONIT MONITORING #1
virtual=192.168.1.106:10001
        real=192.168.1.104:10001 gate
        checktype = on
#PER MONIT MONITORING #2
virtual=192.168.1.106:20001
        real=192.168.1.105:20001 gate
        checktype = on

virtual è l’IP virtuale dei servizi (es. 192.168.1.106 e 107)

real sono gli IP dei server reali nel cluster (192.168.1.104 e 105)

fallback è il server di backup. Se l’IP reale fallisce, le richieste vengono inoltrate all’IP di fallback ma non sono bilanciate.

Questa configurazione si basa sulla mia esperienza personale. Alcuni servizi sono bilanciati, altri no. Tutto ciò che riguarda la posta non è bilanciato. Non vuoi che un messaggio arrivi sul primo server e il secondo sull’altro (a meno che tu non abbia uno storage condiviso). Se non hai un traffico di posta molto elevato, non ha senso bilanciare la posta (ma è comunque altamente disponibile), lo stesso vale per DNS. In seguito sincronizzeremo i messaggi sul secondo server in modo da avere un backup nel caso in cui il primo server fallisca.

Riguardo alla porta 81. La utilizzeremo per il webmail. La utilizzo anche per l’amministrazione del nostro sito web di e-commerce a causa del caricamento delle immagini. In seguito configureremo rsync da web1.example.com a web2.example.com ma non viceversa. Fondamentalmente non vuoi caricare un file su web2.example.com (a meno che tu non utilizzi uno storage condiviso).

Se desideri ulteriori informazioni sull’argomento cerca “ldirectord man”.

Successivamente creiamo i collegamenti di avvio del sistema per heartbeat e rimuoviamo quelli di ldirectord perché ldirectord sarà avviato dal demone heartbeat:

update-rc.d -f ldirectord remove

Infine avviamo heartbeat (e con esso ldirectord):

/etc/init.d/ldirectord stop
/etc/init.d/heartbeat start

12.5 Testare i Bilanciatori di Carico

Controlliamo se entrambi i bilanciatori di carico funzionano come previsto:

ip addr sh eth0

Il bilanciatore di carico attivo lb1.example.com dovrebbe elencare gli indirizzi IP virtuali (192.168.1.106 e 192.168.1.107):

2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.102/24 brd 192.168.1.255 scope global eth0
    inet 192.168.1.106/24 brd 192.168.1.255 scope global eth0
    inet 192.168.1.107/24 brd 192.168.1.255 scope global secondary eth0

L’hot-standby (lb2.example.com) dovrebbe mostrare qualcosa di simile:

2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0c:29:34:d7:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.103/24 brd 192.168.1.255 scope global eth0

Ora prova :

ldirectord ldirectord.cf status

Output sul bilanciatore di carico attivo (lb1) :

ldirectord per /etc/ha.d/ldirectord.cf è in esecuzione con pid: 5321

Output sul bilanciatore di carico hot standby (lb2) :

ldirectord è fermo per /etc/ha.d/ldirectord.cf

Ora controlleremo se le porte sono inoltrate correttamente :

ipvsadm -L -n | grep :80

Dovresti vedere qualcosa di simile su lb1.example.com:

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.1.106:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0
TCP  192.168.1.107:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0

E nulla su lb2.example.com.

Un ultimo test :

/etc/ha.d/resource.d/LVSSyncDaemonSwap master status

Output sul bilanciatore di carico attivo:

master in esecuzione (ipvs_syncmaster pid: 5470)

Output sull’hot-standby:

master fermo

12.6 Testare il Failover dei Bilanciatori di Carico

lb1.example.com

/etc/init.d/heartbeat stop

Il comando ipvsadm :

ipvsadm -L -n | grep :80

dovrebbe non restituire nulla.

Su lb2.example.com

ipvsadm -L -n | grep :80

e dovresti vedere quanto segue :

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.1.106:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0
TCP  192.168.1.107:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0

Riavvia il servizio heartbeat su lb1.example.com :

/etc/init.d/heartbeat start

Se riprovi il comando ipvsadm su entrambi vedrai che lb1.example.com è ora attivo mentre lb2.example.com è tornato in standby.

Se il tuo test è andato bene puoi procedere.

Share: X/Twitter LinkedIn
#Configurazione Server

Ricevi i nuovi post nella tua casella di posta.

Nessuno spam. Disiscriviti in qualsiasi momento.