Esta sección le permite administrar el servicio de agrupación en clústeres, que garantiza una alta disponibilidad para el equilibrio de carga a través de dos nodos colaborativos en modo activo-pasivo.

Cómo funciona el proceso RELIANOID El clúster funciona #

Resumen #

El Clúster con estado en RELIANOID Garantiza la disponibilidad continua del servicio y la tolerancia a fallos mediante la combinación de dos nodos que operan juntos como una única unidad lógica.

El objetivo principal de esta configuración es evitar interrupciones del servicio y mantener una conectividad perfecta desde la perspectiva del cliente, incluso en caso de falla de un nodo.

Un clúster consta de dos nodos que funcionan en modo activo-pasivo , donde uno actúa como nodo maestro y el otro como nodo de respaldo.

• El nodo maestro Gestiona activamente todo el tráfico de clientes, equilibrando las conexiones a los servidores backend y manteniendo la información de sesión en tiempo real.
• El nodo de respaldo se queda en modo de espera, sincronizando continuamente su configuración, estado y datos de sesión con el maestro para estar listo para tomar el control en cualquier momento.

Si el nodo maestro deja de responder o queda inaccesible, el nodo de respaldo toma el control automáticamente, garantizando así la prestación ininterrumpida del servicio.

Selección de roles maestro y de respaldo #

Keepalived se encarga de determinar qué nodo actúa como maestro y cuál como respaldo , utilizando el protocolo VRRP (Protocolo de Redundancia de Enrutador Virtual) y mecanismos de seguimiento de interfaces .

A cada nodo del clúster se le asigna un valor de prioridad, que influye en el proceso de elección del maestro:

• El nodo con la prioridad más alta se selecciona como maestro.
• Si ambos nodos tienen la misma prioridad, el que tenga la dirección IP más baja se convierte en maestro de forma predeterminada.

Keepalived supervisa continuamente las interfaces monitorizadas (interfaces de red configuradas para la detección de fallos). Si una de estas interfaces falla o deja de estar disponible, la prioridad efectiva del nodo disminuye , lo que permite que el otro nodo asuma el rol de maestro.

Esto garantiza que el tráfico siempre se enrute a través del nodo más estable y completamente operativo.

Sincronización con estado #

RELIANOID Los clústeres operan en modo con estado, lo que significa que los datos de sesión y las tablas de conexión se sincronizan entre los nodos maestro y de respaldo en tiempo real.
Esta sincronización permite que las sesiones de clientes activas persistan incluso después de que se produzca una conmutación por error; los clientes no experimentan interrupciones ni necesitan volver a conectarse, lo que mantiene una experiencia de usuario fluida.

Los cambios de configuración, la configuración de IPDS, los certificados SSL y los estados de la granja también se replican automáticamente, lo que garantiza que ambos nodos permanezcan totalmente alineados en todo momento.

Comportamiento de mantenimiento #

Al realizar operaciones de mantenimiento (como actualizaciones de software, cambios de configuración o intervenciones de hardware), el clúster puede ajustar temporalmente los roles de maestro-respaldo:

• Si el modo de mantenimiento está habilitado en el maestro actual, nodo de respaldo Se promueve automáticamente a sí mismo como maestro, tomando el control de los servicios activos.
• Cuando finaliza el mantenimiento y se vuelve a habilitar el nodo, este se reincorpora al clúster como copia de seguridad a menos que esté configurado como el maestro preferido.

Este mecanismo garantiza que las actividades de mantenimiento puedan realizarse sin interrumpir las conexiones ni la disponibilidad de los clientes activos.

Nodo maestro preferido #

Los administradores pueden configurar un nodo maestro preferido dentro del clúster.

Esta configuración garantiza que, una vez que ambos nodos estén en línea y estables, el nodo preferido designado recuperará automáticamente el rol de maestro , incluso si el otro nodo asumió temporalmente el control durante una conmutación por error.

Ventajas #

• Enrutamiento de tráfico predecibleLa selección consistente de un maestro simplifica la monitorización, el registro y el análisis del tráfico.
• consistencia de configuración:Garantiza que un nodo conocido y estable siga siendo el punto de control predeterminado.

Desventajas #

• Cambios breves de servicio: cuando el nodo preferido regresa y recupera el rol de maestro, puede ocurrir un breve evento de conmutación por error, que potencialmente restablezca algunas sesiones.
• Menos flexibilidad en el control de conmutación por error: en ciertos casos, el clúster puede volver al maestro preferido incluso si ambos nodos están en buen estado, lo que podría generar transiciones innecesarias.

Para implementaciones que priorizan el máximo tiempo de actividad y la mínima interrupción , los administradores pueden optar por deshabilitar la opción de maestro preferido.

En entornos donde la coherencia de roles y la previsibilidad operativa son fundamentales, se recomienda habilitar el nodo maestro preferido.

Requisitos para crear un clúster #

Ambos nodos deben ejecutar la misma versión de Relianoid (es decir, el mismo modelo de dispositivo).
Cada nodo debe tener un nombre de host único.
La sincronización del reloj en el hipervisor debe estar desactivada. Se recomienda el uso del servidor NTP en ambos nodos.más información sobre la configuración de NTP).
Ambos nodos deben tener nombres de NIC idénticos (interfaces de red) con diferentes IP en las mismas subredes.
Ambos nodos deben tener conectividad con el otro nodo a través del puerto 22/TCP y permitir paquetes VRRP.
Ambos nodos deben tener las mismas políticas de seguridad (acceso a servicios y redes).
Los cambios de configuración se deben realizar únicamente en el nodo maestro, nunca en el nodo de respaldo.
Los dispositivos de conmutación y enrutamiento intermedios pueden requerir configuración para evitar conflictos con la conmutación del clúster. No se requiere modo promiscuo, cambios de dirección MAC ni transmisiones falsificadas. Sin embargo, el clúster podrá enviar paquetes ARP gratuitos.
Se recomienda configurar una IP flotante para evitar el tiempo de inactividad del servicio durante un cambio de clúster. Más información sobre IP flotantes.

Cuando los servicios de equilibrio de carga cambian de un nodo a otro, el nodo de respaldo administra las conexiones actuales y el estado del servicio para evitar interrupciones del cliente.

Componentes del servicio de cluster #

Esta es la página principal para configurar el Cluster. El servicio de clustering incluye varios componentes:

SINCRONIZACIÓN. Sincroniza automáticamente las configuraciones del nodo maestro al nodo de respaldo usando inotify y rsync atravesar SSH. Cada cambio aplicado en el sistema de archivos en el nodo maestro que esté relacionado con los servicios virtuales o la configuración común para los servicios virtuales se replicará automáticamente en el nodo de respaldo.
DISCIPULADO HEARTBEAT. Supervisa el estado de los nodos del clúster mediante el VRRP protocolo sobre multidifusión, facilitado por mantener viva.
Seguimiento de conexión. Replica los estados de conexión en tiempo real para permitir una conmutación por error perfecta sin interrumpir las conexiones del cliente o del backend, utilizando el rastreado .
Replicación de comandos. Envía y activa configuraciones desde el maestro al nodo de respaldo a través de administrador de clusters vía SSH.

El nodo donde se configura el clúster se convierte en el nodo maestro. Advertencia : Se borrará cualquier configuración previa en el nodo de respaldo, lo que provocará la pérdida de granjas (incluidos certificados), interfaces virtuales , reglas IPDS , etc.

Datos replicados en un clúster #

En un entorno de agrupación en clústeres, la replicación de datos garantiza que la configuración y el estado de los servicios sean coherentes entre los nodos maestro y de respaldo. A continuación se muestran los elementos específicos que se replican en los nodos:

• Servicios LSLB (equilibrador de carga de servidor local), GSLB (equilibrador de carga de servidor global), DSLB (equilibrador de carga de servidor de datos). Estos servicios son fundamentales para el equilibrio de carga y se replican para garantizar que la conmutación por error no interrumpa la distribución del tráfico, incluida la configuración, las sesiones y los estados del tráfico.
• Enrutamiento estatico. Las rutas definidas estáticamente se replican para mantener rutas de red consistentes.
• Configuración de RBAC (control de acceso basado en roles). Las funciones de usuario, los permisos y las configuraciones relacionadas se replican para garantizar que las políticas de seguridad sean consistentes en todos los nodos.
• Usuarios, grupos y permisos. Se sincronizan las cuentas de usuario, las membresías de grupos y los permisos asociados.
• Certificados SSL y configuración Let's Encrypt. Los certificados SSL, incluidos los administrados por Let's Encrypt, se replican para proteger las comunicaciones y los servicios.
• Interfaces virtuales, VLAN, de enlace y flotantes. Se replican las configuraciones de interfaces de red, como interfaces virtuales, VLAN, interfaces vinculadas e IP flotantes.
• Servicios VPN. Las configuraciones y los estados de VPN se sincronizan para mantener conexiones seguras.
• Reglas y archivos IPDS (Sistema de detección y prevención de intrusiones). Las reglas IPDS y los archivos asociados se replican para un monitoreo de seguridad consistente.
• Configuración de Farmguardians. Se replican las configuraciones de monitoreo y verificación de estado para granjas (grupos de servidores).
• Configuración de las notificaciones. La configuración de las notificaciones del sistema está sincronizada para garantizar que las alertas sean consistentes.

Datos no replicados en un clúster #

• Interfaces NIC físicas. Las configuraciones de las tarjetas de interfaz de red (NIC) físicas no se replican porque son específicas del hardware.
• Puertas de enlace predeterminadas. La configuración de la puerta de enlace predeterminada es local para cada nodo y no se replica.
• Configuración de Servicios Locales y Remotos. Servicios como DNS, NTP (Protocolo de hora de red) y SNMP (Protocolo simple de administración de red) se configuran localmente y no se replican.
• Claves API. Las claves API utilizadas para acceder a los servicios no se replican por motivos de seguridad.
• Certificados de Activación. Los certificados de activación para licencias de software no se replican.
• Paquetes instalados. Los paquetes de software instalados en los nodos no están sincronizados, ya que pueden variar entre nodos.
• Copias de seguridad. Las copias de seguridad generadas son específicas de cada nodo y, por lo tanto, no se replican entre nodos.

Configurar el servicio de cluster #

IP local. Seleccione entre las interfaces de red disponibles para la administración de clústeres (no se permiten interfaces virtuales).
IP remota. Dirección IP del futuro nodo de respaldo.
Contraseña del nodo remoto. Contraseña de root para el nodo remoto (copia de seguridad futura).
Confirmar contraseña del nodo remoto. Contraseña de root para el nodo remoto (copia de seguridad futura).

Tras introducir los parámetros necesarios, haga clic en el botón Aplicar .

Mostrar servicio de clúster #

Si el servicio de clúster está configurado y activo, muestra la siguiente información sobre servicios, backends y acciones:

Fácil de usar. Interfaz de red donde se configuran los servicios del cluster.
Failback. Opción de devolver los servicios de equilibrio de carga al maestro cuando vuelvan a estar disponibles.
Comprobar intervalo. Intervalo de tiempo para comprobaciones de latidos entre nodos.
Interfaces rastreadas. Interfaces de red activas monitoreadas en tiempo real.

Acciones del grupo #

Mostrar nodos. Muestra el estado de los nodos.
Editar. Modificar los ajustes de configuración.
Destruir. Elimine los ajustes de configuración y un nodo.

La acción Mostrar nodos muestra una tabla con:

Nodo. Indica si el nodo es local o remoto según el nodo donde se haya conectado a la GUI web. Local será el nodo al que estás conectado actualmente y sanaciones es el nodo remoto.
Rol. Muestra si el nodo está dominar (actualmente presta servicios de equilibrio de carga), copia de seguridad, o mantenimiento si es un nodo temporalmente deshabilitado.
IP. Dirección IP de cada nodo.
Hostname. Nombre de host de cada nodo.
Estado. Estado del nodo, indicado por:

• Rojo. Falla.
• Gris. Inalcanzable.
• Orange. Modo de mantenimiento.
• Verde. Operacional.

Mensaje. Mensajes de depuración de cada nodo.
Acciones. Las opciones para cada nodo incluyen.

• Habilitar mantenimiento. Deshabilita temporalmente un nodo para mantenimiento y evitar la conmutación por error.
• Deshabilitar el mantenimiento. Habilita el nodo nuevamente.

Configuración del clúster #

Opciones de configuración global disponibles:

Failback. Seleccione qué balanceador de carga se prefiere como maestro.
Seguimiento de interfaces para monitorear. Supervise interfaces específicas (por ejemplo, LAN o VLAN).
Comprobar intervalo. Tiempo entre comprobaciones de estado desde el nodo de respaldo hasta el maestro.

Haz clic en el botón Aplicar para guardar los cambios.

Mantenimiento y actualizaciones del cluster #

Para realizar mantenimiento o actualizar un clúster Relianoid con un tiempo de inactividad mínimo, consulte la guía detallada Actualizar RELIANOID Clúster con tiempo de inactividad mínimo.