Balanceo de carga con NGINX y NGINX Plus, parte 2

NGINX | 17 de marzo de 2014

Owen GarrettDirector sénior de Gestión de Producto

En Equilibrado de carga con NGINX y NGINX Plus, parte 1, configuramos un proxy HTTP sencillo para equilibrar la carga del tráfico entre varios servidores web. En este artículo, veremos otras funciones, algunas de ellas disponibles en NGINX Plus: optimización del rendimiento mediante conexiones persistentes, comprobaciones de estado, persistencia de sesión, redirecciones y reescritura de contenido.

Para obtener más información sobre las funciones de balanceo de carga de NGINX y NGINX Plus, consulte la Guía de administración de NGINX Plus.

Nota del 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ó considerablemente en la versión 6 con la incorporación de comprobaciones de estado, reconfiguración dinámica, terminación SSL y mucho más. En NGINX Plus versión 7 y posteriores, el equilibrador de carga TCP ofrece las mismas funcionalidades que el equilibrador de carga HTTP. La compatibilidad con el equilibrio de carga UDP se introdujo en la versión 9.

La configuración del balanceo de carga TCP y UDP se realiza en el contexto stream en lugar de en el contexto http. Las directivas y los parámetros disponibles difieren ligeramente debido a las diferencias inherentes entre HTTP y TCP/UDP. Para obtener más información, consulte la documentación de los módulos Upstream de HTTP y TCP/UDP.

Un breve repaso

A modo de repaso, esta es la configuración que creamos 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 sencillas de configurar NGINX y NGINX Plus para mejorar la eficacia del balanceo de carga.

Conexiones persistentes HTTP

Habilitar las conexiones persistentes HTTP entre NGINX o NGINX Plus y los servidores ascendentes mejora el rendimiento (al reducir la latencia) y disminuye 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 persistentes HTTP permiten reutilizar estas conexiones TCP, evitando así la sobrecarga que supone crear y cerrar una conexión para cada solicitud:

NGINX es un proxy completo y gestiona de forma independiente las conexiones de los clientes (conexiones persistentes del frontend) y las conexiones con los servidores (conexiones persistentes del upstream):

NGINX mantiene una «caché» de conexiones persistentes —un conjunto de conexiones persistentes inactivas con los servidores ascendentes— y, cuando necesita reenviar una solicitud a un servidor ascendente, utiliza una conexión persistente ya establecida de la caché en lugar de crear una nueva conexión TCP. Esto reduce la latencia de las transacciones entre NGINX y los servidores ascendentes, así como la frecuencia con la que se utilizan los puertos efímeros, lo que permite a NGINX absorber y equilibrar grandes volúmenes de tráfico. Si se produce un pico de tráfico considerable, la caché puede vaciarse, en cuyo caso NGINX establece nuevas conexiones HTTP con los servidores ascendentes.

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

La caché de conexiones persistentes se configura incluyendo 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 las comprobaciones de estado aumenta la fiabilidad de su servicio con equilibrio de carga, reduce la probabilidad de que los usuarios finales vean mensajes de error y también puede facilitar las operaciones habituales de mantenimiento.

La función de comprobación de estado de NGINX Plus permite detectar fallos en los servidores ascendentes. NGINX Plus sondea cada servidor mediante «transacciones sintéticas» y comprueba la respuesta según los parámetros configurados en la directiva health_check (y, cuando se incluye el parámetro match, en 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 location principal. Esto puede causar problemas si utiliza variables en tiempo de ejecución en su configuración. Por ejemplo, la siguiente configuración funciona con tráfico HTTP real porque extrae el valor de la cabecera Host de la solicitud del cliente. Probablemente no funcione con las transacciones sintéticas que utiliza la comprobación de estado porque la cabecera Host no está definida para ellas, lo que significa que no se utiliza ninguna cabecera 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 location ficticio que defina de forma estática todos los parámetros utilizados por la transacción de comprobació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, consulta la Guía de administración de NGINX Plus.

Persistencia de sesión

Gracias a la persistencia de sesión, las aplicaciones que no pueden implementarse en un clúster pueden equilibrar su carga y escalarse de forma fiable. Las aplicaciones que almacenan y replican el estado de la sesión funcionan de manera más eficiente y mejora el rendimiento para el usuario final.

Algunas aplicaciones almacenan en ocasiones información de estado en los servidores ascendentes, por ejemplo, cuando un usuario añade un artículo a un carrito de compra virtual o edita una imagen que ha subido. En estos casos, puede ser conveniente dirigir todas las solicitudes posteriores de ese usuario al mismo servidor.

Persistencia de sesión especifica adónde debe dirigirse una solicitud, mientras que el balanceo de carga permite a NGINX seleccionar el servidor ascendente óptimo. Ambos procesos pueden coexistir gracias a la función de persistencia de sesión de NGINX Plus:

Si la solicitud coincide con una regla de persistencia de sesión
entonces se utiliza el servidor ascendente de destino
de lo contrario se aplica el algoritmo de equilibrio de carga para seleccionar el servidor ascendente

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

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

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

En el método alternativo «ruta persistente», NGINX selecciona el servidor ascendente en función de parámetros de la 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, consulta la Guía de administración de NGINX Plus.

Reescritura de redirecciones HTTP

Reescriba las redirecciones HTTP si alguna no funciona correctamente, especialmente si observa que se le redirige desde el proxy al servidor de origen real.

Cuando se utiliza un proxy para acceder a un servidor ascendente, el servidor publica la aplicación en una dirección local, pero se accede a ella mediante una dirección diferente: la dirección del proxy. Estas direcciones suelen resolverse en nombres de dominio, y pueden surgir problemas si el servidor y el proxy tienen dominios diferentes.

Por ejemplo, en un entorno de pruebas, puede acceder directamente al proxy (mediante la dirección IP) o como localhost. Sin embargo, el servidor de origen podría escuchar en un nombre de dominio real (como www.nginx.com). Cuando el servidor de origen emite un mensaje de redirección (mediante un estado 3xx y una cabecera Location, o mediante una cabecera Refresh), el mensaje podría incluir el dominio real del servidor.

NGINX intenta interceptar y corregir los casos más habituales de este problema. Si necesita un control total para forzar determinadas reescrituras, 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 de una respuesta HTTP. Quizá, como en el ejemplo anterior, la respuesta contenga enlaces absolutos que apunten a un servidor distinto del proxy.

Puede utilizar la directiva «sub_filter» para definir la reescritura que se aplicará:

sub_filter /blog/ /blog-staging/;
sub_filter_once off;

Un problema muy habitual es el uso de la compresión HTTP. Si el cliente indica que puede aceptar datos comprimidos y el servidor comprime la respuesta, NGINX no puede inspeccionarla ni modificarla. La solución más sencilla es eliminar la cabecera Accept-Encoding de la solicitud del cliente asignándole una cadena vacía (""):

proxy_set_header Accept-Encoding "";

Un ejemplo completo

A continuación se muestra una plantilla de configuración de balanceo de carga que utiliza todas las técnicas descritas 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 utilizar la API de NGINX Plus para la supervisión de la actividad en tiempo real y la configuración dinámica de los grupos de servidores upstream, en sustitución de los módulos independientes que se utilizaban 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
    }
}