Saiba Mais sobre o Failover de Inicialização Rápida da Oracle Data Guard
Você obtém alta disponibilidade, desempenho e escalabilidade integrados do Oracle Exadata Database Machine e do Oracle Real Application Clusters (Oracle RAC), com baixa latência para aplicativos baseados no Azure.
A extensão da solução com um banco de dados stand-by em outra zona ou região de disponibilidade fornece proteção de dados e recuperação de desastres para interrupções regionais e de data center.
O Data Guard transporta dados de forma síncrona para o banco de dados stand-by para garantir zero perda de dados. O failover de inicialização rápida permite que o broker faça failover automaticamente do banco de dados stand-by de destino para a atribuição principal sem etapas de failover manual.
Os sites do Observer monitoram o ambiente de failover de inicialização rápida. Um observador é um componente separado do lado do cliente que é executado em uma VM do Compute diferente dos bancos de dados principal e stand-by e monitora a disponibilidade do banco de dados principal.
O failover de inicialização rápida fornece failover mais rápido com um RTO (Recovery Time Objective) configurável, com zero perda de dados no modo síncrono ou um RPO (Recovery Point Objective) vinculado no modo assíncrono.
Neste manual de soluções, você aprende a configurar e implantar o Data Guard e ativar o failover de inicialização rápida nas zonas de disponibilidade do Oracle AI Database@Azure usando o Oracle Exadata Database Service on Exascale Infrastructure. A mesma solução se aplica ao Oracle Exadata Database Service on Dedicated Infrastructure.
Antes de Começar
Antes de começar, certifique-se de que:
- Os clusters de VMs do Exascale são implantados em diferentes zonas de disponibilidade do Azure.
- O Oracle AI Database 26ai é criado na zona de disponibilidade principal.
- As faixas de CIDR de IP de rede dos clusters de VMs do Exascale principal e stand-by não se sobrepõem.
Revise as seguintes soluções:
Em seguida, você deve provisionar uma VM de computação no Azure para hospedar o observer, de preferência em uma zona de disponibilidade diferente dos bancos de dados principal e stand-by. O observer pode ser executado em uma VM leve à medida que opera como um cliente Oracle que se conecta aos bancos de dados principal e stand-by.
Arquitetura
A arquitetura a seguir mostra um Data Guard entre zonas com o observador em execução em outra zona de disponibilidade:
cross-zones-dg-oracledb-azure-oracle.zip
Você pode rotear o tráfego do Data Guard pela rede do Oracle Cloud Infrastructure (OCI) ou do Azure. Essa arquitetura direciona o tráfego de rede do Data Guard por meio da rede do Azure para manter todos os dados dentro da plataforma do Azure. As VCNs no site da OCI são criadas após os clusters de VMs do Oracle Exadata Database Service on Exascale Infrastructure no Oracle AI Database@Azure serem criados para os bancos de dados principal e stand-by.
Nesta arquitetura:
- O Cluster de VMs do Exascale principal é implantado na zona de disponibilidade principal em
VNet1com o CIDR10.10.0.0/16e a sub-rede delegada CIDR10.10.1.0/24. - O Cluster de VMs do Exascale stand-by é implantado na zona de disponibilidade stand-by em
VNet2com o CIDR10.20.0.0/16e o CIDR da sub-rede delegada10.20.1.0/24. - O observer é implantado em
VNet3com o CIDR10.30.0.0/16e o CIDR da sub-rede10.30.1.0/24. - O
VNet1é pareado com oVNet2para permitir que o tráfego do Data Guard flua entre os bancos de dados principal e standby. VNet3é pareado comVNet1eVNet2para permitir que o observer se conecte aos dois bancos de dados.
Essa arquitetura tem 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 de zonas de disponibilidade, residem. Regiões são independentes de outras regiões, e grandes distâncias podem separá-las (em países ou mesmo continentes).
As regiões do Azure e da OCI são áreas geográficas localizadas. Para o Oracle AI 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 da OCI são selecionados para minimizar a distância e a latência.
- Domínio de Disponibilidade do Azure
O Domínio de Disponibilidade do Azure, ou conjunto de disponibilidade, é um agrupamento lógico de máquinas virtuais.
- Rede Virtual do Azure e sub-rede
O Azure Virtual Network (VNet) permite que você implante recursos do Azure em uma rede privada isolada logicamente que você define. Essa rede se assemelha a uma rede on-premises tradicional, enquanto se beneficia da infraestrutura de nuvem escalável e altamente disponível do Azure. Depois de criar uma VNet, você pode segmentá-la em uma ou mais sub-redes para organizar e controlar o tráfego de rede para suas cargas de trabalho.
- Sub-rede delegada do Azure
Uma sub-rede delegada é uma sub-rede VNet reservada e delegada ao serviço Oracle AI Database@Azure, permitindo que a Oracle implante e gerencie os recursos de banco de dados necessários dentro do seu espaço IP de rede privada.
- VNIC (Interface Card) da Rede Virtual do Azure
Os serviços nos data centers do Azure têm placas de interface de rede (NICs) físicas. 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 o tempo de vida da instância.
- VM de Computação do Microsoft Azure
As VMs (Máquinas Virtuais) do Azure fornecem recursos de computação escaláveis e sob demanda que você pode usar como um servidor físico ou um desktop. Use VMs quando precisar de controle total sobre o sistema operacional e o ambiente de software.
As VMs removem a necessidade de gerenciar o hardware físico, mas você ainda configura, aplica patches e gerencia o software em execução nelas. Eles suportam cargas de trabalho personalizadas e legadas.
- Região da OCI
Uma região do OCI é uma área geográfica localizada que contém um ou mais data centers, hospedando domínios de disponibilidade. Regiões são independentes de outras regiões, e grandes distâncias podem separá-las (em países ou mesmo continentes).
- Domínio 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 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.
- 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.
- 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.
- Oracle AI Database@Azure
O Oracle AI Database@Azure é o serviço do Oracle Database (Oracle Exadata Database Service on Dedicated Infrastructure e Oracle Autonomous AI Database Serverless) em execução na OCI, implementado 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 AI 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 no console do Azure e com as 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 da OCI e do Oracle AI 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 AI Database foi desenvolvido na infraestrutura do Oracle Exadata, é autogerenciado, autoprotegido e autorreparável, ajudando a eliminar o gerenciamento manual do banco de dados e os erros humanos. O Autonomous AI Database permite o desenvolvimento de aplicativos escaláveis com tecnologia de IA com qualquer dado usando recursos de IA integrados usando sua escolha de modelo de linguagem grande (LLM) e local de implementação.
O Oracle Exadata Database Service e o Oracle Autonomous AI Database Serverless são facilmente provisionados por meio do Portal nativo do Azure, permitindo o acesso ao ecossistema mais amplo do Azure.
Recomendações
Seus requisitos podem ser diferentes da arquitetura descrita aqui.
- Coloque o observador em um host em um terceiro local separado. Isso garante que, se o site principal ou stand-by falhar totalmente, o observador permanecerá ativo para coordenar o failover ou monitorar o site restante.
- Caso não haja um terceiro local disponível, coloque o observador no local primário.
- Configure vários observadores em diferentes servidores para alta disponibilidade. Enquanto apenas um observador pode ser o principal observador, observadores adicionais servem como observadores de backup.
- Siga a documentação da Oracle para definir os valores das propriedades de configuração de Failover Fast-Start, como as propriedades de Failover Fast-Start, como
FastStartFailoverThreshold,FastStartFailoverLagLimiteFastStartFailoverAutoReinstate. - Sempre execute o observador do Data Guard Broker usando a mesma release principal e o mesmo nível de patch (incluindo a Atualização da Release [RU]) que os homes do Oracle AI Database na configuração do Data Guard. Esta combinação recebe os testes mais completos e minimiza os riscos operacionais. Também garante que quaisquer correções que afetem o código do cliente (observador) e do servidor (banco de dados) estejam em vigor a qualquer momento. É permitida uma diferença de até uma versão principal do Suporte de Longo Prazo (LTS) entre o Observer e o banco de dados, principalmente para facilitar atualizações contínuas e minimizar o tempo de inatividade. Por exemplo, o observador no 26ai com o Database no 19c durante os procedimentos de atualização ou vice-versa.
Considerações
- Nunca coloque o observador no mesmo site do banco de dados stand-by. Se o site stand-by for desativado, o principal também será desativado porque não pode se comunicar com o observador, levando a uma interrupção completa
- O observador pode ser executado em uma VM leve. No entanto, a estabilidade da conexão de rede com o banco de dados principal e stand-by é crítica para garantir operações adequadas e evitar failovers desnecessários.
- Configure o modo de disponibilidade máxima do Data Guard para garantir zero perda de dados. Se você estiver mais preocupado com o desempenho do banco de dados principal do que com uma perda mínima de dados, considere ativar o failover de inicialização rápida quando o modo de proteção de configuração estiver definido para o desempenho máximo.
-
O tempo de failover depende se o banco de dados stand-by de destino aplicou todos os dados de redo recebidos do banco de dados principal. O failover de inicialização rápida é mais rápido quando você toma medidas para otimizar a recuperação para que a aplicação de dados de redo ao banco de dados stand-by seja mantida atualizada com a taxa de aplicação de redo do banco de dados principal. Consulte a seção Considerações de Desempenho para Failover Fast-Start na documentação do Data Guard, Conceitos do Broker.
- O tempo de failover depende do estado de redo apply no banco de dados stand-by.
Sobre Serviços e Atribuições Obrigatórios
Esta solução requer os seguintes serviços e funções:
- Oracle Exadata Database Service on Exascale Infrastructure
- Oracle Cloud Infrastructure Networking
Essas são as funções necessárias para cada serviço.
| Nome do Serviço: Função | Obrigatório para... |
|---|---|
OCI Database: manage database-family |
Criar um banco de dados stand-by do Data Guard |
Rede do OCI: manage vcn-family |
Gerenciar o Grupo de Segurança de Rede no OCI |
Consulte Produtos, Soluções e Serviços Oracle para obter o que você precisa.