From: Luis Gil Date: Tue, 28 Feb 2017 00:47:18 +0000 (+0000) Subject: reviewed reverse proxy xml file, fixed english phrase missconfig, and updated and... X-Git-Tag: 2.5.0-alpha~596 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1d691b854b0ec693e9b9b620684db71a23c4ff62;p=thirdparty%2Fapache%2Fhttpd.git reviewed reverse proxy xml file, fixed english phrase missconfig, and updated and generated the corresponding files, also added the updated meta file. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1784674 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/howto/reverse_proxy.html b/docs/manual/howto/reverse_proxy.html index a72ae2e6669..6f59820f9c7 100644 --- a/docs/manual/howto/reverse_proxy.html +++ b/docs/manual/howto/reverse_proxy.html @@ -3,3 +3,7 @@ URI: reverse_proxy.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: reverse_proxy.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/howto/reverse_proxy.html.es b/docs/manual/howto/reverse_proxy.html.es new file mode 100644 index 00000000000..dde23b3ac33 --- /dev/null +++ b/docs/manual/howto/reverse_proxy.html.es @@ -0,0 +1,334 @@ + + + + + +Guía de Proxy Inverso - Servidor HTTP Apache Versión 2.5 + + + + + + + +
<-
+
+Apache > Servidor HTTP > Documentación > Versión 2.5 > How-To / Tutoriales

Guía de Proxy Inverso

+
+

Idiomas disponibles:  en  | + es 

+
+ +

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

+ +
+ +
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 dos 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 activos no están disponibles; los set de balanceo con números inferiores se usan 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 

+
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.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/reverse_proxy.xml b/docs/manual/howto/reverse_proxy.xml index ca986d36ebe..2095012ff79 100644 --- a/docs/manual/howto/reverse_proxy.xml +++ b/docs/manual/howto/reverse_proxy.xml @@ -211,7 +211,7 @@ ProxyPassReverse "/images/" "balancer://myset/" with the +H status flag, which puts it in hot standby mode, and making the 2 bkup# servers part of the #1 load balancer set (the default set is 0); for failover, hot standbys (if they exist) are used 1st, when all regular - workers are unavailable; load balancer sets are always tried lowest number first. + workers are unavailable; load balancer sets with lowest number are always tried first.

diff --git a/docs/manual/howto/reverse_proxy.xml.es b/docs/manual/howto/reverse_proxy.xml.es new file mode 100644 index 00000000000..f0d4d977388 --- /dev/null +++ b/docs/manual/howto/reverse_proxy.xml.es @@ -0,0 +1,318 @@ + + + + + + + + + + +How-To / Tutoriales + + Guía de Proxy Inverso + + +

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

+ +
+ + + + +
+ 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. +

+
+ +
+ 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). +

+
+ +
+ +
+ 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/" + + +
+ +
+ 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 dos 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 activos no están disponibles; los set de balanceo con números inferiores se usan siempre primero. +

+ +
+ +
+ 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. +

+ +
+ +
+ 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. +

+ +
+ +
+ 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.
+
+ +
diff --git a/docs/manual/howto/reverse_proxy.xml.meta b/docs/manual/howto/reverse_proxy.xml.meta index 3c15cd22774..bd09343e359 100644 --- a/docs/manual/howto/reverse_proxy.xml.meta +++ b/docs/manual/howto/reverse_proxy.xml.meta @@ -8,5 +8,6 @@ en + es