Configurer la récupération d'urgence pour Omnissa Access

Omnissa Access prend en charge la récupération d'urgence à l'aide d'un modèle de sauvegarde et de restauration avec un montage NFS partagé. Dans ce modèle, un cluster secondaire a accès aux données de sauvegarde produites par le cluster principal. Lors d'un événement DR déclaré, le cluster secondaire est promu manuellement en principal et gère le trafic de lecture/d'écriture. Le retour arrière vers le site d'origine est une opération manuelle planifiée ; cela ne se produit pas automatiquement. Lorsque l'instance principale d'origine devient disponible, elle reste dans le rôle secondaire jusqu'à ce que le retour arrière planifié soit exécuté.

Cette rubrique décrit comment configurer le stockage de sauvegarde NFS, gérer les planifications de sauvegarde, sauvegarder les données de nœud de démarrage requises et restaurer Omnissa Access à partir d'une sauvegarde pendant un basculement.

---

Conditions préalables

Avant de configurer la récupération d'urgence, assurez-vous que les conditions suivantes sont remplies :

• Un partage NFS répliqué est configuré et accessible par le réseau aux nœuds de cluster principal et aux nœuds de cluster secondaires.
• Le cluster secondaire sera déployé à l'aide de la même version de bundle de ressources que le cluster source.
• Vous disposez d'un accès administratif au nœud de démarrage du cluster principal pour sauvegarder les secrets et les fichiers de configuration.

---

Configurer les exportations NFS sur le serveur NFS

Étant donné que les services de sauvegarde s'exécutent en tant qu'utilisateur racine, l'exportation NFS doit inclure l'option no_root_squash. Sur le serveur NFS, vérifiez la configuration de l'exportation dans /etc/exports :

cat /etc/exports

La sortie doit inclure une entrée au format suivant :

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

<NFS-CLIENT-IP> est la plage d'adresses IP ou l'ensemble d'adresses IP qui couvre tous les nœuds de cluster autorisés à accéder au montage. Par exemple, si les nœuds du cluster source utilisent des adresses dans la plage 10.48.34.100-10.48.34.105, définissez <NFS-CLIENT-IP> sur 10.48.34.0/24 pour couvrir le sous-réseau complet. Lorsque le cluster secondaire est promu à l'état principal lors d'un basculement, ses adresses de nœud doivent également être comprises dans la plage d'adresses IP autorisée.

---

Configurer le fichier profile.yml pour la sauvegarde NFS

Le cluster source doit être configuré pour écrire des sauvegardes sur un montage NFS partagé avant le déploiement des services. Ces sauvegardes sont utilisées pour restaurer le cluster secondaire lors d'un basculement.

1. Sur le nœud de démarrage du cluster source, ouvrez /root/<cluster_name>/profile.yml.

2. Localisez les lignes suivantes, remplissez-les avec les détails de votre serveur NFS et annulez leur mise en commentaire :

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

3. Enregistrez le fichier, puis poursuivez le déploiement du service comme décrit dans les phases 4 et 5 de ce guide.

   Remarque : si les détails NFS n'étaient pas inclus dans profile.yml avant le déploiement du service initial, ajoutez-les ensuite et redéployez les services dépendants de la sauvegarde :

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

4. Pour confirmer que le montage NFS est accessible à partir d'une autre machine sur le cluster secondaire, exécutez les commandes suivantes à partir d'une machine virtuelle distincte :

   # 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>
   

   La sortie de showmount -e doit inclure une entrée pour le point de montage configuré :

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

---

Sauvegarder les données du nœud de démarrage

Les éléments suivants du nœud de démarrage principal doivent être disponibles sur le nœud de démarrage secondaire avant qu'une restauration puisse avoir lieu. Sauvegardez ces éléments dans un emplacement sécurisé avant qu'un événement DR se produise.

Omnissa recommande de stocker ces données sur le même serveur NFS que celui utilisé pour les sauvegardes de service, mais sur un montage NFS distinct, afin d'éviter toute interférence avec les opérations de sauvegarde automatisées.

---

Configurer la fréquence et la rétention des sauvegardes

Vous pouvez contrôler la fréquence des sauvegardes et leur durée de conservation en définissant des variables d'environnement dans le fichier additional_env_vars.env sur le nœud de démarrage. Ces paramètres déterminent votre objectif de point de récupération (RPO), c'est-à-dire la quantité maximale de données pouvant être perdues en cas de panne.

---

Types de sauvegardes de la base de données

Omnissa Access utilise deux types de sauvegarde complémentaires pour la base de données PostgreSQL.

Sauvegarde complète

Une sauvegarde complète capture un snapshot complet de l'intégralité du répertoire de données PostgreSQL à un instantané spécifique. Les sauvegardes complètes sont autonomes et peuvent être restaurées sans fichiers de sauvegarde supplémentaires. Par défaut, une sauvegarde de base de données complète s'exécute une fois par jour à 5 h 00 UTC et sert de ligne de base pour les sauvegardes delta.

Sauvegarde delta

Une sauvegarde delta capture uniquement les pages de données qui ont été modifiées depuis la sauvegarde complète la plus récente. Les sauvegardes delta sont plus petites et plus rapides à effectuer que les sauvegardes complètes, mais elles ne sont pas autonomes : la restauration à partir d'une sauvegarde delta nécessite la sauvegarde complète la plus récente et la sauvegarde delta. Par défaut, une sauvegarde delta s'exécute une fois par jour à 17 h 00 UTC.

Les tâches de sauvegarde complète et delta fournissent ensemble une couverture quotidienne complète. En cas de panne qui se produit entre les sauvegardes planifiées, la restauration utilise la sauvegarde complète la plus récente avec le dernier delta appliqué au-dessus, limitant ainsi la perte de données potentielle à dans environ 12 heures.

Profondeur de chaîne de sauvegarde delta

Le nombre maximal de couches de sauvegarde delta pouvant être chaînées en haut d'une sauvegarde complète unique est fixé à 2. Cette limite est appliquée en interne par WALG_DELTA_MAX_STEPS et n'est pas configurable.

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

Lorsque la chaîne atteint la valeur maximale configurée, WAL-G promeut automatiquement la sauvegarde delta planifiée suivante en une nouvelle sauvegarde complète.

Vous pouvez ajuster la planification des sauvegardes complètes et delta, mais vous devez vous assurer que deux sauvegardes delta au maximum s'exécutent entre les sauvegardes complètes successives. Le dépassement de cette limite n'est pas pris en charge.

---

Spécifications du nom de domaine et de mise en réseau

Pour prendre en charge un basculement sans devoir apporter de modifications à la configuration de l'utilisateur final ou du connecteur, le cluster secondaire doit réunir les conditions requises suivantes avant qu'un événement DR se produise :

• Les certificats TLS sur les points de terminaison du cluster secondaire doivent être valides pour le même nom de domaine complet (FQDN) que le cluster principal. Les processus de rotation des certificats doivent couvrir les sites principal et secondaire de manière cohérente.
• Les règles de pare-feu doivent autoriser le trafic sortant vers les points de terminaison de cluster principal et secondaire. Les plages d'adresses IP publiées doivent être activement conservées pour les deux sites.
• L'état de la session du connecteur doit pouvoir être recréé sur la passerelle secondaire, sans dépendance matérielle sur le stockage de session qui existe uniquement sur le cluster principal.

---

Restaurer Omnissa Access à partir d'une sauvegarde

Cette procédure décrit comment activer le cluster secondaire en tant que nouveau cluster principal lors d'un basculement. Lorsque la restauration est terminée, le cluster secondaire gère tout le trafic de lecture et d'écriture. Le cluster principal d'origine, une fois qu'il est de nouveau disponible, est traité comme le nouveau cluster secondaire jusqu'à ce qu'un retour arrière planifié soit effectué.

Important : avant de commencer cette procédure, assurez-vous que le cluster principal d'origine n'est pas accessible à partir du cluster secondaire. Si le cluster d'origine est toujours accessible pendant la restauration, OpenSearch et PostgreSQL peuvent tenter d'ajouter des nœuds du cluster d'origine au cluster restauré.

Remarque : Omnissa recommande d'effectuer des exercices de restauration planifiés dans un environnement hors production avant de déployer la récupération d'urgence en production. Cela établit des estimations d'objectif de temps de récupération (RTO) réalistes basées sur vos volumes de données réels.

Conditions préalables

Avant de commencer la procédure de restauration, confirmez les point suivants :

• Le cluster secondaire sera déployé à l'aide de la même version de bundle de ressources que le cluster source, afin d'assurer la correspondance entre toutes les images du service Omnissa Access.
• Les données du nœud de démarrage répertoriées dans Sauvegarder les données du nœud de démarrage sont accessibles sur le nœud de démarrage secondaire.

Procédure

Étape 1 : Déployer le cluster secondaire

Provisionnez des nouvelles machines virtuelles et déployez le bundle de ressources du plan de contrôle sur celles-ci, en utilisant la même version de bundle de ressources que le cluster source. Le cluster secondaire doit avoir la même configuration que le cluster source.

Important : dans cette étape, déployez uniquement les services de plate-forme CP : Vault, Consul et Nomad. Ne déployez pas les services Omnissa Access à cette étape. Les services Access sont restaurés ultérieurement dans la procédure.

Avant de continuer, sauvegardez le répertoire /root/<cluster_name>/cp-cluster/secrets/cp-cluster sur le nœud de démarrage secondaire.

Durée estimée : 30 minutes

---

Étape 2 : Prendre un snapshot des nœuds de cluster secondaires

Une fois le plan de contrôle correctement déployé, prenez des snapshots de machine virtuelle de tous les nœuds de cluster secondaires. Ces snapshots fournissent un point de restauration correct connu si la procédure de récupération d'urgence doit être redémarrée.

Remarque : si vous restaurez ces snapshots à un moment donné pendant la procédure de restauration, vérifiez que Vault est descellé sur le cluster secondaire avant de continuer. Connectez-vous à l'UI de Vault à l'aide des informations d'identification appropriées pour confirmer que l'état du Vault n'est pas scellé.

---

Étape 3 : Copier les secrets sur le cluster secondaire

Copiez les dossiers tls et vault de votre emplacement de sauvegarde dans le répertoire du backup_secrets cluster secondaire :

• Copier le dossier sauvegardé tls → /root/<cluster_name>/cp-cluster/backup_secrets/tls
• Copier le dossier sauvegardé vault → /root/<cluster_name>/cp-cluster/backup_secrets/vault

Après la copie, vérifiez que le répertoire backup_secrets sur le nœud de démarrage secondaire contient les deux dossiers :

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

---

Étape 4 : Planifier la restauration de sauvegarde

Dans le répertoire du cluster secondaire, exécutez la commande suivante pour vérifier la sauvegarde et confirmer le point de restauration :

wso cp plan-restore-backup

Pour effectuer une restauration à partir d'un moment donné, utilisez l'indicateur -a avec une durée. Par exemple :

Cet indicateur définit l'objectif de point de récupération pour l'opération de restauration.

---

Étape 5 : Restaurer les composants du plan de contrôle

Cette étape restaure les données clé-valeur Consul et les secrets Vault sur le cluster secondaire.

1. Assurez-vous que Vault n'est pas scellé sur le cluster secondaire.

2. Avant d'exécuter la commande de restauration, vérifiez que les dossiers tls et vault sont présents dans backup_secrets sur le nœud de démarrage secondaire :

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

   La sortie doit afficher les répertoires tls et vault :

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

3. Dans le répertoire du cluster, exécutez :

   wso cp restore-backup
   

   La commande restaure les données clé-valeur Consul et les secrets Vault sur le cluster secondaire. Sortie attendue :

   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
   

   Remarque : si une erreur se produit pendant cette étape, restaurez toutes les machines virtuelles du cluster secondaire vers les snapshots pris à l'étape 2, confirmez que Vault n'est pas scellé sur le cluster secondaire et redémarrez la procédure à partir de l'étape 3.

   Durée estimée : 15 minutes

---

Étape 6 : Restaurer les services

Cette étape restaure la base de données et tous les services. Aucune sauvegarde n'est effectuée pendant cette étape.

1. Copiez le fichier de variables d'environnement de l'emplacement de sauvegarde vers le nœud de démarrage secondaire :

   /root/<cluster_name>/additional_env_vars.env
   

2. Copiez le profil du service Access sur le nœud de démarrage secondaire :

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

3. Dans le fichier access-profile.yml, procédez comme suit :

   • Mettez à jour les champs ip_ignore_list_for_xff_header et fqdn.ip pour refléter les adresses IP et la configuration du cluster secondaire.
   • Ajoutez le sous-réseau Nomad à la liste ip_ignore_list_for_xff_header.
     • Remarque : la valeur par défaut est 172.26.64.0/20. Si vous choisissez d'effectuer le déploiement avec un sous-réseau personnalisé, mettez à jour la valeur du sous-réseau dans le champ ip_ignore_list_for_xff_header en conséquence.

4. Mettez à jour le serveur DNS pour diriger le nom de domaine complet vers le cluster secondaire.

5. Confirmez que le cluster principal d'origine est hors ligne ou inaccessible.

6. Exécutez la commande suivante pour restaurer tous les services :

   wso services restore --cps_image <cps-image>
   

   Remarque : si une tâche échoue pendant cette étape, purgez-la et réitérez la même commande.

   Pour restaurer uniquement un service spécifique, incluez l'indicateur -s :

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

   Où <cps-image> est la balise d'image des services du plan de contrôle qui correspond au déploiement du cluster source.

   Remarque : si une erreur se produit pendant cette étape, restaurez toutes les machines virtuelles du cluster secondaire vers les snapshots pris à l'étape 2, confirmez que Vault n'est pas scellé sur le cluster secondaire et redémarrez la procédure à partir de l'étape 3.

   Durée estimée : 75 minutes. Le temps réel évolue de manière linéaire avec le volume de données dans PostgreSQL et OpenSearch.

---

Étape 7 : Terminer les opérations de restauration et de reprise de la sauvegarde

Exécutez la commande suivante pour vérifier les données restaurées et activer les opérations de sauvegarde sur le cluster principal récemment promu :

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

Durée estimée : 10 minutes

---

Objectif de temps de récupération

L'objectif de temps de récupération total (RTO) dépend du volume de données dans PostgreSQL et OpenSearch. Le RTO minimal attendu est d'environ deux heures, le temps réel augmentant proportionnellement au volume de données. Omnissa recommande d'exécuter des exercices de restauration planifiés pour établir des valeurs de RTO spécifiques à votre déploiement avant de s'appuyer sur cette procédure lors d'un basculement de production.