> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/es/pam/deploy-operate/install-cluster.md).

# 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

{% hint style="warning" %}
**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.
{% endhint %}

## 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](/es/pam/deploy-operate/install-single-node.md) 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](/es/pam/deploy-operate/requirements.md). 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](/es/pam/deploy-operate/network-requirements.md).
* **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.

{% hint style="warning" %}
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.
{% endhint %}

El acceso inverso por un [broker](/es/pam/administration/connectivity/broker.md) 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](/es/pam/deploy-operate/install-single-node.md)
* [Requisitos del sistema](/es/pam/deploy-operate/requirements.md)
* [Requisitos de red y conectividad](/es/pam/deploy-operate/network-requirements.md)
* [Broker](/es/pam/administration/connectivity/broker.md)
* [Gateways](/es/pam/administration/connectivity/gateways.md)