Instalar un clúster de alta disponibilidad

De qué se compone un despliegue de alta disponibilidad, en qué se diferencia de un nodo único, qué decisiones cerrar antes del montaje, y cómo demostrar que el clúster tolera de verdad la pérdida de u

Valide este procedimiento contra la versión que está desplegando. El procedimiento de instalación cambia entre versiones, y las fuentes con las que se ha construido esta página no indican para qué versión se escribieron.

El montaje paso a paso del clúster lo mantiene DataDike y no está documentado aquí. El aprovisionamiento de los nodos, la replicación de la base de datos y de Redis, el almacenamiento compartido de las grabaciones y la configuración de la dirección virtual son todos específicos de la versión y se realizan junto al equipo de implantación. Lo que sigue es de qué se compone un clúster, qué debe decidir antes del montaje y cómo verificar el resultado. No es un procedimiento para seguir sin ayuda.

Qué es esto y cuándo usarlo

Un clúster son varios nodos tras una dirección virtual, con los datos replicados entre ellos, de modo que la pérdida de un nodo no se lleve consigo el acceso privilegiado. Elíjalo cuando una caída de la plataforma signifique una caída de su capacidad de administrar todo lo demás.

Todo lo que hay en Instalar un nodo único sigue aplicando: licencia, DNS, certificado, fuentes de autenticación, retención. Esta página cubre solo lo que cambia.

En qué se diferencia un clúster de un nodo único

	Nodo único	Clúster
Punto de entrada del cliente	La dirección del propio nodo	Una única dirección virtual (keepalived). Apunte usuarios, DNS e integraciones a la dirección virtual, nunca a un nodo
Direcciones de los nodos	La única dirección	Cada nodo responde además directamente en su propia dirección, y eso es lo que hace posible la monitorización por nodo
Datos	Locales al nodo	Replicados entre los nodos
Carga de sesiones	En el nodo	Distribuida entre los nodos, y redistribuida cuando se pierde uno
Almacenamiento de grabaciones	El disco local es el valor instalado por defecto	El disco local deja cada grabación en el nodo que la produjo. El almacenamiento de objetos externo es, en la práctica, obligatorio
Componentes	Se registran una vez	Los componentes de cada nodo se registran por sí mismos y aparecen en la consola con la dirección de ese nodo

Se ofrecen tres topologías: activo-activo, activo-pasivo y clúster de réplica de DR. La documentación de disponibilidad declara objetivos de diseño de RTO ≤ 1 hora y RPO ≤ 15 minutos para la arquitectura activo/activo, y redundancia de los componentes de bóveda, de intermediación de sesiones y de consola de administración, para que ninguno de ellos sea un punto único de fallo.

Antes de empezar

• Dimensionamiento por nodo. Las cifras publicadas cubren una instancia; consulte Requisitos del sistema. Confirme con DataDike si todos los nodos llevan la misma especificación y qué necesita la capa de almacenamiento compartido.

• La dirección virtual y el nombre DNS que apunta a ella. El nombre que usan sus usuarios y sus integraciones debe resolver a la dirección virtual, no a un nodo.

• Almacenamiento de objetos externo para las grabaciones, configurado como backend por defecto desde el primer día. Encajarlo más tarde deja grabaciones varadas en nodos individuales.

• Reglas de firewall, incluidos los puertos que se usan entre nodos para la replicación. Consígalos de DataDike antes de situar los nodos en segmentos distintos. Consulte Requisitos de red y conectividad.

• El licenciamiento adicional que, según la documentación de disponibilidad, exige la alta disponibilidad on-premises "según el dimensionamiento". Pone como ejemplos el licenciamiento de base de datos y de Windows RDS y las licencias de HA, sin dar una lista definitiva. Resuélvalo comercialmente antes del montaje.

Cómo se compone el clúster

La plataforma es un conjunto de microservicios que se registran por sí mismos en el core una vez instalados y configurados, y así es como se ensambla un clúster: los conectores de terminal, gráfico, de base de datos y de aplicaciones virtuales de cada nodo, su servicio de tareas y sus servicios de grabación aparecen en la consola como componentes registrados independientes, cada uno mostrando la dirección del nodo en el que se ejecuta.

El registro viene habilitado por defecto y, mientras está activo, cualquier componente que conozca la dirección de la plataforma puede registrarse por su cuenta. En cuanto estén presentes los componentes de todos los nodos, desmarque Registration en Configuración del sistema › Componentes › Básico, y vuelva a habilitarlo solo el tiempo necesario para añadir un nodo o un conector.

El acceso inverso por un broker es redundante por diseño: el componente que marca hacia el broker se ejecuta como una instancia por nodo del clúster, cada una con su propia identidad, enrolamiento automático y recuperación autónoma. Perder un nodo de la plataforma no interrumpe el acceso inverso, y perder un nodo de broker tampoco: los restantes siguen atendiendo.

Si la plataforma se entrega como SaaS

La modalidad alojada por el proveedor se ofrece con un conector local redundante en su entorno, para que el acceso siga funcionando de forma transparente si el enlace con la nube se cae. La sincronización entre los componentes de los dos sitios es automática y en tiempo real: si los componentes de un sitio quedan indisponibles, el otro sitio asume los servicios sin pérdida de datos. Las conexiones son unidireccionales, desde su entorno hacia la nube del proveedor, nunca al revés.

Qué debería ver

La dirección virtual responde, y cada nodo responde también en la suya propia. Configuración del sistema › Componentes lista los componentes de todos los nodos, cada uno con su propia Dirección remota y un Load status igual a Normal. Un nodo que nunca se registró aparece como una ausencia en esa lista, lo que es más fácil de pasar por alto que un fallo. Cuente los nodos.

Cómo verificar que funcionó

Un clúster al que nunca se le ha provocado un failover no es un clúster verificado.

1. Consulte /api/health/ en la dirección virtual y después en cada nodo directamente. El endpoint no exige autenticación y devuelve status, db_status, db_time, redis_status, redis_time y time, de modo que demuestra el acceso de ese nodo a la base de datos y a Redis, y no solo que nginx respondió. Deje las consultas por nodo de forma permanente en su monitorización: un clúster esconde un único nodo enfermo tras la dirección virtual, y esto es lo que lo saca a la luz.

2. Cuente los componentes. Los conectores de todos los nodos presentes en Configuración del sistema › Componentes, todos en Normal, cada uno con la Dirección remota esperada.

3. Confirme que las grabaciones no son locales al nodo. Abra una sesión en un nodo y después reproduzca su grabación a través de la dirección virtual hasta caer en un nodo distinto. Si la reproducción depende de qué nodo responde, las grabaciones siguen en disco local.

4. Tire un nodo a propósito, en una ventana de mantenimiento y con la orientación de DataDike. La dirección virtual debe seguir respondiendo, una sesión nueva debe seguir conectando, y el registro de auditoría debe seguir mostrándolo. Después devuelva el nodo y confirme que se reincorpora: es en la lista de componentes donde lo verá volver.

5. Compruebe qué ocurrió con las sesiones que estaban en curso durante esa prueba. Las fuentes afirman que el acceso sigue disponible y que la carga de sesiones se redistribuye; no afirman que las sesiones ya abiertas sobrevivan al fallo de un nodo. Mídalo en su propio despliegue.

Errores frecuentes

Síntoma	Causa	Solución
A los usuarios el fallo de un nodo unas veces no les afecta y otras les corta el acceso	Los clientes, el DNS o una integración apuntan a la dirección propia de un nodo en lugar de a la dirección virtual	Apunte todo a la dirección virtual; reserve las direcciones de nodo solo para monitorización y administración
Una grabación unas veces se reproduce y otras da 404	Las grabaciones están en el backend local Servidor, de modo que cada archivo solo existe en el nodo que lo produjo	Configure almacenamiento de objetos externo y conviértalo en el backend por defecto
Un nodo está en marcha pero sus sesiones fallan	Uno de los conectores de ese nodo está Sin conexión mientras la dirección virtual le sigue enviando tráfico	Revise la lista de componentes por nodo y monitorice /api/health/ por nodo, no solo la dirección virtual
Aparece un componente inesperado en la lista	El registro se dejó habilitado después del montaje	Desmarque Registration y confirme qué se registró por su cuenta y desde qué dirección
Las contraseñas de un solo uso fallan en un solo nodo	El reloj de ese nodo se ha desviado; el TOTP se valida al segundo	Sincronice el reloj en todos los nodos, no solo en el que montó primero

Páginas relacionadas

• Instalar un nodo único

• Requisitos del sistema

• Requisitos de red y conectividad

• Broker

• Gateways