Transferindo o controle da implantação de volta do site de destino para o site principal
Quando o site principal estiver pronto, volte a transferir o controle de implantação do site de destino para o site principal.
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.
Considere os seguintes cenários antes de prosseguir com a operação de failback.
- Depois que o site principal for recuperado e voltar a funcionar, tanto o site principal quanto o site de destino exibirão 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 realocados para o console de destino durante o processo de ativação. Conclua as seguintes tarefas para resolver este problema.
- Remova os hosts gerenciados que estão no estado Desconhecido do site principal antes de executar a operação de failback no site principal.
- Se o site principal MH 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.
- Se todos os aplicativos estiverem hospedados no AppHost que se conecta ao site principal, você não poderá remover o host do aplicativo desconhecido do console do site principal. Você precisa migrar todas as configurações e dados de volume dos aplicativos (incluindo o aplicativo de sincronização de dados) do AppHost, para o console do site principal, pois o host atual do aplicativo foi realocado para o site de destino. O aplicativo de sincronização de dados 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.
- Se algum host gerenciado ainda estiver aparecendo como Ativo, abra um ticket de suporte para identificar a causa raiz e removê-lo do console principal do site.
- Quando o site principal estiver em funcionamento, mas a conexão de emparelhamento entre os hosts do site principal e o host do site de destino se desconectar repentinamente, os hosts deverão primeiro ser desemparelhados e, em seguida, emparelhados novamente. Para desemparelhar o host, consulte “Desemparelhamento de hosts ”. Para emparelhar o host, consulte “Emparelhamento de hosts gerenciados ”.
Business Rules (mapeamento do grupo de hosts) deve ser o mesmo que era antes da ativação para o host gerenciado emparelhado. Após a ativação, não é recomendável adicionar ou remover hosts ou alterar mapeamentos de host (editar conexão de host), pois isso pode afetar o processo de failback. Para mais informações, consulte Business Rules.
Você deve fazer login como usuário administrador para fazer um novo backup no console do site de destino. Após a geração de um backup, o sistema transfere o backup gerado para o site principal. Abra a tela Backup e recuperação para verificar se o backup transferido está visível. Se o backup transferido não estiver visível, atualize a tela Backup e recuperação.
Failback é a operação de restauração do site principal quando você não precisa mais do site de destino para substituir 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 referentes ao período entre a ativação do site de destino e o final da hora em que o processo de failback foi iniciado.
- 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. A hora em que o failback começa é arredondada 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 está 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.
Se o HA estiver configurado no Console do site principal ou no Host gerenciado emparelhado do site principal, o failback não será executado. O HA deve ser removido antes de iniciar o processo de failback a partir do site principal.
A restauração de aplicativos precisa ser realizada manualmente na configuração híbrida. Os aplicativos instalados no console são suportados apenas durante operações de failover e failback
O backup do volume dos aplicativos está sendo transferido automaticamente de acordo com a programação diária. No entanto, é recomendável fazer um backup do volume mais recente.
- Para fazer um backup do volume do aplicativo a partir do console do site de destino:
- Aplicativos que funcionam no console
- 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.
- 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 - 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 que funcionam em um AppHost
- Mova todos os aplicativos instalados para o console do site de destino
- 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.
- 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 - 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 que funcionam no console
- Para fazer um backup do volume do aplicativo a partir do console do site principal (aplicativos executados no console):
- 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.
- Transfira os dados de backup 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). Esta etapa é necessária apenas para o site principal que estava disponível.
- 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 - 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
O que fazer a seguir
- Após o failover, se algum host gerenciado emparelhado estiver em um estado desconhecido, acesse .
- Após a conclusão da reativação, se a conexão de emparelhamento entre os hosts de ambos os locais for removida, os hosts devem primeiro ser desemparelhados e, em seguida, emparelhados novamente. Para desemparelhar o host, consulte “Desemparelhamento de hosts ”. Para emparelhar o host, consulte “Emparelhamento de hosts gerenciados”.
- Para restaurar os aplicativos do site de destino no console principal, execute as seguintes etapas
- Se um usuário no Site Principal precisar acessar um aplicativo que estava disponível no Site de Destino, mas não está acessível a partir do Site Principal, ele deve 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.
- Faça backup dos dados do volume dos aplicativos existentes no console do site principal 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 do site principal. Para restaurar os backups do volume dos aplicativos transferidos, copie os dados do backup do volume dos aplicativos de /store/app_sync/backups para /store/apps/backup.
- Restaure apenas os aplicativos necessários e aqueles de tamanho menor. 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 UUID e 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.
- Se algum aplicativo estiver em 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
qappmanagerutilitário (/opt/qradar/support/qappmanager).
- Se um usuário no Site Principal precisar acessar um aplicativo que estava disponível no Site de Destino, mas não está acessível a partir do Site Principal, ele deve ser reinstalado usando o site do Console Principal -> IBM QRadar Hub (anteriormente conhecido como IBM QRadar Assistant) -> Aplicativos -> seção Extensões Instaladas.
- Na configuração híbrida, durante o failover e o failback, apenas as informações da chave de licença são restauradas. O host gerenciado mantém os parâmetros flowLimit correspondentes nonConsoleEventLimit ou definidos na chave de licença. Você precisa reconfigurar manualmente as alocações do pool de licenças usando Console Admin -> Gerenciamento do sistema e licenças -> Alterar exibição Menu suspenso: Licenças -> Gerenciamento do pool de licenças.