Compartilhar via


Considerações sobre continuidade de negócios e recuperação de desastres para o Oracle Database@Azure

Este artigo expande as considerações e recomendações definidas na área de design da zona de destino do Azure para BCDR (continuidade dos negócios e recuperação de desastre).

A primeira etapa para criar uma arquitetura resiliente para seu ambiente de carga de trabalho é identificar os requisitos de disponibilidade para sua solução. Você precisa determinar o RTO (Recovery Time Objective, objetivo de tempo de recuperação) e o RPO (Recovery Point Objective, objetivo de ponto de recuperação) para diferentes níveis de falha. O RTO define o tempo de inatividade máximo que um aplicativo pode tolerar após um incidente. O RPO especifica a perda máxima de dados que um aplicativo pode tolerar devido a um desastre. Depois de determinar os requisitos da sua solução, você pode projetar sua arquitetura para atender ao RTO e ao RPO.

Considerações sobre o design

  • Coloque o Oracle Exadata Database Service em Infraestrutura Dedicada com o Oracle Database@Azure em datacenters do Azure e coloque os datacenters em uma zona de disponibilidade do Azure. As zonas de disponibilidade são específicas de uma assinatura. Por exemplo, a zona de disponibilidade 1 em uma assinatura pode não representar o mesmo datacenter físico que a zona de disponibilidade 1 em uma assinatura diferente. Para obter mais informações, consulte O que são zonas de disponibilidade.

  • A solução Oracle Database@Azure fornece tecnologias Oracle nativas, como RAC (Real Application Clusters) e Data Guard automatizado, para alta disponibilidade e DR.

  • A solução inclui uma configuração automatizada do Data Guard para o banco de dados stand-by inicial, também conhecido como primeiro secundário. Você deve configurar manualmente todas as réplicas extras do Data Guard.

  • Para ambientes ativos-ativos, considere usar o Oracle GoldenGate para integração de dados em tempo real e recursos de replicação. Essa abordagem ajuda a garantir alta disponibilidade e consistência de dados em seus sistemas. Essa ferramenta oferece suporte a uma ampla variedade de bancos de dados e plataformas para que você possa mover e transformar dados sem problemas. Use o Oracle GoldenGate para minimizar o tempo de inatividade durante migrações e upgrades, o que aprimora suas estratégias de DR. O Oracle GoldenGate não está incluído na solução, portanto, você pode incorrer em custos de licenciamento.

  • A solução Oracle Database@Azure e seus componentes principais são limitados à assinatura e à região em que você cria a instância. O serviço não é multizonal e não abrange várias regiões. Para obter resiliência multizonal ou multirregional, você pode implantar novas instâncias em zonas de disponibilidade ou regiões de destino.

  • O Oracle Database@Azure usa o Oracle Cloud Infrastructure (OCI) Object Storage redundante para integrar backups automáticos de banco de dados. O Oracle Database Autonomous Recovery Service fornece proteção para bancos de dados Oracle implantados no Exadata.

Recomendações sobre design

Considere estas considerações de BCDR para o Oracle Database@Azure.

BCDR entre zonas de disponibilidade

Para garantir alta disponibilidade e proteção de DR contra falhas de bancos de dados, clusters de banco de dados ou zonas de disponibilidade, use o Oracle RAC no Oracle Database@Azure e um banco de dados stand-by simétrico localizado em outra zona. Essa configuração pode ajudá-lo a obter resiliência de datacenter para serviços de banco de dados.

Para obter o desempenho ideal, coloque os serviços de aplicativos que dependem do banco de dados na mesma zona de disponibilidade que o banco de dados. Se os serviços de aplicativo estiverem em uma assinatura diferente dos serviços de banco de dados, você deverá aplicar o código apropriado. Use a availabilityZoneMappings propriedade para identificar a zona de disponibilidade física em que você deve colocar seus serviços.

  • Você pode configurar o Data Guard no modo Disponibilidade Máxima com transporte SYNC ou no modo Desempenho Máximo com transporte ASSÍNCRONO de acordo com seus serviços de aplicativos e requisitos de RPO.

    • Recomendamos que você use o modo de disponibilidade máxima (SYNC) para ambientes em que a integridade dos dados e a perda zero de dados são os fatores mais importantes.

    • Recomendamos que você use o modo de desempenho máximo (ASYNC) para ambientes em que o desempenho é crítico e o ambiente pode tolerar alguma perda de dados.

BCDR entre regiões

  • Configure o Data Guard no modo Desempenho Máximo para BCDR regional com base nos recursos do aplicativo e na latência de rede entre regiões. Para obter mais informações, consulte Resultados do teste de latência de rede do Azure.

  • A combinação de operações BCDR entre zonas de disponibilidade e entre regiões se alinha com o nível Gold das arquiteturas de referência do Oracle Maximum Availability Architecture. A arquitetura de nível Gold fornece proteção contra uma falha regional completa.

  • As recomendações de BCDR entre zonas de disponibilidade e entre regiões se concentram na resiliência do serviço Oracle Database@Azure. Para ajudar a garantir a resiliência de seus serviços de aplicativo, você pode usar Conjuntos de Dimensionamento de Máquinas Virtuais do Azure, Azure Site Recovery, Azure Front Door ou outros recursos ou serviços que habilitam a disponibilidade do serviço de aplicativo entre zonas ou regiões de disponibilidade.

  • Recomendamos que você use backups gerenciados e armazene dados de backup no OCI Object Storage.

Outras considerações

  • Use a infraestrutura como código (IaC) para implantar a instância inicial do Oracle Database@Azure e os clusters de máquinas virtuais.

  • Use a IaC para implantar bancos de dados no OCI. Você pode usar a IaC para replicar a mesma implantação em um site de recuperação de desastre e minimizar o risco de erro humano.

  • Use operações de failover e switchback de teste para ajudar a garantir que elas funcionem em um cenário de desastre real. Automatize as operações de failover e switchback quando possível para minimizar erros.

Próximas etapas