IP Source

Nous avons déjà vu cette persistance dans l'article Load Balancing de serveur Web avec HAProxy – Partie 2.

Dans le même genre il y a l'algorithme de load balancing url_param qui fait indirectement de la persistence.

Cookie

Edition la partie backend de /etc.haproxy/haproxy.conf :

backend bk_apache
        balance roundrobin
        mode http
        cookie SERVERID insert indirect nocache
        server apache1 10.0.0.1:80 check cookie srv1
        server apache2 10.0.0.2:80 check cookie srv2
        server apache3 10.0.0.3:80 check cookie srv3

Ici on insert un cookie qui s’appellera SERVERID.
insert et indirect font que le cookie est entre le client et le load balancer, le cookie n'est jamais transmis au serveur vu qu'il n'en a pas connaissance et ne pourrait pas le comprendre.
nocache permet de s'assurer qu'un cache en amont ne le stockera pas.

Comportement du load balancer :
A la première connexion, HAProxy va voir qu'il n'y a pas encore de cookie, il load balancera la connexion en fonction de l'algorithme définit (ici round robin), il répondra au client en mettant un header Set-Cookie: SERVERID=s1.
A la connexion suivante le client renverra une requête avec le header Cookie: SERVERID=srv1, HAProxy saura alors vers quel serveur il devra envoyer la connexion.
Attention : le client doit accepter les cookies, dans le cas contraire il sera tout le temps répartie sur les serveurs de backend !

Résultat de la page web :

Il est ou le cookie :

On voit bien qu'on est envoyé sur le srv2 qui correspond à apache2, parfait.

Inconvénient de cette méthode c'est que le client peut forger le cookie pour modifier le comportement du load balancing et indirectement rendre indisponible un serveur de backend.

Cookie de serveur

Il est aussi possible d'utilisé le cookie de session fournit par le serveur backend.
Edition la partie backend de /etc.haproxy/haproxy.conf :

backend bk_apache
        balance roundrobin
        mode http
        cookie PHPSESSID prefix indirect nocache
        server apache1 10.0.0.1:80 check cookie srv1
        server apache2 10.0.0.2:80 check cookie srv2
        server apache3 10.0.0.3:80 check cookie srv3

Dans cet exemple on va intercepter le cookie de session PHP et ajouter/supprimer la référence du serveur de backend.

Le mot clé prefix permet de réutiliser un cookie applicatif et lui préfixer l'identifiant du serveur,
puis le supprimer dans les requêtes suivantes.

Un petit schéma explicatif :

Nom par défaut des cookies par type de seveur backend :
Java : JSESSIONID
ASP.Net : ASP.NET_SessionId
ASP : ASPSESSIONID
PHP : PHPSESSID

Note :
Il est tout à fait possible d'utiliser un nom de cookie personnalisé, dans tous les cas il faut voir cela avec le développeur de l'application hébergé par les serveurs backend.