Continuidade de negócios e recuperação de desastres para Oracle no acelerador de zona de aterrissagem de Máquinas Virtuais do Azure

Este artigo baseia-se nas considerações e recomendações definidas na área de design da zona de aterrissagem do Azure para continuidade de negócios e recuperação de desastres (BCDR). Este artigo segue essa orientação e descreve considerações de design e práticas recomendadas sobre opções BCDR para implantações de carga de trabalho Oracle em máquinas virtuais (VMs) de infraestrutura do Azure.

O Azure fornece serviços que você pode usar para projetar arquiteturas altamente disponíveis e resilientes. Este guia descreve várias opções e práticas recomendadas para ajudá-lo a projetar alta disponibilidade e recuperação de desastres para bancos de dados Oracle no acelerador de zona de aterrissagem de Máquinas Virtuais do Azure. Ele também descreve como configurar os serviços do Azure para ajudá-lo a obter alta disponibilidade de ponta a ponta para sua solução.

Começar agora

Para criar uma arquitetura resiliente para seu ambiente de carga de trabalho, determine os requisitos de disponibilidade para sua solução com base no RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e no RPO (Recovery Point Objetive, objetivo de ponto de recuperação) para vários níveis de falha. RTO é o tempo máximo que um aplicativo permanece indisponível após a ocorrência de um incidente. RPO é a quantidade máxima de perda de dados durante um desastre. Depois de determinar os requisitos para sua solução, projete sua arquitetura para fornecer os níveis estabelecidos de resiliência e disponibilidade.

As cargas de trabalho do Oracle on Azure usam principalmente o Oracle Data Guard, que é um recurso interno do Oracle Database Enterprise Edition que usa a tecnologia de replicação. Você pode usar o Data Guard para atender às necessidades de alta disponibilidade e recuperação de desastres. O Data Guard oferece três modos de proteção: desempenho máximo, disponibilidade máxima e proteção máxima. Escolha seu modo de proteção com base em seu projeto arquitetônico e seus requisitos específicos de RPO e RTO.

Configure sua carga de trabalho para alta disponibilidade

As instâncias de Máquinas Virtuais do Azure que executam cargas de trabalho Oracle se beneficiam da arquitetura dos Conjuntos de Dimensionamento de Máquina Virtual do Azure, especificamente do modo de orquestração flexível. Uma configuração de alta disponibilidade fornece replicação de dados quase em tempo real com recursos de failover potencialmente rápidos. Uma configuração de alta disponibilidade não fornece proteção para falhas no nível do datacenter do Azure ou no nível da região.

Escolha a opção certa de alta disponibilidade

Use o fluxograma a seguir para escolher a melhor opção de alta disponibilidade para seu banco de dados Oracle.

Use o Data Guard no modo de disponibilidade máxima para alta disponibilidade

O Data Guard no modo de disponibilidade máxima fornece a mais alta disponibilidade com uma promessa de perda de dados zero (RPO=0) para operações normais. Para uma configuração altamente disponível de dois servidores de banco de dados Oracle criados em uma orquestração flexível de Conjuntos de Dimensionamento de Máquina Virtual, o Azure fornece 99,95% de disponibilidade de serviço para um contrato de nível de serviço (SLA) para instâncias espalhadas entre domínios de falha. O Azure fornece 99,99% de disponibilidade de serviço para instâncias que estão espalhadas por zonas de disponibilidade. Para obter mais informações, consulte Alta disponibilidade para conjuntos de dimensionamento de máquina virtual.

Para obter uma configuração passo a passo do Data Guard no Azure, consulte Implementar o Oracle Data Guard em uma VM do Azure baseada em Linux.

Use o Data Guard no modo de proteção máxima para alta disponibilidade

Se você precisar de uma cópia transacional consistente do seu banco de dados, considere usar o Data Guard no modo de proteção máxima. No entanto, o modo de proteção máxima não permite que as transações continuem quando o banco de dados em espera não estiver disponível. Portanto, apesar de usar a orquestração flexível de Conjuntos de Escala de Máquinas Virtuais, seu SLA é reduzido para 99,9% x 99,9% = 99,8% quando você usa o modo de proteção máxima. Essa configuração garante uma cópia consistente dos dados, mas não necessariamente aumenta a disponibilidade.

Outros atributos dessa arquitetura são os mesmos do modo de disponibilidade máxima. Por exemplo, o RPO é zero e o RTO é menor ou igual a dois minutos.

Considere outras maneiras de implementar alta disponibilidade

As seções a seguir descrevem considerações especiais para alta disponibilidade.

Usar zonas de disponibilidade para melhorar a alta disponibilidade

As zonas de disponibilidade do Azure são datacenters do Azure que estão dentro da mesma região do Azure. As zonas de disponibilidade têm uma latência de ida e volta inferior a dois milissegundos. Normalmente, você usa zonas de disponibilidade para fins de recuperação de desastres, mas pode usá-las para melhorar a alta disponibilidade. Se você fizer isso, você deve certificar-se de que sua solução pode ser executada com a quantidade de latência e taxa de transferência que suas zonas de disponibilidade fornecem.

Uma vantagem das zonas de disponibilidade com uma orquestração flexível de Conjuntos de Escala de Máquina Virtual é que o SLA de disponibilidade da VM aumenta para 99,99%.

Usar clustering de armazenamento compartilhado para alta disponibilidade

As tecnologias de clustering de armazenamento compartilhado fornecem atributos exclusivos que podem ajudá-lo a atingir suas metas de negócios. Por exemplo, você pode implementar um cluster Pacemaker e Corosync (PCS) com armazenamento compartilhado. Você pode usar discos gerenciados ou Arquivos NetApp do Azure como armazenamento compartilhado para instâncias de cluster PCS. Um cluster PCS não duplica dados. Ele fornece um serviço IP virtual com um endereço IP estático ou nome de rede IP que não muda entre failovers.

Nota

Um cluster PCS não é uma solução certificada pela Oracle. Tenha esse fator em mente ao escolher sua arquitetura de alta disponibilidade.

Utilizar grupos de colocação por proximidade

Para fornecer a menor latência possível, coloque as VMs o mais próximo possível. Você pode implantá-los em um grupo de posicionamento de proximidade. Um grupo de posicionamento de proximidade é um agrupamento lógico que garante que os recursos de computação do Azure estejam fisicamente localizados próximos uns dos outros. Os grupos de posicionamento de proximidade são úteis para cargas de trabalho que exigem baixa latência.

Configure sua carga de trabalho para recuperação de desastres

Uma arquitetura de recuperação de desastres fornece resiliência contra falhas que afetam datacenters ou regiões do Azure ou contra falhas que prejudicam a funcionalidade do aplicativo em toda uma região. Nesse cenário, você deve mover toda a carga de trabalho para um datacenter ou região diferente.

Escolha sua arquitetura de recuperação de desastres com base nos requisitos da solução. Você determina seus requisitos com base em seu RTO e RPO. As arquiteturas de recuperação de desastres são para casos de falha excecionais, portanto, os processos de failover são manuais. No design de alta disponibilidade, os processos de failover são automáticos. Em uma arquitetura de recuperação de desastres, você deve ter requisitos mais relaxados para RTO e RPO, o que economiza dinheiro.

Este artigo se concentra em cenários nos quais o servidor primário e os servidores secundários estão ambos no Azure. Você também pode ter um servidor primário local e um servidor secundário no Azure para fins de recuperação de desastres. Para obter mais informações, consulte Site primário local e site de recuperação de desastres no Azure.

Escolha a opção certa de recuperação de desastres

Use o fluxograma a seguir para escolher a melhor opção de recuperação de desastres para seu banco de dados Oracle.

Usar o Data Guard para recuperação de desastres

Você pode usar o Data Guard para replicar dados para seu site de recuperação de desastres. Use esse site como outra zona de disponibilidade na mesma região ou em uma região diferente, dependendo dos seus requisitos de proteção de dados. Sua configuração também depende da estrutura da zona de disponibilidade em seu local de produção. Uma implementação do Data Guard em um cenário de recuperação de desastres é semelhante ao cenário de alta disponibilidade discutido anteriormente, com algumas diferenças importantes. Por exemplo:

• Ao fazer failover para uma réplica secundária no cenário de alta disponibilidade, você configura o Balanceador de Carga do Azure para redirecionar solicitações para a nova instância de banco de dados primária.

• Ao fazer failover para o site de recuperação de desastres, você faz failover de toda a solução para o novo site. Para evitar desafios de latência, normalmente é necessário configurar o failover para serviços de aplicativos.

Se o local de recuperação de desastres estiver em outra região, você precisará projetar o site para o failover, dependendo de suas necessidades.

A latência dentro de um único datacenter é menor do que a latência entre datacenters separados uns dos outros e muito menor do que a latência entre diferentes regiões. Portanto, a opção menos complexa e menos dispendiosa é usar o Data Guard no modo de desempenho máximo para fins de recuperação de desastres. Se a perda potencial de dados no modo de desempenho máximo for muito alta, você poderá usar o modo de disponibilidade máxima com o mecanismo Oracle Data Guard Far Sync. Mas uma instância do Far Sync aciona o licenciamento do Ative Data Guard no ambiente principal e no ambiente de espera. Para obter mais informações, consulte Detalhes da licença Oracle.

Além disso, ao enviar dados entre regiões ou datacenters do Azure, você paga custos de saída por dados, como logs de refazer, que são enviados para um site de recuperação de desastres. Se você não precisar replicar todos os dados em seu banco de dados, poderá usar a replicação baseada no Oracle Golden Gate para replicar apenas dados parciais conforme necessário, o que reduz os custos de saída.

Para obter uma configuração passo a passo do Data Guard no Azure, consulte Implementar o Data Guard em uma VM Linux do Azure baseada em Linux.

Use o Golden Gate para recuperação de desastres

Golden Gate é um software de replicação lógica que você pode usar para replicação, filtragem e transformação em tempo real de dados de um banco de dados de origem para um banco de dados de destino ou entre vários bancos de dados primários. Esse recurso garante que as alterações no banco de dados de origem sejam replicadas quase em tempo real para que o banco de dados de destino esteja atualizado com os dados mais recentes.

Você pode usar o Golden Gate para replicar dados de um banco de dados primário para um banco de dados secundário em uma configuração de recuperação de desastre. Golden Gate é especialmente prático se você precisa proteger apenas alguns de seus dados. Para evitar a replicação de dados desnecessários, use o Golden Gate para replicar seletivamente tabelas e filtrar linhas de tabela durante a replicação.

Para obter um guia passo a passo sobre como implementar o Golden Gate no Azure, consulte Implementar o Golden Gate em uma VM do Azure baseada em Linux.

Usar backup para recuperação de desastres

Backup e restauração é um método tradicional para uma arquitetura de recuperação de desastres. Há dois componentes principais para backup como um método de recuperação de desastres para bancos de dados Oracle no Azure:

• Extraia e mova o backup de dados de um banco de dados para garantir que o site de recuperação de desastres tenha dados atualizados.

• Garanta uma implantação atualizada no local de recuperação de desastres. Para atualizar o site, replique a mesma implantação de todos os componentes de rede, servidores de aplicativos e configurações para o site de recuperação de desastres.

Há várias opções de backup que você pode usar para replicar dados. Para obter mais informações, consulte Estratégias de backup para o banco de dados Oracle no Azure.

Considere o uso de uma das seguintes abordagens para manter um local de recuperação de desastres:

Abordagem 1: Para evitar o esforço e o custo extra de manutenção, não mantenha nenhuma implantação física no local de recuperação de desastres. Você pode usar a infraestrutura como código e práticas de engenharia de confiabilidade do site para desenvolver e manter um repositório. Esse repositório pode replicar a implantação como configuração para um site de recuperação de desastres no momento do failover. Esse método otimiza o custo porque não usa nenhum recurso físico até que o failover ocorra.

Importante

Se você criar uma implantação inteira do zero durante um failover, deverá garantir que sua implantação possa atender aos requisitos de RTO da solução. Para garantir que o código de implantação não seja quebrado, você deve simular e testar rotineiramente o cenário de recuperação de desastres.

Abordagem 2: Implante e mantenha uma versão dimensionada do seu ambiente de produção. Tenha uma versão que possa funcionar corretamente para uma pequena carga de trabalho e que você possa potencialmente aumentar conforme necessário durante um failover para servir para carga de produção. Esse método é comumente usado, especialmente para implantações complexas nas quais você não quer correr o risco de criar um ambiente inteiro ou se deseja fazer failover rapidamente para fornecer um RTO baixo.

Abordagem 3: Implante e mantenha toda a sua solução no local de recuperação de desastres para obter os tempos de RTO e failover mais rápidos. Este método aumenta o custo devido à execução de uma infraestrutura totalmente redundante.

Considere outras maneiras de implementar a recuperação de desastres

As seções a seguir descrevem considerações especiais para a recuperação de desastres.

Usar o Far Sync

O Far Sync não melhora os recursos de alta disponibilidade, mas você pode usá-lo para obter recursos de proteção contra perda de dados zero para bancos de dados Oracle. Sua carga de trabalho pode exigir perda de dados zero se o banco de dados principal falhar. Para obter mais informações, consulte Arquiteturas de referência Oracle no Azure.

Escolha a tecnologia de replicação de dados certa

Além das tecnologias neste artigo, você pode usar qualquer tecnologia que facilite a replicação de dados em dois bancos de dados Oracle para manter uma réplica de alta disponibilidade e uma réplica de recuperação de desastres para seus bancos de dados Oracle no Azure. A tecnologia escolhida deve atender aos requisitos da sua solução nessas categorias.

Latência: o tempo necessário para replicar uma atualização de um banco de dados primário para bancos de dados secundários para alta disponibilidade e recuperação de desastres deve estar em conformidade com os requisitos da solução.

Largura de banda: a quantidade e o custo da largura de banda de que você precisa para replicar dados para bancos de dados secundários para alta disponibilidade e recuperação de desastres. O Azure fornece uma infraestrutura de rede de alta velocidade entre zonas de disponibilidade. Ao considerar a replicação para outras regiões do Azure para fins de recuperação de desastres, considere a quantidade de largura de banda e os custos de saída dos dados que saem do datacenter do Azure.

Impacto: o nível de impacto da replicação no processamento de transações no banco de dados principal deve estar em conformidade com os requisitos da solução.

Perda de dados: a quantidade de perda de dados que você espera durante uma falha abrupta do banco de dados primário deve estar em conformidade com os requisitos da sua solução.

Custo total de propriedade: considere o custo de aquisição de uma solução de replicação que não seja da Microsoft e a quantidade de esforço necessária para configurar e manter a solução de replicação. Verifique se esses fatores estão em conformidade com os requisitos da sua solução.

Otimizar uma instância de failover

Ao usar o Data Guard no modo de alta disponibilidade ou no modo de alta proteção, você pode configurar o failover automático para que, quando o servidor primário falhar, o servidor secundário seja acionado automaticamente. Ao configurar corretamente os servidores de aplicativos, você pode garantir que quase não tenha tempo de inatividade do aplicativo durante um failover.

Nessa implementação, um banco de dados deve executar o mesmo após um failover. Portanto, você precisa configurar um servidor secundário com a mesma CPU, memória e capacidade de entrada/saída (E/S) que o servidor primário. Você precisa manter uma alta capacidade com um servidor secundário, o que aumenta os custos do Azure e os custos de licença do Oracle Database. O servidor secundário geralmente não processa solicitações de usuários.

O Azure fornece 99,9% de disponibilidade para VMs em uma zona de disponibilidade. Para obter mais informações, consulte SLA de tempo de atividade da VM. Ao usar uma tecnologia de replicação de dados para manter uma réplica secundária do banco de dados na mesma zona de disponibilidade, em uma zona de disponibilidade diferente ou em uma região diferente, você pode otimizar a capacidade secundária.

Com essa abordagem, o banco de dados secundário é configurado com a capacidade necessária para permanecer atualizado. Quando ocorre uma falha, o banco de dados secundário é redimensionado para a mesma capacidade do banco de dados primário. Esta operação ocorre apenas se houver uma falha. Assim, durante a operação normal, você paga apenas por uma fração do custo do servidor primário. O banco de dados primário não está operacional durante a falha, portanto, você não precisa de outras licenças de banco de dados Oracle.

A capacidade necessária para operar um banco de dados secundário como destino de replicação depende da tecnologia de replicação usada. Essencialmente, uma carga de trabalho que está em um sistema de processamento de transações online transacionais (OLTP) tem principalmente solicitações de leitura. Por exemplo, 90% de operações de leitura e 10% de gravação ou 95% de operações de leitura e 5% de gravação são comuns em aplicativos OLTP. A replicação de dados essencialmente replica o resultado da gravação de solicitações no banco de dados de origem. Com essa configuração, você pode esperar que o banco de dados secundário opere com 1/10 (se você tiver uma taxa de leitura e gravação de 90%) da capacidade do banco de dados primário.

Automatize os procedimentos de failover para garantir que você atenda aos padrões corporativos durante o processo de failover. Você pode configurar os procedimentos de failover para incluir operações de redimensionamento de servidor que simplificam o processo de ponta a ponta.

Configure sua topologia de rede para proteção de serviços e proteção de dados

Para obter alta disponibilidade e recuperação de desastres, você precisa tomar decisões financeiras e de negócios que equilibrem o tempo de recuperação, ou RTO, e a perda potencial de dados, ou RPO, em relação a outros custos de licenciamento, manutenção de VM e transferência de dados da Oracle. Ao hospedar uma carga de trabalho em uma única VM do Azure, você obtém proteção básica para falhas comuns de hardware a um baixo custo. Mas uma falha em uma única VM provavelmente causa tempo de inatividade e perda de dados. Portanto, em seus ambientes de produção, inclua pelo menos um banco de dados Oracle secundário hospedado em uma VM separada com o Data Guard. Dependendo dos seus requisitos, use uma ou mais das seguintes configurações do Data Guard para replicação de dados:

• RTO e RPO ideais. Para minimizar a latência, incorpore um banco de dados Oracle secundário em uma VM separada dentro da mesma orquestração flexível de Conjuntos de Dimensionamento de Máquina Virtual e na mesma zona de disponibilidade do banco de dados primário. Essa configuração oferece alta disponibilidade e proteção contra uma falha de instância única.

• Proteção de dados contra uma falha no datacenter. Coloque o banco de dados Oracle secundário em uma segunda zona de disponibilidade para fornecer uma configuração de alta disponibilidade e fornecer proteção se uma zona de disponibilidade inteira falhar. Essa configuração pode ter até dois milissegundos de latência entre o banco de dados primário e secundário, o que pode afetar o desempenho, RTOs e RPOs.

• Proteção de dados contra uma falha regional. Para ajudar a proteger contra possíveis perdas de dados devido a uma falha regional do Azure, você pode colocar o banco de dados secundário em uma região diferente. Essa configuração pode ter entre 30 milissegundos e 300 milissegundos de latência entre regiões, portanto, você pode não atingir suas metas de RTO e RPO. Essa solução é melhor para recuperação de desastres regionais em vez de alta disponibilidade.

A continuidade de negócios requer uma abordagem integrada que inclua todos os componentes de uma carga de trabalho. A infraestrutura de rede é um componente principal para qualquer carga de trabalho no Azure. Sua infraestrutura de rede precisa estar alinhada com sua arquitetura de alta disponibilidade ou recuperação de desastres. Considere os seguintes fatores de infraestrutura de rede:

• O Data Guard fornece alta disponibilidade e, na maioria dos cenários, fornece suporte suficiente para falhas comuns. Você pode colocar VMs em uma orquestração flexível de Conjuntos de Escala de Máquina Virtual. Para reduzir a latência da rede, todos os serviços em uma única solução devem residir na mesma zona de disponibilidade e os serviços devem compartilhar a mesma rede virtual.

  Para maior proteção, você pode colocar as VMs estrategicamente em zonas de disponibilidade separadas, em vez de uma única zona de disponibilidade. Essa abordagem pode evitar o tempo de inatividade durante uma falha no datacenter.

• Para obter proteção máxima, você pode colocar um banco de dados secundário em uma região do Azure diferente da região do banco de dados primário. Para aplicar atualizações contínuas, você pode usar o Data Guard para implementar o emparelhamento de rede virtual global. Use essa abordagem para aplicar atualizações de dados à região secundária de forma privada por meio do backbone da Microsoft. Os recursos se comunicam diretamente sem gateways, saltos extras ou trânsito pela Internet pública.

  Esta opção de rede fornece uma conexão de alta largura de banda e baixa latência em redes virtuais emparelhadas em diferentes regiões. Você pode usar o emparelhamento de rede virtual global para conectar seu site principal a um site de recuperação de desastres em uma região diferente por meio de uma rede de alta velocidade.

Resumo da resiliência contra vários tipos de falhas

Cenário de falha	Oracle no cenário de alta disponibilidade ou recuperação de desastres do Azure	RPO/RTO
Falha de componente único, como host, rack, resfriamento, rede ou falha de energia	Data Guard com dois nós na mesma escala de máquina virtual Define orquestração flexível no mesmo datacenter: - Protege contra uma falha de instância única. - Causa tempo de inatividade se um datacenter inteiro falhar.	Se você usar o Observer para failover de início rápido e modo MAX_AVAILABILITY ou MAX_PROTECTION para o Data Guard: - RPO é zero. - RTO é menor ou igual a 2 min.
Falha do datacenter	Data Guard com dois nós em zonas de disponibilidade separadas: - Protege contra uma falha no datacenter. - Causa tempo de inatividade se uma região inteira falhar. - Requer mais configuração de failover para servidores de aplicativos para gerenciar a latência da rede.	- RPO é menor ou igual a 5 min. - RTO é menor ou igual a 5 min. Se você usar o modo MAX_PERFORMANCE e o modo MAX_AVAILABILITY para o Data Guard: - RPO é zero. - RTO é menor ou igual a 5 min.
Fracasso regional	Data Guard com dois nós em regiões separadas do Azure: - Protege contra falhas regionais. - Requer mais configuração de failover para servidores de aplicativos para gerenciar a latência da rede.	Se você usar MAX_PERFORMANCE modo para o Data Guard: - RPO é maior ou igual a 10 min. - RTO é maior ou igual a 15 min.
Todos os cenários: falha de um único componente, datacenter e região	Backups enviados para uma região diferente do Azure: - Proteger contra falhas regionais. - Exigir que um ambiente inteiro do Azure seja configurado na região de destino durante um failover.	- RPO é maior ou igual a 24 h. - RTO é maior ou igual a 4 h.

Próximo passo

Saiba mais sobre as considerações de design para a segurança do acelerador de zona de aterrissagem Oracle on Virtual Machines em um cenário de escala empresarial.

Diretrizes de segurança para o acelerador de zona de aterrissagem Oracle on Virtual Machines