Renvoi du contrôle du déploiement au site principal depuis le site de destination

Lorsque votre site principal est prêt, remettez le contrôle du déploiement sur le site principal à partir du site de destination.

Avant de commencer

Avant de lancer l'opération de basculement de secours, ouvrez le tableau de bord de reprise après sinistre et vérifiez l'état de préparation du système en passant en revue tous les contrôles d'intégrité requis. Résolvez tous les contrôles ayant échoué avant de poursuivre l'opération de basculement de secours.

ATTENTION :

Avant de procéder à l'opération de basculement, envisagez les scénarios suivants.

Une fois le site principal récupéré et opérationnel, le site principal et le site de destination affichent tous les hôtes gérés référencés. Cependant, le site principal indique que ces hôtes gérés sont dans un état "inconnu". Cela est dû au fait que les hôtes gérés ont été réaffectés à la console de destination au cours du processus d'activation. Effectuez les tâches suivantes pour résoudre ce problème.
1. Supprimez les hôtes gérés qui sont dans l'état Inconnu du site principal avant d'exécuter l'opération de basculement sur le site principal.
2. Si le site principal MH est configuré avec HA et que le site principal est hors service au moment de l'activation, il est nécessaire d'effectuer des étapes supplémentaires après la mise sous tension du site principal pour supprimer HA qui est dans l'état Inconnu. Si vous ne parvenez toujours pas à supprimer des hôtes HA de la console en suivant les étapes décrites dans la section « Dépannage des déploiements HA d’ QRadar », contactez le support technique d’ IBM.
3. Si toutes les applications sont hébergées sur le site AppHost qui se connecte au site principal, vous ne pouvez pas supprimer l'hôte inconnu de la console du site principal. Vous devez transférer toutes les données de configuration et de volume des applications (y compris celles de l'application de synchronisation des données) depuis le site « AppHost, » vers la console du site principal, car l'hôte actuel de ces applications est en cours de migration vers le site de destination. L'application de synchronisation des données doit fonctionner normalement sur le site principal avant que vous n'exécutiez l'opération de basculement. Consultez la page QRadar : « Comment forcer les applications à s'exécuter sur la console lorsque l'hôte d'applications est irrécupérable » pour forcer les applications à s'exécuter sur la console du site principal avec l'état « Inconnu »; vous pourrez ensuite supprimer « AppHost » de la console du site principal.
4. Si des hôtes gérés sont toujours affichés comme actifs, veuillez ouvrir un ticket d'assistance pour identifier la cause principale et pour supprimer ces hôtes de la console du site principal.
Lorsque le site principal est opérationnel, mais que la connexion de couplage entre le site principal et le site de destination se déconnecte soudainement. Effectuez les tâches suivantes pour rétablir la connexion d'appairage.
1. Depuis la console QRadar sur le site principal, exécutez la commande suivante :
```
/opt/ibm/si/dr/bin/dr_create_ssh.sh -i <destination_site_ip>
```
2. Depuis la console QRadar sur le site de destination, exécutez la commande suivante :
```
/opt/ibm/si/dr/bin/dr_create_ssh.sh -i <main_site_ip>
```

Vous devez vous connecter en tant qu'utilisateur administrateur pour effectuer de nouvelles sauvegardes sur la console du site principal et sur la console du site de destination. Une fois la sauvegarde générée, le système la transfère vers un autre site. Ouvrez l'écran Sauvegarde et restauration pour vérifier si la sauvegarde transférée est visible. Si la sauvegarde transférée n'est pas visible, actualisez l'écran Sauvegarde et restauration.

Failback est l'opération de restauration du site principal lorsque vous n'avez plus besoin du site de destination pour remplacer le fonctionnement du site principal. Lorsque vous revenez sur le site principal, le processus de copie Ariel copie les données Ariel qui ont été collectées. Les données sont disponibles à partir du moment où le site de destination a été activé jusqu'à la fin de l'heure à laquelle le processus de retour à la normale a été lancé.

La durée du processus de restauration automatique peut varier en fonction des conditions suivantes :

Durée de l'activité du site de destination.
Quantité de données collectées sur le site de destination pendant qu'elle était active.
Bande passante disponible entre le site de destination et le site principal.

Ariel Copy n'accepte que le temps à l'heure la plus proche. L'heure de début du basculement est arrondie à l'heure la plus proche. 9:15 AM est enregistré comme 9:00 AM dans les profils Ariel Copy. Ariel Copy synchronise toutes les heures de données ; par exemple, de 9:00 à 9:59 AM.

Dans ce processus de reprise, la synchronisation Ariel est terminée et reçoit une notification indiquant que la copie Ariel est terminée sur le site de destination. Une fois la synchronisation Ariel terminée, la restauration démarre automatiquement sur le site principal avec la dernière sauvegarde effectuée après l'activation sur le site de destination et transférée sur le site principal. Une fois la restauration du site principal terminée, la restauration commence sur le site de destination.

Astuce :

Si le site principal n'était pas disponible lors de l'activation (scénario d'activation 1), la dernière sauvegarde du site de destination initiée par l'administrateur avant l'activation est restaurée sur le site de destination lors du processus de failback.

Pour la restauration des applications, la dernière sauvegarde du volume d'applications du site de destination que l'administrateur a initiée avant l'activation est restaurée sur le site de destination pendant le processus de reprise sur panne.

Si le site principal était disponible lors de l'activation (scénario d'activation 2), la dernière sauvegarde du site principal qui a été transférée sur le site de destination est restaurée sur le site de destination pendant le processus de reprise sur panne.

Pour la restauration des applications, la dernière sauvegarde du volume d'applications du site principal qui a été transférée vers le site de destination est restaurée sur le site de destination pendant le processus de basculement.

Rappelez-vous :

Les applications installées sur la console ne sont prises en charge que pendant les opérations de basculement et de reprise. Si les applications sont installées sur AppHost,, elles ne sont pas restaurées ou migrées pendant les opérations de basculement et de reprise.

La sauvegarde du volume des applications est transférée automatiquement selon un calendrier quotidien. Toutefois, il est conseillé d'effectuer la dernière sauvegarde du volume.

Pour effectuer une sauvegarde du volume de l'application à partir de la console du site de destination :
- Applications fonctionnant sur la console
  1. Reportez-vous à la section « Sauvegarde et restauration des données d'application » pour sauvegarder les données d'un volume d'application à partir de la console du site de destination.
  2. Transférez la sauvegarde du volume d'applications de la console du site de destination vers la console du site principal en exécutant la commande suivante sur la console du site de destination.
```
systemctl start app_sync
```
  3. Vérifiez le transfert dans le répertoire de la console du site principal (/store/app_sync/backups). Si le transfert échoue ou s'accompagne de problèmes, copiez la sauvegarde du volume de l'application depuis le répertoire de la console du site de destination (/store/apps/backup) vers le répertoire de la console du site principal (/store/app_sync/backups).
- Applications fonctionnant sur AppHost
  1. Déplacer toutes les applications installées vers la console du site de destination
  2. Reportez-vous à la section « Sauvegarde et restauration des données d'application » pour sauvegarder les données d'un volume d'application à partir de la console du site de destination.
  3. Transférez la sauvegarde du volume d'applications de la console du site de destination vers la console du site principal en exécutant la commande suivante sur la console du site de destination.
```
systemctl start app_sync
```
  4. Vérifiez le transfert dans le répertoire de la console du site principal (/store/app_sync/backups). Si le transfert échoue ou s'accompagne de problèmes, copiez la sauvegarde du volume de l'application depuis le répertoire de la console du site de destination (/store/apps/backup) vers le répertoire de la console du site principal (/store/app_sync/backups).
Pour effectuer une sauvegarde du volume d'une application à partir de la console du site principal (Apps qui s'exécutent sur la console) :
1. Consultez la section « Sauvegarde et restauration des données d'application » pour sauvegarder les données du volume d'application depuis la console principale du site.
2. Transférer les données de sauvegarde du volume d'applications de la console du site principal (/store/app_sync/backups) vers le répertoire de la console du site de destination (/store/app_sync/backups). Cette étape n'est requise que pour le site principal qui était disponible lors du scénario d'activation 2.
3. Transférez les données de sauvegarde du volume de l'application depuis la console du site principal vers la console du site de destination en exécutant la commande suivante sur la console du site principal.
```
systemctl start app_sync
```
4. Vérifiez le transfert dans le répertoire de la console du site de destination (/store/app_sync/backups). Si le transfert échoue ou s'accompagne de problèmes, copiez la sauvegarde du volume de l'application depuis le répertoire de la console du site principal (/store/apps/backup) vers le répertoire de la console du site de destination (/store/app_sync/backups).

Procédure

Lancer l'opération de basculement à partir du site de destination.
1. Dans la console d' QRadar, sur le site de destination, cliquez sur Admin > Application de synchronisation des données.
2. Vous pouvez lancer l'opération de basculement vers le site de secours de deux manières :
  - Vous pouvez sélectionner « Reprise sur le site principal » depuis le tableau de bord pour lancer l'opération de reprise.
  - Vous pouvez ouvrir le menu coulissant de gauche et sélectionner « Reprise sur le site principal » pour lancer l'opération de reprise. Cette option peut être utilisée si les utilisateurs doivent poursuivre l'opération de « failback » malgré l'échec des vérifications. Cependant, vous devez d'abord vérifier et corriger les contrôles qui ont échoué.
3. Cliquez sur Exécuter la reprise sur défaillance, puis confirmez.
4. Renvoyer vers le site principal toutes les sources de données qui ont été dirigées vers le site de destination.
5. Lorsque les processus de restauration sont terminés sur les consoles du site principal et du site de destination :
  1. Effectuer le déploiement complet sur le site principal.
  2. Effectuer le déploiement complet sur le site de destination.
  Note : La séquence de déploiement complète doit être maintenue pour s'assurer que les hôtes gérés sont ré-homés correctement sur le site principal.
6. Sur le site principal QRadar Console, exécutez le script /opt/ibm/si/dr/bin/dr_clear_seal_files.sh à l'heure où le failback a été effectué pour permettre une synchronisation correcte des données entre les sites. Pour plus de détails, consultez la section « Resynchronisation des données précédemment copiées sur le site principal ».
Réactiver le site principal.
1. Dans la console d' QRadar, sur le site principal, cliquez sur Admin > Application de synchronisation des données.
2. Ouvrez le menu de l'application et sélectionnez Réactiver le site principal.
3. Cliquez sur Réactiver, puis sur Suivant.
4. Dans l'onglet Admin du site principal et du site de destination, cliquez sur Déployer les modifications. Le site principal est maintenant actif.

Etape suivante

Une fois l'activation terminée, la connexion d'appariement entre les deux sites est supprimée. Pour établir à nouveau la connexion de couplage, vous devez exécuter les commandes de couplage suivantes à partir des deux sites :
1. Dans la console QRadar du site principal, exécutez le script suivant :
```
/opt/ibm/si/dr/bin/dr_create_ssh.sh -i <destination_site_ip>
```
  .
2. Dans la console QRadar sur le site de destination, exécutez le script suivant :
```
/opt/ibm/si/dr/bin/dr_create_ssh.sh -i <main_site_ip>
```
  .
Les applications installées sur AppHost ne sont pas restaurées ou migrées pendant les opérations de basculement et de reprise. Pour restaurer les applications du site de destination sur la console principale, procédez comme suit
1. Si un utilisateur du site principal a besoin d'accéder à une application qui était disponible sur le site de destination mais qui n'est pas accessible depuis le site principal, il doit la réinstaller en utilisant le site Main Console -> IBM QRadar Hub (anciennement IBM QRadar Assistant) -> Applications -> section Extensions installées.
  Pour une restauration réussie, les versions des applications doivent être identiques sur le site principal et sur le site de destination.
2. Sauvegardez les données de volume des applications existantes sur la console du site principal avant de procéder aux opérations de restauration.
  - Assurez-vous que les sauvegardes correctes du volume de l'application sont disponibles sur la console du site principal. Pour restaurer les sauvegardes de volume d'applications transférées, copiez les données de sauvegarde de volume d'applications de /store/app_sync/backups à /store/apps/backup.
  - Ne restaurez que les applications nécessaires et les applications de petite taille. Pour restaurer plus d'applications sur le site de destination ou pour conserver les applications sur le site DR plus longtemps, vous pouvez d'abord migrer les applications de la console du site de destination vers AppHost avant de procéder à la procédure de restauration.
  - Consultez la section « Sauvegarde et restauration des données d'application » pour restaurer les données de volume d'une application. La pratique standard consiste à utiliser l'UUID pour ne pas restaurer le volume de l'application de synchronisation des données sur la console du site de destination.
  - L'application de synchronisation des données est nécessaire pour maintenir son propre état et pour exécuter une opération de secours afin d'activer le site principal.
3. Si des applications se trouvent dans un état d'erreur une fois la restauration terminée ou après l'opération de basculement ou de retour à la normale, redémarrez les applications à l'aide de l'utilitaire qappmanager ( /opt/qradar/support/qappmanager ).
Après un basculement et un retour en mode normal, la clé de licence de l'hôte de la console n'est pas restaurée. Les licences hôte de la console restent inchangées et sont conservées sur leurs sites principaux ou de destination respectifs. Seules les informations relatives à la clé de licence « Managed Host » sont restaurées. Par conséquent, l'hôte géré conserve les valeurs ou flowLimit correspondantes nonConsoleEventLimit définies dans sa clé de licence. Une fois le processus de restauration terminé, les attributions du pool de licences doivent être reconfigurées manuellement via Console Admin -> Gestion du système et des licences -> Modifier l'affichage (menu déroulant) : Licences -> Gestion du pool de licences.