Balanceo de carga con NGINX y NGINX Plus, parte 1

Owen GarrettDirector sénior de Gestión de Producto

NGINX es un proxy de aceleración eficaz para una amplia variedad de aplicaciones basadas en HTTP. Sus funciones de almacenamiento en caché, procesamiento de conexiones HTTP y descarga de tareas aumentan considerablemente el rendimiento de las aplicaciones, especialmente durante los periodos de alta carga.

Nota del editor: NGINX Plus versión 5 y posteriores también pueden equilibrar la carga de aplicaciones basadas en TCP. El equilibrado 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<.htmla> y posteriores, el equilibrador de carga TCP ofrece las mismas funcionalidades que el equilibrador de carga HTTP. La compatibilidad con el equilibrado 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.

NGINX Plus amplía las capacidades de NGINX añadiendo funciones adicionales de balanceo de carga: comprobaciones de estado, persistencia de sesión, supervisión de la actividad en tiempo real, y configuración dinámica de grupos de servidores con balanceo de carga.

Esta entrada de blog le guía en la configuración de NGINX para equilibrar el tráfico entre un conjunto de servidores web. También destaca algunas de las funciones adicionales de NGINX Plus.

Para obtener más información, también puede consultar la Guía de administración de NGINX Plus y el artículo que continúa este, Equilibrio de carga con NGINX y NGINX Plus, parte 2.

Proxy de tráfico con NGINX

Comenzaremos redirigiendo el tráfico mediante proxy a dos servidores web ascendentes. La siguiente configuración de NGINX basta para gestionar todas las solicitudes HTTP dirigidas al puerto 80 y reenviarlas de forma rotatoria entre los servidores web del grupo ascendente:

http {    server {
        listen 80;

        location / {
            proxy_pass http://backend;
        }
    }

    upstream backend {
        server web-server1:80;
        server web-server2:80;
    }
}

Con esta sencilla configuración, NGINX reenvía cada solicitud recibida en el puerto 80 a web-server1 y web-server2 por turnos, estableciendo una nueva conexión HTTP en cada caso.

Configurar el método de balanceo de carga

De forma predeterminada, NGINX utiliza el método Round Robin para distribuir el tráfico de manera uniforme entre los servidores, teniendo en cuenta un «peso» opcional asignado a cada servidor para indicar su capacidad relativa.

El método Hash de IP distribuye el tráfico basándose en un hash de la dirección IP de origen. Las solicitudes procedentes de la misma dirección IP de cliente se envían siempre al mismo servidor ascendente. Se trata de un método rudimentario de persistencia de sesión que se vuelve a calcular cada vez que un servidor falla o se recupera, o cuando se modifica el grupo de servidores ascendentes; NGINX Plus ofrece mejores soluciones si se requiere persistencia de sesión.

El método de Menos conexiones dirige cada solicitud al servidor ascendente con menos conexiones activas. Este método funciona bien cuando se gestiona una combinación de solicitudes rápidas y complejas.

Todos los métodos de balanceo de carga se pueden ajustar mediante un parámetro opcional weight en la directiva server. Esto resulta útil cuando los servidores tienen distintas capacidades de procesamiento. En el siguiente ejemplo, NGINX dirige cuatro veces más solicitudes a web-server2 que a web-server1:

upstream backend {    zone backend 64k;
    least_conn;

    server web-server1 weight=1;
    server web-server2 weight=4;
}

En NGINX, cada proceso de trabajo gestiona los pesos de forma independiente. NGINX Plus utiliza un segmento de memoria compartida para los datos de los servidores upstream (configurado mediante la directiva zone), por lo que los pesos se comparten entre los procesos de trabajo y el tráfico se distribuye con mayor precisión.

Detección de fallos

Si se produce un error o se agota el tiempo de espera cuando NGINX intenta conectarse a un servidor, enviarle una solicitud o leer la cabecera de respuesta, NGINX vuelve a intentar la solicitud de conexión con otro servidor. (Puede incluir la directiva proxy_next_upstream en la configuración para definir otras condiciones en las que se debe volver a intentar la solicitud). Además, NGINX puede retirar el servidor que ha fallado del conjunto de servidores disponibles y enviarle solicitudes ocasionalmente para detectar cuándo se recupera. Los parámetros max_fails y fail_timeout de la directiva server controlan este comportamiento.

NGINX Plus añade un conjunto de comprobaciones de estado fuera de banda que realizan pruebas HTTP avanzadas en cada servidor ascendente para determinar si está activo, así como un mecanismo de inicio lento para reincorporar gradualmente los servidores recuperados al grupo con equilibrio de carga:

server web-server1 slow_start=30s;

Un error habitual: corregir la cabecera Host Header

Es bastante habitual que un servidor ascendente utilice la cabecera Host de la solicitud para determinar qué contenido debe servir. Si el servidor devuelve errores 404 inesperados o cualquier otra respuesta que indique que está sirviendo un contenido incorrecto, esto es lo primero que debe comprobar. A continuación, incluya la directiva proxy_set_header en la configuración para asignar el valor adecuado a la cabecera:

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;
}

Balanceo de carga avanzado con NGINX Plus

Una serie de funciones avanzadas de NGINX Plus lo convierten en un balanceador de carga ideal para situarlo delante de grupos de servidores ascendentes:

• Equilibrado de carga y persistencia de sesión – Mejor equilibrado de carga entre procesos de trabajo y métodos de persistencia de sesión para identificar y respetar las sesiones de las aplicaciones
• Comprobación del estado HTTP y arranque lento de servidores – «Transacciones sintéticas» asíncronas para comprobar el correcto funcionamiento de cada servidor ascendente y reintroducción gradual de los servidores mediante un «arranque lento» cuando se recuperan
• Monitorización de la actividad en tiempo real – Informe inmediato de la actividad y el rendimiento
• Grupos de servidores upstream configurados dinámicamente – Herramienta que facilita algunas tareas habituales de gestión de servidores upstream, como la retirada segura y temporal de un servidor

Para obtener más información sobre el equilibrio de carga avanzado y el uso de proxies, consulte la continuación de este artículo, «Equilibrio de carga con NGINX y NGINX Plus, parte 2».

Para probar NGINX Plus, inicie hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso de balanceo de carga.

Sobre el autor

Owen GarrettDirector sénior de Gestión de Producto

Más artículos de Owen Garrett