¿Cuál es la configuración óptima para usar Apache o NGINX como servidor de backend para ELB?

4 minutos de lectura
0

Quiero usar una instancia de Amazon Elastic Compute Cloud (Amazon EC2) que ejecute Apache o NGINX como servidor de backend para Elastic Load Balancing (ELB). Sin embargo, no sé qué ajustes usar para obtener el mejor rendimiento.

Resolución

La mejor configuración para un equilibrador de carga depende de su caso de uso. Para obtener el mejor rendimiento, analice los tiempos de respuesta de su aplicación de backend y los requisitos de sus clientes.

Si la aplicación de backend ejecuta Apache o NGINX, revise los siguientes parámetros:

Tiempo de espera del encabezado del cliente (tiempo de espera en Apache; client_header_timeout en NGINX):
Defina el tiempo de espera de la aplicación en un valor superior al valor de tiempo de espera de inactividad del equilibrador de carga. Haga esto para asegurarse de que el equilibrador de carga cierra correctamente las conexiones inactivas. Si el servidor de backend termina una conexión sin notificar adecuadamente al equilibrador de carga, es posible que reciba un error 504.

Keep-alive (KeepAlive en Apache; keepalive_disable en NGINX):
Active keep-alive para reducir el uso de la CPU y mejorar el tiempo de respuesta. Con keep-alive activado, el equilibrador de carga no necesita establecer una nueva conexión TCP para cada solicitud HTTP.

Tiempo de espera de keep-alive (KeepAliveTimeout en Apache; keepalive_timeout en NGINX):

Cuando la opción keep-alive esté activada, elija un tiempo de espera de mantenimiento más largo que el tiempo de inactividad del equilibrador de carga.

Tiempos de espera de lectura (RequestReadTimeout en Apache; client_header_timeout y client_body_timeout en NGINX):
Establezca tiempos de espera de lectura que se ajusten a los tiempos de respuesta de su aplicación. Haga esto para asegurarse de que el equilibrador de carga mantenga la conexión abierta el tiempo suficiente para recibir tanto el encabezado como el cuerpo de la solicitud.

Advertencia: Asegúrese de que el valor del tiempo de espera de inactividad del equilibrador de carga sea inferior al tiempo de espera del backend.

Número máximo de solicitudes de keep-alive (MaxKeepAliveRequests en Apache; keepalive_requests en NGINX):
Esta opción establece el número de solicitudes que recibe una sola conexión TCP cuando keep-alive está activado. Para un mejor uso de los recursos, establezca el número máximo de solicitudes de mantenimiento activo en 100 o más.

AcceptFilter (AcceptFilter en Apache; accept_filter en NGINX):
AcceptFilter está activado de forma predeterminada y le indica a Apache que utilice la opción TCP_DEFER_ACCEPT para las conexiones. Esta configuración puede hacer que el socket TCP esté en un estado «semiabierto». En este estado, el equilibrador de carga asume que la conexión está establecida, pero la instancia de backend no la tiene establecida. Las conexiones semiabiertas son más comunes en los equilibradores de carga de bajo volumen, donde las conexiones tienen tiempo de envejecer antes de usarse.

Registro: Active la opción**%{X-Forwarded-For}i** para que Apache muestre el encabezado x-desaforar-for de ELB en sus registros para cada solicitud. Este encabezado contiene la dirección IP del cliente original. La opción %D agrega el tiempo necesario para completar cada solicitud a los registros de acceso:

LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b %D \"%{Referer}i\" \"%{User-Agent}i\"" combined

Apache: El módulo de evento MPM de Apache puede cerrar prematuramente las conexiones de los equilibradores de carga. El cierre prematuro de las conexiones genera errores HTTP 502 para el equilibrador de carga de aplicación y errores HTTP 504 para el equilibrador de carga clásico. Se recomienda utilizar el módulo de trabajo de MPM en su lugar para reducir este comportamiento.

Nota: Después de actualizar la configuración, reinicie Apache o NGINX.


Información relacionada

Instancias registradas para el equilibrador de carga clásico

Configurar su equilibrador de carga clásico

OFICIAL DE AWS
OFICIAL DE AWSActualizada hace un año