Você pode implantar uma segunda instância do Ops Manager, chamada de Ops Manager secundário, para fazer backup de um Ops Manager primary e seus bancos de dados de backup. O Ops Manager secundário também serve como seu caminho de recuperação se você perder o Ops Manager principal.
Esse padrão protege os dados operacionais que o Ops Manager armazena em seu banco de dados de aplicativo e armazenamentos de metadados. Use este guia para projetar, configurar e operar a recuperação de desastres para o próprio Ops Manager.
Este guia é para administradores do Ops Manager que gerenciam backup e recuperação de desastres e para equipes que projetam topologias de alta disponibilidade e recuperação de desastres para o Ops Manager.
Como funciona o backup do Ops Manager secundário
Nesse padrão, duas instâncias do Ops Manager têm responsabilidades distintas:
O principal Ops Manager gerencia seus MongoDB deployments e seus backups, como de costume.
O Ops Manager secundário gerencia e faz backup somente dos bancos de dados de suporte do Ops Manager principal. O Ops Manager secundário não gerencia seus clusters de aplicação .
O MongoDB Agent é executado em cada host do banco de dados de aplicativo do Ops Manager primário e se registra no Ops Manager secundário. O Ops Manager secundário realiza backups contínuos e pontuais desses bancos de dados de backup.
Se você perder o Ops Manager principal, restaurará os bancos de dados de backup do Ops Manager secundário e, em seguida, iniciará um novo Ops Manager principal. O Ops Manager principal se reconecta aos bancos de dados de backup restaurados e retoma o gerenciamento de suas implementações do MongoDB .
Quando os MongoDB Agents se reconectam após a reinicialização, eles relatam uma versão de configuração mais recente do que o banco de dados restaurado. O Ops Manager principal detecta a incompatibilidade, entra automaticamente no Modo de Restauração para o projeto afetado,converge todos os agentes na configuração restaurada e bloqueia alterações de implantação até que a reconciliação seja concluída.
Arquitetura
A tabela a seguir descreve os componentes deste padrão e suas responsabilidades:
Componente | Responsabilidade |
|---|---|
Primary Ops Manager | Gerencia suas implantações do MongoDB e seus backups. Armazena seus próprios dados operacionais em seu banco de dados de aplicativo, armazenamento de metadados de snapshot e armazenamento de metadados de oplog. |
Gerente de operações secundário | Executa um Backup Daemon que grava em um3blockstore de armazenamento compatível com S para snapshots do banco de dados de aplicativo e fatias de oplog. Faz backup contínuo dos bancos de dados de backup do Ops Manager principal. Não gerencia seus clusters de aplicação . |
banco de dados de aplicativos | Armazena os dados operacionais do Ops Manager principal, incluindo configuração do projeto , estado de automação e metadados de backup. Você deve fazer backup do banco de dados de aplicativo. |
Armazenamentos de metadados de snapshots e oplog | Armazene os índices de bloqueio e oplog para as implantações que o Ops Manager principal faz backup. Faça backup desses armazenamentos também. |
MongoDB Agent | É executado em cada host de banco de dados de backup e registrado no Ops Manager secundário para executar backups e restaurações. |
O Ops Manager secundário armazena os backups dos bancos de dados de backup do Ops Manager principal em seu próprio blockstore de armazenamento compatível com S3, separado do armazenamento de backup do Ops Manager principal.
Variantes de sistema
Implante o Ops Manager secundário em um domínio de falha separado do Ops Manager principal para evitar que uma única falha afete ambas as instâncias. Variantes comuns incluem:
Diferentes regiões
Implemente o Ops Manager secundário em uma região de nuvem diferente do Ops Manager primary. Esta variante protege contra a perda de uma região.
Diferentes data centers
Implemente o Ops Manager secundário em um data center diferente do Ops Manager primary. Essa variante protege contra a perda de um centro de dados.
Rede de backup separada
Coloque o Ops Manager secundário em uma rede separada dedicada ao tráfego de backup. Essa variante isola o tráfego de backup da sua rede de aplicação .
Importante
Implante o Ops Manager secundário em um domínio de falha separado, como um rack, zona de disponibilidade, região ou segmento de rede diferente do Ops Manager principal. Se ambas as instâncias compartilharem um domínio de falha, uma única falha poderá interromper o Ops Manager principal e seu caminho de recuperação.
Versões e limitações suportadas
Antes de usar esse padrão, revise os seguintes requisitos e limitações.
Versões suportadas
As instâncias primária e secundária do Ops Manager devem executar o Ops Manager 8.0.24 ou posterior.
O Ops Manager secundário deve executar a mesma versão ou versão posterior que o Ops Manager principal. Não execute um Ops Manager secundário que seja uma versão anterior ao Ops Manager principal.
Aviso
Restaure o banco de dados de aplicativo em um Ops Manager primário que execute a mesma versão ou uma versão posterior ao Ops Manager principal original do qual o snapshot foi obtido. Se o binário de substituição for mais antigo do que a versão registrada do banco de dados do aplicação , o Ops Manager se recusará a iniciar com um erro "Downgrades não são permitidos".
Limitações
Esse padrão faz backup dos bancos de dados de backup do Ops Manager principal. Ele não faz backup de clusters MongoDB arbitrários. O principal Ops Manager continua a gerenciar backups para suas implementações do MongoDB .
Fazer backup e reconciliar o armazenamento de metadados de snapshot e o armazenamento de metadados oplog é um procedimento manual. O Ops Manager não seleciona automaticamente um ponto de restauração para esses armazenamentos. Como resultado, os metadados de backup podem ser inconsistentes após uma restauração, e alguns backups podem ser não restauráveis. O Ops Manager valida um snapshot antes de restaurar e falha com um erro em vez de executar uma restauração insegura.
O Modo de Restauração não se aplica a sistemas gerenciados externamente, como sistemas que um Operador Kubernetes gerencia. Depois de restaurar o banco de dados de aplicativo, os agentes nesses projetos recebem a configuração restaurada diretamente na próxima pesquisa e convergem sem entrar no Modo de Restauração. Nenhuma ação é necessária para esses projetos.
Um snapshot pode se tornar irrecuperável se seus blocos de dados não estiverem mais no armazenamento de snapshots. Antes de uma restauração, o gerente de operações principal verifica se os blocos do snapshot existem. Se houver blocos ausentes, a restauração falhará com um erro e deixará o conjunto de réplicas inalterado, em vez de defini-lo e falhar parcialmente.
Uma restauração não testada é um risco operacional. Valide o caminho de backup e restauração regularmente. Consulte o manual de validação em Restaurar Ops Manager a partir de um Ops Manager Secundário.
Próximos passos
Para configurar e operar este padrão, consulte as seguintes páginas: