¶ Balanceador de Carga
Los balanceadores de carga permiten distribuir de forma eficiente el tráfico entrante (HTTP, HTTPS o conexiones TCP) entre un conjunto de instancias que forman parte de un pool de servidores a puertos concretos de cada máquina. Esta distribución mejora la disponibilidad, escalabilidad y tolerancia a fallos del sistema.
En esta sección se detallan las configuraciones disponibles para implementar y gestionar un balanceador del orquestador.
¶ Crear un Balanceador
Es tan sencillo como arrastrar el icono a cualquier parte del D&D.
¶ Detalles de un Balanceador
Se puede observar una primera pantalla donde se especifican los detalles del balanceador de carga.
Nombre del Balanceador.
Especificamos el sabor que requiere el balanceador.
Podemos elegir si el Balanceador va a arrancar en modo activo o inactivo.
Debemos de especificar la red en la que desplegaremos el balanceador.
Debemos de especificar la subred en la que tendremos las instancias que queramos asociar al Balanceador.
Podemos añadir una descripción del Balanceador.
¶ Detalles del Listener
Un listener es el componente del balanceador que escucha las conexiones entrantes en un puerto y protocolo específico. Se encarga de recibir el tráfico y enviarlo a los pools correspondientes según la configuración definida.
En esta segunda ventana se accede a los detalles de Listener.
Nombre del Balanceador y se le añade -listener.
Podemos añadir una descripción del Listener.
Especifica el número de conexiones simultáneas al balanceador, -1 significa sin límites.
Especificamos el protocolo entre el balanceador y Listener.
Podemos elegir si el Listener va a arrancar en modo activo o inactivo.
Podemos especificar el puerto del protocolo, por si fuera uno alternativo a los indicados en HTTP y HTTPS, en TCP deberemos de indicar el puerto específico.
¶ Detalles del Pool
En esta ventana se configuran los detalles del pool.
Nombre del Balanceador y se le añade -pool.
Podemos elegir si el pool va a arrancar en modo activo o inactivo.
Podemos elegir entre diferentes algoritmos de balanceo de carga.
-
LEAST_CONNECTIONS: Calcula el número de conexiones activas por Instancia durante un tiempo determinado y dirige el tráfico entrante a la Instancia con la menor cantidad de conexiones.
-
ROUND_ROBIN: Es un método para seleccionar todas las instancias en un pool de manera equitativa y en un orden racional, normalmente comenzando por el primer elemento de la lista hasta llegar al último y empezando de nuevo desde la primera Instancia.
-
SOURCE_IP: Todas las conexiones con la misma IP de origen serán manejadas por el mismo miembro del pool.
-
SOURCE_IP_PORT: Todas las conexiones con la misma IP de origen serán manejadas por el mismo miembro del pool dependiendo del puerto.
-
APP_COOKIE: Funciona de la misma manera que HTTP_COOKIE, sin embargo este método resulta útil si dispone de aplicaciones y servicios de backend web que no pueden generar sus propias cookies.
-
HTTP_COOKIE: Al configurar la persistencia de cookie, el Balanceador inserta una cookie en la respuesta. Los parámetros configurados en la cookie permiten la persistencia de sesiones.
-
SOURCE_IP: Mantiene las sesiones provenientes de la IP origen al mismo servidor.
¶ Detalles del Monitor
En esta ventana se pueden configurar los detalles de monitor.
Nombre del monitor.
El tiempo que tarda el monitor en enviar un mensaje de comprobación.
Tiempo de espera hasta recibir respuesta de la comprobación de estado.
Número de intentos fallidos antes de dar como erróneo el nodo del pool.
Podemos elegir entre diferentes tipos.
¶ Detalles de los miembros
En esta última ventana se configuran los detalles de los miembros.
Para acceder a la configuración se debe activar la pestaña de Crear miembro.
Nombre del miembro.
Podemos elegir si el conector del Balanceador va a arrancar en modo activo o inactivo.
Si disponemos de más de un balanceador, podremos indicar la importancia, siendo el número más bajo desde el 1 el más importante.
Debemos indicar de nuevo el puerto del protocolo que hayamos definido en el Listener.
Debemos seleccionar un puerto de los disponibles de la subred seleccionada a donde se redirigirá el tráfico del balanceador.
Puerto de protocolo: Debemos indicar de nuevo el puerto del protocolo que hayamos definido en el Listener.
Peso: Si disponemos de más de un balanceador, podremos indicar la importancia, siendo el número más bajo desde el 1 el más importante.
Estado de administración: Podemos elegir si el conector del Balanceador va a arrancar en modo activo o inactivo.
Disponibles - Seleccionados:
Podremos arrastrar las instancias de la subred dentro del pool a seleccionados.
Tenga en cuenta que para que el balanceador funcione, necesita todos los componentes configurados en administración activos. (Balanceador, Listener, Pool, Monitor y Miembros).
¶ Capa L7 (Aplicación)
A los balanceadores se les pueden asignar reglas y políticas que actúan sobre la capa 7 del modelo OSI, es decir, sobre la capa de Aplicación. En esta capa se encuentran protocolos como HTTP, SMTP, FTP, etc. Gracias a esto, se puede analizar el tipo de contenido de las peticiones permitiendo una configuración más completa.
¶ Detalles de la Política L7
En esta ventana se configuran las acciones que se ejecutarán cuando se cumplan las reglas definidas.
Nombre de la política L7.
Podemos elegir si la política va a arrancar en modo activo o inactivo.
Define la acción que se aplicará cuando se cumpla la regla asociada.
Acciones disponibles:
- REDIRECT_TO_URL: Redirige la petición a una URL específica.
- REDIRECT_TO_POOL: Redirige el tráfico a un pool concreto.
- REDIRECT_PREFIX: Redirige cambiando solo el inicio de la url.
- REJECT: Rechaza la petición del cliente.
En caso de seleccionar REDIRECT_TO_URL, se deberá indicar la URL destino (por ejemplo: https://nuevaweb.com).
En caso de seleccionar REDIRECT_TO_POOL, se deberá seleccionar el pool al que enviar el tráfico.
¶ Detalles de la Regla L7
En esta ventana se definen las condiciones que deben cumplirse para que se aplique una política L7.
Define el tipo de información que se va a evaluar en la petición.
Tipos más comunes:
- HOST_NAME: Evalúa el dominio solicitado.
- PATH: Evalúa la ruta de la URL.
- FILE_TYPE: Evalúa la extensión del archivo.
- HEADER: Evalúa cabeceras HTTP.
Indica cómo se comparará el valor introducido con la petición.
Opciones disponibles:
- EQUAL_TO: Coincidencia exacta.
- CONTAINS: Contiene el valor indicado.
- STARTS_WITH: Comienza por el valor indicado.
- ENDS_WITH: Termina por el valor indicado.
Campo utilizado en algunas reglas avanzadas (por ejemplo, cabeceras HTTP).
En la mayoría de configuraciones básicas puede dejarse vacío.
Valor que se va a comparar con la petición entrante.
Ejemplos:
/ruta→ para rutasmidominio.com→ para dominios
¶ Funcionamiento conjunto de Políticas y Reglas L7
Las Reglas L7 y las Políticas L7 trabajan conjuntamente:
- La Regla L7 define la condición ("si ocurre esto")
- La Política L7 define la acción ("haz esto")
¶ Ejemplo práctico
-
Regla:
- Tipo:
PATH - Comparación:
STARTS_WITH - Valor:
/antigua
- Tipo:
-
Política:
- Acción:
REDIRECT_TO_URL - URL:
https://nuevaweb.com
- Acción:
✅ Resultado:
Cuando un usuario acceda a /antigua, será redirigido a la nueva web.
💡 Se recomienda utilizar comparaciones como STARTS_WITH en lugar de CONTAINS para evitar coincidencias no deseadas.
Finalmente se mostrará un resumen de la configuración del balanceador antes de crearse.
