Cluster de Failover do Windows Server com o SQL Server em VMs do Azure

Aplica-se a:SQL Server na VM do Azure

Este artigo descreve as diferenças ao usar o recurso Cluster de Failover do Windows Server com o SQL Server em VMs do Azure para alta disponibilidade e recuperação de desastres (HADR), como para grupos de disponibilidade Always On (AG) ou instâncias de cluster de failover (FCI).

Para saber mais sobre o recurso do Windows em si, consulte a documentação do Cluster de Failover do Windows Server.

Descrição geral

As soluções de alta disponibilidade do SQL Server no Windows, como grupos de disponibilidade Always On (AG) ou instâncias de cluster de failover (FCI), dependem do serviço WSFC (Cluster de Failover do Windows) subjacente.

O serviço de cluster monitora as conexões de rede e a integridade dos nós no cluster. Esse monitoramento é adicional às verificações de integridade que o SQL Server faz como parte do grupo de disponibilidade ou do recurso de instância de cluster de failover. Se o serviço de cluster não conseguir alcançar o nó ou se a função AG ou FCI no cluster não estiver íntegra, o serviço de cluster iniciará as ações de recuperação apropriadas para recuperar e colocar aplicativos e serviços online, no mesmo nó ou em outro nó do cluster.

Monitoramento da integridade do cluster

Para fornecer alta disponibilidade, o cluster deve garantir a integridade dos diferentes componentes que compõem a solução clusterizada. O serviço de cluster monitora a integridade do cluster com base em vários parâmetros do sistema e da rede para detetar e responder a falhas.

Estabelecer o limite para declarar uma falha é importante para alcançar um equilíbrio entre responder prontamente a uma falha e evitar falsas falhas.

Existem duas estratégias de monitorização:

A monitorizar	Description
Agressivo	Fornece deteção rápida de falhas e recuperação de falhas graves, o que proporciona os mais altos níveis de disponibilidade. O serviço de cluster e o SQL Server perdoam menos falhas transitórias e, em algumas situações, podem fazer failover prematuro de recursos quando há interrupções transitórias. Uma vez detetada uma falha, a ação corretiva que se segue pode demorar mais tempo.
Descontraído	Fornece uma deteção de falhas mais tolerante com uma maior tolerância para breves problemas transitórios de rede. Evita falhas transitórias, mas também introduz o risco de atrasar a deteção de uma falha verdadeira.

Configurações agressivas em um ambiente de cluster na nuvem podem levar a falhas prematuras e interrupções mais longas, portanto, uma estratégia de monitoramento relaxada é recomendada para clusters de failover em VMs do Azure. Para ajustar as configurações de limite, consulte as práticas recomendadas de cluster para obter mais detalhes.

Batimento cardíaco em cluster

As principais configurações que afetam o batimento cardíaco do cluster e a deteção de integridade entre nós:

Definição	Description
Atraso	Isso define a frequência na qual as pulsações do cluster são enviadas entre nós. O atraso é o número de segundos antes do próximo batimento cardíaco ser enviado. Dentro do mesmo cluster pode haver diferentes configurações de atraso configuradas entre nós na mesma sub-rede e entre nós que estão em sub-redes diferentes.
Limiar	O limite é o número de pulsações que podem ser perdidas antes que o cluster execute uma ação de recuperação. Dentro do mesmo cluster pode haver diferentes configurações de limite configuradas entre nós na mesma sub-rede e entre nós que estão em sub-redes diferentes.

Os valores padrão para essas configurações podem ser muito baixos para ambientes de nuvem e podem resultar em falhas desnecessárias devido a problemas transitórios de rede. Para ser mais tolerante, use configurações de limite relaxadas para clusters de failover em VMs do Azure. Consulte as práticas recomendadas de cluster para obter mais detalhes.

Quórum

Embora um cluster de dois nós funcione sem um recurso de quorum, os clientes são estritamente obrigados a usar um recurso de quorum para ter suporte à produção. A validação de cluster não passará por nenhum cluster sem um recurso de quorum.

Tecnicamente, um cluster de três nós pode sobreviver a uma perda de único nó (até dois nós) sem um recurso de quorum. Mas depois que o cluster é reduzido a dois nós, há um risco de que os recursos clusterizados fiquem offline para evitar um cenário de cérebro dividido se um nó for perdido ou houver uma falha de comunicação entre os nós. A configuração de um recurso de quorum permitirá que os recursos do cluster permaneçam online com apenas um nó online.

A testemunha de disco é a opção de quorum mais resiliente, mas para usar uma testemunha de disco em um SQL Server na VM do Azure, você deve usar um Disco Compartilhado do Azure que impõe algumas limitações à solução de alta disponibilidade. Como tal, use uma testemunha de disco quando estiver configurando sua instância de cluster de failover com os Discos Compartilhados do Azure, caso contrário, use uma testemunha de nuvem sempre que possível.

A tabela a seguir lista as opções de quorum disponíveis para o SQL Server em VMs do Azure:

	Testemunha da nuvem	Testemunha de disco	Testemunha de compartilhamento de arquivos
SO suportado	Windows Server 2016+	Tudo	Tudo
Descrição	Uma testemunha de nuvem é um tipo de testemunha de quorum de cluster de failover que usa o Microsoft Azure para fornecer uma votação sobre o quórum de cluster. O tamanho padrão é de cerca de 1 MB e contém apenas o carimbo de data/hora. Uma testemunha de nuvem é ideal para implantações em vários locais, várias zonas e várias regiões. Use uma testemunha de nuvem sempre que possível, a menos que você tenha uma solução de cluster de failover com armazenamento compartilhado.	Uma testemunha de disco é um pequeno disco clusterizado no grupo Armazenamento Disponível em Cluster. Este disco é altamente disponível e pode fazer failover entre nós. Ele contém uma cópia do banco de dados de cluster, com um tamanho padrão inferior a 1 GB. A testemunha de disco é a opção de quorum preferida para qualquer cluster que use Discos Compartilhados do Azure (ou qualquer solução de disco compartilhado, como SCSI compartilhado, iSCSI ou SAN de canal de fibra). Um Volume Compartilhado Clusterizado não pode ser usado como testemunha de disco. Configure um disco compartilhado do Azure como testemunha de disco.	Uma testemunha de compartilhamento de arquivos é um compartilhamento de arquivos SMB normalmente configurado em um servidor de arquivos que executa o Windows Server. Ele mantém informações de clustering em um arquivo .log testemunha, mas não armazena uma cópia do banco de dados do cluster. No Azure, você pode configurar um compartilhamento de arquivos em uma máquina virtual separada dentro da mesma rede virtual. Use uma testemunha de compartilhamento de arquivos se uma testemunha de disco ou testemunha de nuvem não estiver disponível em seu ambiente.

Para começar, consulte Configurar quórum de cluster.

Nome de rede virtual (VNN)

Para corresponder à experiência local de conexão com seu ouvinte de grupo de disponibilidade ou instância de cluster de failover, implante suas VMs do SQL Server em várias sub-redes dentro da mesma rede virtual. Ter várias sub-redes nega a necessidade da dependência extra de um Balanceador de Carga do Azure para rotear o tráfego para sua solução HADR. Para saber mais, consulte Multi-sub-net AG, e Multi-sub-net FCI.

Em um ambiente local tradicional, recursos clusterizados, como instâncias de cluster de failover ou grupos de disponibilidade Always On, dependem do Nome da Rede Virtual para rotear o tráfego para o destino apropriado - a instância de cluster de failover ou o ouvinte do grupo de disponibilidade Always On. O nome virtual vincula o endereço IP no DNS, e os clientes podem usar o nome virtual ou o endereço IP para se conectar ao destino de alta disponibilidade, independentemente de qual nó possui atualmente o recurso. A VNN é um nome e endereço de rede gerenciados pelo cluster, e o serviço de cluster move o endereço de rede de nó para nó durante um evento de failover. Durante uma falha, o endereço é colocado offline na réplica primária original e colocado online na nova réplica primária.

Nas Máquinas Virtuais do Azure em uma única sub-rede, um componente adicional é necessário para rotear o tráfego do cliente para o Nome da Rede Virtual do recurso clusterizado (instância de cluster de failover ou ouvinte de um grupo de disponibilidade). No Azure, um balanceador de carga mantém o endereço IP da VNN na qual os recursos clusterizados do SQL Server dependem e é necessário para rotear o tráfego para o destino de alta disponibilidade apropriado. O balanceador de carga também deteta falhas com os componentes de rede e move o endereço para um novo host.

O balanceador de carga distribui fluxos de entrada que chegam ao front-end e, em seguida, roteia esse tráfego para as instâncias definidas pelo pool de back-end. Configure o fluxo de tráfego usando regras de balanceamento de carga e testes de integridade. Com a FCI do SQL Server, as instâncias do pool de back-end são as máquinas virtuais do Azure que executam o SQL Server e, com grupos de disponibilidade, o pool de back-end é o ouvinte. Há um ligeiro atraso de failover quando você está usando o balanceador de carga, porque a sonda de integridade realiza verificações ativas a cada 10 segundos por padrão.

Para começar, saiba como configurar o Balanceador de Carga do Azure para uma instância de cluster de failover ou um grupo de disponibilidade.

SO suportado: Todos
Versão SQL suportada: Todos
Solução HADR suportada: instância de cluster de failover e grupo de disponibilidade

A configuração da VNN pode ser complicada, é uma fonte adicional de falha, pode causar um atraso na deteção de falhas e há uma sobrecarga e um custo associados ao gerenciamento do recurso adicional. Para resolver algumas dessas limitações, o SQL Server introduziu suporte para o recurso Nome da Rede Distribuída.

Nome de rede distribuída (DNN)

Para corresponder à experiência local de conexão com seu ouvinte de grupo de disponibilidade ou instância de cluster de failover, implante suas VMs do SQL Server em várias sub-redes dentro da mesma rede virtual. Ter várias sub-redes nega a necessidade da dependência extra de uma DNN para rotear o tráfego para sua solução HADR. Para saber mais, consulte Multi-sub-net AG, e Multi-sub-net FCI.

Para VMs do SQL Server implantadas em uma única sub-rede, o recurso de nome de rede distribuída fornece uma maneira alternativa para os clientes do SQL Server se conectarem à instância de cluster de failover do SQL Server ou ao ouvinte do grupo de disponibilidade sem usar um balanceador de carga. O recurso DNN está disponível a partir do SQL Server 2016 SP3, SQL Server 2017 CU25, SQL Server 2019 CU8, no Windows Server 2016 e posterior.

Quando um recurso DNN é criado, o cluster vincula o nome DNS com os endereços IP de todos os nós no cluster. O cliente tentará se conectar a cada endereço IP nesta lista para encontrar a qual recurso se conectar. Você pode acelerar esse processo especificando MultiSubnetFailover=True na cadeia de conexão. Essa configuração informa ao provedor para tentar todos os endereços IP em paralelo, para que o cliente possa se conectar à FCI ou ouvinte instantaneamente.

Um nome de rede distribuída é recomendado em um balanceador de carga quando possível porque:

• A solução de ponta a ponta é mais robusta, pois você não precisa mais manter o recurso do balanceador de carga.
• A eliminação dos testes do balanceador de carga minimiza a duração do failover.
• A DNN simplifica o provisionamento e o gerenciamento da instância de cluster de failover ou do ouvinte do grupo de disponibilidade com o SQL Server em VMs do Azure.

A maioria dos recursos do SQL Server funciona de forma transparente com FCI e grupos de disponibilidade ao usar a DNN, mas há certos recursos que podem exigir consideração especial.

SO suportado: Windows Server 2016 e posterior
Versão SQL suportada: SQL Server 2019 CU2 (FCI) e SQL Server 2019 CU8 (AG)
Solução HADR suportada: instância de cluster de failover e grupo de disponibilidade

Para começar, aprenda a configurar um recurso de nome de rede distribuído para uma instância de cluster de failover ou um grupo de disponibilidade.

Há considerações adicionais ao usar a DNN com outros recursos do SQL Server. Consulte Interoperabilidade FCI e DNN e Interoperabilidade AG e DNN para saber mais.

Ações de recuperação

O serviço de cluster executa uma ação corretiva quando uma falha é detetada. Isso pode reiniciar o recurso no nó existente ou fazer failover do recurso para outro nó. Uma vez iniciadas as medidas corretivas, elas levam algum tempo para serem concluídas.

Por exemplo, um grupo de disponibilidade reiniciado fica online de acordo com a seguinte sequência:

1. O IP do ouvinte fica online
2. O nome da rede de ouvintes fica online
3. O grupo de disponibilidade fica online
4. Os bancos de dados individuais passam pela recuperação, o que pode levar algum tempo dependendo de vários fatores, como o comprimento do log de refazer. As conexões são roteadas pelo ouvinte somente quando o banco de dados é totalmente recuperado. Para saber mais, consulte Estimando o tempo de failover (RTO).

Como a recuperação pode levar algum tempo, o monitoramento agressivo definido para detetar uma falha em 20 segundos pode resultar em uma interrupção de minutos se ocorrer um evento transitório (como a manutenção da VM do Azure que preserva a memória). Definir o monitoramento para um valor mais relaxado de 40 segundos pode ajudar a evitar uma interrupção mais longa do serviço.

Para ajustar as configurações de limite, consulte as práticas recomendadas de cluster para obter mais detalhes.

Localização do nó

Os nós em um cluster do Windows em máquinas virtuais no Azure podem estar fisicamente separados dentro da mesma região do Azure ou podem estar em regiões diferentes. A distância pode introduzir latência de rede, da mesma forma que ter nós de cluster espalhados entre locais em suas próprias instalações. Em ambientes de nuvem, a diferença é que, dentro de uma região, você pode não estar ciente da distância entre nós. Além disso, alguns outros fatores como componentes físicos e virtuais, número de lúpulos, etc. também pode contribuir para o aumento da latência. Se a latência entre os nós for uma preocupação, considere colocar os nós do cluster dentro de um grupo de posicionamento de proximidade para garantir a proximidade da rede.

Limites de recursos

Ao configurar uma VM do Azure, você determina os limites de recursos de computação para a CPU, memória e E/S. Cargas de trabalho que exigem mais recursos do que a VM do Azure comprada ou limites de disco podem causar problemas de desempenho da VM. A degradação do desempenho pode resultar em uma falha na verificação de integridade do serviço de cluster ou do recurso de alta disponibilidade do SQL Server. Os gargalos de recursos podem fazer com que o nó ou o recurso apareça até o cluster ou o SQL Server.

Operações intensivas de E/S do SQL ou operações de manutenção, como backups, manutenção de índices ou estatísticas, podem fazer com que a VM ou o disco atinjam os limites de taxa de transferência de IOPS ou MBPS, o que pode fazer com que o SQL Server não responda a uma verificação IsAlive/LooksAlive.

Se o SQL Server estiver enfrentando failovers inesperados, verifique se você está seguindo todas as práticas recomendadas de desempenho e monitore o servidor quanto a limites de disco ou nível de VM.

Manutenção da plataforma Azure

Como qualquer outro serviço de nuvem, o Azure atualiza periodicamente sua plataforma para melhorar a confiabilidade, o desempenho e a segurança da infraestrutura de host para máquinas virtuais. O objetivo destas atualizações vai da correção de componentes de software no ambiente anfitrião à atualização de componentes de rede ou desativação de hardware.

A maioria das atualizações de plataforma não afeta as VMs dos clientes. Quando uma atualização sem impacto não é possível, o Azure escolhe o mecanismo de atualização menos impactante para as VMs do cliente. A maioria das manutenções sem impacto zero pausa a VM por menos de 10 segundos. Em certos casos, o Azure usa mecanismos de manutenção de preservação de memória. Esses mecanismos pausam a VM por até 30 segundos e preservam a memória na RAM. A VM é então retomada e seu relógio é sincronizado automaticamente.

A manutenção de preservação de memória funciona para mais de 90% das VMs do Azure. Não funciona para as séries G, M, N e H. O Azure usa cada vez mais tecnologias de migração ao vivo e melhora os mecanismos de manutenção de preservação de memória para reduzir as durações de pausa. Quando a VM é migrada ao vivo para um host diferente, algumas cargas de trabalho confidenciais, como o SQL Server, podem mostrar uma ligeira degradação de desempenho nos poucos minutos que antecedem a pausa da VM.

Um afunilamento de recursos durante a manutenção da plataforma pode fazer com que a AG ou a FCI apareçam até o serviço de cluster. Consulte a seção de limites de recursos deste artigo para saber mais.

Se você estiver usando um monitoramento de cluster agressivo, uma pausa estendida da VM poderá disparar um failover. Um failover geralmente causa mais tempo de inatividade do que a pausa de manutenção, por isso é recomendável usar um monitoramento relaxado para evitar acionar um failover enquanto a VM está pausada para manutenção. Consulte as práticas recomendadas de cluster para obter mais informações sobre como definir limites de cluster em VMs do Azure.

Limitações

Considere as limitações a seguir ao trabalhar com FCI ou grupos de disponibilidade e SQL Server em Máquinas Virtuais do Azure.

MSDTC

As Máquinas Virtuais do Azure suportam o Microsoft Distributed Transaction Coordinator (MSDTC) no Windows Server 2019 com armazenamento em Volumes Partilhados Clusterizados (CSV) e Azure Standard Load Balancer ou em VMs do SQL Server que utilizam discos partilhados do Azure.

Nas Máquinas Virtuais do Azure, o MSDTC não é suportado para o Windows Server 2016 ou anterior com Volumes Partilhados Clusterizados porque:

• O recurso MSDTC clusterizado não pode ser configurado para usar armazenamento compartilhado. No Windows Server 2016, se você criar um recurso MSDTC, ele não mostrará nenhum armazenamento compartilhado disponível para uso, mesmo que o armazenamento esteja disponível. Esse problema foi corrigido no Windows Server 2019.
• O balanceador de carga básico não lida com portas RPC.

Próximos passos

Agora que você já se familiarizou com as diferenças ao usar um Cluster de Failover do Windows com o SQL Server em VMs do Azure, saiba mais sobre os recursos de alta disponibilidade, grupos de disponibilidade ou instâncias de cluster de failover. Se você estiver pronto para começar, certifique-se de revisar as práticas recomendadas para recomendações de configuração.