Elección de una técnica de equilibrio de carga NGINX Plus

Hemos escrito mucho sobre cómo puedes usar NGINX Plus y NGINX Open Source para equilibrar la carga de tus sitios web y aplicaciones para lograr una disponibilidad y confiabilidad óptimas. El equilibrio de carga es una herramienta fundamental para mejorar el rendimiento de las aplicaciones , entregar aplicaciones a escala e implementar contenedores y microservicios .

Anteriormente explicamos cómo se puede implementar NGINX Plus en el centro de datos (quizás junto con controladores de entrega de aplicação heredadas), en contenedores y en entornos de nube, incluidos Amazon Web Services (AWS), Google Cloud Platform y Microsoft Azure .

En esta publicación, nos centraremos en las técnicas de equilibrio de carga (también llamadas métodos o algoritmos de equilibrio de carga) en NGINX Plus y NGINX, ofreciendo algunos consejos sobre cómo elegir el método correcto para diferentes casos de uso. NGINX proporciona cuatro técnicas de equilibrio de carga ( Round Robin , Hash , IP Hash y Least Connections ), y NGINX Plus agrega una más ( Least Time ). Todos los métodos para el tráfico HTTP también están disponibles para TCP (y UDP, en NGINX Plus versión 9 y posteriores), excepto IP Hash.

[ Editor – NGINX Plus R16 y NGINX Open Source 1.15.1 introdujeron Random with Two Choices como un algoritmo de equilibrio de carga adicional. Para obtener más información al respecto, consulte NGINX y el algoritmo de equilibrio de carga “Poder de dos opciones” en nuestro blog.]

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

Damos por sentado que conoces los conceptos básicos de cómo configurar el equilibrio de carga, pero puedes consultar estos recursos si quieres un repaso:

• Los artículos de la Guía de administración de NGINX Plus proporcionan una descripción general completa.
• Los enlaces de equilibrio de carga de alto rendimiento conducen a debates detallados sobre las características mejoradas de NGINX Plus que pueden mejorar aún más la eficiencia de un método de equilibrio de carga.
• Equilibrio de carga con NGINX y NGINX Plus , Parte 1 y Parte 2 es un tutorial que convierte un proxy inverso simple en una solución integral de equilibrio de carga con las funciones mejoradas de NGINX Plus.
• La página Soluciones de equilibrio de carga contiene enlaces a otros recursos, incluidos libros electrónicos, seminarios web y documentos técnicos.

Para simplificar, nos centraremos en el equilibrio de carga HTTP, que se configura en el contexto http . El equilibrio de carga TCP se configura en el contexto del flujo (al igual que el equilibrio de carga UDP en NGINX Plus versión 9 y posteriores). Aunque los balanceadores de carga HTTP y TCP/UDP tienen paridad de características, las directivas y parámetros disponibles difieren un poco debido a diferencias inherentes entre los protocolos; para obtener más detalles, consulte la documentación sobre los módulos Upstream para HTTP y TCP/UDP .

El equilibrio de carga se habilita con dos bloques de configuración, que mostraremos en su forma básica, sin parámetros opcionales ni características auxiliares:

• El bloque de servidor define un servidor virtual que escucha el tráfico con las características que usted define y lo envía a un grupo designado 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 envía al grupo de servidores ascendentes llamado backend . Este bloque es el mismo en todos nuestros ejemplos.

  servidor { nombre_servidor www.ejemplo.com;
  
  ubicación / {
  contraseña_proxy http://backend;
  }
  }

  (NGINX Plus y NGINX también pueden equilibrar la carga de los servidores backend FastCGI, memcached, SCGI y uwsgi. Reemplace proxy_pass con la directiva adecuada: fastcgi_pass , memcached_pass , scgi_pass o uwsgi_pass .)

• El bloque ascendente nombra un grupo ascendente y enumera los servidores que pertenecen a él, identificados por nombre de host, dirección IP o ruta de socket de dominio UNIX. En nuestros ejemplos, el grupo ascendente denominado backend incluye tres servidores: web1 , web2 y web3 .

  El bloque ascendente es donde se especifica la técnica de equilibrio de carga, por lo que lo destacaremos en las secciones siguientes. A modo de ejemplo, aquí está el bloque para el método predeterminado, Round Robin:

  backend ascendente { servidor web1;
  servidor web2;
  servidor web3;
  }

Round Robin

Round Robin es la técnica de balanceo de carga predeterminada tanto para NGINX Plus como para NGINX. El balanceador de carga recorre la lista de servidores ascendentes en secuencia, asignando la siguiente solicitud de conexión a cada uno, por turno.

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

backend ascendente { servidor web1;
servidor web2;
servidor web3;
}

servidor {
nombre_del_servidor www.ejemplo.com;

ubicación / {
contraseña_del_proxy http://backend;
}
}

Picadillo

Con el método Hash, para cada solicitud, el balanceador de carga calcula un hash que se basa en la combinación de texto y variables NGINX que usted especifique, y asocia el hash con uno de los servidores. Envía todas las solicitudes con ese hash a ese 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:

backend ascendente { hash $scheme$request_uri; servidor web1; servidor web2; servidor web3; } servidor { nombre_servidor www.example.com; ubicación / { contraseña_proxy http://backend; } }

Hash de IP

IP Hash (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. Lo configuras con la directiva ip_hash .

backend ascendente { ip_hash ; servidor web1; servidor web2; servidor web3; } servidor { nombre_servidor www.ejemplo.com; ubicación / { contraseña_proxy 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 solo en los primeros tres octetos de la dirección. Esto está diseñado para optimizar para clientes ISP a quienes se les asignan direcciones IP dinámicamente desde un rango de subred (/24). En caso de reinicio o reconexión, la dirección del cliente a menudo cambia a una diferente en el rango de red /24, pero la conexión todavía representa al mismo cliente, por lo que no hay razón para cambiar la asignación al servidor.

Sin embargo, si la mayoría del tráfico a su sitio proviene de clientes en la misma red /24, IP Hash no tiene sentido porque asigna a todos los clientes al mismo servidor. En ese caso (o si desea aplicar un hash a los cuatro octetos por otro motivo), utilice en su lugar el método Hash con la variable $remote_addr .

hash $dirección_remota;

Conexiones mínimas

Con el método de Menos Conexiones, el balanceador de carga compara la cantidad actual de conexiones activas que tiene con cada servidor y envía la solicitud al servidor con menos conexiones. Lo configuras con la directiva less_conn .

backend ascendente { less_conn ; servidor web1; servidor web2; servidor web3; } servidor { nombre_servidor www.ejemplo.com; ubicación / { contraseña_proxy http://backend; } }

Menos tiempo

Con el método de menor tiempo (disponible solo en NGINX Plus), el balanceador de carga combina matemáticamente dos métricas para cada servidor (la cantidad actual de conexiones activas y un tiempo de respuesta promedio ponderado para solicitudes anteriores) y envía la solicitud al servidor con el valor más bajo.

Su elección de parámetro en la directiva least_time controla cuál de los dos tiempos de respuesta se rastrea: el tiempo para recibir el encabezado de respuesta ( header ) o el tiempo para recibir la respuesta completa ( last_byte ).

backend ascendente { tiempo_menor (encabezado | último_byte) ; servidor web1; servidor web2; servidor web3; } servidor { nombre_servidor www.ejemplo.com; ubicación / { contraseña_proxy http://backend; } }

Notas:

• Para equilibrar la carga de TCP y UDP (en el contexto de transmisión ), puede elegir entre tres tipos de tiempo de respuesta con estos parámetros para la directiva least_time :

  • Conectar : Es hora de conectarse al servidor ascendente
  • first_byte – Tiempo para recibir el primer byte de datos de respuesta
  • last_byte – Tiempo para recibir el último byte de datos de respuesta

• Para el tráfico HTTP y TCP/UDP, en NGINX Plus R12 y versiones posteriores agregue el parámetro inflight para incluir conexiones incompletas en cada métrica; dichas conexiones se incluyen de manera predeterminada en versiones anteriores.

Elección de una técnica de equilibrio de carga

Entonces, ¿cómo sabe cuál de las técnicas de equilibrio de carga es mejor para su 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 en diferentes momentos del día, que no tiene sentido basar la elección de la técnica de equilibrio de carga en una única característica (como tráfico en ráfagas frente a tráfico constante, conexiones de corta duración frente a tráfico de larga duración, etc.). Dicho esto, consideraremos los pros y contras de cada método para ayudarle a reducir el rango de opciones a considerar.

Ejecución de pruebas para comparar métodos

Cualquiera sea el subconjunto de métodos de equilibrio de carga que considere, le recomendamos que los pruebe para ver cuál funciona mejor para su tráfico. “Mejor” generalmente significa el menor tiempo para entregar respuestas a los clientes, pero es posible que tenga criterios diferentes.

Las herramientas de gestión del rendimiento de las aplicação son muy útiles para este tipo de pruebas: puede crear pantallas personalizadas con gráficos para cada uno de los servidores del grupo ascendente, lo que hace posible compararlos en tiempo real a medida que los valores cambian durante la prueba. Varios APM ofrecen complementos personalizados para NGINX Plus y NGINX, incluidos AppDynamics , Datadog , Dynatrace y New Relic .

Las pruebas son más sencillas si todos los servidores tienen la misma capacidad. De lo contrario, deberá establecer los pesos del servidor para que las máquinas con más capacidad reciban más solicitudes. Consulte Cómo establecer pesos cuando los servidores no son idénticos a continuación.

Algunas métricas a comprobar durante las pruebas son:

• Carga de CPU y memoria: observe el porcentaje de capacidad total utilizada, tanto para CPU como para memoria. Si no todos los servidores tienen la misma carga, el tráfico no se distribuye de manera eficiente.
• Tiempo de respuesta del servidor: si el tiempo es sistemáticamente mayor para algunos servidores que para otros, de alguna manera las solicitudes “más pesadas” (que requieren más cálculos o llamadas a una base de datos u otros servicios) se dirigen a ellos de manera desequilibrada. Intente ajustar los pesos, ya que el desequilibrio podría deberse a pesos incorrectos en lugar de a un problema con la técnica de equilibrio de carga.
• Tiempo total para responder al cliente: una vez más, los tiempos consistentemente más altos para algunos servidores sugieren que están recibiendo una parte desproporcionada de solicitudes que consumen mucho tiempo. Y nuevamente, puedes intentar ajustar los pesos para ver si eso elimina el problema.
• Errores y solicitudes fallidas: debe asegurarse de que la cantidad de solicitudes fallidas y otros errores durante las pruebas no sea mayor de lo habitual para su sitio. De lo contrario, estará basando su decisión en condiciones de error en lugar de en tráfico realista. Para algunos errores, el servidor puede enviar su respuesta más rápidamente que cuando la solicitud es exitosa. Para el código de respuesta HTTP 404( Archivo no encontrado ), por ejemplo, el servidor probablemente devuelve el error mucho más rápido de lo que podría entregar el archivo real si existiera. Con los algoritmos de equilibrio de carga de menor cantidad de conexiones y menor tiempo, esto puede llevar al equilibrador de carga a favorecer a un servidor que en realidad no está funcionando bien.

Pros, contras y casos de uso

Ahora veamos los beneficios y desventajas de cada técnica de equilibrio de carga y describamos algunos casos de uso para los que son particularmente adecuadas. Los discutiremos en orden de creciente idoneidad para la mayoría de casos de uso. A modo de avance rápido: consideramos que las conexiones mínimas (y, para NGINX Plus, el tiempo mínimo) son las mejores opciones para la más amplia variedad de casos de uso.

Hash y hash de IP

Las técnicas de equilibrio de carga Hash y IP Hash crean una asociación fija entre un tipo determinado de solicitud de cliente (capturada en el valor hash) y un servidor determinado. Quizás reconozcas esto como persistencia de sesión: todas las solicitudes con un valor hash determinado siempre van al mismo servidor.

El mayor inconveniente de estos métodos es que no garantizan que distribuyan las solicitudes en cantidades iguales entre los servidores, y mucho menos que equilibren la carga de manera uniforme. El algoritmo hash divide de manera uniforme el conjunto de todos los valores hash posibles en "grupos", uno para cada servidor del grupo ascendente, pero no hay forma de predecir si las solicitudes que realmente ocurren tendrán hashes distribuidos de manera uniforme. Supongamos, por ejemplo, que diez clientes acceden a un sitio y el algoritmo IP Hash asocia el hash de siete de las direcciones IP con web1 , una con web2 y dos con web3 . El servidor web1 termina recibiendo más del doble de solicitudes que los otros servidores combinados.

Por lo tanto, tiene sentido utilizar Hash o IP Hash cuando el beneficio de mantener sesiones supera 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 en combinación con el balanceo de carga (se configuran con la directiva sticky ). Pero puedes elegir Hash o IP Hash incluso con NGINX Plus, porque los tres mecanismos no funcionan en los siguientes casos:

• El navegador o la aplicación cliente no aceptan cookies y la aplicação no tiene forma de trabajar con los mecanismos de persistencia de sesión sin cookies. Utilice el método IP Hash para asociar cada cliente (específicamente su dirección IP) con un servidor en particular.

• Desea enviar solicitudes para una URL determinada al mismo servidor cada vez, para aprovechar el almacenamiento en caché en el propio servidor. Utilice el método Hash con la variable $request_uri para obtener el archivo del mismo servidor cada vez.

  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 lo tanto, se pueden almacenar en caché. Si dirige todas las solicitudes del archivo al mismo servidor, solo el primer cliente experimenta un gran retraso debido a las llamadas a la base de datos. Para todos los clientes posteriores, los datos se recuperan rápidamente de la caché. Otra ventaja es que sólo un servidor tiene que almacenar en caché ese conjunto particular de datos. Para no terminar almacenando en caché duplicado los mismos datos en cada servidor, puedes usar cachés más pequeños.

Hay un par de casos en los que el Hash de IP (y el Hash cuando la dirección IP del cliente está en la clave) no funcionan:

• Cuando la dirección IP del cliente puede cambiar durante la sesión, por ejemplo, cuando un cliente móvil cambia de una red WiFi a una celular.
• Cuando las solicitudes de una gran cantidad de clientes pasan a través de un proxy de reenvío, porque la dirección IP del proxy se utiliza para todas ellas.

Los hashes son deterministas (el algoritmo hash produce los mismos resultados cada vez). Esto tiene un par de efectos secundarios positivos: todas las instancias NGINX Plus o NGINX en una implementación equilibran la carga de las solicitudes exactamente de la misma manera, y la asignación de hash a servidor persiste después de los reinicios del equilibrador de carga. (En realidad, se vuelve a calcular después del reinicio, pero como el resultado siempre es el mismo, persiste de manera efectiva).

Por otro lado, cambiar el conjunto de servidores ascendentes generalmente obliga a recálculo de al menos algunas de las asignaciones, rompiendo la persistencia de la sesión. Puedes reducir un poco el número de asignaciones recalculadas:

• Para el método Hash, incluya el parámetro consistente en la directiva hash ; NGINX Plus utiliza el algoritmo hash ketama , que da como resultado menos reasignación.

• Para el método IP Hash, antes de eliminar temporalmente un servidor del grupo ascendente, agregue el parámetro inactivo a su directiva de servidor , como para web2 en el siguiente ejemplo. Las asignaciones no se vuelven a calcular, asumiendo que el servidor volverá pronto al servicio.

  backend ascendente { ip_hash; servidor web1; servidor web2 inactivo ; servidor web3; }

Round Robin

Como se mencionó anteriormente, Round Robin es el método de balanceo de carga predeterminado en NGINX Plus y NGINX. Esto lo convierte en el método más fácil de elegir: no es necesario configurar nada más allá del grupo ascendente.

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 relación con otros. Algunas de las condiciones son:

• Todos los servidores tienen aproximadamente la misma capacidad. Este requisito es menos importante si las diferencias entre servidores se representan con precisión mediante los pesos de los servidores.
• Todos los servidores alojan el mismo contenido.
• Las solicitudes son bastante similares en la cantidad de tiempo o potencia de procesamiento que requieren. Si hay una amplia variación en el peso de la solicitud, un servidor puede sobrecargarse porque el balanceador de carga le envía muchas solicitudes pesadas en rápida sucesión.
• El volumen de tráfico no es lo suficientemente pesado como para llevar los servidores casi a su capacidad máxima con mucha frecuencia. Si los servidores ya están muy cargados, es más probable que la distribución rutinaria de solicitudes de Round Robin empuje a algunos servidores "al límite" hasta la sobrecarga, como se describe en el punto anterior.

Round Robin es especialmente adecuado para escenarios de prueba, porque garantiza que las solicitudes se distribuyan entre todos los servidores y en cantidades iguales (o en la proporción ponderada adecuada). Algunos 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 naturaleza uniforme de la distribución también puede revelar si los cachés están funcionando bien y a plena capacidad: debido a que no hay forma con Round Robin de enviar solicitudes para un archivo determinado al mismo servidor, es probable que cada servidor termine sirviendo y almacenando en caché una amplia gama de archivos (y generalmente muchos de los mismos archivos que sus pares), lo que hace que sea más probable que el caché se llene.

Finalmente, la distribución inicial uniforme ayuda a descubrir problemas con la persistencia de la sesión en NGINX Plus (tal como se configura con la directiva sticky ).

Menos conexiones y menos tiempo

Como mencionamos anteriormente, Least Connections es la técnica de equilibrio de carga más adecuada para la más amplia gama de casos de uso, y particularmente para el tráfico de producción. Esto está respaldado por evidencia anecdótica de nuestros clientes. Su rendimiento es estable y predecible.

Least Connections también distribuye eficazmente la carga de trabajo entre los servidores según su capacidad. Un servidor más potente cumple con las solicitudes más rápidamente, por lo que en un momento dado es probable que tenga una menor cantidad de conexiones aún en proceso (o incluso esperando que se inicie el procesamiento) que un servidor con menos capacidad. Menos conexiones envía cada solicitud al servidor con la menor cantidad de conexiones actuales, por lo que es más probable que envíe solicitudes a servidores potentes. (Sin embargo, establecer pesos aún da como resultado una distribución más eficiente de las solicitudes, como se describe en Establecer pesos cuando los servidores no son idénticos a continuación).

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

El tiempo mínimo es especialmente adecuado cuando los servidores ascendentes tienen tiempos de respuesta promedio muy diferentes. Si, por ejemplo, tiene servidores en diferentes centros de datos para 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 del servidor suele ser muy impredecible.

Establecer pesos cuando los servidores no son idénticos

Hemos mencionado varias veces la importancia de establecer los pesos de los servidores cuando los servidores del grupo ascendente tienen diferentes capacidades. Es particularmente importante para el balanceador de carga Round Robin, que de lo contrario envía la misma cantidad de solicitudes a cada servidor. Es probable que esto dé como resultado que un servidor menos potente se sobrecargue mientras que uno más potente permanezca parcialmente inactivo.

Para establecer pesos, incluya el parámetro de peso en una o más directivas de servidor en el bloque ascendente . El valor predeterminado es 1.

Puedes pensar en el efecto de establecer pesos para las diferentes técnicas de equilibrio de carga de la siguiente manera. Tenga en cuenta que las descripciones son conceptualmente correctas, pero la implementación en el código NGINX Plus no necesariamente utiliza las operaciones matemáticas indicadas. Aquí está el grupo ascendente para nuestros ejemplos:

backend ascendente { servidor web1 peso=6;
servidor web2 peso=3;
servidor web3;
}

• Round Robin : cada servidor recibe el porcentaje de las solicitudes entrantes igual a su peso dividido por la suma de los pesos. En nuestro ejemplo, de cada diez solicitudes, web1 obtiene seis (60%), web2 obtiene tres (30%) y web3 obtiene una (10%).

• Hash y hash de IP : recuerde que, sin pesos, el algoritmo de hash divide de manera uniforme el conjunto de todos los valores de hash posibles en “depósitos”, uno para cada servidor del grupo ascendente. Con pesos, en cambio, suma los pesos, divide el conjunto de hashes posibles entre esa cantidad de buckets y asocia cada servidor con la cantidad de buckets equivalente a su peso.

  En nuestro ejemplo, hay diez contenedores, cada uno con el 10% de los hashes posibles. Seis depósitos (60% de los hashes posibles) están asociados con web1 , tres depósitos (30%) con web2 y un depósito (10%) con web3 .

• Menos conexiones y menos tiempo : mencionamos anteriormente que incluso sin pesos, estos algoritmos son bastante efectivos para distribuir la carga de trabajo entre los servidores según su capacidad. La fijación de pesas mejora aún más su rendimiento en este aspecto.

  Recuerde que Menos Conexiones y Menos Tiempo envían cada solicitud al servidor con el “puntaje” más bajo (número de conexiones o una combinación matemática de conexiones y tiempo, respectivamente). Al asignar pesos, el balanceador de carga divide la puntuación de cada servidor por su peso y nuevamente envía la solicitud al servidor con el valor más bajo.

  He aquí un ejemplo de Menos Conexiones con nuestros pesos de muestra y el número indicado de conexiones activas: la puntuación de 100 de web1 es la más baja y recibe la solicitud a pesar de que su recuento de conexiones de 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

Después de revisar los pros y contras de las técnicas de equilibrio de carga disponibles en NGINX Plus y NGINX, consideramos que las conexiones mínimas (y, para NGINX Plus, el tiempo mínimo) son las más adecuadas para la más amplia gama de casos de uso. Pero es importante que pruebe varios métodos en su implementación, porque su combinación única de características de tráfico y servidor podría hacer que otro método sea mejor para usted.

Para probar usted mismo el equilibrio de carga de NGINX Plus, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso.

Nos encantaría conocer sus experiencias con el equilibrio de carga en diferentes casos de uso. Agreguelos a la sección de comentarios a continuación.