Lors de la mise en place d'un haproxy, le check des backend évite d'envoyer vers un backend non disponible.
Il existe plusieurs types de check (cf la documentation, mais nous allons en regarder quelques un de simple et efficaces.
httpchk
Le check http basique :
option httpchk OPTIONS / HTTP/1.0
http-check expect rstatus (2|3)[0-9][0-9]
default-server inter 3s fall 3 rise 2
server selphie 172.27.236.2:80 maxconn 32 check
le check à la fin de la directive server indique que le contrôle doit être fait, la ou httpchk et http-check expect précisent comment faire.
Ce contrôle repose sur la réponse à la directive OPTIONS du serveur web. il faut donc la mettre en place sur votre apache ou nginx
exemple sur nginx :
location / {
if ($request_method = OPTIONS ) {
add_header Content-Length 0;
add_header Content-Type text/plain;
return 200;
}
}
Il est aussi possible de faire un test sur la réponse d'une page, mais la encore, le plus complet reste la documentation officielle.
tcp check
Le tcp-check permet de simplement vérifier que le port est ouvert. Il est utile pour apache si on se moque de vérifier un état précis du serveur, mais surtout pour les autres services que nous voudrions proxiser avec haproxy (car ou, haproxy peut servir de frontal haute disponibilité à tout service tcp, dont ldap, pop, imap, rdp ...)
option tcp-check
option forwardfor except 127.0.0.1
http-request add-header X-Forwarded-Proto https if { ssl_fc }
http-request replace-header X-Location-Path /cluster /
server web1 10.40.0.6 weight 100 check port 80
server web2 10.40.0.8 weight 100 check port 80
ici c'est l'ajout de check qui précise qu'il doit y avoir contrôle, et port XX quel port contrôler par une connexion tcp.
Nous pouvons aussi faire en sorte que dans un cas multi-servers en backend, nous renvoyons un utilisateur toujours vers le même serveur. Pour cela, nous rajoutons dans le backend, les directives :
stick-table type ip size 200k expire 30m stick on src