cluster Tomcat 6 Configuration d?un cluster Tomcat 6

Clustertomcat6
cluster Tomcat 6
Configuration d?un cluster Tomcat 6
Lors de la mise en place d?un cluster avec Tomcat 6, il est indispensable de garantir l?intégrité des applications
entre les instances. En effet, il n?y a pas à l?heure actuelle d?outil d?administration permettant de déployer les
applications Web dans un cluster Tomcat 6, les applications doivent être installées individuellement sur chacune
des instances de serveur.
Un tel outil possède évidement une très grande valeur ajoutée car il permet la distribution automatique des
applications vers toutes les instances, y compris si elles se trouvent sur des machines différentes.
Consciente de ce manque, l?équipe de développeurs de Tomcat s?est penché sur la question et un outil de ce type
devrait apparaître dans les prochaines versions de Tomcat.
Installer plusieurs instances de Tomcat 6 sur la même machine
Pour permettre à plusieurs instances de Tomcat 6 de s?exécuter sur la même machine, l?installation des instances
du serveur est un peu particulière. En effet, une première contrainte impose à chacune des instances d?utiliser des
ports TCP/IP distincts pour éviter les conflits, mais il n?est pas possible de simplement décompresser l?archive ZIP
du serveur à deux endroits différents pour avoir deux instances, car il ne peut y avoir qu?une seule variable
d?environnement CATALINA_HOME.
La solution consiste à utiliser la variable d?environnement CATALINA_BASE. Cette variable permet de faire
référence au répertoire contenant la configuration spécifique d?une instance. Lorsqu?une seule instance de Tomcat
6 fonctionne, la valeur de cette variable est copiée de CATALINA_HOME.
Dans le cas où, par exemple, deux instances de serveur doivent fonctionner sur la même machine, les deux
instances partageront la même variable CATALINA_HOME, mais auront chacune une variable
CATALINA_BASE. Il y a donc une partie commune à ces instances, et une partie qui leur est propre.
Chaque instance de serveur doit posséder :
sa propre configuration (le répertoire conf/),
son propre répertoire logs/,
ses propres répertoires temporaires (work/ et temp/).
Les autres répertoires, c?est-à-dire bin/ et lib/, peuvent être commun, ainsi, les librairies du serveur ne sont pas
dupliquées. Voici un exemple d?arborescence de cluster Tomcat 6 : 08RI01.png
Il faut ensuite créer des scripts de démarrage et d?arrêt spécifiques pour chacune des deux instances, l?objectif est
de positionner la variable CATALINA_BASE puis d?invoquer le script startup.bat ou shutdown.bat, chacun de ces
scripts devant se trouver dans CATALINA_HOME/bin.
Installer plusieurs instances de Tomcat 6 sur la même machine
1
Clustertomcat6
Le script de démarrage de la première instance peut par exemple être nommé startTomcat1.bat, il contient les
lignes suivantes :
set CATALINA_BASE=C:\Cluster\tomcat1 call startup
Le script d?arrêt stopTomcat1.bat :
set CATALINA_BASE=C:\Cluster\tomcat1 call shutdown
Les scripts de la deuxième instance sont identiques, à la valeur près de CATALINA_BASE.
La version Linux de ces scripts n?est pas plus compliquée, par exemple, le script de démarrage de la première
instance peut s?appeler startTomcat1.sh et il contient les lignes suivantes :
1. ! /bin/bash
export CATALINA_BASE=/usr/cluster/tomcat1 . $CATALINA_HOME/bin/startup.sh
Le script d?arrêt quant à lui peut s?appeler stopTomcat1.sh :
1. ! /bin/bash
export CATALINA_BASE=/usr/cluster/tomcat1 . $CATALINA_HOME/bin/shutdown.sh
Ces deux exemples supposent que CATALINA_HOME pointe vers /usr/cluster/.
La dernière étape consiste à faire en sorte que chacune des instances utilise des ports distincts pour le connecteur
HTTP, le connecteur JK, et le port d?arrêt du serveur.
Les deux instances peuvent maintenant être démarrées, en cas de problème, les fichiers journaux de chacune des
instances sont suffisamment explicites sur les erreurs de configuration.
Répartition de charge avec les modules JK
Le chapitre Le serveur Apache Tomcat 6 - Installation et configuration aborde la configuration de Tomcat 6 avec
un serveur frontal Apache HTTP Server ou Microsoft IIS, les modules JK respectifs pour ces serveurs, mod_jk
pour Apache, et le redirecteur ISAPI pour IIS, permettent la mise en ?uvre d?une solution de répartition de charge
et de tolérance de panne.
D?un point de vue de la répartition de charge, les modules JK utilisent un algorithme de répartition de type
Round-Robin , c?est-à-dire que les requêtes sont envoyées alternativement sur chacune des instances, et ce,
toujours dans le même ordre.
Cet algorithme est un des plus utilisé dans le domaine de la répartition de charge car il permet d?équilibrer la
charge sur chacune des instances, il est cependant possible d?affecter un poids plus important à une instance, si elle
se trouve sur une machine plus puissante que les autres par exemple.
Répartition de charge avec les modules JK
2
Clustertomcat6
Cependant, un problème survient lorsqu?il s?agit de gérer les sessions utilisateurs, qui sont conservées sur le
serveur (voir le chapitre La plate-forme JEE 5). En effet, en supposant qu?un client émette une première requête et
qu?il soit dirigé vers la première instance, cette requête va lui créer une session, qui sera conservée dans la
mémoire de la Machine Virtuelle Java de cette instance. Ensuite, si ce même client émet une deuxième requête,
l?algorithme de Round-Robin peut très bien envoyer cette requête vers une autre instance dans ce cas, la session de
ce client est perdue.
Pour éviter ce phénomène, les modules JK utilisent un mécanisme appelé affinité de session . L?affinité de session
permet de garantir qu?à partir du moment où un client se connecte à une application qui utilise les sessions, ce
client sera toujours dirigé vers la même instance de serveur.
Du coté de la tolérance de panne, si une instance de serveur Tomcat 6 ne répond pas à un envoi de requête fait par
le module JK, alors cette instance est marquée indisponible, et le module tente d?envoyer cette requête sur une
autre instance. Répartition de charge et de tolérance de panne avec les modules JK : 08RI02.png
L?objectif est maintenant d?étendre la configuration étudiée au chapitre Le serveur Apache Tomcat 6 - Installation
et configuration pour faire cohabiter plusieurs serveurs Tomcat 6 avec un serveur Web. Les fichiers de
configuration sont les mêmes que ceux qui ont déjà été mis en ?uvre pour une configuration avec un serveur
Tomcat 6 unique.
Configuration avec Apache HTTP Server
Apache utilise son propre fichier de configuration httpd.conf ainsi que le fichier workers.properties pour
communiquer avec Tomcat 6.
Voici, à titre de rappel, un exemple de configuration.
Le fichier de configuration d?Apache httpd.conf :
JkWorkersFile conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevel info JkMount /ListeEmployes
worker1
Le fichier workers.properties :
worker.list=worker1 worker.worker1.type=ajp13 worker.worker1.host=localhost worker.worker1.port=8009
En reprenant l?exemple de cluster proposé au point Configuration d?un cluster Tomcat 6 - Installer plusieurs
instances de Tomcat sur la même machine de ce chapitre, il faut modifier la configuration de telle sorte que
chacune des instances soit associée à un travailleur : voici le fichier workers.properties à utiliser pour cette
configuration :
Pour plus de clarté, les travailleurs portent le nom des instances.
worker.list=tomcat1, tomcat2
worker.tomcat1.type=ajp13 worker.tomcat1.host=localhost worker.tomcat1.port=8109
worker.tomcat2.type=ajp13 worker.tomcat2.host=localhost worker.tomcat2.port=8209
Configuration avec Apache HTTP Server
3
Clustertomcat6
Dans cet exemple, le serveur Web ainsi que les deux instances de Tomcat 6 sont sur la même machine physique,
d?où l?utilisation de la valeur localhost en tant que nom d?hôte, il faut bien sûr adapter ces valeurs en fonction de
l?architecture mise en ?uvre, et utiliser de préférence des adresses IP plutôt que des noms de machines.
Les travailleurs pour chacune des deux instances étant maintenant déclarés, il faut maintenant ajouter un travailleur
supplémentaire responsable de la répartition de charge avec l?algorithme Round-Robin. Ce travailleur est
particulier, car son type n?est pas ajp13, mais lb dans la mesure où il ne communique pas avec Tomcat 6 mais fait
simplement la répartition des requêtes (lb = Load-Balancing). En plus d?avoir un type différent, ce travailleur
utilise un attribut permettant de faire référence à tous les travailleurs qui participent à la répartition de charge, c?est
l?attribut balanced_workers.
Voici le fichier workers.properties modifié avec l?ajout du travailleur supplémentaire, il est nommé balancer. Les
lignes modifiées sont en gras.
worker.list=tomcat1, tomcat2, balancer
worker.tomcat1.type=ajp13 worker.tomcat1.host=localhost worker.tomcat1.port=8109
worker.tomcat2.type=ajp13 worker.tomcat2.host=localhost worker.tomcat2.port=8209
worker.balancer.type=lb worker.balancer.balanced_workers=tomcat1,tomcat2
Il est également possible d?ajouter un attribut supplémentaire sur les travailleurs de type ajp13, l?attribut lbfactor
permet d?affecter un poids aux travailleurs, par défaut cet attribut vaut 1, chaque travailleur reçoit donc une
quantité identique de requête. En donnant la valeur 1 pour cet attribut au travailleur tomcat1, et la valeur 2 au
travailleur tomcat2, le premier reçoit alors deux fois moins de requêtes que le second.
Une fois le fichier workers.properties modifié, la configuration du serveur Apache doit, elle aussi, subir un petit
changement. En effet, le travailleur associé aux applications doit être le travailleur responsable de la répartition de
charge.
Le fichier httpd.conf précédent doit donc être modifié comme ceci :
JkWorkersFile conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevel info JkMount /ListeEmployes
balancer
La configuration du côté du serveur Web est maintenant terminée.
La topologie de cluster présentée précédemment dans ce chapitre est quasiment opérationnelle, il manque
simplement un élément pour permettre l?affinité de session. Il s?agit d?un attribut de configuration à rajouter sur
l?élément <Engine> de chaque instance, c?est l?attribut jvmRoute. Cet attribut doit prendre comme valeur le nom
du travailleur Tomcat 6 qui sera amené à envoyer des requêtes sur cette instance. Il faut donc éditer les fichiers
server.xml des deux instances pour ajouter cet attribut.
Fichier server.xml de la première instance (C:\Cluster\tomcat1\conf\server.xml) :
... <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1"> ...
Fichier server.xml de la seconde instance (C:\Cluster\tomcat2\conf\server.xml) :
Configuration avec Apache HTTP Server
4
Clustertomcat6
... <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat2"> ...
À noter qu?il n?y a rien de particulier à faire du coté du module JK ou d?Apache pour activer l?affinité de session :
elle l?est par défaut. Par contre, s?il est nécessaire de désactiver ce mécanisme, il faut ajouter l?attribut de
configuration sticky_session sur le travailleur de type lb dans le fichier workers.properties, et lui donner la valeur 0
(Il vaut 1 par défaut).
Exemple :
worker.balancer.sticky_session=0
La configuration est maintenant terminée. Pour la tester, il faut utiliser plusieurs clients, et vérifier que chacun est
bien envoyé sur une instance différente.
Pour tester ce fonctionnement, il suffit juste d?ajouter une page HTML à l?application en cluster, mais qui aura un
contenu différent sur la première instance et sur la seconde, elle peut afficher le nom de l?instance par exemple.
Ensuite, la procédure suivante permet de tester que la tolérance de panne fonctionne correctement.
Démarrer les deux instances de serveur Tomcat 6.
Ouvrir un navigateur Web et demander la page ajoutée précédemment.
Arrêter l?instance qui a servi cette page.
Rafraîchir l?affichage dans le navigateur Web, il doit maintenant afficher la page de l?autre
Configuration avec Microsoft IIS
La configuration avec le serveur Web de Microsoft diffère assez peu de celle réalisée pour Apache, dans la mesure
où IIS utilise également le fichier workers.properties avec exactement la même syntaxe.
La différence réside dans la manière de mettre en relation les applications Web avec les travailleurs, en effet, IIS
utilise pour ceci le fichier uriworkermap.properties. Pour utiliser la même configuration de cluster Tomcat 6 que
précédemment, le fichier uriworkermap.properties doit contenir la ligne suivante :
/ListeEmployes/*=balancer
Pour tester la configuration, la procédure décrite avec Apache fonctionne également très bien avec IIS.
Configuration d?un cluster Tomcat 6 en mode maître/esclave
Avec les versions récentes de mod_jk, il est également possible de configurer un cluster Tomcat 6 en mode
maître/esclave. Dans ce mode de fonctionnement avec deux instances de serveurs par exemple, une seule des deux
instances est active pour satisfaire les demandes utilisateur, la deuxième instance sert uniquement à remplacer la
première en cas de défaillance.
Configuration d?un cluster Tomcat 6 en mode maître/esclave
5
Clustertomcat6
Pour mettre en ?uvre une telle configuration, peu de modifications doivent être apportées à la configuration de
répartition de charge étudiée précédemment, il suffit simplement d?ajouter deux directives au fichier
workers.properties.
Exemple de configuration avec deux serveurs :
worker.list=tomcat1, tomcat2, balancer
worker.tomcat1.type=ajp13 worker.tomcat1.host=localhost worker.tomcat1.port=8109
1. Spécifier quelle instance doit prendre
2. le relais en cas de défaillance (maître)
worker.tomcat1.redirect=tomcat2
worker.tomcat2.type=ajp13 worker.tomcat2.host=localhost worker.tomcat2.port=8209
1. Spécifier que cette instance n?est qu?une instance
2. de secours (esclave)
worker.tomcat2.activation=disabled
worker.balancer.type=lb worker.balancer.balanced_workers=tomcat1,tomcat2
Dans cette configuration, une seule instance est sollicitée pour satisfaire les requêtes utilisateur (tomcat1), la
deuxième (tomcat2) prend le relais en cas de défaillance de la première. Ce type de fonctionnement d?un cluster
Tomcat 6 peut bien sûr être mis en ?uvre avec un nombre de serveurs plus important.
Configuration d?un cluster Tomcat 6 en mode maître/esclave
6