NGINX Plus y los equilibradores de carga de Microsoft Azure

Michael Pleshakov

[Nota del editor: Esta publicación se ha actualizado para reflejar las funcionalidades compatibles con NGINX Plus y los servicios de equilibrio de carga de Azure a fecha de junio de 2021. También hace referencia a la API de NGINX Plus, que sustituye y deja obsoleto el módulo independiente de configuración dinámica mencionado en la versión original de la publicación.]

Los clientes que utilizan Microsoft Azure disponen de tres opciones para el balanceo de carga: NGINX Plus, los servicios de balanceo de carga de Azure o NGINX Plus junto con dichos servicios. Esta publicación pretende ofrecerle información suficiente para tomar una decisión y también muestra cómo el uso de NGINX Plus con Azure Load Balancer puede proporcionarle un balanceador de carga HTTP de alta disponibilidad con amplias funcionalidades de capa 7.

Descripción general

Microsoft Azure ofrece a sus usuarios dos opciones de balanceador de carga: Azure Load Balancer para el balanceo de carga TCP/UDP básico (en la capa 4, la capa de red) y Azure Application Gateway para el balanceo de carga HTTP/HTTPS (en la capa 7, la capa de aplicación). Aunque estas soluciones funcionan para casos de uso sencillos, no ofrecen muchas de las funciones incluidas de serie en NGINX Plus.

A continuación se ofrece una comparación general entre NGINX Plus y las soluciones de balanceo de carga de Azure:

Veamos ahora algunas de las diferencias entre NGINX Plus y los servicios de equilibrio de carga de Azure, sus características exclusivas y cómo NGINX Plus y los equilibradores de carga de Azure pueden funcionar conjuntamente.

Comparación entre NGINX Plus y los servicios de equilibrio de carga de Azure

Métodos de balanceo de carga

NGINX Plus permite elegir entre varios métodos de balanceo de carga además del método Round Robin predeterminado:

• Menor número de conexiones – Cada solicitud se envía al servidor con el menor número de conexiones activas.
• Menor tiempo – Cada solicitud se envía al servidor con la puntuación más baja, calculada a partir de una combinación ponderada de la latencia media y el menor número de conexiones activas.
• Hash de IP – Cada solicitud se envía al servidor determinado por la dirección IP de origen de la solicitud.
• Generic Hash – Each request is sent to the server determined from a user‑defined key, which can contain any combination of text and NGINX variables, for example the variables corresponding to the Source IP Address and Source Port header fields, or the URI.
• Aleatorio – Cada solicitud se envía a un servidor seleccionado al azar. Cuando se incluye el parámetro two, NGINX Plus selecciona dos servidores al azar y, a continuación, elige entre ellos mediante el algoritmo de menor número de conexiones (el predeterminado) o el de menor tiempo, según la configuración.

Todos los métodos se pueden ampliar asignando distintos valores de peso a cada servidor backend. Para obtener más información sobre los métodos, consulte la Guía de administración de NGINX Plus.

Azure Load Balancer ofrece un único método de equilibrio de carga, Hash, que de forma predeterminada utiliza una clave basada en los campos de encabezado Source IP Address, Source Port, Destination IP Address, Destination Port y Protocol para elegir un servidor backend.

Azure Application Gateway solo proporciona un método de turno rotatorio.

Persistencia de sesión

Persistencia de sesión, también conocida como sesiones persistentes o afinidad de sesión, es necesaria cuando una aplicación requiere que todas las solicitudes de un cliente específico se sigan enviando al mismo servidor backend porque el estado del cliente no se comparte entre los servidores backend.

NGINX Plus admite tres métodos avanzados de persistencia de sesión:

• Cookie persistente – NGINX Plus añade una cookie de sesión a la primera respuesta del grupo de servidores upstream para un cliente determinado. Esta cookie identifica el servidor backend que se utilizó para procesar la solicitud. El cliente incluye esta cookie en las solicitudes posteriores y NGINX Plus la utiliza para dirigir la solicitud del cliente al mismo servidor backend.
• Aprendizaje de persistencia – NGINX Plus supervisa las solicitudes y respuestas para localizar identificadores de sesión (normalmente cookies) y los utiliza para determinar el servidor al que se dirigirán las solicitudes posteriores de una sesión.
• Ruta persistente – Se puede configurar una correspondencia entre los valores de ruta y los servidores backend para que NGINX Plus supervise las solicitudes en busca de un valor de ruta y elija el servidor backend correspondiente.

NGINX Plus también ofrece dos métodos básicos de persistencia de sesión, implementados como dos de los métodos de balanceo de carga descritos anteriormente:

• Hash de IP – El servidor backend se determina mediante la dirección IP de la solicitud.
• Hash – El servidor backend se determina a partir de una clave definida por el usuario, por ejemplo, Dirección IP de origen y Puerto de origen, o el URI.

Azure Load Balancer admite el equivalente al método Hash de NGINX Plus, aunque la clave está limitada a determinadas combinaciones de los campos de cabecera Dirección IP de origen, Puerto de origen, Dirección IP de destino, Puerto de destino y Protocolo.

Azure Application Gateway admite el equivalente al método Sticky Cookie de NGINX Plus con las siguientes limitaciones: no se pueden configurar el nombre de la cookie, su fecha de caducidad, el dominio, la ruta ni los atributos de cookie HttpOnly o Secure.

Nota: Cuando se utiliza Azure Load Balancer, el método Hash de IP de NGINX Plus o el método Hash de NGINX Plus con Dirección IP de origen incluida en la clave, la persistencia de sesión solo funciona correctamente si la dirección IP del cliente permanece igual durante toda la sesión. Esto no siempre ocurre, por ejemplo, cuando un cliente móvil cambia de una red WiFi a una red móvil. Para garantizar que las solicitudes sigan llegando al mismo servidor backend, es preferible utilizar uno de los métodos avanzados de persistencia de sesión indicados anteriormente.

Comprobaciones de estado

Azure Load Balancer y Azure Application Gateway admit comprobaciones básicas del estado de la aplicación. Puede especificar la URL que solicita el equilibrador de carga, que considera que el servidor back-end está en buen estado si recibe el código de respuesta HTTP esperado: 200. Puede especificar la frecuencia de las comprobaciones de estado y el tiempo de espera antes de que el servidor se considere en mal estado. Con Azure Application Gateway, también puede personalizar el código de respuesta esperado y comprobar que coincida con el contenido del cuerpo de la respuesta.

NGINX Plus amplía esta funcionalidad con comprobaciones de estado avanzadas. Además de especificar la URL que se va a utilizar, NGINX Plus permite insertar encabezados en la solicitud, buscar distintos códigos de respuesta y examinar tanto los encabezados como el cuerpo de la respuesta.

Una función relacionada muy útil de NGINX Plus es el inicio lento. NGINX Plus aumenta gradualmente la carga de un servidor nuevo o recién recuperado para evitar que se vea desbordado por las conexiones. Esto resulta útil cuando los servidores backend necesitan cierto tiempo de calentamiento y fallarían si recibieran toda la proporción de tráfico que les corresponde en cuanto aparecieran como operativos.

NGINX Plus también admite comprobaciones de estado de servidores TCP y UDP, que permiten especificar una cadena que se enviará y otra que se buscará en la respuesta.

Azure Load Balancer admite comprobaciones de estado de TCP, pero no ofrece este nivel de supervisión.

Terminación SSL/TLS

NGINX Plus admite la terminación SSL/TLS, al igual que Azure Application Gateway. Azure Load Balancer no la admite.

Límites de conexiones y de velocidad

Con NGINX Plus, puede configurar varios límites para controlar el tráfico entrante y saliente de su instancia de NGINX Plus. Entre ellos se incluyen la limitación de las conexiones entrantes, las conexiones a los nodos de backend, la tasa de solicitudes entrantes y la velocidad de transmisión de datos de NGINX Plus a los clientes.

Azure Application Gateway y Azure Load Balancer no admiten límites de velocidad ni de conexiones. Sin embargo, puede utilizar otros servicios de Azure para configurar y habilitar la limitación de velocidad.

Compatibilidad con protocolos y reescritura y redirección de URL

NGINX Plus, Azure Application Gateway y Azure Load Balancer son compatibles con lo siguiente:

• HTTP/2 – NGINX Plus acepta solicitudes HTTP/2 de clientes desde 2016. Azure incorporó la compatibilidad con WebSocket más recientemente.
• WebSocket – NGINX Plus acepta conexiones WebSocket de clientes desde 2014. Azure incorporó la compatibilidad con WebSocket más recientemente.
• Reescritura de URL y redirección de solicitudes – La URL de una solicitud se puede cambiar antes de enviarla a un servidor backend, lo que permite modificar internamente las rutas de las solicitudes y las ubicaciones de los archivos sin cambiar las URL comunicadas a los clientes. También puede redirigir solicitudes, por ejemplo, cambiando el esquema de una solicitud de HTTP a HTTPS.

NGINX Plus con los servicios de equilibrio de carga de Azure

Cuando se utiliza junto con Azure Load Balancer y Azure Traffic Manager, NGINX Plus se convierte en una solución de equilibrado de carga de alta disponibilidad con amplias funcionalidades de capa 7.

Alta disponibilidad activo-activo

Al usar Azure Load Balancer para equilibrar la carga entre instancias de NGINX Plus en un conjunto de disponibilidad, se crea un equilibrador de carga de alta disponibilidad dentro de una región.

Escalado automático de NGINX Plus

Puede configurar el escalado automático de las instancias de NGINX Plus en función del uso medio de la CPU. Para ello, cree conjuntos de disponibilidad en el servicio en la nube de Azure que aloja sus instancias de NGINX Plus. Debe encargarse de sincronizar los archivos de configuración de NGINX Plus.

Escalado automático de instancias de backend

También puede configurar el escalado automático de sus instancias de backend en función del uso medio de la CPU. Para ello, puede crear conjuntos de disponibilidad en el servicio en la nube de Azure que aloja sus instancias de backend. Debe encargarse de añadir o eliminar instancias de backend de la configuración de NGINX Plus, lo que puede hacer mediante la API de NGINX Plus.

Para automatizar las actualizaciones de la configuración de NGINX Plus (ya sea en combinación con conjuntos de disponibilidad o al utilizar NGINX Plus de forma independiente), puede integrar un sistema de detección de servicios con NGINX Plus, bien mediante la API de NGINX Plus o mediante DNS, si el sistema dispone de una interfaz DNS. Consulte nuestras entradas de blog sobre el uso de NGINX Plus con sistemas de detección de servicios populares:

• Descubrimiento de servicios para NGINX Plus mediante registros DNS SRV de Consul
• Descubrimiento de servicios para NGINX Plus mediante las API de Consul
• Descubrimiento de servicios para NGINX Plus con etcd
• Descubrimiento de servicios para NGINX Plus con ZooKeeper

Integración con Azure Traffic Manager

Para un entorno distribuido globalmente, puede usar Azure Traffic Manager para distribuir el tráfico de los clientes entre varias regiones.

Características adicionales de los servicios de equilibrio de carga de Azure

Azure Load Balancer y Application Gateway están administrados por Azure Cloud y ambos ofrecen una solución de equilibrio de carga de alta disponibilidad.

Una característica de Azure Load Balancer que no está disponible en NGINX Plus es la NAT de origen, mediante la cual el tráfico saliente de las instancias de backend tiene la misma dirección IP de origen que el equilibrador de carga.

Azure Load Balancer proporciona reconfiguración automática cuando se utiliza la función de escalado automático de Azure Cloud.

Resumen

Si sus requisitos de equilibrio de carga son sencillos, las soluciones de equilibrio de carga de Azure pueden ser una buena opción. Cuando los requisitos son más complejos, NGINX Plus es una buena alternativa. Puede utilizar NGINX Plus de forma independiente o junto con Azure Load Balancer para garantizar la alta disponibilidad de las instancias de NGINX Plus.

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

Sobre el autor

Michael Pleshakov

Más artículos de Michael Pleshakov