Continuidade dos negócios e HADR para o SQL Server em VMs do Azure

Aplica-se a: SQL Server na VM do Azure

Este artigo compara e contrasta as soluções de continuidade dos negócios híbridas e somente do Azure que você pode usar para garantir alta disponibilidade e recuperação de desastre (HADR) com o SQL Server em Máquinas Virtuais (VMs) do Azure

A continuidade dos negócios significa continuar seus negócios em caso de desastre, planejar a recuperação e garantir que seus dados estejam altamente disponíveis. O SQL Server em Máquinas virtuais do Microsoft Azure com podem ajudar a reduzir o custo de uma solução de banco de dados HADR.

Observação

É possível migrar por lift-and-shift sua solução de instância de cluster de failover e grupo de disponibilidade para o SQL Server em VMs do Azure usando Migrações para Azure.

Visão geral

O SQL Server em VMs do Azure oferece suporte aos seguintes tipos de soluções:

• Somente Azure: todo o sistema de HADR é executado no Azure.
• Híbridas parte da solução é executada no Azure e outra parte é executada no local em sua organização.

A flexibilidade do ambiente do Azure permite que você se mova parcial ou completamente para o Azure para atender aos requisitos de orçamento e HADR de seus sistemas de banco de dados do SQL Server. Cabe a você garantir que seus sistemas de banco de dados tenham recursos de HADR que atendam aos seus requisitos de objetivo de tempo de recuperação (RTO), objetivo de ponto de recuperação (RPO) e contrato de nível de serviço (SLA).

Os mecanismos internos de alta disponibilidade fornecidos pelo Azure, como reparação de serviço para serviços de nuvem e detecção de recuperação de falha para máquinas virtuais, não garantem que você possa atender ao SLA, ao RTO ou ao RPO. Embora esses mecanismos ajudem a proteger a alta disponibilidade da máquina virtual, eles não protegem a disponibilidade do SQL Server em execução dentro da VM. É possível que a instância do SQL Server falhe enquanto a VM estiver online e íntegra. Até mesmo os mecanismos de alta disponibilidade fornecidos pelo Azure permitem tempo de inatividade das VMs em razão de eventos como recuperação de software ou falhas de hardware e atualizações do sistema operacional.

Recursos da continuidade dos negócios

A tabela a seguir lista os recursos de SQL Server híbridos e somente Azure que você pode usar para garantir alta disponibilidade (HA), recuperação de desastre (DR) ou ambos (HA/DR):

Esses recursos do SQL Server têm suporte para continuidade dos negócios em uma configuração híbrida ou somente Azure. Algumas das opções são ideais tanto para alta disponibilidade e recuperação de desastre (HA/DR) quanto para alta disponibilidade (HA), enquanto outras seriam usadas para recuperação de desastre (DR).

recursos do SQL Server	Opção de HA/DR	Detalhes
Grupos de Disponibilidade AlwaysOn	Alta disponibilidade e recuperação de desastre	Fornece proteção no nível do banco de dados, aumenta a alta disponibilidade e recuperação de desastre adicionando réplicas em zonas de disponibilidade e/ou regiões diferentes.
FCIs (Instâncias do cluster de failover) do Always On	Alta disponibilidade	Usa armazenamento compartilhado para fornecer proteção no nível da instância. Aumente a proteção no nível do banco de dados e da instância combinando com grupos de disponibilidade.
Envio de logs	Recuperação de desastre	A proteção no nível do banco de dados para recuperação de desastre envolve o envio de backup de log de transações de um servidor primário e sua restauração em um servidor secundário. É necessário um compartilhamento de arquivos do Azure.
Backup e restauração do SQL Server no serviço de Armazenamento de Blobs do Azure	Recuperação de desastre	Backups de banco de dados de produção armazenados no armazenamento de blobs do Azure para proteção e recuperação de desastre.
Azure Site Recovery	Recuperação de desastre	Uma solução de recuperação de desastre que replica VMs de um site primário para um site secundário.

Você pode combinar tecnologias para implementar uma solução do SQL Server com recursos de alta disponibilidade e recuperação de desastre. Dependendo da tecnologia usada, uma implantação híbrida pode exigir um túnel VPN com a rede virtual do Azure. Embora as tecnologias sejam as mesmas, pode haver algumas diferenças na maneira como são configuradas no Azure ou em um design híbrido.

Grupos de disponibilidade (HADR)

A proteção do SQL Server em VMs do Azure no nível do banco de dados pode ser feita usando grupos de disponibilidade como uma solução de alta disponibilidade e recuperação de desastre (HADR). Réplicas de disponibilidade sendo executadas em VMs do Azure na mesma região fornecem alta disponibilidade. É necessária uma VM de controlador de domínio porque o clustering de failover do Windows requer um domínio do Active Directory.

Para começar, examine otutorial do grupo de disponibilidade.

Para garantir maior redundância, disponibilidade e proteção para recuperação de desastre, as VMs do Azure podem ser implantadas em zonas de disponibilidade diferentes, como documentado na visão geral sobre grupo de disponibilidade. A expansão das réplicas de disponibilidade para execução em vários datacenters em VMs do Azure adiciona mais cobertura de recuperação de desastre. Uma solução entre regiões ajuda a proteger contra uma total interrupção do site.

Dentro de uma região, todas as réplicas devem estar dentro do mesmo serviço de nuvem e na mesma rede virtual. Como cada região tem uma rede virtual separada, essas soluções exigem conectividade de rede para rede. Para saber mais, consulte Configurar uma conexão rede para rede o portal do Azure. Para obter instruções detalhadas, confira Configurar um grupo de disponibilidade do SQL Server Always On em diferentes regiões do Azure.

Em uma configuração híbrida, algumas réplicas de disponibilidade são executadas em VMs do Azure e outras réplicas são executadas no local para recuperação de desastre entre sites. O site de produção pode ser local ou em um datacenter do Azure.

Como todas as réplicas de disponibilidade devem estar no mesmo cluster de failover, o cluster deve abranger as duas redes (um cluster de failover de várias sub-redes). Essa configuração requer uma conexão VPN entre o Azure e a rede local.

Para recuperação de desastres bem-sucedida de seus bancos de dados, você também deve instalar um controlador de domínio de réplica no local da recuperação de desastres. Para começar, examine otutorial do grupo de disponibilidade.

Instâncias de cluster de failover (HA)

O SQL Server em VMs do Azure oferece suporte a instâncias de cluster de failover (FCI) e essa solução fornece alta disponibilidade no nível da instância. Para garantir mais proteção, você pode criar redundância no nível do banco de dados e no nível da instância criando grupos de disponibilidade além das instâncias de cluster de failover. O recurso de FCI requer armazenamento compartilhado e existem cinco soluções que funcionam com o SQL Server em VMs do Azure:

• Usar discos compartilhados do Azure para o Windows Server 2019. Discos gerenciados compartilhados são um produto do Azure que permite anexar um disco gerenciado a várias máquinas virtuais simultaneamente. As VMs no cluster podem ler ou gravar no disco anexado com base na reserva escolhida pelo aplicativo clusterizado usando Reservas Persistentes de SCSI (PR SCSI). As PR SCSI são um padrão do setor utilizado por aplicativos executados na SAN (Rede de Área de Armazenamento) local. Habilitar as PR SCSI em um disco gerenciado permite migrar esses aplicativos para o Azure no estado em que se encontram.

• Usar espaços de armazenamento diretos (S2D) para fornecer uma SAN virtual baseada em software para o Windows Server 2016 e posteriores.

• Usar um compartilhamento de arquivos Premium para o Windows Server 2012 e posteriores. Os compartilhamentos de arquivos Premium são apoiados em SSD, têm baixa latência consistentemente e têm suporte total para uso com FCI.

• Usar armazenamento com o suporte de uma solução de parceiro para clustering. Para um exemplo específico que usa o SIOS Datakeeper, consulte a entrada de blog Clustering de failover e SIOS Datakeeper.

• Usar o armazenamento em bloco compartilhado para um destino iSCSI remoto por meio do Azure ExpressRoute. Por exemplo, o NPS (Armazenamento Privado do NetApp) expõe um destino iSCSI por meio do ExpressRoute com o Equinix para VMs do Azure.

Para soluções de replicação de dados e armazenamento compartilhado de parceiros da Microsoft, contate o fornecedor para solucionar problemas relacionados ao acesso a dados no failover.

Para começar, prepare a sua VM para FCI.

Envio de logs (DR)

Outra solução de recuperação de desastre no Azure é o envio de logs, que envia automaticamente backups de log de transações de um banco de dados primário em um servidor primário para um ou mais bancos de dados secundários em um servidor secundário separado. A configuração do envio de logs usa um compartilhamento de arquivos do Azure para armazenar os backups de logs de transações.

Se você precisar configurar o envio de logs em um ambiente híbrido, um servidor ficará localizado em uma VM do Azure e o outro ficará no local para permitir a recuperação de desastre entre sites. O envio de log depende do compartilhamento de arquivos do Windows, assim, uma conexão VPN entre a rede virtual do Azure e a rede local é necessária.

Para recuperação de desastres bem-sucedida de seus bancos de dados, você também deve instalar um controlador de domínio de réplica no local da recuperação de desastres.

Backup e restauração (DR)

É necessário efetuar backup dos bancos de dados de produção para recuperação de desastre. No Azure, você pode fazer backup dos bancos de dados diretamente no armazenamento de blobs em outro datacenter para recuperação de desastre.

Em uma solução híbrida, o backup de bancos de dados de produção no local pode ser feito diretamente no armazenamento de blobs do Azure para recuperação de desastre.

Para saber mais, consulte Backup e Restauração para o SQL Server em Máquinas Virtuais do Azure.

Replicar com o Azure Site Recovery (DR)

O Azure Site Recovery pode ser usado como uma solução de recuperação de desastre tanto em uma configuração do Azure quanto em uma configuração híbrida.

Dentro do Azure, a instância de produção do SQL Server em um datacenter do Azure é replicada diretamente para o Armazenamento do Azure em outro datacenter do Azure para recuperação de desastre.

Para ambientes híbridos, uma instância do SQL Server de produção no local é replicada diretamente no Armazenamento do Microsoft Azure para recuperação de desastre.

Para obter mais informações, consulte Proteger o SQL Server usando a recuperação de desastre do SQL Server e o Azure Site Recovery.

Réplica de DR gratuita no Azure

Se você tem o Software Assurance, pode implementar planos de DR (recuperação de desastre) híbridos com o SQL Server sem custos de licenciamento adicionais para a instância de recuperação de desastre passiva. Você também se qualifica para réplicas de DR sem licença com licenciamento pré-pago se todas as réplicas estiverem hospedadas no Azure.

Por exemplo, você pode ter dois secundários passivos gratuitos quando todas as três réplicas são hospedadas no Azure:

Ou você pode configurar um ambiente de failover híbrido, com um primário licenciado local, um passivo gratuito para HA, um passivo gratuito para DR local e um passivo gratuito para DR no Azure:

Para obter mais informações, confira os termos de licenciamento de produtos.

Para habilitar esse benefício, vá para seu Recurso de máquina virtual do SQL Server. Selecione Configurar em Configurações e escolha a opção HA/DR em Licença do SQL Server e, em seguida, selecione Aplicar para salvar as configurações. Observe que, quando todas as três réplicas são hospedadas no Azure, os clientes que realizam pagamento conforme o uso também têm o direito de usar o tipo de licença HA/DR.

Considerações importantes para HADR do SQL Server no Azure

VMs do Azure, armazenamento e rede têm características operacionais diferentes da infraestrutura de TI não virtualizada local. Uma implementação bem-sucedida de uma solução HADR do SQL Server no Azure requer que você compreenda essas diferenças e crie sua solução para acomodá-las.

Nós de alta disponibilidade em um conjunto de disponibilidade

Conjuntos de disponibilidade no Azure permitem que você coloque os nós de alta disponibilidade em domínios de falha e domínios de atualização separados. A plataforma do Azure atribui um domínio de atualização e um domínio de falha para cada máquina virtual do conjunto de disponibilidade. Essa configuração em um datacenter garante que durante um evento de manutenção planejada ou não planejada, pelo menos uma máquina virtual estará disponível e atenderá os SLA do Azure de 99,95%.

Para configurar a instalação de alta disponibilidade, coloque todas as máquinas virtuais do SQL Server participantes no mesmo conjunto de disponibilidade para evitar a perda de aplicativos ou dados durante um evento de manutenção. Somente nós no mesmo serviço de nuvem podem participar do mesmo conjunto de disponibilidade. Para saber mais, veja Gerenciar a disponibilidade de máquinas virtuais.

Nós de alta disponibilidade em uma zona de disponibilidade

As zonas de disponibilidade são locais físicos exclusivos em uma região do Azure. Cada zona é composta por um ou mais datacenters equipados com energia, resfriamento e rede independentes. A separação física das zonas de disponibilidade dentro de uma região ajuda a proteger os aplicativos e os dados contra falhas do datacenter, garantindo que pelo menos uma máquina virtual esteja disponível e atenda aos SLA de 99,99% do Azure.

Para configurar a alta disponibilidade, coloque as máquinas virtuais do SQL Server participantes espalhadas por zonas de disponibilidade disponíveis na região. Haverá encargos adicionais para transferências de rede para rede entre zonas de disponibilidade. Para obter mais informações, confira Zonas de disponibilidade.

Latência de rede em TI híbrida

Implante sua solução HADR supondo que pode haver períodos com alta latência da rede entre sua própria rede local e o Azure. Ao implantar réplicas no Azure, você deve usar a confirmação assíncrona, em vez de confirmação síncrona, para o modo de sincronização. Ao implantar servidores de espelhamento de banco de dados localmente e no Azure, use o modo de alto desempenho, em vez do modo de alta segurança.

Confira as práticas recomendadas de configuração do HADR para configurações de cluster e HADR que podem ajudar a acomodar o ambiente de nuvem.

Suporte para replicação geográfica

A replicação geográfica em discos do Azure não oferece suporte ao arquivo de dados e ao arquivo de log do mesmo banco de dados a ser armazenado em discos separados. GRS replica as alterações em cada disco, de forma independente e assíncrona. Esse mecanismo garante a ordem de gravação em um único disco na cópia replicada geograficamente, mas não em cópias replicadas geograficamente de vários discos. Se você configurar um banco de dados para armazenar arquivo de dados e arquivo de log em discos separados, os discos recuperados após um desastre poderão conter uma cópia mais recente do arquivo de dados do que o arquivo de log, interrompendo o log write-ahead no SQL Server e as propriedades ACID (atomicidade, consistência, isolamento e durabilidade) das transações.

Se você não tiver a opção de desabilitar a replicação geográfica na conta de armazenamento, mantenha todos os dados e arquivos de log em um banco de dados no mesmo disco. Se você precisar usar mais de um disco devido ao tamanho do banco de dados, implante uma das soluções de recuperação de desastres listadas anteriormente para garantir a redundância dos dados.

Próximas etapas

Decida se um grupo de disponibilidade ou uma instância de cluster de failover é a melhor solução de continuidade de negócios para sua empresa. Em seguida, examine as melhores práticas para configurar seu ambiente para alta disponibilidade e recuperação de desastres.