Casi no hay información sistemática sobre NSX ALB en ruso en la red, solo la documentación del proveedor en inglés. Por lo tanto, en la primera parte, resumí fuentes dispares e hice una descripción general del producto: hablé sobre las características, la arquitectura y la lógica del trabajo, incluso para sitios geográficamente dispersos. En la segunda parte describiré cómo implementar y configurar el sistema. Es de esperar que ambos artículos sean útiles para quienes buscan un equilibrador para entornos de nube y desean evaluar rápidamente las capacidades de NSX ALB.
Funciones y capacidades
NSX ALB es un balanceador de carga definido por software (SDLB) de nivel empresarial. Esto no es típico de los sistemas de equilibrio de carga del tipo que normalmente utilizan equilibradores de carga de hardware. Este enfoque para construir el sistema le da al NSX ALB una fácil administración y escalabilidad horizontal y vertical.
Qué funciones ofrece NSX ALB:
- Control automático de potencia del equilibrador. Cuando aumenta la carga por parte de los clientes, la capacidad aumenta automáticamente, cuando la carga disminuye, se cae.
- Equilibrio de carga en servidores dispersos geográficamente. Un mecanismo de equilibrio de carga de servidor global (GSLB) independiente es responsable de esto.
- Equilibrio en uno de los niveles: L4 (sobre TCP / UDP) y L7 (sobre HTTP / HTTPS).
- . NSX ALB ( VMware) on-premise :
- Inteligencia de aplicaciones incorporada. El sistema monitorea el rendimiento de la aplicación y recopila datos: tiempo para cada etapa del procesamiento de la conexión, evaluación del estado de la aplicación y registros de tráfico en tiempo real. Si hay un problema, el monitoreo puede indicar rápidamente dónde buscarlo.
Los datos en tiempo real se recopilan en conexiones abiertas simultáneamente, tiempo de ida y vuelta (RTT), rendimiento, errores, retrasos en las respuestas, retrasos en el protocolo de enlace SSL, tipos de respuesta y más. Toda la información en un solo lugar:
en el bloque Log Analytics de la derecha, se recopilan estadísticas sobre los principales parámetros de conexión. Puede colocar el mouse sobre la sección deseada y familiarizarse rápidamente.
Además, NSX ALB tiene:
- Soporte para tenencia múltiple para diferenciar el acceso a los recursos.
- Health Monitor .
- Web Application Firewall (WAF).
- IPAM DNS.
- , . . IP-, . : Botnet, DoS, Mobile threats, Phishing, Proxy, Scanner, Spam source, Web attacks, Windows exploit .., – .
- Analizar los encabezados HTTP de los paquetes que pasan. Puede usar scripts (DataScript) basados en el lenguaje Lua y definir acciones Avi en función de los valores en estos encabezados: redireccionar una solicitud, cerrar o restablecer una conexión, falsificar URI o valores en un encabezado HTTP, seleccionar un grupo de servidores específico para procesar una solicitud, trabajar con cookies etc.
- Actuando como controlador de Ingress para Kubernetes.
NSX ALB se puede administrar a través de GUI, CLI y REST API.
Arquitectura y esquema de trabajo NSX ALB
NSX ALB funciona según los principios estándar para la mayoría de SDLB. Los servidores que proporcionan el servicio de equilibrio se combinan en grupos . Por encima de las piscinas, el administrador del sistema crea servicios virtuales (VS) . Contienen parámetros del servicio que se está equilibrando, por ejemplo: tipo de aplicación, algoritmo de equilibrio, configuración de la conexión. VS también proporciona a los clientes una dirección IP virtual externa (IP virtual, VIP) para acceder al servicio equilibrado.
Echemos un vistazo más de cerca a cómo se ve la arquitectura: el
elemento clave del sistema es el controlador (Avi Controller)... Es responsable de la acumulación automática de energía y controla centralmente el VS. Puede implementar un solo controlador o un grupo de controladores de conmutación por error en su infraestructura.
En la configuración de conmutación por error, el clúster del controlador consta de 3 nodos. Uno de los nodos se convierte en líder, el resto de seguidores. Los 3 nodos están activos y comparten la carga entre ellos. Los principales escenarios para un grupo de controladores:
- si un nodo falla, esto no afecta el funcionamiento del clúster;
- si falla el nodo principal, esta función se transfiere a uno de los restantes;
- si fallan 2 nodos, el servicio del controlador en el nodo restante entra en modo de solo lectura para evitar un cerebro dividido y espera a que otro nodo vuelva a estar disponible.
Después de implementar el controlador, el ingeniero crea un VS y un grupo de servidores para cada VS. Para los servidores dentro del grupo, puede elegir un algoritmo de equilibrio :
- Round Robin: la nueva conexión irá al siguiente servidor del grupo.
- Menos conexiones: la nueva conexión irá al servidor con la menor cantidad de conexiones simultáneas.
- Carga mínima: la nueva conexión irá al servidor con la carga mínima independientemente del número de conexiones.
- Hash consistente: las nuevas conexiones se distribuyen entre servidores en función del hash calculado. La clave para calcular el hash se especifica en un campo especial o en una cadena personalizada. Para cada solicitud, se calcula un hash utilizando esta clave. La conexión se envía al servidor correspondiente al hash calculado.
- Fastest Response – .
- Fewest Tasks – ( Avi CLI REST API.
- Fewest Servers – , .
Después de crear VS y el grupo de servidores, el controlador mismo implementa máquinas virtuales de servicio, Service Engine (SE) , en las que se encuentra el servicio equilibrado. Cada servicio (VS) se distribuye entre varios SE que procesan las solicitudes de los clientes en paralelo. Esto asegura la resistencia del servicio en caso de fallas en la máquina virtual.
El controlador puede evaluar la carga y agregar nuevos SE o eliminar los descargados. Debido a esta arquitectura, NSX ALB puede escalar tanto horizontalmente, aumentando la cantidad de SE, como verticalmente, aumentando la capacidad de cada SE.
Cuantos más servicios equilibra el SE, más interfaces de red se utilizan. En el diagrama detallado a continuación, vemos 2 tipos de redes:
- la red para el control y transmisión de información de servicio forma el Plano de Control ,
- las redes de datos forman el plano de datos .
Cada SE tiene una interfaz de red separada en la red de control para comunicarse con el controlador. El resto de las interfaces están conectadas a la red externa y a la red donde se encuentra el grupo de servidores para el equilibrio. Esta separación de la infraestructura de red mejora la seguridad.
Para cada VS, debe definir los parámetros de SE en los que se alojará el servicio. Estos parámetros se establecen en el grupo SE (Grupo SE) . Al crear VS, seleccionamos el grupo SE: puede especificar un grupo predeterminado (Grupo predeterminado) o crear un nuevo grupo si VS necesita configuraciones especiales de máquina virtual.
El grupo seleccionado determinará cómo se ubicará el nuevo SV. Por ejemplo, si los SE del grupo predeterminado ya están implementados en el sistema y estos SE aún tienen recursos, entonces el nuevo VS con el grupo predeterminado especificado se ubicará en ellos. Si especificamos un nuevo grupo para VS, se implementarán nuevos SE con diferentes parámetros debajo de él.
En el nivel del grupo SE, configure los siguientes ajustes de ubicación VS:
- número máximo de PE en un grupo,
- número máximo de VS por SE,
- forma de colocar VS en SE: Compacto, cuando primero llenamos el primer SE lo más apretado posible y pasamos al siguiente, o Distribuido con una distribución uniforme:
- Parámetros de la máquina virtual SE: número de vCPU, memoria y tamaño de disco,
El ancho de banda por 1 vCPU es de aproximadamente 40K conexiones / s, con un promedio de 4 GB / s. Este indicador difiere para los diferentes niveles de balanceo y el protocolo utilizado: es más en L4, menos en L7 por la necesidad de analizar el tráfico, con SSL es mucho menos por la necesidad de cifrado.
- la vida útil de un SE no utilizado, después de lo cual debe eliminarse,
- recursos para alojar SE. En un entorno de VMware, puede especificar o excluir un clúster o hosts y un almacén de datos específicos para su uso.
Pasemos a la arquitectura y el flujo de trabajo del servicio de equilibrio global GSLB.
Arquitectura y flujo de trabajo para servidores dispersos geográficamente
En un servicio virtual regular, podemos agregar servidores al grupo desde una sola nube. Incluso si agregamos varias nubes en el controlador al mismo tiempo, no podremos combinar servidores de diferentes nubes dentro de un VS. El servicio de equilibrado global GSLB resuelve este problema. Le permite equilibrar los servidores dispersos geográficamente ubicados en diferentes nubes.
Dentro de un servicio global, puede usar nubes públicas y privadas al mismo tiempo. Estos son los casos en los que podría necesitar una GSLB:
- alta disponibilidad del servicio si todos los servidores de una de las nubes no están disponibles,
- recuperación ante desastres si una nube es completamente inaccesible,
- , , . .
Veamos la arquitectura GSLB: Brevemente cómo
funciona: el servicio de DNS local implementado dentro de NSX ALB realiza el equilibrio. El cliente envía una solicitud para conectarse al servicio utilizando el nombre FQDN. DNS le da al cliente la IP virtual del VS local en la nube más óptima. El servicio elige la nube más óptima en función del algoritmo de equilibrio, los datos sobre la disponibilidad de VS locales en el Health Monitor y la ubicación geográfica del cliente. Puede establecer diferentes algoritmos de equilibrio, tanto a nivel de servicio global como a nivel de GSLB.
Como puede ver en el diagrama GSLB, se basa en los elementos del diagrama anterior: grupos de servidores, por encima de ellos servicios virtuales locales (VS) con IP virtual local (VIP) y máquinas virtuales de servicio (SE). Aparecen nuevos elementos al construir el GSLB.
Servicio global (VS global) : un servicio equilibrado entre servidores dispersos geográficamente o nubes públicas y privadas.
Un sitio GSLB incluye el controlador y los SE gestionados por él, ubicados en la misma nube. Para cada sitio, puede configurar la geolocalización en latitud y longitud. Esto permitirá a GSLB seleccionar el grupo de servidores en función de la distancia del cliente.
Los sitios GSLB basados en el sistema NSX ALB se dividen en líderes (líderes) y seguidores (seguidores). Como en el caso de los controladores, este esquema proporciona tolerancia a fallos para el servicio GSLB.
El sitio principal toma decisiones de equilibrio, gestiona las conexiones y supervisa. Solo puede cambiar la configuración de GSLB desde el controlador de sitio maestro.
Los sitios esclavos pueden ser activos o pasivos.
- Un sitio esclavo pasivo solo maneja conexiones de clientes entrantes si el sitio maestro elige su VS local.
- El sitio esclavo activo recibe su configuración del sitio maestro y, si falla, puede asumir el papel principal.
Los sitios GSLB también pueden ser sitios externos, construidos sobre equilibradores de terceros.
El grupo global es diferente del grupo local, que contiene servidores locales. En un grupo global, puede combinar servicios virtuales geográficamente dispersos de diferentes sitios. En otras palabras, el grupo global contiene VS locales, que se establecen a nivel de sitios GSLB.
Se realiza el equilibrio de conexiones entre servidores en el grupo global:
- por el algoritmo Round Robin,
- por geolocalización del servidor,
- ,
- Consistent Hash.
Para un servicio global, puede crear varios grupos globales e incluir uno o más sitios en cada VS local. En este caso, las nuevas conexiones se distribuirán según la geolocalización o según las prioridades especificadas. Para establecer prioridades para los servidores del grupo, puede establecer un peso diferente para cada uno.
Un ejemplo de equilibrio entre grupos globales . Así es como el VS global distribuirá las conexiones en este esquema:
GslbPool_3 tiene una prioridad de 10 y será el preferido para las conexiones de los clientes. De estas conexiones, el 40% de la carga irá a VS-B3 y el 60% a VS-B4. Si GslbPool_3 deja de estar disponible, todas las conexiones del cliente irán completamente a GslbPool_2 y la carga entre VS-B3 y VS-B4 se distribuirá uniformemente.
DNS localcontienen registros con los nombres FQDN de los servicios equilibrados a través de él.
GSLB DNS es el modo operativo VS de DNS local, que se utiliza para equilibrar las conexiones entre sitios GSLB.
El VS de DNS local comienza a actuar como DNS GSLB cuando lo seleccionamos como el servicio DNS para un GSLB elevado. Este DNS VS debe implementarse en todos los sitios incluidos en los grupos globales.
GSLB agrega registros FQDN de servicio global a cada DNS local. NSX ALB llena este registro con las direcciones IP virtuales del VS local de todos los sitios incluidos en el grupo de VS global. Estos VIP adicionales se agregan automáticamente con los nuevos VS locales agregados al grupo. Los datos de los registros se actualizan a medida que se acumula información sobre la carga del servicio, la disponibilidad de los servidores y la lejanía de los clientes de los sitios. Cuando un nuevo cliente se conecta utilizando el FQDN, uno de los DNS locales emite la dirección VIP del VS local, teniendo en cuenta estos datos reales acumulados.
Cómo implementar y configurar el sistema NSX ALB, así como aumentar el servicio GSLB en él, lo describiré en la segunda parte de este artículo.