L'affinité de session avec ClusterHAT
De quoi s'agit-il ?
Dans un article intitulé "Haute disponibilité et équilibrage de charge avec ClusterHAT", on a vu qu'il était possible à plusieurs serveurs de répondre en fonction de leur charge respective à une même requête http.
Seulement lorsqu'une transaction passe par la navigation dans plusieurs pages web, on risque de perdre les données de session, si ce n'est pas le même serveur qui répond d'une page l'autre.
Comme vu dans un autre article, les sessions sont enregistrées dans le navigateur de l'internaute sous la forme d'un cookie. Or ce cookie est propre au serveur web qui en est à l'origine. Si, entre deux pages web, ce n'est pas le même serveur qui répond, il y aura un cookie différent pour chaque serveur. Et si celui-ci est sensé porter les données d'une transaction la transaction a toutes les chances d'échouer.
Il est donc important de s'assurer que le cookie est toujours valide tout au long de la transaction, voire pendant toute la navigation d'un internaute sur le site et que c'est toujours le même serveur qui répond. Ce qui n'empêche pas que les autres serveurs répondent chacun leur tour lorsque d'autres internautes arrivent sur le site web. Cela s'appelle l'affinité de sessions.
Comme vu dans un autre article, les sessions sont enregistrées dans le navigateur de l'internaute sous la forme d'un cookie. Or ce cookie est propre au serveur web qui en est à l'origine. Si, entre deux pages web, ce n'est pas le même serveur qui répond, il y aura un cookie différent pour chaque serveur. Et si celui-ci est sensé porter les données d'une transaction la transaction a toutes les chances d'échouer.
Il est donc important de s'assurer que le cookie est toujours valide tout au long de la transaction, voire pendant toute la navigation d'un internaute sur le site et que c'est toujours le même serveur qui répond. Ce qui n'empêche pas que les autres serveurs répondent chacun leur tour lorsque d'autres internautes arrivent sur le site web. Cela s'appelle l'affinité de sessions.
Prérequis
Lire l'article intitulé "Les session en PHP". C'est l'exemple décrit alors qui sert de base pour le présent article.
Lire l'article intitulé "Haute disponibilité et équilibrage de charge avec ClusterHAT" qui décrit comment plusieurs serveurs Web peuvent répondre alternativement à une même requête http.
Lire l'article intitulé "Haute disponibilité et équilibrage de charge avec ClusterHAT" qui décrit comment plusieurs serveurs Web peuvent répondre alternativement à une même requête http.
Description du problème
Afin de bien mettre en évidence le problème on va reprendre les deux scripts session.php et page1.php utilisés dans l'article "Les sessions en PHP" auxquels on va ajouter quelques instructions pour afficher quel est le serveur qui répond.
Contenu de session.php
<?php
session_start();
$_SESSION["nom"] = "LIMOUZIN";
$_SESSION["prenom"] = "André Pierre";
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>sans titre</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta name="generator" content="Geany 1.29" />
</head>
<body>
<h2>Quel est le serveur qui répond ?</h2>
<h3> <?php $hostaddress = $_SERVER['SERVER_ADDR']; $hostname = gethostbyaddr($hostaddress); echo "Réponse provenant de $hostname ( $hostaddress )"; ?> </h3>
<h2>Variables de session</h2>
<table border="1">
<tr><th>Clef</th><th>Valeur</th></tr>
<?php
foreach ($_SESSION as $key=>$value
{
echo "<tr><td>$key</td><td>$value</td></tr>";
}
?>
</table>
<p><a href="page1.php">Lien vers Page 1</a></p>
<p>
nom= <?= $_SESSION["nom"] ?>
</p>
</body>
</html>
session_start();
$_SESSION["nom"] = "LIMOUZIN";
$_SESSION["prenom"] = "André Pierre";
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>sans titre</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta name="generator" content="Geany 1.29" />
</head>
<body>
<h2>Quel est le serveur qui répond ?</h2>
<h3> <?php $hostaddress = $_SERVER['SERVER_ADDR']; $hostname = gethostbyaddr($hostaddress); echo "Réponse provenant de $hostname ( $hostaddress )"; ?> </h3>
<h2>Variables de session</h2>
<table border="1">
<tr><th>Clef</th><th>Valeur</th></tr>
<?php
foreach ($_SESSION as $key=>$value
{
echo "<tr><td>$key</td><td>$value</td></tr>";
}
?>
</table>
<p><a href="page1.php">Lien vers Page 1</a></p>
<p>
nom= <?= $_SESSION["nom"] ?>
</p>
</body>
</html>
Contenu de page1.php
<?ph
session_start();
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Page 1</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta name="generator" content="Geany 1.29" />
</head>
<body>
<h1>Page 1</h1>
<h2>Quel est le serveur qui répond ?</h2>
<h3> <?php $hostaddress = $_SERVER['SERVER_ADDR']; $hostname = gethostbyaddr($hostaddress); echo "Réponse provenant de $hostname ( $hostaddress )"; ?> </h3>
<h2>Variables de session</h2>
<table border="1">
<tr><th>Clef</th><th>Valeur</th></tr>
<?php
foreach ($_SESSION as $key=>$value)
{
echo "<tr><td>$key</td><td>$value</td></tr>";
}
?>
</table>
</body>
</html>
session_start();
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Page 1</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta name="generator" content="Geany 1.29" />
</head>
<body>
<h1>Page 1</h1>
<h2>Quel est le serveur qui répond ?</h2>
<h3> <?php $hostaddress = $_SERVER['SERVER_ADDR']; $hostname = gethostbyaddr($hostaddress); echo "Réponse provenant de $hostname ( $hostaddress )"; ?> </h3>
<h2>Variables de session</h2>
<table border="1">
<tr><th>Clef</th><th>Valeur</th></tr>
<?php
foreach ($_SESSION as $key=>$value)
{
echo "<tr><td>$key</td><td>$value</td></tr>";
}
?>
</table>
</body>
</html>
Lors du chargement de la page session.php, c'est le serveur slave02 (par hasard) qui a répondu. Comme dans le précédent article, les deux valeurs nom et prenom sont enregistrées dans le cookie.
Lorsque l'internaute clique le lien vers la Page 1, c'est le serveur slave01 qui répond. Mais comme le cookie est lié au serveur slave02, un nouveau cookie vide est créé pour slave01. La page ci-dessous s'affiche pour un cookie vide.
En rafraîchissant la page avec F5, cette fois c'est à nouveau le serveur slave02 qui répond et les valeur enregistrées peuvent être affichées.
En rafraîchissant encore la page avec F5, cette fois c'est le serveur slave03 qui répond et un nouveau cookie vide est créé pour ce serveur.
En rafraîchissant successivement la page, on constate que les valeurs de session ne sont affichées que si c'est le serveur qui les a initialisées (slave02 en l’occurrence) qui répond.
Configurer le proxy pour implémenter l'affinité de session
Comme vu dans l'article intitulé "Haute disponibilité et équilibrage de charge avec ClusterHAT", la configuration de HaProxy utilisé pour l'équilibrage de charge s'effectue dans le fichier /etc/haproxy/haproxy.cfg.
pi@cluster01:~ $ sudo nano /etc/haproxy/haproxy.cfg
pi@cluster01:~ $
pi@cluster01:~ $
Avec nano, modifier la configuration de HaProxy comme indiqué ci-dessous.
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL). This list is from:
# https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
# An alternative list with additional directives can be obtained from
# https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend ClusterHat-nodes
bind *:80
mode http
default_backend Web-nodes
backend Web-nodes
mode http
balance roundrobin
option forwardfor
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
option httpchk HEAD / HTTP/1.1\r\nHost:localhost
cookie CLUSTER insert nocache
server Pi-Zero-01 slave01:8080 cookie Z1 check
server Pi-Zero-02 slave02:8080 cookie Z2 check
server Pi-Zero-03 slave03:8080 cookie Z3 check
stats enable
stats uri /stats
stats hide-version
stats auth admin:admin
stats refresh 30s
stats show-node
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL). This list is from:
# https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
# An alternative list with additional directives can be obtained from
# https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend ClusterHat-nodes
bind *:80
mode http
default_backend Web-nodes
backend Web-nodes
mode http
balance roundrobin
option forwardfor
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
option httpchk HEAD / HTTP/1.1\r\nHost:localhost
cookie CLUSTER insert nocache
server Pi-Zero-01 slave01:8080 cookie Z1 check
server Pi-Zero-02 slave02:8080 cookie Z2 check
server Pi-Zero-03 slave03:8080 cookie Z3 check
stats enable
stats uri /stats
stats hide-version
stats auth admin:admin
stats refresh 30s
stats show-node
CLUSTER est le nom du cookie qui sera inséré. Z1, Z2 et Z3 sont les valeurs que va prendre le cookie en fonction du serveur qui a répondu à la visite de la première page par l'internaute. La mention nocache indique qu'il ne faut pas mettre en cache le cookie pour ne pas généré d'effet de bord, le cache étant vidé lorsque le navigateur est fermé,
A l'arrivée de l'internaute sur votre site, si aucun cookie CLUSTER n'est trouvé, un nouveau cookie CLUSTER est créé et il prend la valeur du serveur qui a répondu. Lors de la visite de l'internaute sur les autres pages su site, comme le cookie CLUSTER est trouvé, la redirection s'effectue sur le serveurs correspondant à la valeur du cookie.
Une fois la configuration modifiée, il faut redémarrer le proxy :
A l'arrivée de l'internaute sur votre site, si aucun cookie CLUSTER n'est trouvé, un nouveau cookie CLUSTER est créé et il prend la valeur du serveur qui a répondu. Lors de la visite de l'internaute sur les autres pages su site, comme le cookie CLUSTER est trouvé, la redirection s'effectue sur le serveurs correspondant à la valeur du cookie.
Une fois la configuration modifiée, il faut redémarrer le proxy :
pi@cluster01:~ $ sudo service haproxy restart
pi@cluster01:~ $
pi@cluster01:~ $
Test de la configuration
Nous allons reprendre l'expérience effectuée au début de cet article.
Lors du chargement de la page session.php, c'est encore le serveur slave02 (par hasard) qui a répondu. Comme vu au début de cet article, les deux valeurs nom et prenom sont enregistrées dans le cookie.
En rafraîchissant successivement la page avec F5, on constate que c'est toujours le serveur slave02 qui, cette fois, répond.
En revanche, si on ferme le navigateur pour le rouvrir avec la page session.php, il est probable que ce soit un autre serveur qui réponde. L'équilibrage de charge est bien effectif. Et, tant qu'on ne ferme pas le navigateur, l'affinité de session est assurée.
Commentaires
Enregistrer un commentaire