QRadar DR sur console uniquement à l'aide de l'application de synchronisation des données

Dans un déploiement distribué à grande échelle, les collecteurs, le processeur et les consoles sont répartis géographiquement. Si l'un des centres de données n'est pas fonctionnel, les autres centres de données qui fonctionnent normalement peuvent être utilisés. Dans un tel scénario, l’opération de basculement n’est pas nécessaire pour l’ensemble de l’environnement. Toutefois, si vous souhaitez effectuer l'opération de basculement uniquement pour la console, vous pouvez utiliser l'optionQRadar Fonctionnalité DR uniquement sur console. Cette fonctionnalité restaure l'hôte géré sur le site de destination.

L’implémentation de DR sur console uniquement est utile pour les clients dans les scénarios suivants.
  • Une véritable reprise après sinistre où la console n'est pas disponible mais les autres hôtes de déploiement sont toujours en cours d'exécution.
  • Un exercice de reprise après sinistre dans lequel le site principal est toujours disponible pendant le processus de reprise après sinistre.

Prérequis

Les conditions suivantes doivent être remplies avant de commencer la procédure DR en mode console seule :
  1. Assurez-vous que les deux consoles IBM® QRadar (console principale et console de destination) sont installées avec la même version de logiciel, c'est-à-dire UP11 ou une version ultérieure. La version de Data Synchronization App doit être 3.2.1 ou ultérieure.
  2. Le site de destination doit disposer uniquement d'une console.
  3. Vous devez disposer d'un accès réseau entre l'hôte géré, le site principal et le site DR avant l'opération de basculement ou de restauration. Si un hôte géré n'est pas accessible aux sites DR, il est affiché comme hôte inconnu.
  4. Assurez-vous que vous vous êtes connecté en utilisant le nom d'utilisateur "admin" pour effectuer les opérations de basculement et de retour à la normale.
  5. Assurez-vous que les sauvegardes sont générées et transférées sur les deux sites avant et après les opérations de basculement et de restauration.
  6. Seul l'utilisateur root peut exécuter les activités SSH pour les opérations de basculement et de rétablissement.
  7. Si vous souhaitez restaurer les données du volume d'applications sur le site de destination, vous devez générer une sauvegarde du volume d'applications avant l'opération de basculement.
    1. Assurez-vous que la minuterie et les tâches de sauvegarde du volume de l'application sont activées (systemctl status app_sync.timer et systemctl status app_sync.service) pour que le transfert automatique fonctionne comme il se doit. Cette fonction n'est disponible que pour la console du site principal.
    2. Lorsque des applications sont installées sur la console, la sauvegarde de votre volume d'applications est automatiquement transférée vers le site de destination.
    3. Lorsque les applications sont installées sur le site AppHost,, déplacez toutes les applications installées vers la console du site principal avant d'exécuter les opérations de basculement et de rétablissement.
    4. La procédure suivante est un exemple de génération d'une sauvegarde de volume d'application.
      1. Voir Sauvegarde et restauration des données d' une application pour sauvegarder les données d'un volume d'application.
      2. Transférez la 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
      3. 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).
  8. Si une configuration HA existe dans l'environnement, supprimez la configuration HA du site principal et du site DR avant les opérations de basculement et de reprise. Vous pouvez ajouter HA après avoir terminé les opérations de basculement et de retour à la normale.
  9. Avant d'effectuer une opération de restauration automatique, assurez-vous qu'aucun hôte géré ne se trouve sur le site principal. Si des hôtes gérés se trouvent sur le site principal, vous devez les supprimer du site principal, effectuer une nouvelle sauvegarde, puis effectuer l'opération de restauration automatique.
Important : au cours du cycle de basculement et de retour en mode normal, la licence de la console du site principal (site DC) n'est pas transférée vers le déploiement du site de destination. Le site de destination continue de fonctionner en utilisant sa propre licence de console, qui doit être conservée tout au long du cycle de reprise après sinistre. Par conséquent, les clients doivent s'assurer que le site de destination dispose d'une licence lui conférant une capacité de reprise après sinistre suffisante pour prendre en charge la charge de travail de production prévue pendant les opérations de reprise après sinistre.

Procédure

Pour activer la fonctionnalité DR de console uniquement, configurez la console pour le site de destination distant. Pour les déploiements avec des hôtes gérés où la résilience DR de la console est nécessaire, basculez le déploiement du site principal vers un site de destination. Vous pouvez utiliser l'application de synchronisation des données pour résoudre les problèmes de déploiement sur plusieurs sites. Le site d'origine sert de site principal pour ces opérations, tandis que le site de reprise après sinistre sert de site de destination. Vous pouvez rétablir le contrôle de déploiement sur le site principal à partir du site de destination et réactiver le site principal.

Pour implémenter la fonctionnalité DR de console uniquement, utilisez la procédure suivante.