Guide Open Source

GUIDE E MANUALI DEL MONDO LINUX E CMS

Guide Open Source

GUIDE E MANUALI DEL MONDO LINUX E CMS

Guide Open Source

GUIDE E MANUALI DEL MONDO LINUX E CMS

Creazione di un bilanciatore ad alta disponibilità (con Failover e supporto di sessione) con HAProxy/Keepalived su Debian Lenny

Questo articolo spiega come impostare un bilanciamento del carico di due nodi in una configurazione attivo/passivo con HAProxy e keepalived su Debian Lenny. Il bilanciamento del carico si trova tra l’utente e due (o più) backend Apache web server che contengono lo stesso contenuto. Non solo bilanciamento del carico distribuisce le richieste per i due server di backend Apache, inoltre, controlla l’integrità dei server back-end. Se uno di loro è giù, tutte le richieste di essere ridiretti automaticamente al server back-end rimanenti. In aggiunta a ciò, i nodi di bilanciamento del due carico controllano reciprocamente utilizzando keepalived, e se il padrone non riesce, lo schiavo diventa il padrone, che significa che gli utenti non noterà alcuna interruzione del servizio. HAProxy è compatibile con sessione, il che significa che è possibile utilizzarlo con qualsiasi applicazione web che fa uso di sessioni (ad esempio forum, shopping cart, ecc.).

Dal sito web HAProxy: “HAProxy è una soluzione gratuita, molto veloce e affidabile che offre alta disponibilità, bilanciamento del carico e l’inoltro per applicazioni basate su HTTP e TCP. È particolarmente adatto per i siti web strisciando sotto carichi molto alti mentre che necessitano di persistenza o elaborazione Layer7. Supporto di decine di migliaia di connessioni è chiaramente realistico con l’hardware di oggi. Sua modalità di funzionamento rende sua integrazione in architetture esistenti molto facile e privo di rischio, pur offrendo la possibilità di non esporre i fragili web server alla rete.”

Io non rilasciano alcuna garanzia che questo funziona per voi!

 

1 Nota preliminare

In questa esercitazione utilizza i seguenti host:

  • Bilanciamento del carico 1: lb1.example.com, indirizzo IP: 192.168.0.100
  • Bilanciamento del carico 2: lb2.example.com, indirizzo IP: 192.168.0.101
  • Web Server 1: http1.example.com, indirizzo IP: 192.168.0.102
  • Web Server 2: http2.example.com, indirizzo IP: 192.168.0.103
  • Abbiamo anche bisogno di un indirizzo IP virtuale che galleggia tra lb1 e lb2192.168.0.99

Ecco un piccolo diagramma che mostra il nostro programma di installazione:

IP condiviso = 192.168.0.99
192.168.0.100 192.168.0.101 192.168.0.102 192.168.0.103
——-+————+————–+———–+———-
|            |              |           |
+–+–+      +–+–+      +—-+—-+ +—-+—-+
LB1 | | LB2 | | http1 | | http2 |
+—–+      +—–+      +———+ +———+
HAProxy haproxy 2 web server (Apache) 
keepalived keepalived

L’indirizzo IP (virtuale) condiviso non è nessun problema fino a quando sei nella tua LAN dove è possibile assegnare gli indirizzi IP come ti piace. Tuttavia, se si desidera utilizzare il programma di installazione con indirizzi IP pubblici, è necessario trovare un hoster dove è possibile noleggiare due server (nodi di bilanciamento del carico) nella stessa sottorete; è quindi possibile utilizzare un indirizzo IP libero in questa subnet per l’indirizzo IP virtuale.

configurazioni standard di Debian Lenny Apache con il documento radice /var/www (la configurazione di questa impostazione predefinita vhost è memorizzata nel /etc/apache2/sites-available/defaulthttp1 e http2 . Se la radice del documento è diversa, potrebbe essere necessario regolare la guida un po’.

Per dimostrare la sessione-consapevolezza di HAProxy, sto assumendo che l’applicazione web che viene installato su http1 e http2utilizza l’id di sessione JSESSIONID.

 

2 preparazione dei server Web di back-end

Si configurerà come un proxy trasparente, cioè HAProxy, passerà sull’indirizzo IP dell’utente originale in un campo denominato X-Forwarded-For ai server web back-end. Naturalmente, i server web di back-end devono accedere l’indirizzo IP dell’utente originale nei loro registri di accesso anziché gli indirizzi IP dei nostri servizi di bilanciamento del carico. Quindi dobbiamo modificare la riga LogFormat in /etc/apache2/apache2.conf e sostituire %h con % {X-Forwarded-For} io:

http1/http2:

vi /etc/apache2/apache2.conf
[...]
#LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
[...]

Inoltre, si configurerà HAProxy per controllare la salute dei server back-end richiedendo continuamente il file txt (si traduce in /var/www/ www/check.txt se /var/www è la radice del documento) dai server back-end. Naturalmente, queste richieste sarebbero totalmente gonfiare i registri di accesso e rovinare le vostre statistiche di visualizzazione di pagina (se si utilizza uno strumento come Webalizer o AWstats che genera statistiche basate sui registri di accesso).

Quindi apriamo la nostra configurazione vhost (in questo esempio che è in /etc/apache2/sites-available/default) e mettere queste due righe in esso (commento fuori tutte le altre direttive CustomLog nella configurazione vhost):

vi /etc/apache2/sites-available/default
[...]
SetEnvIf Request_URI "^/check\.txt$" dontlog
CustomLog /var/log/apache2/access.log combined env=!dontlog
[...]

Questa configurazione impedisce che le richieste di txt ottenere registrate nel log di accesso di Apache.

In seguito abbiamo riavviare Apache:

/etc/init.d/apache2 restart

… e creare il file txt (questo può essere un file vuoto):

touch /var/www/check.txt

Siamo finiti già con i server back-end; il resto della configurazione accade sui nodi di bilanciamento del due carico.

 

3 installazione HAProxy

LB1/lb2:

Possiamo installare HAProxy come segue:

aptitude install haproxy

 

4 configurazione di bilanciamento del carico

La configurazione di HAProxy è memorizzata in /etc/haproxy/haproxy.cfg ed è abbastanza straight-forward. Non spiegherò tutte le direttive qui; Per ulteriori informazioni su tutte le opzioni, si prega di leggere http://haproxy.1wt.eu/download/1.3/doc/haproxy-en.txt e http://haproxy.1wt.eu/download/1.2/doc/architecture.txt.

We back up the original /etc/haproxy/haproxy.cfg and create a new one like this:

lb1/lb2:

cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg_orig
cat /dev/null > /etc/haproxy/haproxy.cfg
vi /etc/haproxy/haproxy.cfg

global
        log 127.0.0.1   local0
        log 127.0.0.1   local1 notice
        #log loghost    local0 info
        maxconn 4096
        #debug
        #quiet
        user haproxy
        group haproxy

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        retries 3
        redispatch
        maxconn 2000
        contimeout      5000
        clitimeout      50000
        srvtimeout      50000

listen webfarm 192.168.0.99:80
       mode http
       stats enable
       stats auth someuser:somepassword
       balance roundrobin
       cookie JSESSIONID prefix
       option httpclose
       option forwardfor
       option httpchk HEAD /check.txt HTTP/1.0
       server webA 192.168.0.102:80 cookie A check
       server webB 192.168.0.103:80 cookie B check

In seguito, impostiamo ENABLED su 1 in /etc/default/haproxy:

vi /etc/default/haproxy
# Set ENABLED to 1 if you want the init script to start haproxy.
ENABLED=1
# Add extra flags here.
#EXTRAOPTS="-de -m 16"

5 impostazione keepalived

Noi abbiamo appena configurato HAProxy per l’ascolto sulla virtuale indirizzo IP 192.168.0.99, ma qualcuno deve dire lb1 e lb2 che dovrebbero stare ascoltare su quell’indirizzo IP. Questo è fatto da keepalived che installiamo come questo:

LB1/lb2:

aptitude install keepalived

Per consentire HAProxy associare l’indirizzo IP condiviso, aggiungiamo la seguente riga a /etc/sysctl.conf:

vi /etc/sysctl.conf
[...]
net.ipv4.ip_nonlocal_bind=1

… ed eseguire:

sysctl -p

Avanti che dobbiamo configurare keepalived (questo viene fatto attraverso il file di configurazione /etc/keepalived/keepalived.conf). Lb1 voglio di essere il bilanciatore attivo (o master), quindi usiamo questa configurazione su lb1:

LB1:

vi /etc/keepalived/keepalived.conf
vrrp_script chk_haproxy {           # Requires keepalived-1.1.13
        script "killall -0 haproxy"     # cheaper than pidof
        interval 2                      # check every 2 seconds
        weight 2                        # add 2 points of prio if OK
}

vrrp_instance VI_1 {
        interface eth0
        state MASTER
        virtual_router_id 51
        priority 101                    # 101 on master, 100 on backup
        virtual_ipaddress {
            192.168.0.99
        }
        track_script {
            chk_haproxy
        }
}

(È importante che si utilizza priorità 101 in file di cui sopra – questo rende lb1 master!)

Quindi iniziamo keepalived sul lb1:

LB1:

/etc/init.d/keepalived start

Quindi eseguire:

LB1:

ip addr sh eth0

… e si dovrebbe trovare che lb1 ora è in ascolto sull’indirizzo IP condiviso, troppo:

LB1: ~ # ip addr sh eth0
2: eth0: < BROADCAST, MULTICAST, UP, LOWER_UP > mtu 1500 qdisc pfifo_fast stato sconosciuto qlen 1000
link/ether 00: 0C: 29:63:f7:5 c brd ff
inet 192.168.0.100/24 brd 192.168.0.255 ambito globale eth0
inet 192.168.0.99/32 ambito globale eth0
inet6 fe80::20c:29ff:fe63:f75c / 64 scope link
valid_lft forever preferred_lft forever
LB1: ~ #

Ora facciamo quasi lo stesso su lb2Non c’è un piccola, ma importante differenza – usiamo priorità 100 invece priorità 101in /etc/keepalived/keepalived.conf che rende lb2 il passivo (slave o hot standby) bilanciamento del carico:

lb2:

vi /etc/keepalived/keepalived.conf
vrrp_script chk_haproxy {           # Requires keepalived-1.1.13
        script "killall -0 haproxy"     # cheaper than pidof
        interval 2                      # check every 2 seconds
        weight 2                        # add 2 points of prio if OK
}

vrrp_instance VI_1 {
        interface eth0
        state MASTER
        virtual_router_id 51
        priority 100                    # 101 on master, 100 on backup
        virtual_ipaddress {
            192.168.0.99
        }
        track_script {
            chk_haproxy
        }
}

Poi cominciamo a keepalived:

lb2:

/etc/init.d/keepalived start

Come lb2 è il bilanciamento del carico passivo, dovrebbe non essere ascolto sull’indirizzo IP virtuale come lb1 è fino. Possiamo verificare che con:

lb2:

ip addr sh eth0

L’output dovrebbe assomigliare a questo:

lb2:~# ip addr sh eth0
2: eth0: < BROADCAST, MULTICAST, UP, LOWER_UP > mtu 1500 qdisc pfifo_fast stato sconosciuto qlen 1000
link/ether 00: 0c: 29: essere: 7b:3b brd ff
inet 192.168.0.101/24 brd 192.168.0.255 scope global eth0
inet6 fe80::20c:29ff:febe:7b3b / 64 scope link
valid_lft forever preferred_lft forever
LB2: ~ #

 

6 a partire HAProxy

Ora possiamo avviare HAProxy:

LB1/lb2:

/etc/init.d/haproxy start

 

7 test

Il nostro servizio di bilanciamento del carico di elevata disponibilità è ora attivo e funzionante.

È ora possibile fare richieste HTTP per il virtuale indirizzo IP 192.168.0.99 (o per qualsiasi dominio/nome host che sta puntando all’indirizzo IP virtuale), e si dovrebbe ottenere contenuto dai server web back-end.

È possibile testare le funzionalità di alta disponibilità/failover spegnendo un server web di back-end – il bilanciamento del carico deve quindi reindirizzare tutte le richieste al server web back-end rimanenti. In seguito, spegnere il sistema di bilanciamento del carico attivo (lb1) – lb2 dovrebbe assumere immediatamente. È possibile verificare che eseguendo:

lb2:

ip addr sh eth0

Ora si dovrebbe vedere l’indirizzo IP virtuale nell’output su lb2:

lb2:~# ip addr sh eth0
2: eth0: < BROADCAST, MULTICAST, UP, LOWER_UP > mtu 1500 qdisc pfifo_fast stato sconosciuto qlen 1000
link/ether 00: 0c: 29: essere: 7b:3b brd ff
inet 192.168.0.101/24 brd 192.168.0.255 scope global eth0
inet 192.168.0.99/32 ambito globale eth0
inet6 fe80::20c:29ff:febe:7b3b / 64 scope link
valid_lft forever preferred_lft forever
LB2: ~ #

Quando lb1 tornerà, assumerà il ruolo di master nuovamente.

 

8 HAProxy statistiche

Potreste aver notato che abbiamo usato le opzioni attivare statistiche e statistiche auth someuser:somepasswordnella configurazione HAProxy nel capitolo 4. Questo permette di accedere alle statistiche di HAProxy (protetta da password) sotto l’ URL http://192.168.0.99/haproxy?statsQuesto è come appare:

Se non hai bisogno di statistiche, basta commentare o rimuovere le righe di statistiche dalla configurazione HAProxy.

 

  • HAProxy: http://haproxy.1wt.eu
  • Keepalived: http://www.keepalived.org
  • Debian: http://www.debian.org

Piaciuto l'articolo? Condividilo sui social!

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on whatsapp
WhatsApp