Sobre Implantação

Implante o aplicativo e o banco de dados em duas AZs do Azure para alta disponibilidade e configure o gerenciamento de chaves e o backup automatizado do banco de dados na OCI.

Implantar a Camada de Aplicativos no Azure

As soluções MAA exigem que os aplicativos sejam implantados com redundância e tolerância a falhas.

  1. Implante a camada de aplicativos em pelo menos duas AZs. O processo e a solução a serem implantados em várias AZs variam com base nos serviços e recursos do Azure envolvidos. Com o Azure Kubernetes Service (AKS), você pode implantar um cluster privado de nós de trabalho em diferentes AZs. O plano de controle do Kubernetes mantém e sincroniza os pods e a carga de trabalho.
  2. Consulte Explorar Mais para Lista de Verificação de Aplicativos para Serviço Contínuo para Soluções MAA e siga as etapas para garantir que seus aplicativos se reconectem com eficiência às instâncias RAC principais disponíveis ou às instâncias RAC stand-by durante cenários planejados de manutenção e interrupção. Essas práticas recomendadas de configuração simples incluem a criação de um serviço de banco de dados gerenciado por clusterware para seu aplicativo, usando uma string de conexão recomendada por MAA que é compatível com SCAN principal e stand-by, permitindo FAN (Fast Application Notification) e drenagem de aplicativos para switchover de aplicativo adequado. Seguir, no mínimo, as etapas de nível 1 e nível 2 são pré-requisitos para reduzir o tempo de inatividade do serviço de aplicativo.

Configurar Camada de Banco de Dados no OCI

O Oracle Data Guard mantém um banco de dados standby transmitindo e aplicando dados de redo do banco de dados principal. Para manutenção planejada ou um teste de recuperação de desastre, use o switchover do Oracle Data Guard. Se o banco de dados principal não estiver disponível, use o failover do Oracle Data Guard para retomar o serviço.

As etapas a seguir descrevem o processo para ativar o Oracle Data Guard entre AZs para o Oracle Database@Azure pela rede gerenciada do OCI. A OCI é a rede preferencial para desempenho (latência, throughput) e nenhum custo de saída ou entrada é incorrido.

Quando os clusters Exadata forem criados no Azure, cada um deles estará em outra VCN (Rede Virtual na Nuvem) do OCI. Para que recursos de diferentes VCNs se comuniquem entre si, conforme exigido pelo Oracle Data Guard, são necessárias etapas adicionais para parear as VCNs e permitir que as faixas de endereços IP acessem umas às outras. Siga estas etapas para configurar essa comunicação entre VCNs.

  1. Faça log-in na Console do OCI e crie um LPG (Local Peering Gateway) nas VCNs dos clusters de VMs principais e stand-by do Exadata.
  2. Estabeleça uma conexão de mesmo nível entre o LPG principal e o stand-by e selecione o gateway de mesmo nível não pareado na VCN stand-by.

    Observação:

    Cada VCN pode ter apenas um LPG (Local Peering Gateway). Uma VCN hub precisará ser configurada se houver vários bancos de dados em um determinado cluster de VMs do Exadata que terão bancos de dados stand-by em diferentes clusters de VMs do Exadata.
  3. Atualize a tabela de roteamento padrão para rotear o tráfego entre os bancos de dados principal e stand-by por meio da rede do OCI sem incorrer em custos de transferência de dados de entrada e saída.

    Observação:

    Para atualizar a tabela de roteamento padrão, no momento você precisa criar um ticket de suporte fornecendo o nome da tenancy e o OCID do DRG.
  4. Atualize o Grupo de Segurança de Rede principal e stand-by para criar uma regra de segurança que permita a entrada da sub-rede do cliente principal e stand-by para a porta TCP 1521. Opcionalmente, você pode adicionar a porta SSH 22 para acesso SSH direto aos servidores de banco de dados.
  5. Ative o Data Guard ou o Data Guard Ativo para o banco de dados principal. Na página de detalhes do Oracle Database, clique em Associações do Data Guard e, em seguida, no botão Ativar Data Guard.
  6. Na página Ativar Data Guard:
    1. Selecione o domínio de disponibilidade stand-by mapeado para o Azure AZ.
    2. Selecione o Exadata Infrastructure stand-by.
    3. Selecione o cluster de VMs stand-by desejado.
    4. Escolha o Data Guard ou o Active Data Guard. O MAA recomenda o Active Data Guard para reparo automático de blocos de corrupções de dados e capacidade de descarregar relatórios.
    5. Escolha um modo de proteção e um tipo de transporte de redo que satisfaça seu RTO e RPO.
    6. Selecione um home de banco de dados existente ou crie um novo. É recomendável usar a mesma imagem de software de banco de dados do banco de dados principal para o home do banco de dados stand-by; portanto, ambos têm os mesmos patches disponíveis.
    7. Informe a senha para o usuário SYS e ative o Data Guard.
    Depois que o Data Guard for ativado, o banco de dados stand-by será listado na seção Associações do Data Guard.
  7. (Opcional) Ative o failover automático (Failover de Inicialização Rápida) para reduzir o tempo de recuperação em caso de falhas, instalando o Data Guard Observer em uma VM separada, de preferência em um local separado ou na rede do aplicativo. Para obter mais informações, siga a documentação para Fast-Start Failover e Configurar e Implantar o Oracle Data Guard. (Essas são etapas manuais no momento e não fazem parte da automação da nuvem.)

Sobre Resoluções Esperadas com Manutenção Planejada e Interrupções

O uso da configuração do Oracle Data Guard deste manual, que inclui bancos de dados Oracle RAC no hardware Exadata, eventos de interrupção planejados e não planejados podem ser mitigados.

Esta tabela mostra os eventos de interrupção e as resoluções que fornecem proteção de dados.

Evento Resolução
Proteção contra falhas de instância de banco de dados e hardware. Alta disponibilidade e redundância fornecidas por ExaDB-D e Oracle RAC.
Manutenção planejada: Atualizações contínuas (aplicação de patches) sem tempo de inatividade. Alta disponibilidade e redundância fornecidas por ExaDB-D, Oracle RAC e automação da nuvem. Consulte Explorar Mais para Upgrade Incremental do Exadata Cloud Database 19c com DBMS_ROLLING (ID do Documento 2832235.1).
Manutenção planejada: Atualizações contínuas com tempo de inatividade mínimo (cinco minutos). Replicação e proteção de dados fornecidas pelo Oracle Data Guard DBMS_ROLLING entre AZs.
Proteção contra falhas de banco de dados, cluster e AZ. Replicação e proteção de dados fornecidas pelo Oracle Data Guard entre AZs.
Falha no local do plano de dados AZ. Replicação e proteção de dados fornecidas pelo Oracle Data Guard entre AZs.
Interrupção da sessão do banco de dados durante eventos de manutenção e interrupções não planejadas. Consulte Explorar Mais para incorporar as melhores práticas de Disponibilidade Contínua para Aplicativos.