Module Apache mod_proxy_balancer

L'algorithme de planification de la répartition de charge ¶

A l'heure actuelle, 4 algorithmes de planification de la répartition de charge sont disponibles : ils se basent respectivement sur le comptage des requêtes (mod_lbmethod_byrequests), la mesure de l'intensité du trafic (mod_lbmethod_bytraffic), le comptage des requêtes en attente (mod_lbmethod_bybusyness) et la mesure de l'activité du serveur (mod_lbmethod_heartbeat). Ils sont contrôlés par la valeur de lbmethod dans la définition du répartiteur. Voir la directive ProxyPass pour plus de détails, et en particulier la configuration du répartiteur et de ses membres.

Répartition de charge avec abonnement utilisateur (stickyness) ¶

Le répartiteur supporte l'abonnement utilisateur. Lorsqu'une requête est mandatée vers un serveur d'arrière-plan particulier, toutes les requêtes suivantes du même utilisateur seront alors mandatées vers le même serveur d'arrière-plan. De nombreux répartiteurs de charge implémentent cette fonctionnalité via une table qui associe les adresses IP des clients aux serveurs d'arrière-plan. Cette approche est transparente aux clients et aux serveurs d'arrière-plan, mais induit certains problèmes : distribution de charge inégale si les clients se trouvent eux-mêmes derrière un mandataire, erreurs d'abonnement lorsqu'un client possède une adresse IP dynamique qui peut changer au cours d'une session et perte d'abonnement en cas de dépassement de la table de correspondances.

Le module mod_proxy_balancer implémente l'abonnement selon deux alternatives : les cookies et le codage d'URL. Le cookie peut être fourni par le serveur d'arrière-plan ou par le serveur web Apache lui-même, alors que le codage d'URL est en général effectué par le serveur d'arrière-plan.

Exemples de configuration d'un répartiteur ¶

Avant de nous plonger dans les détails techniques, voici un exemple d'utilisation de mod_proxy_balancer mettant en oeuvre la répartition de charge entre deux serveurs d'arrière-plan :

<Proxy "balancer://mycluster">
    BalancerMember "http://192.168.1.50:80"
    BalancerMember "http://192.168.1.51:80"
</Proxy>
ProxyPass        "/test" "balancer://mycluster"
ProxyPassReverse "/test" "balancer://mycluster"

Voici un autre exemple de répartiteur de charge avec abonnement utilisant mod_headers, fonctionnant même si le serveur d'arrière-plan ne définit pas de cookie de session approprié :

Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
<Proxy "balancer://mycluster">
    BalancerMember "http://192.168.1.50:80" route=1
    BalancerMember "http://192.168.1.51:80" route=2
    ProxySet stickysession=ROUTEID
</Proxy>
ProxyPass        "/test" "balancer://mycluster"
ProxyPassReverse "/test" "balancer://mycluster"

Variables d'environnement exportées ¶

A l'heure actuelle, 6 variables d'environnement sont exportées :

BALANCER_SESSION_STICKY

Cette variable se voir assignée la valeur de stickysession pour la requête courante. Il s'agit du nom du cookie ou du paramètre de requête utilisé pour les sessions avec abonnement.

BALANCER_SESSION_ROUTE

Cette variable se voit assignée la route interprétée pour la requête courante.

BALANCER_NAME

Cette variable se voit assigné le nom du répartiteur pour la requête courante. Il s'agit d'une valeur du style balancer://foo.

BALANCER_WORKER_NAME

Cette variable se voit assigné le nom du membre du groupe de répartition de charge utilisé pour la requête courante. Il s'agit d'une valeur du style http://hostA:1234.

BALANCER_WORKER_ROUTE

Cette variable se voit assignée la route du membre du groupe de répartition de charge qui sera utilisé pour la requête courante.

BALANCER_ROUTE_CHANGED

Cette variable est définie à 1 si la route de la session ne correspond pas à celle du membre du groupe de répartition de charge (BALANCER_SESSION_ROUTE != BALANCER_WORKER_ROUTE), ou si la session ne possède pas encore de route établie. Elle peut servir à déterminer quand il est éventuellement nécessaire d'envoyer au client une route mise à jour lorsque les sessions persistantes sont utilisées.

Activation du support du gestionnaire de répartiteur ¶

Cette fonctionnalité nécessite le chargement du module mod_status. Le gestionnaire de répartiteur permet la mise à jour dynamique des membres du groupe de répartition de charge. Vous pouvez utiliser le gestionnaire de répartiteur pour modifier le facteur de charge d'un membre particulier, ou passer ce dernier en mode hors ligne.

Ainsi, pour mettre en oeuvre la gestion du répartiteur de charge, mod_status et mod_proxy_balancer doivent être chargés dans le serveur.

Pour permettre la gestion du répartiteur de charge aux navigateurs appartenant au domaine example.com, ajoutez ces lignes à votre fichier de configuration httpd.conf :

<Location "/balancer-manager">
    SetHandler balancer-manager
    Require host example.com
</Location>

Vous pourrez alors accéder au gestionnaire du répartiteur de charge en utilisant un navigateur web pour afficher la page http://nom.de.votre.serveur/balancer-manager. Notez que pour pouvoir contrôler dynamiquement un membre de groupe de répartition, ce dernier ne doit pas être défini au sein d'une section <Location ...>.

Détails à propos de la répartition de charge par abonnement (stickyness) ¶

Si l'abonnement s'appuie sur un cookie, vous devez définir le nom de ce cookie dont le contenu précise le serveur d'arrière-plan à utiliser. Pour ce faire, on utilise l'attribut stickysession avec la directive ProxyPass ou ProxySet. Le nom du cookie est sensible à la casse. Le répartiteur extrait le contenu du cookie et recherche un serveur membre dont la route correspond à cette valeur. La route doit aussi être définie dans la directive ProxyPass ou