Implemente a recuperação de desastres com stand-by multirregional no Oracle Database@Azure

Garantir a continuidade ininterrupta dos negócios é fundamental para o sucesso ao projetar aplicativos. Alcançar isso requer uma estratégia robusta de recuperação de desastres projetada para restaurar rapidamente a funcionalidade em caso de interrupções.

Por anos, as organizações confiaram no Oracle Exadata Database Service, que é as principais tecnologias 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@Azure traz o mesmo desempenho, conjunto de recursos e paridade de preços líderes do setor que o Exadata na OCI. Ele aproveita as zonas de disponibilidade (AZs) e as regiões do Microsoft Azure para fornecer baixa latência aos aplicativos do Azure, 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.

Arquitetura

Essa arquitetura mostra o Oracle Exadata Database Service on Dedicated Infrastructure no Oracle Database@Azure em uma topologia de recuperação de desastres com várias regiões usando dois bancos de dados stand-by remotos.

O diagrama a seguir ilustra essa arquitetura de referência.


Veja a seguir a descrição da multi-região-standby-dr-db-azure-arch.png
Descrição da ilustração multi-region-standby-dr-db-azure-arch.png

multi-região-standby-dr-db-azure-arch-oracle.zip

O Oracle Database é executado em um cluster de máquina virtual (VM) do Exadata na região Principal. Para proteção de dados e recuperação de desastres, o Oracle Active Data Guard replica os dados para dois bancos de dados stand-by em execução nos clusters de VMs do Exadata em duas regiões Stand-by diferentes. Uma configuração de banco de dados stand-by remoto garante a proteção de dados contra falhas regionais e também pode ser usada para descarregar o processamento de consulta somente leitura. Replique o aplicativo entre regiões para evitar maior latência depois de fazer switchover para um banco de dados Stand-by.

Você pode rotear o tráfego do Active Data Guard por meio da rede do Azure. No entanto, essa arquitetura se concentra no tráfego de rede do Active Data Guard por meio da rede da OCI para otimizar o throughput e a latência da rede.

A rede Oracle Exadata Database Service on Dedicated Infrastructure no Oracle Database@Azure é conectada à sub-rede 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 Redes Virtuais na Nuvem (VCNs) em diferentes regiões. Como apenas um DRG é permitido por VCN no OCI, uma segunda VCN atuando como uma VCN de Hub com seu próprio DRG é necessária para conectar as VCNs principal e stand-by em cada região. Nesta arquitetura:

  • O cluster de VMs principal do Exadata é implantado em Region 1 em VCN1 com CIDR 10.10.0.0/16.
  • A VCN hub no Region 1 principal é HubVCN1 com CIDR 10.11.0.0/16.
  • O primeiro cluster de VMs do Exadata stand-by é implantado em Region 2 em VCN2 com CIDR 10.20.0.0/16.
  • A VCN hub na primeira região stand-by é HubVCN2 com CIDR 10.22.0.0/16.
  • O segundo cluster de VMs do Exadata stand-by é implantado em Region 3 em VCN3 com CIDR 10.30.0.0/16.
  • A VCN hub na segunda região stand-by é HubVCN3 com CIDR 10.33.0.0/16.

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. As VCNs no site filho do OCI são criadas após os clusters de VMs do Oracle Exadata Database Service on Dedicated Infrastructure no Oracle Database@Azure serem criados para os bancos de dados Principal e Stand-by.

O Microsoft Azure fornece os seguintes componentes:

  • Região do Azure

    Uma região do Azure é uma área geográfica na qual um ou mais data centers físicos do Azure, chamados zonas de disponibilidade, residem. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).

    As regiões do Azure e da OCI são áreas geográficas localizadas. Para o Oracle Database@Azure, uma região do Azure é conectada a uma região da OCI, com zonas de disponibilidade (AZs) no Azure conectadas a domínios de disponibilidade (ADs) na OCI. Os pares de regiões do Azure e OCI são selecionados para minimizar a distância e a latência.

  • Zona de disponibilidade do Azure

    As zonas de disponibilidade do Azure são locais fisicamente separados dentro de uma região do Azure, projetados para garantir alta disponibilidade e resiliência, fornecendo energia, refrigeração e rede independentes.

  • Rede Virtual do Azure (VNet)

    A Rede Virtual do Azure (VNet) é o bloco de construção fundamental da sua rede privada no Azure. O VNet permite que muitos tipos de recursos do Azure, como máquinas virtuais (VMs) do Azure, se comuniquem com segurança entre si, com a Internet e com as redes locais.

  • Sub-rede delegada do Azure

    Uma sub-rede delegada permite inserir um serviço gerenciado, especificamente um serviço de plataforma como serviço (PaaS), diretamente na sua rede virtual como recurso. Você tem gerenciamento de integração total de serviços PaaS externos em suas redes virtuais.

  • Placa de Interface de Rede Virtual (VNIC) do Azure

    Os serviços nos data centers do Azure têm placas físicas de interface de rede (NICs). As instâncias de máquina virtual se comunicam usando NICs virtuais (VNICs) associadas às NICs físicas. Cada instância tem uma VNIC principal que é criada e anexada automaticamente durante a inicialização e está disponível durante a vida útil da instância.

O OCI fornece os seguintes componentes:

  • Região

    Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, hospedando domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).

  • Domínios de disponibilidade

    Domínios de disponibilidade são data centers stand-alone e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que oferece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou refrigeração ou a rede interna do domínio de disponibilidade. Portanto, uma falha em um domínio de disponibilidade não deve afetar os outros domínios de disponibilidade na região.

  • Rede virtual na nuvem (VCN) e sub-redes

    Uma VCN é uma rede personalizável definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs oferecem controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após a criação da 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.

  • Pareamento local

    O pareamento local permite que você pareie uma VCN com outra VCN na mesma região. Pareamento significa que as VCNs se comunicam usando endereços IP privados, sem o tráfego que passa pela internet ou que é roteado pela sua rede local.

  • Gateway de roteamento dinâmico (DRG)

    O DRG é um roteador virtual que fornece um caminho para o 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 Oracle Cloud Infrastructure, uma rede local ou uma rede em outro provedor de nuvem.

  • Armazenamento de objetos

    O serviço OCI Object Storage oferece acesso a grandes quantidades de dados estruturados e não estruturados de qualquer tipo de conteúdo, incluindo backups de bancos de dados, dados de análise e conteúdo avançado, como imagens e vídeos. Você pode armazenar dados de forma segura e protegida diretamente da internet ou de dentro da plataforma da nuvem. Você pode dimensionar o armazenamento sem prejudicar o desempenho ou a confiabilidade do serviço.

    Use o armazenamento padrão para armazenamento de acesso frequente que você precisa para acessar de forma rápida, imediata e com frequência. Use o armazenamento de arquivos compactados para armazenamento "frio" que você mantém por longos períodos de tempo e raramente acessa.

  • Data Guard

    O Oracle Data Guard e o Oracle Active Data Guard fornecem um conjunto abrangente de serviços que criam, mantêm, gerenciam e monitoram um ou mais bancos de dados standby e permitem a manutenção de bancos de dados Oracle de produção 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 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 principalmente para bancos de dados stand-by e também fornece recursos avançados de proteção de dados.

  • Oracle Database Autonomous Recovery Service

    O Oracle Database Autonomous Recovery Service é um serviço do Oracle Cloud que protege bancos de dados Oracle. A automação de backup e os recursos aprimorados de proteção de dados para bancos de dados da OCI permitem que você descarregue todos os requisitos de processamento e armazenamento de backup para o Oracle Database Autonomous Recovery Service, o que reduz os custos de infraestrutura de backup e a sobrecarga de administração manual.

  • 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 Database em uma infraestrutura otimizada e específica do Oracle Exadata na nuvem pública. A automação da nuvem integrada, o dimensionamento elástico de recursos, a segurança e o desempenho rápido para todas as cargas de trabalho do Oracle Database ajudam a simplificar o gerenciamento e reduzir custos.

  • Oracle Database@Azure

    O Oracle Database@Azure é o serviço Oracle Database (Oracle Exadata Database Service on Dedicated Infrastructure e Oracle Autonomous Database Serverless) executado na Oracle Cloud Infrastructure (OCI), implantado nos data centers do Microsoft Azure. O serviço oferece recursos e paridade de preços com a OCI. Compre o serviço no Azure Marketplace.

    O Oracle Database@Azure integra as tecnologias Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC) e Oracle Data Guard à plataforma Azure. Os usuários gerenciam o serviço na console do Azure e com ferramentas de automação do Azure. O serviço é implantado na Rede Virtual do Azure (VNet) e integrado ao sistema de gerenciamento de identidade e acesso do Azure. As métricas genéricas e os logs de auditoria do OCI e do Oracle Database estão disponíveis nativamente no Azure. O serviço exige que os usuários tenham uma assinatura do Azure e uma tenancy do OCI.

    O Autonomous Database foi desenvolvido na infraestrutura do Oracle Exadata, é autogerenciado, autoprotegido e autorreparável, ajudando a eliminar o gerenciamento manual do banco de dados e erros humanos. O Autonomous Database permite o desenvolvimento de aplicativos escaláveis com tecnologia de IA com qualquer dado usando recursos integrados de IA usando sua escolha de modelo de linguagem grande (LLM) e local de implantação.

    O Oracle Exadata Database Service e o Oracle Autonomous Database Serverless são facilmente provisionados por meio do Portal nativo do Azure, permitindo o acesso ao ecossistema mais amplo do Azure.

Recomendações

Use as recomendações a seguir como ponto de partida ao executar a recuperação de desastre do Oracle Exadata Database Service on Dedicated Infrastructure no Oracle Database@Azure. Seus requisitos podem ser diferentes da arquitetura descrita aqui.
  • Use o Active Data Guard para prevenção abrangente de corrupção de dados com reparo automático de blocos, upgrades e migrações online e carga de trabalho de descarregamento para stand-by com expansão de leitura na maioria das vezes.
  • Ative a Continuidade do Aplicativo para mascarar interrupções do banco de dados durante eventos planejados e não planejados dos usuários finais e garantir aplicativos ininterruptos.
  • Configure o backup automático no Oracle Database Autonomous Recovery Service (no Azure ou OCI), mesmo que os dados sejam protegidos pelo Oracle Data Guard para minimizar a carga de trabalho de backup no banco de dados, implementando a estratégia de backup incremental para sempre que elimina backups completos semanais. Como alternativa, os clientes podem usar o OCI Object Storage para backups automáticos.
  • Ative backups do stand-by para obter replicação de backup entre regiões.
  • Use o OCI Full Stack DR para orquestrar operações de switchover e failover de banco de dados.
  • Use o OCI Vault para armazenar as chaves de Criptografia Transparente de Dados (TDE) do banco de dados usando chaves gerenciadas pelo cliente.

Considerações

Ao executar a recuperação de desastre multirregional para o Oracle Exadata Database Service on Dedicated Infrastructure no Oracle Database@Azure, considere o seguinte.

  • Quando os clusters de VMs do Exadata são criados no site filho do Oracle Database@Azure, cada cluster de VMs é criado em sua própria VCN do OCI. O Oracle Data Guard exige que os bancos de dados se comuniquem entre si para enviar dados redo. Associe as VCNs para ativar essa comunicação. Portanto, as VCNs do cluster de VMs do Exadata não devem compartilhar faixas CIDR de IPs sobrepostas.
  • A preparação para um cenário de desastre requer uma abordagem abrangente que considere diferentes requisitos de negócios e arquiteturas de disponibilidade e que englobe essas considerações em um plano acionável, de alta disponibilidade e de recuperação de desastres. O cenário descrito aqui fornece diretrizes para ajudar a selecionar a abordagem que melhor se adapta à implantação do seu aplicativo usando um failover simples, mas eficaz, para a configuração de recuperação de desastres em seus ambientes OCI e Microsoft Azure.
  • A OCI é a rede preferida para obter melhor desempenho, medido por latência e taxa de transferência, e para obter custo reduzido, incluindo a primeira saída de 10 TB/mês gratuitamente.
  • Você pode criar até seis bancos de dados stand-by para um banco de dados principal por meio do Cloud Tooling.
  • Não há suporte para a criação de um banco de dados stand-by associado a outro banco de dados stand-by (stand-by em cascata) usando o Conjunto de Ferramentas da Nuvem.

Implante

Siga estas etapas para configurar a comunicação de rede entre regiões mostradas no diagrama de arquitetura:

Siga estas etapas para configurar a região Principal:

  1. Adicione as regras de entrada a seguir à Lista de Segurança da sub-rede do cliente VCN1 para permitir o tráfego de entrada de VCN2 e VCN3.
    Sem Informações de Estado Origem Protocolo IP Faixa de Portas de Origem Faixa de Portas de Destino Permite Descrição
    No 10.20.0.0/16 TCP 1521 1521 Tráfego TCP nas portas: 1521 Permitir entrada de VCN2
    No 10.30.0.0/16 TCP 1521 1521 Tráfego TCP nas portas: 1521 Permitir entrada de VCN3
  2. Crie a Rede Virtual na Nuvem HubVCN1 com CIDR 10.11.0.0/16.
  3. Crie o LPG (Local Peering Gateway) HubLPG1 na Rede Virtual na Nuvem HubVCN1.
  4. Crie o LPG (Local Peering Gateway) LPG1R na Rede Virtual na Nuvem VCN1.
  5. Estabeleça a conexão de pareamento local entre LPG1R e HubLPG1.
  6. Adicione regras de roteamento à tabela de roteamento da sub-rede do cliente VCN1 para encaminhar o tráfego direcionado para VCN2 e VCN3 para LPG1R.
    Destino Tipo de Alvo Target Tipo de Rota da Rota Descrição
    10.20.0.0/16 LPG (Local Peering Gateway) LPG1R Estática Tráfego para VCN2
    10.30.0.0/16 LPG (Local Peering Gateway) LPG1R Estática Tráfego para VCN3
  7. Crie a Tabela de Roteamento HubLPG1rt em HubVCN1.
  8. Associe a Tabela de Roteamento HubLPG1rt ao LPG (Local Peering Gateway) HubLPG1.
  9. Crie o Gateway de Roteamento Dinâmico DRG1.
  10. Crie a Tabela de Roteamento DRG1rt em HubVCN1.
  11. Adicione uma regra de roteamento à Tabela de Roteamento DRG1rt para encaminhar o tráfego direcionado para VCN1 para HubLPG1.
    Destino Tipo de Alvo Target Tipo de Rota da Rota Descrição
    10.10.0.0/16 LPG (Local Peering Gateway) HubLPG1 Estática Tráfego para VCN1
  12. Para anexar DRG1 a HubVCN1:
    1. Selecione Tabela de Roteamento de Drg Gerada Automaticamente para anexos de VCN.
    2. Selecione a tabela de roteamento existente DRG1rt.
    3. Selecione Blocos CIDR da VCN.
  13. Crie duas Conexões de Pareamento Remoto em DRG1, denominadas RPC1a e RPC1b.
  14. Adicione duas regras de roteamento a HubLPG1rt para encaminhar o tráfego direcionado para VCN2 e VCN3 a DRG1.
    Destino Tipo de Alvo Target Tipo de Rota da Rota Descrição
    10.20.0.0/16 Gateway de Roteamento Dinâmico DRG1 Estática Tráfego para VCN2
    10.30.0.0/16 Gateway de Roteamento Dinâmico DRG1 Estática Tráfego para VCN3

Siga estas etapas para criar a primeira região Stand-by (Região 2):

  1. Adicione as regras de entrada a seguir à Lista de Segurança da sub-rede do cliente VCN2 para permitir o tráfego de entrada de VCN1 e VCN3.
    Sem Informações de Estado Origem Protocolo IP Faixa de Portas de Origem Faixa de Portas de Destino Permite Descrição
    No 10.10.0.0/16 TCP 1521 1521 Tráfego TCP nas portas: 1521 Permitir entrada de VCN1
    No 10.30.0.0/16 TCP 1521 1521 Tráfego TCP nas portas: 1521 Permitir entrada de VCN3
  2. Crie a Rede Virtual na Nuvem HubVCN2 com o CIDR 10.22.0.0/16.
  3. Crie o LPG (Local Peering Gateway) HubLPG2 na Rede Virtual na Nuvem HubVCN2.
  4. Crie o LPG (Local Peering Gateway) LPG2R na Rede Virtual na Nuvem VCN2.
  5. Estabeleça a conexão de pareamento local entre LPG2R e HubLPG2.
  6. Adicione regras de roteamento à Tabela de Roteamento da sub-rede do cliente VCN2 para encaminhar o tráfego direcionado para VCN1 e VCN3 para LPG2R.
    Destino Tipo de Alvo Target Tipo de Rota da Rota Descrição
    10.10.0.0/16 LPG (Local Peering Gateway) LPG2R Estática Tráfego para VCN1
    10.30.0.0/16 LPG (Local Peering Gateway) LPG2R Estática Tráfego para VCN3
  7. Crie a Tabela de Roteamento HubLPG2rt em HubVCN2.
  8. Associe a Tabela de Roteamento HubLPG2rt ao LPG (Local Peering Gateway) HubLPG2.
  9. Crie o Gateway de Roteamento Dinâmico DRG2.
  10. Crie a Tabela de Roteamento DRG2rt em HubVCN2.
  11. Adicione uma regra de roteamento a DRG2rt para encaminhar o tráfego direcionado para VCN2 para HubLPG2.
    Destino Tipo de Alvo Target Tipo de Rota da Rota Descrição
    10.20.0.0/16 LPG (Local Peering Gateway) HubLPG2 Estática Tráfego para VCN2
  12. Para anexar DRG1 a HubVCN2:
    1. Selecione Tabela de Roteamento de Drg Gerada Automaticamente para anexos de VCN.
    2. Selecione a tabela de roteamento existente DRG2rt.
    3. Selecione Blocos CIDR da VCN.
  13. Crie duas Conexões de Pareamento Remoto em DRG2, denominadas RPC2a e RPC2c.
  14. Estabeleça uma conexão de pareamento remoto entre RPC1a (região 1) e RPC2a (região 2).
  15. Adicione duas regras de roteamento a HubLPG2rt para encaminhar o tráfego direcionado para VCN1 e VCN3 a DRG2.
    Destino Tipo de Alvo Target Tipo de Rota da Rota Descrição
    10.10.0.0/16 Gateway de Roteamento Dinâmico DRG2 Estática Tráfego para VCN1
    10.30.0.0/16 Gateway de Roteamento Dinâmico DRG2 Estática Tráfego para VCN3

Siga estas etapas para criar a segunda região Stand-by (Região 3):

  1. Adicione as regras de entrada a seguir à Lista de Segurança da sub-rede do cliente VCN3 para permitir o tráfego de entrada de VCN1 e VCN2.
    Sem Informações de Estado Origem Protocolo IP Faixa de Portas de Origem Faixa de Portas de Destino Permite Descrição
    No 10.10.0.0/16 TCP 1521 1521 Tráfego TCP nas portas: 1521 Permitir entrada de VCN1
    No 10.20.0.0/16 TCP 1521 1521 Tráfego TCP nas portas: 1521 Permitir entrada de VCN2
  2. Crie a Rede Virtual na Nuvem HubVCN3 com CIDR 10.33.0.0/16.
  3. Crie o LPG (Local Peering Gateway) HubLPG3 na Rede Virtual na Nuvem HubVCN3.
  4. Crie o LPG (Local Peering Gateway) LPG3R na Rede Virtual na Nuvem VCN3.
  5. Estabeleça a conexão de pareamento local entre LPG3R e HubLPG3.
  6. Adicione regras de roteamento à Tabela de Roteamento da sub-rede do cliente VCN3 para encaminhar o tráfego direcionado para VCN1 e VCN2 para LPG3R.
    Destino Tipo de Alvo Target Tipo de Rota da Rota Descrição
    10.10.0.0/16 LPG (Local Peering Gateway) LPG3R Estática Tráfego para VCN1
    10.20.0.0/16 LPG (Local Peering Gateway) LPG3R Estática Tráfego para VCN2
  7. Crie a Tabela de Roteamento HubLPG3rt em HubVCN3.
  8. Associe a Tabela de Roteamento HubLPG3rt ao LPG (Local Peering Gateway) HubLPG3.
  9. Crie o Gateway de Roteamento Dinâmico DRG3.
  10. Crie a Tabela de Roteamento DRG3rt em HubVCN3.
  11. Adicione uma regra de roteamento a DRG3rt para encaminhar o tráfego direcionado para VCN3 para HubLPG3.
    Destino Tipo de Alvo Target Tipo de Rota da Rota Descrição
    10.30.0.0/16 LPG (Local Peering Gateway) HubLPG3 Estática Tráfego para VCN3
  12. Para anexar DRG1 a HubVCN3:
    1. Selecione Tabela de Roteamento de Drg Gerada Automaticamente para anexos de VCN.
    2. Selecione a tabela de roteamento existente DRG3rt.
    3. Selecione Blocos CIDR da VCN.
  13. Crie duas Conexões de Pareamento Remoto em DRG3, denominadas RPC3b e RPC3c.
  14. Estabeleça uma conexão de pareamento remoto entre RPC1b (região 1) e RPC3b (região 3).
  15. Estabeleça uma conexão de pareamento remoto entre RPC2c (região 2) e RPC3c (região 3).
  16. Adicione duas regras de roteamento a HubLPG3rt para encaminhar o tráfego direcionado para VCN1 e VCN2 a DRG3.
    Destino Tipo de Alvo Target Tipo de Rota da Rota Descrição
    10.10.0.0/16 Gateway de Roteamento Dinâmico DRG3 Estática Tráfego para VCN1
    10.20.0.0/16 Gateway de Roteamento Dinâmico DRG3 Estática Tráfego para VCN2

Explorar Mais

Saiba mais sobre o Oracle Database@Azure e o Oracle Data Guard.

Revise estes recursos adicionais:

Confirmações

  • Autors: Sinan Petrus Toma, Sebastian Solbach, Julien Silverston
  • Colaborador: Sreya Dutta