La última vez hablamos sobre las capacidades de NSX Edge en términos de enrutamiento estático y dinámico, y hoy nos ocuparemos del equilibrador de carga.
Antes de comenzar con la configuración, me gustaría recordarles brevemente los principales tipos de equilibrio.
Теория
Todas las soluciones de equilibrio de carga útil actuales se dividen con mayor frecuencia en dos categorías: equilibrio en el cuarto (transporte) y séptimo nivel (aplicación) del modelo. . El modelo OSI no es el mejor punto de referencia a la hora de describir métodos de equilibrio. Por ejemplo, si un equilibrador L4 también admite la terminación TLS, ¿se convierte en un equilibrador L7? Pero es lo que es.
- Equilibrador L4 la mayoría de las veces es un proxy intermedio entre el cliente y un conjunto de backends disponibles, que finaliza las conexiones TCP (es decir, responde independientemente a SYN), selecciona un backend e inicia una nueva sesión TCP en su dirección, enviando SYN de forma independiente. Este tipo es uno de los básicos, son posibles otras opciones.
- Equilibrador L7 distribuye el tráfico entre los backends disponibles "más sofisticados" que el equilibrador L4. Puede decidir qué backend elegir basándose, por ejemplo, en el contenido del mensaje HTTP (URL, cookie, etc.).
Independientemente del tipo, el equilibrador puede admitir las siguientes funciones:
- El descubrimiento de servicios es el proceso de determinar el conjunto de backends disponibles (estático, DNS, cónsul, etc.).
- Comprobación de la funcionalidad de los backends detectados (ping activo del backend mediante una solicitud HTTP, detección pasiva de problemas en las conexiones TCP, presencia de varios códigos 503 HTTP en las respuestas, etc.).
- El equilibrio en sí (round robin, selección aleatoria, hash de IP de origen, URI).
- Terminación 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 compatibilidad con dos modos de implementación del equilibrador de carga:
Modo proxy o de un solo brazo. En este modo, NSX Edge utiliza su dirección IP como dirección de origen al enviar una solicitud a uno de los backends. Así, el equilibrador realiza simultáneamente las funciones de NAT de origen y destino. El backend ve todo el tráfico enviado desde el equilibrador y responde directamente a él. En tal esquema, el equilibrador debe estar en el mismo segmento de red que los servidores internos.
Así es como sucede:
1. El usuario envía una solicitud a la dirección VIP (dirección del balanceador) que está configurada en Edge.
2. Edge selecciona uno de los backends y realiza la NAT de destino, reemplazando la dirección VIP con la dirección del backend seleccionado.
3. Edge realiza NAT de origen y reemplaza la dirección del usuario que envió la solicitud por la suya propia.
4. El paquete se envía al backend seleccionado.
5. El backend no responde directamente al usuario, sino al Edge, ya que la dirección original del usuario se ha cambiado a la dirección del balanceador.
6. Edge transmite la respuesta del servidor al usuario.
El diagrama está a continuación.
Modo transparente o en línea. En este escenario, el equilibrador tiene interfaces en las redes interna y externa. Al mismo tiempo, no existe acceso directo a la red interna desde la externa. El equilibrador de carga integrado actúa como puerta de enlace NAT para máquinas virtuales en la red interna.
El mecanismo es el siguiente:
1. El usuario envía una solicitud a la dirección VIP (dirección del balanceador) que está configurada en Edge.
2. Edge selecciona uno de los backends y realiza la NAT de destino, reemplazando la dirección VIP con la dirección del backend seleccionado.
3. El paquete se envía al backend seleccionado.
4. El backend recibe una solicitud con la dirección original del usuario (no se realizó la NAT de origen) y responde directamente a ella.
5. El equilibrador de carga vuelve a aceptar el tráfico, ya que en un esquema en línea suele actuar como puerta de enlace predeterminada para la granja de servidores.
6. Edge realiza NAT de origen para enviar tráfico al usuario, utilizando su VIP como dirección IP de origen.
El diagrama está a continuación.
Práctica
Mi banco de pruebas tiene 3 servidores que ejecutan Apache, que está configurado para funcionar a través de HTTPS. Edge realizará un equilibrio por turnos de solicitudes HTTPS, enviando cada nueva solicitud a un nuevo servidor.
Vamos a empezar
Generar un certificado SSL que utilizará NSX Edge
Puede importar un certificado de CA válido o utilizar uno autofirmado. Para esta prueba usaré autofirmado.
- En la interfaz de vCloud Director, vaya a la configuración de servicios Edge.
- Vaya a la pestaña Certificados. De la lista de acciones, seleccione agregar una nueva CSR.
- Complete los campos obligatorios y haga clic en Conservar.
- Seleccione la CSR recién creada y seleccione la opción CSR de autofirma.
- Seleccione el período de validez del certificado y haga clic en Conservar
- El certificado autofirmado aparece en la lista de disponibles.
Configurar el perfil de la aplicación
Los perfiles de aplicaciones le brindan un control más completo sobre el tráfico de la red y hacen que su administración sea simple y efectiva. Se pueden utilizar para definir el comportamiento de tipos de tráfico específicos.
- Vaya a la pestaña Load Balancer y habilite el balanceador. La opción Aceleración habilitada aquí permite que el equilibrador utilice un equilibrio L4 más rápido en lugar de L7.
- Vaya a la pestaña Perfil de la aplicación para configurar el perfil de la aplicación. Haga clic en +.
- Establezca el nombre del perfil y seleccione el tipo de tráfico para el que se aplicará el perfil. Déjame explicarte algunos parámetros.
Persistencia – almacena y rastrea datos de la sesión, por ejemplo: qué servidor específico en el grupo está atendiendo la solicitud del usuario. Esto garantiza que las solicitudes de los usuarios se enruten al mismo miembro del grupo durante la duración de la sesión o las sesiones posteriores.
Habilitar paso a través de SSL – Cuando se selecciona esta opción, NSX Edge deja de finalizar SSL. En cambio, la terminación se produce directamente en los servidores que se están equilibrando.
Insertar encabezado HTTP X-Forwarded-For – le permite determinar la dirección IP de origen del cliente que se conecta al servidor web a través del equilibrador de carga.
Habilitar SSL junto a la piscina – le permite especificar que el grupo seleccionado consta de servidores HTTPS.
- Dado que equilibraré el tráfico HTTPS, necesito habilitar SSL junto a la piscina y seleccionar el certificado generado previamente en la pestaña Certificados de servidor virtual -> Certificado de servicio.
- De manera similar para Certificados de grupo -> Certificado de servicio.
Creamos un grupo de servidores, cuyo tráfico será equilibrado. Grupos
- Vaya a la pestaña Grupos. Haga clic en +.
- Configuramos el nombre del grupo, seleccionamos el algoritmo (usaré round robin) y el tipo de monitoreo para el backend de verificación de estado. La opción Transparente indica si las IP de origen iniciales de los clientes son visibles para los servidores internos.
- Si la opción está deshabilitada, el tráfico de los servidores internos proviene de la IP de origen del equilibrador.
- Si la opción está habilitada, los servidores internos ven la IP de origen de los clientes. En esta configuración, NSX Edge debe actuar como puerta de enlace predeterminada para garantizar que los paquetes devueltos pasen a través de NSX Edge.
NSX admite los siguientes algoritmos de equilibrio:
- IP_HASH – selección del servidor basada en los resultados de una función hash para la IP de origen y destino de cada paquete.
- MENOS CONEXIÓN – equilibrio de conexiones entrantes, dependiendo del número ya disponible en un servidor en particular. Las nuevas conexiones se dirigirán al servidor con la menor cantidad de conexiones.
- ROUND_ROBIN – las nuevas conexiones se envían a cada servidor por turno, de acuerdo con el peso que se le asigna.
- URI – la parte izquierda del URI (antes del signo de interrogación) se aplica un hash y se divide por el peso total de los servidores en el grupo. El resultado indica qué servidor recibe la solicitud, lo que garantiza que la solicitud siempre se enrute al mismo servidor, siempre que todos los servidores permanezcan disponibles.
- ENCABEZADO HTTP – equilibrio basado en un encabezado HTTP específico, que se puede especificar como parámetro. Si falta el encabezado o no tiene ningún valor, se aplica el algoritmo ROUND_ROBIN.
- Enlance – Cada solicitud HTTP GET busca el parámetro de URL especificado como argumento. Si el parámetro va seguido de un signo igual y un valor, entonces el valor se aplica mediante hash y se divide por el peso total de los servidores en ejecución. El resultado indica qué servidor recibe la solicitud. Este proceso se utiliza para realizar un seguimiento de los ID de usuario en las solicitudes y garantizar que siempre se envíe el mismo ID de usuario al mismo servidor, siempre que todos los servidores permanezcan disponibles.
- En el bloque Miembros, haga clic en + para agregar servidores al grupo.
Aquí debe especificar:- nombre del servidor;
- Dirección IP del servidor;
- el puerto en el que el servidor recibirá tráfico;
- puerto para control de salud (Monitor control de salud);
- peso: con este parámetro puede ajustar la cantidad proporcional de tráfico recibido para un miembro específico del grupo;
- Conexiones máximas: número máximo de conexiones al servidor;
- Conexiones mínimas: el número mínimo de conexiones que el servidor debe procesar antes de que el tráfico se reenvíe al siguiente miembro del grupo.
Así es como se ve el grupo final de tres servidores.
Agregar servidor virtual
- Vaya a la pestaña Servidores virtuales. Haga clic en +.
- Activamos el servidor virtual usando Enable Virtual Server.
Le damos un nombre, seleccionamos el Perfil de Aplicación, Pool previamente creado e indicamos la dirección IP a la que el Servidor Virtual recibirá solicitudes del exterior. Especificamos el protocolo HTTPS y el puerto 443.
Parámetros opcionales aquí:
Límite de conexión – el número máximo de conexiones simultáneas que el servidor virtual puede procesar;
Límite de velocidad de conexión (CPS) – el número máximo de nuevas solicitudes entrantes por segundo.
Esto completa la configuración del equilibrador, puede comprobar su funcionalidad. Los servidores tienen una configuración simple que le permite comprender qué servidor del grupo procesó la solicitud. Durante la configuración, elegimos el algoritmo de equilibrio Round Robin y el parámetro Peso para cada servidor es igual a uno, por lo que cada solicitud posterior será procesada por el siguiente servidor del grupo.
Ingresamos la dirección externa del balanceador en el navegador y vemos:
Después de actualizar la página, la solicitud será procesada por el siguiente servidor:
Y nuevamente, para verificar el tercer servidor del grupo:
Al comprobar, puedes ver que el certificado que nos envía Edge es el mismo que generamos al principio.
Comprobación del estado del equilibrador desde la consola de la puerta de enlace Edge. Para hacer esto, ingrese mostrar el grupo de equilibradores de carga del servicio.
Configuración de Service Monitor para verificar el estado de los servidores en el grupo
Usando Service Monitor podemos monitorear el estado de los servidores en el grupo backend. Si la respuesta a una solicitud no es la esperada, el servidor se puede sacar del grupo para que no reciba nuevas solicitudes.
De forma predeterminada, se configuran tres métodos de verificación:
- monitor TCP,
- monitor HTTP,
- Monitor HTTPS.
Creemos uno nuevo.
- Vaya a la pestaña Monitoreo de servicio, haga clic en +.
- Escoger:
- nombre del nuevo método;
- el intervalo en el que se enviarán las solicitudes,
- tiempo de espera esperando una respuesta,
- tipo de monitoreo: solicitud HTTPS utilizando el método GET, código de estado esperado: 200 (OK) y URL de solicitud.
- Esto completa la configuración del nuevo Service Monitor; ahora podemos usarlo al crear un grupo.
Configurar reglas de aplicación
Las reglas de aplicación son una forma de manipular el tráfico en función de ciertos factores desencadenantes. Con esta herramienta podemos crear reglas avanzadas de equilibrio de carga que pueden no ser posibles a través de perfiles de aplicación u otros servicios disponibles en Edge Gateway.
- Para crear una regla, vaya a la pestaña Reglas de aplicación del balanceador.
- Seleccione un nombre, un script que utilizará la regla y haga clic en Conservar.
- Una vez creada la regla, debemos editar el servidor virtual ya configurado.
- En la pestaña Avanzado, agregue la regla que creamos.
En el ejemplo anterior habilitamos la compatibilidad con tlsv1.
Un par de ejemplos más:
Redirigir el tráfico a otro grupo.
Con este script podemos redirigir el tráfico a otro grupo de equilibrio si el grupo principal no funciona. Para que la regla funcione, se deben configurar varios grupos en el equilibrador y todos los miembros del grupo principal deben estar inactivos. Debe especificar el nombre del grupo, no su ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Redirigir el tráfico a un recurso externo.
Aquí redirigimos el tráfico al sitio web externo si todos los miembros del grupo principal están caídos.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Aún más ejemplos .
Eso es todo para mí sobre el equilibrador. Si tienes alguna duda, pregunta, estoy dispuesto a responder.
Fuente: habr.com