Ha Proxy est, comme son nom l’indique, un serveur mandataire (ou proxy) de haute disponibilité. Il permet d’apporter une répartition de charge (ou load-balancing) et / ou une tolérance de panne (ou fail-safe) entrante vers tout serveur TCP, avec quelques bénéfices supplémentaires en HTTP. Nous allons voir comment mettre en place ce type de solution.
Le présent article traite d’HA Proxy 1.4.18 sur Ubuntu 13.04. Les directives sont susceptibles de changer si vous utilisez des versions différentes des applications.
Mise en place du répartiteur
Après avoir suivi les instructions de l’Architecture commune en ayant nommé la machine ha-proxy, j’installe HA Proxy avec apt-get install haproxy. La configuration par défaut ne donnera pas grand chose. Il s’agit d’un fichier d’exemple. De plus, le service est désactivé par défaut, et il faudra éditer /etc/defaults/haproxy pour qu’il puisse se lancer.
Interface de gestion
Je commence par activer l’interface de gestion du répartiteur de charge. Elle permet de vérifier et d’aider à affiner la configuration. Dans le futur elle permettra aussi de la surveiller.
Je crée donc une configuration minimale avec un seul serveur (qui n’existe pas pour le moment) :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
global daemon maxconn 256 user haproxy group haproxy defaults mode http timeout connect 5000ms timeout client 50000ms timeout server 50000ms stats enable listen http-in bind *:80 server dummy 127.0.0.1:80 |
Je redémarre HA Proxy avec service haproxy restart. Je dois pouvoir y accéder par http://192.168.1.203/haproxy?stats (C’est l’URL par défaut, mais elle est personnalisable).
Mise en place d’une grappe
Si j’ai suivi les instructions de l’Architecture commune en ayant nommé les machines apache-w1 et apache-w2, je n’ai rien de plus à faire.
De retour sur le répartiteur de charge (ha-proxy), nous allons définir un frontend comme point d’entrée, et un ou plusieurs backends ou grappe de serveurs :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
global daemon maxconn 256 user haproxy group haproxy defaults mode http timeout connect 5000ms timeout client 50000ms timeout server 50000ms stats enable frontend incomming #1 bind *:80 acl isCluster1 path_beg /c1 #2 use_backend cluster1 if isCluster1 #3 default_backend cluster1 #4 backend cluster1 :80 #5 server apache-w1 apache-w1:80 check #6 server apache-w2 apache-w2:80 check |
Explications :
- Nous définissons un frontend que nous nommerons incomming. Il écoutera le port 80 de toutes les interfaces réseau.
- Nous définissons une variable isCluster1 qui vaudra TRUE si le chemin demandé par le client commence par /c1.
- Notre frontend répartira les requêtes entrantes sur la grappe cluster1 si la variable isCluster1 vaut TRUE.
- Notre frontend répartira les requêtes entrantes sur la grappe cluster1 par défaut, si aucune condition citée avant n’a été validée.
- Nous définissons un backend que nous nommerons cluster1.
- Nous définissons un serveur que nous nommerons apache-w1 et dont l’adresse est apache-w1:80. L’état de ce serveur sera régulièrement vérifié grâce à la directive check.
Je recharge ou redémarre HA Proxy avec service haproxy reload ou restart, et je teste sa présence en retournant sur l’interface : http://192.168.1.203/haproxy?stats.
Ensuite on teste le répartiteur en conditions réelles en appelant l’URL balancée http://192.168.1.203/c1 et on vérifie que l’hôte change bien un appel sur deux.
C’est à vous ! Créez deux nouvelles machines virtuelles (apache-w3 et apache-w4); définissez une seconde grappe de serveurs (cluster2) joignable sur l’URL /c2 sur le répartiteur, et admirez sa capacité de multi répartition !
Pour aller un peu plus loin
Les grappes que nous avons configuré ci-dessus utilisent les paramètres par défaut. La répartition de charge se fera équitablement sur chaque serveur membre de la grappe par nombre de requête. HA Proxy ne cherchera pas particulièrement à associer chaque client à un serveur donné.
HA Proxy est capable de vérifier l’état de nombreux protocoles, de répartir la charge de n’importe quel protocole TCP (en ayant certains avantages supplémentaires en HTTP) en suivant un grand nombre d’algorithmes de répartition de charge.
Retours vers Haute disponibilité.