Continuidade de negócios e HADR para o SQL Server em Máquinas Virtuais do Azure

Aplicável a:SQL Server na VM 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.

A maioria das soluções HADR do SQL Server tem suporte em máquinas virtuais, tanto soluções híbridas como somente Azure. Em uma solução somente Azure, todo o sistema HADR é executado no Azure. Em uma configuração híbrida, parte da solução é executada no Azure e a outra parte é executada localmente 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.

Este artigo compara e contrasta as soluções de continuidade de negócios disponíveis para o SQL Server em VMs do Azure.

Visão geral

Você é o responsável por garantir que seu sistema de banco de dados possua os recursos HADR exigidos pelo SLA (Contrato de Nível de Serviço). O fato de que o Azure fornece mecanismos de alta disponibilidade, como recuperação de serviço para serviços de nuvem e detecção de recuperação de falhas para máquinas virtuais, não é garantia de que você possa atender ao SLA. 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.

O GRS (armazenamento com redundância geográfica) no Azure é implementado com um recurso chamado replicação geográfica. GRS pode não ser uma solução de recuperação de desastre adequada para seus bancos de dados. Como a replicação geográfica envia dados de forma assíncrona, atualizações recentes podem ser perdidas em um desastre. Mais informações sobre as limitações da replicação geográfica são abordadas na seção suporte à replicação geográfica.

Observação

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

Arquiteturas de implantação

O Azure dá suporte a essas tecnologias do SQL Server para continuidade dos negócios:

• Grupos de Disponibilidade AlwaysOn
• FCIs (Instâncias do cluster de failover) do Always On
• Envio de logs
• Backup e restauração do SQL Server no serviço de Armazenamento de Blobs do Azure
• Espelhamento de banco de dados - preterido no SQL Server 2016
• Azure Site Recovery

Você pode combinar as tecnologias para implementar uma solução do SQL Server com alta disponibilidade e recursos de 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. As seções a seguir mostram algumas das arquiteturas de implantação de exemplo.

Somente Azure: soluções de alta disponibilidade

É possível ter uma solução de alta disponibilidade para o SQL Server em um nível de banco de dados com Grupos de Disponibilidade AlwaysOn. Você também pode criar uma solução de alta disponibilidade no nível da instância com Instâncias de Cluster de Failover do Always On. Para adicionar proteção, crie a redundância nos dois níveis, criando grupos de disponibilidade em instâncias de cluster de failover.

Tecnologia	Arquiteturas de exemplo
Grupos de disponibilidade	As réplicas de disponibilidade em execução em VMs do Azure para a mesma região fornecem alta disponibilidade. Você precisa configurar uma VM de controlador de domínio, porque o clustering de failover do Windows exige um domínio do Active Directory. Para maior redundância e disponibilidade, as VMs do Azure podem ser implantadas em diferentes zonas de disponibilidade conforme documentado na visão geral sobre grupo de disponibilidade. Para começar, examine otutorial do grupo de disponibilidade.
Instâncias de cluster de failover	As instâncias de cluster de failover têm suporte em VMs do SQL Server. Como o recurso FCI requer armazenamento compartilhado, cinco soluções funcionarão com o SQL Server em VMs do Azure: - Usando 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. - Usando Espaços de Armazenamento Diretos (S2D) para fornecer uma SAN virtual baseada em software para o Windows Server 2016 e posterior. - Usando um Compartilhamento de arquivos Premium para o Windows Server 2012 e posterior. 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. - Usando o armazenamento com 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. - Usando o armazenamento de 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 VM para FCI

Somente Azure: soluções de recuperação de desastre

Você pode ter uma solução de recuperação de desastres para seus bancos de dados do SQL Server no Azure usando Grupos de Disponibilidade, espelhamento de banco de dados ou backup e restauração com blobs de armazenamento.

Tecnologia	Arquiteturas de exemplo
Grupos de disponibilidade	Réplicas de disponibilidade executadas em vários datacenters em VMs do Azure para recuperação de desastres. Essa solução de região cruzada ajuda a proteger contra uma interrupção completa 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 terá 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.
Espelhamento de banco de dados	Servidores principal e de espelho em execução em diferentes datacenters para recuperação de desastres. Você deve implantá-los usando certificados do servidor.
Backup e restauração com o armazenamento de Blob do Azure	Bancos de dados de produção com backup direto no armazenamento de Blob em um datacenter diferente para recuperação de desastre. Para saber mais, consulte Backup e Restauração para o SQL Server em VMs do Azure.
Replicação e failover do SQL Server para o Azure com o Azure Site Recovery	Instância SQL Server de produção de um datacenter do Azure replicado diretamente para o Armazenamento do Microsoft Azure em um datacenter diferente do 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.

TI Híbrida: Soluções de recuperação de desastre

Você pode ter uma solução de recuperação de desastres para bancos de dados do SQL Server em um ambiente de TI híbrido, usando Grupos de disponibilidade, espelhamento de banco de dados, envio de log e backup e restauração com o armazenamento de Blobs do Azure.

Tecnologia	Arquiteturas de exemplo
Grupos de disponibilidade	Algumas réplicas de disponibilidade executadas em VMs do Azure e outras réplicas executadas localmente para recuperação de desastres intersite. 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.
Espelhamento de banco de dados	Um parceiro executado em uma VM do Azure e o outro executado localmente para recuperação de desastres intersite usando certificados de servidor. Os parceiros não precisam estar no mesmo domínio do Active Directory e nenhuma conexão VPN é necessária. Outro cenário que o espelhamento de banco de dados envolve é um parceiro em execução em uma VM do Azure e o outro em execução localmente no mesmo domínio do Active Directory para recuperação de desastres intersite. 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.
Envio de logs	Um servidor em execução em uma VM do Azure e outro em execução local para recuperação de desastre intersite. 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 com o armazenamento de Blob do Azure	Bancos de dados de produção local com backup diretamente no armazenamento de Blobs do Azure para recuperação de desastres. Para saber mais, consulte Backup e Restauração para o SQL Server em Máquinas Virtuais do Azure.
Replicação e failover do SQL Server para o Azure com o Azure Site Recovery	Instância SQL Server de produção local replicado 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 Definir em Configurações e escolha a opção HA/DR em Licença do SQL Server. Marque a opção de seleção para confirmar que esta VM do SQL Server será usada como uma réplica passiva e selecione Aplicar para salvar suas 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 local, não virtualizada. 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 dá 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.