Recuperação de Desastre
Um plano de DR (recuperação de desastre) bem arquitetado permite que você se recupere rapidamente de desastres e continue a fornecer serviços aos seus usuários.
DR é o processo de preparação e recuperação de um desastre. Um desastre pode ser qualquer evento que coloque seus aplicativos em risco, desde interrupções na rede, falhas de equipamentos e aplicativos até desastres naturais. É quase impossível prever quando você vai precisar de recuperação de desastre, assim como não é possível prever um acidente de trânsito. Se você não pode controlar a ocorrência de um desastre, o melhor a fazer é ser capaz de controlar o processo de recuperação.
Um plano de DR bem projetado permite que você se recupere rapidamente de desastres e forneça continuidade dos negócios. À medida que sua organização move cargas de trabalho para a nuvem, você precisa converter seu entendimento sobre como criar sistemas locais resilientes para a nuvem. O OCI (Oracle Cloud Infrastructure) fornece infraestrutura e serviços altamente disponíveis, seguros e escaláveis que permitem recuperar suas cargas de trabalho na nuvem de forma rápida, confiável e segura.
Como arquiteturas multicamadas ou de três camadas são comuns em aplicativos empresariais on-premises tradicionais, vamos usar um exemplo de aplicativo empresarial em três camadas para mostrar como você pode tornar esse aplicativo mais resiliente no desastre usando os recursos de DR do OCI e as melhores práticas de topologia de nuvem confiável e resiliente. O diagrama a seguir mostra um exemplo de aplicativo empresarial na configuração de DR stand-by quente.
Conceitos de DR
O primeiro passo no planejamento da DR envolve a determinação do RTO (Recovery Time Objective) e do RPO (Recovery Point Objective).
O RTO é o horário fixado para o qual um determinado aplicativo deve ser restaurado após um desastre. Normalmente, quanto mais crítico for o aplicativo, menor o RTO.
O RPO é o período após um desastre, durante o qual um aplicativo pode tolerar dados perdidos, antes que o desastre comece a afetar os negócios.
Para criar um plano que garanta a recuperação de seus aplicativos após um desastre e que seja econômico, considere o horário fixado para a recuperação e a tolerância à perda de dados.
Para obter mais informações, consulte Melhores práticas para proteger sua topologia de nuvem contra desastres.
Escolhendo uma Abordagem de DR
Alguns aplicativos são mais críticos do que outros. A solução de DR que você escolhe depende de muitos requisitos possíveis, incluindo disponibilidade, durabilidade de dados, RTO e RPO.
Avalie os métodos de DR na tabela a seguir para decidir quais recursos de DR do OCI usar ao implantar aplicativos empresariais em várias camadas no OCI.
| Método de DR | RPO | RTO | Custo |
|---|---|---|---|
| Backup e restauração | Horas | Horas | $ |
| Luz piloto | Minutos | Minutos | $$ |
| Stand-by quente | Segundos | Minutos | $$$ |
| Ativo/ativo | Quase zero | Zero potencial | $$$$ |
Considere as regiões e os domínios de disponibilidade dentro de uma região para DR e os cenários de HA (alta disponibilidade). Uma região é uma área geográfica localizada e um domínio de disponibilidade abrange um ou mais data centers localizados em uma região. Se o seu plano de DR exigir que os sites de DR estejam fisicamente separados, o uso de várias regiões poderá atingir esse objetivo.
Para nosso exemplo de aplicativo empresarial, precisamos sobreviver a uma interrupção regional, mas poderemos lidar com algum período de indisponibilidade se uma região for afetada. Por esses motivos, escolhemos uma implantação stand-by quente em várias regiões.
Gerenciar Orquestração de DR com DR de Pilha Completa
O Full Stack Disaster Recovery (DR) é um serviço nativo do OCI que fornece uma interface simples e consistente para orquestrar operações de DR para muitos sistemas diferentes, facilitando para qualquer usuário autorizado em suas operações de TI acionar um failover ou switchover sem precisar entender nenhum dos processos de recuperação subjacentes.
O Full Stack DR é a primeira verdadeira solução de recuperação de desastres como serviço (DRaaS) da Oracle para a OCI e é mais do que apenas um mecanismo de orquestração simples. O Full Stack DR é um serviço de gerenciamento de DR altamente escalável e extensível que automatiza totalmente as etapas necessárias para testar, fazer a transição ou recuperar sistemas de negócios críticos e não críticos entre duas regiões da OCI de qualquer lugar do mundo com um único clique.
Os problemas que as empresas enfrentam com a recuperação em escala
Sua empresa provavelmente tem mais do que apenas alguns aplicativos essenciais para a missão e os negócios hospedados em sua tenancy da OCI. Para complicar as coisas, cada um desses aplicativos Oracle ou não Oracle tem um processo de recuperação diferente com diferentes objetivos de ponto de recuperação e tempo de recuperação. Além disso, os processos de recuperação de cada pilha de aplicativos diferentes podem ser complexos, exigindo toda a atenção de seus especialistas técnicos mais antigos para realizar.
Sua organização de TI provavelmente tem as habilidades e a determinação de recuperar um ou dois aplicativos diferentes em um dia ou dois em um esforço prático e abrangente dos especialistas de TI mais experientes da empresa. Mas o que acontece se sua organização de TI enfrentar a perspectiva de recuperar mais do que apenas alguns sistemas ao mesmo tempo?
Full Stack DR Facilita a Recuperação em Escala
O Full Stack DR foi projetado para lidar com fluxos de trabalho de DR em escala sem envolver seus especialistas técnicos mais qualificados no caso de você precisar recuperar muitos sistemas ao mesmo tempo. O Full Stack DR normaliza a forma como as operações de DR são executadas e monitoradas usando um método simples e consistente por meio da Console do OCI.
O Full Stack DR organiza vários aplicativos em grupos de proteção independentes sem alterar nada sobre a maneira como você instalou e configurou seus aplicativos Oracle e não Oracle existentes na OCI. O Full Stack DR pode recuperar apenas um componente de uma pilha de aplicativos ou recuperar toda a pilha de aplicativos com um único clique – você escolhe o que deseja fazer.
Full Stack DR Valida a Prontidão dos Planos de DR
O Full Stack DR ajuda a validar se os sistemas de negócios críticos estão prontos para quaisquer interrupções inesperadas de serviço por meio de nossas verificações de prontidão de DR integradas e totalmente automatizadas. Nosso recurso de Pré-verificação é adicionado automaticamente à lista de tarefas que o Full Stack DR executa durante qualquer operação de DR.
As Pré-verificações não são disruptivas e podem ser executadas a qualquer momento sem perturbar seus sistemas de produção. Validamos a integridade dos planos de DR verificando se a rede, o armazenamento, a computação, os bancos de dados Oracle e quaisquer scripts personalizados adicionados a um plano de DR estão onde eles devem estar e prontos para uso.
Flexibilidade para Gerenciar Qualquer Arquitetura de Implantação
Flexibilidade é um conceito-chave por trás do design do Full Stack DR. Diferentes sistemas de negócios exigem diferentes soluções de recuperação. Portanto, o Full Stack DR está em conformidade com a maneira como você precisa recuperar cada sistema de negócios individual de uma forma que corresponda às suas necessidades técnicas e comerciais. A forma como você escolhe instalar e implantar um sistema de negócios para recuperação de desastres depende de você.
Nossa solução DRaaS pode gerenciar a recuperação de forma diferente para cada sistema de negócios individual, seja implantado para failover de VM, luz piloto, espera fria, espera quente, espera quente ou ativo/ativo. Você lida com a implantação e nós lidamos com a recuperação.
Saiba mais sobre o Full Stack DR
O Full Stack DR oferece a você o poder e a flexibilidade para implementar o DR para aplicações Oracle ou não Oracle na OCI da maneira que você deseja, não da maneira que queremos.
- Saiba mais sobre o Full Stack DR
- Guia do usuário
- Guia de API
- Mergulhe mais fundo na recuperação de desastres
- Laboratório prático ao vivo
Considerações de Design de DR
Há muitas coisas a serem consideradas, dependendo do método de DR que você implementar.
Para obter informações básicas sobre recursos de DR, consulte Recursos de DR do Oracle Cloud. Neste exemplo, revisamos o método stand-by quente e os recursos da OCI necessários para implementar stand-by quente, que incluem uma segunda região para uma implantação entre regiões.
Redes
Após criar a base das VCNs (redes virtuais na nuvem) e sub-redes nas respectivas regiões, para configurar a DR, você precisa parear as VCNs nas diferentes regiões para facilitar a conectividade de rede.
Computação
Para executar aplicativos em instâncias de computação em duas regiões, disponibilize as imagens de computação em ambas as regiões. Na região de DR, implante uma configuração mínima para manter um stand-by quente. Em seguida, use reservas de capacidade para reservar o restante da capacidade necessária para executar todas as VMs quando a região de DR se tornar principal. Para obter mais informações, consulte Visão Geral do Serviço Compute e Melhores Práticas para a Sua Instância de Computação.
Armazenamento
A OCI fornece um conjunto de serviços de armazenamento que inclui o serviço Block Volume, o serviço File Storage e o serviço Object Storage, que fornecem redundância integrada e recursos de alta disponibilidade, mantendo várias cópias de dados. Esses serviços de armazenamento também fornecem replicação nativa que pode ser configurada para recuperação de desastres entre regiões.
O Object Storage é uma plataforma de armazenamento de alto desempenho em escala na internet que oferece durabilidade de dados confiável e econômica. O serviço Object Storage é um serviço regional e está disponível em todos os domínios de disponibilidade de uma região. A replicação do serviço Object Storage pode ser configurada entre regiões para fins de DR.
O Block Volume tem um recurso de replicação assíncrona totalmente gerenciado para ajudar na recuperação de desastres. Com um RTO (Recovery Time Objective) de menos de um minuto, você pode replicar volumes e grupos de volumes para outra região. Um recurso de backup automatizado também está disponível para produzir backups consistentes com falhas para volumes e grupos de volumes. Esses backups podem ser copiados automaticamente para outra região.
Semelhante a outros serviços de armazenamento na OCI, o File Storage tem recursos de replicação integrados para replicar de forma assíncrona para outro domínio e região de disponibilidade. Usando o recurso de clonagem do serviço File Storage, os dados no lado de destino podem ser disponibilizados quase instantaneamente (RTO). Para uma experiência de DR completa, a replicação também replica snapshots com os dados do sistema de arquivos principal.
Banco de Dados
O design de alta disponibilidade destina-se a garantir a disponibilidade do aplicativo em caso de eventos de falha IaaS, como falha de nó ou rede. Os cenários de DR do banco de dados lidam com a prevenção da perda de dados de negócios críticos devido a interrupções significativas e inevitáveis no(s) banco(s) de dados principal(is) que geralmente afetam uma região inteira ou um domínio de disponibilidade.
Recomendamos que você faça referência a Arquitetura de Disponibilidade Máxima (MAA), que é um conjunto de melhores práticas e arquiteturas de referência desenvolvidas por engenheiros da Oracle durante muitos anos para o uso integrado de tecnologias de alta disponibilidade, proteção a dados e recuperação por desastres da Oracle.
As principais considerações para um design de DR são o RPO (Recovery Point Objective), que é a quantidade de perda de dados que seu aplicativo pode tolerar, e o RTO (Recovery Time Objective), que é o tempo máximo de recuperação que seu aplicativo pode tolerar antes que os sistemas precisem voltar a ficar on-line. Com base nestes, existem várias categorias que o MAA define com o aumento de custos e complexidade. Estes são categorizados como Bronze, Prata, Aurous, Ouro e Platina, cada um com crescente complexidade e resiliência. Estes formam a base para as arquiteturas de referência DR especificadas pela MAA.
| Camadas de Arquitetura de Disponibilidade Máxima (MAA) | Arquitetura Básica | RPO (Recovery Point Objective) | RTO (Recovery Time Objective) | Oracle Autonomous Database Serverless (ADB-S) | Oracle Autonomous Database on Dedicated Exadata Infrastructure (ADB-D e ADB-C@C) | Oracle Base Database Service (VM) | Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) | Oracle Exadata Database Service on Cloud@Customer (ExaDB-C@C) |
|---|---|---|---|---|---|---|---|---|
| BRONZE | Instância única com backup local e backup replicado | Último Backup | Horas | Pré-Definido | Pré-Definido | Pré-Definido | Pré-Definido | Pré-Definido |
| SILVER | RAC com backup local e backup replicado | Último Backup | Horas (Zero para manutenção planejada) | Pré-Definido | Pré-Definido | Pronto para uso para 2 nós (Exigir Desempenho Extremo EE) | Pré-Definido | Pré-Definido |
| AUROUS | PDB Atualizável | Última Atualização | Minutos | + Autonomous Data Guard | Opcional | Opcional | Opcional | Opcional |
| OURO | Banco de dados com replicação Ativo-Passivo entre sites por meio do Data Guard (Ativo) | Zero | Segundos | Não se Aplica | + Data Guard | + Data Guard (Requer EE/EE HP para DG Padrão, EE EP para DG Ativo) | + Data Guard | + Data Guard |
| PLATINUM | Banco de dados com replicação Ativo-Ativo entre sites por meio de GoldenGate | Zero | Zero | + GoldenGate | + GoldenGate | + GoldenGate | + GoldenGate | + GoldenGate |
Esse design e estratégia de DR descreve a prevenção da perda de dados no banco de dados Oracle. Uma estratégia robusta de DR também deve abordar configurações para disponibilidade contínua de aplicativos.
As principais tecnologias que formam a base do MAA incluem:
- Recovery Manager (RMAN)
- Banco de Dados Plugável Atualizável (PDB)
- Data Guard e Active Data Guard
- Autonomous Data Guard
- OCI Golden Gate
Monitoring
O OCI Monitoring permite monitorar de forma ativa e passiva seus recursos de nuvem para obter disponibilidade aprimorada e níveis do serviço consistentes. Certifique-se de estar inscrito nas Notificações de status do OCI e verifique o Painel de Integridade do Serviço. Por exemplo, consulte Monitoramento Ponto a Ponto de aplicativos em execução no Oracle Cloud Infrastructure.
Explorar Mais
Playbooks de Soluções:
- Saiba mais sobre como automatizar a recuperação de aplicativos Oracle e não Oracle
- Saiba como proteger sua topologia de nuvem contra desastres
- Projete a infraestrutura para implantar o Oracle Enterprise Performance Management na nuvem (Arquitetura de DR: Várias Regiões)
- Proteja seu VMware SDDC na nuvem contra desastres
- Implante o Commvault para proteger o SDDC do VMware na nuvem contra desastres
- Implante o Zerto para proteger o SDDC do VMware na nuvem contra desastres
- Implante o Veeam para proteger seu SDDC da VMware na nuvem contra desastres
- Implante o Actifio para proteger seu SDDC do VMware na nuvem contra desastres
Arquiteturas de Referência:
- Projete uma topologia de DR (recuperação de desastre) de luz piloto
- Implantar o Exadata Cloud Service com o Data Guard em várias regiões
- Implante uma solução de recuperação de desastre entre regiões usando o RackWare
- Configure a conectividade privada entre regiões e entre tenancies
Documentação e outros recursos