Melhores práticas de configuração da solução HADR (SQL Server nas VMs do Azure)

Aplica-se a:SQL Server na VM do Azure

Um Cluster de Failover do Windows Server é usado para alta disponibilidade e recuperação de desastres (HADR) com o SQL Server em Máquinas Virtuais (VMs) do Azure.

Este artigo fornece práticas recomendadas de configuração de cluster para instâncias de cluster de failover (FCIs) e grupos de disponibilidade quando você os usa com o SQL Server em VMs do Azure.

Para saber mais, consulte os outros artigos desta série: Lista de verificação, tamanho da VM, Armazenamento, Segurança, Configuração HADR, Coletar linha de base.

Lista de Verificação

Analise a lista de verificação a seguir para obter uma breve visão geral das práticas recomendadas de HADR que o restante do artigo aborda com mais detalhes.

Os recursos de alta disponibilidade e recuperação de desastres (HADR), como o grupo de disponibilidade Always On e a instância de cluster de failover, dependem da tecnologia subjacente de Cluster de Failover do Windows Server. Analise as práticas recomendadas para modificar suas configurações de HADR para oferecer melhor suporte ao ambiente de nuvem.

Para o cluster do Windows, considere estas práticas recomendadas:

• Implante suas VMs do SQL Server em várias sub-redes sempre que possível para evitar a dependência de um Balanceador de Carga do Azure ou de um DNN (nome de rede distribuído) para rotear o tráfego para sua solução HADR.
• Altere o cluster para parâmetros menos agressivos para evitar interrupções inesperadas devido a falhas de rede transitórias ou manutenção da plataforma Azure. Para saber mais, consulte Configurações de pulsação e limite. Para o Windows Server 2012 e versões posteriores, use os seguintes valores recomendados:
  • SameSubnetDelay: 1 segundo
  • SameSubnetThreshold: 40 batimentos cardíacos
  • CrossSubnetDelay: 1 segundo
  • CrossSubnetThreshold: 40 batimentos cardíacos
• Coloque suas VMs em um conjunto de disponibilidade ou em zonas de disponibilidade diferentes. Para saber mais, consulte Configurações de disponibilidade de VM.
• Use uma única NIC por nó de cluster.
• Configure a votação de quórum de cluster para usar 3 ou mais números ímpares de votos. Não atribua votos a regiões DR.
• Monitore cuidadosamente os limites de recursos para evitar reinicializações inesperadas ou failovers devido a restrições de recursos.
  • Verifique se seu sistema operacional, drivers e SQL Server estão nas compilações mais recentes.
  • Otimize o desempenho do SQL Server em VMs do Azure. Consulte as outras secções deste artigo para saber mais.
  • Reduza ou distribua a carga de trabalho para evitar limites de recursos.
  • Mova para uma VM ou disco que seus limites mais altos para evitar restrições.

Para seu grupo de disponibilidade do SQL Server ou instância de cluster de failover, considere estas práticas recomendadas:

• Se você estiver enfrentando falhas inesperadas frequentes, siga as práticas recomendadas de desempenho descritas no restante deste artigo.
• Se a otimização do desempenho da VM do SQL Server não resolver seus failovers inesperados, considere relaxar o monitoramento para o grupo de disponibilidade ou instância de cluster de failover. No entanto, isso pode não resolver a origem subjacente do problema e pode mascarar os sintomas, reduzindo a probabilidade de falha. Talvez ainda seja necessário investigar e abordar a causa raiz subjacente. Para Windows Server 2012 ou superior, use os seguintes valores recomendados:
  • Tempo limite de locação: use esta equação para calcular o valor máximo de tempo limite de locação:
    Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
    Comece com 40 segundos. Se você estiver usando os valores relaxados SameSubnetThreshold e SameSubnetDelay recomendados anteriormente, não exceda 80 segundos para o valor de tempo limite de locação.
  • Falhas máximas em um período especificado: defina esse valor como 6.
• Ao usar o nome da rede virtual (VNN) e um Balanceador de Carga do Azure para se conectar à sua solução HADR, especifique MultiSubnetFailover = true na cadeia de conexão, mesmo que o cluster abranja apenas uma sub-rede.
  • Se o cliente não oferecer suporte MultiSubnetFailover = True , talvez seja necessário definir RegisterAllProvidersIP = 0 e HostRecordTTL = 300 armazenar em cache as credenciais do cliente por períodos mais curtos. No entanto, isso pode causar consultas adicionais ao servidor DNS.

• Para se conectar à sua solução HADR usando o nome de rede distribuída (DNN), considere o seguinte:
  • Você deve usar um driver de cliente que ofereça suporte a MultiSubnetFailover = True, e esse parâmetro deve estar na cadeia de conexão.
  • Use uma porta DNN exclusiva na cadeia de conexão ao se conectar ao ouvinte DNN para um grupo de disponibilidade.
• Use uma cadeia de conexão de espelhamento de banco de dados para um grupo de disponibilidade básica para ignorar a necessidade de um balanceador de carga ou DNN.
• Valide o tamanho do setor de seus VHDs antes de implantar sua solução de alta disponibilidade para evitar ter E/S desalinhadas. Consulte KB3009974 para saber mais.
• Se o mecanismo de banco de dados do SQL Server, o ouvinte do grupo de disponibilidade Always On ou a sonda de integridade da instância de cluster de failover estiverem configurados para usar uma porta entre 49.152 e 65.536 (o intervalo de portas dinâmicas padrão para TCP/IP), adicione uma exclusão para cada porta. Isso evita que outros sistemas recebam dinamicamente a mesma porta. O exemplo a seguir cria uma exclusão para a porta 59999:
  netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Para comparar a lista de verificação HADR com as outras práticas recomendadas, consulte a lista de verificação abrangente de práticas recomendadas de desempenho.

Configurações de disponibilidade de VM

Para reduzir o efeito do tempo de inatividade, considere as seguintes configurações de melhor disponibilidade da VM:

• Use grupos de posicionamento de proximidade junto com a rede acelerada para obter a menor latência.
• Coloque nós de cluster de máquina virtual em zonas de disponibilidade separadas para proteger contra falhas no nível do datacenter ou em um único conjunto de disponibilidade para redundância de baixa latência no mesmo datacenter.
• Use o sistema operacional gerenciado premium e discos de dados para VMs em um conjunto de disponibilidade.
• Configure cada camada de aplicativo em conjuntos de disponibilidade separados.

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 passa em nenhum cluster sem um recurso de quorum.

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

A testemunha de disco é a opção de quórum 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, o 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:

• A 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ê esteja usando uma solução de cluster de armazenamento compartilhado.
• A testemunha de disco é a opção de quorum mais resiliente e é 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.
• A testemunha de compartilhamento de arquivos é adequada para quando as opções testemunha de disco e testemunha de nuvem não estão disponíveis.

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

Votação do quórum

É possível alterar a votação de quórum de um nó participante de um Cluster de Failover do Windows Server.

Ao modificar as configurações de votação do nó, siga estas diretrizes:

Conectividade

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 ou de um nome de rede distribuída para rotear seu tráfego para o ouvinte.

Para simplificar sua solução HADR, implante suas VMs do SQL Server em várias sub-redes sempre que possível. Para saber mais, consulte Multi-sub-net AG, e Multi-sub-net FCI.

Se suas VMs do SQL Server estiverem em uma única sub-rede, será possível configurar um nome de rede virtual (VNN) e um Balanceador de Carga do Azure ou um DNN (nome de rede distribuída) para instâncias de cluster de failover e ouvintes de grupo de disponibilidade.

O nome da rede distribuída é a opção de conectividade recomendada, quando disponível:

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

Considere as seguintes limitações:

• O driver do cliente deve suportar o MultiSubnetFailover=True parâmetro.
• O recurso DNN está disponível a partir do SQL Server 2016 SP3, SQL Server 2017 CU25 e SQL Server 2019 CU8 no Windows Server 2016 e posterior.

Para saber mais, consulte a visão geral do Cluster de Failover do Windows Server.

Para configurar a conectividade, consulte os seguintes artigos:

• Grupo de disponibilidade: Configurar DNN, Configurar VNN
• Instância de cluster de failover: Configurar DNN, Configurar VNN.

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. Consulte Interoperabilidade FCI e DNN e Interoperabilidade AG e DNN para saber mais.

Batimento cardíaco e limiar

Altere as configurações de pulsação e limite do cluster para configurações relaxadas. As configurações padrão de pulsação e cluster de limite são projetadas para redes locais altamente sintonizadas e não consideram a possibilidade de aumento da latência em um ambiente de nuvem. A rede de pulsação é mantida com UDP 3343, que é tradicionalmente muito menos confiável do que o TCP e mais propenso a conversas incompletas.

Portanto, ao executar nós de cluster para o SQL Server em soluções de alta disponibilidade de VM do Azure, altere as configurações de cluster para um estado de monitoramento mais relaxado para evitar falhas transitórias devido à maior possibilidade de latência ou falha de rede, manutenção do Azure ou afunilamentos de recursos.

As configurações de atraso e limite têm um efeito cumulativo na deteção de integridade total. Por exemplo, definir CrossSubnetDelay para enviar uma pulsação a cada 2 segundos e definir CrossSubnetThreshold para 10 pulsações perdidas antes de executar a recuperação significa que o cluster pode ter uma tolerância total de rede de 20 segundos antes que a ação de recuperação seja executada. Em geral, é preferível continuar a enviar batimentos cardíacos frequentes, mas com limiares maiores.

Para garantir a recuperação durante interrupções legítimas e, ao mesmo tempo, fornecer maior tolerância a problemas transitórios, relaxe as configurações de atraso e limite para os valores recomendados detalhados na tabela a seguir:

Use o PowerShell para alterar os parâmetros do cluster:

(get-cluster).SameSubnetThreshold = 40
(get-cluster).CrossSubnetThreshold = 40

(get-cluster).SameSubnetThreshold = 10
(get-cluster).CrossSubnetThreshold = 20
(get-cluster).SameSubnetDelay = 2000
(get-cluster).CrossSubnetDelay = 2000

Use o PowerShell para verificar suas alterações:

get-cluster | fl *subnet*

Considere o seguinte:

• Essa alteração é imediata, reiniciando o cluster ou quaisquer recursos não são necessários.
• Os mesmos valores de sub-rede não devem ser maiores do que os valores cruzados de sub-rede.
• SameSubnetThreshold = CrossSubnetThreshold <
• SameSubnetDelay = CrossSubnetDelay <

Escolha valores relaxados com base em quanto tempo de inatividade é tolerável e quanto tempo antes de uma ação corretiva deve ocorrer, dependendo do seu aplicativo, das necessidades de negócios e do seu ambiente. Se não conseguir exceder os valores predefinidos do Windows Server 2019, tente pelo menos correspondê-los, se possível:

Para referência, a tabela a seguir detalha os valores padrão:

Para saber mais, consulte Ajustando limites de rede de cluster de failover.

Monitorização descontraída

Se ajustar as configurações de pulsação e limite do cluster conforme recomendado for tolerância insuficiente e você ainda estiver vendo failovers devido a problemas transitórios em vez de verdadeiras interrupções, você poderá configurar seu monitoramento AG ou FCI para ser mais relaxado. Em alguns cenários, pode ser benéfico relaxar temporariamente o monitoramento por um período de tempo, dado o nível de atividade. Por exemplo, você pode querer relaxar o monitoramento quando estiver fazendo cargas de trabalho intensivas de E/S, como backups de banco de dados, manutenção de índice, DBCC CHECKDB, etc. Quando a atividade estiver concluída, defina seu monitoramento para valores menos relaxados.

Comece aumentando os seguintes parâmetros a partir de seus valores padrão para monitoramento relaxado e ajuste conforme necessário:

Use Transact-SQL (T-SQL) para modificar a verificação de integridade e as condições de falha para AGs e FCIs.

Para grupos de disponibilidade:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);
ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 2);

Para instâncias de cluster de failover:

ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY HealthCheckTimeout = 60000;
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY FailureConditionLevel = 2;

Específico para grupos de disponibilidade, comece com os seguintes parâmetros recomendados e ajuste conforme necessário:

Antes de fazer qualquer alteração, considere o seguinte:

• Não diminua nenhum valor de tempo limite abaixo de seus valores padrão.
• Use esta equação para calcular o valor máximo de tempo limite de locação: Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
  Comece com 40 segundos. Se você estiver usando os valores relaxados SameSubnetThreshold e SameSubnetDelay recomendados anteriormente, não exceda 80 segundos para o valor de tempo limite de locação.
• Para réplicas de confirmação síncrona, alterar o tempo limite da sessão para um valor alto pode aumentar HADR_sync_commit esperas.

Tempo limite de locação

Use o Gerenciador de Cluster de Failover para modificar as configurações de tempo limite de concessão para seu grupo de disponibilidade. Consulte a documentação de verificação de integridade da concessão do grupo de disponibilidade do SQL Server para obter etapas detalhadas.

Tempo limite da sessão

Use Transact-SQL (T-SQL) para modificar o tempo limite da sessão para um grupo de disponibilidade:

ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON 'INSTANCE01' WITH (SESSION_TIMEOUT = 20);

Falhas máximas no período especificado

Use o Gerenciador de Cluster de Failover para modificar as falhas máximas no valor de período especificado:

1. Selecione Funções no painel de navegação.
2. Em Funções, clique com o botão direito do mouse no recurso clusterizado e escolha Propriedades.
3. Selecione a guia Failover e aumente o valor Máximo de falhas no período especificado, conforme desejado.

Limites de recursos

Os limites de VM ou disco podem resultar em um afunilamento de recursos que afeta a integridade do cluster e impede a verificação de integridade. Se você estiver enfrentando problemas com limites de recursos, considere o seguinte:

• Verifique se seu sistema operacional, drivers e SQL Server estão nas compilações mais recentes.
• Otimizar o SQL Server no ambiente de VM do Azure conforme descrito nas diretrizes de desempenho para o SQL Server em Máquinas Virtuais do Azure
• Reduza ou distribua a carga de trabalho para reduzir a utilização sem exceder os limites de recursos
• Ajuste a carga de trabalho do SQL Server se houver alguma oportunidade, como
  • Adicionar/otimizar índices
  • Atualize as estatísticas, se necessário e, se possível, com a verificação completa
  • Use recursos como o administrador de recursos (começando com o SQL Server 2014, somente empresa) para limitar a utilização de recursos durante cargas de trabalho específicas, como backups ou manutenção de índice.
• Mude para uma VM ou disco que tenha limites mais altos para atender ou exceder as demandas de sua carga de trabalho.

Rede

Implante suas VMs do SQL Server em várias sub-redes sempre que possível para evitar a dependência de um Balanceador de Carga do Azure ou de um DNN (nome de rede distribuído) para rotear o tráfego para sua solução HADR.

Use uma única NIC por servidor (nó de cluster). A rede do Azure tem redundância física, o que torna NICs adicionais desnecessárias em um cluster convidado de máquina virtual do Azure. O relatório de validação de cluster avisa que os nós podem ser acessados apenas em uma única rede. Você pode ignorar esse aviso em clusters de failover de convidado de máquina virtual do Azure.

Os limites de largura de banda para uma VM específica são compartilhados entre NICs e adicionar uma NIC adicional não melhora o desempenho do grupo de disponibilidade para o SQL Server em VMs do Azure. Como tal, não há necessidade de adicionar uma segunda NIC.

O serviço DHCP não compatível com RFC no Azure pode fazer com que a criação de determinadas configurações de cluster de failover falhe. Essa falha acontece porque o nome da rede do cluster recebe um endereço IP duplicado, como o mesmo endereço IP de um dos nós do cluster. Esse é um problema quando você usa grupos de disponibilidade, que dependem do recurso de cluster de failover do Windows.

Considere o cenário em que um cluster de dois nós é criado e colocado online:

1. O cluster fica online e, em seguida, o NODE1 solicita um endereço IP atribuído dinamicamente para o nome da rede do cluster.
2. O serviço DHCP não fornece nenhum endereço IP além do próprio endereço IP do NODE1, porque o serviço DHCP reconhece que a solicitação vem do próprio NODE1.
3. O Windows deteta que um endereço duplicado é atribuído ao NODE1 e ao nome de rede do cluster de failover, e o grupo de cluster padrão não fica online.
4. O grupo de cluster padrão é movido para NODE2. O NODE2 trata o endereço IP do NODE1 como o endereço IP do cluster e coloca o grupo de cluster padrão online.
5. Quando o NODE2 tenta estabelecer conectividade com o NODE1, os pacotes direcionados ao NODE1 nunca saem do NODE2 porque ele resolve o endereço IP do NODE1 para si mesmo. O NODE2 não pode estabelecer conectividade com o NODE1 e, em seguida, perde o quórum e desliga o cluster.
6. NODE1 pode enviar pacotes para NODE2, mas NODE2 não pode responder. O NODE1 perde quórum e desliga o cluster.

Você pode evitar esse cenário atribuindo um endereço IP estático não utilizado ao nome da rede do cluster para colocar o nome da rede do cluster online e adicionar o endereço IP ao Balanceador de Carga do Azure.

Se o mecanismo de banco de dados do SQL Server, ouvinte do grupo de disponibilidade Always On, investigação de integridade da instância de cluster de failover, ponto de extremidade de espelhamento de banco de dados, recurso IP principal do cluster ou qualquer outro recurso SQL estiver configurado para usar uma porta entre 49.152 e 65.536 (o intervalo de portas dinâmicas padrão para TCP/IP), adicione uma exclusão para cada porta. Isso impede que outros processos do sistema sejam atribuídos dinamicamente à mesma porta. O exemplo a seguir cria uma exclusão para a porta 59999:

netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

É importante configurar a exclusão de porta quando a porta não estiver em uso, caso contrário, o comando falhará com uma mensagem como "O processo não pode acessar o arquivo porque está sendo usado por outro processo".

Para confirmar se as exclusões foram configuradas corretamente, use o seguinte comando: netsh int ipv4 show excludedportrange tcp.

Definir essa exclusão para a porta de sonda IP da função de grupo de disponibilidade deve impedir eventos como ID do Evento: 1069 com status 10048. Esse evento pode ser visto nos eventos de cluster de Failover do Windows com a seguinte mensagem:

Cluster resource '<IP name in AG role>' of type 'IP Address' in cluster role '<AG Name>' failed.
An Event ID: 1069 with status 10048 can be identified from cluster logs with events like:
Resource IP Address 10.0.1.0 called SetResourceStatusEx: checkpoint 5. Old state OnlinePending, new state OnlinePending, AppSpErrorCode 0, Flags 0, nores=false
IP Address <IP Address 10.0.1.0>: IpaOnlineThread: **Listening on probe port 59999** failed with status **10048**
Status [**10048**](/windows/win32/winsock/windows-sockets-error-codes-2) refers to: **This error occurs** if an application attempts to bind a socket to an **IP address/port that has already been used** for an existing socket.

Isso pode ser causado por um processo interno que usa a mesma porta definida como porta de sonda. Lembre-se de que a porta de teste é usada para verificar o status de uma instância do pool de back-end do Balanceador de Carga do Azure.
Se o teste de integridade não conseguir obter uma resposta de uma instância de back-end, nenhuma nova conexão será enviada para essa instância de back-end até que o teste de integridade seja bem-sucedido novamente.

Problemas conhecidos

Analise as resoluções para verificar se há alguns problemas e erros comumente conhecidos.

Contenção de recursos (E/S em particular) causa failover

O esgotamento da capacidade de E/S ou CPU da VM pode fazer com que seu grupo de disponibilidade faça failover. Identificar a contenção que acontece antes do failover é a maneira mais confiável de identificar o que está causando o failover automático. Monitore as Máquinas Virtuais do Azure para examinar as métricas de Utilização de E/S de Armazenamento para entender a latência da VM ou do nível de disco.

Siga estes passos para rever o evento de Exaustão Geral de E/S da VM do Azure:

1. Navegue até sua Máquina Virtual no portal do Azure - não as máquinas virtuais SQL.

2. Selecione Métricas em Monitoramento para abrir a página Métricas.

3. Selecione Hora local para especificar o intervalo de tempo em que está interessado e o fuso horário, local para a VM ou UTC/GMT.

   

4. Selecione Adicionar métrica para adicionar as duas métricas a seguir para ver o gráfico:

   • Porcentagem de largura de banda em cache da VM consumida
   • Percentagem da Largura de Banda fora da Cache da VM Consumida

Azure VM HostEvents causa failover

É possível que um HostEvent de VM do Azure faça com que seu grupo de disponibilidade faça failover. Se você acredita que um HostEvent de VM do Azure causou um failover, você pode verificar o log de Atividade do Monitor do Azure e a Visão geral da Integridade dos Recursos da VM do Azure.

O log de atividades do Azure Monitor é um log de plataforma, no Azure, que fornece informações sobre eventos no nível de assinatura. O log de atividades inclui informações como quando um recurso é modificado ou uma máquina virtual é iniciada. Você pode exibir o log de atividades no portal do Azure ou recuperar entradas com o PowerShell e a CLI do Azure.

Para verificar o registo de atividades do Azure Monitor, siga estes passos:

1. Navegue até sua Máquina Virtual no portal do Azure

2. Selecionar Log de Atividades no painel Máquina Virtual

3. Selecione Período de tempo e, em seguida, escolha o período de tempo em que o grupo de disponibilidade falhou. Selecione Aplicar.

   

Se o Azure tiver mais informações sobre a causa raiz de uma indisponibilidade iniciada pela plataforma, essas informações poderão ser publicadas na página de visão geral da VM do Azure - Integridade dos Recursos até 72 horas após a indisponibilidade inicial. Neste momento, estas informações só estão disponíveis para máquinas virtuais.

1. Navegue até sua Máquina Virtual no portal do Azure
2. Selecione Estado de Funcionamento do Recurso no painel Estado de Funcionamento .

Você também pode configurar alertas com base em eventos de integridade nesta página.

Nó de cluster removido da associação

Se as configurações de pulsação e limite do Cluster do Windows forem muito agressivas para seu ambiente, você poderá ver a seguinte mensagem no log de eventos do sistema com freqüência.

Error 1135
Cluster node 'Node1' was removed from the active failover cluster membership.
The Cluster service on this node may have stopped. This could also be due to the node having
lost communication with other active nodes in the failover cluster. Run the Validate a
Configuration Wizard to check your network configuration. If the condition persists, check
for hardware or software errors related to the network adapters on this node. Also check for
failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Para obter mais informações, consulte Solução de problemas de cluster com a ID de Evento 1135.

O contrato de arrendamento expirou / o contrato de arrendamento deixou de ser válido

Se o monitoramento for muito agressivo para seu ambiente, você poderá ver reinicializações, falhas ou failovers frequentes do grupo de disponibilidade ou da FCI. Além disso, para grupos de disponibilidade, você pode ver as seguintes mensagens no log de erros do SQL Server:

Error 19407: The lease between availability group 'PRODAG' and the Windows Server Failover Cluster has expired.
A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster.
To determine whether the availability group is failing over correctly, check the corresponding availability group
resource in the Windows Server Failover Cluster

Error 19419: The renewal of the lease between availability group '%.*ls' and the Windows Server Failover Cluster
failed because the existing lease is no longer valid.

Limite de tempo da ligação

Se o tempo limite da sessão for muito agressivo para o ambiente do grupo de disponibilidade, você poderá ver as seguintes mensagens com frequência:

Error 35201: A connection timeout has occurred while attempting to establish a connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or firewall issue exists,
or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

Error 35206
A connection timeout has occurred on a previously established connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or a firewall issue
exists, or the availability replica has transitioned to the resolving role.

Grupo sem falha

Se o valor Máximo de Falhas no Período Especificado for muito baixo e você estiver enfrentando falhas intermitentes devido a problemas transitórios, seu grupo de disponibilidade poderá terminar em um estado de falha. Aumente esse valor para tolerar falhas mais transitórias.

Not failing over group <Resource name>, failoverCount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2.

Evento 1196 - Falha no registro do recurso de nome de rede do nome DNS associado

• Verifique as definições de NIC para cada um dos nós de cluster para confirmar que não há registos DNS externos presentes
• Confirme que o registo A do cluster está presente nos servidores DNS internos. Caso contrário, crie um novo Registo A manualmente no Servidor DNS para o objeto de Controlo de Acesso do Cluster e assinale a opção Permitir que quaisquer utilizadores autenticados atualizem os Registos DNS com o mesmo nome de proprietário.
• Utilize o Recurso “Nome do Cluster” com o Recurso IP offline e corrija-o.

Evento 157 - O disco foi removido de surpresa.

Tal poderá acontecer se a propriedade Espaços de Armazenamento AutomaticClusteringEnabled estiver definida como True para um ambiente do AG. Altere-a para False. Além disso, executar um Relatório de Validação com a opção Armazenamento pode acionar o evento de reposição do disco ou de remoção inesperada. A Limitação do sistema de armazenamento também pode acionar o evento de remoção inesperada do disco.

Evento 1206 - O recurso de nome de rede do cluster não pode ser colocado online.

O objeto de computador associado ao recurso não pôde ser atualizado no domínio. Verifique se você tem as permissões apropriadas no domínio

Erros de clustering do Windows

Você pode encontrar problemas ao configurar um cluster de failover do Windows ou sua conectividade se não tiver Portas de Serviço de Cluster abertas para comunicação.

Se você estiver no Windows Server 2019 e não vir um IP de Cluster do Windows, configurou o Nome da Rede Distribuída, que só é suportado no SQL Server 2019. Se tiver versões anteriores do SQL Server, poderá remover e Recriar o Cluster com o Nome da Rede.

Analise outros erros de eventos de clustering de failover do Windows e suas soluções aqui

Próximos passos

Para saber mais, veja:

• Configurações HADR para SQL Server em VMs do Azure
• Cluster de Failover do Windows Server com o SQL Server em VMs do Azure
• Grupos de disponibilidade Always On com o SQL Server em VMs do Azure
• Cluster de Failover do Windows Server com o SQL Server em VMs do Azure
• Instâncias de cluster de failover com o SQL Server em VMs do Azure
• Visão geral da instância de cluster de failover