Le Management :

Description

C'est un bien grand mot pour indiquer comment mettre des serveurs backend en backup, maintenance via le fichier de configuration et le pseudo cli.

Configuration

Serveur en Backup

haproxy.cfg

Il suffit d'ajouter backup à la ligne "server ...."

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
        stats socket /var/run/haproxy.stat level admin

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

listen IP_stats 192.168.5.17:80
       stats enable
        stats       uri /stats // Endroit où les stats seront consultables
        stats auth  pseudo:password // votre username : password

frontend ft_www
        bind  192.168.5.18:80
        mode http
        log global
        option httplog
        maxconn 4000
        default_backend bk_apache

backend bk_apache
        balance static-rr
        mode http
        server apache1 10.0.0.1:80 check
        server apache2 10.0.0.2:80 check backup
        server apache3 10.0.0.3:80 check backup

Page Web

Page de statistiques

Comme précédemment on voit bien que toutes les requêtes sont envoyées sur apache1 et les 2 autres serveurs en backup.

Simulation de panne de apache1

Faisons tomber apache1 :

service httpd stop

Les stats nous indiquent bien qu'apache1 est down mais à par les nombres de sessions, visuellement on voit pas trop qu'apache2 à prit le relais.
Autre point indiqué dans la documentation officiel, il n'y a qu'un backup qui prend le relais en cas de perte de TOUS les serveurs normaux.
Pour avoir plusieurs serveurs backups actif, il faut ajouter option allbackups dans la section backend.
Il est peut être intéressant d'avoir un serveur de backup pour distribuer une page d'indisponibilité, dans ce cas ne pas mettre de cookie (voir article persistance).

Serveur en Disabled

haproxy.cfg

Il suffit d'ajouter disabled à la ligne "server ...."
Je focalise sur la partie du fichier qui nous intérésse.

backend bk_apache
        balance static-rr
        mode http
        option allbackups
        server apache1 10.0.0.1:80 check
        server apache2 10.0.0.2:80 check
        server apache3 10.0.0.3:80 check disabled

Cela aura pour effet de mettre le serveur MAINT pour maintenance.

Page de Statistiques

C'est bien beau de mettre un serveur en maintenance, mais un load balancer en production c'est pas génial de faire des redémarrages de service !
Pour palier à cela il y a un pseudo cli, pourquoi pseudo, parce qu'il a le mérite d'exister mais pas assez de fonctionnalités hélàs.

CLI

Sur ma configuration j'ai du installer socat :

yum install socat

Il faut avoir la ligne suivante dans la section global :

stats socket /var/run/haproxy.stat level admin

L'interface

root@haproxy ~ # socat stdio /var/run/haproxy.stat
prompt

> ?
Unknown command. Please enter one of the following commands only :
  clear counters : clear max statistics counters (add 'all' for all counters)
  help           : this message
  prompt         : toggle interactive mode with prompt
  quit           : disconnect
  show info      : report information about the running process
  show stat      : report counters for each proxy and server
  show errors    : report last request and response errors for each proxy
  show sess [id] : report the list of current sessions or dump this session
  get weight     : report a server's current weight
  set weight     : change a server's weight
  set timeout    : change a timeout setting
  disable server : set a server in maintenance mode
  enable server  : re-enable a server that was previously in maintenance mode

Sur ma configuration après quelques secondes (genre le temps de voir la syntax d'une commande), le shell m'éjecte ...

Partons de l'exemple précédent, à savoir apache3 en maintenance, nous allons le réactiver sans redémarrage du service haproxy :

root@haproxy ~ # socat readline /var/run/haproxy.stat
prompt

> enable server bk_apache/apache3

Note :
Les actions en CLI ne survivent pas au redémarrage de service !

Comme on le voit au dessus, il y a d'autres actions comme affichage des erreurs, stats, session, poids d'un serveur backend (on le verra plus tard), modifier le poids d'un serveur à la volée.
Attention certaines actions ne peuvent pas être appliquées avec certaines méthode de load balancong (ex : modif de poids sur un algo static-rr).

Il est possible de le faire via la commande echo :

# echo "show stat" | socat stdio /var/run/haproxy.stat
 pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,dreq,dresp,ereq,econ,eresp,wretr,wredis,status,weight,act,bck,chkfail,chkdown,lastchg,downtime,qlimit,pid,iid,sid,throttle,lbtot,tracked,type,rate,rate_lim,rate_max,check_status,check_code,check_duration,hrsp_1xx,hrsp_2xx,hrsp_3xx,hrsp_4xx,hrsp_5xx,hrsp_other,hanafail,req_rate,req_rate_max,req_tot,cli_abrt,srv_abrt,
IP_stats,FRONTEND,,,0,0,2000,0,0,0,0,0,0,,,,,OPEN,,,,,,,,,1,1,0,,,,0,0,0,0,,,,0,0,0,0,0,0,,0,0,0,,,
IP_stats,BACKEND,0,0,0,0,2000,0,0,0,0,0,,0,0,0,0,UP,0,0,0,,0,114,0,,1,1,0,,0,,1,0,,0,,,,0,0,0,0,0,0,,,,,0,0,
ft_www,FRONTEND,,,0,0,4000,0,0,0,0,0,0,,,,,OPEN,,,,,,,,,1,2,0,,,,0,0,0,0,,,,0,0,0,0,0,0,,0,0,0,,,
bk_apache,apache1,0,0,0,0,,0,0,0,,0,,0,0,0,0,UP,1,1,0,0,0,114,0,,1,3,1,,0,,2,0,,0,L4OK,,0,0,0,0,0,0,0,0,,,,0,0,
bk_apache,apache2,0,0,0,0,,0,0,0,,0,,0,0,0,0,UP,2,1,0,0,0,114,0,,1,3,2,,0,,2,0,,0,L4OK,,0,0,0,0,0,0,0,0,,,,0,0,
bk_apache,apache3,0,0,0,0,,0,0,0,,0,,0,0,0,0,UP,3,1,0,0,0,114,0,,1,3,3,,0,,2,0,,0,L4OK,,0,0,0,0,0,0,0,0,,,,0,0,
bk_apache,BACKEND,0,0,0,0,0,0,0,0,0,0,,0,0,0,0,UP,6,3,0,,0,114,0,,1,3,0,,0,,1,0,,0,,,,0,0,0,0,0,0,,,,,0,0,

Le poids des serveurs

Dans une ferme de serveurs il n'est pas rare d'avoir des serveurs avec des capacités de traitements différents, pour cela il faut mettre des poids (weight) différents aux serveurs.
Il faut pour cela "connaître" ou avoir une idée des performances des serveurs.
Pour simplifier l'explication on va schématiser (un peu à l'extrème) ainsi :
- apache1 a 1 processeur
- apache2 a 2 processeurs
- apache3 a 3 processeurs
Ce qui va avoir pour effet d'envoyer 1 requête à apache1, 2 à apache2 et 3 à apache3.

Dans la section backend de haproxy.cfg :

backend bk_apache
        balance roundrobin
        mode http
        server apache1 10.0.0.1:80 check weight 1
        server apache2 10.0.0.2:80 check weight 2
        server apache3 10.0.0.3:80 check weight 3

On voit bien la répartition entre les différents serveurs backend.