Configuración de la recuperación ante desastres para Omnissa Access

Omnissa Access admite la recuperación ante desastres mediante un modelo de copia de seguridad y restauración con un montaje NFS compartido. En este modelo, un clúster secundario tiene acceso a los datos de copia de seguridad generados por el clúster primario. Tras declararse un evento de recuperación ante desastres, el clúster secundario se eleva manualmente a primario y se encarga del tráfico de lectura y escritura. La conmutación por recuperación al sitio original es una operación manual planificada (no se produce de forma automática). Cuando el clúster primario original vuelve a estar disponible, este permanece en el rol de secundario hasta que se ejecute la conmutación por recuperación planificada.

En este tema se describe cómo configurar el almacenamiento de copias de seguridad NFS, gestionar las programaciones de copias de seguridad, realizar copias de seguridad de los datos necesarios del nodo de arranque y restaurar Omnissa Access a partir de la copia de seguridad durante una conmutación por error.

---

Requisitos

Antes de configurar la recuperación ante desastres, asegúrese de que se cumplan las siguientes condiciones:

• Se ha configurado un recurso compartido NFS replicado y es accesible desde la red tanto para los nodos del clúster primario como para los del clúster secundario.
• El clúster secundario se implementará utilizando la misma versión del paquete de activos que el clúster de origen.
• Dispone de acceso administrativo al nodo de arranque del clúster primario para realizar copias de seguridad de los secretos y los archivos de configuración.

---

Configurar las exportaciones NFS en el servidor NFS

Dado que los servicios de copia de seguridad se ejecutan como root, la exportación NFS debe incluir la opción no_root_squash. En el servidor NFS, compruebe la configuración de exportación en /etc/exports:

cat /etc/exports

El resultado debe incluir una entrada con el siguiente formato:

<NFS-MOUNT-POINT> <NFS-CLIENT-IP>(rw,sync,no_subtree_check,no_root_squash)

<NFS-CLIENT-IP> es el rango de direcciones IP o el conjunto de direcciones IP que abarca todos los nodos del clúster a los que se permite acceder al montaje. Por ejemplo, si los nodos del clúster de origen utilizan direcciones en el rango 10.48.34.100–10.48.34.105, establezca <NFS-CLIENT-IP> en 10.48.34.0/24 para cubrir la subred completa. Cuando el clúster secundario pasa a ser primario durante una conmutación por error, las direcciones de sus nodos también deben estar comprendidas dentro del rango de direcciones IP permitido.

---

Configurar el archivo profile.yml para las copias de seguridad NFS

El clúster de origen debe configurarse para escribir las copias de seguridad en un montaje NFS compartido antes de que se implementen los servicios. Estas copias de seguridad se utilizan para restaurar el clúster secundario durante una conmutación por error.

1. En el nodo de arranque del clúster de origen, abra /root/<cluster_name>/profile.yml.

2. Busque las siguientes líneas, rellénelas con los datos de su servidor NFS y elimine los comentarios:

   nfs_host: <NFS-HOST-IP>
   nfs_path: <NFS-MOUNT-POINT>
   nfs_version: 4
   

3. Guarde el archivo y, a continuación, continúe con la implementación del servicio tal y como se describe en las fases 4 y 5 de esta guía.

   Nota: Si no se incluyeron los datos de NFS en el archivo profile.yml antes de la implementación inicial del servicio, agregue los datos posteriormente y vuelva a implementar los servicios que dependen de la copia de seguridad:

     > ```bash
     > wso services deploy -s postgres
     > wso services deploy -s control-plane-backup
     > wso services deploy -s opensearch
     > ```
   

4. Para confirmar que se puede acceder al montaje NFS desde otra máquina del clúster secundario, ejecute los siguientes comandos desde una máquina virtual independiente:

   # Mount the NFS share manually to test connectivity
   mount -t nfs <NFS-IP>:<NFS-MOUNT-POINT> /mnt
   
   # List the NFS exports visible to the client
   showmount -e <NFS-IP>
   

   El resultado de showmount -e debería incluir una entrada para el punto de montaje configurado:

   <NFS-MOUNT-POINT> <NFS-IP>
   

---

Hacer una copia de seguridad de los datos del nodo de arranque

Los siguientes elementos del nodo de arranque primario deben estar disponibles en el nodo de arranque secundario antes de que se pueda proceder a la restauración. Realice una copia de seguridad de estos elementos en una ubicación segura antes de que se produzca un incidente de recuperación ante desastres.

Omnissa recomienda almacenar estos datos en el mismo servidor NFS que se utiliza para las copias de seguridad de los servicios, pero en un montaje NFS independiente, para evitar cualquier interferencia con las operaciones de copia de seguridad automatizadas.

---

Configurar la frecuencia y la retención de las copias de seguridad

Para controlar la frecuencia con la que se realizan las copias de seguridad y el tiempo que se conservan, debe configurar las variables de entorno en el archivo additional_env_vars.env del nodo de arranque. Estos ajustes determinan el objetivo de punto de recuperación (RPO), es decir, la cantidad máxima de datos que se podrían perder en caso de fallo.

---

Tipos de copia de seguridad de base de datos

Omnissa Access utiliza dos tipos de copias de seguridad complementarios para la base de datos PostgreSQL.

Copia de seguridad completa

Una copia de seguridad completa captura una instantánea completa de todo el directorio de datos de PostgreSQL en un momento concreto. Las copias de seguridad completas son autónomas y pueden restaurarse sin necesidad de archivos de copia de seguridad adicionales. Por defecto, se realiza una copia de seguridad completa de la base de datos una vez al día a las 5:00 UTC que sirve como punto de referencia para las copias de seguridad delta.

Copia de seguridad delta

Una copia de seguridad delta captura únicamente las páginas de datos que cambiaron desde la última copia de seguridad completa. Las copias de seguridad delta son más pequeñas y se completan más rápido que las completas, pero no son autónomas: para restaurar a partir de una copia de seguridad delta se necesitan tanto la copia de seguridad completa más reciente como la copia de seguridad delta. Por defecto, se ejecuta una copia de seguridad delta una vez al día a las 17:00 UTC.

En conjunto, las tareas de copia de seguridad completa y delta proporcionan una cobertura diaria completa. En caso de que se produzca un fallo entre dos copias de seguridad programadas, la restauración utilizará la copia de seguridad completa más reciente con el último delta aplicado, lo que limita la posible pérdida de datos a un máximo de aproximadamente 12 horas.

Profundidad de la cadena de copias de seguridad delta

El número máximo de capas de copias de seguridad delta que se pueden encadenar a partir de una única copia de seguridad completa está fijado en 2. Este límite viene impuesto internamente por WALG_DELTA_MAX_STEPS y no se puede configurar.

Full Backup (base)
└── Delta 1 (changes since Full Backup)
    └── Delta 2 (changes since Delta 1)  ← maximum chain depth

Cuando la cadena alcanza el máximo configurado, WAL-G convierte automáticamente la siguiente copia de seguridad delta programada en una nueva copia de seguridad completa.

Puede ajustar la programación de las copias de seguridad completas y delta, pero debe asegurarse de que no se ejecuten más de dos copias de seguridad delta entre copias de seguridad completas sucesivas. No se puede superar este límite.

---

Requisitos de FQDN y de red

Para permitir una conmutación por error sin necesidad de realizar cambios en la configuración del usuario final o del conector, el clúster secundario debe cumplir los siguientes requisitos antes de que se produzca un evento de recuperación ante desastres:

• Los certificados TLS de los endpoints del clúster secundario deben ser válidos para el mismo nombre de dominio completo (FQDN) que el del clúster primario. Los procesos de rotación de certificados deben abarcar tanto el sitio principal como el secundario de forma coherente.
• Las reglas del firewall deben permitir el tráfico saliente hacia los endpoints tanto del clúster primario como del secundario. Los rangos de direcciones IP publicadas deben mantenerse de forma activa para ambos sitios.
• El estado de la sesión del conector debe poder reconstruirse por completo en la puerta de enlace secundaria, sin dependencia estricta del almacenamiento de sesiones que solo exista en el clúster primario.

---

Restaurar Omnissa Access desde una copia de seguridad

Este procedimiento describe cómo activar el clúster secundario como nuevo clúster primario durante una conmutación por error. Una vez completada la restauración, el clúster secundario gestiona todo el tráfico de lectura y escritura. El clúster primario original, una vez que vuelve a estar disponible, se considera el nuevo clúster secundario hasta que se realice una conmutación por recuperación planificada.

Importante: Antes de iniciar este procedimiento, asegúrese de que no se pueda acceder al clúster primario original desde el clúster secundario. Si el clúster original sigue siendo accesible durante la restauración, OpenSearch y PostgreSQL podrían intentar agregar nodos del clúster original al clúster restaurado.

Nota: Omnissa recomienda realizar simulacros de restauración programados en un entorno que no sea de producción antes de implementar la recuperación ante desastres en producción. De este modo, se establecen estimaciones realistas del objetivo de tiempo de recuperación (RTO) basadas en sus volúmenes de datos reales.

Requisitos

Antes de iniciar el procedimiento de restauración, compruebe lo siguiente:

• El clúster secundario se implementará utilizando la misma versión del paquete de activos que el clúster de origen para garantizar que todas las imágenes del servicio Omnissa Access coincidan.
• Los datos del nodo de arranque que se indican en Hacer una copia de seguridad de los datos del nodo de arranque deben estar disponibles en el nodo de arranque secundario.

Procedimiento

Paso 1: Implementar el clúster secundario

Aprovisione nuevas máquinas virtuales e implemente en ellas el paquete de activos del plano de control utilizando la misma versión del paquete de activos que el clúster de origen. El clúster secundario debe tener la misma configuración que el clúster de origen.

Importante: En este paso, implemente únicamente los servicios de la plataforma CP: Vault, Consul y Nomad. No implemente los servicios de Omnissa Access en esta fase. Los servicios de Access se restaurarán más adelante en el procedimiento.

Antes de continuar, haga una copia de seguridad del directorio /root/<cluster_name>/cp-cluster/secrets/cp-cluster en el nodo de arranque secundario.

Tiempo estimado: 30 minutos

---

Paso 2: Tomar instantáneas de los nodos del clúster secundario

Una vez que el plano de control se haya implementado correctamente, tome instantáneas de las máquinas virtuales de todos los nodos del clúster secundario. Estas instantáneas proporcionarán un punto de restauración válido en caso de que sea necesario reiniciar el procedimiento de recuperación ante desastres.

Nota: Si se revierte a estas instantáneas en cualquier momento durante el procedimiento de restauración, compruebe que Vault esté desbloqueado en el clúster secundario antes de continuar. Inicie sesión en la interfaz de usuario de Vault con las credenciales adecuadas para confirmar que el estado de Vault está desbloqueado.

---

Paso 3: Copiar secretos en el clúster secundario

Copie las carpetas tls y vault de la ubicación de la copia de seguridad en el directorio backup_secrets del clúster secundario:

• Copiar carpeta tls de copia de seguridad → /root/<cluster_name>/cp-cluster/backup_secrets/tls
• Copiar carpeta vault de copia de seguridad → /root/<cluster_name>/cp-cluster/backup_secrets/vault

Después de copiar, compruebe que el directorio backup_secrets del nodo de arranque secundario contenga ambas carpetas:

ls -lrt backup_secrets/
total 0
drwxr-x---. 2 root root 64 May  7 07:46 tls
drwxr-x---. 4 root root 30 May  7 07:46 vault

---

Paso 4: Planificar la restauración de copia de seguridad

En el directorio del clúster secundario, ejecute el siguiente comando para revisar la copia de seguridad y confirmar el punto de restauración:

wso cp plan-restore-backup

Para restaurar desde un momento específico, utilice la marca -a con una duración de tiempo. Por ejemplo:

Esta marca establece el RPO para la operación de restauración.

---

Paso 5: Restaurar componentes del plano de control

Este paso restaura los datos de clave-valor de Consul y los secretos de Vault en el clúster secundario.

1. Asegúrese de que Vault esté desbloqueado en el clúster secundario.

2. Antes de ejecutar el comando de restauración, confirme que las carpetas tls y vault estén presentes en backup_secrets en el nodo de arranque secundario:

   ls -lrt /root/<cluster_name>/cp-cluster/backup_secrets/
   

   El resultado debe mostrar los directorios tls y vault:

   drwxr-x---. 2 root root 64 <date> tls
   drwxr-x---. 4 root root 30 <date> vault
   

3. En el directorio del clúster, ejecute:

   wso cp restore-backup
   

   Este comando restaura los datos de clave-valor de Consul y los secretos de Vault en el clúster secundario. Resultado esperado:

   Imports KV in case of disaster recovery
   Backing up control plane credentials
   Restoring vault
   Restoring control plane credentials
   Resetting vault integration tokens
   Resetting vault integration token in nomad
   Resetting vault PKI integration token
   Updated vault with secrets after restore during Disaster recovery
   Adding PKI root and intermediate CA to truststore
   Deploying vault
   Restarting vault servers
   Unsealing Vault
   Enabling consul and nomad integration with vault
   Deploying consul
   Configuring consul connect CA provider
   Restarting the consul leader
   Restarting nomad scheduler agent
   Cleaning up
   Generating environment file with cluster details and secret tokens
   

   Nota: Si se produce un error durante este paso, revierta todas las máquinas virtuales del clúster secundario a las instantáneas realizadas en el Paso 2, confirme que Vault no está bloqueado en el clúster secundario y reinicie el procedimiento desde el Paso 3.

   Tiempo estimado: 15 minutos

---

Paso 6: Restaurar servicios

Este paso restaura la base de datos y todos los servicios. Durante este paso no se realizan copias de seguridad.

1. Copie el archivo de variables de entorno desde la ubicación de copia de seguridad al nodo de arranque secundario:

   /root/<cluster_name>/additional_env_vars.env
   

2. Copie el perfil del servicio Access en el nodo de arranque secundario:

   /root/<cluster_name>/access/access-profile.yml
   

3. En el archivo access-profile.yml, haga lo siguiente:

   • Actualice los campos ip_ignore_list_for_xff_header y fqdn.ip con las direcciones IP y la configuración del clúster secundario.
   • Agregue la subred de Nomad a la lista ip_ignore_list_for_xff_header.
     • Nota: El valor predeterminado es 172.26.64.0/20. Si decidió implementar el servicio con una subred personalizada, actualice el valor de la subred en el campo ip_ignore_list_for_xff_header correspondiente.

4. Actualice el servidor DNS para dirigir el FQDN al clúster secundario.

5. Compruebe que el clúster primario original esté fuera de línea o inaccesible.

6. Ejecute el siguiente comando para restaurar todos los servicios:

   wso services restore --cps_image <cps-image>
   

   Nota: Si se produce un error en algún trabajo durante este paso, depúrelo y vuelva a ejecutar el mismo comando.

   Para restaurar solo un servicio específico, incluya la marca -s:

   wso services restore -s <service-name> --cps_image <cps-image>
   

   Donde <cps-image> es la etiqueta de la imagen de los servicios del plano de control que se corresponde con la implementación del clúster de origen.

   Nota: Si se produce un error durante este paso, revierta todas las máquinas virtuales del clúster secundario a las instantáneas realizadas en el Paso 2, confirme que Vault no está bloqueado en el clúster secundario y reinicie el procedimiento desde el Paso 3.

   Tiempo estimado: al menos 75 minutos. El tiempo real varía linealmente según el volumen de datos en PostgreSQL y OpenSearch.

---

Paso 7: Completar las operaciones de restauración y reanudación de copia de seguridad

Ejecute el siguiente comando para verificar los datos restaurados y habilitar las operaciones de copia de seguridad en el clúster primario recién ascendido:

wso services restore-complete --cps_image <cps-image>

Tiempo estimado: 10 minutos

---

Objetivo de tiempo de recuperación

El objetivo de tiempo de recuperación (RTO) total depende del volumen de datos en PostgreSQL y OpenSearch. El RTO mínimo previsto es de aproximadamente dos horas, y el tiempo real aumenta proporcionalmente en función del volumen de datos. Omnissa recomienda realizar simulacros de restauración cronometrados para establecer valores de RTO específicos para su implementación antes de recurrir a este procedimiento en una conmutación por error en un entorno de producción.