Cómo elegir una técnica de balanceo de carga de NGINX Plus

Tony Mauro

Hemos escrito mucho sobre cómo puede utilizar NGINX Plus y NGINX Open Source para equilibrar la carga de sus sitios web y aplicaciones y lograr una disponibilidad y fiabilidad óptimas. El equilibrio de carga es una herramienta fundamental para mejorar el rendimiento de las aplicaciones, ofrecer aplicaciones a gran escala, y desplegar contenedores y microservicios.

Anteriormente hemos explicado cómo puede implementar NGINX Plus en el centro de datos (quizá junto con controladores de entrega de aplicaciones heredados), en contenedores, y en entornos de nube, incluidos Amazon Web Services (AWS), Google Cloud Platform, y Microsoft Azure.

En este artículo, nos centraremos en las técnicas de balanceo de carga (también denominadas métodos o algoritmos de balanceo de carga) de NGINX Plus y NGINX, y ofreceremos algunos consejos para elegir el método adecuado en función del caso de uso. NGINX proporciona cuatro técnicas de balanceo de carga (Round Robin, Hash, IP Hash y Least Connections), mientras que NGINX Plus añade una más (Least Time). Todos los métodos para el tráfico HTTP también están disponibles para TCP (y para UDP a partir de NGINX Plus Release 9), excepto IP Hash.

[Editor – NGINX Plus R16 y NGINX Open Source 1.15.1 incorporaron el algoritmo Aleatorio con dos opciones como algoritmo adicional de balanceo de carga. Para obtener más información, consulte NGINX y el algoritmo de balanceo de carga «El poder de dos opciones» en nuestro blog.]

Revisión de las técnicas de equilibrio de carga

Damos por hecho que conoces los conceptos básicos para configurar el balanceo de carga, pero puedes consultar estos recursos si quieres refrescar la memoria:

• Los artículos de la Guía de administración de NGINX Plus ofrecen una visión general completa.
• Equilibrado de carga de alto rendimiento enlaza con análisis detallados de las funciones avanzadas de NGINX Plus que pueden mejorar aún más la eficiencia de un método de equilibrado de carga.
• Balanceo de carga con NGINX y NGINX Plus, Parte 1 y Parte 2 es una guía paso a paso que convierte un sencillo proxy inverso en una solución integral de balanceo de carga gracias a las funciones avanzadas de NGINX Plus.
• La página de soluciones de equilibrio de carga incluye enlaces a otros recursos, como libros electrónicos, seminarios web y documentos técnicos.

Para simplificar, nos centraremos en el balanceo de carga HTTP, que se configura en el contexto http. En cambio, el balanceo de carga TCP se configura en el contexto stream (al igual que el balanceo de carga UDP en NGINX Plus versión 9 y posteriores). Aunque los balanceadores de carga HTTP y TCP/UDP ofrecen las mismas funcionalidades, las directivas y los parámetros disponibles difieren ligeramente debido a las diferencias inherentes entre los protocolos. Para obtener más información, consulte la documentación sobre los módulos Upstream para HTTP y TCP/UDP.

El balanceo de carga se habilita mediante dos bloques de configuración, que mostraremos en su forma básica, sin parámetros opcionales ni funciones auxiliares:

• El bloque server define un servidor virtual que escucha el tráfico con las características especificadas y lo reenvía a un grupo con nombre de servidores ascendentes. En nuestros ejemplos, el servidor virtual escucha en el puerto predeterminado (80) el tráfico HTTP enviado a www.example.com y lo reenvía al grupo de servidores ascendentes denominado backend. Este bloque es el mismo en todos nuestros ejemplos.

server {    server_name www.example.com;

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

• (NGINX Plus y NGINX también pueden equilibrar la carga de servidores backend FastCGI, memcached, SCGI y uwsgi. Sustituya proxy_pass por la directiva correspondiente: fastcgi_pass, memcached_pass, scgi_pass o uwsgi_pass.)
• El bloque upstream asigna un nombre a un grupo de servidores upstream y enumera los servidores que pertenecen a él, identificados por el nombre de host, la dirección IP o la ruta del socket de dominio UNIX. En nuestros ejemplos, el grupo upstream denominado backend incluye tres servidores: web1, web2 y web3. El bloque upstream es donde se especifica la técnica de balanceo de carga, por lo que la destacaremos en las secciones siguientes. A modo de ejemplo, este es el bloque correspondiente al método predeterminado, Round Robin:

upstream backend {    server web1;
    server web2;
    server web3;
}

Turno rotatorio

Round Robin es la técnica de balanceo de carga predeterminada tanto para NGINX Plus como para NGINX. El balanceador de carga recorre secuencialmente la lista de servidores upstream y asigna por turnos la siguiente solicitud de conexión a cada uno de ellos.

Dada la siguiente configuración de ejemplo del grupo de servidores upstream backend, el balanceador de carga envía las tres primeras solicitudes de conexión a web1, web2 y web3, en ese orden; la cuarta, a web1; la quinta, a web2; y así sucesivamente.

upstream backend {    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Hash

Con el método Hash, para cada solicitud el equilibrador de carga calcula un hash basado en la combinación de texto y variables de NGINX que especifique, y asocia el hash a uno de los servidores. Envía todas las solicitudes con ese hash a dicho servidor, por lo que este método establece un tipo básico de persistencia de sesión.

En el siguiente ejemplo, la directiva hash utiliza el esquema (http o https) y el URI completo de la solicitud como base para el hash:

upstream backend {    hash $scheme$request_uri;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Hash de IP

Hash de IP (disponible solo para HTTP) es una variante predefinida del método Hash, en la que el hash se basa en la dirección IP del cliente. Se configura con la directiva ip_hash.

upstream backend {    ip_hash;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Si el cliente tiene una dirección IPv6, el hash se basa en la dirección completa. Si tiene una dirección IPv4, el hash se basa únicamente en los tres primeros octetos de la dirección. Esto está diseñado para optimizar el funcionamiento con clientes de proveedores de servicios de Internet a los que se asignan direcciones IP dinámicamente dentro del intervalo de una subred (/24). En caso de reinicio o reconexión, la dirección del cliente suele cambiar por otra dentro del intervalo de la red /24, pero la conexión sigue correspondiendo al mismo cliente, por lo que no hay motivo para cambiar su asignación al servidor.

Sin embargo, si la mayor parte del tráfico de su sitio procede de clientes de la misma red /24, IP Hash no resulta adecuado, ya que asigna todos los clientes al mismo servidor. En ese caso (o si, por algún otro motivo, desea calcular el hash a partir de los cuatro octetos), utilice en su lugar el método Hash con la variable $remote_addr.

hash $remote_addr;

Menor número de conexiones

Con el método de conexiones mínimas, el balanceador de carga compara el número actual de conexiones activas que mantiene con cada servidor y envía la solicitud al servidor con menos conexiones. Se configura mediante la directiva least_conn.

upstream backend {
    least_conn;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Menor tiempo

Con el método Least Time (disponible únicamente en NGINX Plus), el balanceador de carga combina matemáticamente dos métricas de cada servidor —el número actual de conexiones activas y el promedio ponderado del tiempo de respuesta de solicitudes anteriores— y envía la solicitud al servidor con el valor más bajo.

El parámetro que elija en la directiva least_time determina cuál de los dos tiempos de respuesta se registra: el tiempo necesario para recibir la cabecera de respuesta (header) o el tiempo necesario para recibir la respuesta completa (last_byte).

upstream backend {    least_time (header | last_byte);

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Notas:

• Para el balanceo de carga TCP y UDP (en el contexto stream), puede elegir entre tres tipos de tiempo de respuesta mediante estos parámetros de la directiva least_time:
  • connect – Tiempo necesario para conectarse al servidor ascendente
  • first_byte – Tiempo hasta recibir el primer byte de los datos de respuesta
  • last_byte – Tiempo hasta recibir el último byte de los datos de respuesta
• Tanto para el tráfico HTTP como para el tráfico TCP/UDP, en NGINX Plus R12 y versiones posteriores, añada el parámetro «inflight» para incluir las conexiones incompletas en cada métrica; en versiones anteriores, estas conexiones se incluyen de forma predeterminada.

Elegir una técnica de balanceo de carga

Entonces, ¿cómo saber cuál de las técnicas de equilibrio de carga es la más adecuada para tu sitio web o aplicación?

Los patrones de tráfico varían tanto de un sitio a otro —e incluso dentro de un mismo sitio según la hora del día— que no tiene sentido basar la elección de la técnica de balanceo de carga en una única característica (como tráfico con picos frente a tráfico constante, conexiones de corta duración frente a conexiones de larga duración, etc.). Dicho esto, analizaremos las ventajas y desventajas de cada método para ayudarle a acotar las opciones que debe considerar.

Realización de pruebas para comparar métodos

Sea cual sea el subconjunto de métodos de balanceo de carga que esté considerando, le recomendamos que los pruebe para determinar cuál funciona mejor con su tráfico. «Mejor» suele significar el menor tiempo de entrega de respuestas a los clientes, aunque puede que sus criterios sean distintos.

Gestión del rendimiento de aplicaciones son herramientas muy útiles para este tipo de pruebas: puede crear pantallas personalizadas con gráficos para cada uno de los servidores del grupo de servidores ascendentes, lo que permite compararlos en tiempo real a medida que cambian los valores durante la prueba. Varias soluciones de APM ofrecen complementos personalizados para NGINX Plus y NGINX, entre ellas AppDynamics, Datadog, Dynatrace y New Relic.

Las pruebas son más sencillas si todos los servidores tienen la misma capacidad. De lo contrario, debe configurar los pesos de los servidores para que las máquinas con mayor capacidad reciban más solicitudes. Consulte Configurar pesos cuando los servidores no son idénticos más adelante.

Algunas métricas que conviene comprobar durante las pruebas son:

• Carga de CPU y memoria: compruebe el porcentaje de la capacidad total utilizada tanto de la CPU como de la memoria. Si la carga no se distribuye por igual entre todos los servidores, el tráfico no se está distribuyendo de forma eficiente.
• Tiempo de respuesta del servidor – Si el tiempo es sistemáticamente mayor en unos servidores que en otros, significa que, de algún modo, se están dirigiendo hacia ellos de forma desequilibrada solicitudes más «pesadas» (que requieren más capacidad de procesamiento o más llamadas a una base de datos u otros servicios). Pruebe a ajustar las ponderaciones, ya que el desequilibrio podría deberse a que estas son incorrectas y no a un problema con la técnica de balanceo de carga.
• Tiempo total de respuesta al cliente – De nuevo, si algunos servidores presentan sistemáticamente tiempos más elevados, es probable que estén recibiendo una proporción excesiva de solicitudes que requieren mucho tiempo. También en este caso, puede probar a ajustar los pesos para comprobar si así se soluciona el problema.
• Errores y solicitudes fallidas – Debe asegurarse de que el número de solicitudes fallidas y otros errores durante las pruebas no sea superior al habitual en su sitio. De lo contrario, estará basando su decisión en condiciones de error en lugar de en un tráfico realista. En el caso de algunos errores, el servidor puede enviar su respuesta más rápidamente que cuando la solicitud se procesa correctamente. Por ejemplo, para el código de respuesta HTTP 404 (Archivo no encontrado), es probable que el servidor devuelva el error mucho más rápidamente de lo que podría entregar el archivo real si existiera. Con los algoritmos de balanceo de carga de Menos conexiones y Menor tiempo, esto puede hacer que el balanceador de carga favorezca a un servidor que, en realidad, no funciona correctamente.

Ventajas, desventajas y casos de uso

Veamos ahora las ventajas y desventajas de cada técnica de balanceo de carga y describamos algunos casos de uso para los que resultan especialmente adecuadas. Las analizaremos en orden creciente de idoneidad para la mayoría de los casos de uso. A modo de adelanto: consideramos que Menos conexiones (y, en el caso de NGINX Plus, Menor tiempo) son las mejores opciones para la gama más amplia de casos de uso.

Hash y hash de IP

Las técnicas de equilibrio de carga Hash e IP Hash crean una asociación fija entre un determinado tipo de solicitud del cliente (reflejado en el valor hash) y un servidor concreto. Esto se conoce como persistencia de sesión: todas las solicitudes con un valor hash determinado se dirigen siempre al mismo servidor.

El mayor inconveniente de estos métodos es que no garantizan que las solicitudes se distribuyan en igual número entre los servidores, y mucho menos que la carga se reparta de manera uniforme. El algoritmo de hash divide uniformemente el conjunto de todos los valores hash posibles en «grupos», uno por cada servidor del grupo de servidores upstream, pero no hay forma de predecir si las solicitudes que realmente se produzcan tendrán valores hash distribuidos de manera uniforme. Supongamos, por ejemplo, que diez clientes acceden a un sitio y que el algoritmo IP Hash asocia el hash de siete de las direcciones IP con web1, el de una con web2 y los de dos con web3. El servidor web1 acaba recibiendo más del doble de solicitudes que todos los demás servidores juntos.

Por tanto, tiene sentido usar Hash o IP Hash cuando las ventajas de mantener las sesiones compensan los posibles efectos negativos de una carga desequilibrada. Son la única forma de persistencia de sesión disponible en NGINX. NGINX Plus ofrece otros tres mecanismos de persistencia de sesión más sofisticados que funcionan junto con el balanceo de carga propiamente dicho (se configuran mediante la directiva sticky). Sin embargo, incluso con NGINX Plus, puede optar por Hash o IP Hash, ya que estos tres mecanismos no funcionan en los siguientes casos:

• El navegador o la aplicación cliente no acepta cookies y la aplicación no puede utilizar los mecanismos de persistencia de sesión sin ellas. Utilice el método IP Hash para asociar cada cliente (en concreto, su dirección IP) a un servidor determinado.
• Quiere enviar siempre las solicitudes de una URL determinada al mismo servidor para aprovechar el almacenamiento en caché del propio servidor. Utilice el método Hash con la variable $request_uri para obtener siempre el archivo del mismo servidor. Por ejemplo, supongamos que sabe que servir un determinado archivo .php requiere varias llamadas a la base de datos que consumen mucho tiempo, pero los datos obtenidos no cambian con frecuencia y, por tanto, se pueden almacenar en caché. Si dirige todas las solicitudes del archivo al mismo servidor, solo el primer cliente experimentará una demora prolongada debido a las llamadas a la base de datos. Para todos los clientes posteriores, los datos se recuperarán rápidamente de la caché. Otra ventaja es que solo ese servidor tendrá que almacenar en caché ese conjunto concreto de datos. Como no se almacenan en caché los mismos datos por duplicado en todos los servidores, puede utilizar cachés más pequeñas.

Hay un par de casos en los que IP Hash —y Hash cuando la dirección IP del cliente forma parte de la clave— no funcionan:

• Cuando la dirección IP del cliente puede cambiar durante la sesión, por ejemplo, cuando un cliente móvil pasa de una red WiFi a una red móvil.
• Cuando las solicitudes de un gran número de clientes pasan por un proxy directo, ya que se utiliza la dirección IP del proxy para todos ellos.

Los hashes son deterministas (el algoritmo de hash produce siempre los mismos resultados). Esto tiene un par de efectos secundarios positivos: todas las instancias de NGINX Plus o NGINX de un despliegue equilibran las solicitudes exactamente de la misma manera, y la asignación de hashes a servidores se mantiene tras reiniciar el balanceador de carga. (En realidad, se vuelve a calcular después del reinicio, pero, como el resultado es siempre el mismo, en la práctica se mantiene).

Por otro lado, cambiar el conjunto de servidores ascendentes suele obligar a recalcular al menos algunas de las asignaciones, lo que interrumpe la persistencia de las sesiones. Puede reducir en cierta medida el número de asignaciones que se recalculan:

• Para el método Hash, incluya el parámetro consistent en la directiva hash; NGINX Plus utiliza el algoritmo hash ketama, lo que reduce las reasignaciones.
• Para el método Hash de IP, antes de retirar temporalmente un servidor del grupo de servidores ascendentes, añada el parámetro down a su directiva server, como en el caso de web2 en el siguiente ejemplo. Las asignaciones no se vuelven a calcular, ya que se presupone que el servidor volverá a estar operativo pronto.

upstream backend {    ip_hash;

    server web1;
    server web2 down;
    server web3;
}

Turno rotatorio

Como se ha indicado anteriormente, Round Robin es el método de balanceo de carga predeterminado en NGINX Plus y NGINX. Esto lo convierte, sin duda, en el método más fácil de elegir, ya que no es necesario configurar nada aparte del propio grupo upstream.

El consenso general es que Round Robin funciona mejor cuando es poco probable que las características de los servidores y las solicitudes provoquen que algunos servidores se sobrecarguen en comparación con otros. Algunas de estas condiciones son:

• Todos los servidores tienen aproximadamente la misma capacidad. Este requisito es menos importante si las diferencias entre los servidores se reflejan con precisión mediante sus ponderaciones.
• Todos los servidores alojan el mismo contenido.
• Las solicitudes son bastante similares en cuanto al tiempo o la capacidad de procesamiento que requieren. Si el peso de las solicitudes varía mucho, un servidor puede sobrecargarse si el equilibrador de carga le envía por casualidad muchas solicitudes pesadas en rápida sucesión.
• El volumen de tráfico no es lo bastante elevado como para que los servidores se acerquen con frecuencia a su capacidad máxima. Si los servidores ya soportan una carga elevada, es más probable que la distribución mecánica de solicitudes de Round Robin lleve a algunos servidores «al límite» y los sobrecargue, como se describe en el punto anterior.

Round Robin es especialmente adecuado para entornos de prueba, ya que garantiza que las solicitudes se distribuyan entre todos los servidores en cantidades iguales (o según la proporción ponderada correspondiente). Otros métodos no siempre distribuyen el tráfico de manera uniforme cuando el volumen es bajo, lo que puede sesgar los resultados de las pruebas.

La uniformidad de la distribución también puede revelar si las cachés funcionan correctamente y a pleno rendimiento: como con Round Robin no hay forma de enviar las solicitudes de un archivo determinado al mismo servidor, es probable que cada servidor acabe sirviendo y almacenando en caché una amplia variedad de archivos (y, por lo general, muchos de los mismos archivos que los demás servidores), lo que aumenta la probabilidad de que la caché se llene.

Por último, la distribución inicial uniforme ayuda a detectar problemas con la persistencia de las sesiones en NGINX Plus (según la configuración establecida mediante la directiva sticky).

Menor número de conexiones y menor tiempo

Como mencionamos anteriormente, el método de menos conexiones es la técnica de balanceo de carga más adecuada para la mayor variedad de casos de uso, especialmente para el tráfico de producción. Así lo demuestra la experiencia de nuestros clientes. Su rendimiento es estable y predecible.

El método de menos conexiones también distribuye eficazmente la carga de trabajo entre los servidores en función de su capacidad. Un servidor más potente atiende las solicitudes con mayor rapidez, por lo que, en un momento dado, es probable que tenga menos conexiones aún en proceso (o incluso a la espera de que comience su procesamiento) que un servidor con menor capacidad. El método de menos conexiones envía cada solicitud al servidor con el menor número de conexiones activas, por lo que es más probable que las envíe a servidores potentes. (No obstante, asignar pesos permite distribuir las solicitudes de forma aún más eficiente, como se explica más adelante en Asignación de pesos cuando los servidores no son idénticos.)

Puede considerar Least Time (solo en NGINX Plus) una versión más sensible de Least Connections. Al incluir el tiempo medio de respuesta, tiene en cuenta el historial de rendimiento reciente del servidor (en realidad, se trata de una media móvil ponderada exponencialmente, por lo que los tiempos de respuesta más antiguos influyen menos en la media que los más recientes).

Least Time resulta especialmente adecuado cuando los servidores ascendentes tienen tiempos medios de respuesta muy diferentes. Si, por ejemplo, dispone de servidores en distintos centros de datos con fines de recuperación ante desastres, Least Time tiende a enviar más solicitudes a los servidores locales porque responden más rápido. Otro caso de uso son los entornos de nube, donde el rendimiento de los servidores suele ser muy impredecible.

Configurar pesos cuando los servidores no son idénticos

Ya hemos mencionado varias veces la importancia de asignar pesos a los servidores cuando los servidores del grupo de upstream tienen capacidades diferentes. Esto es especialmente importante para el balanceador de carga Round Robin, ya que, de lo contrario, envía el mismo número de solicitudes a cada servidor. Es probable que esto provoque que un servidor menos potente se sobrecargue mientras otro más potente permanece parcialmente inactivo.

Para establecer pesos, incluya el parámetro weight en una o varias directivas server del bloque upstream. El valor predeterminado es 1.

Puede entender el efecto de configurar pesos para las distintas técnicas de balanceo de carga de la siguiente manera. Tenga en cuenta que las descripciones son correctas desde el punto de vista conceptual, pero la implementación en el código de NGINX Plus no utiliza necesariamente las operaciones matemáticas indicadas. Este es el grupo upstream que utilizaremos en nuestros ejemplos:

upstream backend {    server web1 weight=6;
    server web2 weight=3;
    server web3;
}

• Round Robin – Cada servidor recibe un porcentaje de las solicitudes entrantes equivalente a su peso dividido entre la suma de los pesos. En nuestro ejemplo, de cada diez solicitudes, web1 recibe seis (60 %), web2 recibe tres (30 %) y web3 recibe una (10 %).
• Hash e IP Hash – Recuerde que, sin ponderaciones, el algoritmo de hash divide uniformemente el conjunto de todos los valores hash posibles en «buckets», uno por cada servidor del grupo de servidores upstream. Con ponderaciones, suma las ponderaciones, divide el conjunto de hashes posibles entre ese número de buckets y asigna a cada servidor tantos buckets como indique su ponderación. En nuestro ejemplo, hay diez buckets, cada uno con el 10 % de los hashes posibles. Seis buckets (el 60 % de los hashes posibles) están asociados a web1, tres buckets (el 30 %) a web2 y un bucket (el 10 %) a web3.
• Menos conexiones y Menor tiempo – Como mencionamos anteriormente, incluso sin ponderaciones, estos algoritmos son bastante eficaces a la hora de distribuir la carga de trabajo entre los servidores según su capacidad. La asignación de ponderaciones mejora aún más su rendimiento en este sentido. Recordemos que Menos conexiones y Menor tiempo envían cada solicitud al servidor con la «puntuación» más baja (el número de conexiones o una combinación matemática de conexiones y tiempo, respectivamente). Al asignar ponderaciones, el equilibrador de carga divide la puntuación de cada servidor entre su ponderación y, de nuevo, envía la solicitud al servidor con el valor más bajo. Este es un ejemplo de Menos conexiones con nuestras ponderaciones de muestra y el número indicado de conexiones activas: web1 tiene la puntuación más baja, 100, y recibe la solicitud, aunque su número de conexiones, 600, es 1,5 veces el de web2 y más de 4 veces el de web3.
  • web1 – 600 conexiones activas ÷ 6 = 100
  • web2 – 400 conexiones activas ÷ 3 = 133
  • web3 – 125 conexiones activas ÷ 1 = 125

Resumen

Tras analizar las ventajas y desventajas de las técnicas de equilibrio de carga disponibles en NGINX Plus y NGINX, consideramos que el método de menos conexiones (y, en el caso de NGINX Plus, el de menor tiempo) es el más adecuado para la mayor variedad de casos de uso. No obstante, es importante probar varios métodos en su implementación, ya que su combinación específica de tráfico y características de los servidores podría hacer que otro método resultase más adecuado.

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

Nos encantaría conocer sus experiencias con el balanceo de carga en distintos casos de uso. Compártalas en la sección de comentarios que aparece a continuación.

Sobre el autor

Tony Mauro

Más artículos de Tony Mauro