Mecânica e diretrizes de tempo limite de locação, cluster e verificação de integridade para grupos de disponibilidade Always On
As diferenças nas configurações de hardware, software e cluster, bem como os diferentes requisitos de aplicativos para tempo de atividade e desempenho, exigem configurações específicas para valores de tempo limite de concessão, cluster e verificação de integridade. Determinados aplicativos e cargas de trabalho exigem um monitoramento mais agressivo para limitar o tempo de inatividade após falhas graves. Outros requerem mais tolerância a problemas de rede transitórios, aceitando atrasos devido ao elevado uso de recursos, e estão confortáveis com failovers mais lentos.
Vários serviços em cada nó trabalham para detetar falhas. O serviço de cluster pode detetar perda de quorum, a DLL de recurso pode detetar um problema surgido pela deteção de integridade Always On ou o failover manual pode ser iniciado diretamente na instância primária. O serviço de cluster, o host de recursos e a instância do SQL Server sincronizam entre si via RPC, memória compartilhada e T-SQL. Na maioria dos cenários, esses serviços se comunicam com sucesso, no entanto, essa comunicação não é perfeitamente confiável, mesmo entre serviços na mesma máquina. Além disso, o grupo de disponibilidade (AG) precisa ser capaz de suportar eventos em todo o sistema, como falhas de rede e disco, que podem impedir a comunicação ou interromper a funcionalidade. Com muitos casos de falha e sem comunicação totalmente confiável entre serviços, o AG depende de vários mecanismos de deteção de failover para detetar e responder a falhas independentemente uns dos outros, para que o estado do cluster seja sempre consistente para todos os nós.
Deteção de nós e recursos do cluster
Cada nó no cluster executa um único serviço de cluster, que opera o cluster de comutação por falha e monitoriza todos os recursos do cluster. O host de recursos opera como um processo separado e é a interface entre o serviço de cluster e os recursos de cluster. O host de recursos executa operações em recursos de cluster quando chamado pelo serviço de cluster. Aplicativos com reconhecimento de cluster, como o SQL Server, fornecem interfaces personalizadas para o monitor de recursos por meio de DLLs de recursos. A DLL do recurso implementa operações online e offline e monitorização de integridade para recursos personalizados. O host de recursos é um processo filho do serviço de cluster e é morto sempre que o serviço de cluster é morto.
Para o SQL Server, a DLL do recurso AG determina a integridade do AG com base no mecanismo de concessão AG e na deteção de integridade Always On. A DLL do recurso AG expõe a integridade do recurso por meio da operação IsAlive. O monitor de recursos sonda IsAlive no intervalo de batimento do cluster, que é definido pelos valores CrossSubnetDelay e SameSubnetDelay para todo o cluster. Em um nó primário, o serviço de cluster inicia failovers sempre que a chamada IsAlive para a DLL de recurso retorna que o AG não está íntegro.
O serviço de cluster envia pulsações para outros nós no cluster e reconhece as pulsações recebidas deles. Quando um nó deteta uma falha de comunicação a partir de uma série de batimentos cardíacos não confirmados, ele transmite uma mensagem fazendo com que todos os nós alcançáveis reconciliem suas visões da saúde dos nós do cluster. Esse evento, chamado de evento de reagrupamento, mantém a consistência do estado do cluster através de nós. Após um evento de reagrupamento, se o quórum for perdido, todos os recursos do cluster, incluindo AGs nessa partição, serão colocados offline. Todos os nós nesta partição são transferidos para um estado de resolução. Se existir uma partição, que contém um quórum, o AG é atribuído a um nó na partição e torna-se a réplica primária, enquanto todos os outros nós se tornam réplicas secundárias.
Deteção permanente de saúde
A DLL do recurso Always On monitora o status dos componentes internos do SQL Server.
sp_server_diagnostics relata a integridade desses componentes SQL Server em um intervalo controlado por HealthCheckTimeout.
sp_server_diagnostics relata o status de integridade de cinco componentes de nível de instância: sistema, recurso, processamento de consultas, subsistema de E/S e eventos. Também informa a saúde de cada AG. Após cada atualização, a DLL do recurso atualiza o status de integridade do recurso AG com base no nível de falha do AG. Quando os dados são retornados por sp_server_diagnostics, ele mostra cada componente como em um estado limpo, de aviso, erro ou desconhecido com alguns dados XML descrevendo o estado do componente. Para deteção de saúde, a DLL do recurso só entra em ação se um componente estiver em estado de erro.
Se a deteção de saúde não conseguir relatar uma atualização para a DLL do recurso por vários intervalos, o AG será considerado não saudável e relatará falhas nas chamadas de IsAlive.
Mecanismo de locação
Ao contrário de outros mecanismos de failover, a instância do SQL Server desempenha um papel ativo no mecanismo de concessão. O mecanismo de concessão é usado como uma validação de Looks-Alive entre o host de recursos de cluster e o processo do SQL Server. O mecanismo é usado para garantir que os dois lados (o Serviço de Cluster e o serviço SQL Server) estejam em contato frequente, verificando o estado um do outro e, em última análise, evitando um cenário de cérebro dividido. Ao colocar o AG online como a réplica primária, a instância do SQL Server inicia um thread trabalhador de lease dedicado para o AG. O trabalhador de locação compartilha uma pequena região de memória com o host de recursos que contém eventos de renovação e interrupção de locação. O trabalhador arrendatário e o anfitrião de recursos trabalham de forma circular, sinalizando o seu respetivo evento de renovação do contrato de arrendamento e, em seguida, dormindo, esperando que a outra parte sinalize o seu próprio evento de renovação do contrato de arrendamento ou evento de paragem. Tanto o host de recursos quanto o thread de concessão do SQL Server mantêm um valor de tempo de vida, que é atualizado sempre que o thread é ativado depois de ser sinalizado pelo outro thread. Se o tempo de vida for atingido enquanto aguarda o sinal, a concessão expira e, em seguida, a réplica transita para o estado de resolução para esse AG específico. Se o evento de parada de concessão for sinalizado, a réplica passará para uma função de resolução.
O mecanismo de concessão impõe a sincronização entre o SQL Server e o Cluster de Failover do Windows Server. Quando um comando de failover é emitido, o serviço de cluster realiza a chamada Offline para a DLL de recurso da réplica primária atual. A DLL do recurso primeiro tenta colocar o AG offline usando um procedimento armazenado. Se esse procedimento armazenado falhar ou atingir o tempo limite, a falha será relatada de volta ao serviço de cluster, que emitirá um comando terminate. O terminate novamente tenta executar o mesmo procedimento armazenado, mas o cluster desta vez não espera que a DLL do recurso relate sucesso ou falha antes de colocar o AG online em uma nova réplica. Se essa segunda chamada de procedimento falhar, o host de recursos terá que confiar no mecanismo de concessão para colocar a instância offline. Quando a DLL do recurso é chamada para colocar o AG offline, a DLL do recurso sinaliza o evento de parada de concessão, despertando o thread de trabalho de concessão do SQL Server para colocar o AG offline. Mesmo que esse evento de parada não seja sinalizado, a concessão expira e a réplica passará para o estado de resolução.
A concessão é principalmente um mecanismo de sincronização entre a instância primária e o cluster, mas também pode criar condições de falha onde de outra forma não haveria necessidade de failover. Por exemplo, elevada utilização da CPU, condições de esgotamento de memória (pouca memória virtual, paginação de processos), processo SQL não respondendo ao gerar um despejo de memória, sistema não respondendo, cluster (WSFC) ficando offline (como devido a perda de quórum) podem impedir a renovação de arrendamento da instância SQL e causar uma reinicialização ou transição (failover).
Diretrizes para valores de tempo de inatividade de cluster
Considere cuidadosamente as compensações e compreenda as consequências do uso de um monitoramento menos agressivo do cluster do SQL Server. O aumento dos valores de tempo limite do cluster aumenta a tolerância a problemas transitórios de rede, mas retarda as reações a falhas graves. O aumento dos tempos limite para lidar com a pressão de recursos ou a grande latência geográfica também aumentará o tempo de recuperação de falhas difíceis ou não recuperáveis. Embora isso seja aceitável para muitas aplicações, não é ideal em todos os casos.
As configurações padrão são otimizadas para reagir rapidamente a sintomas de falhas graves e limitar o tempo de inatividade, mas essas configurações também podem ser excessivamente agressivas para determinadas cargas de trabalho e configurações. Não é recomendado baixar nenhum dos LeaseTimeout, CrossSubnetDelay, CrossSubnetThreshold, SameSubnetDelay, SameSubnetThresholdou HealthCheckTimeout além de seus valores padrão. As configurações corretas para cada implantação variam e provavelmente levam um período mais longo de ajuste fino para serem descobertas. Ao fazer alterações em qualquer um desses valores, faça-as gradualmente e levando em consideração as relações e dependências entre esses valores.
Relação entre o tempo limite do cluster e o tempo limite da concessão
A função principal do mecanismo de concessão é colocar o recurso do SQL Server offline se o serviço de cluster não puder se comunicar com a instância durante a execução de um failover para outro nó. Quando o cluster executa a operação offline no recurso de cluster AG, o serviço de cluster faz uma chamada RPC para rhs.exe para colocar o recurso offline. A DLL do recurso usa procedimentos armazenados para informar ao SQL Server para colocar o AG offline, mas esse procedimento armazenado pode falhar ou atingir o tempo limite. O host de recursos também interrompe seu próprio thread de renovação de concessão durante a chamada offline. Na pior das hipóteses, o SQL Server faz com que a concessão expire em 1/2 * LeaseTimeout e faça a transição da instância para um estado de resolução. Os failovers podem ser iniciados por várias partes diferentes, mas é de vital importância que a exibição do estado do cluster seja consistente no cluster e nas instâncias do SQL Server. Por exemplo, imagine um cenário em que a instância primária perde a conexão com o restante do cluster. Cada nó no cluster determina uma falha em momentos semelhantes devido aos valores de tempo limite do cluster, mas apenas o nó primário pode interagir com a instância primária do SQL Server para forçá-la a desistir da função principal.
Da perspetiva do nó primário, o serviço de cluster perdeu quórum e o serviço começa a se encerrar. O serviço de cluster emite uma chamada RPC para o host de recursos para encerrar o processo. Esta chamada de encerramento é responsável por colocar o AG em modo offline na instância do SQL Server. Essa chamada offline é feita via T-SQL, mas não pode garantir que a conexão será estabelecida com êxito entre o SQL e a DLL do recurso.
Do ponto de vista do resto do cluster, não há nenhuma réplica primária atualmente, portanto, o cluster vota e estabelece um único novo primário para os nós restantes no cluster. Se a procedura armazenada que foi chamada pela DLL do recurso falhar ou expirar, o cluster pode estar vulnerável a um cenário de divisão do cérebro.
O tempo limite de locação evita cenários cerebrais divididos em face de erros de comunicação. Mesmo que toda a comunicação falhe, o processo de DLL do recurso será encerrado e não será possível atualizar a concessão. Uma vez que o contrato de arrendamento expira, o sistema tira o AG do ar automaticamente. A instância do SQL Server precisa estar ciente de que não hospeda mais a réplica primária antes que o cluster estabeleça uma nova. Como o restante do cluster, que é responsável pela escolha de uma nova réplica primária, não tem meios de coordenação com a réplica primária atual, os valores de tempo limite garantem que uma nova réplica primária não seja estabelecida antes que a réplica primária atual fique offline.
Quando o cluster faz failover, a instância do SQL Server que hospeda a réplica primária anterior deve fazer a transição para um estado de resolução antes que a nova réplica primária fique online. O thread de concessão do SQL Server a qualquer momento tem um tempo restante de vida útil de 1/2 * LeaseTimeout, porque sempre que a concessão é renovada, o novo time-to-live é atualizado para o LeaseInterval ou 1/2 * LeaseTimeout. Se o serviço de cluster ou o host de recursos parar ou terminar sem sinalizar o evento de término de arrendamento, o cluster declarará o nó primário morto após SameSubnetThreshold\ SameSubnetDelay milissegundos. Dentro desse tempo, a locação deve expirar para que o principal tenha a garantia de estar offline. Como o tempo máximo de vida para o tempo limite do contrato de arrendamento é de 1/2 * LeaseTimeout, 1/2 * LeaseTimeout deve ser inferior a SameSubnetThreshold * SameSubnetDelay.
SameSubnetThreshold \<= CrossSubnetThreshold e SameSubnetDelay \<= CrossSubnetDelay devem ser verdadeiras para todos os clusters do SQL Server.
Operação de limite de tempo de análise de integridade
O tempo limite da verificação de integridade é mais flexível porque nenhum outro mecanismo de proteção contra falhas depende dele diretamente. O valor padrão de 30 segundos define o intervalo de sp_server_diagnostics em 10 segundos, com um valor mínimo de 15 segundos para o tempo limite e um intervalo de 5 segundos. Mais geralmente, o intervalo de atualização sp_server_diagnostics é sempre 1/3 * HealthCheckTimeout. Quando a DLL do recurso não recebe um novo conjunto de dados de integridade dentro de um intervalo de tempo, a mesma continua a usar os dados de integridade do intervalo anterior para determinar a integridade atual do AG e da instância. Aumentar o valor do tempo limite de verificação de integridade torna o primário mais tolerante à pressão da CPU, o que pode impedir que sp_server_diagnostics forneça novos dados em cada intervalo, no entanto, ele depende de verificações de integridade de dados desatualizadas por mais tempo. Independentemente do valor de tempo limite, assim que os dados forem recebidos indicando que a réplica não está saudável, a próxima chamada de IsAlive retornará que a instância não está saudável e o serviço de cluster iniciará um failover.
O nível de condição de falha do AG altera as condições de falha da verificação de integridade. Para qualquer nível de falha, se o elemento AG for relatado como não íntegro por sp_server_diagnostics a verificação de integridade falhará. Cada nível herda todas as condições de falha dos níveis abaixo dele.
| Nível | Condição em que a instância é considerada desativada |
|---|---|
| 1: OnServerDown | A verificação de integridade não toma nenhuma medida se algum recurso falhar, exceto o AG. Se os dados AG não forem recebidos dentro de 5 intervalos, ou 5/3 * HealthCheckTimeout |
| 2: EmServidorNãoResponde | Se nenhum dado for recebido do sp_server_diagnostics para o HealthCheckTimeout |
| 3: OnCriticalServerError | (Padrão) Se o componente do sistema relatar um erro |
| 4: OnModerateServerError | Se o componente de recurso reportar um erro |
| 5: EmQualquerCondiçãoDeFalhaQualificada | Se o componente de processamento de consultas relatar um erro |
Atualização de valores de tempo limite de cluster e "Always On"
Valores de cluster
Há quatro valores na configuração do WSFC que são responsáveis por determinar os valores de tempo limite do cluster:
- SameSubnetDelay
- SameSubnetThreshold
- CrossSubnetDelay
- CrossSubnetThreshold
Os valores de atraso determinam o tempo de espera entre pulsações do serviço de cluster e os valores de limite definem o número de pulsações que não podem receber nenhuma confirmação do nó ou recurso de destino antes que o objeto seja declarado morto pelo cluster. Se não houver um batimento cardíaco bem-sucedido entre nós na mesma sub-rede por mais de SameSubnetDelay \* SameSubnetThreshold milissegundos, o nó será considerado inativo. O mesmo acontece com a comunicação entre sub-redes usando os valores entre sub-redes.
Para listar todos os valores de cluster atuais, abra um terminal PowerShell elevado em qualquer nó do cluster de destino. Execute o seguinte comando:
Get-Cluster | fl *
Para atualizar qualquer um desses valores, execute o seguinte comando em um terminal do PowerShell elevado:
(Get-Cluster).<ValueName> = <NewValue>
Ao aumentar o produto Delay * Threshold para tornar o tempo limite do cluster mais tolerante, é mais eficaz aumentar primeiro o valor de atraso antes de aumentar o limite. Ao aumentar o atraso, o tempo entre cada batimento cardíaco é aumentado. Mais tempo entre os batimentos cardíacos dá mais tempo para que os problemas transitórios da rede se resolvam e diminuam o congestionamento da rede em relação ao envio de mais batimentos cardíacos no mesmo período.
Tempo limite de arrendamento
O mecanismo de concessão é controlado por um único valor específico para cada AG em um cluster WSFC. Um tempo limite de concessão pode resultar nos seguintes erros:
Error 35201:
A connection timeout has occurred while attempting to establish a connection to availability replica 'replicaname'
Error 35206:
A connection timeout has occurred on a previously established connection to availability replica 'replicaname'
Para modificar o valor de tempo limite de concessão, utilize o Gerenciador de Cluster de Failover e siga estas etapas:
Na guia funções, localize a função AG de destino. Selecione a função AG de destino.
Clique com o botão direito do mouse no recurso AG na parte inferior da janela e selecione Propriedades.
Na janela pop-up, navegue até ao separador de propriedades para ver uma lista de valores específicos para este AG. Selecione o valor LeaseTimeout para alterá-lo.
Dependendo da configuração do AG, pode haver recursos adicionais para ouvintes, discos compartilhados, compartilhamentos de arquivos, etc., esses recursos não exigem nenhuma configuração adicional.
Observação
O novo valor da propriedade 'LeaseTimeout' entrará em vigor depois que o recurso for colocado offline e colocado online novamente.
Valores de verificação de saúde
Dois valores controlam a verificação de integridade Always On: FailureConditionLevel e HealthCheckTimeout. O FailureConditionLevel indica o nível de tolerância para condições de falha específicas relatadas pelo sp_server_diagnostics e o HealthCheckTimeout configura o tempo que a DLL do recurso pode passar sem receber uma atualização do sp_server_diagnostics. O intervalo de atualização para sp_server_diagnostics é sempre HealthCheckTimeout / 3.
Para configurar o nível de condição de failover, use a opção FAILURE_CONDITION_LEVEL = <n> da instrução CREATE ou ALTERAVAILABILITY GROUP, onde <n> é um inteiro entre 1 e 5. O comando a seguir define o nível de condição de falha como 1 para AG 'AG1':
ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 1);
Para configurar o tempo limite de verificação de integridade, use a opção HEALTH_CHECK_TIMEOUT das instruções CREATE ou ALTERAVAILABILITY GROUP. O comando a seguir define o tempo limite de verificação de integridade para 60.000 milissegundos para AG AG1:
ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);
Resumo das diretrizes de timeout
Não é aconselhável reduzir quaisquer valores de tempo limite abaixo dos valores padrão.
O intervalo de concessão (½ * LeaseTimeout) deve ser menor que SameSubnetThreshold * SameSubnetDelay
LimiarMesmoSub-rede <= LimiarCruzSub-rede
SameSubnetDelay <= CrossSubnetDelay
| Configuração de tempo limite | Finalidade | Entre | Utilizações | EstáVivo & PareceVivo | Causas | Resultado |
|---|---|---|---|---|---|---|
| Tempo de expiração de locação Padrão: 20000 |
Evitar a divisão do cérebro | Principal para o clúster (HADR) |
objetos de evento do Windows | Utilizado em ambos | Sistema operativo não está a responder, memória virtual baixa, paginação de conjunto de trabalho, geração de dump, CPU sobrecarregada, WSFC inativo (perda de quórum) | Grupo de Disponibilidade (AG) recurso offline-online, failover (alternância automática) |
| Tempo limite da sessão Padrão: 10000 |
Informar sobre um problema de comunicação entre o Primário e o Secundário | Secundário a Primário (HADR) |
Soquetes TCP (mensagens enviadas via ponto de extremidade DBM) | Utilizado em nenhum dos dois | Comunicação de rede, Problemas no secundário - inativo, sistema operativo não responde, contenção de recursos |
Secundário - DESLIGADO |
| Tempo de espera do "HealthCheck" Padrão: 30000 |
Indicar o tempo de espera ao tentar determinar a integridade da réplica primária | Cluster para servidor primário (FCI & HADR) |
sp_server_diagnostics T-SQL | Utilizado em ambos | Condições de falha atendidas, SO não respondendo, memória virtual baixa, redução do conjunto de trabalho, geração de dump, WSFC (perda de quórum), problemas do agendador (agendadores bloqueados) | Recurso de AG Offline-online ou Failover, reinicialização/failover de FCI |