Module Apache mod_proxy_balancer

L'algorithme de planification de la r�partition de charge

A l'heure actuelle, 3 algorithmes de planification de la r�partition de charge sont disponibles : ils se basent respectivement sur le comptage des requ�tes, la mesure du trafic et le comptage des requ�tes en attente. 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 apache2.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 ProxySet. Le cookie peut �tre d�fini soit par le serveur d'arri�re-plan, soit, comme indiqu� dans l'exemple ci-dessus par le serveur web Apache lui-m�me.

Certains serveurs d'arri�re-plan, tels qu'Apache Tomcat, utilisent une forme sensiblement diff�rente de cookie d'abonnement. Tomcat ajoute le nom de l'instance Tomcat � la fin de son identifiant de session, pr�c�d� par un point. Ainsi, si le serveur web Apache trouve un point dans la valeur du cookie d'abonnement, il n'utilisera que la partie situ�e apr�s ce point pour rechercher sa route. Pour que Tomcat puisse conna�tre son nom d'instance, vous devez d�finir l'attribut jvmRoute dans son fichier de configuration conf/server.xml � la valeur de la route du serveur qui se connecte au Tomcat consid�r�. Le nom du cookie de session utilis� par Tomcat (et plus g�n�ralement par les applications web Java � base de servlets) est JSESSIONID (en majuscules), mais peut �tre modifi�.

La seconde m�thode pour impl�menter l'abonnement est le codage d'URL. Ici, le serveur web recherche un param�tre dans l'URL de la requ�te. Le nom du param�tre est sp�cifi� par l'attribut stickysession. Pour trouver un serveur membre, on recherche un serveur dont la route est �gale � la valeur du param�tre. Comme il n'est pas ais� d'extraire et de manipuler tous les liens URL contenus dans les r�ponses, le travail consistant � ajouter les param�tres � chaque lien est g�n�ralement effectu� par le serveur d'arri�re-plan qui g�n�re le contenu. Bien qu'il soit possible dans certains cas d'effectuer ces ajouts au niveau du serveur web via les modules mod_substitute ou mod_sed, cette m�thode peut d�grader les performances.

Les standards Java impl�mentent le codage d'URL de mani�re sensiblement diff�rente. Ils ajoutent une information de chemin � l'URL en utilisant un point-virgule (;) comme s�parateur, puis ajoutent enfin l'identifiant de session. Comme dans le cas des cookies, Apache Tomcat peut ins�rer la valeur de l'attribut jvmRoute dans cette information de chemin. Pour qu'Apache puisse trouver ce genre d'information de chemin, vous devez d�finir scolonpathdelim � On dans la directive ProxyPass ou ProxySet.

Enfin, vous pouvez utiliser simultan�ment les cookies et le codage d'URL en d�finissant le nom du cookie et le nom du param�tre d'URL s�par�s par une barre verticale (|) comme dans l'exemple suivant :

ProxyPass /test balancer://mycluster stickysession=JSESSIONID|jsessionid scolonpathdelim=On
<Proxy balancer://mycluster>
    BalancerMember http://192.168.1.50:80 route=node1
    BalancerMember http://192.168.1.51:80 route=node2
</Proxy>
    

Si le cookie et le param�tre de requ�te fournissent tous deux une information de route correcte pour la m�me requ�te, c'est l'information en provenance du param�tre de requ�te qui sera retenue.

R�solution des probl�mes li�s � la r�partition de charge par abonnement

Si vous �tes confront� � des erreurs d'abonnement, comme la n�cessit� pour les utilisateurs de se reconnecter suite � une perte de session d'application, vous devez tout d'abord v�rifier si ceci n'est pas du � une indisponibilit� sporadique des serveurs d'arri�re-plan ou � une erreur de configuration. La pr�sence de messages d'erreur de type proxy dans le journal des erreurs d'Apache pourra r�v�ler des probl�mes de stabilit� au niveau des serveurs d'arri�re-plan.

Pour contr�ler votre configuration, regardez tout d'abord si l'abonnement est � base de cookie ou de codage d'URL. L'�tape suivante consiste � enregistrer certaines donn�es dans le journal des acc�s en utilisant un format de journalisation personnalis�. Les champs int�ressants sont les suivants :

%{MONCOOKIE}C

La valeur que contient le cookie de nom MONCOOKIE. Le nom doit correspondre au nom d�fini par l'attribut stickysession.

%{Set-Cookie}o

Ce champ contient tout cookie d�fini par le serveur d'arri�re-plan. Vous pouvez ainsi v�rifier si le serveur d'arri�re-plan d�finit bien le cookie de session auquel vous vous attendez, et � quelle valeur il est d�fini.

%{BALANCER_SESSION_STICKY}e

Le nom du cookie ou du param�tre de requ�te utilis� pour la recherche de l'information de routage.

%{BALANCER_SESSION_ROUTE}e

L'information de routage extraite de la requ�te.

%{BALANCER_WORKER_ROUTE}e

La route du serveur choisi.

%{BALANCER_ROUTE_CHANGED}e

Contient la valeur 1 si la route extraite de la requ�te est diff�rente de la route du serveur ; autrement dit, le traitement de la requ�te n'a pas pu �tre effectu� dans le cadre d'une r�partition de charge par abonnement.

Les pertes de session sont souvent dues � des expirations de session dont la valeur peut en g�n�ral �tre configur�e au niveau du serveur d'arri�re-plan.

Si le niveau de journalisation est d�fini � debug ou plus, le r�partiteur journalise aussi des informations d�taill�es � propos de l'abonnement dans le journal des erreurs, ce qui facilite la r�solution des probl�mes d'abonnement. Notez cependant que le volume de journalisation pourra alors s'av�rer trop important pour un serveur en production sous forte charge.