Mudança do controle de implantação de volta para o site principal a partir do site de destino

Quando o site principal estiver pronto, alterne o controle de implantação de volta para o site principal a partir do site de destino.

Antes de iniciar

Antes de iniciar a operação de failback, abra o painel de recuperação de desastres e verifique o status de prontidão do sistema, analisando todas as verificações de integridade necessárias. Resolva todas as verificações com falha antes de prosseguir com a operação de failback.

CUIDADO:

Considere os seguintes cenários antes de prosseguir com a operação de failback.

Depois que o site principal é recuperado e se torna operacional, os sites principal e de destino exibem todos os hosts gerenciados referenciados. No entanto, o site principal mostra esses hosts gerenciados em um estado "desconhecido". Isso ocorre porque os hosts gerenciados foram redirecionados para o console de destino durante o processo de ativação. Conclua as seguintes tarefas para resolver esse problema.
1. Remova os hosts gerenciados que estão no estado Desconhecido do site principal antes de executar a operação de failback no site principal.
2. Se o MH do site principal estiver configurado com HA e o site principal estiver inativo no momento da ativação, será necessário executar etapas adicionais após ligar o site principal para remover o HA que está no estado Desconhecido. Se você ainda não conseguir remover os hosts de alta disponibilidade (HA) do console seguindo os passos descritos em Solução de problemas de implementações QRadar HA, entre em contato com o Suporte IBM.
3. Se todos os aplicativos estiverem hospedados no AppHost que se conecta ao site principal, não será possível remover o host de aplicativo desconhecido do console do site principal. É necessário migrar todos os dados de configuração e volume dos aplicativos (incluindo o aplicativo de sincronização de dados) para o console do site principal a partir do site AppHost,, pois o host do aplicativo atual foi transferido para o site de destino. O aplicativo Data Synchronization deve funcionar normalmente no site principal antes de você executar a operação de failback. Consulte QRadar : Como forçar a execução dos aplicativos no Console quando o App Host estiver irrecuperável para forçar a execução dos aplicativos no console do site principal com o estado “Desconhecido”; em seguida, você poderá remover AppHost do console do site principal.
4. Se algum host gerenciado ainda estiver sendo exibido como ativo, abra um tíquete de suporte para identificar a causa raiz e remover o mesmo do console principal do site.
Quando o site principal está em funcionamento, mas a conexão de emparelhamento entre o site principal e o site de destino se desconecta repentinamente. Conclua as tarefas a seguir para restabelecer a conexão de emparelhamento.
1. No console QRadar do site principal, execute o seguinte comando:
```
/opt/ibm/si/dr/bin/dr_create_ssh.sh -i <destination_site_ip>
```
2. No console QRadar do site de destino, execute o seguinte comando:
```
/opt/ibm/si/dr/bin/dr_create_ssh.sh -i <main_site_ip>
```

É necessário fazer login como usuário administrador para fazer novos backups no console do site principal e no console do site de destino. Depois que um backup é gerado, o sistema transfere o backup gerado para outro site. Abra a tela Backup and Recovery para verificar se o backup transferido está visível. Se o backup transferido não estiver visível, atualize a tela Backup and Recovery.

Failback é a operação de restauração do site principal quando você não precisa mais que o site de destino substitua a operação do site principal. Quando você volta ao site principal, o processo de cópia do Ariel copia os dados do Ariel que foram coletados. Os dados são obtidos a partir do momento em que o site de destino foi ativado até o final da hora em que o processo de failback foi iniciado.

O tempo que leva o processo de failback pode variar com base nas seguintes condições:

O período de tempo em que o site de destino estava ativo.
A quantidade de dados coletados no site de destino enquanto ele estava ativo.
A largura de banda disponível entre o site de destino e o site principal.

Ariel Copy aceita apenas o horário mais próximo. O horário de início do failback é arredondado para a hora mais próxima. 9h15m é salvo como 9h nos perfis do Ariel Copy. Ariel Copy faz a sincronização dos dados em horas inteiras, por exemplo, das 9h às 9h59m.

Nesse processo de failback, a sincronização do Ariel é concluída e recebe uma notificação de que a cópia do Ariel foi concluída no site de destino. Após a conclusão da sincronização do Ariel, a restauração é iniciada automaticamente no site principal com o backup mais recente que foi feito após a ativação no site de destino e transferido para o site principal. Após a conclusão da restauração do site principal, a restauração é iniciada no site de destino.

Dica:

Se o site principal não estava disponível durante a ativação (cenário de ativação 1 ), o último backup do site de destino que o administrador iniciou antes da ativação é restaurado no site de destino durante o processo de failback.

Para a restauração de aplicativos, o backup mais recente do volume de aplicativos do site de destino que o administrador iniciou antes da ativação é restaurado no site de destino durante o processo de failback.

Se o site principal estava disponível durante a ativação (cenário de ativação 2 ), o último backup do site principal que foi transferido para o site de destino é restaurado no site de destino durante o processo de failback.

Para a restauração de aplicativos, o último backup de volume de aplicativo do site principal que foi transferido para o site de destino é restaurado no site de destino durante o processo de failback.

Lembre-se:

Os aplicativos instalados no console são suportados apenas durante operações de failover e failback. Se os aplicativos estiverem instalados em AppHost,, eles não serão restaurados ou migrados durante as operações de failover e failback.

O backup do volume de aplicativos está sendo transferido automaticamente de acordo com a programação diária. No entanto, é recomendável fazer o backup mais recente do volume.

Para fazer um backup do volume do aplicativo no console do site de destino:
- Aplicativos executados no console
  1. Consulte “Backup e restauração de dados de aplicativos” para fazer o backup dos dados de um volume de aplicativo a partir do console do site de destino.
  2. Transfira o backup do volume do aplicativo do console do site de destino para o console do site principal executando o seguinte comando no console do site de destino.
```
systemctl start app_sync
```
  3. Verifique a transferência no diretório do console do site principal (/store/app_sync/backups). Se a transferência não for bem-sucedida ou apresentar problemas, copie o backup do volume do aplicativo do diretório do console do site de destino (/store/apps/backup) para o diretório do console do site principal (/store/app_sync/backups).
- Aplicativos executados em AppHost
  1. Mova todos os aplicativos instalados para o console do site de destino
  2. Consulte “Backup e restauração de dados de aplicativos” para fazer o backup dos dados de um volume de aplicativo a partir do console do site de destino.
  3. Transfira o backup do volume do aplicativo do console do site de destino para o console do site principal executando o seguinte comando no console do site de destino.
```
systemctl start app_sync
```
  4. Verifique a transferência no diretório do console do site principal (/store/app_sync/backups). Se a transferência não for bem-sucedida ou apresentar problemas, copie o backup do volume do aplicativo do diretório do console do site de destino (/store/apps/backup) para o diretório do console do site principal (/store/app_sync/backups).
Para fazer um backup do volume do aplicativo no console principal do site (aplicativos executados no console):
1. Consulte “Como fazer backup e restaurar dados de aplicativos” para fazer backup dos dados do volume do aplicativo a partir do console do site principal.
2. Transfira os dados de backup do volume do aplicativo do console do site principal (/store/app_sync/backups) para o diretório do console do site de destino (/store/app_sync/backups). Essa etapa é necessária apenas para o site principal que estava disponível durante o cenário de ativação 2.
3. Transfira os dados de backup do volume do aplicativo do console do site principal para o console do site de destino executando o seguinte comando no console do site principal.
```
systemctl start app_sync
```
4. Verifique a transferência no diretório do console do site de destino (/store/app_sync/backups). Se a transferência não for bem-sucedida ou apresentar problemas, copie o backup do volume do aplicativo do diretório do console do site principal (/store/apps/backup) para o diretório do console do site de destino (/store/app_sync/backups).

Procedimento

Inicie a operação de failback a partir do site de destino.
1. No Console QRadar no site de destino, clique em Admin > Aplicativo de Sincronização de Dados.
2. É possível iniciar a operação de failback de duas maneiras:
  - Você pode selecionar “Revertida para o site principal” no painel para iniciar a operação de reversão.
  - Você pode abrir o menu deslizante à esquerda e selecionar “Revertida para o site principal” para iniciar a operação de reversão. Essa opção pode ser utilizada caso os usuários precisem prosseguir com a operação de failback, mesmo que as verificações tenham falhado. No entanto, você deve primeiro verificar e resolver as verificações que deram errado.
3. Clique em Perform failback e, em seguida, confirme.
4. Aponte todas as fontes de dados que foram direcionadas para o site de destino de volta para o site principal.
5. Quando os processos de restauração forem concluídos nos consoles do site principal e do site de destino:
  1. Realize a implementação completa no site principal.
  2. Realize a implementação completa no site de destino.
  Observação: a sequência completa de implementação deve ser mantida para garantir que os hosts gerenciados sejam realocados corretamente no site principal.
6. No site principal QRadar Console, execute o script /opt/ibm/si/dr/bin/dr_clear_seal_files.sh na hora em que o failback foi concluído para permitir que os dados fossem sincronizados corretamente entre os sites. Consulte “Resincronização de dados que foram copiados anteriormente no site principal” para obter mais detalhes.
Reativar o site principal.
1. No Console QRadar no site principal, clique em Admin > Aplicativo de Sincronização de Dados.
2. Abra o menu do aplicativo e selecione Reativar site principal.
3. Clique em Reactivate e, em seguida, em Next.
4. Na guia Admin do site principal e do site de destino, clique em Deploy Changes (Implementar alterações ). O site principal agora está ativo.

O que fazer a seguir

Após a conclusão da ativação, a conexão de emparelhamento entre os dois locais é removida. Para estabelecer a conexão de emparelhamento novamente, você deve executar os seguintes comandos de emparelhamento em ambos os sites:
1. No console QRadar no site principal, execute o seguinte script:
```
/opt/ibm/si/dr/bin/dr_create_ssh.sh -i <destination_site_ip>
```
  .
2. Em QRadar Console, no site de destino, execute o seguinte script:
```
/opt/ibm/si/dr/bin/dr_create_ssh.sh -i <main_site_ip>
```
  .
Os aplicativos instalados em AppHost não são restaurados ou migrados durante as operações de failover e failback. Para restaurar os aplicativos do site de destino no console principal, execute as seguintes etapas
1. Se um usuário no site principal precisar acessar um aplicativo que estava disponível no site de destino, mas que não está acessível no site principal, ele deverá ser reinstalado usando o site do console principal -> IBM QRadar Hub (anteriormente conhecido como IBM QRadar Assistant) -> Aplicativos -> seção Extensões instaladas.
  Para uma restauração bem-sucedida, as versões do aplicativo devem ser idênticas no site principal e no site de destino.
2. Faça backup dos dados de volume dos aplicativos existentes no console principal do site antes de prosseguir com as operações de restauração.
  - Certifique-se de que os backups corretos do volume do aplicativo estejam disponíveis no console principal do site. Para restaurar os backups de volume de aplicativos transferidos, copie os dados de backup de volume de aplicativos de /store/app_sync/backups para /store/apps/backup.
  - Restaure apenas os aplicativos necessários e os aplicativos de tamanhos menores. Para restaurar mais aplicativos no site de destino ou para manter os aplicativos no site de DR por mais tempo, você pode migrar os aplicativos do console do site de destino para AppHost antes de prosseguir com o procedimento de restauração.
  - Consulte “Como fazer backup e restaurar dados de aplicativos” para restaurar os dados de volume dos aplicativos. A prática padrão é usar o UUID para não restaurar o volume do aplicativo Data Synchronization no console do site de destino.
  - O aplicativo Data Synchronization é necessário para manter seu próprio estado e executar a operação de failback para ativar o site principal.
3. Se algum aplicativo for encontrado em um estado de erro após a conclusão da restauração ou após a operação de failover ou failback, reinicie os aplicativos usando o utilitário qappmanager ( /opt/qradar/support/qappmanager ).
Na configuração Console-Only, durante o failover e o failback, somente as informações da chave de licença são restauradas. O host gerenciado mantém os parâmetros correspondentes de nonConsoleEventLimit ou flowLimit definidos na chave de licença. Você precisa reconfigurar manualmente as alocações do pool de licenças usando o Console Admin -> Gerenciamento de sistema e licenças -> Alterar menu suspenso de exibição: Licenças -> Gerenciamento do pool de licenças.