F5 NGINX Plus: equilibrio de carga

Equilibrio de la carga HTTP

Al equilibrar la carga del tráfico HTTP, NGINX Plus finaliza todas las conexiones HTTP y procesa cada solicitud de forma individual. Puede eliminar el cifrado SSL/TLS, inspeccionar y manipular la solicitud, ponerla en cola con límites de velocidad y, después, seleccionar la política de equilibrio de carga.

Para mejorar el rendimiento, NGINX Plus puede aplicar una amplia gama de optimizaciones a una transacción HTTP de forma automática, incluidas las actualizaciones del protocolo HTTP, la optimización de keepalive y transformaciones como la compresión del contenido y el almacenamiento en caché de respuestas.

Equilibrar la carga de tráfico HTTP es muy fácil con NGINX Plus:

http {
    upstream my_upstream {
        server server1.example.com;
        server server2.example.com;
    }

    server {
        listen 80;
        location / {
            proxy_set_header Host $host;
            proxy_pass http://my_upstream;
        }
    }
}

Primero, especifique un servidor virtual con la directiva server y, después, especifique el puerto de escucha del tráfico (listen). Haga que las direcciones URL de las solicitudes de los clientes se correspondan con un bloque location, establezca el encabezado Host con la directiva proxy_set_header e incluya la directiva proxy_pass para reenviar la solicitud a un grupo ascendente. (El bloque upstream define los servidores en los que NGINX Plus equilibra la carga de tráfico).

Para obtener más información, compruebe esta introducción para equilibrar la carga con NGINX y NGINX Plus.

Equilibrio de carga de TCP y UDP

NGINX Plus también puede equilibrar la carga de aplicaciones TCP, como MySQL, y de aplicaciones UDP, como DNS y RADIUS. Para las aplicaciones TCP, NGINX Plus finaliza las conexiones TCP y crea nuevas conexiones con el backend.

stream {
    upstream my_upstream {
        server server1.example.com:1234;
        server server2.example.com:2345;
    }

    server {
        listen 1123 [udp];
        proxy_pass my_upstream;
    }
}

La configuración es similar a la de HTTP: especifique un servidor virtual con la directiva server, aplique listen para el tráfico en un puerto y use la directiva proxy_pass para pasar la solicitud a un grupo upstream.

Para obtener más información sobre el equilibrio de carga de TCP y UDP, consulte la Guía de gestión de NGINX Plus.

Métodos de equilibrio de carga

NGINX Plus admite diversos métodos de equilibrio de carga de aplicaciones para HTTP, TCP y UDP. Todos ellos tienen en cuenta el valor weight que puede asignar de manera opcional a cada servidor ascendente.

• Round Robin (predeterminado): distribuye las solicitudes entre los servidores ascendentes en orden.
• Menos conexiones: reenvía las solicitudes al servidor con el menor número de conexiones activas.
• Menos tiempo: reenvía las solicitudes al servidor con menos carga, basándose en un cálculo que combina el tiempo de respuesta y el número de conexiones activas. Exclusivo de NGINX Plus.
• Hash: distribuye las solicitudes en función de una clave específica, por ejemplo, la dirección IP del cliente o la dirección URL de la solicitud. Opcionalmente, NGINX Plus puede aplicar un hash uniforme para minimizar la redistribución de las cargas si el conjunto de servidores ascendentes cambia.
• Hash IP (solo HTTP): distribuye las solicitudes en función de los tres primeros octetos de la dirección IP del cliente.
• Aleatorio con dos selecciones: elige dos servidores de forma aleatoria y reenvía la solicitud al que tenga el número más bajo de conexiones activas (método de menos conexiones). Con NGINX Plus, también se puede usar el método de menos tiempo.

Limitación de las conexiones con NGINX Plus

Puede limitar el número de conexiones que NGINX Plus establece con los servidores TCP o HTTP ascendentes, o bien el número de sesiones con los servidores UDP. Cuando el número de conexiones o sesiones con un servidor supera un límite definido, NGINX Plus deja de establecer nuevas conexiones.

En el fragmento de código de configuración siguiente, el límite de conexiones es de 250 para webserver1 y de 150 para webserver2. La directiva queue especifica el número máximo de conexiones en exceso que NGINX Plus coloca en la cola de escucha del sistema operativo durante un máximo de 30 segundos cada una; las solicitudes en exceso adicionales se eliminan.

upstream backend {
    zone backends 64k;
    queue 750 timeout=30s;

    server webserver1 max_conns=250;
    server webserver2 max_conns=150;
}

Cuando el número de conexiones activas de un servidor queda por debajo de su límite, NGINX Plus envía las conexiones desde la cola. La limitación de las conexiones ayuda a garantizar un servicio coherente y predecible de las solicitudes de los clientes, incluso durante los picos de tráfico.

Persistencia de sesión

Puede configurar NGINX Plus para identificar las sesiones de usuario y enviar todas las solicitudes de una sesión al mismo servidor ascendente. Esto es esencial cuando los servidores de aplicaciones almacenan el estado de forma local, ya que cuando se envía una solicitud para una sesión de usuario en curso a un servidor distinto se producen errores irrecuperables. La persistencia de sesión también puede mejorar el rendimiento cuando las aplicaciones comparten información en un clúster.

Además de la persistencia de sesión basada en hash compatible con NGINX Open Source (métodos de equilibrio de carga Hash y Hash IP), NGINX Plus admite persistencia de sesión basada en cookies, incluido el método sticky cookie. NGINX Plus agrega una cookie de sesión a la primera respuesta del grupo ascendente a un cliente dado, lo que identifica de forma segura qué servidor ha generado la respuesta. Las solicitudes del cliente posteriores incluyen la cookie, que NGINX Plus utiliza para enrutar la solicitud al mismo servidor ascendente:

upstream backend {
    server webserver1;
    server webserver2;

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

En el ejemplo anterior, NGINX Plus inserta una cookie llamada srv_id en la respuesta de cliente inicial para identificar el servidor que ha gestionado la respuesta. Cuando una solicitud posterior contiene la cookie, NGINX Plus la reenvía al mismo servidor.

NGINX Plus también admite los métodos de persistencia de aprendizaje persistente y ruta persistente.

Nota: La persistencia de sesión basada en cookies es exclusiva de NGINX Plus.

Comprobaciones de estado activas

De forma predeterminada, NGINX realiza comprobaciones básicas en las respuestas procedentes de servidores ascendentes y vuelve a probar las solicitudes con errores cuando es posible. NGINX Plus agrega comprobaciones de estado de aplicaciones fuera de banda (lo que también se conoce como transacciones sintéticas) y una función de inicio lento para agregar servidores nuevos y recuperados al grupo de carga equilibrada sin problemas.

Estas características permiten que NGINX Plus pueda detectar y evitar una variedad de problemas mucho mayor, lo que mejora significativamente la fiabilidad de sus aplicaciones HTTP y TCP/UDP.

upstream my_upstream {
	zone my_upstream 64k;
	server server1.example.com slow_start=30s;
}

server {
    # ...
    location /health {
        internal;
        health_check interval=5s uri=/test.php match=statusok;
        proxy_set_header Host www.example.com;
        proxy_pass http://my_upstream
    }
}

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

En el ejemplo siguiente, NGINX Plus envía una solicitud para /test.php cada cinco segundos. El bloque match define las condiciones que la respuesta debe cumplir para que se considere que el servidor ascendente está en buen estado: un código de estado de 200 OK y un cuerpo de respuesta que contenga el texto ServerN is alive.

Nota: Las comprobaciones de estado activas son exclusivas de NGINX Plus.

Detección de servicios con DNS

De forma predeterminada, los servidores NGINX Plus resuelven los nombres DNS al inicio y almacenan en caché los valores resueltos de forma persistente. Cuando usa un nombre de dominio como example.com para identificar un grupo de servidores ascendentes con la directiva server y el parámetro resolve, NGINX Plus vuelve a resolver de forma periódica el nombre de dominio. Si la lista de direcciones IP asociada ha cambiado, NGINX Plus comienza a aplicar inmediatamente el equilibrio de carga en el grupo de servidores actualizado.

Para configurar NGINX Plus a fin de que use registros SRV de DNS, incluya la directiva resolver junto con el parámetro service=http en la directiva server, tal y como se muestra:

resolver 127.0.0.11 valid=10s;

upstream service1 {
    zone service1 64k;
    server service1 service=http resolve;
}

En el ejemplo anterior, NGINX Plus consulta 127.0.0.11 (el servidor DNS de Docker integrado) cada 10 segundos para volver a resolver el nombre de dominio service1.

Nota: La detección de servicios con DNS es exclusiva de NGINX Plus.

API de NGINX Plus

NGINX Plus incluye una API RESTful con un solo punto de conexión de API. Use la API de NGINX Plus para actualizar sobre la marcha las configuraciones ascendentes y los almacenes de clave-valor sin tiempo de inactividad.

El fragmento de código de configuración siguiente incluye la directiva api para habilitar el acceso de lectura-escritura en el punto de conexión /api.

upstream backend {
    zone backends 64k;
    server 10.10.10.2:220 max_conns=250;
    server 10.10.10.4:220 max_conns=150;
}

server {
    listen 80;
    server_name www.example.org;

    location /api {
        api write=on;
    }
}

Con la API habilitada como en el ejemplo anterior, puede agregar un nuevo servidor a un grupo ascendente que ya exista con el comando curl siguiente. Se utiliza el método POST y codificación JSON para establecer la dirección IP del servidor en 192.168.78.66, su valor weight en 200 y el número máximo de conexiones simultáneas en 150. (Para versión, sustituya el número de versión actual de la API tal y como se especifica en la documentación de referencia.)

$ curl -iX POST -d '{"server":"192.168.78.66:80","weight":"200","max_conns":"150"}' http://localhost:80/api/versión/http/upstreams/backend/servers/

Para mostrar la configuración completa de todos los servidores ascendentes de backend en formato JSON, ejecute:

$ curl -s http://localhost:80/api/versión/http/upstreams/backend/servers/ | python -m json.tool
	{
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 0,
      "max_conns": 250,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.2:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 1,
      "max_conns": 150,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.4:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 2,
      "max_conns": 200,
      "max_fails": 1,
      "route": "",
      "server": "192.168.78.66:80",
      "slow_start": "0s",
      "weight": 200
      }

Para modificar la configuración de un servidor ascendente ya existente, identifíquelo mediante su ID interno, que aparece en el campo id de la salida anterior. El comando siguiente utiliza el método PATCH para reconfigurar el servidor con ID 2 y configura su dirección IP y puerto de escucha en 192.168.78.55:80, su valor weight en 500 y el límite de conexiones en 350.

$ curl -iX PATCH -d '{"server":"192.168.78.55:80","weight":"500","max_conns":"350"}' http://localhost:80/api/versión/http/upstreams/backend/servers/2

Puede acceder a la documentación completa de Swagger (Especificaciones de OpenAPI) de la API de NGINX Plus en https://demo.nginx.com/swagger-ui/.

Nota: La API de NGINX Plus es exclusiva de NGINX Plus.