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

Este artigo se baseia nas 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). Este artigo segue essas diretrizes e descreve as considerações de design e as práticas recomendadas sobre as opções de BCDR para implantações de carga de trabalho do Oracle em VMs (máquinas virtuais) 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 desastre para bancos de dados Oracle no acelerador de zona de destino de Máquinas Virtuais do Azure. Ele também descreve como configurar os serviços do Azure que acompanham para ajudá-lo a obter alta disponibilidade de ponta a ponta para sua solução.

Introdução

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 (objetivo de tempo de recuperação) e no RPO (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 no Azure usam principalmente o Oracle Data Guard, que é um recurso integrado do Oracle Database Enterprise Edition que usa 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 em seus requisitos específicos de RPO e RTO.

Configurar sua carga de trabalho para alta disponibilidade

As instâncias de Máquinas Virtuais do Azure que executam cargas de trabalho do Oracle se beneficiam da arquitetura dos Conjuntos de Dimensionamento de Máquinas Virtuais 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 ou no nível da região do Azure.

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áquinas Virtuais, o Azure fornece 99,95% de disponibilidade de serviço para um SLA (contrato de nível de serviço) para instâncias distribuídas entre domínios de falha. O Azure fornece 99,99% de disponibilidade de serviço para instâncias distribuídas entre zonas de disponibilidade. Para obter mais informações, consulte Alta disponibilidade para Conjuntos de Dimensionamento de Máquinas Virtuais.

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 transacionalmente 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 stand-by não está disponível. Portanto, apesar de usar a orquestração flexível de Conjuntos de Dimensionamento 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 a 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 de menos de dois milissegundos. Normalmente, você usa zonas de disponibilidade para fins de recuperação de desastre, mas pode usá-las para melhorar a alta disponibilidade. Se você fizer isso, deverá garantir que sua solução possa 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 Dimensionamento de Máquinas Virtuais é 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 Azure NetApp Files como armazenamento compartilhado para instâncias de cluster do 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 é alterado entre failovers.

Observação

Um cluster PCS não é uma solução certificada pela Oracle. Lembre-se desse fator ao escolher sua arquitetura de alta disponibilidade.

Usar grupos de posicionamento de 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 por proximidade. Um grupo de posicionamento por 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 por proximidade são úteis para cargas de trabalho que exigem baixa latência.

Configurar sua carga de trabalho para recuperação de desastre

Uma arquitetura de recuperação de desastre fornece resiliência contra falhas que afetam datacenters ou regiões do Azure ou contra falhas que prejudicam a funcionalidade do aplicativo em uma região inteira. 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 desastre 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 excepcionais, 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 flexíveis para RTO e RPO, o que economiza dinheiro.

Este artigo se concentra em cenários em que o servidor primário e os servidores secundários estão 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 desastre. Para obter mais informações, consulte Site primário local e site de recuperação de desastre 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 desastre 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 de seus requisitos de proteção de dados. Sua configuração também depende da estrutura da zona de disponibilidade em seu site 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 Azure Load Balancer para redirecionar solicitações para a nova instância de banco de dados primário.

• 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, você normalmente precisa configurar o failover para serviços de aplicativo.

Se o site de recuperação de desastre estiver em outra região, você precisará projetar o site para o failover, dependendo de seus requisitos.

A latência em um único datacenter é menor do que a latência entre datacenters separados uns dos outros e muito menor do que a latência entre regiões diferentes. 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 Active Data Guard no ambiente principal e no ambiente em espera. Para obter mais informações, consulte Detalhes da licença do Oracle.

Além disso, ao enviar dados entre regiões ou datacenters do Azure, você paga os custos de saída dos dados, como logs de restauração, que são enviados para um site de recuperação de desastre. 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.

Usar a Golden Gate para recuperação de desastres

O 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. A Golden Gate é especialmente prática se você precisar proteger apenas alguns de seus dados. Para evitar a replicação de dados desnecessários, use o Golden Gate para replicar tabelas seletivamente 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

O backup e a restauração sã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 desastre 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 Oracle Database no Azure.

Considere usar uma das seguintes abordagens para manter um site de recuperação de desastre:

Abordagem 1: para evitar o esforço e o custo extras de manutenção, não mantenha nenhuma implantação física no local de recuperação de desastre. Você pode usar a infraestrutura como código e as 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 desastre no momento do failover. Esse método otimiza o custo porque não usa nenhum recurso físico até que ocorra o failover.

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

Abordagem 2: Implante e mantenha uma versão dimensionada do seu ambiente de produção. Ter uma versão que possa funcionar corretamente para uma pequena carga de trabalho e que você possa escalar verticalmente conforme necessário durante um failover para atender à carga de produção. Esse método é comumente usado, especialmente para implantações complexas nas quais você não deseja arriscar a criação de um ambiente inteiro ou se quiser fazer failover rapidamente para fornecer um RTO baixo.

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

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

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

Usar sincronização distante

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 zero de dados se o banco de dados primário falhar. Para obter mais informações, consulte Arquiteturas de referência da 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 desastre para seus bancos de dados Oracle no Azure. A tecnologia escolhida deve atender aos requisitos da solução nessas categorias.

Latência: a quantidade de tempo necessária 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 desastre deve estar em conformidade com os requisitos da sua solução.

Largura de banda: a quantidade e o custo da largura de banda necessários para replicar dados em 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 desastre, 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 que a replicação tem no processamento de transações no banco de dados primário deve estar em conformidade com os requisitos da sua solução.

Perda de dados: a quantidade de perda de dados esperada durante uma falha abrupta do banco de dados primário deve estar em conformidade com os requisitos da 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 ativado 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 ser executado da mesma forma após um failover. Portanto, você precisa configurar um servidor secundário com a mesma capacidade de CPU, memória e E/S (entrada/saída) do 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 que o banco de dados primário. Essa operação ocorrerá somente se houver uma falha. Portanto, durante a operação normal, você paga apenas 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 OLTP (processamento de transações online) transacional 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 replica essencialmente o resultado das solicitações de gravação 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ço 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 custo baixo. 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 de 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 dos Conjuntos de Dimensionamento de Máquinas Virtuais e na mesma zona de disponibilidade que o banco de dados primário. Essa configuração fornece alta disponibilidade e proteção contra uma falha de instância única.

• Proteção de dados contra uma falha de datacenter. Coloque o banco de dados Oracle secundário em uma segunda zona de disponibilidade para fornecer uma configuração de alta disponibilidade e 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ível perda 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, talvez você não atinja suas metas de RTO e RPO. Essa solução é melhor para recuperação de desastre regional em vez de alta disponibilidade.

A continuidade dos negócios requer uma abordagem integrada que inclua todos os componentes de uma carga de trabalho. A infraestrutura de rede é um componente primário 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 Dimensionamento de Máquinas Virtuais. Para reduzir a latência de 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 obter mais proteção, você pode colocar estrategicamente as VMs em zonas de disponibilidade separadas, em vez de uma única zona de disponibilidade. Essa abordagem pode evitar o tempo de inatividade durante uma falha do datacenter.

• Para 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 pareamento 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.

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

Resumo da resiliência em relação a vários tipos de falha

Cenário de falha	Cenário de alta disponibilidade ou recuperação de desastre do Oracle no Azure	RPO/RTO
Falha de componente único, como host, rack, resfriamento, rede ou falha de energia	Data Guard com dois nós no mesmo Conjuntos de Dimensionamento de Máquinas Virtuais 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 MAX_AVAILABILITY ou modo MAX_PROTECTION para o Data Guard: - RPO é zero. - O 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 de datacenter. - Causa tempo de inatividade se uma região inteira falhar. - Requer mais configuração de failover para que os servidores de aplicativos gerenciem a latência da rede.	- O RPO é menor ou igual a 5 min. - O 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. - O RTO é menor ou igual a 5 min.
Falha regional	Data Guard com dois nós em regiões separadas do Azure: - Protege contra falhas regionais. - Requer mais configuração de failover para que os servidores de aplicativos gerenciem a latência da rede.	Se você usar MAX_PERFORMANCE modo para o Data Guard: - O RPO é maior ou igual a 10 min. - O RTO é maior ou igual a 15 min.
Todos os cenários: um único componente, datacenter e falha de 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. - O RTO é maior ou igual a 4 h.

Próxima etapa

Saiba mais sobre as considerações de design para a segurança do acelerador de zona de destino do Oracle em Máquinas Virtuais em um cenário de escala empresarial.

Diretrizes de segurança para o acelerador de zona de destino do Oracle em Máquinas Virtuais