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