Equilibrio de carga con NGINX y NGINX Plus, Parte 2

En Equilibrio de carga con NGINX y NGINX Plus, Parte 1 , configuramos un proxy HTTP simple para equilibrar el tráfico en varios servidores web. En este artículo, veremos características adicionales, algunas de ellas disponibles en NGINX Plus : optimización del rendimiento con keepalives , controles de estado , persistencia de sesión , redirecciones y reescritura de contenido .

Para obtener detalles sobre las funciones de equilibrio de carga en NGINX y NGINX Plus, consulte la Guía de administración de NGINX Plus .

Editor: NGINX Plus versión 5 y posteriores también pueden equilibrar la carga de aplicações basadas en TCP. El equilibrio de carga TCP se amplió significativamente en la versión 6 mediante la incorporación de controles de estado, reconfiguración dinámica, terminación SSL y más. En NGINX Plus versión 7 y posteriores, el balanceador de carga TCP tiene paridad de funciones completa con el balanceador de carga HTTP. El soporte para el equilibrio de carga UDP se introdujo en la versión 9.

Configura el equilibrio de carga TCP y UDP en el contexto de transmisión en lugar del contexto http . Las directivas y parámetros disponibles difieren un poco debido a las diferencias inherentes entre HTTP y TCP/UDP; para obtener más detalles, consulte la documentación de los módulos Upstream HTTP y TCP/UDP .

Una revisión rápida

Para repasar, esta es la configuración que construimos en el artículo anterior:

servidor { escucha 80;

ubicación / {
contraseña_proxy http://backend;

# Reescribe el encabezado 'Host' con el valor de la solicitud del cliente,
    # o el nombre del servidor principal
    proxy_set_header Host $host;

# Alternativamente, escribe el valor en la configuración:
# proxy_set_header Host www.example.com;
} 
}

backend ascendente {
zona backend 64k; # Usa la memoria compartida de NGINX Plus
less_conn;

servidor servidor web1 peso=1;
servidor servidor web2 peso=4;
}

En este artículo, veremos algunas formas simples de configurar NGINX y NGINX Plus que mejoran la eficacia del equilibrio de carga.

Keepalives HTTP

Habilitar los keepalives HTTP entre NGINX o NGINX Plus y los servidores ascendentes mejora el rendimiento (al reducir la latencia) y reduce la probabilidad de que NGINX se quede sin puertos efímeros.

El protocolo HTTP utiliza conexiones TCP subyacentes para transmitir solicitudes HTTP y recibir respuestas HTTP. Las conexiones HTTP keepalive permiten la reutilización de estas conexiones TCP, evitando así la sobrecarga de crear y destruir una conexión para cada solicitud:

NGINX es un proxy completo y administra las conexiones de los clientes (conexiones keepalive de frontend) y las conexiones a los servidores (conexiones keepalive de upstream) de forma independiente:

NGINX mantiene un “caché” de conexiones keepalive (un conjunto de conexiones keepalive inactivas a los servidores ascendentes) y cuando necesita reenviar una solicitud a un servidor ascendente, utiliza una conexión keepalive ya establecida desde el caché en lugar de crear una nueva conexión TCP. Esto reduce la latencia de las transacciones entre NGINX y los servidores ascendentes y reduce la velocidad a la que se utilizan los puertos efímeros, por lo que NGINX puede absorber y equilibrar la carga de grandes volúmenes de tráfico. Con un gran pico de tráfico, la caché se puede vaciar y en ese caso NGINX establece nuevas conexiones HTTP con los servidores ascendentes.

Con otras herramientas de equilibrio de carga, esta técnica a veces se denomina multiplexación , agrupación de conexiones , reutilización de conexiones o OneConnect .

Para configurar la caché de conexión keepalive, incluya las directivas proxy_http_version , proxy_set_header y keepalive en la configuración:

servidor { escuchar 80; ubicación / { proxy_pass http://backend; proxy_http_version 1.1 ; proxy_set_header Conexión "" ; } } upstream backend { servidor webserver1; servidor webserver2; # mantener hasta 20 conexiones inactivas al grupo de servidores upstream keepalive 20 ; }

Comprobaciones de estado

Habilitar controles de estado aumenta la confiabilidad de su servicio de equilibrio de carga, reduce la probabilidad de que los usuarios finales vean mensajes de error y también puede facilitar operaciones de mantenimiento comunes.

La función de verificación de estado de NGINX Plus se puede utilizar para detectar fallas en los servidores ascendentes. NGINX Plus prueba cada servidor mediante “transacciones sintéticas” y compara la respuesta con los parámetros que usted configura en la directiva health_check (y, cuando incluye el parámetro match , el bloque de configuración match asociado):

servidor { escuchar 80; ubicación / { proxy_pass http://backend; health_check interval=2s fails=1 passed=5 uri=/test.php match=statusok ; # Las comprobaciones de estado heredan otras configuraciones de proxy proxy_set_header Host www.foo.com; } } match statusok { # Se usa para la comprobación de estado /test.php estado 200 ; encabezado Content-Type = text/html ; cuerpo ~ "Server[0-9]+ está activo" ; }

La comprobación de estado hereda algunos parámetros de su bloque de ubicación principal. Esto puede causar problemas si utiliza variables de tiempo de ejecución en su configuración. Por ejemplo, la siguiente configuración funciona para el tráfico HTTP real porque extrae el valor del encabezado Host de la solicitud del cliente. Probablemente no funcione para las transacciones sintéticas que utiliza la comprobación de estado porque el encabezado de Host no está configurado para ellas, lo que significa que no se utiliza ningún encabezado de Host en la transacción sintética.

location / { proxy_pass http://backend;

# Esta comprobación de estado podría no funcionar...
health_check interval=2s fails=1 passed=5 uri=/test.php match=statusok;

# Extraer el encabezado "Host" de la solicitud
proxy_set_header Host $host;
}

Una buena solución es crear un bloque de ubicación ficticio que defina estáticamente todos los parámetros utilizados por la transacción de verificación de estado:

location /internal-health-check1 { internal; # Evitar que las solicitudes externas coincidan con este bloque de ubicación

proxy_pass http://backend;

health_check interval=2s fails=1 passed=5 uri=/test.php match=statusok;

# Establecer explícitamente los parámetros de la solicitud; no usar variables de tiempo de ejecución
proxy_set_header Host www.example.com;
}

Para obtener más información, consulte la Guía de administración de NGINX Plus .

Persistencia de sesión

Con la persistencia de sesión, las aplicações que no se pueden implementar en un clúster se pueden equilibrar y escalar de manera confiable. Las aplicações que almacenan y replican el estado de la sesión funcionan de manera más eficiente y mejora el rendimiento del usuario final.

Algunas aplicações a veces almacenan información de estado en los servidores ascendentes, por ejemplo, cuando un usuario coloca un artículo en un carrito de compras virtual o edita una imagen cargada. En estos casos, es posible que desee dirigir todas las solicitudes posteriores de ese usuario al mismo servidor.

La persistencia de la sesión especifica a dónde debe enrutarse una solicitud, mientras que el equilibrio de carga le da a NGINX la libertad de seleccionar el servidor ascendente óptimo. Los dos procesos pueden coexistir utilizando la capacidad de persistencia de sesión de NGINX Plus:

   Si la solicitud coincide con una regla de persistencia de sesión
Luego use el servidor ascendente de destino
De lo contrario, aplique el algoritmo de equilibrio de carga para seleccionar el servidor ascendente

Si la decisión de persistencia de la sesión falla porque el servidor de destino no está disponible, NGINX Plus toma una decisión de equilibrio de carga.

El método de persistencia de sesión más simple es el enfoque de “ cookie persistente ”, donde NGINX Plus inserta una cookie en la primera respuesta que identifica el servidor ascendente persistente:

cookie adhesiva srv_id caduca=1h dominio=.example.com ruta=/;

En el método alternativo de “ ruta fija ”, NGINX selecciona el servidor ascendente en función de parámetros de solicitud como la cookie JSESSIONID:

backend ascendente { servidor backend1.example.com route=a ; servidor backend2.example.com route=b ; # seleccione la primera variable no vacía; debe contener 'a' o 'b' ruta fija $route_cookie $route_uri ; }

Para obtener más información, consulte la Guía de administración de NGINX Plus .

Reescritura de redirecciones HTTP

Reescriba las redirecciones HTTP si algunas redirecciones están rotas, y particularmente si descubre que lo están redireccionando desde el proxy al servidor ascendente real.

Cuando se accede a un servidor proxy, el servidor publica la aplicação en una dirección local, pero usted accede a la aplicação a través de una dirección diferente: la dirección del proxy. Estas direcciones normalmente se resuelven en nombres de dominio y pueden surgir problemas si el servidor y el proxy tienen dominios diferentes.

Por ejemplo, en un entorno de prueba, puede dirigirse a su proxy directamente (por dirección IP) o como localhost . Sin embargo, el servidor ascendente podría escuchar en un nombre de dominio real (como www.nginx.com ). Cuando el servidor ascendente emite un mensaje de redirección (utilizando un estado 3xx y un encabezado de ubicación , o utilizando un encabezado de actualización ), el mensaje puede incluir el dominio real del servidor.

NGINX intenta interceptar y corregir las instancias más comunes de este problema. Si necesita control total para forzar reescrituras particulares, utilice la directiva proxy_redirect de la siguiente manera:

proxy_redirect http://staging.misitio.com/ http://$host/;

Reescritura de respuestas HTTP

A veces es necesario reescribir el contenido en una respuesta HTTP. Quizás, como en el ejemplo anterior, la respuesta contenga enlaces absolutos que hagan referencia a un servidor distinto del proxy.

Puede utilizar la directiva sub_filter para definir la reescritura a aplicar:

sub_filtro /blog/ /blog-staging/;
sub_filtro_una vez desactivado;

Un problema muy común es el uso de la compresión HTTP. Si el cliente señala que puede aceptar datos comprimidos y el servidor luego comprime la respuesta, NGINX no puede inspeccionar ni modificar la respuesta. La medida más sencilla es eliminar el encabezado Accept-Encoding de la solicitud del cliente configurándolo en una cadena vacía ( "" ):

proxy_set_header Aceptar-Codificación "";

Un ejemplo completo

A continuación se muestra una plantilla para una configuración de equilibrio de carga que emplea todas las técnicas analizadas en este artículo. Las funciones avanzadas disponibles en NGINX Plus están resaltadas en naranja.

[Editor: La siguiente configuración se ha actualizado para usar la API NGINX Plus para el monitoreo de actividad en vivo y la configuración dinámica de grupos ascendentes, reemplazando los módulos separados que se usaban originalmente.]

servidor { escuchar 80; ubicación / { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_set_header Accept-Encoding ""; proxy_redirect http://staging.example.com/ http://$host/; # Reescribir el encabezado del Host con el valor en la solicitud del cliente proxy_set_header Host $host; # Reemplazar cualquier referencia en línea a staging.example.com sub_filter http://staging.example.com/ /; sub_filter_once off; } ubicación /internal-health-check1 { interno; # Evitar que las solicitudes externas coincidan con este bloque de ubicación proxy_pass http://backend; health_check interval=2s fails=1 passed=5 uri=/test.php match=statusok ; # Establecer explícitamente los parámetros de la solicitud; no usar variables de tiempo de ejecución proxy_set_header Host www.example.com; } backend ascendente { zone backend 64k ; # Usar la memoria compartida de NGINX Plus least_conn; keepalive 20; # Aplicar persistencia de sesión para este grupo ascendente sticky cookie srv_id expires=1h domain=.example.com path=/servlet ; server webserver1 weight=1; server webserver2 weight=4; } match statusok { # Usado para la comprobación de estado de /test.php status 200 ; header Content-Type = text/html ; body ~ "Server[0-9]+ is alive" ; } server { listen 8080; root /usr/share/nginx/html; location = /api { api write=on ; # Monitoreo de actividad en vivo y # configuración dinámica de grupos ascendentes allow 127.0.0.1; # permitir acceso desde localhost deny all; # denegar acceso desde cualquier otro lugar } }

Pruebe usted mismo todas las excelentes funciones de equilibrio de carga en NGINX Plus: comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .