Page spéciale "checks" pour HAProxy

HowtoHAProxy/Checks.md

@@ -0,0 +1,181 @@
+---
+title: Howto HAProxy - les checks
+category: web HA
+---
+
+Cet article se focalise sur la manière dont HAProxy fait ses checks et dont on peut les configurer.
+
+Pour une documentation plus générale, consultez la page [/HowtoHAProxy]().
+
+Liens externes utiles :
+* https://www.haproxy.com/blog/haproxy-configuration-basics-load-balance-your-servers
+* https://www.haproxy.com/blog/the-four-essential-sections-of-an-haproxy-configuration
+* https://www.haproxy.com/documentation/haproxy-configuration-tutorials/service-reliability/health-checks/
+
+## Pas de check
+
+~~~
+backend
+    server srv1 192.0.2.1:80
+    server srv2 192.0.2.2:80
+~~~
+
+Dans cet exemple, les 2 serveurs sont réputés être disponibles en tout temps.
+La répartition des requêtes dépend de l'option `balance`.
+
+## Check actif
+
+Doc : http://docs.haproxy.org/2.6/configuration.html#check
+
+### check simple
+
+~~~
+backend
+    default-server check
+    server srv1 192.0.2.1:80
+    server srv2 192.0.2.2:80
+~~~
+
+Dans cet exemple, un check actif est exécuté à intervale régulier.
+Le check est fait sur la plus haute couche de transport configurée : TCP par défaut, ou SSL/TLS si l'option `ssl` (ou `check-ssl`) est présente.
+
+### check HTTP
+
+Doc : http://docs.haproxy.org/2.6/configuration.html#option%20httpchk
+
+~~~
+backend
+    option httpchk
+    default-server check
+    server srv1 192.0.2.1:80
+    server srv2 192.0.2.2:80
+~~~
+
+Dans cet exemple, le check est fait sur la couche applicative HTTP.
+Le check est une requête `OPTIONS /` sur le port de proxification (ici `80`).
+
+Le check est en succès si la partie transport (connexion TCP et/ou SSL/TLS) **et** la partie applicative (réponse HTTP correcte) est OK.
+
+~~~
+backend
+    option httpchk
+    default-server check port 81
+    server srv1 192.0.2.1:80
+    server srv2 192.0.2.2:80
+~~~
+
+Cet exemple montre comment spécifier un port spécifique (`81`) pour le check.
+
+~~~
+backend
+    option httpchk GET /healthz
+    default-server check
+    server srv1 192.0.2.1:80
+    server srv2 192.0.2.2:80
+~~~
+
+Cet exemple montre comment modifier la requête HTTP envoyée (`GET /healthz`) par le check.
+
+Il existe aussi de nombreuses options pour personnaliser le comportement du check ; status attendu, contenu attendu, mode de connexion…
+
+### Fréquence des checks
+
+Doc : http://docs.haproxy.org/2.6/configuration.html#inter
+
+~~~
+backend
+    option httpchk
+    default-server check inter 1s
+    server srv1 192.0.2.1:80
+    server srv2 192.0.2.2:80
+~~~
+
+Dans cet exemple on voit l'option `inter <delay>` qui permet de personnaliser la fréquence des checks (défaut: `2` secondes).
+
+
+~~~
+backend
+    option httpchk
+    default-server check inter 1s fastinter 500 downinter 1m
+    server srv1 192.0.2.1:80
+    server srv2 192.0.2.2:80
+~~~
+
+Cet exemple montre que le check est exécuté chaque seconde pour un serveur `UP`, mais toutes les 500 millisecondes lorsque l'état est en transition (après un échec quand il est `UP`, ou après un succès quand il est `DOWN`), et toutes les minutes lorsqu'il est `DOWN`.
+
+### Seuils des checks
+
+Doc :
+* http://docs.haproxy.org/2.6/configuration.html#fall
+* http://docs.haproxy.org/2.6/configuration.html#rise
+
+~~~
+backend
+    option httpchk
+    default-server check fall 5 rise 10
+    server srv1 192.0.2.1:80
+    server srv2 192.0.2.2:80
+~~~
+
+Cet exemple montre comment personnaliser le nombre d'échecs consécutifs (`fall 5`) avant de passer en statut `DOWN` (défaut: `3`), et le nombre de succès (`rise 10`) avant de passer en statut `UP` (défaut: `2`).
+
+### Timeouts
+
+Doc : http://docs.haproxy.org/2.6/configuration.html#timeout%20check
+
+Pour les checks actifs, le timeout par défaut est la valeur minimale entre la fréquence du check (`inter`) et le délai de connextion (`timeout connect`). Cela permet de ne pas avoir plusieurs checks identiques en cours en même temps.
+
+~~~
+backend
+    option httpchk
+    timeout check 100
+    default-server check inter 1000
+    server srv1 192.0.2.1:80
+    server srv2 192.0.2.2:80
+~~~
+
+Cet exemple montre comment personnaliser le timeout du check à `100 millisecondes` tout en conservant une fréquence de check à `1 seconde`.
+
+
+### Checks "agent"
+
+Doc : http://docs.haproxy.org/2.6/configuration.html#agent-check
+
+Il est possible d'utiliser des checks actifs plus avancés, appelés `agent-check`.
+Les capacités de personnalisation sont similaires.
+
+La différence est surtout dans le fait qu'on interroge un agent spécifique sur les serveurs distants (et pas l'application proxifiée elle-même) et qu'on s'attend à une information à la fois simple (pas de HTTP) et plus riche (possibilité d'instruire HAProxy sur des états plus riches : statut, poids…).
+
+## Checks passifs
+
+En plus des checks actifs, il est possible de surveiller le flux de données de manière passive, grace à l'utilisation de la directive `observe`.
+
+Doc :
+* http://docs.haproxy.org/2.6/configuration.html#observe
+* http://docs.haproxy.org/2.6/configuration.html#on-error
+
+### observe layer4
+
+~~~
+backend
+    default-server check observe layer4 inter 1m
+    server srv1 192.0.2.1:80
+    server srv2 192.0.2.2:80
+~~~
+
+Cet exemple montre comment activer la surveillance passive au niveau de la couche transport.
+Ici, la fréquence des checks actifs est réglée à 1 minute (indépendamment de l'intensité du trafic réel), mais si des erreurs de connexion constatées sur le trafic géré, alors on va passer un serveur `DOWN` plus rapidement qu'avec les checks actifs.
+
+L'option `on-error` permet de définir le comportement lorsqu'une telle erreur est détectée. Par défaut c'est `on error fail-check` qui est équivalent à un échec de check actif (et provoque donc le passage en mode `fastinter`).
+
+### observe layer7
+
+~~~
+backend
+    option httpchk
+    default-server check observe layer7 inter 1m
+    server srv1 192.0.2.1:80
+    server srv2 192.0.2.2:80
+~~~
+
+Cet exemple est quasi identique au précédent, sauf que la surveillance passive du trafic se fait au niveau de la couche applicative (HTTP ici), en plus de la couche transport. Des entêtes imparsables, ou un code HTTP (autre que `100` à `499`, `501` ou `505`).

HowtoHaproxy.md

@@ -46,7 +46,7 @@ local5.*  -/var/log/haproxy.log
 ~~~
 
 
-### Checker la configuration
+### Vérifier la validité de la configuration
 
 On vérifie qu'il n'y a pas d'erreur de syntaxes :
 
@@ -429,7 +429,11 @@ frontend foo
     bind […] accept-proxy
 ~~~
 
-## Check HTTP
+### Checks
+
+Un article dédié au [fonctionnement des checks HAProxy](/HowtoHAProxy/Checks) est disponible.
+
+#### HTTP
 
 Cela consiste à utiliser un check http pour déterminer l'état du serveur.
 
@@ -510,7 +514,7 @@ On redémarre xinetd (surveiller `/var/log/syslog` pour d'éventuelles erreurs)
 
 Il est également possible d'utiliser tout programme ou script, pourvu qu'au final il puisse être accessible en HTTP.
 
-## Ajustement dynamique
+### Ajustement dynamique
 
 Le propos est d'utiliser l'option `agent-check` pour pouvoir ajuster dynamiquement le poids ou les états des membres d'un backend.
 
@@ -599,7 +603,7 @@ C'est pourquoi il peut être important de combiner plusieurs mots clés dans le
 
 On notera que seuls les algorithmes d'équilibrage dynamiques (roundrobin et leastconn) permettront l'ajustement du poids via `agent-check`. Dans le cas de l'utilisation d'un algorithme statique comme `source` par exemple, seules des opérations telles que le passage en DRAIN, DOWN, MAINT et UP seront possibles. 
 
-### Agent-check sur la surveillance de l'espace disque
+#### Agent-check sur la surveillance de l'espace disque
 
 On peut faire un agent check avec xinetd comme vu plus haut et le script `diskchk.sh` qui permet de surveiller l'espace disque, exemple avec la partition `/var` :