L'objectif est de faire en sorte que Apache répartisse les utilisateurs sur deux serveur Tomcat . Ceci peut être utile pour répartir la charge (load balancing) et sécuriser l'exploitation (crash d'un des serveurs). En revanche, il faudra livrer les mises à jour de l'arborescence du client riche sur chacun des serveurs. Cette configuration n'est donc adaptée qu'aux environnements sans publication par HRStudio.
La configuration initiale du site est la suivante :
- un Apache en frontal,
- un Tomcat avec son application HRaSpace v7,
- une base JetSpeed déportée sur l'instance DB2 de HR Design.
- si un des Tomcat "tombe", HRAccess n'assure pas la persistance de la session des utilisateurs. Ceux initialement affectés au Tomcat défaillant seront basculés sur le rescapé où ils devront se ré-authentifier (ce n'est pas une configuration de "cluster" avec réplication de session).
- Apache a été compilé avec le module proxy_balancer (présence du fichier /hraxxx/apache/modules/mod_proxy_balancer.so et dans httpd.conf : LoadModule proxy_balancer_module modules/mod_proxy_balancer.so)
- L'expérience montre qu'un schema JetSpeed unique est suffisant.
Coté Tomcat
Mise en place d'un second tomcat et son fichier de configuration :
- fermeture et copie de l'arbo tomcat /hraxxx/hraspace dans /hraxxx/hraspace.balancer,
- dans le server.xml du nouveau Tomcat, les ports 5208* sont modifiés en 5209* (pour mon test les Tomcat sont "côte à côte" sur le même serveur. Installés sur deux machines distinctes, cette modification serait inutile).
- Définition des Routes dans les fichiers "server.xml" de chaque Tomcat :
<Engine name="Catalina" defaultHost="localhost">
-->
<Engine name="Catalina" defaultHost="localhost"
jvmRoute="route1" debug="0">
(et route2 pour le second Tomcat)
Coté Apache
Fermer Apache, puis dans le extra/httpd_hraccess.conf de mon Apache (mon httpd.conf inclue cet extra) :
- Mise en commentaire du routage initial (Tomcat unique) :
# ProxyPass / ajp://localhost:52085/
# ProxyPassReverse / ajp://localhost:52085/
- Mise en place du "répartiteur" avec Proxy balancer,
- Redirection de chacune des application HRaSpace (merci Stéphane pour le tuyau) sur le cluster par ProxyPass,
- Avec stickysession (pour que les requêtes de l'utilisateurs "restent" dirigées sur le serveur qui lui a été attribué lors de sa première transaction),
- Correction avec ProxyPassReverse des messages retournés pour rétablir l'entête initial :
# Load balancing two local Tomcats
<Proxy balancer://HRaCluster>
BalancerMember ajp://localhost:52085/ loadfactor=1 route=route1
BalancerMember ajp://localhost:52095/ loadfactor=1 route=route2
# byrequests / bytraffic / bybusyness
# ProxySet lbmethod=bytraffic
</Proxy>
ProxyPass /hra-space balancer://HRaCluster/hra-space stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hra-space balancer//localhost:52085/hra-space
ProxyPassReverse /hra-space balancer//localhost:52095/hra-space
ProxyPass /hr-dms balancer://HRaCluster:52083/hr-dms stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-dms balancer//localhost:52085/hr-dms
ProxyPassReverse /hr-dms balancer//localhost:52095/hr-dms
ProxyPass /hr-rich-client balancer://HRaCluster:52083/hr-rich-client stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-rich-client balancer//localhost:52085/hr-rich-client
ProxyPassReverse /hr-rich-client balancer//localhost:52095/hr-rich-client
ProxyPass /hr-portlets balancer://HRaCluster:52083/hr-portlets stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-portlets balancer//localhost:52085/hr-portlets
ProxyPassReverse /hr-portlets balancer//localhost:52095/hr-portlets
ProxyPass /hr-self-service balancer://HRaCluster:52083/hr-self-service stickysession=JSESSIONID|jsessionid nofailover=OnProxyPassReverse /hr-self-service balancer//localhost:52085/hr-self-service
ProxyPassReverse /hr-self-service balancer//localhost:52095/hr-self-service
ProxyPass /hr-configuration-tool-web balancer://HRaCluster:52083/hr-configuration-tool-web stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-configuration-tool-web balancer//localhost:52085/hr-configuration-tool-web
ProxyPassReverse /hr-configuration-tool-web balancer//localhost:52095/hr-configuration-tool-web
ProxyPass /hr-admin-console balancer://HRaCluster:52083/hr-admin-console stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-admin-console balancer//localhost:52085/hr-admin-console
ProxyPassReverse /hr-admin-console balancer//localhost:52095/hr-admin-console
ProxyPass /hr-online-query balancer://HRaCluster:52083/hr-online-query stickysession=JSESSIONID|jsessionid nofailover=On
ProxyPassReverse /hr-online-query balancer//localhost:52085/hr-online-query
ProxyPassReverse /hr-online-query balancer//localhost:52095/hr-online-query
ProxyTimeout 300
Coté Objet Site HRS
Créer une seconde fonction "Serveur Web" pour pouvoir accéder au second Tomcat sur la console d'administration Web de HRaSpace (je vois que l'on peut créer des "Cluster" de serveur Web mais je n'en connais pas les implications ... A tester).Pour finir
- Un lien sur la doc Apache :http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
- Noter que le "balancer" Apache a sa propre console : http://mon.serveur.apache:52000/balancer-manager
- Vous pouvez tester la répartition en altérant le loadfactor puis en contrôlant avec la console ou par consultation des logs sur quel Tomcat vous êtes redirigé.
Avec la clause "nofailover=on" l’utilisateur qui pointe sur un Tomcat arrêté se voit retourner une erreur.
RépondreSupprimerJ'ai du placer "nofailover=off" pour que Apache inhibe les Tomcats indisponibles et déroute automatiquement les requêtes.
Dans le cas de HRaSpace et de ses multiples applications (Rich Client, Self-service, ...), le stickysession=JSESSIONID peut être a la source d'erreurs "User not connected" (si Apache a choisi deux Tomcats différents pour deux applications HR différentes). Un stickysession basé sur la "route" choisie sera plus fiable :
RépondreSupprimerHeader add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
BalancerMember ajp://localhost:52085/ loadfactor=1 route=route1
BalancerMember ajp://localhost:52095/ loadfactor=1 route=route2
...
ProxySet stickysession=ROUTEID
# stickysession=ROUTEID means a user will stay on the same Tomcat for all applications
# nofailover=Off means Tomcat should failover and Apache redirects
ProxyPass /hra-space balancer://HRaCluster/hra-space stickysession=ROUTEID nofailover=Off
ProxyPassReverse /hra-space balancer//localhost:52085/hra-space
ProxyPassReverse /hra-space balancer//localhost:52095/hra-space
ProxyPass /hr-dms balancer://HRaCluster:52083/hr-dms stickysession=ROUTEID nofailover=Off
ProxyPassReverse /hr-dms balancer//localhost:52085/hr-dms
...
Suite aux dernières analyses de Michel, il a été décidé de modifier le paramétrage du "BalancerMember" :
RépondreSupprimer- augmenter fortement le "timeout" pour éviter qu'un Tomcat soit déclaré "en erreur" du fait d'une transaction HRAccess trop longue,
- réduire fortement le "retry", car durant cet intervalle les utilisateurs restent en attente,
- remettre en place nofailover=on et si besoin gérer manuellement la redirection sur un Tomcat valide.