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 de uso do recurso de cluster de failover do Windows Server com o SQL Server em VMs do Azure para HADR (alta disponibilidade e recuperação de desastre), como para AGs (grupos de disponibilidade) Always On ou FCIs (instâncias de cluster de failover).
Para saber mais sobre o recurso do Windows propriamente dito, confira a documentação do cluster de failover do Windows Server.
Visão geral
As soluções de alta disponibilidade do SQL Server no Windows, como os AGs (grupos de disponibilidade) Always On ou as FCIs (instâncias de cluster de failover) dependem do serviço WSFC (clustering de failover do Windows Server) subjacente.
O serviço de cluster monitora as conexões de rede e a integridade dos nós no cluster. Esse monitoramento ocorre além das verificações de integridade feitas pelo SQL Server como parte do recurso do grupo de disponibilidade ou da instância de cluster de failover. Se o serviço de cluster não conseguir acessar o nó ou se a função AG ou FCI no cluster se tornar não íntegra, o serviço de cluster iniciará as ações de recuperação apropriadas para recuperar e colocar os aplicativos e os serviços online, seja no mesmo nó ou em outro nó do cluster.
Monitoramento de integridade do cluster
Para fornecer alta disponibilidade, o cluster precisa 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 de rede para detectar falhas e responder a elas.
A definição do limite para declarar uma falha é importante para obter um equilíbrio entre responder imediatamente a uma falha e evitar falhas falsas.
Existem duas estratégias de monitoramento:
| Monitoramento | Descrição |
|---|---|
| Agressivo | Fornece detecção rápida de falhas e recuperação de falhas graves, o que proporciona os níveis mais altos de disponibilidade. O serviço de cluster e o SQL Server são menos tolerantes a falhas transitórias e, em algumas situações, podem fazer failover prematuro dos recursos quando há interrupções transitórias. Quando a falha é detectada, a ação corretiva decorrente pode levar mais tempo. |
| Reduzido | Fornece mais tolerância a detecção de falhas com maior tolerância para problemas de rede transitórios breves. Evita falhas transitórias, mas também apresenta o risco de atrasar a detecção de uma falha verdadeira. |
As configurações agressivas em um ambiente de cluster na nuvem podem levar a falhas prematuras e a interrupções mais longas. Portanto, uma estratégia de monitoramento flexível é recomendada para os clusters de failover em VMs do Azure. Para ajustar as configurações de limite, confira Melhores práticas de cluster para obter mais detalhes.
Pulsação do cluster
As configurações primárias que afetam a pulsação do cluster e a detecção de integridade entre os nós:
| Configuração | Descrição |
|---|---|
| Atrasar | Isso define a frequência com que as pulsações do cluster são enviadas entre os nós. O atraso é o número de segundos antes que a próxima pulsação seja enviada. No mesmo cluster, pode haver diferentes configurações de atraso definidas entre os nós na mesma sub-rede e entre os nós que estão em sub-redes diferentes. |
| Limite | O limite é o número de pulsações que podem ser perdidas antes que o cluster execute a ação de recuperação. No mesmo cluster, pode haver diferentes configurações de limite definidas entre os nós na mesma sub-rede e entre os nós que estão em sub-redes diferentes. |
Os valores padrão dessas configurações podem ser muito baixos para ambientes de nuvem e podem resultar em falhas desnecessárias devido a problemas de rede transitórios. Para ser mais tolerante, use configurações de limite flexíveis para os clusters de failover em VMs do Azure. Confira Melhores práticas de cluster para obter mais detalhes.
Quorum
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 de produção. A validação do cluster não aprovará nenhum cluster sem um recurso de quorum.
Tecnicamente, um cluster de três nós pode sobreviver a uma só perda de nó (inativo em dois nós) sem um recurso de quorum. Mas, depois que o cluster estiver inativo em dois nós, há um risco de que os recursos clusterizados sejam colocados offline para evitar um cenário de divisão de rede, se um nó for perdido ou se houver uma falha de comunicação entre os nós. A configuração de um recurso de quorum permitirá que os recursos de cluster permaneçam online apenas com 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ê precisa usar um disco compartilhado do Azure que impõe algumas limitações para a solução de alta disponibilidade. Dessa forma, use uma testemunha de disco quando estiver configurando a 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 seguinte tabela 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 com suporte | Windows Server 2016 e posterior | Tudo | Todos |
| Descrição | Uma testemunha de nuvem é um tipo de testemunha de quorum de cluster de failover que usa o Microsoft Azure para fornecer um voto no quorum 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 sites, 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 de armazenamento disponível do cluster. Esse disco é altamente disponível e pode fazer failover entre os nós. Ele contém uma cópia do banco de dados do cluster, com um tamanho padrão inferior a 1 GB. A testemunha de disco é a opção de quorum preferencial 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 uma testemunha de disco. Configure um disco compartilhado do Azure como a testemunha de disco. | Uma testemunha de compartilhamento de arquivo é um compartilhamento de arquivo SMB que normalmente é configurado em um servidor de arquivos que executa o Windows Server. Ela mantém as informações de clustering em um arquivo witness.log, mas não armazena uma cópia do banco de dados do cluster. No Azure, você pode configurar um compartilhamento de arquivo em uma máquina virtual separada na mesma rede virtual. Use uma testemunha de compartilhamento de arquivo se uma testemunha de disco ou uma testemunha de nuvem não estiver disponível no seu ambiente. |
Para começar, confira Configurar o quorum do cluster.
VNN (Nome da rede virtual)
Para fazer a correspondência com a experiência local de conexão com a instância de cluster de failover ou com o ouvinte do grupo de disponibilidade, implante as VMs do SQL Server em várias sub-redes na mesma rede virtual. A presença de várias sub-redes elimina a necessidade de depender de um Azure Load Balancer para encaminhar o tráfego até a solução de HADR. Para saber mais, confira AG de várias sub-redes e FCI de várias sub-redes.
Em um ambiente local tradicional, os 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 associa o endereço IP no DNS, e os clientes podem usar o nome virtual ou o endereço IP para se conectarem ao destino de alta disponibilidade, independentemente de qual nó é o proprietário atual do recurso. O VNN é um nome de rede e um endereço gerenciados pelo cluster, e o serviço de cluster move o endereço de rede de nó em 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 só sub-rede, um componente adicional é necessário para encaminhar o tráfego do cliente para o Nome da Rede Virtual do recurso clusterizado (instância de cluster de failover ou o ouvinte de um grupo de disponibilidade). No Azure, um balanceador de carga armazena o endereço IP do VNN do 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 detecta falhas nos componentes de rede e move o endereço para um novo host.
O balanceador de carga distribui os fluxos de entrada que chegam ao front-end e roteia esse tráfego para as instâncias definidas pelo pool de back-end. O fluxo de tráfego é configurado com regras de balanceamento de carga e investigações de integridade. Com a FCI do SQL Server, as instâncias de subfase de back-end são as máquinas virtuais do Azure que executam o SQL Server e, com grupos de disponibilidade, a subfase de back-end são as máquinas virtuais do Azure que se tornam a réplica primária para o ouvinte. Há um pequeno atraso de failover quando o balanceador de carga é usado, pois a investigação de integridade realiza verificações ativas a cada 10 segundos por padrão.
Para começar, saiba como configurar o Azure Load Balancer para uma instância de cluster de failover ou um grupo de disponibilidade.
SO com suporte: Todos
Versão do SQL com suporte: Todos
Solução de HADR compatível: instância de cluster de failover e grupo de disponibilidade
A configuração do VNN pode ser complicada, é uma fonte adicional de falha, pode causar um atraso na detecção de falhas, e há uma sobrecarga e um custo associados ao gerenciamento do recurso adicional. Para resolver algumas dessas limitações, no SQL Server foi introduzido o suporte para o recurso de Nome de Rede Distribuída.
DNN (Nome de rede distribuída)
Para fazer a correspondência com a experiência local de conexão com a instância de cluster de failover ou com o ouvinte do grupo de disponibilidade, implante as VMs do SQL Server em várias sub-redes na mesma rede virtual. A presença de várias sub-redes elimina a necessidade de depender de um DNN para encaminhar o tráfego até a solução de HADR. Para saber mais, confira AG de várias sub-redes e FCI de várias sub-redes.
Para as VMs do SQL Server implantadas em uma só sub-rede, o recurso de nome de rede distribuída oferece uma forma alternativa para que os clientes do SQL Server se conectem com a instância de cluster de failover do SQL Server ou com o ouvinte do grupo de disponibilidade sem usar um balanceador de carga. O recurso DNN está disponível começando com o SQL Server 2016 SP3, SQL Server 2017 CU25 e SQL Server 2019 CU8 no Windows Server 2016 e posteriores.
Quando um recurso de DNN é criado, o cluster associa o nome DNS aos endereços IP de todos os nós do cluster. O cliente tentará se conectar a cada endereço IP nessa lista para descobrir a qual recurso ele deverá se conectar. Você pode acelerar esse processo especificando MultiSubnetFailover=True na cadeia de conexão. Essa configuração instrui o provedor a testar todos os endereços IP em paralelo, para que o cliente possa se conectar à FCI ou ao ouvinte instantaneamente.
Um nome de rede distribuído é 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 de balanceador de carga.
- A eliminação das investigações do balanceador de carga minimiza a duração do failover.
- O 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 maneira transparente com a FCI e os grupos de disponibilidade quando o DNN é usado, mas há alguns recursos que podem exigir consideração especial.
SO com suporte: Windows Server 2016 e posterior
Versão compatível do SQL: SQL Server 2019 CU2 (FCI) e SQL Server 2019 CU8 (AG)
Solução de HADR compatível: instância de cluster de failover e grupo de disponibilidade
Para começar, saiba como configurar um recurso de nome de rede distribuída para uma instância de cluster de failover ou um grupo de disponibilidade.
Há considerações adicionais no uso do DNN com outros recursos do SQL Server. Confira Interoperabilidade da FCI e do DNN e Interoperabilidade do AG e do DNN para saber mais.
Observação
Quando você tem vários AGs ou FCIs no mesmo cluster e usa um ouvinte DNN ou VNN, cada AG ou FCI precisa de seu próprio ponto de conexão independente.
Ações de recuperação
O serviço de cluster executa uma ação corretiva quando uma falha é detectada. Isso pode reiniciar o recurso no nó existente ou fazer o failover do recurso para outro nó. Depois que as medidas corretivas são iniciadas, elas levam algum tempo para serem concluídas.
Por exemplo, um grupo de disponibilidade reiniciado fica online de acordo com a seguinte sequência:
- O IP do ouvinte fica online
- O nome da rede do ouvinte fica online
- O grupo de disponibilidade fica online
- Os bancos de dados individuais passam pela recuperação, o que pode levar algum tempo, dependendo de vários fatores, como o tamanho do log de restauração. As conexões só são roteadas pelo ouvinte quando o banco de dados é totalmente recuperado. Para saber mais, confira Como estimar o tempo de failover (RTO).
Como a recuperação pode levar algum tempo, o monitoramento agressivo definido para detectar uma falha em 20 segundos poderá resultar em uma interrupção de vários minutos se ocorrer um evento transitório (como a manutenção de VM do Azure com preservação da memória). A definição do monitoramento com um valor mais flexível de 40 segundos pode ajudar a evitar uma interrupção mais longa do serviço.
Para ajustar as configurações de limite, confira Melhores práticas de cluster para obter mais detalhes.
Local do nó
Os nós de um cluster do Windows em máquinas virtuais no Azure podem estar fisicamente separados na mesma região do Azure ou podem estar em regiões diferentes. A distância pode introduzir a latência de rede, assim como a existência de nós de cluster distribuídos entre localizações em instalações próprias. Em ambientes de nuvem, a diferença é que, em uma região, você pode não estar ciente da distância entre os nós. Além disso, alguns outros fatores, como componentes físicos e virtuais, número de saltos etc., podem contribuir para uma latência maior. Se a latência entre os nós for uma preocupação, considere a colocação dos nós do cluster em um grupo de posicionamento por 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, a memória e a E/S. As cargas de trabalho que exigem mais recursos do que a VM do Azure comprada ou os limites de disco podem causar problemas de desempenho de VM. A degradação do desempenho pode resultar em uma verificação de integridade com falha para o serviço de cluster ou para o recurso de alta disponibilidade do SQL Server. Os gargalos de recursos podem fazer com que o nó ou o recurso seja exibido como offline para o cluster ou o SQL Server.
Operações de E/S intensivas de SQL ou operações de manutenção como backups, índice ou manutenção de estatísticas podem fazer com que a VM ou o disco atinja 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 tendo failovers inesperados, verifique se você está seguindo todas as melhores práticas de desempenho e monitore o servidor em relação ao limite de nível de VM ou de disco.
Manutenção da plataforma Azure
Assim como qualquer outro serviço de nuvem, o Azure atualiza a plataforma periodicamente para aprimorar a confiabilidade, o desempenho e a segurança da infraestrutura do host para máquinas virtuais. A finalidade dessas atualizações vai desde a aplicação de patch de componentes de software no ambiente de hospedagem até a atualização de componentes de rede ou o encerramento de hardware.
A maioria das atualizações de plataforma não afeta as VMs do cliente. Quando uma atualização sem impacto não é possível, o Azure escolhe o mecanismo de atualização menos impactante para as VMs dos clientes. A manutenção de impacto mais diferente de zero pausa a VM por menos de 10 segundos. Em determinados 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. Depois, a VM é reiniciada e o respectivo relógio é sincronizado automaticamente.
A manutenção de preservação de memória funciona para mais de 90% das VMs do Azure. Ela não funciona para as séries G, M, N e H. Cada vez mais, o Azure usa tecnologias de migração ao vivo e aprimora o mecanismo de manutenção de preservação de memória para reduzir as durações da pausa. Quando a VM é migrada ao vivo para outro host, algumas cargas de trabalho confidenciais como o SQL Server podem mostrar uma pequena degradação do desempenho em alguns minutos, causando a pausa da VM.
Um gargalo de recursos durante a manutenção da plataforma pode fazer com que o AG ou a FCI sejam exibidos como offline para o serviço de cluster. Confira a seção Limites de recursos deste artigo para saber mais.
Se você estiver usando o monitoramento agressivo de cluster, uma pausa estendida da VM poderá disparar um failover. Um failover geralmente causará mais tempo de inatividade do que a pausa de manutenção. Portanto, recomendamos usar o monitoramento flexível para evitar disparar um failover enquanto a VM está em pausa para manutenção. Confira as Melhores práticas 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 quando estiver trabalhando com a FCI ou os grupos de disponibilidade e o SQL Server em máquinas virtuais do Azure.
MSDTC
As Máquinas Virtuais do Azure dão suporte ao MSDTC (Coordenador de Transações Distribuídas da Microsoft) no Windows Server 2019 com armazenamento em CSVs (Volumes Compartilhados Clusterizados) e um Standard Load Balancer do Azure ou em VMs do SQL Server que estão usando discos compartilhados do Azure.
Nas Máquinas Virtuais do Azure, o MSDTC não tem suporte para o Windows Server 2016 ou versões anteriores com Volumes Compartilhados Clusterizados porque:
- O recurso MSDTC clusterizado não pode ser configurado para usar o armazenamento compartilhado. No Windows Server 2016, se você criar um recurso MSDTC, ele não mostrará nenhum armazenamento compartilhado disponível para uso, mesmo se o armazenamento estiver disponível. Esse problema foi corrigido no Windows Server 2019.
- O balanceador de carga básico não lida com portas RPC.
Próximas etapas
Agora que você já está familiarizado com as diferenças de uso de 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 estiver pronto para começar, examine as melhores práticas para obter recomendações de configuração.