Não foi possível encontrar uma correspondência para sua pesquisa.

Sugerimos que você tente o seguinte para ajudar a encontrar o que procura:

  • Verifique a ortografia da sua pesquisa por palavra-chave.
  • Use sinônimos para a palavra-chave digitada; por exemplo, tente “aplicativo” em vez de “software.”
  • Inicie uma nova pesquisa.
Entre em Contato Faça login na Oracle Cloud

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 DR 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.

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 DR 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 abaixoA imagem é intitulada "Receita, produtividade e perda de fidelidade". Há três estatísticas de chave exibidas nesta imagem. Essas estatísticas foram derivadas de um estudo encomendado pela Forrester Consulting em nome da IBM em 2019. A pergunta feita aos entrevistados foi "Qual dos seguintes custos sua organização enfrenta devido ao tempo de inatividade planejado e não planejado?"
No lado esquerdo, a estatística exibida mostra que 53% dos entrevistados responderam "Receita perdida". No meio, a estatística mostra que 47% responderam "perda de produtividade". No lado direito, a estatística mostra que 41% responderam “Perda do valor da marca ou da confiança".
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 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 do cliente e confiança.

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

Principais causas do gráfico de tempo de inatividade não planejado, descrição abaixoEsta imagem é intitulada "Principais causas de tempo de inatividade não planejado". A imagem exibe um gráfico de barras que mostra causas de interrupções não planejadas. O gráfico de barras é segmentado em três categorias: falhas operacionais, desastres naturais e eventos humanos. As falhas operacionais são agrupadas na parte mais à esquerda do gráfico de barras, os desastres naturais estão no meio e os eventos causados por humanos são agrupados na parte mais à direita do gráfico de barras. A fonte deste gráfico é a Forrester Research, Inc.
Fonte: Forrester Research, Inc.
Apresentado na Gartner Data Center Conference 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.
  • Mesmo os sistemas de negócios nos data centers da camada 1 podem ser impactados por interrupções de energia, que são muito frequentes. Com que frequência um incidente comum, como uma queda de energia, causou um dia ou dois de perda de produtividade? A equipe de TI acaba gastando horas ou muitos dias em chamadas de conferência fazendo com que os sistemas entrem em funcionamento novamente usando soluções stopgap. • Algumas empresas gastam partes significativas de seus orçamentos de TI desenvolvendo a automação interna para gerenciar a recuperação de desastres apenas para ter medo de usá-la ou até mesmo testá-la periodicamente para garantir que ela continue funcionando conforme o esperado. • Muitas vezes leva um dia (ou dias) para se recuperar de uma janela de manutenção planejada. • Mesmo planos de DR bem documentados ou livros de execução podem envolver dias de perda de produtividade, enquanto a equipe de operações de TI realiza atos de heroísmo para fazer as coisas correrem novamente.

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 abaixoA imagem é intitulada "Terminologia de proteção de dados". A tolerância para a perda de dados e a tolerância para o tempo de inatividade são representadas em uma linha reta que se estende em direções opostas do centro da imagem. À esquerda, você tem "Perda de dados" e, à direita, tem "Tempo de inatividade".

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 (HA) 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 HA tradicionais funcionam bem em conjunto com uma solução de DR na nuvem (CDR) de baixo custo. A tecnologia de CDR complementar fornece uma camada extra de proteção para bancos de dados que exigem zero perda de dados, tempo de inatividade zero HA e precisam de proteção contra ransomware com rollback incremental de longo prazo.

A DR 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. O DR 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 aplicação de patches de soluções de backup fornecidas pelo fornecedor e ferramentas de migração de código-fonte aberto para criar um ambiente altamente específico e altamente controlado. O usuário final só pode recuperar cargas de trabalho no ambiente de hospedagem tradicional do provedor DRaaS de seu ambiente local VMware. 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 DR

A Oracle normalmente se refere a um fluxo de trabalho de DR como um plano de DR. 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 DR, manual de execução de DR e fluxo de trabalho de DR são intercambiáveis.

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

Uma operação de recuperação de desastres é o processo de executar cada etapa ou tarefa predeterminada em um plano de DR 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 DR 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 principal 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 DR 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 de nuvem. 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 DR entre regiões, como o Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery, protegem aplicações empresariais inteiras 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 DR em nuvem híbrida

DR 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 DR entre a infraestrutura on-premises e a OCI. Rackware está disponível por meio do Oracle Cloud Marketplace.

Soluções de DR multicloud

As soluções de DR 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 DR entre regiões, DR em nuvem híbrida e DR entre várias nuvens. No momento, a OCI pode fornecer DRaaS para DR entre regiões e DR 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 sem servidor 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 Replicação de Grupo MySQL 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ídos 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á, com perda de dados zero 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.

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

O 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 o Oracle Maximum Availability Architecture para recuperação de desastres na nuvem.

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 DR 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 DR e arquiteturas de implementação. No entanto, as várias abordagens e padrões para descrever como implantar a infraestrutura, a plataforma e as aplicações para recuperação de desastres se enquadram em duas grandes categorias estratégicas: DR 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 DR.

Estratégia Arquitetura de implementação RPO RTO
Ativo/espera Espera fria horas horas
Ativo/espera Luz do piloto Minutos horas
Ativo/espera Espera morna Segundos horas
Ativo/espera Em espera a 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 luz do 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 DR 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.

Imagem em espera fria, descrição abaixoMostra uma imagem com a região principal à esquerda e a região em espera à direita. A região principal tem três blocos: aplicação, banco de dados e infraestrutura, cada um contendo seus respectivos ícones. Ambas as regiões têm um ícone que representa um balanceador de carga na parte superior. O ícone do balanceador de carga na região em espera é um tom mais claro do que o da região principal. A região em espera tem três blocos: aplicação, banco de dados e infraestrutura. Na região em espera, somente o bloco de infraestrutura é preenchido com ícones - um para armazenamento de objetos, armazenamento em blocos e armazenamento de arquivos. Os blocos de banco de dados e aplicações na região em espera estão vazios. Duas setas que representam a replicação de armazenamento de objetos e a replicação de armazenamento são mostradas entre os dois blocos de infraestrutura. Essas setas representam a replicação da região principal para a região em espera.

Durante uma operação de DR, 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 back-end. 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 DR para esta arquitetura de implementação

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

No caso de um switchover, as seguintes tarefas são executadas nas regiões principal 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 on-line, 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 redo 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 on-line, 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 redo 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 principal 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.

Imagem em espera morna, descrição abaixoMostra uma imagem com a região principal à esquerda e a região em espera à direita. A região principal tem três blocos: aplicação, banco de dados e infraestrutura, cada um contendo seus respectivos ícones. Ambas as regiões têm um ícone que representa um balanceador de carga na parte superior. O ícone do balanceador de carga na região em espera é um tom mais claro do que o da região principal. A região em espera tem três blocos: aplicação, banco de dados e infraestrutura. Na região em espera, o bloco de infraestrutura é preenchido com ícones - um para armazenamento de objetos, armazenamento em blocos e armazenamento em arquivos. Há também um ícone para máquinas virtuais no nível de infraestrutura, mas é uma sombra mais clara. Os ícones do banco de dados e o ícone da aplicação na região em espera também são um tom mais claro. Duas setas que representam a replicação de armazenamento de objetos e a replicação de armazenamento são mostradas entre os dois blocos de infraestrutura. Essas setas representam a replicação da região principal para a região em espera.

Os bancos de dados devem estar em execução nas regiões principal 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 principal 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 DR para esta arquitetura de implementação

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

No caso de um switchover, as seguintes tarefas são executadas nas regiões principal 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 on-line, 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 on-line, 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 redo 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.

Em espera a quente

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

Imagem em espera quente, descrição abaixoMostra uma imagem com a região principal à esquerda e a região em espera à direita. A região principal tem três blocos: aplicação, banco de dados e infraestrutura, cada um contendo seus respectivos ícones. Ambas as regiões têm um ícone que representa um balanceador de carga na parte superior. O ícone do balanceador de carga na região em espera é um tom mais claro do que o da região principal. A região em espera tem três blocos: aplicação, banco de dados e infraestrutura. As regiões principal e em espera têm ícones nos blocos de aplicações, banco de dados e infraestrutura. O bloco de infraestrutura tem ícones para máquinas virtuais, armazenamento de arquivos, armazenamento de objetos e armazenamento em blocos nas regiões principal e em espera. Somente os ícones do banco de dados na região em espera são um tom mais claro. Duas setas que representam a replicação de armazenamento de objetos e a replicação de armazenamento são mostradas entre os dois blocos de infraestrutura. Essas setas representam a replicação da região principal para a região em espera.

Os bancos de dados devem estar em execução nas regiões principal 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 principal 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 DR para esta arquitetura de implementação

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

No caso de um switchover, as seguintes tarefas são executadas nas regiões principal 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 on-line, 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 on-line, 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 redo 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 principal e em espera.

Imagem da arquitetura de implementação ativa/ativa, descrição abaixoMostra uma imagem com a região principal à esquerda e a região em espera à direita. Cada uma das regiões principal e em espera tem três blocos: aplicação, banco de dados e infraestrutura, cada um contendo seus respectivos ícones. Ambas as regiões têm um ícone que representa um balanceador de carga na parte superior. Nenhum está esmaecido. Os ícones dos blocos de aplicação, banco de dados e infraestrutura nas regiões principal e em espera são mostrados em cores. Uma seta que representa a replicação de armazenamento opcional é mostrada entre os dois blocos de infraestrutura. Essa seta representa a replicação do principal para a região em espera.

Os bancos de dados devem estar em execução nas regiões principal 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 principal 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 DR 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.