Howto HAProxy - les checks

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).