HAPROXY

1. Préparation de la plate-forme

Ouvrir VirtualBox et créer 3 machines virtuelles avec le système d’exploitation Débian.

Les machines auront respectivement les noms HAPROXYNL, servWeb1 et servWeb2.

Pour ce qui est des configurations des machines, il faut procéder par étape :

- Pour HAPROXYNL : On a besoin de 2 cartes réseau, la première en accès par pont et la

deuxième en accès privé hôte.

La première carte réseau doit être configurée en : 172.16.38.10 255.255.0.0 172.16.0.1 dns :

172.16.224.10 domaine : bts-sio.ozenne.fr

La seconde carte réseau en : 192.168.38.10 255.255.255.0

- Pour servWeb1 : La seule carte réseau doit être configurée en 192.168.38.20

255.255.255.0

- Pour servWeb2 : La carte réseau doit avoir pour configuration 192.168.38.30 255.255.255.0

Une fois les configurations réalisées, il faut tester si cela fonctionne correctement en effectuant des

ping entre les machines.

Ensuite sur la machine HAPROXYNL nous avons besoin d’installer le paquet haproxy avec la

commande apt-get install haproxy. La création du paquet créer automatiquement un dossier

« haproxy » dans /etc et nous devons renommer le fichier haproxy.cfg en haproxy.exemple qui se

trouve à l’intérieur du dossier.

Pour différencier les deux serveurs web, sur chacun d’eux nous modifions le fichier index.htm en y

ajoutant un indicateur tel que : It Works servWebX (X étant 1 ou 2 suivant le serveur).

Pour vérifier le bon fonctionnement des serveurs http, il faut depuis HAPROXYNL taper dans l’URL les

adresses IP des serveurs web.

2. Configuration initiale de HAPROXY

Le fichier de configuration du répartiteur de charge se trouve dans /etc/haproxy/haproxy.cfg.

La première version proposée pour ce fichier est :

Listen : Permet de demander à HAPROXY d'écouter l'IP et le port indiqué.

Mode : Permet de spécifier que l'on va travailler sur des flux http

HAPROXY fera une analyse détaillé des requêtes clients avant de les faire suivre aux "frontaux". Ce

mode permettra ultérieurement de faire du filtrage de niveau 7. Les autres modes possibles sont tcp

ou health.

Balance : Permet de choisir l'algorithme de répartition vers les frontaux.

Roundrobin : Il est le plus classique et le plus simple ; il consiste à utiliser les serveurs un à

un, chacun son tour.

Option httpclose : Force à fermer la connexion http une fois la requête envoyée au client. On

évite ainsi de conserver la connexion HTTP ouverte et donc de renvoyer systématiquement cette

dernière vers le même frontal tant que la connexion reste ouverte.

Option httpchk : Suivie d'une requête HTTP, permet de vérifier qu'un frontal web est

toujours en vie.

Server : Déclare un serveur frontal, utilisé pour assurer le service. Chaque serveur est nommé

et suivi de son IP/port de connexion.

Pour vérifier si la syntaxe d'un fichier de configuration est correcte, il suffit de taper la commande :

haproxy -c -f /etc/haproxy/haproxy.cfg

Le message suivant doit s'afficher :

Ce message indique que le fichier de configuration est valide mais un avertissement signale que ce

fichier est un bâclé : aucun timeout n'est précisé, ce qui peut poser un problème.

A présent, s'il on fait /etc/init.d/haproxy restart, voici ce qu'il en résulte :

On constate que le démon ne réagi pas.

En réalité c'est parce que nous n’avons pas fini de configurer HAPROXY, si l'on se rend dans le fichier

/etc/default/haproxy on voit que la variable enable est initialisée par défaut à "0". Il faut donc

remplacer cette valeur par un "1".

Une fois la modification apportée, nous allons réessayer le redémarrage du service :

Cette fois ci le démon démarre mais avec un message d'avertissement qui signifie qu'il y a une

absence de timeout dans le fichier de configuration haproxy.cfg.

Pour supprimer les avertissements au démarrage, il suffit de rajouter les options proposées par

défaut dans le fichier de configuration /etc/haproxy/haproxy.cfg :

Nous pouvons maintenant redémarrer le service HAPROXY :

Le démarrage se fait normalement.

A noter que les warning n'empêchent pas le démarrage du service "à la main", mais empêchent le

démon de démarrer lors du boot de la machine ce qui peut être embêtant..

Nous allons vérifier si le service fonctionne bien et écoute sur le port 80 avec la commande netstat –

tpnl :

Tout ce passe correctement, alors nous allons faire deux essais successifs depuis une machine

cliente.

Pour ce faire, nous devons ouvrir un navigateur depuis la machine cliente et taper l'adresse IP du

répartiteur (172.16.38.10).

On constate que le répartiteur bascule sur les deux serveurs successivement, cela prouve le bon

fonctionnement du service.

3. Configuration avancée de HAPROXY : surveillance du "Cluster".

Il faut savoir que HAPROXY dispose de sa propre interface de statistiques et de surveillance. Nous

allons donc mettre cette fonctionnalité en place.

Tout d'abord nous allons sauvegarder notre première configuration en copiant puis renommant le

fichier /etc/haproxy/haproxy.cfg en haprox.cfg1, puis en modifiant le fichier haproxy.cfg de cette

façon :

Frontend : Décrit la partie publique, vue par les internautes, autrement dit le port d'écoute

et le backend associé à ce port d'écoute, qui gèrera les connexions sur ce port et qu'on défini dans le

bloc suivant.

Backend : Est le moteur de la bête, le cluster web à proprement parlé.

Stats uri : Permet d'activer la page statistique, en définissant l'endroit où celles-ci pourront

êtres consultées.

Stats auth : Permet de sécuriser l'accès en le protégeant par un nom d'utilisateur et un mot

de passe séparés par " : ".

Ce qui donnera :

Après avoir modifié le fichier de configuration, on vérifie s’il est correct par la commande haproxy -c-f

/etc/haproxy/haproxy.cfg.

Puis on test l'accès aux statistiques depuis la machine client en tapant l'url :

http://172.16.38.10/stats.

Pour pouvoir effectuer des tests nous allons faire "tomber" un des deux serveurs avec la commande

service apache2 stop, et en revérifier les statiques comme précédemment. Puis on rallume le service

apache service apache2 start et on revérifie les statistiques.

4. Configuration avancée de HAPROXY : répartition inégalitaire

sur serveurs hétérogènes.

La situation suivante est dans le cas où nous avons un serveur plus puissant qu'un autre et dans ce

cas nous souhaitons que HAPROXY réparti la charge sur les serveurs en fonction de leur puissance.

Tout d'abord nous allons sauvegarder notre configuration en copiant puis renommant le fichier

/etc/haproxy/haproxy.cfg en haprox.cfg2, puis en modifiant le fichier haproxy.cfg de cette façon :

Weight : Permet d'affecter au serveur une valeur de pondération (reflet de sa puissance).

Puis nous vérifions s'il la syntaxe est correcte : haproxy -c -f /etc/haproxy/haproxy.cfg.

Et nous rechargeons le fichier de configuration : /etc/init.d/haproxy reload

Dans l'exemple ci-dessus, nous avons supposé que le serveur web 1 est plus puissant que l'autre.

Pour vérifier si l'application de la nouvelle répartition de charge est correcte nous chargeons la page

web à partir d'une machine cliente. On appuie sur F5 pour actualiser successivement et on constate

que le serveur web 1 est davantage sollicité par le répartiteur.

5. Configuration avancée de HAPROXY : la problématique des sessions.

A des fins de tests, sur chaque serveur Web, il faut modifier la page index.html et ajouter une

deuxième page html (achat.html), accessible depuis la page d'accueil (index.html), censée permettre

d'effectuer des achats en ligne.

Index.html :

Achat.html :

Avec les configurations actuelles, si un utilisateur se connecte sur la page index.html il sera redirigé

sur le serveur Web 1, et s’il clique sur "ici" il accèdera sur la page achat.html toujours sur le serveur

Web 1, mais s’il clique sur "ici" pour retourner sur la page d'accueil on constate que HAPROXY

l'envoie sur le serveur Web 2.

Ce changement de serveur pour une même session utilisateur peut poser quelques problèmes.

Donc il faudrait que HAPROXY puisse effectuer une répartition de charge sur les différents frontaux,

mais qu'un même utilisateur soit toujours redirigé vers le même frontal, afin de gérer correctement

sa session, et donc le cas échéant son authentification.

Pour faire cela, HAPROXY permet de mémoriser le serveur sur lequel est le client et communiquer

cette information à chaque nouvelle requête. Cela s'appelle un cookie.

Nous allons donc sauvegarder notre configuration en copiant puis renommant le fichier

/etc/haproxy/haproxy.cfg en haprox.cfg3, puis en modifiant le fichier haproxy.cfg de cette façon :

A la première connexion de l'utilisateur sur le site, HAPROXY va déterminer, selon l'algorithme

sélectionné dans la configuration (ici roundrobin), vers quel serveur Web le rediriger.

Quand HAPROXY récupère auprès du serveur Web la copie de la page demandée par l'utilisateur, il la

renvoie en y insérant un cookie COOKIEHAPROXY valant W1 ou W2 selon le serveur web utilisé.

Ainsi, à la prochaine requête de notre utilisateur, son navigateur renverra également ce cookie avec

la requête.

HAPROXY, en fonction de la valeur, saura déterminer vers quel frontal renvoyer l'utilisateur. Ainsi,

plus de problème de session.