Saiba mais sobre a Implantação do Active Data Guard Far Sync

O Oracle Database@Azure permite que você execute seus bancos de dados Oracle de missão crítica usando o Oracle Exadata Database Service on Dedicated Infrastructure no data center do Microsoft Azure.

Aproveite a alta disponibilidade, o desempenho e a escalabilidade integrados do Oracle Exadata Database Service e do Oracle Real Application Clusters (Oracle RAC), beneficiando-se da baixa latência para aplicativos do Azure.

A extensão da arquitetura com um banco de dados stand-by hospedado em outro cluster de máquina virtual (VM) do Exadata fornece proteção de DR (recuperação de desastre) contra falhas de banco de dados e cluster. Colocar o stand-by em outra zona de disponibilidade (AZ) do Azure aprimora ainda mais a solução, garantindo proteção contra uma falha inteira da AZ. Para uma recuperação de desastre regional abrangente, o banco de dados stand-by deve ser implantado em uma região separada.

O Oracle Data Guard permite transportar de forma síncrona o redo para o banco de dados stand-by para garantir zero perda de dados. No entanto, quando o banco de dados stand-by está geograficamente muito distante, a latência aumenta, afetando o tempo de resposta do commit e o throughput da transação no banco de dados principal. A Far Sync do Active Data Guard pode garantir zero perda de dados a qualquer distância, com impacto mínimo no desempenho do banco de dados principal. O Far Sync, uma instância leve, fornece proteção de redo síncrona e failover de zero perda de dados sem exigir um banco de dados stand-by local síncrono.

Arquitetura

Essa arquitetura de referência mostra uma recuperação de desastre entre regiões com o Active Data Guard.

Duas instâncias de far sync do Active Data Guard são criadas nas regiões do OCI (Oracle Cloud Infrastructure) correspondentes. O banco de dados principal em Toronto envia os dados de redo no modo SYNC para a instância de far SYNC local em Toronto, que encaminha os dados de redo no modo ASYNC para o banco de dados stand-by na região remota de Sydney.

Depois que um switch de atribuição e o banco de dados em Sydney se torna o principal, ele envia os dados de redo no modo SYNC para sua instância de far SYNC local em Sydney, que encaminha os dados de redo no modo ASYNC para o banco de dados stand-by na região remota de Toronto.

O Oracle Exadata Database Service na rede do Oracle Database@Azure é 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 apenas um DRG é permitido 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 aplicativo é replicado entre regiões para acessar o banco de dados na mesma região e obter a menor latência e o melhor desempenho.

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



active-data-guard-far-sync-dba-oracle.zip

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.

  • Azure VNet

    A Rede Virtual do Microsoft 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 (VM) do Azure, se comuniquem com segurança entre si, com a Internet e com as redes locais.

  • Sub-rede Delegada do Azure

    A delegação de sub-rede é a capacidade da Microsoft de injetar um serviço gerenciado, especificamente um serviço de plataforma como serviço (PaaS), diretamente na sua rede virtual. Isso permite designar ou delegar uma sub-rede para ser um home de um serviço gerenciado externo dentro da sua rede virtual, de forma que o serviço externo atue como um recurso de rede virtual, mesmo que seja um serviço PaaS externo.

  • 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 Oracle Cloud Infrastructure fornece os seguintes componentes:

  • Região

    Região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominada 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).

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

    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.

  • Lista de segurança

    Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que deve ser permitido dentro e fora da sub-rede.

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

  • LPG (Local peering gateway)

    Um LPG 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.

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

  • Far Sync do Data Guard Ativo

    O Oracle Active Data Guard Far Sync é uma instância leve do banco de dados Oracle que recebe dados de redo de forma síncrona do banco de dados principal e os encaminha de forma assíncrona para um ou mais bancos de dados stand-by. Ele garante zero perda de dados a qualquer distância, com impacto mínimo no desempenho do banco de dados principal e sem exigir um banco de dados stand-by síncrono local.

  • 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. Seus requisitos podem ser diferentes da arquitetura descrita aqui.
  • A instância de far sync deve estar longe o suficiente do banco de dados principal para garantir que não possa ser afetada pela mesma falha ou desastre, mas perto o suficiente para minimizar a latência da rede.
  • Crie duas instâncias de far sync por região para alta disponibilidade. Sem uma instância alternativa de far sync ou se todas as instâncias de far sync na região principal estiverem indisponíveis, o transporte de redo do Oracle Data Guard será enviado diretamente para o banco de dados stand-by no modo ASYNC, afetando a proteção sem perda de dados e, dependendo da configuração e da distância, pode resultar em atraso no transporte afetando ainda mais o RPO.
  • Como o desempenho de armazenamento da instância de far sync é crítico, a capacidade de IOPS deve ser adequada para suportar a carga de trabalho. O armazenamento da instância de far sync deve ter um desempenho de IOPS igual ou melhor que o armazenamento de redo logs on-line do banco de dados principal.
  • Use o Oracle Data Guard entre regiões para os bancos de dados provisionados no cluster de VMs do Exadata no Oracle Database@Azure usando uma rede Gerenciada pelo OCI.

Considerações sobre Recuperação de Desastres entre Regiões

Ao executar a recuperação de desastre entre regiões para o Oracle Exadata Database Service no Oracle Database@Azure, considere o seguinte.

  • A Oracle Cloud Infrastructure é a rede preferida para obter melhor desempenho, medido por latência e taxa de transferência e para reduzir custos, pois os primeiros 10 TB/mês são gratuitos.
  • Far sync é uma instância leve. No entanto, o desempenho do disco é crítico, pois o far sync grava o redo recebido no disco antes de confirmar novamente para o principal, o que pode afetar o desempenho do aplicativo.
  • O desempenho da rede da instância de far sync é fundamental para cargas de trabalho pesadas.
  • Com vários bancos de dados stand-by e instâncias de far sync, a configuração pode ficar mais complicada. Use a propriedade RedoRoutes do broker do Active Data Guard para simplificar a definição de como o redo é transportado para os vários destinos.
  • O uso da far sync requer a opção Active Data Guard.