Contexte :

Nous allons voir la mise en place d'un load balancer HAProxy (dans notre exemple, celui-ci ne sera pas doublé) avec différents algorithmes de répartition de charge. L'architecture est basée sur de la CentOS 6.4.

Prérequis :

- 1 serveur Linux sur lequel installer HAProxy
- 3 serveurs Linux avec un serveur Web d'installé (dans cet exemple se sont 3 Apache) et fonctionnels
- 1 poste pour faire les tests
Note : Personnellement j'ai fait les tests avec des machines virtuelles via VirtualBOX.

Schéma d'architecture :

schema_haproxy_archi

Installation des composants :

Serveurs Web

Nous ne verrons pas l'installation des serveurs Web ici.
Pour faciliter la compréhension et la visibilité des exemples de répartition de charge, j'ai créé pour chaque serveurs Web les images suivantes :
- image1 serverX
- image2 serverX
- image3 serverX
- image4 serverX

X représente le numéro du serveur.

Ainsi qu'une page HTML basique (index.html) :

<html>
 <head>
 <meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
 <meta http-equiv="Pragma" content="no-cache" />
 <meta http-equiv="Expires" content="0" />
 <title>Page de Tests LB</title>
 </head>
 <body>
 Page du serveur X
 <img src="image1.png">
 <img src="image2.png">
 <img src="image3.png">
 <img src="image4.png">
 </body>
 </html>

Pour chaque serveur Web la page doit ressembler à cela (perso j'ai mis des couleurs différentes pour chaque serveur)
Capture d’écran 2013-07-07 à 15.34.28

Le load balancer

Installation d'HAProxy

yum -y install haproxy

Démarrage du service

service haproxy start

Pour qu'HAProxy se lance à chaque démarrage de la machine

chkconfig --level 2345 haproxy on

Configuration d'une VIP avec une répartition en Round Robin

Définition :

La méthode Round-robin est une répartition équitable de la charge entre les serveurs d'une ferme (cluster, pool, ... terminologie qui dépends du développeur de la solution). Chaque serveur traite le même nombre de requêtes, mais cela nécessite d'avoir des serveurs homogènes en terme de capacité de traitement.

Schéma

schema_haproxy_roundrobin

Déroulement

Suivant la page web que nous avons mis en place, nous allons chercher séquentiellement :
index.html sur Apache1/server1
image1.png sur Apache2/server2
image2.png sur Apache3/server3
image3.png sur Apache1/server1
image4.png sur Apache2/server2

Configuration sur le serveur HAProxy

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
        option redispatch
        maxconn 2000
        contimeout      5000
        clitimeout      50000
        srvtimeout      50000

listen VIP_Web 192.168.5.17:80         //Declaration des l adresse de Haut Dispo et port
       mode http
       stats enable
       stats       uri /stats         // URI où les stats seront consultables
       stats auth  pseudo:password    // votre username : password
       balance roundrobin             // Methode de load balancing
       option httpclose
       option forwardfor
       server apache1 10.0.0.1:80 check  // Declaration des serveurs
       server apache2 10.0.0.2:80 check  // syntax : server:
       server apache3 10.0.0.3:80 check

On redémarre HAProxy

service haproxy restart

Tests des accès

Service derrière la VIP
http://192.168.5.17

Premier accès
Capture d’écran 2013-07-07 à 16.24.17
Cela se passe comme évoquer dans la partie déroulement.

Deuxième accès
Capture d’écran 2013-07-07 à 16.21.17
On voit bien la page et les images changer, le load balancing s'effectue correctement.

Statistiques du load balancer
http://192.168.5.17/stats
Capture d’écran 2013-07-07 à 22.02.34
Pour VIP_web (le screenshots représente le premier accès), on voit bien les 5 requêtes réparties (dans la colonnes Session, LbTot ou Total).
Quelques informations :
Session Rate : c'est le nombre de nouvelles sessions par seconde
Cur : nombre de nouvelles sessions par seconde en cours
Max : le plus grand nombre de nouvelles sessions par seconde vu depuis le démarrage du service

Sessions : le nombre de sessions en cours
Cur : nombre de session en cours
Max : nombre de session max vu depuis le démarrage du service

LastChk : indique le type et l'état de check/health check (verification de vie du serveur) et le temps pris
L4 : check de niveau 4 (du modèle OSI), c'est une connexion à un socket (IP et port)
L7 : check de niveau 7, par exemple on vérifie la présence d'une page web

Bonus

Accessoirement on peut générer un volume important de requêtes pour voir que le load balancing s'effectue correctement.
Sur le poste qui fait les tests ou un autre serveur possédant ab (Apache Bench : fournit avec le package httpd).
Lancer la commande suivante :

ab -n 70000 -c 400 192.168.5.17/

-n : nombre de requêtes à envoyer
-c : nombre de requêtes concurrentes
Ne pas oublier le / à la fin de l'IP ou fqdn

Voila le résultat après avoir lancer deux fois la commande ab :
Capture d’écran 2013-07-07 à 22.15.56
On peut voir que le load balancing est parfait !

Et quand on perd un serveur web !!

Stoppons le serveur apache 2

Le load balancer voit bien la perte du serveur 2 :
Capture d’écran 2013-07-07 à 22.37.46

La page web :
Capture d’écran 2013-07-07 à 22.39.08

Et quand on remet le serveur 2 actif :
Capture d’écran 2013-07-07 à 22.40.30