<-
Apache > Servidor HTTP > Documentación > Versión 2.5 > How-To / Tutoriales

Guía de Proxy Inverso

Idiomas disponibles:  en  |  es  |  fr 

Esta traducción podría estar obsoleta. Consulte la versión en inglés de la documentación para comprobar si se han producido cambios recientemente.

Además de ser un servidor web "básico", y proveer contenido estático y dinámico a los usuarios finales, Apache HTTPD (al igual que la mayoría de servidores http) puede también actuar como proxy inverso, también conocido como "servidor de paso" o gateway.

En tales escenarios, el propio httpd no genera contenido o aloja datos, en su lugar el contenido se obtiene de uno o varios servidores backend, que normalmente no tienen conexión directa con redes externas. Cuando httpd recibe una petición de un cliente, se hace proxy de esta petición a uno de estos servidores backend, que gestiona la petición, genera el contenido y entonces envía este contenido de vuelta a httpd, que entonces genera la respuesta HTTP definitiva que se envía de vuelta al cliente.

Existen muchas razones para usar esta implementación, pero generalmente las razones típicas se deben a seguridad, alta disponibilidad, balanceo de carga, y centralización de autenticación/autorización. Es crítico en estas implementaciones que la arquitectura y el diseño de la infraestructura de los backend (esos servidores que son los que acaban gestionando las peticiones) estén aislados y protegidos del exterior; en cuanto al cliente se refiere, el proxy inverso és la única fuente de todo el contenido.

Ejemplo de implementación típica:

reverse-proxy-arch

Consulte también

top

Proxy Inverso

top

Proxy inverso sencillo

La directiva ProxyPass especifica el mapeo de peticiones entrantes al servidor backend (o un cluster de servidores conocido como grupo de Balanceo). El ejemplo más sencillo hace proxy de todas las solicitudes ("/") a un solo backend:

ProxyPass "/"  "http://www.example.com/"

Para asegurarse de ello y que las cabeceras Location: generadas en el backend se modifican para apuntar al proxy inverso, en lugar del propio backend, la directiva ProxyPassReverse suele ser necesaria a menudo:

ProxyPass "/"  "http://www.example.com/"
ProxyPassReverse "/"  "http://www.example.com/"

Sólo se hará proxy de ciertas URIs, como se muestra en este ejemplo:

ProxyPass "/images/"  "http://www.example.com/"
ProxyPassReverse "/images/"  "http://www.example.com/"

En este ejemplo, se hará proxy al backend especificado, de cualquier solicitud que comience con la ruta /images/, si no se gestionarán localmente.

top

Clusters y Balanceadores

Aunque los ejemplos de más arriba son útiles, tienen la deficiencia en la que si el backend se cae, o recibe mucha carga, hacer proxy de esas solicitudes no aporta grandes beneficios. Lo que se necesita es la habilidad de definir un grupo de servidores backend que puedan gestionar esas peticiones y que el proxy inverso pueda balancear la carga y aplicar la tolerancia a fallos entre los backend. A veces a este grupo se le llama cluster, pero el término para Apache httpd es balanceador. Se puede definir un balanceador usando las directivas <Proxy> and BalancerMember como se muestra a continuación:

<Proxy balancer://myset>
    BalancerMember http://www2.example.com:8080
    BalancerMember http://www3.example.com:8080
    ProxySet lbmethod=bytraffic
</Proxy>

ProxyPass "/images/"  "balancer://myset/"
ProxyPassReverse "/images/"  "balancer://myset/"

El esquema balancer:// es lo que le dice a httpd que estamos generando un grupo de balanceo, con el nombre myset. Incluye 2 servidores backend, que httpd llama BalancerMember. En este caso, se hará proxy inverso de cualquier petición para /images/ hacia uno de los dos backend. La directiva ProxySet especifica que el Balanceador myset usa un algoritmo que balancea basado en los bytes de entrada/salida (I/O).

Información adicional

También se refiere a los Miembros del Balanceador BalancerMember como workers (trabajadores).

top

Configuración de Balanceador y BalancerMember

Puede ajustar numerosos parámetros de los balanceadores y los workers definiéndolos a través de la directiva ProxyPass. Por ejemplo, asumiendo que quisiéramos que http://www3.example.com:8080 gestionara 3 veces más tráfico con un "timeout" de 1 segundo, ajustaríamos la configuración como sigue:

<Proxy balancer://myset>
    BalancerMember http://www2.example.com:8080
    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
    ProxySet lbmethod=bytraffic
</Proxy>

ProxyPass "/images/"  "balancer://myset/"
ProxyPassReverse "/images/"  "balancer://myset/"
top

Tolerancia a fallos

Puede también ajustar varios escenarios de tolerancia a fallos, detallando qué workers, e incluso balanceadores, deberían usarse en tales casos. Por ejemplo, la siguiente configuración implementa dos casos de tolerancia a fallos: En el primero, sólo se envía tráfico a http://hstandby.example.com:8080 si todos los demás workers en el balanceador myset no están disponibles. Si ese worker tampoco está disponible, sólo entonces los workers de http://bkup1.example.com:8080 y http://bkup2.example.com:8080 serán incluidos en la rotación:

<Proxy balancer://myset>
    BalancerMember http://www2.example.com:8080
    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
    BalancerMember http://hstandby.example.com:8080 status=+H
    BalancerMember http://bkup1.example.com:8080 lbset=1
    BalancerMember http://bkup2.example.com:8080 lbset=1
    ProxySet lbmethod=byrequests
</Proxy>

ProxyPass "/images/"  "balancer://myset/"
ProxyPassReverse "/images/"  "balancer://myset/"

La "magia" de ésta configuración de tolerancia a fallos es configurar http://hstandby.example.com:8080 con la marca de estado +H, que lo pone en modo hot standby (en reserva), y hacen que los 2 servidores bkup# sean parte del set nº 1 del balanceo de carga (el valor por defecto es 0); para tolerancia a fallos, los "hot standby" (si existen) se usan primero cuando todos los workers estándar no están disponibles; los set de balanceo con el número inferior se intentan usar siempre primero.

top

Gestor del Balanceador

Una de las características más útiles y única del proxy inverso de Apache httpd es la aplicación embebida balancer-manager (gestor de balanceo). wSimilar a mod_status, balancer-manager muestra la configuración actual que está funcionando, el estado de los balanceadores activados y workers que están en uso en ese momento. Aun así, no sólo muestra estos parámetros, también permite reconfiguración dinámica, en tiempo real, de prácticamente todos ellos, incluido añadir nuevos BalancerMember (workers) a un balanceo existente. Para activar esta prestación, se tiene que añadir lo siguiente a la configuración:

<Location "/balancer-manager">
    SetHandler balancer-manager
    Require host localhost
</Location>

Atención

No active el balancer-manager hasta que haya securizado su servidor. En particular, asegúrese de que el acceso a ésta URL (la de configuración del balanceador) esté altamente restringido.

Cuando se accede al proxy inverso en la url (p.e: http://rproxy.example.com/balancer-manager/, verá una página similar a la siguiente:

balancer-manager page

Este formulario permite al administrador ajustar varios parámetros, desactivar workers, cambiar los métodos de balanceo de carga y añadir nuevos workers. Por ejemplo, haciendo clic en el balanceador, verá la siguiente página:

balancer-manager page

Y haciendo clic en el worker, mostrará esta página:

balancer-manager page

Para hacer que estos cambios sean persistentes en los reinicios del proxy inverso, asegúrese de que BalancerPersist está activado.

top

Comprobaciones de estado dinámicas

Antes de que httpd haga proxy de una petición a un worker, puede "comprobar" si ese worker está disponible mediante el parámetro de configuración ping para ese worker usando ProxyPass. A menudo es más útil comprobar el estado de los workers no disponibles, con un método dinámico. Esto se consigue con el módulo mod_proxy_hcheck.

top

Marcas de estado de los Miembros del Balanceador

En el balancer-manager el estado actual, o status, de un worker se muestra y puede ser configurado/reseteado. El significado de estos estados es el siguiente:

MarcaCadenaDescripción
 OkEl Worker está disponible
 InitEl Worker ha sido inicializado
DDisEl Worker está desactivado y no aceptará peticiones; se intentará reutilizar automáticamente.
SStopEl Worker ha sido desactivado por el administrador; no aceptará peticiones y no se reintentará utilizar automáticamente
IIgnEl Worker está en modo "ignore-errors" (obviar-errores) y estará siempre en modo disponible.
HStbyEl Worker está en modo "hot-standby" y sólo se usará si no hay otros workers disponibles.
EErrEl Worker está en estado de error, generalmente debido a fallos de comprobación antes de enviar peticiones; no se hará proxy de peticiones a este worker, pero se reintentará el uso de este worker dependiendo de la configuración del parámetro retry.
NDrnEl Worker está en modo vaciado y sólo aceptará sesiones activas previamente destinadas a él mismo y obviará el resto de peticiones.
CHcFlLa comprobación dinámica del estado del Worker ha fallado y no se usará hasta que pase las comprobaciones de estado posteriores.

Idiomas disponibles:  en  |  es  |  fr 

top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.