mod_proxy vs mod_proxy_ajp vs mod_jk

9

Nous préparons la migration depuis l'environnement suivant:

Apache 2.0.2 --AJP -> JBoss4.2.2

à

Apache 2.2.3 - ??? -> JBoss 5.1.0

Comment voulez-vous joindre les deux ensemble?

Les options sont:

  1. AJP classique (signifie construire mod_jk pour Apache)
  2. mod_proxy (transfert des requêtes HTTP à JBoss)
  3. mod_proxy_ajp

L'option 2 est la solution la plus populaire pour le moment car elle semble signifier moins de traitement car elle n'a plus besoin de traduire les réponses de JBoss d'AJP, et le temps CPU est quelque chose que nous devons surveiller de près dans notre infrastructure. Les options 2 et 3 sont également fournies avec la version Apache prise en charge par Red Hat.

Pour le moment, je ne peux pas nous voir opter pour l'option 1, car nous recevons AJP «gratuitement» avec l'option 3.

Quels sont donc les avantages et les inconvénients des options 2 et 3? Le souci de la charge CPU est-il vraiment quelque chose dont nous devons nous inquiéter? Ce que nous perdons dans le traitement des données binaires (trafic AJP) récupérons-nous dans une bande passante et des E / S réduites?

Notre infrastructure sera Apache, qui offrira jusqu'à 9 JBoss très ajustés (mais généralement environ la moitié) sur la même machine RHEL 5, qui est virtualisée dans un cloud privé.

Merci d'avance pour tous les pointeurs / conseils.

Riches

Riches
la source

Réponses:

8

2 mod_proxy_http, sauf si vous avez besoin de l'en-tête Host du client.

Je ne recommande pas le mod_jk classique car sa fonctionnalité a été remplacée par le mod_proxy_ajp et comme vous l'avez dit vous-même, il nécessite de construire et de maintenir ce module vous-même.

Je pense que mod_proxy_http est une solution très propre et cela prend ajp hors de l'image. Cependant, vous devez être conscient de quelques mises en garde pour passer de ajp à http. Si vous avez besoin d'accéder aux en-têtes de serveur exactement tels qu'ils ont été reçus par apache (y compris l'en-tête Host), vous devez utiliser ajp. JBoss verra une nouvelle requête http provenant d'Apache, pas du client d'origine. Si vous n'avez besoin que de l'IP distante du client, vous pouvez toujours l'obtenir avec un en-tête spécial qu'apache peut définir sur les nouvelles requêtes. Cependant, si vous faites de l'hébergement virtuel à partir de la couche d'application, vous feriez mieux d'ajp.

En ce qui concerne les performances, ajp ou http nécessitent un traitement par JBoss et du trafic TCP de socket local. Vous devrez essayer les deux pour voir lequel est le plus efficace, mais je pense que dans l'ensemble, c'est un très petit pourcentage de la charge totale du serveur. Http est un protocole plus compliqué et ajp est spécialement conçu pour efficacement entre les niveaux web et application, donc théoriquement ajp est probablement mieux. Cela dit, j'ai constaté que http est souvent mieux pris en charge en dehors de la gamme de serveurs d'applications Tomcat.

J'utilise mod_proxy_ajp et mod_proxy_http et je n'ai eu aucun problème.

e_tothe_ipi
la source
L'en- Hosttête sera transmis correctement si vous utilisezProxyPreserveHost On
Derf
Lorsque vous travaillez avec Apache mod_proxy, consultez httpd.apache.org/docs/2.4/mod/mod_proxy.html#x-headers . Si vous configurez RemoteIpValve dans le cadre de votre servlet Tomcat, le code de votre application peut obtenir la plupart des informations de manière transparente tomcat.apache.org/tomcat-8.0-doc/config/…
Scott Markwell