Um plano de continuação de negócios garante que seus aplicativos permaneçam disponíveis e recuperáveis durante interrupções. Seu plano deve combinar:
Alta disponibilidade (HA): implemente arquiteturas que se auto-reparam automaticamente quando a infraestrutura falha.
Recuperação de desastres (DR): estabeleça procedimentos para recuperar manualmente quando o failover automático não puder ajudar.
Teste: valide regularmente as funcionalidades de HA e DR.
Documentação: Mantenha procedimentos e objetivos de recuperação claros.
Observação
O Modelo de responsabilidade compartilhada do MongoDB Atlas define os direitos complementares do MongoDB e de seus clientes em manter um ambiente de dados seguro e resiliente. Nesse framework, o MongoDB gerencia a segurança e a integridade operacional da plataforma subjacente, enquanto os clientes são responsáveis pelas políticas de configuração, gerenciamento e dados de suas implantações específicas. Para obter uma análise detalhada da propriedade em segurança e segurança operacional, consulte Modelo de responsabilidade compartilhada.
Escolha sua estratégia de resiliência
Escolha entre as seguintes abordagens principais com base em seus requisitos:
Alta disponibilidade - Autocorreção automática
Escolha a HA quando precisar de um tempo de inatividade próximo a zero e possa implantar em várias zonas de disponibilidade (AZ), regiões ou provedores de nuvem.
Características:
Failover automático sem intervenção manual.
RPO = 0 ao usar
majoritywrite concern.RTO = segundos.
Maior custo de infraestrutura.
Quando usar: a maioria das implantações de produção, especialmente quando:
Você tem usuários em várias regiões.
Seu aplicativo exige disponibilidade contínua.
Você pode implantar em regiões com zonas de disponibilidade 3+.
Para aprender mais, consulte Orientações para Alta Disponibilidade do Atlas e Paradigmas de Implantação do Atlas.
Recuperação de desastres - Recuperação manual
Escolha DR quando a HA não for possível ou custo-benefício, por exemplo:
Restrições geográficas, como o Canadá, com apenas 2 regiões.
Aplicativos sensíveis ao custo.
Tolerância para procedimentos manuais de recuperação.
Características:
Intervenção manual necessária.
RPO > 0, dependendo da frequência do backup.
RTO = minutos a horas.
Custo de infraestrutura mais baixo, aplicam-se custos de armazenamento de backup.
Quando usar:
Restrições geográficas ou normativas impedem a implantação multirregional.
Restrições orçamentárias exigem otimização de custos.
O aplicativo tolera o tempo de inatividade planejado para recuperação.
Para aprender mais, consulte Orientação para recuperação de desastre do Atlas.
Combinando HA e DR
A maioria dos ambientes de produção se beneficia da combinação das duas abordagens para fornecer proteção abrangente:
HA para falhas de infraestrutura: o failover automático protege contra interrupções de nó, zona, região ou provedor.
DR para problemas de integridade de dados: os backups protegem contra cenários que o failover automático não consegue resolver.
Por que você pode se beneficiar da DR mesmo com HA
Mesmo com uma implantação de alta disponibilidade, você pode se beneficiar dos procedimentos de recuperação de desastre para:
- Corrupção de dados ou exclusão acidental
- A alta disponibilidade replica dados corrompidos em todos os nós. Você deve restaurar a partir de backups para recuperar para um estado anterior à ocorrência da corrupção ou exclusão.
- Falhas no nível do aplicativo
- Erros de código ou ataques maliciosos que afetam a integridade dos dados em vez da infraestrutura. O estado corrompido foi replicado em todo o conjunto de réplicas.
- Requisitos de conformidade
- Muitos regulamentos exigem funcionalidades de recuperação ponto-in-time e políticas de retenção de backup que vão além do que o failover automático oferece.
Essa abordagem em camadas oferece proteção abrangente e, ao mesmo tempo, otimiza a disponibilidade e a integridade dos dados.
Defina seus objetivos de recuperação
Estabeleça objetivos de recuperação claros para orientar suas decisões de arquitetura e backup:
Recovery Point Objective (RPO)
A quantidade máxima aceitável de perda de dados medida no tempo.
Exemplos:
RPO = 0: Use HA com
majoritywrite concern.RPO = 1 hora: configura snapshots por hora.
RPO = 1 day: configure snapshots diários.
objetivo de tempo de recuperação (RTO)
O tempo máximo aceitável para restaurar o serviço após a interrupção.
Exemplos:
RTO = segundos: use HA com failover automático.
RTO = 1 hora: certifique-se de que os procedimentos de restauração de backup sejam concluídos em <1 hora.
RTO = 4 horas: Documentar e testar os procedimentos de recuperação manual.
Seu paradigma de implantação e estratégia de backup devem se alinhar com esses objetivos. Use as tabelas de comparação em Orientação para alta disponibilidade do Atlas e Orientação para recuperação de desastres do Atlas para avaliar as opções.
Teste Seu Plano Regularmente
Teste seu plano de continuação de negócios pelo menos semestralmente (recomendado trimestralmente). O teste valida seus procedimentos e instrui sua equipe.
Testar failover de alta disponibilidade
Testes automatizados:
Use o recurso Testar Failover Primário da IU do Atlas.
Use o failover de teste do ponto de extremidade da API de administração do Atlas.
Simule interrupções regionais para sistemas multirregional .
validar:
O failover é concluído dentro do RTO esperado.
Os aplicativos se reconectam automaticamente.
Não ocorre perda de dados (RPO = 0).
Testar procedimentos de recuperação de desastre
Testes manuais de recuperação:
Pratique restaurar a partir de backup em ambientes que não sejam de produção.
Documente os tempos reais de recuperação e compare com o RTO.
Verifique a integridade dos dados restaurados.
Teste as restaurações entre regiões se estiver usando a distribuição de snapshots de multirregional .
validar:
A equipe segue os procedimentos documentados corretamente.
A recuperação é concluída dentro do RTO esperado.
A perda de dados se alinha ao RPO esperado.
Todas as dependências (redes, credenciais) funcionam corretamente.
Alguns testes podem exigir ações indisponíveis para usuários padrão. Abra um caso de suporte com pelo menos uma semana de antecedência para agendar interrupções artificial ou outros cenários de teste restritos.
Documente seu plano
Mantenha uma documentação clara para o seu plano de continuação de negócios:
Documentação necessária
Objetivos de recuperação:
RPO e RTO documentados para cada tier de aplicação.
Validação do paradigma de implantação escolhido.
Frequência de backup e decisões de retenção.
Documentação da arquitetura:
topologia de implantação (regiões, zonas, fornecedores de nuvem).
Arquitetura de rede e comportamento de failover.
Topologia de implantação de aplicativo.
Dependências de serviços de terceiros.
Procedimentos de recuperação:
Procedimentos de restauração passo a passo.
Informações de contato da equipe de monitoramento .
Caminhos de escalonamento para diferentes tipos de cenário.
Links para painéis e alertas de monitoramento.
Resultados do teste:
Datas e resultados históricos de execução do teste.
Problemas identificados e status de correção.
Alterações nos procedimentos com base nos aprendizados dos testes.
Mantenha a documentação atualizada revisando e atualizando após cada exercício de teste ou alteração de infraestrutura.
Cenários e planos de resposta comuns
Prepare planos de resposta para cenários comuns de interrupção. Para procedimentos detalhados, consulte as seções específicas do cenário em Orientação para Recuperação de desastres do Atlas.
Falhas de infraestrutura (Cenários HA)
interrupção de nó único :
Sistemas de alta disponibilidade: failover automático, nenhuma ação necessária.
Monitore o failover bem-sucedido e a restauração do nó.
interrupção da zona de disponibilidade :
Sistemas Multi-AZ: failover automático, nenhuma ação necessária.
Verifique se o aplicativo continua veicular tráfego.
interrupção regional :
Sistemas multirregionais: failover automático para outra região.
Certifique-se de que o aplicativo também seja implantado em multirregional.
Verifique se os serviços de terceiros permanecem acessíveis.
interrupção do fornecedor de nuvem :
Implantações multinuvem: failover automático para outro provedor.
Implantações de nuvem única: execute procedimentos de DR.
Problemas de integridade de dados (Cenários de DR)
Corrupção de dados:
Identifique o carimbo de data/hora de corrupção.
Restaurar do backup antes da ocorrência da corrupção.
Para backup contínuo: use a restauração point-in-time.
Exclusão acidental:
Identifique o carimbo de data/hora de exclusão.
Restaurar a partir do backup antes da exclusão.
Verifique a integridade dos dados restaurados.
Perda completa da implantação:
Execute procedimentos de DR documentados.
Restaure a partir do backup mais recente.
Valide a funcionalidade do aplicativo.
Falhas no plano de controle:
Efetivamente raro. O Atlas mantém alta confiabilidade.
Consulte Confiabilidade da plataforma.
Entre em contato com o suporte do MongoDB imediatamente.
Para procedimentos de recuperação detalhados para cada cenário, consulte Orientação para Recuperação de desastres do Atlas.