O que é recuperação de desastres?

A recuperação de desastres (RD) é uma faceta dos planos abrangentes de continuidade de negócios desenvolvidos e mantidos pelas várias linhas de negócios dentro de uma organização. Um plano de recuperação de desastres eficaz mitiga o impacto que as interrupções não planejadas ou até planejadas dos sistemas de missão crítica e de negócios têm na capacidade de uma empresa de operar e continuar obtendo receita.

Para isso, um plano de RD fornece às organizações uma estrutura flexível que permite operar de forma unificada e colaborativa para restaurar, reconstruir e revitalizar seus sistemas e criar uma infraestrutura mais resiliente.

Explore os serviços de recuperação de desastres

Por que a recuperação de desastres é importante?

Por quanto tempo uma empresa poderia continuar a operar se perder seu sistema de folha de pagamento pouco antes do cálculo do pagamento e do financiamento de contas? Quais penalidades uma empresa incorreria devido ao atraso no pagamento de impostos federais, estaduais e locais? Quais consequências a empresa enfrentaria por não pagar os funcionários no prazo - e por quanto tempo os trabalhadores permaneceriam trabalhando?

Fazer ou não recuperação de desastres? Esta não é mais uma questão. A pergunta real é: qual é o verdadeiro custo de perder minutos, dias ou semanas de dados importantes e a confiança construída ao longo de anos em um instante?

A recuperação de desastres não pode mais permanecer um pensamento posterior ou algo considerado apenas quando há orçamento suficiente porque as organizações de hoje devem responder prontamente a eventos disruptivos e permanecer operacionais. Em vez de serem dissuadidas pelo custo de implementação de um plano de resiliência, as organizações devem ir mais fundo e avaliar o custo real de não ter um plano. Por exemplo, examine os acordos de nível de serviço (SLAs) que não puderam ser atendidos ou as penalidades e perdas de receita que resultariam de uma interrupção. Compare o custo de implementação da RD com as penalidades, perda de receita e perda de confiança do cliente e a escolha é clara.

Receita, produtividade e imagem de fidelidade perdida; descrição abaixo — Fonte: Estudo encomendado pela Forrester Consulting em nome da IBM, agosto de 2019. "Qual dos seguintes custos sua organização enfrenta devido a períodos de inatividade planejados e não planejados?"
Base: 100 diretores de TI em grandes empresas dos EUA (3º lugar no ranking)

Interrupções não planejadas

Se a interrupção é causada por um desastre natural, erros do operador de TI/provedor de serviços, corrupção de dados ou ataques de ransomware, uma organização deve ser capaz de se proteger de interrupções às operações de negócios que resultam em perdas catastróficas, sendo substituída por concorrentes oportunistas e tendo perda de reputação e boa vontade.

Embora esses resultados pareçam dramáticos, eles refletem as experiências recentes de muitas organizações bem conhecidas que não conseguiram se recuperar em tempo hábil e perderam grandes quantidades de dados transacionais críticos, informações de clientes e confiança.

Uma ampla variedade de cenários e causas primárias pode interromper as operações comerciais.

Gráfico das principais causas de tempo de inatividade não planejado, descrição abaixo — Fonte: Forrester Research, Inc.
Apresentado na Gartner Data Center Conference de 2014 - Quando o tempo de inatividade não é uma opção.
Base: 94 tomadores de decisão e influenciadores globais de recuperação de desastres que foram questionados "Quais foram as causas de suas declarações de desastres mais significativas ou grandes interrupções nos negócios?" (Não inclui respostas "não sei"; várias respostas foram aceitas.)

Interrupções planejadas

A recuperação de desastres como serviço (DRaaS) na nuvem fornece às empresas opções inigualáveis para flexibilidade operacional. As organizações usam soluções de recuperação de desastres para interrupções planejadas com mais frequência do que para se recuperar de eventos catastróficos.

Pontos de dor típicos

As abordagens tradicionais de recuperação de desastres exigem investimentos em automação.

Principais objetivos da recuperação de desastres

Os dois principais objetivos da recuperação de desastres são retornar os sistemas afetados a um estado operacional o mais rápido possível e fazê-lo com a menor perda de dados possível após um evento catastrófico ou interrupção planejada. As métricas para essas duas metas principais são universalmente conhecidas como RTO (Recovery Time Objective) e RPO (Recovery Point Objective), respectivamente.

Cada sistema de negócios terá requisitos diferentes para essas duas métricas, dependendo do contrato de nível de serviço entre as operações de TI e os proprietários de negócios.

Imagem da terminologia de proteção de dados, descrição abaixo

Objetivo do tempo de recuperação

O objetivo do tempo de recuperação é o tempo necessário para restaurar um sistema de negócios para um estado totalmente operacional após interrupções planejadas ou não planejadas.

Objetivo do ponto de recuperação

Um objetivo de ponto de recuperação é a quantidade máxima de dados que podem ser perdidos antes de causar danos prejudiciais a qualquer sistema de negócios. O RPO geralmente é medido no tempo do delta do último backup de dados, replicação ou snapshot.

Recuperação de desastres versus alta disponibilidade

Tradicionalmente, a alta disponibilidade (AD) protege contra pontos únicos de falha, enquanto a recuperação de desastres protege contra vários pontos de falha. Na computação em nuvem, a proteção contra pontos únicos de falha na camada de infraestrutura física, incluindo energia, refrigeração, armazenamento, redes e servidores físicos, é completamente abstraída para a arquitetura geral por meio de domínios de disponibilidade e falha.

A alta disponibilidade nesse caso é escalável e altamente resiliente à perda de dados ou à perda de desempenho do processamento. Quase todos os provedores de nuvem de nível empresarial criam alta disponibilidade em suas ofertas.

Soluções de recuperação de desastres de alta disponibilidade que oferecem zero perda de dados e proteção sem tempo de inatividade para bancos de dados ficam caras quando a tecnologia complexa de mapeamento e replicação de dados está envolvida. Essas soluções não fornecem proteção contra ransomware, que é obtida por meio de um backup abrangente com um armazenamento objetivo e imutável de ponto de recuperação pontual.

As soluções de AD tradicionais funcionam bem em conjunto com uma solução de RD na nuvem de baixo custo. A tecnologia de RD na nuvem complementar fornece uma camada extra de proteção para bancos de dados que exigem AD sem perda de dados, sem tempo de inatividade e precisam de proteção contra ransomware com rollback incremental de longo prazo.

A RD on-premises é uma solução inflexível e cara devido ao alto custo de duplicação da infraestrutura de TI em um local de origem e a um local de data center de destino fixo. Não pode funcionar por meio da WAN ou migrar servidores entre ambientes distintos, portanto, requer um circuito dedicado entre os data centers de origem e destino para operar como um único ambiente LAN interconectado. A RD tradicional também não pode migrar servidores entre ambientes heterogêneos diferentes, como um ambiente on-premises e uma plataforma em nuvem ou entre duas plataformas de nuvem diferentes.

O DRaaS usa uma variedade de soluções de backup oferecidas pelo fornecedor e ferramentas de migração de código aberto para criar um ambiente estritamente controlado e altamente específico. O usuário final só pode recuperar cargas de trabalho no ambiente de hospedagem tradicional do provedor DRaaS de seu ambiente VMware on-premises. Essas soluções oferecidas pelo fornecedor podem ser caras e limitadas na faixa de cargas de trabalho que podem proteger e nos ambientes de computação aos quais podem oferecer suporte.

Fluxos de trabalho, runbooks e planos de RD

A Oracle normalmente se refere a um fluxo de trabalho de RD como um plano de RD. Um plano de recuperação de desastres - ou runbook - é uma lista de etapas ou tarefas predeterminadas que precisam ser concluídas para fazer a transição da instância de computação, plataforma, banco de dados e aplicações para uma região de recuperação predeterminada na nuvem. Isso inclui todas as tarefas ou etapas individuais executadas por uma pessoa ou por algum tipo de automação durante uma operação de recuperação de desastres, como switchover ou failover. Os termos plano de RD, manual de execução de RD e fluxo de trabalho de RD são intercambiáveis.

Operações de RD (switchover vs. failover)

Uma operação de recuperação de desastres é o processo de executar cada etapa ou tarefa predeterminada em um plano de RD que é necessário para restaurar a infraestrutura, o banco de dados e as aplicações a um estado totalmente operacional. Dois termos diferentes são usados para descrever a transição de uma pilha de aplicações para um local diferente: failover e switchover.

Failover

Um failover implica uma interrupção não planejada na qual aplicações, bancos de dados e máquinas virtuais falharam e todos os recursos, incluindo armazenamento, dados e sistemas operacionais convidados, estão em um estado inconsistente. Nesse caso, supõe-se que a região de nuvem principal esteja totalmente inacessível e indisponível, o que indica que uma operação de recuperação de desastre verdadeira precisa ser acionada.

Portanto, todas as tarefas de recuperação de desastres em um plano de RD só podem ser executadas na região de nuvem em espera. É crucial que a solução DRaaS de um provedor de nuvem seja projetada para alta disponibilidade na região em espera para garantir que ela seja acessível e funcional quando um desastre catastrófico ocorrer.

Mudança

O switchover implica um tempo de inatividade planejado que inclui um desligamento ordenado de aplicações, bancos de dados e máquinas virtuais ou servidores. Nesse caso, as regiões principais e em espera operam normalmente e a equipe de operações de TI provavelmente está focada em "mover" um ou mais sistemas de uma região para outra para manutenção ou conclusão de upgrades incrementais.

Estratégia de implementação na nuvem

As empresas modernas podem aproveitar um ou mais dos seguintes modelos de implementação em nuvem por vários motivos, entre os quais custo, desempenho e requisitos de continuidade de negócios. Uma estratégia robusta de implementação na nuvem está se tornando cada vez mais prevalente à medida que as empresas continuam a transferir operações para a nuvem.

Soluções de RD entre regiões

As soluções de recuperação de desastres entre regiões protegem as organizações contra interrupções completas que impactam o acesso a sistemas de negócios hospedados na infraestrutura de nuvem de um único provedor. Como o nome indica, toda uma pilha de aplicações de qualquer sistema de negócios, incluindo máquinas virtuais, bancos de dados e aplicações, pode ser transferida sob demanda para uma região de nuvem totalmente diferente em uma localização geográfica diferente.

As soluções DRaaS devem ser capazes de fazer a transição de todo um sistema empresarial, como portal de recursos humanos, portal de serviços financeiros ou aplicação de gerenciamento de recursos empresariais, para uma região de nuvem totalmente diferente. O DRaaS deve ser capaz de atender aos objetivos de tempo de recuperação e ponto de recuperação exigidos pelos acordos de nível de serviço para cada aplicação individual.

Soluções de RD entre regiões, como o Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery, protegem aplicações corporativas da perda catastrófica de acesso a uma região de nuvem inteira, incluindo perda de todos os domínios de disponibilidade dessa região.

Soluções de RD em nuvem híbrida

RD em nuvem híbrida é uma solução muito popular que permite às empresas fazer a transição de cargas de trabalho e máquinas virtuais de seus próprios data centers para a infraestrutura em nuvem. Uma nuvem híbrida é frequentemente usada como uma solução de recuperação de desastres para proteger os dados e a viabilidade dos sistemas de negócios críticos de uma corporação.

Para clientes da Oracle, a nuvem híbrida é uma confederação frouxa entre a OCI e servidores físicos, appliances de nuvem da Oracle ou outros sistemas no data center físico de uma empresa. Os appliances de nuvem da Oracle, como o Oracle Private Cloud Appliance X9-2 e o Oracle Exadata Cloud@Customer, são excelentes exemplos de sistemas on-premises que se integram bem com a OCI.

Alguns produtos de parceiros da Oracle, como Rackware, podem ser usados para obter RD entre a infraestrutura on-premises e a OCI. Rackware está disponível por meio do Oracle Cloud Marketplace.

Soluções de RD multicloud

As soluções de RD multicloud protegem aplicações e dados distribuindo os vários componentes de uma pilha de aplicações nas infraestruturas de nuvem de dois ou mais provedores de nuvem. A parceria da Oracle com o Microsoft Azure é um bom exemplo de relacionamento multicloud.

A recuperação de desastres como um serviço deve ser capaz de acomodar RD entre regiões, RD em nuvem híbrida e RD entre várias nuvens. No momento, a OCI pode fornecer DRaaS para RD entre regiões e RD em nuvem híbrida.

Consistência de dados para bancos de dados

Soluções viáveis de recuperação de desastres envolvendo bancos de dados devem sempre incluir os meios para garantir a consistência dos dados. O ponto no qual um banco de dados pode ser recuperado para consistência total de dados, incluindo transações em andamento, define o objetivo do ponto de recuperação.

A consistência de dados é muito menos um problema para bancos de dados serverless ou de arquivo simples, mas a recuperação de bancos de dados relacionais sofisticados, como Oracle Database ou MySQL, para um estado consistente de dados para um determinado momento é muito complexa, ainda que crucial.

Considerações sobre recuperação de desastres para bancos de dados MySQL

Ao usar o MySQL Database Service na OCI, um sistema de banco de dados MySQL é um contêiner lógico para uma ou mais instâncias MySQL. Ele fornece uma interface que permite o gerenciamento de tarefas, como provisionamento, backups automáticos e recuperação pontual.

As tecnologias de replicação nativa e log de binários MySQL permitem recuperação pontual, alta disponibilidade e recuperação de desastres. A MySQL Group Replication geralmente é usada para criar clusters tolerantes a falhas locais para alta disponibilidade, enquanto a replicação assíncrona MySQL geralmente é usada para recuperação de desastres distribuída geograficamente.

Um sistema de banco de dados com alta disponibilidade ativada tem três instâncias MySQL colocadas em diferentes domínios de disponibilidade ou domínios de falha. O sistema de banco de dados garante que, se uma instância falhar, outra assumirá, sem perda de dados e tempo de inatividade mínimo. Para recuperação de desastres em regiões diferentes, também é possível criar canais de replicação de entrada entre dois sistemas de banco de dados.

Use os links a seguir para saber muito mais sobre recuperação de desastres para MySQL na nuvem.

Visão geral da continuidade dos negócios para MySQL
Visão geral da alta disponibilidade para MySQL
Visão geral da replicação de entrada para MySQL

Considerações sobre recuperação de desastres para bancos de dados Oracle

A Oracle Maximum Availability Architecture (MAA) fornece arquitetura, configuração e melhores práticas de ciclo de vida para bancos de dados Oracle, permitindo níveis de serviço de alta disponibilidade para bancos de dados que residem em configurações on-premises, na nuvem ou híbridas.

Use os links a seguir para saber muito mais sobre a Oracle Maximum Availability Architecture para recuperação de desastres na nuvem.

Página de destino da Oracle Maximum Availability Architecture
Arquiteturas de referência da Oracle Maximum Availability Architecture
Melhores práticas da Oracle Maximum Availability Architecture para Oracle Fusion Middleware
Melhores práticas da Oracle Maximum Availability Architecture para aplicações

Arquiteturas de implementação baseadas em nuvem

A arquitetura de implementação descreve como vários componentes, como computação, plataforma/banco de dados e aplicações, são implementados entre regiões de nuvem para criar um meio resiliente de recuperação da falha total de um data center. A arquitetura de implementação descreve onde tudo está localizado durante a operação normal de um pacote de aplicações e o que precisa ser recuperado na região em espera para que as coisas sejam executadas novamente.

A Oracle acredita que as soluções DRaaS devem ter a flexibilidade de incorporar qualquer combinação de arquiteturas de implementação de RD para atender aos requisitos de nível de serviço individual para cada sistema de negócios exclusivo. Os provedores de nuvem devem oferecer a seus clientes a liberdade de escolher "todas as soluções acima" para atender aos SLAs para a ampla variedade de sistemas de negócios que as organizações normalmente suportam.

Muitos termos são usados para descrever estratégias de RD e arquiteturas de implementação. No entanto, as várias abordagens e padrões para descrever como implementar a infraestrutura, a plataforma e as aplicações para recuperação de desastres se enquadram em duas grandes categorias estratégicas: RD ativo/ativo e ativo/em espera.

A tabela a seguir quebra os termos comuns usados para descrever as diferentes arquiteturas de implementação que se enquadram nas duas estratégias gerais de RD.

Estratégia	Arquitetura de implementação	RPO	RTO
Ativo/espera	Espera fria	Horas	Horas
Ativo/espera	Chama piloto	Minutos	Horas
Ativo/espera	Espera morna	Segundos	Horas
Ativo/espera	Espera quente	Segundos	Minutos
Ativo/ativo	Ativo/ativo	Quase zero	Quase zero

Esta seção tenta desmistificar algumas das variações de abordagens ativas/ativas e ativas/em espera para recuperação de desastres. Ambas as estratégias de recuperação de desastres têm seu lugar no arsenal de armas disponíveis para alcançar a continuidade dos negócios.

Arquiteturas de implementação ativas/em espera

Há muitas variações de arquiteturas de implementação ativas/em espera. As implementações ativas/em espera, às vezes chamadas de implementações ativas/passivas, geralmente são caracterizadas como implementações em espera frias, mornas, quentes e chama piloto.

Os cenários de luz do piloto, espera fria, espera morna e espera quente representam alguma forma do mesmo tema em que 100% de uma pilha de aplicações está sendo executada na região principal, enquanto menos de 100% do mesmo sistema de negócios está sendo executado ativamente na região de espera.

A série a seguir de diagramas conceituais de alto nível tem o objetivo de ilustrar algumas diferenças fundamentais entre arquiteturas de implementação comuns e não são construídas como arquiteturas de referência; elas não descrevem como implementar a RD para uma pilha de aplicações.

Espera fria

Neste cenário, as máquinas virtuais (VMs), o banco de dados e as aplicações só existem na região principal atual. Os grupos de volumes de armazenamento de arquivo e em blocos que contêm o disco de inicialização e quaisquer outros discos virtuais para cada VM são replicados para a região em espera.

Durante uma operação de RD, como um switchover ou failover, o armazenamento replicado que contém as mesmas VMs é ativado na região em espera, e as mesmas VMs exatas são iniciadas novamente no ponto em que foram interrompidas ou travadas. As VMs são as mesmas máquinas virtuais exatas que estavam sendo executadas anteriormente na região ativa.

Essa arquitetura de implementação tem várias vantagens, incluindo custos de implementação mais baixos, menor sobrecarga de manutenção e custos operacionais mais baixos. No entanto, essa pode não ser a melhor solução para aplicações que se baseiam em bancos de dados relacionais para o backend. A única maneira de garantir a consistência dos dados é executar backups frios periódicos. Essa abordagem funciona bem para aplicações que podem tolerar interrupções ocasionais curtas e completas.

A maioria das operações de TI resolve esse problema encerrando periodicamente o banco de dados, fazendo um snapshot do armazenamento em blocos e retomando as operações normais. Isso define o objetivo do ponto de recuperação, pois você só pode restaurar para o momento em que o backup foi concluído.

Essa arquitetura terá um tempo de recuperação um pouco maior, e há um risco muito maior de perda de dados, mas é uma solução viável para a carga de trabalho certa. Por exemplo, esta pode ser uma excelente solução para aplicações que contam com um banco de dados de arquivo simples, um banco de dados sem servidor ou nenhum banco de dados ou para clientes que simplesmente querem tornar um conjunto de máquinas virtuais móveis entre regiões para maior flexibilidade.

Exemplo de fluxos de trabalho de RD para essa arquitetura de implementação

Os dois cenários a seguir descrevem como o fluxo do processo para operações de RD para implementações em espera frias pode progredir.

No caso de um switchover, as seguintes tarefas são executadas nas regiões principais e em espera:

As aplicações principais estão desativadas.
Os bancos de dados principais são desativados e sincronizados com a região em espera.
As máquinas virtuais primárias são interrompidas de forma adequada.
O armazenamento principal está sincronizado com a região em espera.
O armazenamento replicado é colocado online, a replicação é revertida e agora é principal na região em espera.
Cópias replicadas de máquinas virtuais principais são iniciadas, e qualquer aplicação ou ferramenta do sistema necessária à pilha de aplicações é iniciada e agora é principal na região em espera.
As cópias replicadas dos bancos de dados principais são recuperadas na região em espera usando o backup mais recente ou os logs de transação e restauração do armazenamento replicado.
As cópias replicadas dos bancos de dados principais são iniciadas e montadas e agora são principais na região em espera.
As cópias replicadas das aplicações principais são iniciadas e validadas e agora são principais na região em espera.
Quaisquer alterações no DNS e nos balanceadores de carga são feitas para permitir o acesso à aplicação pela rede voltada ao público.

No caso de um failover, as seguintes tarefas são executadas apenas na região em espera:

O armazenamento replicado é colocado online, a replicação é revertida e agora é principal na região em espera.
Cópias replicadas de máquinas virtuais principais são iniciadas, e qualquer aplicação ou ferramenta do sistema necessária à pilha de aplicações é iniciada e agora é principal na região em espera.
As cópias replicadas dos bancos de dados principais são recuperadas na região em espera usando o backup mais recente ou os logs de transação e restauração do armazenamento replicado.
As cópias replicadas dos bancos de dados principais são iniciadas e montadas e agora são principais na região em espera.
As cópias replicadas das aplicações principais são iniciadas e validadas e agora são principais na região em espera.
Quaisquer alterações no DNS e nos balanceadores de carga são feitas para permitir o acesso à aplicação pela rede voltada ao público.

Espera morna

Neste cenário, as máquinas virtuais existem nas regiões principais e em espera, mas são completamente independentes umas das outras e têm seus próprios nomes de host exclusivos e endereços IP pré-atribuídos. As VMs na região de espera existem e podem ser interrompidas ou executadas, dependendo da preferência do cliente.

Os bancos de dados devem estar em execução nas regiões principais e em espera.

Para bancos de dados Oracle, recomendamos o uso do Oracle Data Guard para replicar o banco de dados principal e em espera. Consulte nossa arquitetura de referência Gold MAA para obter mais detalhes.

Para bancos de dados não Oracle, as respectivas tecnologias de replicação nativas serão usadas para manter os bancos de dados sincronizados entre regiões principais e em espera.

As aplicações também existem na região de nuvem em espera, mas não estão em execução nem acessíveis.

Exemplo de fluxos de trabalho de RD para essa arquitetura de implementação

Os dois cenários a seguir descrevem como o fluxo do processo para operações de RD para implementações em espera frias pode progredir.

No caso de um switchover, as seguintes tarefas são executadas nas regiões principais e em espera:

As aplicações principais estão desativadas.
Os bancos de dados principais são desativados e sincronizados com a região em espera.
As máquinas virtuais primárias são interrompidas de forma adequada.
O armazenamento principal está sincronizado com a região em espera.
O armazenamento replicado é colocado online, a replicação é revertida e agora é principal na região em espera.
As máquinas virtuais em espera serão iniciadas se ainda não estiverem em execução, e quaisquer aplicações do sistema ou ferramentas exigidas pela pilha de aplicações serão iniciadas e agora serão principais na região em espera.
Os bancos de dados em espera são alternados para o acesso de leitura/gravação completo e agora são principais na região em espera.
As aplicações em espera são iniciadas e validadas e agora são principais na região em espera.
Quaisquer alterações no DNS e nos balanceadores de carga são feitas para permitir o acesso à aplicação pela rede voltada ao público.

No caso de um failover, as seguintes tarefas são executadas apenas na região em espera:

O armazenamento replicado é colocado online, a replicação é revertida, se possível, e se torna principal na região em espera.
As máquinas virtuais em espera serão iniciadas se ainda não estiverem em execução, e quaisquer aplicações do sistema ou ferramentas exigidas pela pilha de aplicações serão iniciadas e agora serão principais na região em espera.
Os bancos de dados em espera são recuperados usando os logs de transação e restauração mais recentes do armazenamento replicado.
Os bancos de dados em espera são alternados para o acesso de leitura/gravação completo e agora são principais na região em espera.
As aplicações em espera são iniciadas e validadas e agora são principais na região em espera.
Quaisquer alterações no DNS e nos balanceadores de carga são feitas para permitir o acesso à aplicação pela rede voltada ao público.

Espera quente

Nesse cenário, as máquinas virtuais existem e estão em execução nas regiões principais e em espera com seus próprios nomes de host exclusivos e endereços de IP pré-atribuídos.

Os bancos de dados devem estar em execução nas regiões principais e em espera.

Para bancos de dados Oracle, recomendamos o uso do Oracle Data Guard para replicar o banco de dados principal e em espera. Consulte nossa arquitetura de referência Gold MAA para obter mais detalhes.

Para bancos de dados não Oracle, as respectivas tecnologias de replicação nativas serão usadas para manter os bancos de dados sincronizados entre regiões principais e em espera.

As aplicações estão em execução na região de nuvem em espera, mas não podem ser acessadas pela rede pública.

Exemplo de fluxos de trabalho de RD para essa arquitetura de implementação

Os dois cenários a seguir descrevem como o fluxo do processo para operações de RD para implementações em espera pode progredir.

No caso de um switchover, as seguintes tarefas são executadas nas regiões principais e em espera:

As aplicações principais estão desativadas.
Os bancos de dados principais são desativados e sincronizados com a região em espera.
As máquinas virtuais primárias são interrompidas de forma adequada.
O armazenamento principal está sincronizado com a região em espera.
O armazenamento replicado é colocado online, a replicação é revertida e agora é principal na região em espera.
As máquinas virtuais em espera já estão em execução, e quaisquer aplicações do sistema ou ferramentas exigidas pela pilha de aplicações são iniciadas e agora são principais na região em espera.
Os bancos de dados em espera são alternados para o acesso de leitura/gravação completo e agora são principais na região em espera.
As aplicações em espera são iniciadas e validadas e agora são principais na região em espera.
Quaisquer alterações no DNS e nos balanceadores de carga são feitas para permitir o acesso à aplicação pela rede voltada ao público.

No caso de um failover, as seguintes tarefas são executadas apenas na região em espera:

O armazenamento replicado é colocado online, a replicação é revertida, se possível, e se torna principal na região em espera.
As máquinas virtuais em espera serão iniciadas se ainda não estiverem em execução, e quaisquer aplicações do sistema ou ferramentas exigidas pela pilha de aplicações serão iniciadas e agora serão principais na região em espera.
Os bancos de dados em espera são recuperados usando os logs de transação e restauração mais recentes do armazenamento replicado.
Os bancos de dados em espera são alternados para o acesso de leitura/gravação completo e agora são principais na região em espera.
As aplicações em espera são iniciadas e validadas e agora são principais na região em espera.
Quaisquer alterações no DNS e nos balanceadores de carga são feitas para permitir o acesso à aplicação pela rede voltada ao público.

Arquitetura de implementação ativa/ativa

Nesse cenário, toda a pilha de aplicações está totalmente funcional e trata uma carga de trabalho nas regiões principais e em espera.

Os bancos de dados devem estar em execução nas regiões principais e em espera.

Para bancos de dados Oracle, recomendamos o uso do Oracle GoldenGate para ter configuração de aplicação ativa/ativa. Além disso, recomendamos ter bancos de dados em espera locais em cada região usando o Oracle Data Guard para obter um RTO e RPO quase zero. Consulte nossa arquitetura de referência platinum MAA para obter mais detalhes.

Para bancos de dados não Oracle, a respectiva replicação nativa e tecnologias ativas/ativas serão usadas para manter o banco de dados sincronizado entre as regiões principais e em espera.

As aplicações estão em execução e acessíveis pela rede voltada ao público na região de nuvem em espera e têm uma carga de trabalho em execução.

Automatização de tarefas de recuperação de desastres com DRaaS

As equipes da Oracle se esforçaram muito para projetar alta disponibilidade em seus produtos, incluindo a grande maioria dos bancos de dados e aplicações de classe empresarial da Oracle, e muitas vezes desenvolvem as melhores práticas e arquiteturas de implementação para obter recuperação de desastres em configurações on-premises tradicionais, bem como na nuvem. Cada linha de produtos desenvolve uma abordagem de RD para suas aplicações individuais que incorpora etapas acopladas de modo fraco para recuperar todos os componentes necessários para oferecer suporte a suas aplicações.

O serviço de recuperação de desastres baseado em nuvem pode vincular todas as etapas levadas a cabo por desenvolvedores, arquitetos de nuvem e arquitetos de solução de produto a um único workflow integrado que pode ser iniciado com um único clique. A OCI oferece uma solução DRaaS chamada Full Stack Disaster Recovery que é flexível, altamente escalável e altamente extensível.

O OCI Full Stack Disaster Recovery gerencia a transição de infraestrutura, bancos de dados e aplicações entre regiões da OCI de qualquer lugar do mundo com um único clique. Os clientes podem implementar ambientes de recuperação de desastres sem reprojetar ou reimplementar a infraestrutura, os bancos de dados ou as aplicações existentes, eliminando ao mesmo tempo a necessidade de servidores especializados de gerenciamento ou conversão.

Saiba mais sobre o OCI Full Stack Disaster Recovery
Saiba mais sobre recuperação de desastres para a OCI