Saiba mais sobre Recuperação de Desastres para Standbys Locais e Regionais

Garantir a continuidade dos negócios é fundamental para o sucesso ao projetar aplicativos. Conseguir isso requer uma estratégia de recuperação de desastres que possa restaurar rapidamente o serviço durante interrupções.
Por décadas, as organizações contaram com o Oracle Exadata Database Machine e o Oracle Data Guard, a principal tecnologia de recuperação de desastres da Oracle, para oferecer suporte a aplicações de missão crítica, seja on-premises ou dentro da Oracle Cloud Infrastructure (OCI). O Oracle Exadata Database Service on Dedicated Infrastructure no Oracle Database@AWS traz o mesmo desempenho, conjunto de recursos e paridade de preços líderes do setor do Exadata na OCI. O hardware reside nos data centers da AWS para fornecer baixa latência aos aplicativos da AWS, além de recursos incomparáveis de alta disponibilidade e recuperação de desastres, garantindo operações contínuas durante a manutenção e em caso de interrupção.

Neste manual de soluções, você aprende a implementar a recuperação de desastres com standbys locais e regionais no Oracle Database@AWS.

Antes de Começar

Antes de começar, certifique-se de que:
  • A infraestrutura do Exadata e os clusters de VMs do Exadata são implantados na zona e região de disponibilidade stand-by.
  • As faixas de CIDRs de IP de rede dos clusters de VMs do Exadata principal e stand-by não se sobrepõem.

Revise as seguintes soluções:

Revise estes recursos relacionados:

Arquitetura

Esta arquitetura mostra o Oracle Exadata Database Service no Oracle Database@AWS em uma topologia de recuperação de desastres usando dois bancos de dados stand-by:
  • Um stand-by local na mesma região do principal, mas em uma zona de disponibilidade diferente.
  • Um stand-by remoto em outra região.

Veja a seguir a descrição da ilustração exadb-dbaws-dr-arch.png
Descrição da ilustração exadb-Dbaws-Dr-arch.png

exadb-dbaws-dr-arch-oracle.zip

O Oracle Database é executado em um cluster de VMs do Exadata no Region 1 principal. Para proteção de dados e recuperação de desastres, o Active Data Guard replica os dados para os dois clusters de VMs do Exadata a seguir:

  • Um na mesma região, mas em uma zona de disponibilidade diferente (stand-by local). Um stand-by local é ideal para cenários de failover, oferecendo zero perda de dados para falhas locais, enquanto os aplicativos continuam a operar sem a sobrecarga de desempenho da comunicação com uma região remota.
  • Um segundo stand-by em outra região (stand-by remoto). Um stand-by remoto geralmente é usado para recuperação de desastre ou para descarregar cargas de trabalho somente leitura.

Embora o tráfego de rede do Active Data Guard possa atravessar o backbone da AWS, a Oracle recomenda essa arquitetura que o roteia pela OCI para obter throughput e latência otimizados.

O Oracle Exadata Database Service na rede Oracle Database@AWS é conectado à sub-rede do cliente Exadata usando um Gateway de Roteamento Dinâmico (DRG) gerenciado pela Oracle. Um DRG também é necessário para criar uma conexão de mesmo nível entre VCNs em diferentes regiões. Como só é permitido um DRG por VCN no OCI, uma segunda VCN com seu próprio DRG é necessária para conectar as VCNs principal e stand-by em cada região.

  • O cluster de VMs principal do Exadata é implantado em Region 1, availability zone 1 em VCN1 com CIDR 10.10.0.0/16 e CIDR de sub-rede do cliente 10.10.1.0/24.
  • O VCN1 tem LPGs (Local Peering Gateways) LPG1 remote e LPG1 local.
  • A VCN do Hub no Region 1 principal é Hub VCN1 com CIDR 10.11.0.0/16.
  • O primeiro Cluster de VMs stand-by do Exadata é implantado em Region 1, availability zone 2 em VCN2 com CIDR 10.20.0.0/16 e CIDR de sub-rede do cliente 10.20.1.0/24.
  • VCN2 tem dois LPGs LPG2 remote e LPG2 local.
  • A VCN do Hub é igual à VCN do Hub para o banco de dados Principal, Hub VCN1, pois reside na mesma região.
  • Hub VCN1 tem LPG Hub LPG1, Hub LPG2 e DRG1.
  • O segundo cluster de VMs stand-by do Exadata é implantado em Region 2 no VCN3 com CIDR 10.30.0.0/16 e CIDR de sub-rede do cliente 10.30.1.0/24.
  • VCN3 tem um LPG LPG3 remote.
  • A VCN do Hub no stand-by remoto Region 2 é Hub VCN3 com CIDR 10.33.0.0/16.
  • Hub VCN3 tem um LPG Hub LPG3 e um DRG DRG3.
  • Nenhuma sub-rede é necessária para que as VCNs do hub ativem o roteamento de trânsito. Portanto, essas VCNs podem usar intervalos CIDR de IP muito pequenos.

Essa arquitetura suporta os seguintes componentes:

  • Região da AWS

    As regiões da AWS são áreas geográficas separadas. Consistem em várias zonas de disponibilidade isoladas, separadas fisicamente e conectadas com rede de baixa latência, alto throughput e altamente redundante.

  • Zona de disponibilidade da AWS

    As zonas de disponibilidade são data centers altamente disponíveis em cada região da AWS.

  • Rede e sub-rede virtual na nuvem da OCI

    VCN (rede virtual na nuvem) é uma rede personalizável definida por software que você configura em uma região do OCI. Assim como as redes tradicionais do data center, as VCNs dão a você controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos de CIDR (Classless Inter-domain Routing) não sobrepostos que você pode alterar após criar a VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.

  • Tabela de roteamento

    As tabelas de roteamento virtual contêm regras para rotear o tráfego de sub-redes para destinos fora de uma VCN, geralmente por meio de gateways.

  • Grupo de segurança de rede (NSG)

    Os NSGs atuam como firewalls virtuais para seus recursos de nuvem. Com o modelo de segurança de confiança zero da OCI, você controla o tráfego de rede dentro de uma VCN. Um NSG consiste em um conjunto de normas de segurança de entrada e saída que se aplicam apenas a um conjunto especificado de VNICs (placas de interface de rede virtual) em uma única VCN.

  • Pareamento local

    O pareamento local permite que duas VCNs dentro da mesma região da OCI se comuniquem diretamente usando endereços IP privados. Essa comunicação não atravessa a internet nem a sua rede local. O pareamento local é ativado por um LPG (Local Peering Gateway), que serve como ponto de conexão entre VCNs. Configure um LPG em cada VCN e estabeleça um relacionamento de pareamento para permitir que instâncias, balanceadores de carga e outros recursos em uma VCN acessem com segurança recursos em outra VCN dentro da mesma região.

  • Gateway de roteamento dinâmico (DRG)

    O DRG é um roteador virtual que fornece um caminho para tráfego de rede privada entre VCNs na mesma região, entre uma VCN e uma rede fora da região, como uma VCN em outra região do OCI, uma rede on-premises ou uma rede em outro provedor de nuvem.

  • Pareamento remoto

    O pareamento remoto permite comunicação privada entre recursos em diferentes VCNs, que podem estar localizadas nas mesmas regiões da OCI ou em regiões diferentes. Cada VCN usa seu próprio DRG (Dynamic Routing Gateway) para pareamento remoto. Os DRGs roteiam com segurança o tráfego entre as VCNs pelo backbone privado da OCI, permitindo que os recursos se comuniquem usando endereços IP privados sem rotear o tráfego pela internet ou por meio de redes on-premises. O pareamento remoto elimina a necessidade de gateways de internet ou endereços IP públicos para instâncias que precisam se conectar entre regiões.

  • Oracle Exadata Database Service on Dedicated Infrastructure

    O Oracle Exadata Database Service on Dedicated Infrastructure permite que você aproveite o poder do Exadata na nuvem. O Oracle Exadata Database Service oferece recursos comprovados do Oracle AI Database em infraestrutura otimizada e desenvolvida especificamente para o Oracle Exadata na nuvem pública. A automação integrada da nuvem, o dimensionamento elástico de recursos, a segurança e o desempenho rápido para todas as cargas de trabalho do Oracle AI Database ajudam a simplificar o gerenciamento e reduzir custos.

  • Oracle Data Guard

    O Oracle Data Guard e o Active Data Guard fornecem um conjunto abrangente de serviços que criam, mantêm, gerenciam e monitoram um ou mais bancos de dados stand-by e que permitem que os bancos de dados Oracle de produção permaneçam disponíveis sem interrupção. O Oracle Data Guard mantém esses bancos de dados stand-by como cópias do banco de dados de produção usando a replicação na memória. Se o banco de dados de produção ficar indisponível devido a uma interrupção planejada ou não planejada, o Oracle Data Guard poderá alternar qualquer banco de dados stand-by para a atribuição de produção, minimizando o tempo de inatividade associado à interrupção. O Oracle Active Data Guard fornece a capacidade adicional de descarregar cargas de trabalho de leitura máxima para bancos de dados stand-by e também fornece recursos avançados de proteção de dados.

Recomendações

Use as recomendações a seguir como ponto de partida ao executar a recuperação de desastres do Oracle Exadata Database Service no Oracle Database@AWS. Seus requisitos podem ser diferentes da arquitetura descrita aqui.
  • Use o Active Data Guard para uma prevenção abrangente de corrupção de dados com reparo automático em blocos, upgrades e migrações on-line e para descarregar a carga de trabalho para o stand-by com escalabilidade horizontal de leitura.
  • Ative o serviço Application Continuity para mascarar interrupções do banco de dados durante eventos planejados e não planejados dos usuários finais.
  • Configure backups automáticos para o Oracle Database Autonomous Recovery Service no OCI. Embora os dados sejam protegidos pelo Oracle Data Guard, minimize a carga de trabalho de backup no banco de dados implementando a estratégia de backup incremental-forever que elimina backups completos semanais. Como alternativa, use o Amazon Simple Storage Service para backups automáticos.
  • Execute backups do stand-by para obter a replicação de backup entre regiões.
  • Use o OCI Full Stack DR para orquestrar operações de switchover e failover do banco de dados.
  • Armazene as chaves de Criptografia Transparente de Dados (TDE) do banco de dados no OCI Vault com chaves gerenciadas pelo cliente.

Considerações

Ao executar a recuperação de desastres local e regional do Oracle Exadata Database Service no Oracle Database@AWS, considere o seguinte:

  • Quando os clusters de VMs do Exadata são criados no site filho do Oracle Database@AWS, cada cluster de VMs do Exadata é provisionado em sua própria VCN do OCI. Faça pareamento das VCNs e evite a sobreposição de CIDRs e garanta que os bancos de dados se comuniquem entre si para que o Data Guard possa enviar dados redo.
  • A latência entre regiões geralmente é muito alta para transporte síncrono em aplicativos de missão crítica. Portanto, use a replicação ASYNC do Data Guard entre regiões. Adicione o Active Data Guard Far Sync para garantir zero perda de dados entre regiões.
  • Configure a OCI como a rede preferida para melhor desempenho, menor latência, maior taxa de transferência e custo reduzido; os primeiros 10 TB/mês de saída de dados são gratuitos em todas as regiões.
  • Você pode criar até seis bancos de dados stand-by por principal usando ferramentas de nuvem.

Sobre Serviços e Atribuições Obrigatórios

Esta solução requer os seguintes serviços e funções:

  • Oracle Cloud Infrastructure Networking
  • Oracle Exadata Database Service

Essas são as funções necessárias para cada serviço.

Nome do Serviço: Função Obrigatório para...
Oracle Exadata Database Service: manage database-family Gerenciar o banco de dados, incluindo a adição e operação de implantações do Active Data Guard
Rede da OCI: manage vcn-family Gerencie os componentes de rede, incluindo VCNs, sub-redes, regras de segurança e pareamento de VCN

Consulte Produtos, Soluções e Serviços Oracle para obter o que você precisa.