mod_proxy vs mod_proxy_ajp vs mod_jk


9

Nos estamos preparando para la migración desde el siguiente entorno:

Apache 2.0.2 --AJP -> JBoss4.2.2

a

Apache 2.2.3 - ??? -> JBoss 5.1.0

¿Cómo unirías a los dos?

Las opciones son:

  1. AJP clásico (significa construir mod_jk para Apache)
  2. mod_proxy (reenvío de solicitudes HTTP a JBoss)
  3. mod_proxy_ajp

La opción 2 es la solución más popular en este momento porque parece significar menos procesamiento debido a que ya no es necesario traducir las respuestas de JBoss de AJP, y el tiempo de CPU es algo que debemos vigilar de cerca en nuestra infraestructura. Las opciones 2 y 3 también vienen con la compilación Apache compatible con Red Hat.

Por el momento no puedo vernos yendo a la opción 1, ya que obtenemos AJP 'gratis' con la opción 3.

Por lo tanto, ¿cuáles son los pros y los contras de las opciones 2 y 3? ¿La preocupación por la carga de la CPU es realmente algo de lo que debemos preocuparnos? Lo que perdemos al procesar datos binarios (tráfico AJP), ¿recuperamos el ancho de banda reducido y la E / S?

Nuestra infraestructura será Apache al frente de hasta 9 JBosses muy ajustados (pero generalmente alrededor de la mitad) en la misma máquina RHEL 5, que está virtualizada en una nube privada.

Gracias de antemano por cualquier sugerencia / consejo.

Rico

Respuestas:


8

2 mod_proxy_http, a menos que necesite el encabezado Host del cliente.

No recomiendo mod_jk clásico porque su funcionalidad ha sido reemplazada por mod_proxy_ajp y, como usted mismo dijo, requiere construir y mantener ese módulo usted mismo.

Creo que mod_proxy_http es una solución muy limpia y saca ajp de la imagen. Sin embargo, debe tener en cuenta algunas advertencias para pasar de ajp a http. Si necesita acceder a los encabezados del servidor exactamente como los recibió Apache (incluido el encabezado Host), debe usar ajp. JBoss verá una nueva solicitud http proveniente de apache, no del cliente original. Si solo necesita la IP remota del cliente, aún puede obtener esto con un encabezado especial que apache puede establecer en las nuevas solicitudes. Sin embargo, si está realizando un alojamiento virtual desde la capa de aplicación, es mejor que tenga ajp.

En lo que respecta al rendimiento, ajp o http requerirán algún procesamiento por parte de JBoss y algo de tráfico TCP de socket local. Tendrá que probar ambos para ver cuál es más eficiente, pero creo que, en general, es un porcentaje muy pequeño de la carga total del servidor. Http es un protocolo más complicado y ajp está diseñado específicamente para eficientemente entre niveles web y de aplicaciones, por lo que teóricamente ajp es probablemente mejor. Dicho esto, he encontrado que http a menudo se admite mejor fuera de la línea del servidor de aplicaciones Tomcat.

Uso mod_proxy_ajp y mod_proxy_http y no he tenido ningún problema.


El Hostencabezado se pasará correctamente si usaProxyPreserveHost On
Derf

Cuando trabaje con Apache mod_proxy, consulte httpd.apache.org/docs/2.4/mod/mod_proxy.html#x-headers . Si configura RemoteIpValve como parte de su Servlet Tomcat, su código de aplicación puede obtener la mayoría de la información de forma transparente tomcat.apache.org/tomcat-8.0-doc/config/…
Scott Markwell
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.