Rétablir le contrôle du déploiement sur le site principal à partir du site de destination

Lorsque votre site principal est prêt, basculez le contrôle du déploiement du site de destination vers le site principal.

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 reprise après sinistre, envisagez les scénarios suivants.

Une fois que le site principal est restauré et redevient opérationnel, les sites principal et de destination affichent tous les hôtes gérés référencés. Cependant, le site principal affiche ces hôtes gérés dans un état « inconnu ». Cela se produit parce que les hôtes gérés ont été redirigés vers la console de destination pendant le 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 reprise 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 à l’adresse IBM.
3. Si toutes les applications sont hébergées dans l' AppHost, qui se connecte au site principal, vous ne pouvez pas supprimer l'hôte d'application inconnu de la console du site principal. Vous devez migrer toutes les données de configuration et de volume des applications (y compris l'application de synchronisation des données) vers la console du site principal à partir de l' AppHost,, car l'hôte actuel de l'application est transféré 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 reprise après défaillance. 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 certains hôtes gérés apparaissent toujours comme actifs, veuillez ouvrir un ticket d'assistance afin d'identifier la cause profonde et de les supprimer de la console principale du site.
Lorsque le site principal est opérationnel, mais que la connexion entre les hôtes du site principal et l'hôte du site de destination est soudainement interrompue, les hôtes doivent d'abord être désolidarisés, puis à nouveau solidarisés. Pour désappairer l'hôte, consultez la section « Désappairage des hôtes ». Pour associer l'hôte, consultez la section « Association des hôtes gérés ».

Business Rules (mappage du groupe hôte) doit être identique à celui qui était utilisé avant l'activation pour l'hôte de gestion appairé. Après l'activation, il n'est pas recommandé d'ajouter ou de supprimer des hôtes ou de modifier les mappages d'hôtes (modifier la connexion hôte), car cela pourrait avoir un impact sur le processus de reprise après sinistre. Pour plus d'informations, voir Business Rules.

Vous devez vous connecter en tant qu'utilisateur administrateur pour effectuer une nouvelle sauvegarde sur la console du site de destination. Une fois la sauvegarde générée, le système transfère la sauvegarde générée vers le site principal. 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.

Le Failback est l'opération de restauration vers le site principal lorsque vous n'avez plus besoin du site de destination pour remplacer le fonctionnement du site principal. Lorsque vous revenez au site principal, le processus de copie Ariel copie les données Ariel qui ont été collectées. Les données proviennent de la période comprise entre l'activation du site de destination et la fin de l'heure au cours de laquelle le processus de reprise après sinistre a été lancé.

La durée du processus de reprise après sinistre 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 à laquelle la reprise après sinistre commence est arrondie à l'heure inférieure 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 après défaillance, la synchronisation Ariel est terminée et une notification indique 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 à partir de la dernière sauvegarde effectuée après l'activation sur le site de destination et transférée vers le site principal.

N'oubliez pas :

Si HA est configuré sur la console du site principal ou sur l'hôte géré jumelé au site principal, la reprise après sinistre ne se produira pas. HA doit être supprimé avant de lancer le processus de reprise après sinistre à partir du site principal.

La restauration des applications doit être effectuée manuellement dans la configuration hybride. Les applications installées sur la console ne sont prises en charge que pendant les opérations de basculement et de reprise

Les sauvegardes des applications sont transférées automatiquement selon un calendrier quotidien. Il est toutefois conseillé d'effectuer une sauvegarde du dernier volume.

Pour effectuer une sauvegarde du volume d'une 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 de l'application depuis 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 rencontre des 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 l' 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 de l'application depuis 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 rencontre des 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 (applications 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érez les données de sauvegarde du volume de l'application depuis 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.
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 rencontre des 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

Lancez l'opération de reprise après sinistre à 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 » dans 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 Effectuer la reprise après défaillance, puis confirmez.
4. Redirigez toutes les sources de données qui étaient dirigées vers le site de destination vers le site principal.
5. Une fois le processus de restauration terminé sur le site principal, accédez à l'onglet Admin et exécutez Déployer la configuration complète. Lors du premier déploiement, un délai d'expiration peut se produire sur l'hôte géré jumelé. Ce comportement est normal.
6. Une fois la première tentative de déploiement terminée ou expirée, relancez le déploiement de la configuration complète.
7. Sur le site principal QRadar Console, exécutez le script /opt/ibm/si/dr/bin/dr_clear_seal_files.sh à l'heure où la reprise après sinistre a été effectuée afin de permettre la 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 désormais actif.

Etape suivante

Après le basculement, si un hôte géré apparié se trouve dans un état inconnu, accédez à Admin > Gestion du système et des licences > > Sélectionnez l'hôte géré > Cliquez sur Actions > Redémarrer le système...
Une fois la réactivation terminée, si la connexion d'appairage entre les hôtes des deux sites est supprimée, les hôtes doivent d'abord être désappariés, puis appariés à nouveau. Pour désappairer l'hôte, consultez la section « Désappairage des hôtes ». Pour associer l'hôte, consultez la section « Association des hôtes gérés ».
Pour restaurer les applications du site de destination sur la console principale, procédez comme suit
1. Si un utilisateur du site principal doit accéder à une application qui était disponible sur le site de destination mais qui n'est pas accessible depuis le site principal, celle-ci doit être réinstallée à l'aide de la console principale -> IBM QRadar Hub (anciennement IBM QRadar Assistant) -> Applications -> section Extensions installées.
  Pour une restauration réussie, les versions de l'application doivent être identiques sur le site principal et 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 principale du site. Pour restaurer les sauvegardes du volume des applications transférées, copiez les données de sauvegarde du volume des applications de /store/app_sync/backups vers /store/apps/backup.
  - Ne restaurez que les applications nécessaires et celles de petite taille. Pour restaurer davantage d'applications sur le site de destination ou pour conserver les applications sur le site de reprise après sinistre plus longtemps, vous pouvez d'abord migrer les applications depuis la console du site de destination vers AppHost avant de passer à 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 UUID et à ne pas restaurer le volume de l'application Data Synchronization sur la console du site de destination.
  - L'application de synchronisation des données est nécessaire pour maintenir son propre état et exécuter une opération de reprise après sinistre afin d'activer le site principal.
3. Si des applications se trouvent dans un état d'erreur après la restauration ou après l'opération de basculement ou de reprise, redémarrez les applications à l'aide de qappmanager l'utilitaire (/opt/qradar/support/qappmanager).
Dans une configuration « Console uniquement », lors d'un basculement et d'un retour en mode normal, seules les informations relatives à la clé de licence sont gérées par restored.The. L'hôte géré conserve les paramètres correspondants nonConsoleEventLimit ou flowLimit définis dans la clé de licence. Vous devez reconfigurer manuellement les attributions du pool de licences à l'aide de Console Admin -> Gestion du système et des licences -> Modifier l'affichage déroulant : Licences -> Gestion du pool de licences.