| Version | Date | Description |
|---|
| 1.0.0 | 26/09/2008 | Création de l'article. |
I - IntroductionI-1 - PrésentationLors 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éePour ce tutoriel (mise en place du load balancing sans clustering), voilà la configuration que j'ai utilisée:
III - InstallationIII-1 - Installation d'Apache HTTP Server- Lancez l'installeur du serveur HTTP et laissez-vous guider, choisissez le répertoire d'installation (par exemple D:\prod-apps\apache2.2.9).
III-2 - Installation d'Apache Tomcat- Dé-zippez le fichier .zip précédemment téléchargé dans un répertoire (par exemple D:\prod-apps\apache-tomcat-x.y.z-node1)
- Dé-zippez une seconde fois le fichier .zip précédemment téléchargé dans un répertoire (par exemple D:\prod-apps\apache-tomcat-x.y.z-node2)
Au terme de cette installation, nous avons 2 installation de tomcat, une pour chacun des noeuds du pool de serveurs.
III-3 - Installation du Connecteur mod_jk- Copiez le fichier mod_jk-1.2.26-httpd-2.2.4.so dans le répertoire D:\prod-apps\apache2.2.9\modules
- Renommez ce fichier en mod_jk.so
IV - ConfigurationIV-1 - Configuration du premier noeud tomcat (apache-tomcat-x.y.z-node1)- Editez le fichier D:\prod-apps\apache-tomcat-x.y.z-node1\conf\server.xml, et remplacez tous les numéros de ports pour avoir des numéros en 9XXX ainsi le numéro de port 8005 devient 9005, 8080 devient 9080, 8443 devient 9443, 8009 devient 9009, ...
- Positionner l'attribut jvmRoute de l'élement Engine à node1.
- Sauvegardez et fermez.
IV-2 - Configuration du second noeud tomcat (apache-tomcat-x.y.z-node2)- Editez le fichier D:\prod-apps\apache-tomcat-x.y.z-node2\conf\server.xml, et remplacez tous les numéros de ports pour avoir des numéros en 10XXX ainsi le numéro de port 8005 devient 10005, 8080 devient 10080, 8443 devient 10443, 8009 devient 10009, ...
- Positionner l'attribut jvmRoute de l'élement Engine à node2.
- Sauvegardez et fermez.
IV-3 - Configuration du connecteur mod_jk- Editez le fichier D:\prod-apps\apache2.2.9\conf\httpd.conf, et ajoutez les directive suivantes à la suite des directives LoadModule:
[...]
LoadModule jk_module modules/mod_jk.so
JkWorkersFile "D:/prod-apps/apache/apache2.2.9/conf/worker.properties"
JkLogFile "D:/prod-apps/apache/apache2.2.9/logs/mod_jk.log"
JkLogLevel warning
JkMount / loadbalancer
JkMount /* loadbalancer
[...]
|
| httpd.conf |
|---|
- Enregistrez et fermez.
- Créez un fichier D:\prod-apps\apache2.2.9\conf\worker.properties avec le contenu suivant:
ps=/
#La liste des tomcat qui rentre dans notre load-balancer, plus l'alias sur le load-balancer
worker.list=loadbalancer,node1,node2
#La config du load-balencer
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=node1,node2
#Le premier tomcat
worker.node1.type=ajp13
worker.node1.host=127.0.0.1
worker.node1.port=9009
worker.node1.lbfactor=10
#Le second Tomcat, attention soit l'hôte soit le port doivent différés
worker.node2.type=ajp13
worker.node2.host=127.0.0.1
worker.node2.port=10009
worker.node2.lbfactor=10
|
| worker.properties |
|---|
- 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://[hostname]:9080
- Démarrez votre second noeud tomcat.
- Une fois le second noeud démarré, il doit être accessible sur l'URL http://[hostname]:10080. Il se peut que le seveur n'arrive pas à démarré si les numéros de port ont mal été configuré et 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://[hostname]. 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 - ConclusionLes 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 utilisation 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 - BibliographieSur le même thème:
