HAProxy - Load Balancing de serveur Web - Partie 1
Alasta 7 Juillet 2013 ha Apache CentOS HA Proxy Linux Load Balancer Open Source Reverse Proxy Round Robin VirtualBox
Description : Voici une aide à la mise en place d'un load balancer Open Source sur un exemple de répartition de charge sur des serveurs Web.
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 :
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)
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
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
Cela se passe comme évoquer dans la partie déroulement.
Deuxième accès
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
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 :
On peut voir que le load balancing est parfait !
Et quand on perd un serveur web !!
Stoppons le serveur apache 2