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 aplicaciones 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:

server {    listen 80;

    location / {
        proxy_pass http://backend;

        # Rewrite the 'Host' header to the value in the client request,
        # or primary server name
        proxy_set_header Host $host;

        # Alternatively, put the value in the config:
        # proxy_set_header Host www.example.com;
    } 
}

upstream backend {
    zone backend 64k;  # Use NGINX Plus' shared memory
    least_conn;

    server webserver1 weight=1;
    server webserver2 weight=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:

server {    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
     }
}

upstream backend {
    server webserver1;
    server webserver2;

    # maintain up to 20 idle connections to the group of upstream servers
    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):

server {    listen 80;

    location / {
        proxy_pass http://backend;

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

        # The health checks inherit other proxy settings
        proxy_set_header Host www.foo.com;
    }
}

match statusok {
    # Used for /test.php health check
    status 200;
    header Content-Type = text/html;
    body ~ "Server[0-9]+ is alive";
}

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;

    # This health check might not work...
    health_check interval=2s fails=1 passes=5 uri=/test.php match=statusok;

    # Extract the 'Host' header from the request
    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; # Prevent external requests from matching this location block

    proxy_pass http://backend;

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

    # Explicitly set request parameters; don't use run-time variables
    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 aplicaciones que no se pueden implementar en un clúster se pueden equilibrar y escalar de manera confiable. Las aplicaciones que almacenan y replican el estado de la sesión funcionan de manera más eficiente y mejora el rendimiento del usuario final.

Algunas aplicaciones 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:

sticky cookie srv_id expires=1h domain=.example.com path=/;

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:

upstream backend {
   server backend1.example.com route=a;
   server backend2.example.com route=b;

    # select first non-empty variable; it should contain either 'a' or 'b'
    sticky route $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 aplicación en una dirección local, pero usted accede a la aplicación 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.mysite.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_filter /blog/ /blog-staging/;
sub_filter_once off;

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 Accept-Encoding "";

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

server {
    listen 80;

    location / {
        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/;

        # Rewrite the Host header to the value in the client request
        proxy_set_header Host $host;

        # Replace any references inline to staging.example.com
        sub_filter http://staging.example.com/ /;
        sub_filter_once off;
    }

    location /internal-health-check1 {
        internal; # Prevent external requests from matching this location block
        proxy_pass http://backend;
        health_check interval=2s fails=1 passes=5 uri=/test.php match=statusok;
        # Explicitly set request parameters; don't use runtime variables
        proxy_set_header Host www.example.com;
    }
 
upstream backend {
    zone backend 64k; # Use NGINX Plus' shared memory
    least_conn;
    keepalive 20;

    # Apply session persistence for this upstream group
    sticky cookie srv_id expires=1h domain=.example.com path=/servlet;

    server webserver1 weight=1; 
    server webserver2 weight=4; 
}

match statusok {
    # Used for /test.php health check
    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; # Live activity monitoring and
                      # dynamic configuration of upstream groups

        allow 127.0.0.1; # permit access from localhost
        deny all;        # deny access from everywhere else
    }
}

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 .