Tutoriel : Load balancing avec Apache et Tomcat

Version	Date	Description
1.0.0	26/09/2008	Création de l'article.
1.1.0	17/05/2010	Mise à jour de l'article nouvelle façon de configurer apache2 depuis la version 2.1.

I - Introduction

I-1 - Présentation
Lors de la mise en production d'une application internet ou intranet, il est fréquent de vouloir mettre en frontal un Apache HTTP Server devant un Tomcat. Cela permet une integration plus aisée et plus flexible que la simple utilisation d'un Tomcat. En effet, cela permet d'utiliser pleins de fonctionnalités d'Apache:

• Re-écriture d'URLs;
• Compression des flux HTTP (pour une meilleure performance);
• Utilisation des mécanismes de caches HTTP (pour une meilleure performance);
• Intégration d'un environnement de répartition de charge "Load Balancing", c'est ce que nous allons voir dans cet article.

I-2 - Qu'est-ce que le load balancing?
L'équilibrage de charge (parfois appelé répartition de charge ou en anglais load balancing) consiste à distribuer une tâche à un pool de machines ou de périphériques afin :

• de lisser le trafic réseau, c'est-à-dire de répartir la charge globale vers différents équipements;
• de s'assurer de la disponibilité des équipements, en n'envoyant des données qu'aux équipements en mesure de répondre, voire à ceux offrant le meilleur temps de réponse.

Ce type de mécanisme s'appuie sur un élément, appelé répartiteur de charge (en anglais load balancer) chargé de distribuer le travail entre les différentes machines.

Les avantages du load balancing sont donc multiples:

• Meilleur performance du service demandé: les requêtes sont réparties sur les différentes machines;
• Tolérance aux pannes: si un serveur s'arrête, les nouvelles requêtes sont réparties sur le pool de serveurs restant;
• Continuité du service en cas de maintenance: si un serveur est arrêté pour être maintenu, les nouvelles requêtes sont réparties sur le pool de serveurs restant en service.

L'infrastructure cible de load balancing est la suivante:

Infrastructure avec load balancing

Attention, il ne faut pas confondre load balancing et clustering. Le load balancing consiste à répartir de la charge de travail sur un pool de serveurs. Le clustering consiste à avoir une réplication de l'état des objets sur tous les noeuds du cluster. Une infrastructure en mode clustering ressemble au schéma suivant:

Infrastructure avec load balancing et clustering de sessions

II - Configuration utilisée

Pour ce tutoriel (mise en place du load balancing sans clustering), voilà la configuration que j'ai utilisée:

• Ubuntu 10.4 - http://www.ubuntu.com/
• Apache HTTP Server v2.2.14 - http://httpd.apache.org/
• Apache Tomcat v6.0.24 - http://tomcat.apache.org/

III - Installation

III-1 - Installation d'Apache HTTP Server

• Lancez l'installation du serveur HTTP: sudo apt-get install apache2 (le serveur apache est installé sous /etc/apache2).

III-2 - Installation d'Apache Tomcat

• Lancez l'installation de Tomcat: sudo apt-get install tomcat6 (le serveur tomcat est installé sous /etc/tomcat6) sur une machine A (dans mon cas 192.168.0.10).
• Lancez une seconde fois l'installation de Tomcat: sudo apt-get install tomcat6 (le serveur tomcat est installé sous /etc/tomcat6) sur une machine B (dans mon cas 192.168.0.11).

Au terme de cette installation, nous avons 2 installations de tomcat, une pour chacun des noeuds du pool de serveurs (sur les machines A et B).

III-3 - Installation des mods

• sudo cp /etc/apache2/mods-available/proxy_ajp.load /etc/apache2/mods-enabled/
• sudo cp /etc/apache2/mods-available/proxy_balancer.load /etc/apache2/mods-enabled/

IV - Configuration

IV-1 - Configuration du premier noeud tomcat (Machine A)

• Editez le fichier /etc/tomcat6/server.xml
• Décommentez le connecteur AJP:
• Positionner l'attribut jvmRoute de l'élément Engine à node1:
• Sauvegardez et fermez.

[...] <connector port="8009" protocol="AJP/1.3" redirectport="8443"/> [...] <engine name="Catalina" defaulthost="localhost" jvmroute="node1"> [...]
server.xml (Machine A)

IV-2 - Configuration du second noeud tomcat (Machine B)

• Editez le fichier /etc/tomcat6/server.xml
• Décommentez le connecteur AJP:
• Positionner l'attribut jvmRoute de l'élément Engine à node2:

[...] <connector port="8009" protocol="AJP/1.3" redirectport="8443"/> [...] <engine name="Catalina" defaulthost="localhost" jvmroute="node2"> [...]
server.xml (Machine B)

IV-3 - Configuration des mods

• Créez un fichier /etc/apache2/mods-enabled/proxy_balancer.conf avec le contenu suivant:

• <Proxy balancer://mycluster> BalancerMember ajp://192.168.0.10:8009 min=10 max=100 route=node1 loadfactor=1 BalancerMember ajp://192.168.0.11:8009 min=10 max=100 route=node2 loadfactor=1 Order deny,allow Allow from all </Proxy> ProxyPass / balancer://mycluster/
  proxy_balancer.conf

• Enregistrez et fermez.

V - Lancement des serveurs et test

• Démarrez votre premier noeud tomcat.
• Une fois le premier noeud démarré, il doit être accessible sur l'URL http://machine_a:8080 (dans mon cas http://192.168.0.10:8080)
  
• Démarrez votre second noeud tomcat.
• Une fois le second noeud démarré, il doit être accessible sur l'URL http://machine_b:8080 (dans mon cas http://192.168.0.11:8080). Il se peut que le serveur n'arrive pas à démarré si les numéros de port ont mal été configuré et/ou qu'un port déjà ouvert soit utilisé.
  
• Démarrer ou re-démarrez votre serveur Apache.
• Une fois le serveur Apache démarré, il doit être accessible sur l'URL http://loadbalancer (dans mon cas http://192.168.0.11 car mon serveur apache se trouve sur la même machine qu'une de mes instances Tomcat) Sur cette URL le contenu du serveur tomcat doit être visible.
• Faites des tests en stoppant, un seuveur tomcat (l'application doit toujours être accessible via le second tomcat), puis en stoppant les 2 serveurs tomcat (l'application ne doit plus être accessible), puis redémarrez un tomcat (l'application doit de nouveau être accessible).
  

VI - Conclusion

Les avantages du load balancing sont nombreux: maintenance, continuité du service en cas de panne d'un serveur, répartition de la charge de travail sur les différents serveurs, ...
L'utilisation des sticky sessions (affinité de sessions) implique qu'un utilisateur ayant une session active travaillera toujours avec le même serveur. Cela à l'avantage, d'alléger l'infrastructure car il n'est pas nécessaire de mettre en place du clustering (avec de la réplication de sessions) car c'est lourds à mettre en oeuvre et cela à un cout en terme de réplication de session (surcharge réseau lié à la réplication, plus il y aura de noeuds plus la réplication sera couteuse, ...). Le désavantage est que sans clustering, si un utilisateur travaille avec un serveur et que celui-ci s'arrête (panne, arrêt pour maintenance, ...), l'utilisateur perdra sa session. Cela peut-être problématique pour certaines applications, mais dans la majeur partie des cas cela ne l'est pas. C'est donc à vous de voir en fonction de vos besoins et de vos contraintes.

VII - Bibliographie

• Ubuntu 10.4 - http://www.ubuntu.com/
• Apache HTTP Server v2.2.14 - http://httpd.apache.org/
• Apache Tomcat v6.0.24 - http://tomcat.apache.org/