La última vez hablamos sobre las capacidades de NSX Edge en relación con el enrutamiento estático y dinámico, y hoy vamos a profundizar en el balanceador de carga.
Antes de comenzar la configuración, me gustaría recordar brevemente los tipos principales de balanceo.
Teoría
Las soluciones de balanceo de carga de hoy en día se dividen generalmente en dos categorías: balanceo de nivel 4 (transporte) y de nivel 7 (aplicación) en el modelo . El modelo OSI no es el mejor punto de referencia al describir los métodos de balanceo. Por ejemplo, si un balanceador L4 también soporta la terminación TLS, ¿se convierte en un balanceador L7 en ese caso? Pero eso es lo que hay.
- Balanceador L4 generalmente se presenta como un proxy intermedio entre el cliente y un conjunto de backends disponibles, que termina las conexiones TCP (es decir, responde por sí mismo a SYN), selecciona un backend e inicia una nueva sesión TCP hacia él, enviando SYN por su cuenta. Este tipo es uno de los básicos, existen otras variantes.
- Balanceador L7 distribuye el tráfico entre los backends disponibles de una manera "más sofisticada" que lo hace el balanceador L4. Puede tomar decisiones sobre la elección del backend basándose, por ejemplo, en el contenido del mensaje HTTP (URL, cookie, etc.).
Independientemente del tipo, el balanceador puede soportar las siguientes funciones:
- Detección de servicios: el proceso de determinar el conjunto de backends disponibles (estáticos, DNS, Consul, Etcd, etc.).
- Verificación de la disponibilidad de los backends detectados ("ping" activo del backend mediante solicitudes HTTP, detección pasiva de problemas en conexiones TCP, presencia de múltiples códigos HTTP 503 consecutivos en las respuestas, etc.).
- El propio balanceo (round robin, selección aleatoria, hash de IP de origen, URI).
- Terminación de TLS y verificación de certificados.
- Opciones relacionadas con la seguridad (autenticación, prevención de ataques DoS, limitación de velocidad) y mucho más.
NSX Edge ofrece soporte para dos modos de implementación del balanceador:
Modo proxy, o one-arm. En este modo, NSX Edge utiliza su dirección IP como dirección de origen al enviar una solicitud a uno de los backends. De este modo, el equilibrador realiza simultáneamente funciones de NAT de origen y destino. El backend ve todo el tráfico como enviado desde el equilibrador y le responde directamente. En este esquema, el equilibrador debe estar en el mismo segmento de red que los servidores internos.
Así es como ocurre:
1. El usuario envía una solicitud a la dirección VIP (la dirección del equilibrador), que está configurada en Edge.
2. Edge selecciona uno de los backends y realiza NAT de destino, reemplazando la dirección VIP por la dirección del backend elegido.
3. Edge realiza NAT de origen, reemplazando la dirección del usuario que envió la solicitud por la suya propia.
4. El paquete se envía al backend elegido.
5. El backend no responde directamente al usuario, sino a Edge, ya que la dirección original del usuario se ha cambiado a la dirección del equilibrador.
6. Edge transmite la respuesta del servidor al usuario.
El esquema a continuación.
Modo transparente o en línea. En este escenario, el equilibrador tiene interfaces en redes interna y externa. No hay acceso directo a la red interna desde el exterior. El equilibrador de carga integrado actúa como un gateway NAT para las máquinas virtuales en la red interna.
El mecanismo es el siguiente:
1. El usuario envía una solicitud a la dirección VIP (la dirección del equilibrador), que está configurada en Edge.
2. Edge selecciona uno de los backends y realiza NAT de destino, reemplazando la dirección VIP por la dirección del backend elegido.
3. El paquete se envía al backend elegido.
4. El backend recibe la solicitud con la dirección original del usuario (no se ha realizado NAT de origen) y le responde directamente.
5. El tráfico es nuevamente captado por el equilibrador de carga, ya que en el esquema en línea, normalmente actúa como gateway predeterminado para el grupo de servidores.
6. Edge realiza NAT de origen para enviar tráfico al usuario, utilizando su VIP como dirección IP de origen.
El esquema a continuación.
Práctica
En mi entorno de prueba, he configurado 3 servidores con Apache, que está configurado para funcionar a través de HTTPS. Edge equilibrará las solicitudes HTTPS utilizando el método round robin, proxyizando cada nueva solicitud a un nuevo servidor.
Comencemos.
Generando un certificado SSL que usará NSX Edge.
Puede importar un certificado CA válido o usar uno autofirmado. En esta prueba, utilizaré uno autofirmado.
- En la interfaz de vCloud Director, vamos a la configuración de los servicios Edge.
- Vamos a la pestaña Certificados. En la lista de acciones, seleccionamos añadir una nueva CSR.
- Llenamos los campos necesarios y hacemos clic en Keep.
- Seleccionamos el CSR recién creado y elegimos la opción self-sign CSR.
- Elegimos la duración de validez del certificado y hacemos clic en Keep.
- El certificado autofirmado ha aparecido en la lista de disponibles.
Configuramos el Perfil de Aplicación.
Los perfiles de aplicación brindan un mayor control sobre el tráfico de red y facilitan su gestión. Con ellos, se puede definir el comportamiento para tipos específicos de tráfico.
- Vamos a la pestaña Load Balancer y activamos el equilibrador. La opción Acceleration enabled aquí permite que el equilibrador utilice un balanceo L4 más rápido en lugar de L7.
- Vamos a la pestaña Application profile para establecer el perfil de la aplicación. Haz clic en +.
- Asignamos un nombre al perfil y elegimos el tipo de tráfico para el que se aplicará el perfil. A continuación, explicaré algunos parámetros.
Persistencia – conserva y rastrea los datos de la sesión, por ejemplo: qué servidor específico del grupo está atendiendo la solicitud de un usuario. Esto garantiza que las solicitudes del usuario se dirijan al mismo miembro del grupo durante toda la vida de la sesión o en sesiones posteriores.
Habilitar SSL passthrough – al seleccionar esta opción, NSX Edge deja de terminar SSL. En su lugar, la terminación ocurre directamente en los servidores que se están equilibrando.
Insertar el encabezado HTTP X-Forwarded-For – permite identificar la dirección IP original del cliente que se conecta al servidor web a través del equilibrador.
Habilitar SSL del lado del Pool – permite especificar que el grupo seleccionado consta de servidores HTTPS.
- Dado que voy a equilibrar tráfico HTTPS, necesito habilitar SSL del lado del Pool y seleccionar el certificado generado anteriormente en la pestaña Certificados del Servidor Virtual —> Certificado de Servicio.
- Análogamente para Certificados del Pool —> Certificado de Servicio.
Creamos un grupo de servidores cuyo tráfico será equilibrado:
- Vamos a la pestaña Pools. Hacemos clic en +.
- Asignamos un nombre al grupo, elegimos el algoritmo (usaré round robin) y el tipo de monitoreo para el health check del backend. La opción Transparent indica si las direcciones IP originales de los clientes son visibles para los servidores internos.
- Si la opción está desactivada, el tráfico para los servidores internos proviene de la IP de origen del equilibrador.
- Si la opción está activada, los servidores internos ven las IP de origen de los clientes. En tal configuración, NSX Edge debe actuar como puerta de enlace por defecto para garantizar que los paquetes devueltos pasen a través de NSX Edge.
NSX admite los siguientes algoritmos de balanceo:
- IP_HASH – selección del servidor en función de los resultados de la función hash para las IP de origen y destino de cada paquete.
- LEASTCONN – balanceo de conexiones entrantes, dependiendo de la cantidad que ya existen en cada servidor. Nuevas conexiones se dirigirán al servidor con la menor cantidad de conexiones.
- ROUND_ROBIN – nuevas conexiones se envían a cada servidor de manera secuencial, de acuerdo con el peso que se le haya asignado.
- URI – la parte izquierda del URI (hasta el signo de interrogación) se hash y se distribuye sobre el peso total de los servidores en el grupo. El resultado indica qué servidor recibe la solicitud, garantizando que la solicitud siempre se dirija al mismo servidor, mientras todos los servidores permanezcan disponibles.
- HTTPHEADER – balanceo en función de un encabezado HTTP específico que se puede especificar como parámetro. Si el encabezado falta o no tiene valor, se aplica el algoritmo ROUND_ROBIN.
- URL – en cada solicitud HTTP GET se busca por el parámetro URL especificado como argumento. Si hay un signo igual y un valor después del parámetro, el valor se hash y se distribuye sobre el peso total de los servidores en ejecución. El resultado indica qué servidor recibe la solicitud. Este proceso se utiliza para rastrear identificadores de usuarios en las solicitudes y asegurar que el mismo id de usuario siempre se envíe al mismo servidor, mientras todos los servidores permanezcan disponibles.
- En el bloque Members, pulsamos + para agregar servidores al grupo.
Aquí necesitamos especificar:- el nombre del servidor;
- la dirección IP del servidor;
- el puerto al que el servidor recibirá el tráfico;
- el puerto para la verificación de salud (Monitor healthcheck);
- peso (Weight) – este parámetro permite regular la cantidad proporcional de tráfico recibida para un miembro específico del grupo;
- Max Connections – el número máximo de conexiones al servidor;
- Min Connections – el número mínimo de conexiones que el servidor debe manejar antes de que el tráfico sea redirigido al siguiente miembro del grupo.
Así es como se ve el grupo final de tres servidores.
Agregamos el Servidor Virtual
- Vamos a la pestaña Servidores Virtuales. Pulsamos +.
- Activamos el servidor virtual usando Enable Virtual Server.
Le damos un nombre, seleccionamos el Application Profile, Pool y especificamos la dirección IP en la que el Servidor Virtual recibirá las solicitudes externas. Indicamos el protocolo HTTPS y el puerto 443.
Parámetros opcionales aquí:
Límite de Conexión – número máximo de conexiones simultáneas que puede manejar el servidor virtual;
Límite de Tasa de Conexión (CPS) – número máximo de nuevas solicitudes entrantes por segundo.
Con esto, la configuración del balanceador se ha completado y se puede verificar su funcionamiento. Los servidores tienen una configuración simple que permite entender qué servidor del pool ha manejado la solicitud. Durante la configuración, elegimos el algoritmo de balanceo Round Robin, y el parámetro Weight para cada servidor es uno, por lo que cada siguiente solicitud será manejada por el siguiente servidor del pool.
Introducimos en el navegador la dirección externa del balanceador y vemos:
Después de recargar la página, la solicitud será manejada por el siguiente servidor:
Y una vez más, para verificar el tercer servidor del pool:
Al verificar, podemos ver que el certificado que nos envía Edge es el mismo que generamos al principio.
Verificación del estado del balanceador desde la consola de Edge gateway. Para esto, ingrese show service loadbalancer pool.
Configuramos el Service Monitor para comprobar el estado de los servidores en el pool
Con el Service Monitor podemos rastrear el estado de los servidores en el backend pool. Si la respuesta a la solicitud no coincide con lo esperado, se puede sacar al servidor del pool para que no reciba nuevas solicitudes.
Por defecto, se han configurado tres métodos de verificación:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Crearemos uno nuevo.
- Nos dirigimos a la pestaña de Service Monitoring, hacemos clic en +.
- Seleccionamos:
- nombre para el nuevo método;
- intervalo con el que se enviarán las solicitudes,
- tiempo de espera de respuesta,
- tipo de monitoreo – solicitud HTTPS utilizando el método GET, código de estado esperado – 200(OK) y URL de la solicitud.
- Con esto, la configuración del nuevo Service Monitor ha finalizado, ahora podemos usarlo al crear el pool.
Configuramos las Reglas de Aplicación
Las Reglas de Aplicación son una forma de manipular el tráfico basado en ciertos disparadores. Con esta herramienta, podemos crear reglas avanzadas de balanceo de carga cuya configuración puede no ser posible a través de los perfiles de aplicación o mediante otros servicios disponibles en Edge Gateway.
- Para crear una regla, vamos a la pestaña Reglas de Aplicación del balanceador.
- Elegimos un nombre, el script que utilizará la regla y hacemos clic en Conservar.
- Después de crear la regla, necesitamos editar el Servidor Virtual ya configurado.
- En la pestaña Avanzado, añadimos la regla que hemos creado.
En el ejemplo anterior, habilitamos el soporte para tlsv1.
Un par de ejemplos más:
Redirigir tráfico a otro grupo.
Con este script podemos redirigir el tráfico a otro grupo de balanceo si el grupo principal no está funcionando. Para que la regla funcione, el balanceador debe estar configurado con varios grupos y todos los miembros del grupo principal deben estar en estado inactivo. Debe especificar el nombre del grupo y no su ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Redirigir tráfico a un recurso externo.
Aquí estamos redirigiendo el tráfico a un sitio web externo si todos los participantes del grupo principal están en estado inactivo.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Más ejemplos .
Eso es todo sobre el balanceador de carga. Si tienes alguna pregunta, pregúntame, estoy dispuesto a responder.
Fuente: habr.com
