Partilhar via

Práticas recomendadas de configuração HADR (SQL Server em VMs do Azure)

  • Artigo

Aplica-se a:SQL Server em Máquina Virtual do Azure

Um Cluster de Failover do Windows Server é usado para disponibilidade elevada e recuperação em caso de desastre (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, Coleta da 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 mais informações, consulte configurações de disponibilidade de VM.
  • Use uma única NIC por nó de cluster.
  • Configure o de votação de quórum de de cluster para usar 3 ou mais números ímpares de votos. Não atribua votos a regiões DR.
  • Monitore cuidadosamente 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 tenha 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 de monitoramento para o grupo de disponibilidade ou a 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 concessã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 estiver a usar os valores de SameSubnetThreshold e SameSubnetDelay relaxados recomendados anteriormente, não exceda 80 segundos para o valor de tempo limite do arrendamento.
    • Falhas máximas em um período especificado: Defina este 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 a MultiSubnetFailover = True talvez seja necessário definir RegisterAllProvidersIP = 0 e HostRecordTTL = 300 para 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 = Truee 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 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 investigação 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 em produção. A validação de cluster não aprova qualquer 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. Ao configurar um recurso de quorum, o cluster pode continuar online com apenas um nó ativo.

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, o que impõe algumas limitações à solução de alta disponibilidade. Como tal, use uma testemunha de disco quando estiver a configurar a sua instância de cluster de failover nos Discos Partilhados 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:

Nuvem testemunha Testemunha de disco Testemunha de compartilhamento de arquivos
OS suportados Windows Server 2016+ Tudo Tudo
  • A testemunha de nuvem é ideal para implantações em vários locais, zonas e 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.
  • O disco testemunha é a opção de quórum mais resiliente e é preferencial para qualquer cluster que use os 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.
  • O testemunha de partilha de ficheiros é adequado quando as opções testemunha de disco e testemunha de nuvem não estão disponíveis.

Para começar, consulte Configurar o quorum do 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 alterar as configurações de votação do nó, siga estas orientações:

Diretrizes de votação do quórum
Comece com cada nó sem votos por predefinição. Cada nó deve ter apenas um voto com justificação explícita.
Habilite votos para nós de cluster que hospedam a réplica primária de um grupo de disponibilidade ou os proprietários preferenciais de uma instância de cluster de failover.
Habilite votos para proprietários de failover automático. Cada nó que pode hospedar uma réplica primária ou FCI como resultado de um failover automático deve ter um voto.
Se um grupo de disponibilidade tiver mais de uma réplica secundária, ative apenas os votos para as réplicas que possuem failover automático.
Desative votos para nós que se encontram em sites secundários de recuperação de desastres. Os nós em sites secundários não devem contribuir para a decisão de colocar um cluster offline se não houver nada de errado com o site primário.
Deve haver um número ímpar de votos, com um mínimo de três votos para quórum. Adicione uma testemunha de quórum para uma votação adicional, se necessário, em um cluster de dois nós.
Reavalie as atribuições de votos após o failover. Você não deseja fazer uma transferência de serviço para uma configuração de cluster que não ofereça suporte a um quórum estável.

Conectividade

Para equiparar à experiência local ao ligar ao listener do grupo de disponibilidade ou instância de cluster de failover, implante as 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-subnet AGe Multi-subnet FCI.

Se as suas VMs do SQL Server estiverem numa única sub-rede, é possível configurar ou um nome de rede virtual (VNN) e um Balanceador de Carga do Azure, ou um nome de rede distribuída (DNN) para instâncias de cluster de failover e ouvinte 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 das sondas do balanceador de carga minimiza a duração do failover.
  • A DNN simplifica o provisionamento e a gestão da instância de cluster de failover ou do listener do grupo de disponibilidade com o SQL Server em VMs do Azure.

Considere as seguintes limitações:

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

Para configurar a conectividade, consulte os seguintes artigos:

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

Dica

Defina o parâmetro MultiSubnetFailover = true na cadeia de conexão, mesmo para soluções HADR que abrangem uma única sub-rede, para oferecer suporte à abrangência futura de sub-redes sem a necessidade de atualizar cadeias de conexão.

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 cluster de pulsação e 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 batimentos cardíacos é mantida com UDP 3343, que é tradicionalmente muito menos fiável do que TCP e mais suscetível a transmissões 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 gargalos de recursos.

As configurações de atraso e limite têm um efeito cumulativo na deteção de saúde total. Por exemplo, definir CrossSubnetDelay enviar uma pulsação a cada 2 segundos e definir o 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:

Cenário Windows Server 2012 ou posterior Windows Server 2008 R2
SameSubnetDelay 1 segundo 2 segundos
SameSubnetThreshold 40 batimentos cardíacos 10 batimentos cardíacos (máx.)
CrossSubnetDelay 1 segundo 2 segundos
CrossSubnetThreshold 40 batimentos cardíacos 20 batimentos cardíacos (máx.)

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

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

Use o PowerShell para verificar suas alterações:

get-cluster | fl *subnet*

Considere o seguinte:

  • Essa alteração é imediata, a reinicialização do 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:

Cenário Windows Server 2019 Windows Server 2016 Windows Server 2008 - 2012 R2
SameSubnetDelay 1 segundo 1 segundo 1 segundo
SameSubnetThreshold 20 batimentos cardíacos 10 batimentos cardíacos 5 batimentos cardíacos
CrossSubnetDelay 1 segundo 1 segundo 1 segundo
CrossSubnetThreshold 20 batimentos cardíacos 10 batimentos cardíacos 5 batimentos cardíacos

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 insuficiente para tolerância e ainda estiver a constatar falhas devido a problemas transitórios em vez de interrupções reais, poderá configurar a sua monotorização AG ou FCI para se tornar mais flexível. 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.

Advertência

Alterar essas configurações pode mascarar um problema subjacente e deve ser usado como uma solução temporária para reduzir, em vez de eliminar, a probabilidade de falha. As questões subjacentes devem ainda ser investigadas e abordadas.

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

Parâmetro Valor padrão Valor descontraído Descrição
Tempo limite do Healthcheck 30000 60000 Determina a integridade da réplica ou nó primário. A sp_server_diagnostics DLL do recurso de cluster retorna resultados em um intervalo igual a 1/3 do limite de tempo limite de verificação de integridade. Se sp_server_diagnostics estiver lento ou não estiver retornando informações, a DLL do recurso aguardará o intervalo completo do limite de tempo limite da verificação de integridade antes de determinar que o recurso não está respondendo e iniciar um failover automático, se configurado para isso.
Failure-Condition Nível 3 2 Condições que acionam um failover automático. Existem cinco níveis de condição de falha, que vão desde o menos restritivo (nível um) até o mais restritivo (nível cinco)

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

Para grupos de alta 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;

Para os grupos de disponibilidade , comece com os seguintes parâmetros recomendados e ajuste conforme necessário.

Parâmetro Valor padrão Valor Flexível Descrição
Tempo limite de arrendamento 20000 40000 Previne a divisão do cérebro.
Tempo limite da sessão 10000 20000 Verifica problemas de comunicação entre réplicas. O período de tempo de espera da sessão é uma propriedade de réplica que controla por quanto tempo (em segundos) uma réplica de disponibilidade aguarda uma resposta de ping de uma réplica conectada antes de considerar que a conexão falhou. Por padrão, uma réplica aguarda 10 segundos por uma resposta de ping. Essa propriedade de réplica se aplica somente à conexão entre uma determinada réplica secundária e a réplica primária do grupo de disponibilidade.
Falhas máximas no período especificado 2 6 Usado para evitar o movimento indefinido de um recurso em cluster durante múltiplas falhas de nós. Um valor muito baixo pode fazer com que o grupo de disponibilidade esteja em um estado de falha. Aumente o valor para evitar interrupções curtas devido a problemas de desempenho, pois um valor muito baixo pode levar a AG a estar em um estado de falha.

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 de SameSubnetThreshold e SameSubnetDelay relaxados recomendados anteriormente, não exceda 80 segundos para o valor de tempo limite de concessão.
  • Para réplicas de confirmação síncrona, aumentar o valor do tempo limite da sessão pode aumentar os tempos de espera HADR_sync_commit.

Tempo limite do arrendamento

Use o Gestor de Cluster de Failover para modificar as configurações de tempo limite de leasing do seu grupo de disponibilidade. Consulte a documentação sobre a 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

Utilize o Gestor de Clusters de Failover para modificar o valor de falhas máximas no período especificado.

  1. Selecione Funções no painel de navegação.
  2. Em Funções, clique com o botão direito do rato no recurso clusterizado e escolha Propriedades.
  3. Selecione a guia de Failover e aumente o valor de Falhas Máximas 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:

  • Utilize Análise de E/S (Pré-visualização) no portal do Azure para identificar problemas de desempenho de disco que podem causar um failover.
  • 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 nas Máquinas Virtuais do Azure
  • Utilização
  • 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 uma 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.

Ligação em 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 somente em uma única rede. Você pode ignorar essa advertência em clusters de failover de convidados em máquinas virtuais 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 do Azure, não compatível com a RFC, pode causar a falha na criação de certas configurações de cluster de failover. 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 está atribuído tanto ao NODE1 como ao nome de rede do cluster de failover, e o grupo de cluster padrão não consegue ficar 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 motor de base de dados do SQL Server, o listener do grupo de disponibilidade do Always On, a sonda de integridade da instância do cluster de failover, o endpoint de espelhamento da base de dados, o recurso de 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. Este evento pode ser visto nos eventos do 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 sondagem é usada para verificar o estado de uma instância do pool de back-end do Balanceador de Carga do Azure.
Se o teste de integridade de falhar em obter uma resposta de uma instância de back-end, então 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 a causa do failover automático.

Utilize a análise de E/S

Use Análise de E/S (Visualização) no portal do Azure para identificar problemas de desempenho de disco que podem causar um failover.

Monitorização com métricas de IO de armazenamento de VMs

Monitor de Máquinas Virtuais do Azure 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é o de Máquina Virtual do no portal do Azure - não as máquinas virtuais SQL.

  2. Selecione Métricas em Monitorização para abrir a página de Métricas .

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

    Captura de tela da página Métricas no portal do Azure, selecionando alterar o período de tempo do gráfico.

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

    • Porcentagem de largura de banda consumida em cache da VM
    • Porcentagem de largura de banda consumida sem cache da VM

Captura de ecrã da página Métricas no portal do Azure.

Os eventos do anfitrião do Azure VM causam comutação por falha

É possível que um HostEvent de VM do Azure faça com que seu grupo de disponibilidade faça failover. Se acreditar que um HostEvent de VM do Azure causou um failover, 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 Azure Monitor é um log de plataforma, no Azure, que fornece informações sobre eventos ao nível da subscrição. 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. Selecione Registro de Atividades no painel da Máquina Virtual.

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

    Captura de ecrã do portal do Azure, mostrando o registo de atividades.

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 de Integridade dos Recursos da VM do Azure até 72 horas após a indisponibilidade inicial. Essas informações só estão disponíveis para máquinas virtuais no momento.

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

Captura de ecrã da página Estado de Funcionamento dos Recursos no portal do Azure.

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

Nó de cluster removido da associação

Se o configurações de pulsação e limite do Cluster do Windows for muito agressivo 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 Resolução de problemas de cluster com o ID de Evento 1135.

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

Se de monitoramento for muito agressivo para seu ambiente, você poderá ver reinicializações, falhas ou failovers frequentes do grupo de disponibilidade ou 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.

Tempo limite de conexã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 a enfrentar falhas intermitentes devido a problemas transitórios, o seu grupo de disponibilidade poderá terminar num 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 registo do nome DNS associado ao recurso de nome de rede

  • Verifique as configurações de NIC para cada um dos nós do cluster para certificar-se de que não há registros DNS externos presentes
  • Verifique se o registro A para seu cluster existe em seus servidores DNS internos. Caso contrário, crie um novo manual de Registro A no Servidor DNS para o objeto Controle de Acesso a Cluster e marque a opção Permitir que usuários autenticados atualizem Registros DNS com o mesmo nome de proprietário.
  • Desative o recurso "Nome do cluster" juntamente com o recurso IP e corrija-o.

Evento 157 - O disco foi removido de surpresa.

Isso pode acontecer se a propriedade Espaços de Armazenamento AutomaticClusteringEnabled estiver definida como True para um ambiente AG. Altere-o para False. Além disso, a execução de um Relatório de Validação com a opção de Armazenamento pode acionar o evento de redefinição de disco ou remoção surpresa. O sistema de armazenamento Throttling também pode acionar o evento de remoção surpresa 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 permissões apropriadas no domínio

Erros de agrupamento do Windows

Pode encontrar problemas na configuração de um cluster de failover do Windows ou na sua conectividade se não tiver as portas de serviço do cluster abertas para comunicação.

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

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

Próximos passos

Para saber mais, consulte: