Considerações sobre continuidade de negócios e recuperação de desastres para Oracle Database@Azure
Este artigo expande as considerações e recomendações de continuidade de negócios e recuperação de desastres (BCDR) descritas na área de design da zona de aterrissagem do Azure. Ele incorpora os princípios de Oracle Maximum Availability Architecture (MAA) para Oracle Database@Azure usando o Oracle Exadata Database Service.
A primeira etapa para criar uma arquitetura resiliente para seus bancos de dados Oracle executados no Oracle Database@Azure é identificar os requisitos de disponibilidade para a solução. É crucial estabelecer o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e o RPO (Recovery Point Objetive, objetivo de ponto de recuperação) para diferentes níveis de falhas, incluindo eventos planejados e não planejados. O RTO define o tempo máximo de inatividade que um aplicativo ou empresa pode tolerar após uma interrupção. O RPO especifica a duração máxima da perda de dados que um aplicativo ou empresa pode tolerar. Você deve abordar esse pré-requisito antes de iniciar seu design BCDR. Depois de estabelecer os requisitos de sua solução, você pode projetar seu ambiente Oracle Database@Azure para alinhá-lo com seu RTO e RPO.
Para obter mais informações, consulte as diretrizes do Microsoft Azure Well-Architected Framework sobre como projetar uma estratégia de DR.
Considerações de design
O serviço Oracle Exadata Database@Azure está disponível em duas zonas de disponibilidade diferentes dentro de uma região. Essa disponibilidade ajuda a garantir a confiabilidade do serviço e a DR. Para verificar o local de implantação do seu Database@Azure Oracle Exadata, verifique seu cluster de máquina virtual (VM) no portal do Azure.
O Oracle Exadata Database@Azure e seus componentes principais são limitados à zona de disponibilidade na qual você cria a instância. O serviço não cobre várias zonas ou abrange várias regiões. Para obter resiliência de várias zonas ou multirregionais, você pode implantar novas instâncias do Oracle Exadata Database@Azure para zonas ou regiões de disponibilidade de destino.
O Oracle Exadata Database@Azure fornece tecnologias Oracle nativas, como Oracle Real Application Clusters para alta disponibilidade (HA) e Oracle Data Guard para DR. O Data Guard e o Ative Data Guard são suportados para arquitetura DR.
O Oracle Exadata Database@Azure fornece HA contra falhas de instância de banco de dados e nível de hardware por padrão. Esta arquitetura está alinhada com o nível MAA prata. As operações de manutenção planeadas podem ser realizadas de forma contínua. No entanto, uma arquitetura de zona única padrão não oferece prevenção de falhas contra avarias locais ou regionais.
A solução fornece configuração automatizada do Data Guard para DR. Essa configuração ajuda a proteger contra falhas no site, exigindo outra implantação do Oracle Exadata Database@Azure em uma zona ou região de disponibilidade diferente.
A conectividade de rede entre instâncias principais e de espera do Oracle Exadata Database@Azure pode ser estabelecida através das redes Azure e Oracle Cloud Infrastructure (OCI). Por padrão, a rota principal para essa conectividade é por meio do Azure.
As três opções de backup disponíveis para o Oracle Exadata Database@Azure são:
backup gerenciado por OCI: Esta opção inclui duas soluções integradas, que são o Oracle Database Autonomous Recovery Service e o Oracle Cloud Infrastructure Object Storage. Estas soluções são geridas através da consola OCI.
O Serviço de Recuperação Autônoma foi projetado para cargas de trabalho de missão crítica de nível empresarial com requisitos rigorosos de RTO e RPO. Garante disponibilidade por meio de contratos de nível de serviço. Para obter mais informações, consulte o documento do pilar dos serviços de nuvem pública, plataforma Oracle como serviço e infraestrutura como serviço .
O OCI Object Storage é uma solução de backup de uso geral adequada para cargas de trabalho com requisitos menos rigorosos de RTO ou RPO.
Essas soluções permitem o agendamento e o gerenciamento automáticos de backups de bancos de dados com um período de retenção predefinido. Para obter mais informações, consulte Gestão de backup e recuperação de bases de dados no Exadata Database Service em infraestrutura dedicada da Oracle.
Backup autogerido: Podes configurar o Oracle Exadata Database@Azure para enviar backups de bases de dados para serviços de armazenamento do Azure, incluindo o Blob Storage do Azure, os Arquivos do Azure (através de pontos de extremidade privados) e os Arquivos NetApp do Azure.
Esta opção requer configuração manual e manutenção contínua.
O uso de endpoints privados com o Oracle Database@Azure requer uma passagem intermediária através de um appliance virtual de rede (NVA). Este dispositivo pode ser um NVA de hub, como o Firewall do Azure, ou um NVA que não seja da Microsoft. Para ambientes que não são de produção, pode ser uma VM dedicada usada para encaminhamento de endereços IP, como em Implantar um NVA local. Para obter mais informações, consulte Planeamento de rede para Oracle Database@Azure.
soluções de backup que não são da Microsoft: Você pode usar soluções de backup que não sejam da Microsoft disponíveis no Azure Marketplace, como Commvault, para gerenciar e armazenar backups de banco de dados.
Recomendações de design
Para criar uma arquitetura resiliente adaptada às suas necessidades específicas, considere as seguintes recomendações do BCDR para o Oracle Exadata Database@Azure.
Você deve configurar pelo menos duas instâncias do Oracle Exadata Database@Azure com o Data Guard para ajudar a proteger contra falhas em um único local. Esta configuração está alinhada com o padrão ouro MAA .
BCDR de várias zonas
A arquitetura BCDR de várias zonas é recomendada para clientes que precisam de um RPO zero ou quase zero com redundância de várias zonas, ao mesmo tempo em que atendem aos requisitos de residência de dados de uma única região.
Essa solução inclui uma implantação secundária do Oracle Exadata Database@Azure em uma zona de disponibilidade diferente dentro da mesma região. Para garantir resiliência contra falhas de banco de dados, cluster ou zona de disponibilidade, implemente um banco de dados em espera localizado na instância secundária. Essa configuração fornece proteção contra falhas no nível do site.
modo de transporte de redo do Data Guard: Configure o modo de transporte de redo do Data Guard de acordo com os serviços de aplicação e os requisitos de RPO:
Integridade dos dados e perda zero de dados: Quando a integridade dos dados e a perda zero de dados forem as prioridades mais altas, use o Modo de Disponibilidade Máxima (SYNC). Esse modo replica dados de forma síncrona para o banco de dados em espera, o que garante que nenhum dado seja perdido.
Desempenho do sistema: Quando o desempenho do sistema for crítico e um pequeno grau de perda de dados for aceitável, use o Modo de Desempenho Máximo (ASYNC). Esse modo usa replicação assíncrona, o que resulta em um RPO ligeiramente maior que zero (ou próximo de zero).
Manter uma instância de espera simétrica: Você deve manter uma instância de espera simétrica com recursos equivalentes ao banco de dados primário para garantir um desempenho consistente durante as operações de alternância e failover. Como alternativa, pode-se configurar o banco de dados em standby com recursos mínimos e escalar o cluster de VM dinamicamente, conforme necessário, após a mudança ou failover. No entanto, essa abordagem pode adicionar tempo extra para operações de dimensionamento e seu reflexo no nível do banco de dados.
Automatize as operações de failover: Use o Failover do Oracle Data Guard Fast-Start para minimizar o RTO e reduzir erros.
Observação
Fast-Start Failover não é um serviço gerenciado e requer configuração manual.
Para essa configuração, VMs extras que executam o Oracle Data Guard Observers são necessárias para habilitar o Data Guard Fast-Start Failover. Essas VMs observadoras monitoram o banco de dados e o status da replicação, o que automatiza o processo de failover.
Se você precisar de uma arquitetura de DR simétrica se houver um failover, posicione uma instância observadora no local onde a implantação secundária do Oracle Exadata Database@Azure está configurada.
BCDR multirregional
Para uma estratégia BCDR multirregional, implemente uma implantação secundária do Oracle Exadata Database@Azure com um banco de dados em espera localizado em uma região diferente onde o serviço está disponível. Esta configuração fornece proteção contra interrupções regionais completas.
Configure o Data Guard para replicar de forma assíncrona para DR regional com base nos requisitos do aplicativo e na latência de rede entre a região primária e secundária. Para saber mais, consulte as estatísticas de latência de ida e volta da rede do Azure .
Observação
O Data Guard automatizado só permite a configuração do Modo de Desempenho Máximo (ASYNC) para implantações entre regiões.
- As recomendações BCDR de várias zonas e multirregionais concentram-se na resiliência do serviço de banco de dados. Para ajudar a garantir a resiliência geral da carga de trabalho, considere usar os serviços e recursos do Azure, como Conjuntos de Escala de Máquina Virtual do Azure, Azure Site Recovery e Azure Front Door, para projetar uma arquitetura robusta em zonas ou regiões de disponibilidade.
Cenários BCDR estendidos
Bancos de dados em espera locais e remotos
Para atender aos requisitos de disponibilidade de serviço robusta e resiliência contra interrupções regionais, recomendamos que você implemente vários bancos de dados em espera para cargas de trabalho de missão crítica.
Um banco de dados local em espera em uma implantação do Oracle Exadata Database@Azure reside em uma zona de disponibilidade diferente dentro da mesma região. Essa configuração fornece uma solução viável para aplicativos sensíveis à latência, abordando os requisitos de failover sem perda de dados por meio da replicação do SYNC Data Guard. Essa estratégia ajuda a garantir a disponibilidade do serviço sem afetar a taxa de transferência do aplicativo ou o tempo de resposta geral.
Um banco de dados remoto em espera em uma instância de Database@Azure Oracle Exadata localizada em uma região diferente atende aos requisitos regionais de DR.
Essa arquitetura é ideal para cargas de trabalho de missão crítica e requer um mínimo de três implantações do Oracle Exadata Database@Azure.
Observação
Se uma configuração simétrica for necessária devido a um cenário de failover, coloque um banco de dados em espera extra no Oracle Exadata Database@Azure na região secundária, dentro de uma zona de disponibilidade diferente.
Arquitetura do Data Guard Far Sync
Você pode atender ao requisito de implementar replicação sem perda de dados a qualquer distância usando a configuração do Data Guard Far Sync. Essa abordagem inclui colocar uma instância de sincronização distante mais próxima da implantação principal do Oracle Exadata Database@Azure, essencialmente em outra zona de disponibilidade dentro da mesma região, para enviar os logs de redo de forma síncrona. Em seguida, a instância de sincronização distante transfere esses logs de forma assíncrona para o banco de dados em espera que é executado na implantação secundária do Oracle Exadata Database@Azure em outra região. Essa configuração resulta efetivamente em replicação sem perda de dados entre regiões.
Se você procurar uma arquitetura de DR simétrica se houver um failover, coloque uma instância de sincronização distante em uma zona de disponibilidade separada onde a implantação secundária do Oracle Exadata Database@Azure está configurada.
Observação
A arquitetura Far Sync requer uma licença do Ative Data Guard e deve ser configurada manualmente.
Recomendações de backup
Se você planeja usar backups como sua única solução para os requisitos de BCDR, lembre-se de que o RTO é maior em comparação com cenários de replicação porque se baseia no tamanho do banco de dados e nos métodos de backup usados.
Fazer backup de dados no Azure: Para atender aos requisitos organizacionais que exigem que os dados e backups permaneçam no Azure, considere as seguintes soluções:
Usar o Serviço de Recuperação Autônoma (ARS) no Azure: Durante a configuração da política de backup, opte por armazenar dados de backup no mesmo provedor de nuvem que o banco de dados usar o ARS no Azure.
Usar serviços de armazenamento: Use serviços de armazenamento como Armazenamento de Blob, Arquivos do Azure e Arquivos NetApp do Azure para montar o armazenamento como pontos do sistema de arquivos de rede no servidor de banco de dados e transmitir backups do Oracle Recovery Manager (RMAN) para o armazenamento.
Retenção de backup de longo prazo: Se sua organização exigir retenção de backup de longo prazo, você poderá configurar backups RMAN autogerenciados para o Armazenamento do Azure.
Configurações de backup de armazenamento: Quando os backups forem configurados para serviços de armazenamento, considere as seguintes recomendações:
Agendar com tarefas cron: Use tarefas cron ao nível do nó do banco de dados para agendar backups a horas específicas de acordo com a sua estratégia de backup.
Replicar backups: Use recursos de replicação de armazenamento subjacentes do Azure, como armazenamento com redundância de zona e armazenamento com redundância geográfica para replicar backups.
Operações de backup e restauração: Faça backup manual de Database@Azure VMs do Oracle Exadata para restaurar arquivos críticos se houver exclusões acidentais ou corrupções. Para obter mais informações, consulte operações de backup e restauração do nó Oracle Exadata Cloud Compute (ID do documento 2809393.1).
Outras recomendações
Manter dados no Azure: Se for necessário manter os dados exclusivamente no Azure, encaminhe o tráfego do Data Guard através da rede do Azure e configure os backups para permanecerem no Azure.
Teste DR: Teste as operações de failover e mudança de função para assegurar o seu funcionamento num cenário de desastre real.
Utilize o Oracle Fast-Start Failover para automatizar as operações de failover, sempre que possível, e assim reduzir erros.
Utilize Oracle Application Continuity para mascarar suavemente a interrupção na camada de aplicação.
Dados e replicação em tempo real: Para ambientes ativos-ativos, considere utilizar Oracle GoldenGate para integração de dados em tempo real e recursos de replicação. Requer consciência ao nível da aplicação para lidar com a resolução de conflitos de forma eficaz.
Observação
GoldenGate não está incluído nesta solução e pode incorrer em custos de licenciamento extras.
Minimize as interrupções: Para minimizar as interrupções da sua carga de trabalho, agende a manutenção planejada fora do horário de pico. Quando puder, use atualizações contínuas para garantir um processo contínuo.
Usar infraestrutura como código (IaC): Para uma automação de infraestrutura mais confiável, implante a instância inicial do Oracle Exadata Database@Azure e os clusters de VM usando o IaC. Para obter mais informações sobre automação do Oracle Database@Azure, consulte QuickStart Oracle Database@Azure com módulos Terraform ou OpenTofu.
Use os Módulos Verificados do Azure para implantar instâncias de Database@Azure Oracle Exadata e clusters de VM. Para obter mais informações, consulte os seguintes recursos:
Use o IaC para implantar bancos de dados no plano de controle OCI. Você pode usar o IaC para replicar a mesma implantação em um site de DR e minimizar o risco de erro humano.