Compartilhar via


Otimize a continuidade dos negócios e a recuperação de desastres

Ao migrar recursos do Oracle para o Azure, considere a confiabilidade do banco de dados e também a confiabilidade das camadas em VMs (máquinas virtuais), sub-redes de rede virtual e componentes de armazenamento.

A infraestrutura como serviço (IaaS) do Oracle no Azure pode atender aos objetivos de resiliência necessários das cargas de trabalho Oracle mais exigentes. Para usar efetivamente as diretrizes deste artigo, primeiro defina seus KPIs (indicadores de desempenho) de resiliência com base em seus requisitos de negócios. Use os requisitos de RTO (objetivo de tempo de recuperação) e RPO (objetivo de ponto de recuperação) como KPIs de linha de base para determinar a melhor arquitetura para sua carga de trabalho Oracle no Azure.

O RTO é a quantidade máxima de tempo que um aplicativo permanece indisponível após um desastre, falha ou evento comparável.

O RPO é a quantidade máxima de perda de dados após um desastre, falha ou evento comparável.

Métodos de backup para proteção de dados

Os três métodos de backup de banco de dados Oracle para uma carga de trabalho Oracle no Azure IaaS incluem:

  • Backups de streaming. Use o Oracle Recovery Manager (RMAN) para esse método. O RMAN transmite backups para mídia de fita seqüencial.

    Os destinos de backup no Azure incluem:

    • Bibliotecas de fitas virtuais que não são da Microsoft, que você pode encontrar no Azure Marketplace.
    • Compartilhamentos de arquivos locais e remotos, como o Armazenamento de Blobs do Azure com o protocolo do Sistema de Arquivos de Rede, Arquivos do Azure e Azure NetApp Files.
  • Instantâneos no nível do armazenamento. Use o Backup do Azure para esse método. Esse método depende do tipo de armazenamento que você usa para arquivos de banco de dados. Por exemplo, se você usar discos gerenciados do Azure, como o SSD Premium do Azure, o Backup do Azure se integrará ao banco de dados Oracle. Se você usar o Azure NetApp Files, poderá usar os recursos de proteção de dados do Azure NetApp Files, como backup do Azure NetApp Files e replicação entre regiões.

  • Backups no nível da VM. Use o Backup do Azure para esse método.

    Cuidado

    Verifique se as VMs em seu ambiente de backup estão executando sistemas operacionais com capacidade de suporte. Saiba mais sobre os sistemas operacionais compatíveis.

Quando você transmite backups de bancos de dados grandes, o tempo necessário para copiar os dados e restaurá-los pode exceder os requisitos de RTO. Os instantâneos no nível do armazenamento são a melhor opção para esse cenário.

Recomendações

  • Considere cuidadosamente se deve implementar uma estratégia de backup baseada em streaming, em instantâneos no nível do armazenamento ou em ambas as estratégias.

  • Avalie o efeito de sua estratégia de backup em seus requisitos de RTO e RPO.

  • Analise os destinos de armazenamento disponíveis para seus backups do RMAN com base nos limites de taxa de transferência documentados para cada opção. Escolha a opção que atenda às suas necessidades.

  • Considere usar o Backup do Azure para seus instantâneos em nível de armazenamento e considere colocar os instantâneos em uma região emparelhada ou em uma zona de disponibilidade para proteção extra.

  • Considere várias opções de armazenamento para armazenar os backups de log de arquivamento necessários para recuperar o banco de dados. Considere as considerações de desempenho, replicação e custo de cada opção.

  • Desenvolva e teste regularmente seus planos de backup e restauração para evitar surpresas indesejadas em seu ambiente de produção.

Proteção de serviços e continuidade de negócios

Esta seção descreve como melhorar a HA (alta disponibilidade) geral e a DR (recuperação de desastre) da carga de trabalho do Oracle na IaaS do Azure implementando considerações de BC (proteção de serviço) e continuidade dos negócios.

Incorpore as recomendações a seguir para melhorar a redundância arquitetônica e, por fim, maximizar a quantidade de tempo que seu serviço está disponível. Procure minimizar o tempo de inatividade do serviço devido a interrupções planejadas, como patches, atualizações e upgrades, e interrupções não planejadas, como falhas. Use os recursos do Azure e do Oracle para melhorar sua recuperação de falhas em toda a geografia.

O Azure fornece muitas opções para a alta disponibilidade de componentes individuais em uma arquitetura Oracle on IaaS. Por exemplo, você pode:

  • Implante VMs usando um conjunto de dimensionamento de máquinas virtuais flexível, que distribui automaticamente as VMs entre domínios de falha.
  • Crie zonas de disponibilidade para se proteger contra falhas do datacenter.
  • Coloque implantações em diferentes regiões para proteger contra falhas de região completa.

Vários recursos de armazenamento do Azure fornecem diferentes níveis de redundância de armazenamento, como armazenamento com redundância local, armazenamento com redundância de zona e armazenamento com redundância geográfica. Considere cada opção ao planejar a implantação da carga de trabalho do Oracle na IaaS do Azure.

Você também pode usar o Oracle Data Guard, que é uma ferramenta para configurações de proteção de serviço de banco de dados Oracle. O Data Guard encaminha e aplica logs de transações a um ou mais bancos de dados stand-by. Esse processo mantém cópias exatas do banco de dados primário para as quais você pode fazer failover se tiver planejado manutenção ou um cenário de falha.

O Data Guard tem três modos de replicação de dados: proteção máxima, disponibilidade máxima e desempenho máximo. Cada modo de replicação oferece uma combinação diferente de modos de transporte de log e diferentes garantias transacionais para o aplicativo no banco de dados secundário.

Dependendo da sua estratégia, como uma estratégia de latência zero ou perda de dados zero, você pode escolher uma configuração síncrona ou assíncrona. Você também pode implementar o failover de inicialização rápida, dependendo dos requisitos máximos de tempo de inatividade. Estão disponíveis arquiteturas de referência que fornecem uma recuperação em menos de um minuto ou menos de cinco minutos e até quatro horas. A Enterprise Edition do Oracle Database inclui o Data Guard.

O Oracle GoldenGate é outra ferramenta que você pode usar para replicar dados entre dois bancos de dados e ativar cenários de vários principais. Você deve comprar o GoldenGate separadamente.

Recomendações

  • Considere os recursos que o Azure fornece para a alta disponibilidade de vários componentes de infraestrutura em sua implementação de IaaS do Oracle no Azure.

  • Selecione cuidadosamente o modo de proteção de banco de dados que atenda aos seus requisitos ao usar o Data Guard para HA e DR. Por exemplo, o modo de desempenho máximo minimiza o impacto na origem, mas tem o maior potencial de perda de dados. Para obter mais informações, consulte BCDR para acelerador de zona de destino do Oracle em Máquinas Virtuais do Azure e modos de proteção do Oracle Data Guard.

  • Considere automatizar o processo de failover. Por exemplo, você pode usar o failover de inicialização rápida.

  • Estabeleça procedimentos de teste para seus processos de failover e realize testes regulares para evitar problemas.

  • Arquitete sua solução de forma holística usando recursos nativos do Azure, como zonas de disponibilidade, e ferramentas nativas da Oracle, como o Data Guard, para atender aos seus requisitos de HA e DR. Os dois exemplos a seguir usam componentes nativos do Azure e nativos da Oracle.

Criar um failover com espera passiva

Esta seção descreve um exemplo de um cenário de failover para aplicativos Oracle críticos para os negócios em uma implantação de duas zonas de disponibilidade com espera passiva.

Os aplicativos Oracle críticos para os negócios, como o Oracle E-Business Suite, exigem prevenção de falhas e, portanto, uma arquitetura holística.

Neste exemplo:

  • Tem uma implantação de duas zonas de disponibilidade. A camada de aplicativo usa o Azure Site Recovery com uma VM secundária passiva.

  • Aproveita o recurso de failover de início rápido do Data Guard. Para obter a disponibilidade mais alta, recomendamos que você instale dois observadores. O observador primário está na zona de disponibilidade um e o observador secundário está na zona de disponibilidade dois. Os observadores monitoram e direcionam o tráfego. Quando o banco de dados primário não está disponível, o observador faz failover automaticamente para o banco de dados secundário. O Data Guard executa uma sincronização de restauração. O período de tempo da sincronização de redo depende da configuração de redo.

  • Tem o Data Guard configurado para um modo de proteção de dados, como disponibilidade máxima, desempenho máximo ou proteção máxima. Para obter mais informações sobre como escolher um modo para seus requisitos de carga de trabalho, consulte Modos de proteção do Oracle Data Guard.

A arquitetura a seguir visa um limite de tempo de inatividade de menos de cinco minutos.

Diagrama que mostra a arquitetura de um failover com espera passiva.

Criar um failover com espera ativa

Esta seção descreve um exemplo de um cenário de failover para aplicativos Oracle críticos para os negócios em uma implantação de duas zonas de disponibilidade com espera ativa.

Neste exemplo:

  • A camada de servidor Web, a camada de aplicativo e a camada de banco de dados residem em sua própria sub-rede de rede virtual.

  • O banco de dados primário reside na zona de disponibilidade um.

  • O banco de dados que usa o Active Data Guard para replicar o banco de dados primário para um stand-by ativo reside na zona de disponibilidade três.

Observação

Essa configuração requer uma licença do Active Data Guard.

A arquitetura a seguir visa um limite de tempo de inatividade de menos de um minuto. Esse cenário de failover tem uma configuração de espera ativa, mas tem recursos somente leitura.

Diagrama que mostra a arquitetura de um failover com espera ativa.

Próxima etapa