Tomcat load balancing – mod_proxy vs mod_jk le match
Dans notre article sur l'utilisation de HTTPS avec Tomcat en production, nous avons étudié les solutions reposant sur la mise en place d'un reverse proxy HTTP. Nous n'avons pas oublié pour autant le protocole AJP. Ce protocole est né pour faciliter et accélérer les communications entre un serveur web frontal et le serveur d'application JServ en back-end d'Apache. Avec le temps, Tomcat a remplacé Apache JServ mais AJP est resté. Jusqu'en 2003, AJP était la seule solution viable permettant de placer le serveur d'application derrière un serveur Apache. Avec la maturation de la fonctionnalité Proxy dans Apache est née la solution tout HTTP. Nous avons donc décidé d'organiser un match opposant la solution AJP à la solution HTTP.
Un peu d'histoire
Tout commence en 1997 avec la création d'Apache JServ. A l'époque, il s'agit d'un serveur de Servlet qui supporte uniquement le protocole AJP créé pour l'occasion. Dans l'architecture initiale, c'est Apache 1.1 qui fournit le serveur web et transfère les requêtes par socket au moteur de Servlet. C'est la naissance du protocole AJP dans sa première version implémentée par le mod_jserv. L'Apache JServ Protocol fonctionne au départ comme un proxy qui redirige le flux vers JServ. Le protocole est en texte clair et utilise un caractère en début de ligne pour distinguer les différents éléments de la requête.
Rapidement, le protocole initial est considéré comme trop limité car il fonctionne uniquement en loopback et possède une authentification pauvre. En 1998, le protocole AJP 1.1 permet à JServ de tourner sur une autre machine que le serveur web et d'assurer une authentification forte basée sur md5. Avec le développement de JServ appparaît un problème de performance important : le coût d'ouverture d'une socket et la vitesse des réseaux. Ils sont considérés à l'époque comme les principaux goulets d'étranglement. Pour résoudre ces problèmes, le protocole passe à la version 1.2 dont vous trouverez le draft initial ici. AJP 1.2 est un protocole binaire orienté paquets qui permet de recycler la ou les sockets connectées à JServ. Le passage au binaire permet aussi d'améliorer les performances car il diminue la taille des données qui transitent et simplifie le traitement.
En 1999, Sun offre son implémentation de référence des Servlets à la fondation Apache. C'est le point de départ des projets Tomcat et Ant. Commence alors une période de transition qui finira par l'abandon d'Apache JServ. Pendant cette transition, AJP sera porté sur Tomcat qui bénéficiera d'emblée d'une facilité d'interconnexion avec Apache. Aux alentours de 2000, le mod_jk est développé pour étendre AJP qui pourra supporter le transport des données SSL. C'est la version 1.3 que l'on retrouve aujourd'hui supportée par les dernières générations de Tomcat. Après toutes ces années de développement, le mod_jk est maintenu par le projet Tomcat Connectors et n'a jamais été intégré aux projets Apache.
La création d'AJP résulte donc de la simplicité et de la rapidité de développement souhaitées par les auteurs. Il fallait aller vite, et implémenter un proxy pleinement compatible HTTP aurait été trop long. Le module mod_proxy existe depuis 1996 dans Apache 1.1. Mais il s'agissait d'une fonctionnalité expérimentale qui n'offrait ni performance ni stabilité. A la sortie d'Apache 2, le proxy a même été dé-scopé car il ne fonctionnait plus du tout. Les développeurs vont pourtant rapidement le corriger et le réintégrer comme solution pour faire des reverse proxies. Pour la sortie d'Apache 2.2, le mod_proxy est entièrement réécrit pour supporter le load-balancing. Il offre, pour la première fois dans Apache, une solution capable de concurrencer le mod_jk en performance et en scalabilité. Cerise sur le gâteau, Apache a décidé de supporter nativement le protocole AJP en ajoutant un mod_proxy_ajp à la solution mod_proxy.
Installation
mod_proxy
Le mod_proxy fait partie de la distribution standard d'Apache HTTPD. Il est livré avec le mod_proxy_http, le mod_proxy_ajp et le mod_proxy_balancer. Il suffit donc de s'assurer que ces modules sont bien chargés au démarrage d'Apache.
mod_jk
Si mod_jk était autrefois très délicat à installer avec la compilation du code sur un serveur similaire au serveur cible, la situation s'est grandement simplifiée. Le projet Apache Tomcat Connector fournit désormais les binaires pour les principales plateformes (Linux, Windows, Free BSD, Mac, Solaris, AIX, etc). Il faut donc télécharger le binaire du module et le copier dans le répertoire contenant les modules Apache.
Configuration
Pour mieux comparer les deux solutions, nous avons choisi de prendre comme exemple l'utilisation d'Apache en front desservant deux Tomcat en load-balancing. Nous ne nous intéresserons ici qu'à la configuration d'Apache HTTPD. La configuration AJP de Tomcat étant déjà largement documentée sur le web et celle via HTTP dans nos articles précédents, nous n'aborderons pas ces problématiques.
mod_proxy_http & mod_proxy_balancer
La configuration du mod_proxy consiste d'abord à s'assurer que les modules soient bien chargés avec les directives LoadModule. Nous activons ensuite le server-status ainsi que le balancer-manager pour obtenir une interface de surveillance / administration du load-balancer. Enfin, nous avons configuré le Proxy balancer nommé my-application-cluster pour contenir nos 2 serveurs Tomcat. La dernière ligne de configuration active le reverse proxy pour que les requêtes sur /my-application soient redirigées vers le /my-application du load-balancer.
Configuration avec mod_proxy_http & mod_proxy_balancer - httpd.conf
LoadModule proxy_module libexec/apache2/mod_proxy.so
LoadModule proxy_http_module libexec/apache2/mod_proxy_http.so
LoadModule proxy_balancer_module libexec/apache2/mod_proxy_balancer.so
# STATUS AND MONITORING
# Display proxy balancer status in /server-status page
ProxyStatus On
<Location /server-status>
SetHandler server-info
Order deny,allow
Deny from all
Allow from localhost
</Location>
<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from localhost
</Location>
# APPLICATIONS CONFIGURATION
<Proxy balancer://my-application-cluster>
BalancerMember http://node-1:8080 route=node-1 disablereuse=On
# ...
BalancerMember http://node-n:8081 route=node-n disablereuse=On
</Proxy>
ProxyPreserveHost On
ProxyPass /my-application balancer://my-application-cluster/my-application stickysession=JSESSIONID
Vous pouvez le constater, la configuration est parfaitement intégrée à la configuration standard d'Apache HTTPD. Les équipes de production n'auront à priori pas de grandes difficultés à prendre en main ce type de configuration qui nécessite seulement de savoir parcourir la documentation Apache déjà bien connue des administrateurs.
mod_jk
La première étape consiste à configurer le serveur Apache pour qu'il utilise le mod_jk. Tout commence par le chargement du module avec la directive LoadModule. Ensuite nous fournissons le chemin du deuxième fichier de configuration définissant les workers. La directive JkMount permet ensuite d'associer un worker du mod_jk à un pattern d'url du serveur. Pour chaque requête dont l'URL correspond au pattern, Apache va déléguer le traitement au mod_jk. Nous montons d'abord le worker jkstatus sur /jkmanager en autorisant l'accès uniquement depuis le système local. C'est ensuite au tour du loadbalancer qui servira notre application.
Configuration avec mod_jk - httpd.conf
LoadModule jk_module libexec/apache2/mod_jk.so
# MOD_JK CONFIGURATION FILE
JkWorkersFile /etc/apache2/other/workers.properties
# MOD_JK PROPRIETARY LOG FILE
JkLogFile /var/log/apache2/mod_jk.log
# NEEDED ON MAC SNOW LEOPARD
JkShmFile /var/log/apache2/
# STATUS AND MONITORING
JkMount /jkmanager/* jkstatus
<Location /jkmanager>
Order deny,allow
Deny from all
Allow from localhost
</Location>
# APPLICATIONS CONFIGURATION
JkMount /my-application/* loadbalancer
Il faut maintenant configurer le mod_jk proprement dit dans son fichier de configuration spécifique. Il s'agit d'une liste de propriétés commençant toujours par worker.. La propriété worker.list fournit les noms des workers actifs. Le nom est ensuite utilisé pour paramétrer le worker avec des clés de la forme worker.nomWorker.parametre. Le premier worker activé jkstatus utilise le type spécial status qui correspond à l'interface de suivi et de gestion du mod_jk. Le deuxième worker loadbalancer est en fait chargé de répartir les sessions entre le worker1 et le worker2 via le type lb. Ce sont finalement les workers 1 à n qui assurent le transport des requêtes sur AJP1.3 vers le port 8009 d'un Tomcat distant.
Configuration avec mod_jk - workers.properties
worker.list=jkstatus, loadbalancer
# STATUS AND MANAGEMENT PSEUDO WORKER
worker.jkstatus.type=status
# WORKER 1 TO N
worker.worker1.type=ajp13
worker.worker1.host=node-1
worker.worker1.port=8009
# ...
worker.worker2.port=8009
worker.worker2.host=node-n
worker.worker2.type=ajp13
# LOAD BALANCER PSEUDO WORKER
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=worker1,worker2
Avec ses deux fichiers de configurations séparés et la syntaxe "rustique" du worker.properties, la configuration est définitivement le point faible du mod_jk. L'un des seuls avantages réside dans le nombre impressionnant de paramètres supportés qui permet un paramétrage fin si le besoin s'en fait sentir. Si seulement nous n'étions pas forcés à tant de verbosité !
Interfaces graphiques
Les deux modules fournissent des interfaces web pour assurer la supervision du load-balancer. Cette fois, le mod_proxy se contente de fournir des statistiques réduites dans une interface minimaliste. L'interface liste principalement le statut de chaque nœud du load-balancer ainsi que la quantité de données envoyée et reçue par nœud.
Outre le suivi des statistiques du load-balancer, le Balancer Manager permet aussi de faire des modifications à chaud, éditer les workers, les passer en offline, voire même changer la méthode de répartition utilisée.
De son côté, le mod_jk prouve sa maturité avec son interface rustique elle aussi, mais plus voire trop complète. Elle est composée de plusieurs pages dont une page d'accueil similaire en tout point à l'interface du mod_proxy. L'avantage réside dans la fourniture d'une page détaillant l'état complet pour chaque nœud.
Mais le mod_jk ne se contente pas de cela : il fournit aussi une page permettant de modifier à chaud la configuration du load-balancer. Il est parfaitement envisageable pour le déploiement en production d'une nouvelle version de l'application de couper les nœuds un à un au moment de leur mise à jour puis de les réactiver sans interruption du service.
Attention toutefois, car les modifications faites par ce biais sont uniquement enregistrées en mémoire, la nouvelle configuration sera perdue au prochain redémarrage d'Apache.
La mince différence vient probablement de la jeunesse de la solution de load-balancing du mod_proxy face à la longue expérience de production du mod_jk. Mais elle ne saurait justifier une préférence pour l'un des deux modules, qui sur ce point sont très proches.
LoadBalancing et gestion d'erreur
Outre la configuration et l'interface graphique, les deux solutions disposent de quelques fonctions avancées notamment en ce qui concerne la gestion d'erreur et la gestion des sockets réseaux. Les deux modules utilisent des pools de connexion rangés par Thread du serveur Apache et par membres du cluster.
Avec le mod_proxy, il est possible de choisir parmi trois algorithmes de répartition de charge :
- Par requête : la charge est répartie pour chaque requête entrante en fonction de la session si elle existe.
- Par trafic réseau : les requêtes sont envoyées vers le membre du cluster ayant reçu le moins de trafic.
- Par taux d'occupation : la charge est répartie en fonction du nombre de requêtes en cours de traitement ou en attente.
En ce qui concerne la gestion d'erreur, il n'y a pas grand chose à dire car il n'y a pas grand chose de fait. Si un timeout claque, un certain nombre de tentatives de reconnexion seront réalisées jusqu'à ce que le noeud soit marqué en erreur et n'en décolle plus.
C'est sur la gestion d'erreur que le mod_jk possède une plus grande sophistication que son récent concurrent.
Tout d'abord le protocole AJP fournit un mécanisme de health check (CPing/CPong) qui permet de tester l'état du lien entre le serveur frontal et un membre du cluster. Cependant, c'est beaucoup plus limité que les heart beat des load balancer hardware, il n'est pas possible de tester une url pour détecter des indisponibilités applicatives (échec de démarrage de la web app, web app KO à cause de l'indisponibilité d'un backend clef).
D'autre part, le module fait une distinction entre les erreurs locales temporaires qui sont sans impact particulier, un code d'erreur HTTP par exemple, et les erreurs globales qui indiquent que le serveur est clairement en erreur et ne recevra plus de nouvelles requêtes. Il existe un système d'escalade qui, en cas de répétition trop fréquente d'erreurs locales sur un noeud se charge de le passer en erreur globale. Le module se charge de réactiver le noeud en mode recovery après un délai paramétré.
Côté répartition de charge, mod_jk apporte un dernier algorithme de répartition reposant sur le nombre de sessions HTTP en cours par serveur. Cette méthode est relativement récente puisqu'elle est apparue dans la version 1.2.20 du mod_jk, actuellement en version 1.2.29. Elle est recommandée pour les applications chargeant fortement la session et de ce fait, supportant un nombre limité de sessions par serveur ; ce cas d'utilisation est assez marginal.
Dans les deux modules, l'algorithme de répartition est pondéré par un facteur nommé "lbfactor", qui permet d'appliquer des quotas de travail aux serveurs. Ce système s'avère utile si les serveurs sont de puissances différentes par exemple.
Le mod_jk marque ici un petit point sur le mod_proxy grâce à sa gestion d'erreur plus fine. Attention aux effets de bord, le retry sur timeout en a surpris plus d'un et l'éviction de serveurs tomcat pour cause de répétition d'erreur est un beau sujet de déni de service 
Pour le reste, le mod_proxy colle au fonctionnement du mod_jk, ce qui ne manquera pas de faciliter son utilisation aux habitués du mod_jk.
Exploitation et diagnostic des problèmes
mod_proxy_http présente sur mod_jk le très grand avantage d'utiliser un protocole standard, HTTP, connu de tous les acteurs d'un système d'information alors que mod_jk repose sur le protocole AJP que quasiment personne ne connait. Les administrateurs systèmes et réseaux sont habitués à HTTP et notamment à ses connections persistantes (aka HTTP keepAlive) ; ils savent ajuster leurs algorithmes de load balancing, les timeouts des firewalls et le dimensionnement des piles tcp/ip des serveurs (ulimit, tcp_keepalive_intvl, tcp_tw_bucket, etc).
Un autre atout de mod_proxy est la facilité de diagnostic. N'importe quel acteur du système d'information peut utiliser curl, wget, telnet, elinks voire wireshark pour troubleshooter un problème de communication HTTP; ce n'est pas le cas avec le protocole AJP qui n'est pas human readable et encore moins human writable. Choisir AJP mérite de former les administrateurs systèmes et réseaux et de prévoir des outils de tests permettant de requêter un connecteur AJP mais ce n'est hélas que très rarement fait.
En cas de problème réseau avec HTTP comme avec AJP, n'oubliez pas que désactiver les connections persistantes simplifie grandement les investigations et n'a rien de scandaleux en 2010 (cf HAProxy) ; c'est "disablereuse=On" pour mod_proxy_http et "JkOptions +DisableReuse" pour mod_jk
Conclusion
Avec sa simplicité de configuration, sa répartition de charge calquée sur le mod_jk, le mod_proxy conviendra parfaitement dans la grande majorité des cas. Il s'accommode de clusters répartissant la charge sur plusieurs noeuds ou bien en tant que simple reverse proxy. La cerise sur le gateau étant l'utilisation du protocole HTTP qui permet de garantir la portabilité des services et facilite grandement l'analyse du trafic.
A nos yeux, avec l'intégration native de mod_proxy_http et mod_proxy_balancer à Apache, il n'y a plus de justification à ajouter le module additionnel mod_jk ni d'introduire le protocole méconnu AJP. Les optimisations d'AJP ne sont plus de mise aujourd'hui et ne justifient donc pas l'utilisation d'un mod_jk.
Il reste, dans les deux cas, quelques efforts à faire pour permettre de plus facilement monter des serveurs à chaud dans un cluster. Pour la haute disponibilité sans perte, il faudra mettre en place un cluster Tomcat assurant la réplication des sessions utilisateur entre les serveurs. Encore faut-il en avoir vraiment besoin ...
Attention, la recommandation de Tomcat est encore le mod_jk et, il est important de garder fonctionnel ce qui marche déjà. Donc, quoiqu'il arrive, si vous avez déjà une solution fonctionnelle avec le mod_jk, inutile de migrer. Pour ce qui est de l'interface et de la gestion d'erreur, nous parions sur l'avenir du mod_proxy qui est en développement intensif et bénéficie des corrections de bug de son ainé. Reste un nouveau venu dans le paysage développé par Jboss qui attire déjà notre attention c'est le mod_cluster actuellement, il n'est utilisable qu'avec Jboss AS. L'avantage de cette nouvelle solution en devenir est de suivre le cycle de vie des applications via un protocole spécifique MCMP reposant tout de même sur HTTP.
Billets sur le même thème :
- Tomcat : Adresse IP de l’internaute, load balancer, reverse proxy et header Http X-Forwarded-For
- Sécuriser Tomcat 5 derrière un proxy Apache 2 HTTPS
- Tomcat, SSL, communications sécurisées et X-Forwarded-Proto
- SpringOne 2009 – Sécurisation d’Apache Tomcat
- Devoxx – Jour 1 – Applications robustes avec Amazon EC2
J'ai lu attentivement et avec intérêt cet article, qui montre une véritable connaissance de ses problematiques de connectivité HTTPd / Tomcat.
Quelques commentaires quand même :
- ajp n'est pas un protocol si méconnu, il est présent dans jetty mais aussi dans la liste des dissecteurs de l'analyseur de réseau Wire Shark.
- jk garde l'avantage pour les configurations clusters complexes. Vous avez d'ailleurs bien présenté l'interface de configuration du routage, certes rudimentaire mais bien pratique.
- mod_cluster pourrait être utilisé avec des Tomcat, JBoss As utilisant une version de Tomcat proche du Tomcat standard.
- Longtemps l'objection contre mod_jk était qu'il devait être compilé, mais les binaires Win32/64 et OS/X sont disponibles sur le site. Pour les Linux c'est présent dans la plupart des distributions.
Pour finir l'avenir passera par un module qui saura détecter la topologie dynamique des membres du cluster, leur capacité, leur charge afin d'assurer un routage pertinent et automatique. mod_cluster est une bonne piste de départ.
@Henri,
> ajp n'est pas un protocole si méconnu ...
La spécification d'AJP 1.3 est déconcertante, ça relève de l'archéologie
"Everything in this document is derived from the actual implementation I found in the tomcat 3.x code. I hope it is useful, but I can't make any grand claims to perfect accuracy". On est bien loin de la rigueur des RFC du protocole HTTP.
Mon expérience personnelle n'a pas été meilleure. Je n'ai peut être pas eu de chance mais je n'ai jamais trouvé sur un projet des gens qui connaissaient AJP ; par connaitre, j'entends plus que "savoir que ca existe".
A l'inverse, j'ai travaillé avec beaucoup de personnes très à l'aise avec HTTP, des personnes qui n'avaient aucune difficulté à utiliser telnet ou un tcpdump pour troubleshooter une communication défaillante.
J'ai l'impression que le niveau de maitrise d'AJP sur les mailing lists Tomcat n'est pas tellement meilleur.
Pour l'outillage, je me sens très impuissant avec AJP, je ne connais aucun client de requêtage équivalent aux
.
telnet,curletelinksque j'utilise communément pour http. J'ai quand même une lueur d'espoir, un clientajpgetfigure en 5ème point de la TODO list> clusters complexes, mod_jk et mod_cluster
Même s'il offre plein de paramètres très savants, mod_jk ne répond ni mieux ni moins bien que mod_proxy_balancer à mes attentes de clustering. J'aimerais avoir :
1) un graceful shutdown (aka session draining) de chaque noeud pour ne pas couper les sessions en cours,
2) un progressive startup pour laisser mon application s'initialiser en douceur plutôt que d'avoir un démarrage en "burst" et des énormes à-coup sur la répartition des sessions,
3) pouvoir scripter ces graceful shutdown et progressive startup,
4) monitorer l'équilibrage de mes load-balancers avec Hyperic HQ.
Aujourd'hui, Zeus Load Balancer serait ma première piste mais il complexifierait sensiblement mon architecture (ne se substitue pas à un serveur Apache, demande un nouveau savoir faire, etc). Mod_cluster est sur la bonne voie mais il me semble encore très jeune, sa documentation est pour le moins spartiate
Cyrille (Xebia)
@Henri,
> avenir, détecter la topologie, ...
Je rêverai encore plus loin que vous : une Java Platform as a Service (1) ! Un deployment manager installerait mon war sur plusieurs noeuds de ma grille avec exactement les versions de JVM et de serveur Java que je demande.
JBoss App Server, JBoss ON & mod_cluster
Techniquement, JBoss a beaucoup de cartes en main avec mod_cluster et JBoss App Server 5 dont l'administration est très intégrée à JBoss ON. Il n'y a quasiment plus qu'à assembler les éléments entre eux.
Opérationnellement, JBoss a encore plus de cartes en main : ils sont déjà dans tous les data centers avec RHEL, RHN Satellite et/ou JBoss App Server.
Vont-ils remporter la mise pour autant ? Hélas, j'attends plein d'annonces que ne viennent pas
.
Quand l'agent JBoss ON pourra-il déployer les binaires d'une nouvelle version de JBoss AS et d'une nouvelle JVM ?
Quand seront disponibles les docs sur le scripting de mod_cluster ?
Quand pourrais-je écrire un script de déploiement phasé d'une nouvelle version de mon war ? Je voudrais "pour chaque noeud : graceful-shutdown-mod_cluster + undeploy + deploy + test-d-url + progressive-startup",
Quand JBoss ON m'offrira des démarrages & arrêts automatiques de noeuds sur mes clusters ? Je voudrais "si la charge CPU sur les noeuds du cluster > 60% alors démarrer l'application sur un noeud de réserve"
Prabhakar Gopalan, JBoss ON product manager, est conscient qu'il a de l'or dans les mains mais je n'ai pas l'impression qu'il soit aidé par les stars de JBoss. Stars qui travaillent toujours sur des frameworks et standards Java certes très intéressants mais peut être moins stratégiques que de coiffer au poteau SpringSource dans la course de Java Platform as a Service.
SpringSource tc Server, Hyperic et mod_proxy_balancer
SpringSource avec tcServer a aussi pour but de déployer facilement des applications java clusterisées mais leurs fonctionnalités ont probablement plus de 6 mois de retard sur JBoss.
Bien qu'Hyperic soit le produit original, ses fonctionnalités de déploiement sont en retard sur celles de son fork JBoss ON / RHQ.
C'est pareil pour le load balancer : SpringSource mise sur mod_proxy_balancer qui est lui aussi en retard mod_cluster que soutient JBoss.
Et plus difficile encore, SpringSource est très discret dans les data centers ; Hyperic HQ commence à peine à creuser sa place et tout reste à faire pour tcServer.
Malgré cela, SpringSource est beaucoup plus présent que JBoss sur la scène du Java Platform as a Service notamment avec le rachat de Cloud Foundry qui leur permet de surfer sur la notoriété d'Amazon EC2.
En conclusion, mon rêve de "Java Platform as a Service" est très ambitieux et je ne sais pas qui sera le vainqueur de la première manche
Cyrille (Xebia)
(1) cf Pourquoi VMWare / SpringSource ? Virtualisation matérielle vs. Cloud
Un deployment manager installerait mon war sur plusieurs noeuds de ma grille avec exactement les versions de JVM et de serveur Java que je demande.
Quand pourrais-je écrire un script de déploiement phasé d'une nouvelle version de mon war ? Je voudrais "pour chaque noeud : graceful-shutdown-mod_cluster + undeploy + deploy + test-d-url + progressive-startup"
Avec Deployit - Automated deployment for Java applications !, tu peux facilement assembler toutes ces phases dans un plugin et d"ployer sur l'ensemble des nœuds de ton environnement.
Benoit (Xebia)
Et si vous veniez discuter de tout ça sur Tomcat-dev ?
Il y a des commiters, dont votre serviteur, qui serait très content d'échanger voir réfléchir à tous ces points.
Je vous accorde le point qu'AJP n'est pas le meilleur protocol en terme de définition, norme et documentation.
C'est aussi pour ça que j'avais fait des propositions et add-on comme le cping/cpong.
Si vous remontez dans les archives vous pourrez voir que le sujet de la pondération du routage par collecte des infos de charge OS/webapp (voir back end DB) a été évoqué plus d'une fois.
Mais vous avez déjà un des éléments de réponses à l'absence de certaines fonctionnalités dans JK, SpringSource et JBoss ont des commiters dans les projets Tomcat mais chacun avec des objectifs propres.
A très bientôt donc sur Tomcat-dev pour discuter de tout ça !
Je ne comprend décidément pas la conclusion. Autant il est positif d'avoir un protocole plain-text, compréhensif, répandu, autant il n'est pas raisonnable d'espérer avoir avec le mod_proxy, le même niveau de fonctionnalités qu'avec le protocole AJP.
En effet, les informations circulant entre Apache et Tomcat ne relèvent pas toutes du niveau applicatif (HTTP). Entre autres :
- les informations concernant les erreurs et les ressources disponibles côté tomcat, comme vous le dites très justement;
- si la connexion client-Apache est en HTTPS avec certificats clients, les informations du certificats (comme je l'ai déjà dit dans un précédent commentaire : http://blog.xebia.fr/2009/09/23/securiser-tomcat-5-derriere-un-proxy-apache-2-https/#comment-15299).
Pour ajouter ces informations supplémentaires, comme le mod_proxy se base sur le connecteur coyote (HTTP) classique de Tomcat, aucun information non standard n'est connue. Si on veut utiliser les informations qui ne sont pas de base en HTTP, il faut :
- tunneler ces informations dans le HTTP (via des headers HTTP "X-...") ;
- analyser ces informations côté Tomcat soit par un déploiement de Valves, pour que ce soit transparent applicativement, soit justement faire une interprétation applicative.
En conclusion, dès qu'on a des besoins un tant soit peu complexe, il faut mettre en place des verrues pour utiliser le mod_proxy.
Personnellement, je n'ai pas rencontré un projet où l'on utilise le mod_proxy, pour lequel il n'y a pas eu besoin de faire des développements spécifique, uniquement à cause du mod_proxy.
A mon sens, le mod_proxy ne peut pas être une solution industrielle.
Benoît
@Benoit D,
Il ne me semble pas rédhibitoire d'utiliser des headers http (X-Forwarded-For, X-Forwarded-Proto, etc) pour propager des informations collectées en amont de mes serveurs Tomcat. C'est notamment utilisé par les load balancers dédiés (e.g. Alteon, Big-IP, HAProxy, Zeus), les proxy cache (e.g. Squid) ou les accélérateurs SSL mais aussi par des gros serveurs Java EE comme Websphere ou Weblogic.
Je conviens que cela nécessite de nettoyer les headers http à l'entrée des data centers mais je ne vois hélas pas d'alternative.
Pour les projets qui utilisent industriellement mod_proxy, l'adoption est progressive et SpringSource, le plus gros contributeur Tomcat en ce moment le préconise et MuleSource est sur la même longueur d'onde.
.
A titre personnel, j'ai en tête au moins un portail d'opérateur télécom français qui l'utilise, ca se passe plutôt bien même si nous aimerions beaucoup avec un progressive startup ... qui n'est pas plus disponible dans mod_jk
Pour les situations complexes dont vous parlez, j'ai l'impression qu'il y a le plus souvent un load balancer hardware de niveau 7 suivi d'une couche de serveurs web et seulement après nos serveurs Java.
Si le load balancer hardware intervient au niveau 7, c'est lui qui doit transmettre les informations comme l'adresse ip de l'internaute, le protocole utilisé (http/https), le certificat ssl client utilisé, etc ; dans ces situations qui utilisent une communication http, je pense aux headers X-Forwarded-For, X-Forwarded-Proto ou X-Client-Cert.
.
Les deux premiers sont déjà traités dans Tomcat avec RemoteIpValve, il ne nous reste qu'à apporter l'intégration des certificats SSL clients
Pour revenir à AJP et mod_jk, si mon serveur Apache Httpd est précédé d'un load-balancer ou un firewall de niveau 7, je ne vois pas comment il est possible de récupérer l'adresse IP de l'internaute sauf à utiliser mod_remoteip qui n'est disponible que sur Apache 2.3.5-alpha ; pour ssl, ai-je d'autre solution que des headers http ?
En revanche, si je peux me dispenser de composants réseau de niveau 7 en amont des Apache, je conviens que mod_jk permet plus facilement que mod_proxy_http
de récupérer ces informations. Hélas, ca n'a pas été le cas sur mes projets ces dernières années.
Cyrille (Xebia)
Je plussoie sur les remarques de Benoit.
D'après ma (petite) expérience, le choix de modproxy est toujours effectué par des architectes sous des prétextes de sécurité (DMZ ou protocole HTTP only) au détriment des problématiques de performance (eg : service des fichiers statiques par apache) et des fonctionnalités applicatives (eg : récupération des IPs clients).
Je pense effectivement que modproxy peut se justifier pour certaine applications dédiées (crée pour cette architecture) ou le besoin fonctionnelle est limité. Mais je reste persuadé que modjk est plus riche et plus adapté pour les applications complexes.
@Cyrille Le Clerc
Je n'ai rien contre l'usage des "X-Forwarded-For", "X-Forwarded-Proto", qui sont des headers "standards" (de fait en tout cas) des reverses proxies.
Ce que je n'aime pas, c'est d'ajouter des informations non standard adhérentes spécifiquement à l'architecture HTTPD/mod_proxy/Tomcat. Et du coup, mettre du code spécifique en plus de part et d'autre.
(Il y a eu une erreur de DB lors de mon premier submit, désolé si le commentaire apparait en double)
@Olivier
Pour la performance, les différents benchmarks AJP vs. HTTP disponibles sur internet montrent qu'il n'y a pas grande différence. Si HTTP avait des problèmes de performances, j'imagine que Weblogic et Websphere auraient conservé leur protocoles propriétaires plutôt que de l'adopter.
Pour le service des ressources statiques, je préfère parler de ressources cachables et recourir à un proxy cache (Squid, mod_cache, etc) avec des headers
ExpiresetCache-Controlbien positionnés. Je travaille actuellement sur un gros portail qui utilisemod_disk_cacheavec satisfaction (en complément d'un CDN). Cette approche est indépendante de AJP vs. HTTP pour connecter Apache à Tomcat.Pour les problématiques de récupération des IP clientes, si le serveur Apache est précédé d'un load-balancer ou un firewall de niveau 7, AJP aura autant besoin de X-Forwarded-For que HTTP.
Cyrille
@Benoit D,
Je vous rejoins sur le problème du standard de ces headers liés à SSL :
* F5 BIG-IP émet SSLClientCertStatus, SSLClientCertSN et SSLClientCertb64
* Weblogic consomme WL-Proxy-Client-Cert et WL-Proxy-SSL
* Websphere utilise un header configurable httpsIndicatorHeader et d'autres headers spécifiques que je n'ai pas eu le temps de trouver dans les docs.
* Microsoft Internet Security & Acceleration (ISA) émet Front-End-Https
* X-Client-Cert
* ...
Tout le monde propose une solution à base de header http, c'est incontournable lorsque SSL est déplié par un load balancer dédié ou des accélérateurs SSL.
Après, Squid a réussi à imposer le standard de-facto "X-Forwarded-For", nous pouvons suivre le conseil d'Henri rejoindre la mailing list Tomcat pour intégrer l'envoi de certificat client par header http et promouvoir un nom de header
.
Cyrille
Merci Cyrille pour ces précisions.
Effectivement il existes d'autre alternative pour résoudre les problématiques de performances. Mais comme c'est justement là que mod_jk tire toute sa richesse; bien configuré il se suffit à lui même !
Pas besoin de configurer d'autre module pour obtenir de bonne performance, pas besoin de faire de développement spécifique pour récupérer les IPs, idem pour le SSL...
Juste par curiosité, sauriez-vous me donner un pourcentage de projets dans lesquelles vous avez mis en oeuvre des loadbalancer de niveau 7 ? Quel était le besoin ?
@Olivier,
Pour l'amélioration des performances en optimisant les flux, le projet Chromium - SPDY: An experimental protocol for a faster web mené par Google changera peut être les lignes de front.
Pour les environnements dans lesquels j'ai ou des collègues ont utilisé des load balancers de niveau 7 en amont des serveurs web, j'ai en tête :
),
* les portails grand public et gateway web services de deux des trois grand opérateurs telco français,
* deux grandes banques françaises en intranet et site web grand public (HAProxy n'est pas très éloigné de l'une d'elle
* une compagnie d'assurance,
* Une radio nationale,
* ...
> Quel était le besoin ?
La haute disponibilité d'un load balancer hardware en single point of failure, l'accélération SSL, le firewalling http (URL malicieuses, DOS, audit, etc) et la culture des équipes réseaux qui aiment beaucoup les load balancers hardware.
Quelle solution de load balancing hautement disponible placée en single point of failure avez vous en tête ?
Les approches non-hardware comme HAProxy sur un simple Linux me semblent très intéressantes mais je n'ai jusqu'à présent jamais trouvé d'équipe réseaux réceptives, l'image de fiabilité d'un appliance rassure énormément.
Cyrille
Bonjour,
merci pour ce post et dont je partage les conclusions(nous avons jk 1.2.27 en prod)
juste une question cependant
as tu a un lien sur le session draining ?
Quelle difference avec le status disabled de noeuds en jk
Cordialement
Marc Godin
Bonsoir,
en ce qui concerne les performances je n'ai pas constaté de problèmes majeur sur mon projet actuel lié à mod_proxy. Il est vrai que l'optimisation si besoin passe par l'utilisation de différents modules apache comme mod_expires, mod_disk_cache et le mod_deflate, mais c'est a priori le standard Apache.
A priori, sortie de sa boite, ni Apache, ni Tomcat ne sont très optimisés. De plus, je me permet de rappeler que le moteur SSL d'Apache est bien plus performant que son homologue Java. Côté Tomcat pour la performance il faudra utiliser l'extension native: http://tomcat.apache.org/native-doc/.
Reste le problème des certificats en proxy SSL, et il existe une solution que nous avons volontairement ignoré jusqu'à maintenant. Il s'agit du mod_proxy_connect qui fournit la directive AllowConnect. Cette directive permet de forwarder purement et simplement le traffic SSL vers l'un des serveurs du load balancer. C'est justement la tendance habituelle à l'utilisation de headers HTTP pour communiquer les informations du clients initiale qui nous ont fait ignorer. Car finalement en observant ce qui se fait aujourd'hui en matière de proxy, nous avons pu constater que la norme est précisément d'utiliser des headers. Je reconnais bien volontier qu'il y a un flou artistique autour de cette question, mais il y a bel et bien des solutions, y compris sans développement spécifique.
@Marco,
Voici les liens que je connais sur le session draining / graceful shutdown :
Zeus : Zeus 6.0 User Manual - 11.2.5 Draining Connections et How can I remove back-ends from the cluster without disrupting sessions?.
mod_cluster : hélas, je n'ai rien trouvé dans la documentation si ce n'est cette mention sur un blog : mod_cluster 1.1.0 Beta1 released par Paul Ferraro (JBoss). La documentation est spartiate mais la fonction est disponible !
Pour le status : disabled, j'ai fait il y a quelques mois des essais avec mod_proxy_balancer qui hélas s'étaient soldés par un échec puisque plus aucune requête http n'est transmise à un noeud
.
disabled; passer leloadfactorà0n'a pas marché non plus car l'interface graphique interdit cette valeur.J'avais trouvé pour astuce de passer le
loadfactordu noeud que je voulais éteindre à1et celui de tous les autres noeuds à100; quasiment plus aucune nouvelle session n'était envoyée vers le noeud à éteindre mais ce n'est que de la bidouilleEn revanche, je n'ai pas testé le fonctionnement de mod_jk lorsqu'on
disableun noeud /worker.Cyrille
@Henri,
Merci pour l'invitation à exposer nos idées sur la mailing list Tomcat et pour y avoir cité ce billet.
J'y ai apporté ma modeste mais néanmoins chronophage contribution avec RemoteIpValve qui vient d'être disponible avec Tomcat 6.0.24 et pour lequel j'aimerais améliorer la documentation.
.
J'ai aussi récemment ouvert une discussion avec "JMX Client UnmarshalException with JmxRemoteLifecycleListener and useLocalPorts="true"" qui va vraisemblablement m'amener à me plonger dans l'utilisation de RMI par le JMXConnectorServer. Mais la perspective d'utiliser VisualVM au travers d'un tunnel SSH m'émoustille tellement
Ensuite, contribuer à la gestion dans Tomcat d'un header http portant le certificat X509 client pourrait être excitant, Séven semblait sur la même longueur d'onde cet après midi
.
Cyrille
Merci pour ta réponse,
pour le status disabled du modjk, pour le moment je dirait être a peu près sur du fonctionement(on ne se sert pas beaucoups de la possibilité de mettre en prod à chaud)
Par contre j'avais juste une remarque sur le modjk et la gestion d'erreur,
même si elle paraît assez complete elle gére seulement les codes retours http, planté sur un 404 ca oblige à verifié que personne n'a oublié un seule ressource même pas un css dans les webapps...
bilan,
il manque un la possibilité de tester un get de son choix
ce qu'offre par ex les LoadBalancer standards genre bigIP
Cordialement
Marc
Bonjour.
... ).
J'ai du rater quelque chose, mais pourquoi ne pas utiliser mod_proxy_ajp qui apporte finalement le meilleur de mod_proxy et de mod_ajp ? Tu en parles brièvement au début de l'article comme la "cerise sur le gateau", et puis ça disparait ...)
Personnellement, je n'utilise plus que mod_proxy_ajp depuis qu'il est intégré à apache 2.2 (cad, de puis longtemps. Je ne pensais pas que mod_jk était toujours utilisé
Ce que je reprochais particuliérement à mod_jk, c'est
- le fichier workers.properties unique qui ne permet pas de séparer les configurations des projets dans le cas d'un hébergement mutualisé.
- le fichier de log, là aussi commun à tous les projets.
@Marco,
Merci pour ce retour d'expérience.
La gestion d'erreurs de mod_jk me semble d'autant plus complexe à comprendre que certaines fonctionnalités à l'apparence "sexy" peuvent jouer de très mauvais tour.
* Le mécanisme de
.
retryqui réémet la requête vers un autre noeud du cluster en cas d'erreur de communication vers un premier noeud est trop optimiste et activé par défaut (retries: 2).Le fait qu'un timeout de réponse (
reply_timeout) soit éligible à un ré-essai, même sur des POST, m'a déjà causé des doubles appels inattendus* La désactivation de noeud de cluster sur exception peut causer des arrêts inattendus et être une faille importante de déni de service.
** Les mécanismes de Reply Timeout sont très délicats à gérer en cas de requêtes longues.
** L'invalidation d'un noeud sur code d'erreur (
fail_on_status) est séduisant mais difficile dans la réalité car si Tomcat retourne une 503 lorsqu'il redémarre, c'est en revanche une 404 lorsque le démarrage d'une web application a échoué. Qui oserait configurer 404 ou 500 comme causes d'arrêt d'un noeud de cluster ?Dans les faits, mon plus grand problème est qu'une webapp ne démarre pas pour un défaut de configuration et j'aimerais alors que Tomcat, plutôt que de retourner une erreur 404, s'arrête.
Même les erreurs 503 ne me satisfont plus depuis l'émergence de REST : 503 est un code intéressant pour exprimer qu'un service est indisponible parce qu'un backend est en maintenance. Cependant, un service indisponible ne signifie pas que la web app entière est indisponible.
Pour la page de healthcheck invoquée par des load balancer à la BigIP/Alteon, même si on peut en théorie faire des tests très sophistiqués, je me suis jusqu'à présent limité à des pages quasiment vides : je n'ai jamais pris le temps d'écrire des pages qui faisaient des vrais tests sans pour autant trop nuire aux performances.
Cyrille (Xebia)
@ Mike,
Merci pour ton complément.
Je te rejoins sur l'intérêt à l'unification des fichiers de configuration et de log qu'apporte mod_proxy par rapport à mod_jk. Nous avions oublié de parler des logs de mod_jk mais je me souviens avoir déjà complètement oublié que mod_jk avait son fichier spécifique et m'être focalisé sur un
.
error_logdésespérément vide alors quemod_jk.logpesait plusieurs Go ! Très vexantCependant, le point le plus décisif pour moi dans mod_proxy_balancer + mod_proxy_http est d'utiliser HTTP plutôt que AJP. Les gens connaissent, savent tester et savent tuner HTTP beaucoup plus que AJP.
Je prendrais presque ton contrepied en suggérant mod_proxy_http + mod_cluster pour bénéficier du session draining et de l'API de scripting de mod_cluster tout en utilisant HTTP
... quand la documentation de mod_cluster sera plus fournie 
.
Cyrille (Xebia)
Tout d'abord, un grand merci à Cyrille pour avoir assuré un service après-vente exceptionnel sur notre article.
Je me permet de te répondre aussi Mike pour la question du mod_proxy_ajp, si nous parlons du support AJP dans le début de l'article c'est surtout pour indiquer aux inconditionnels du genre qu'ils peuvent migrer en minimisant les risques vers cette solution, et qu'elle est à peu de chose près iso-fonctionnelle.
Mais comme tu l'auras compris, nous sommes Cyrille et moi convaincus que c'est par HTTP que le salut vient. C'est d'ailleurs le point de vue que nous avons tenté de mettre en avant dans l'historique d'AJP qui montre les faiblesses du protocole devenu standard de facto. A mon sens, le succès d'AJP vient surtout de son histoire et de toutes ces années ou il fût la seule solution possible. Mais maintenant qu'il existe une solution full HTTP pour faire tourner un serveur HTTP, je suis totalement partisan de cette dernière.
Cette solution à été particulièrement appréciée par les auditeurs de sécurité d'une grande régie de transport parisien qui préfère largement l'homogénéité des flux réseaux. C'est très utile en résolution de problèmes mais c'est aussi utile pour maintenir une topologie réseau simple.
Du reste, à mon tour je te rejoins totalement sur l'efficacité de la configuration Apache native qui permet de tuner facilement les configurations de proxy et de logs séparés par hôte virtuelle par exemple.
Donc une fois encore les avantages principaux sont d'utiliser HTTP d'abord, puis l'intégration native à Apache qui offre une facilité de configuration largement accrue.
> Le salut vient d'HTTP
Je serais un zeste plus modéré et diplomatique
.
Je trouve qu'AJP13 et mod_jk sont aujourd'hui respectivement moins intéressants aujourd'hui que HTTP et mod_proxy_balancer.
Cependant, selon l'adage il ne faut pas dire "Fontaine je ne boirai pas de ton eau", je n'exclue pas qu'un jour, HTTP soit dépassé par des protocoles comme SPDY et que mod_proxy_balancer devienne moins intéressant que des initiatives extérieures à Httpd comme mod_cluster
.
Hier, AJP&mod_jk, aujourd'hui HTTP&mod_proxy_balancer, demain ???
Cyrille
Du même avi que Mike, On peut utiliser conjointement mod_proxy et ajp
exemple de configuration :
BalancerMember ajp://node1:8060 route=tomcat1 ping=2
BalancerMember ajp://node2:8060 route=tomcat2 ping=2
ProxyPass / balancer://pool/ stickysession=JSESSIONID
ProxyPassReverse / balancer://pool/
avantage : on a un début de healthcheck sur le tomcat (avec l'option ping) + le tomcat reçoit tous les headers du client sans "bidouilles"
Pour moi le gros problème avec proxy_http, c'est que l'on a aucun healthcheck, or un load balancing sans healthcheck, ca ne marche qu'en fonctionnement nominal, quand tout est up and runing .....
En http, si un des tomcat est parti en vrille, le balancer continuera à lui envoyer des requêtes sans broncher .... pas cool
C'est pour cela que sur les loadbalancer hardware type F5-BigIP, on peut (et on doit) configurer une URL de healthcheck
--Fabrice
@Cyrille:
ca ma déja planté mes 6 serveurs 
Dans les faits, mon plus grand problème est qu'une webapp ne démarre pas pour un défaut de configuration et j'aimerais alors que Tomcat, plutôt que de retourner une erreur 404, s'arrête.
->j'en parlé sur le forum tomcat mais il ne demordent pas que si la page est absente un 404 est la bonne réponse http, on peut les comprendre, on regrette juste que ce code de retour soit dans le marbe...*
@Cyrille
* La désactivation de noeud de cluster sur exception peut causer des arrêts inattendus et être une faille importante de déni de service.
** Les mécanismes de Reply Timeout sont très délicats à gérer en cas de requêtes longues.
c gentils de prevenir mais pour moi c trops tards
@Fabrice,
Je serais comme vous intéressé par un mécanisme qui permettrait d'invalider un noeud devenu indisponible ; les mécanismes de healthcheck sont très adaptés à ce besoin.
Cependant, je viens de refaire les tests : AJP (via
mod_proxy_ajpetmod_jk) ne détecte pas plus quemod_proxy_httpl'indisponibilité d'un noeud pour un problème aussi flagrant que l'échec de démarrage d'une web application. Il en sera de même pour tout indisponibilité qui ne saturera pas le connecteur. Par exemple, un "too many open files" retournera une 500 immédiate qui ne sera pas vue par le ping AJP.Par conséquent, je vous rejoins sur l'intérêt d'un healthcheck pour tester la disponibilité d'un noeud de cluster mais seulement si c'est un healthcheck applicatif ; cela passerait probablement par le requêtage d'une URL.
Le ping AJP est en ce sens un faux ami à mes yeux. Il permet de détecter les échecs de communication vers le connecteur que
mod_jketmod_proxy_balancerdétectent aussi en échouant l'acheminement d'une requête. Le seul gain est que le ping AJP détectera peut être l'indisponibilité avec une tentative d'acheminement. En revanche, si mon trafic est important, la plus grande probabilité est qu'une requête échoue avant le passage du ping.@Marc,
Merci d'avoir défendu la cause de la 503 plutôt que la 404 en cas d'échec de démarrage d'une web application !
J'avais une idée similaire : forcer l'arrêt d'un Tomcat si une application échoue à démarrer. Un simple ContainerListener Tomcat devrait suffire. Dès que je trouve le temps ...
Cyrille
je reviens sur cet pseudo affirmation de ma part:
pour le status disabled du modjk, pour le moment je dirait être a peu près sur du fonctionement
et je remplace fonctionement par disfonctionement
après le post de cyrille j'ai refait des tests en coupant des pattes à mon cluster
et la surprise a été très mauvaise de voir que des requêtes arrive encore sur mes noeud disabled
cela m'étonne et je vais m'enpresser de lancer un post pour les devs du modjk
j'ai surement du raté un truc ce peut pas être possible.....
cdlt marco
Bonjour,
J'essaie de rediriger "http://localhost:8080/monsite/index.do" vers
"http://test-monsite.com".
Je ne veux pas avoir 8080 et /monsite dans l'url. Pour cela j'utilise
apache2.2 coupler avec tomcat6 (en utlisant proxy_ajp_module).
J'ai crée un vhost dans apache:
ServerName test-monsite.com
ServerAlias test-monsite.com
ErrorLog "logs/monsite.com-error.log"
CustomLog "logs/monsite.com-access.log" common
ProxyPass / ajp://127.0.0.1:8009/monsite/
ProxypassReverse / ajp://127.0.0.1:8009/monsite/
Mon problème est quand je demande http://test-monsite.com il
me redirige vers http://test-monsite.com/monsite/index.do.
Pouvez vous me donner quelques indications stp.
Merci d'avance
En théorie, c'est ce à quoi sert la directive
ProxyPreserveHost On
...
Oups ... pardon ... je suis allé trop vite
Je ne pense pas qu'il y ait de solution.
Eventuellement, avec une RewriteRule comme
RewriteRule ^/$ /monsite/index.do
mais ca risque de poser des problèmes ensuite pour l'accès aux ressources statiques ...
Il faudra de plus peut-être transformer les ProxyPass en RewriteRule aussi car ProxyPass risque d'être propriétaire.
Essayez donc avec
RewriteEngine On
RewriteRule ^/$ /monsite/index.do
RewriteRule (.*) asp://127.0.0.1:8009$1 [P]
et en supprimant les ProxyPass ...
Bonjour,
Merci pour votre réponse.
J'ai essayé cela en modifiant modifiant mon vhost comme ceci:
ServerName test-monsite.com
ServerAlias test-monsite.com
ErrorLog "logs/monsite.com-error.log"
CustomLog "logs/monsite.com-access.log" common
RewriteEngine On
RewriteRule ^/$ /monsite/index.do
RewriteRule (.*) ajp://127.0.0.1:8009$1 [P]
Il marche maintenant pour la page d'accueil de mon site enfin presque.
Cependant lorsque je navigue dans les autres pages du site il rajoute tjrs "/monsite. Exemple : http://test-monsite.com/monsite/mapage.jsp au lieu de http://test-monsite.com/mapage.jsp
En attendant de vous lire je vous remercie par avance.
Cdt
Oui, mais là, on ne peut plus rien faire.
Si c'est à un moment passé sur "/monsite" c'est que c'est le serveur qui a renvoyé ce lien.
La seule option est donc de mettre la webapp en contexte root ...
je dois avoir plusieurs sites déployés sur la même instance de tomcat.
Donc j'aurai besoin de plusieurs vhosts.
Si je mets la webapp en contexte root(d'ailleurs comment?)
ça ne va pas me poser des problèmes?
Merci
Cdt
Bonjour,
Une question de débutant.
Quel est la configuration pour avoir des un serveur apache en front qui va intérroger plusieurs tomcat en backend en utilisant le mod-proxy_ajp ?
Ou bien le mod_proxy_balancer est à utiliser pour faire du loadbalancing avec proxy_ajp ?
Merci de votre lumière.
Toty
@Jean,
J'ai l'impression d'arriver après la bataille, j'espère que vous serez indulgent.
En général, je préfère n'avoir qu'une seule web application par instance Tomcat et avoir plusieurs instances Tomcat par serveur physique. L'empreinte mémoire de Tomcat est tellement petite que cela ne pose en général pas de problème.
Si vous ne pouvez séparer vos applications sur des instances Tomcat dédiées, la piste des host dédiés me semble alors la plus élégante.
Ensuite, le problème de changement d'URI (
"/"->"/monsite") me semble introduire une complexité source de bugs récurrents (toutes les urls doivent être relatives, etc) et je préfère avoir avoir les mêmes URI sur les serveur Tomcat et Apache. S'il s'agit du contexte racine ("/"), on peut le faire en :- nommant le war
ROOT.warpour les déploiements par war,- définissant l'attribut
pathà""dans la configuration<Context path="" ... >pour les déploiements par configuration (modification deserver.xmlou ajout d'un fragment .xml dans$CATALINA_BASE/conf/Catalina/localhost*).*
Catalinaetlocalhostcorrespondent respectivement aunamede l'Engineet duHost.Cyrille (Xebia)
@ toty
mod_proxy_ajp ne traite que du protocole AJP, au même titre que mod_proxy_http qui gère HTTP. Si vous voulez que votre serveur Apache redirige les requêtes vers plusieurs serveurs Tomcat, il faut en plus configurer mod_proxy_balancer.
Vous aurez une configuration qui ressemblera à :
BalancerMember ajp://node-1:8009 route=node-1 disablereuse=On
# ...
BalancerMember ajp://node-n:8009 route=node-n disablereuse=On
</Proxy>
ProxyPass /my-application balancer://my-application-cluster/my-application stickysession=JSESSIONID
Cyrille (Xebia)
Bonjour,
Merci pour votre réponse!
J'ai respecté vos conseils et concernant mon 1èr vhost tout marche maintenant
( j'ai mis la web app en context root).
Par contre pour l'autre vhost j'ai le problème suivant:
Quand je demande http://test-monsite.com/mapage.jsp, j'obtiens ce lien à la place http://test-monsite.com/monsite/mapage.jsp. Donc un "/monsite" de trop dans l'url.
Et il m'est impossible de mettre la webapp de cette application en context root car il y'en a déjà un (la 1ère application) dans mon tomcat.
Cdt
@Jean,
Ne pouvez-vous pas créer un vhost Tomcat pour cette application destinée à un contexte root ?
Si mes comptes sont justes, vous auriez alors 3 vhosts.
Cyrille (Xebia)
En résumé j'ai 2 vhosts:
1) dont l'application destinée au contexte root
Celui-ci marche
2)qui pose problème car le context est rajouté dans l'url.
Donc comment faire pour ne pas avoir le context dans l'url?
L'application utilise le Framework Struts.
Voici le vhot du 2èm appli:
ServerName test-appli2.com
ServerAlias test-appli2.com
ErrorLog "logs/test-appli2.com-error.log"
CustomLog "logs/test-appli2.com-access.log" common
RewriteEngine On
RewriteRule ^/$ /appli2/index.do
RewriteRule (.*) ajp://127.0.0.1:8009$1 [P]
Merci pour votre aide.
@Jean,
Ne pouvez-vous pas déclarer un Host Tomcat dédié au nom de host "test-appli2.com" et y déclarer votre deuxième application comme contexte root ?
La configuration Tomcat ressemblerait à :
...
</Host>
<Host name="test-monsite.com" appBase="webapps-test-monsite.com" ...>
<!-- appli-1 est la web app par défaut de test-monsite.com -->
<Context path="" docBase="${path-to-appli-1}" .../>
</Host>
<Host name="test-appli2.com" appBase="webapps-test-appli2.com" ...>
<!-- appli-2 est la web app par défaut de test-appli2.com -->
<Context path="" docBase="${path-to-appli-2}" .../>
</Host>
Cyrille (Xebia)
Je viens de finir les tests.
Tout marche très bien.
Thx you very much
Je vous en prie
Cyrille
Bonjour,
J'ai développé une application multilangue en struts et mes urls sont sur cette forme http://monsite/mapage.do?locale=fr.
Comment les transformer (avec apache je pense que c'est la meilleur solution ???) pour qu'il soit visible pour l'utilisateur comme suit
http://monsite/fr/mapage.do.
Transformation à la volée de tous le urls en remplaçcant ?locale=fr par /fr/
Merci
Votre aide sera vraiment utile
@Jean,
pour réaliser ce type de transformation d'URL, il faudra vous tourner vers le mod_rewrite d'apache.
Cela vous permettra de modifier les URLs exposées aux utilisateurs tout en recevant le paramètre locale=fr.
Par contre je vous recommanderai peut-être plutôt une URL du type /mapage/fr à rediriger en /mapage.do?locale=fr.
Mais c'est à vous de vous faire votre propre avis sur ce point.
Oui effectivement j'ai essayé mod_rewrite d'apache mais en vain (RewriteRule).
Vous n'aurez pas un exemple à me montrer.
Merci
@Jean,
J'aurais une approche assez différente de mod_rewrite.
Votre besoin de reconstruction du fichier ".jsp" est spécifique à votre web application et non un comportement général à l'ensemble de votre site, à l'ensemble des pages webs servies par votre serveur Apache. J'imagine que le prefixage par la locale (e.g. "fr") ne s'applique pas aux servlets). Votre besoin me semble relever de la technique d'implémentation de l'internationalisation de votre framework de présentation.
Apache Httpd vs. web application
J'invoquerai deux principes pour implémenter ce comportement dans la web application plutôt que dans le serveur web amont :
* La cohésion : eviter de disperser le comportement d'une application sur d'autres composants que l'application elle même.
* Le découplage : eviter d'ajouter des comportements spécifiques d'une application à des composants mutualisés comme un serveur web.
Url Rewrite Filter & regexp vs Servlet Filter dédié
Techniquement, votre besoin semble réalisable avec les expressions régulières de l'Url Rewrite Filter (port en java de mod_rewrite). Cependant, je suis assez réticent aux solutions par expressions régulières génériques que je maitrise mal et que je trouve peu explicites alors que notre code java est souvent beaucoup plus auto documenté. Je proposerai donc une approche par un servlet filter dédié.
Je pressens d'ailleurs que la logique de ce filtre va se complexifier (limitation du nombre de locales supportées, locale par défaut, stockage dans une session ou un cookie de la locale choisie, filtrage fin des URL à traiter, etc).
LocaleFilter
Voici une ébauche d'un LocaleFilter qui reposerait sur un forward server-side (plutôt qu'un 302 redirect) :
private String defaultLocale;
private Set<String> supportedLocales;
@Override
public void doFilter(ServletRequest req, ServletResponse response, FilterChain chain) throws IOException, ServletException {
if (req instanceof HttpServletRequest) {
HttpServletRequest request = (HttpServletRequest) req;
String locale = String.valueOf(request.getParameter("locale")).toLowerCase();
if (!supportedLocales.contains(locale)) {
locale = defaultLocale;
}
String to;
if (request.getPathInfo() == null) {
to = "/" + locale + request.getServletPath();
} else {
to = "/" + locale + request.getServletPath() + request.getPathInfo();
}
request.getRequestDispatcher(to).forward(request, response);
} else {
chain.doFilter(req, response);
}
}
@Override
public void init(FilterConfig filterConfig) throws ServletException {
// TODO : code real implementation
defaultLocale = "fr";
supportedLocales = new HashSet<String>(Arrays.asList("fr", "en"));
}
...
}
Cyrille (Xebia)
Bonjour,
Merci pour la qualité de vos réponses.
J'ai testé la méthode de Cyrille, j'obtiens cependant une erreur 404:
ERROR RequestProcessor:664 - Invalid path /fr/index was requested
Pour info, j'utilise Le framework struts pour l'internationalisation.
Cdt
@Jean,
Navré mais moi ça marche avec Tomcat 6.0.26 et une jsp de test "toto.jsp"
.
Quelle URL avez vous invoqué ? N'est-elle pas traitée par Struts qui cherche une action enregistrée en "/fr/index.do" qui n'existerait pas ? N'auriez-vous pas appelé "/" qui votre configuration "web.xml" redirigerait vers le welcome-file "index.do" ?
Le message d'erreur dont vous nous parlez "RequestProcessor- Invalid path ... was requested" fait penser à une erreur Struts.
Votre problème me fait penser au "filtrage fin des URL à traiter" que j'ai évoqué précédemment
> Pour info, j'utilise Le framework struts pour l'internationalisation.
Vous semblez utiliser Struts en conjonction avec votre système par répertoire "/fr/", "/en/", ... Faire cohabiter deux systèmes ajoute en complexité
Bon courage,
Cyrille
@Jean,
Remarque complémentaire : il doit être plus simple de n'intercepter d'abord que les jsp entrantes avec le LocaleFilter, d'exclure les appels aux actions "*.do" (en ne filtrant que "*.jsp") et d'exclure les forward/include internes à Struts pour afficher les vues (en limitant le dispatcher à REQUEST).
<filter>
<filter-name>LocaleFilter</filter-name>
<filter-class>LocaleFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>LocaleFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
</web-app>
Cyrille (Xebia)
Mes urls sont traitées par struts. la configuration "web.xml" redirige vers le welcome-file "index.do".
Et l'action recherchée dans mon struts-config est définie comme suit
Pour votre dernière remarque, si j'exclus les appels aux actions "*.do", le LocaleFilter ne pourra pas s'appliquer
@Jean,
Votre commentaire semble avoir été tronqué, probablement un fragment XML qui a été avalé.
Votre approche "/mapage.do?locale=fr" => "/fr/mapage.do" doit aussi s'appliquer à la welcome page :
"/?locale=fr" => "/index.do?locale=fr" => "/fr/index.do"
Cyrille (Xebia)
Alors,
Toutes mes actions strust sont interceptées et traitées par le LocaleFilter.
Le paramètre de la langue est rajoutée dans le request du user (methode doFilter).
Mais les urls ne sont pas réécrites sous le format /fr/mapage.do ou /en/mapage.do.
Et je dois aussi dupliquer chaque action dans struts-config pour avoir les deux langues.Pas terrible et pire encore si je passe à plusieurs langues.
Je pense que j'ai loupé pas mal de chose.
Merci pour votre éclaircissement.
Cdt
Bonjour,
Merci pour votre réponse.
Concernant la configuration du mod_loadbalancer.
Par contre je suis confronté à un problème de maintient de session.
Je constate bien un fonctionnement de type RR(Round Robin) pour chaque requête apache.
Le souci est que au niveau de la l'application nous n'arrivons plus à nous connecter, puisque apache va interroger un autre tomcat.
Est-possible avec apache de maintenir une session où est-ce au niveau de l'application de palier le fonctionnement du loadbalancing ?
Cdl.
Toty
@Toty,
j'ai l'impression que vous avez oublié un paramètre important dans votre configuration du load balancer.
Pour rappel Cyrille vous a fourni un exemple :
Proxy balancer://my-application-cluster>
BalancerMember ajp://node-1:8009 route=node-1 disablereuse=On
# ...
BalancerMember ajp://node-n:8009 route=node-n disablereuse=On
ProxyPass /my-application balancer://my-application-cluster/my-application stickysession=JSESSIONID
Dans la ligne ProxyPass il faut absolument préciser le stickysession=JSESSIONID sans quoi apache ne reconnaîtra pas les sessions Tomcat et distribuera les requêtes en round robin sans se soucier de la session. Ce paramètre permet à Apache de servir les requêtes d'une même session vers le même serveur Tomcat en backend.
J'espère vous avoir éclairé,
bien cordialement,
Séven (Xebia)
Bonjour,
J'ai essayé plusieurs fois mais je n'arrive toujours pas réécrire mes urls
sous le format http://monsite/fr/mapage.do. au lieu de http://monsite/mapage.do?locale=fr. J'étais parti sur apache avec mod_rewrite mais il parait que c'est mieux de le gérer dans la web application.
Pouvez vous me donner quelques piste svp?
Merci d'avance
Bonjour Jean,
Cyrille vous aidera sûrement sur la partie côté webapp. De mon côté j'ai une solution fonctionnelle en mod_rewrite à vous de tester :
RewriteEngine on
RewriteRule ^([a-z]+)/(.*)\.do$ $2.do?locale=$1 [QSA,L]
En attendant, le support de cyrille, j'espère que cela pourra vous débloquer.
Bien cordialement,
Séven.
@Jean,
J'imagine l'approche suivante :
1. des URLs non localisées dans le browser de l'internaute (e.g. "/mapage.do")
2. gérées par des actions Struts non localisées (e.g. MonAction )
3. action Struts qui utilisentdes vues localisée en faisent des forward vers des jsp dont le chemin sur le file system est du type /fr/mapage.jsp, /en/mapage.jsp, etc
Ce fonctionnement me rappelle les thèmes de Spring MVC (1).
Ce raisonnement prend pour hypothèse que l'internaute ne voit pas la locale dans les urls invoquées avec son browser. Sinon, il faut faire une redirection 302 mais alors le request processor de Struts aura besoin de gérer autant d'action qu'il y a de locale ...
Cyrille
(1) http://static.springsource.org/spring/docs/3.0.2.RELEASE/spring-framework-reference/html/mvc.html#mvc-themeresolver
Je vous remercie pour vos réponses.
Je suis pour l'instant la solution apache.
Mais le RewriteRule ne marche pas.
- Il ne devrait pas y avoir une RewriteCond?
- Faut-il inverser ce deux paramètres ( RewriteRule ancienUrl newUrl ) parce que dans votre exemple on a ( RewriteRule newUrl ancienUrl)?
- Faut-il ajouter http://%{HTTP_HOST} dans le second paramètre (newUrl ) du RewriteRule?
Bien cordialement,
Jean
@seven,
Merci effectivement cela marche très bien, j'avais tenté d'essayer de mettre l'option failover.
Savez-vous dans quels cas et à quoi sert cette option? car sur le site d'apache il indique que l'option est à utiliser lorsque notre backend et notre front possède un firewall entre ?
Cordialement,
Toty
J'avoue être assez surpris que la RewriteRule ne fonctionne pas car je l'ai testé en local sur un apache 2.0 .
Attention, la RewriteRule garantie qu'apache convertisse les requêtes entrantes vers la nouvelle URL typiquement :
Utilisateur -> (Apache) /fr/mapage.do -> (Tomcat) /mapage.do?locale=fr
Apache n'est pas responsable de convertir les URLs fournies par la page générée ccôté Tomcat. Il faut donc que la page web expose des URL compatibles avec la règle de conversion:
Pour confirmer, vous pouvez commencer par tester l'url directement dans votre navigateur http://localhost/fr/mapage.do pour vérifier que la page est affiché avec la bonne locale.
Côté Apache il faudra aussi vous assurer que la RewriteRule soit bien appliquée pour le contexte correspondant.
Je reste à votre disposition pour plus d'éclaircissements.
Séven.
L'option nofailover du mod_proxy permet simplement de désactiver les tentatives d'accès sur un autre serveur du balancer en cas d'indisponibilité d'un worker. En clair comme il est dit dans la documentation Apache, si vous n'avez pas de réplication de session, l'option nofailover doit-être placée à "on" pour casser la session en cas d'indisponibilité du serveur qui hébergeait la session. L'utilisateur devra donc obtenir une nouvelle session sur un autre serveur.
Séven.
J'ai essayé cette règle et ça marche
RewriteRule ([a-z]+)/(.*)\.do$ /$2.do?locale=$1[QSA,L]
Comment faire pour les urls qui contiennent aussi d'autres paramètres en plus . ( http://monsite/mapage.do?param1=val1&locale=fr ou encore
http://monsite/mapage.do?param1=val1¶m2=val2&locale=en.
je ne veux réécrire que le param de la langue.
Cdt
@Jean,
Eh bien, il n'y a rien de plus à faire que d'ajouter vos paramètres comme à votre habitude, ils seront reçus normalement du côté Tomcat.
C'est le rôle du drapeau QSA en fin de ligne de la RewriteRule, cela indique simplement à Apache d'ajouter à l'URL convertie les paramètres reçus en entrée.
Séven.
je veux votre aide pour faire gestion de client( supprimer , ajouter,modifier et supprimer avec deux methode servlet et restmodifiable par j2ee)
Bonjour,
j'aurais un petit soucis a vous soumettre, j'ai 4 instances Jboss dans le même cluster installées sur 2 machines distinctes ( 2x2 ), je dois mettre en cluster 3 applications ( cas + alfresco + liferay ).
j'ai mis apache sur le serveur X , 2 instances jboss sur le serveur X et les 2 autres sur le serveur Y et il communique avec Jboss en AJP.
Quand je désactive au niveau du jkmanager les 2 instance sur le serveur Y tout est nickel ( boucle locale ) mais quand je n'active que les instances sur le serveur Y, une fois sur 2 , je me prends un timeout au niveau du mod_jk.
Je précise qu'il n'y a pas de probleme réseau apparent entre le serveur X et Y, que la conf du mod_jk est par défaut et que les connecteurs HTTP des instances jboss du serveur Y repondent normalement.
Auriez vous des pistes pour tester la communication entre les serveur X et les connecteurs AJP des 2 jboss ?
Merci par avance.
Bonjour Cyril,
Que te disent les captures réseaux ? Le blocage est-il coté serveur apache ou bien serveur d'application ?
Si c'est coté serveur d'application, pense a regarder les spools du connecteur AJP de ton JBOSS.
Pour ma part ton problème semble plus réseau car sur la boucle locale ça fonctionne très bien...
Toty