Meccanismo e linee guida dei timeout di lease, del cluster e del controllo di integrità per i gruppi di disponibilità Always On

Le differenze nell'hardware, nel software e nelle configurazioni del cluster, nonché i diversi requisiti di disponibilità operativa e prestazioni delle applicazioni, richiedono una configurazione specifica dei valori di timeout per lease, cluster e controllo di integrità. Alcune applicazioni e carichi di lavoro richiedono un monitoraggio più aggressivo per limitare il tempo di inattività dopo gli errori hardware. Altri casi richiedono una maggiore tolleranza ai problemi di rete transitori e ai tempi di attesa dovuti all'elevato utilizzo delle risorse e tollerano failover più lenti.

Vari servizi rilevano attivamente gli errori su ogni nodo. Il servizio cluster può rilevare la perdita di quorum, la DLL della risorsa può rilevare un problema associato al rilevamento integrità Always On oppure il failover manuale potrebbe essere avviato direttamente sull'istanza principale. Il servizio cluster, l'host di risorse e l'istanza di SQL Server si sincronizzano tra loro tramite RPC, memoria condivisa e T-SQL. Nella maggior parte degli scenari questi servizi comunicano correttamente. Tuttavia questa comunicazione non è del tutto affidabile anche tra servizi nello stesso computer. Il gruppo di disponibilità (AG) deve anche essere in grado di risolvere eventi che hanno effetto sull'intero sistema, ad esempio errori di rete e disco, che potrebbero impedire la comunicazione o compromettere la funzionalità. In presenza di numerosi scenari di errore e in assenza di una comunicazione completamente affidabile tra i servizi, l'AG si basa su vari meccanismi di rilevamento del failover per rilevare i guasti e reagire a essi indipendentemente gli uni dagli altri, in modo che lo stato del cluster sia sempre coerente per tutti i nodi.

Diagnostica del timeout per i controlli di integrità migliorata in SQL Server 2025

I vincoli di risorse, ad esempio cpu elevata, latenza del disco o esaurimento della memoria, possono attivare un timeout del lease del gruppo di disponibilità AlwaysOn. Quando viene segnalato un timeout di lease nel log del cluster, i dati di monitoraggio delle prestazioni più recenti per l'utilizzo della CPU, l'utilizzo della memoria e la latenza di lettura e scrittura del disco vengono segnalati nel log del cluster di failover di Windows insieme al timeout del lease.

Analogamente, i vincoli delle risorse possono anche attivare un timeout del controllo integrità. A partire da SQL Server 2025 (17.x), gli stessi contatori del monitoraggio delle prestazioni vengono ora riportati nel log del cluster di failover di Windows quando viene rilevato un timeout del controllo di integrità, in modo simile all'output diagnostico del timeout del lease.

Di seguito è riportato un esempio dell'output migliorato del log del cluster di failover di Windows per un timeout di controllo integrità:

[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 ERR   [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] AG health check failed, logging perf counter data collected so far
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:55:25.0, 21.857418, 3248349184.000000, 0.000000, 0.000253
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:55:35.0, 11.442071, 3255394304.000000, 0.000907, 0.000382
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:55:45.0, 9.979768, 3253981184.000000, 0.000415, 0.000549
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:55:55.0, 9.762850, 3251232768.000000, 0.001989, 0.000638
[Verbose] 000035b8.00001a64::2024/04/18-23:56:35.536 WARN  [RES] SQL Server Availability Group: [hadrag] 4/18/2024 23:56:5.0, 9.827234, 3250462720.000000, 0.002250, 0.001418

Nodo cluster e rilevamento delle risorse

Ogni nodo del cluster esegue un singolo servizio cluster, che gestisce il cluster di failover e controlla tutte le risorse del cluster. L'host di risorse funziona come processo separato ed è l'interfaccia tra il servizio cluster e le risorse del cluster. L'host di risorse esegue operazioni sulle risorse del cluster quando viene chiamato dal servizio cluster. Le applicazioni che supportano i cluster, come SQL Server, rendono disponibili interfacce personalizzate al monitoraggio risorse tramite le DLL della risorsa. La DLL della risorsa implementa operazioni online e offline e il monitoraggio dello stato per le risorse personalizzate. L'host di risorse è un processo figlio del servizio cluster e viene terminato ogni volta che viene terminato il servizio cluster.

Per SQL Server, la DLL della risorsa AG determina lo stato di integrità dell'AG in base al meccanismo di lease dell'AG e al rilevamento dell'integrità di Always On. La DLL della risorsa del gruppo di disponibilità espone lo stato di integrità della risorsa tramite l'operazione IsAlive. Il monitor delle risorse interroga IsAlive in base all'intervallo di heartbeat del cluster, impostato dai valori CrossSubnetDelay e SameSubnetDelay validi a livello di cluster. In un nodo primario, il servizio cluster avvia i failover ogni volta che la chiamata IsAlive alla DLL della risorsa indica che il gruppo di disponibilità non è in uno stato integro.

Il servizio del cluster invia heartbeat agli altri nodi del cluster e conferma la ricezione degli heartbeat ricevuti da essi. Quando un nodo rileva un guasto di comunicazione da una serie di heartbeat senza risposta, invia in broadcast un messaggio che induce tutti i nodi raggiungibili a riconciliare la propria visione dello stato di integrità dei nodi del cluster. Questo evento, detto evento regroup, mantiene la coerenza dello stato del cluster nei nodi. In seguito a un evento di raggruppamento, se il quorum viene perso, tutte le risorse del cluster in questa partizione, inclusi i gruppi di disponibilità (AG), vengono messe offline. Tutti i nodi di questa partizione vengono portati a uno stato di risoluzione. Se è presente una partizione che contiene un quorum, il gruppo di disponibilità viene assegnato a un nodo nella partizione e diventa la replica primaria, mentre tutti gli altri nodi diventano repliche secondarie.

Rilevamento dello stato di integrità Always On

La DLL della risorsa Always On esegue il monitoraggio dello stato dei componenti interni di SQL Server. sp_server_diagnostics segnala l'integrità SQL Server di questi componenti in un intervallo controllato da HealthCheckTimeout. sp_server_diagnostics segnala lo stato di integrità di cinque componenti di livello istanza: sistema, risorsa, elaborazione query, sottosistema I/O ed eventi. Segnala anche lo stato di ogni AG. A ogni aggiornamento, la DLL della risorsa aggiorna lo stato di integrità della risorsa AG in base al livello di errore dell'AG. Quando i dati vengono restituiti da sp_server_diagnostics, ogni componente viene visualizzato con stato normale, avviso, errore o sconosciuto e con dati XML che descrivono lo stato del componente. Per il rilevamento dello stato di integrità, la DLL della risorsa interviene solo se un componente si trova in uno stato di errore.

Se il monitoraggio dell'integrità non riesce a segnalare un aggiornamento della DLL della risorsa per più intervalli, il gruppo di disponibilità viene considerato non integro e segnalerà errori nelle chiamate IsAlive.

Meccanismo di locazione

A differenza di quanto accade in altri meccanismi di failover, nel meccanismo lease l'istanza di SQL Server svolge un ruolo attivo. Il meccanismo di lease viene utilizzato come convalida Looks-Alive tra l'host della risorsa cluster e il processo SQL Server. Con il meccanismo ci si assicura che i due lati, cioè il servizio cluster e il servizio SQL Server, abbiano contatti frequenti e che si controllino a vicenda lo stato per impedire, in definitiva, uno scenario split brain. Quando si porta il gruppo di disponibilità in linea come replica primaria, l'istanza di SQL Server genera un thread di lavoro dedicato per il lease del gruppo di disponibilità. Il processo worker del lease condivide una piccola area di memoria con l'host della risorsa, contenente gli eventi di rinnovo e di arresto del lease. Il worker del lease e l'host della risorsa operano in modo ciclico, segnalando il rispettivo evento di rinnovo del lease e quindi sospendendosi, in attesa che l'altra parte segnali il proprio evento di rinnovo del lease o l'evento di arresto. Sia l'host delle risorse sia il thread di lease di SQL Server mantengono un valore di durata residua, che viene aggiornato ogni volta che il thread si riattiva dopo aver ricevuto il segnale dall'altro thread. Se il tempo di vita viene raggiunto durante l'attesa del segnale, il lease scade e la replica passa quindi allo stato di risoluzione per quello specifico AG. Se viene segnalato l'evento di arresto del lease, la replica passa a un ruolo di risoluzione.

Il meccanismo di lease garantisce la sincronizzazione tra SQL Server e il cluster di failover di Windows Server. Quando viene eseguito un comando di failover, il servizio cluster esegue una chiamata Offline alla DLL della risorsa della replica primaria corrente. La DLL della risorsa tenta innanzitutto di portare offline l'AG mediante una stored procedure. Se la stored procedure ha esito negativo o registra un timeout, l'errore viene segnalato al servizio cluster, che esegue un comando di interruzione. Anche il comando Terminate tenta nuovamente di eseguire la stessa stored procedure, ma questa volta il cluster non attende che la DLL della risorsa segnali il successo o l'errore prima di portare online il gruppo di disponibilità su una nuova replica. Se questa seconda chiamata di procedura ha esito negativo, l'host di risorse deve fare affidamento sul meccanismo lease per portare offline l'istanza. Quando la DLL della risorsa viene chiamata per portare offline il gruppo di disponibilità, segnala l'evento di arresto del lease, risvegliando il thread di lavoro del lease di SQL Server affinché porti offline il gruppo di disponibilità. Anche se questo evento di arresto non viene segnalato, il lease scade e la replica passa allo stato di risoluzione.

Il lease è principalmente un meccanismo di sincronizzazione tra l'istanza primaria e il cluster, ma può anche creare condizioni di errore in casi per cui non sarebbe stato necessario eseguire il failover. Ad esempio, utilizzo della CPU elevato, condizioni di memoria insufficiente (scarsa memoria virtuale, paging dei processi), mancata risposta da parte del processo SQL durante la generazione di un dump della memoria, mancata risposta del sistema, cluster (WSFC) offline a causa della perdita del quorum possono impedire il rinnovo del lease da parte dell'istanza SQL Server e causare un riavvio o un failover.

Linee guida per i valori di timeout del cluster

Considerare con cura i vantaggi, gli svantaggi e le conseguenze dell'uso di un monitoraggio meno rigido del cluster di SQL Server. Se si incrementano i valori di timeout cluster, aumenta la tolleranza per i problemi di rete temporanei, ma la reazione agli errori hardware richiede più tempo. Anche l'incremento dei timeout per gestire la pressione sulle risorse o la latenza geografica estesa determina un aumento del tempo necessario per il recupero dagli errori hardware o irreversibili. Questo è accettabile per molte applicazioni, ma non è ideale in tutti i casi.

Le impostazioni predefinite sono ottimizzate per una reazione rapida ai sintomi di errori hardware e per la limitazione dei tempi di inattività, ma queste impostazioni possono rivelarsi eccessivamente aggressive per determinati carichi di lavoro e configurazioni. Non è consigliabile ridurre le impostazioni di LeaseTimeout, CrossSubnetDelay, CrossSubnetThreshold, SameSubnetDelay, SameSubnetThreshold o HealthCheckTimeout al di sotto dei valori predefiniti. Le impostazioni corrette per ogni distribuzione variano e la loro definizione può richiedere un periodo di messa a punto prolungato. Quando si apportano modifiche a uno di questi valori è necessario apportarle gradualmente, tenendo in considerazione le relazioni e le dipendenze tra i valori.

Relazione tra il timeout del cluster e il timeout del lease

La funzione primaria del meccanismo lease è di portare offline la risorsa di SQL Server quando il servizio cluster non può comunicare con l'istanza durante l'esecuzione di un failover a un altro nodo. Quando il cluster esegue l'operazione offline sulla risorsa del cluster AG, il servizio del cluster effettua una chiamata RPC a rhs.exe per mettere la risorsa non in linea. La DLL della risorsa usa le procedure archiviate per indicare a SQL Server di portare offline il gruppo di disponibilità (AG), ma queste procedure archiviate potrebbero non riuscire o scadere per timeout. L'host della risorsa interrompe anche il proprio thread di rinnovo del lease durante la chiamata di passaggio offline. Nel peggiore dei casi, SQL Server causa la scadenza del lease entro ½ * LeaseTimeout ed esegue la transizione dell'istanza a uno stato di risoluzione. I failover possono essere avviati da entità diverse, ma è importante che la visualizzazione dello stato del cluster sia coerente nelle diverse istanze cluster e nelle istanze di SQL Server. Considerare ad esempio uno scenario in cui l'istanza primaria perde la connessione al resto del cluster. Ogni nodo del cluster determina un errore in orari simili a causa dei valori di timeout cluster, ma solo il nodo primario può interagire con l'istanza di SQL Server primaria per imporre la rinuncia al ruolo primario.

Dal punto di vista del nodo primario, il servizio cluster ha perso il quorum e il servizio inizia la procedura di chiusura. Il servizio cluster rilascia una chiamata RPC all'host di risorse per terminare il processo. Questa chiamata di terminazione ha il compito di portare AG offline nell'istanza di SQL Server. Questa chiamata offline viene eseguita tramite T-SQL, ma non può garantire che verrà stabilita una connessione tra SQL e la DLL della risorsa.

Dal punto di vista del resto del cluster, al momento non è presente alcuna replica primaria e il cluster vota e stabilisce una nuova replica primaria singola per i nodi restanti nel cluster. Se la stored procedure che è stata chiamata dalla DLL della risorsa ha esito negativo o registra un timeout, il cluster potrebbe essere vulnerabile a uno scenario split brain.

Il timeout del lease evita scenari di split brain in presenza di errori di comunicazione. Anche se tutte le comunicazioni dovessero interrompersi, il processo DLL della risorsa verrà terminato e non sarà in grado di aggiornare il lease. Alla scadenza del lease, il processo mette automaticamente offline l'AG. L'istanza di SQL Server deve rilevare che non ospita più la replica primaria prima che il cluster ne stabilisca una nuova. Poiché il resto del cluster, responsabile della scelta di una nuova replica primaria, non è in grado di coordinare con la replica primaria corrente, i valori di timeout garantiscono che non venga impostata una nuova replica primaria fino a quando la replica primaria corrente non assume lo stato offline.

Quando il cluster esegue il failover, l'istanza di SQL Server che ospita la replica primaria precedente deve eseguire la transizione a uno stato di risoluzione prima che la nuova replica primaria assuma lo stato online. Il thread di lease di SQL Server ha in qualsiasi momento un time-to-live pari a ½ * LeaseTimeout, perché ogni volta che il lease viene rinnovato il nuovo time-to-live viene aggiornato a LeaseInterval o a ½ * LeaseTimeout. Se il servizio cluster o l'host di risorse si blocca o termina senza segnalare l'evento di arresto del lease, il cluster dichiara il nodo primario inattivo dopo SameSubnetThreshold\ SameSubnetDelay millisecondi. Entro questo periodo, il lease deve scadere, in modo da garantire che il primario sia offline. Poiché il time-to-live massimo per il timeout del lease è ½ * LeaseTimeout, ½ * LeaseTimeout deve essere inferiore a SameSubnetThreshold * SameSubnetDelay.

SameSubnetThreshold \<= CrossSubnetThreshold e SameSubnetDelay \<= CrossSubnetDelay devono essere true per tutti i cluster SQL Server.

Operazione di timeout del controllo di integrità

Il timeout del controllo di integrità è più flessibile perché nessun altro meccanismo di failover dipende direttamente da esso. Il valore predefinito di 30 secondi imposta l'intervallo sp_server_diagnostics su 10 secondi, con un valore minimo di 15 secondi per il timeout e un intervallo di 5 secondi. Più in generale, l'intervallo di aggiornamento di sp_server_diagnostics è sempre 1/3 * HealthCheckTimeout. Quando la DLL della risorsa non riceve un nuovo set di dati di integrità a un determinato intervallo, continua a usare i dati di integrità dell'intervallo precedente per determinare lo stato di integrità corrente di AG e dell'istanza. L'aumento del valore del timeout del controllo di integrità rende la replica primaria più tollerante al carico della CPU, il che può impedire a sp_server_diagnostics di fornire nuovi dati a ogni intervallo; tuttavia, per un periodo più lungo si basa su dati obsoleti per i controlli di integrità. Indipendentemente dal valore di timeout, quando si ricevono dati indicanti che la replica non è integra, la successiva chiamata IsAlive segnala che l'istanza non è integra e il servizio cluster avvia un failover.

Il livello della condizione di errore dell'AG cambia le condizioni di errore per il controllo di integrità. Per qualsiasi livello di guasto, se l'elemento AG è segnalato come non integro da sp_server_diagnostics, il controllo di integrità ha esito negativo. Ogni livello eredita tutte le condizioni di errore dai livelli inferiori.

Aggiornamento dei valori di timeout del cluster e di Always On

Valori del cluster

La configurazione di WSFC include quattro valori che determinano i valori di timeout cluster:

• SameSubnetDelay
• SogliaSottoReteStessa
• CrossSubnetDelay
• Soglia di attraversamento del sottorete

I valori di ritardo determinano il tempo di attesa tra gli heartbeat del servizio cluster, mentre i valori di soglia impostano il numero di heartbeat che possono non ricevere alcun riconoscimento da parte del nodo o della risorsa di destinazione prima che il cluster dichiari l'oggetto non operativo. Se non è presente nessun heartbeat con esito positivo tra nodi nella stessa subnet per oltre SameSubnetDelay \* SameSubnetThreshold millisecondi, il nodo viene considerato inattivo. Lo stesso vale per le comunicazioni tra subnet che usano i valori tra le subnet.

Per elencare tutti i valori cluster correnti, in qualsiasi nodo del cluster di destinazione aprire un terminale PowerShell con privilegi elevati. Esegui questo comando:

 Get-Cluster | fl *

Per aggiornare uno di questi valori, eseguire il comando seguente in un terminale PowerShell con privilegi elevati:

(Get-Cluster).<ValueName> = <NewValue>

Quando si aumenta il prodotto Delay * Threshold per rendere più tollerante il timeout del cluster, è più efficace aumentare prima il valore Delay e poi il valore Threshold. Aumentando il ritardo, aumenta il tempo che intercorre tra un heartbeat e l'altro. Più tempo tra gli heartbeat significa più tempo per la risoluzione dei problemi di rete temporanei e la riduzione della congestione della rete prodotta dall'invio di più heartbeat nello stesso periodo.

Timeout della locazione

Il meccanismo di lease è controllato da un unico valore specifico di ciascun AG in un cluster WSFC. Un timeout del lease potrebbe provocare i seguenti errori:

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'

Per modificare il valore del timeout del lease, utilizzare la Gestione cluster di failover e seguire questa procedura:

1. Nella scheda Ruoli, individuare il ruolo AG di destinazione. Selezionare il ruolo AG di destinazione.

2. Fare clic con il pulsante destro del mouse sulla risorsa AG in fondo alla finestra e selezionare Proprietà.

   

3. Nella finestra popup, passare alla scheda Proprietà per visualizzare un elenco di valori relativi a questo AG. Selezionare il valore LeaseTimeout per modificarlo.

   

   A seconda della configurazione dell'AG, potrebbero esserci risorse aggiuntive per i listener, i dischi condivisi, le condivisioni di file e così via; queste risorse non richiedono alcuna configurazione aggiuntiva.

Valori del controllo integrità

Il controllo integrità Always On è gestito da due valori: FailureConditionLevel e HealthCheckTimeout. FailureConditionLevel indica il livello di tolleranza a condizioni di errore specifiche segnalate da sp_server_diagnostics, mentre HealthCheckTimeout consente di configurare il tempo per il quale la DLL della risorsa può funzionare senza ricevere un aggiornamento da sp_server_diagnostics. L'intervallo di aggiornamento per sp_server_diagnostics è sempre HealthCheckTimeout/3.

Per configurare il livello della condizione di failover, usare l'opzione FAILURE_CONDITION_LEVEL = <n> dell'istruzione CREATE o ALTERAVAILABILITY GROUP, dove <n> è un numero intero incluso tra 1 e 5. Il comando seguente imposta il livello della condizione di errore su 1 per il gruppo di disponibilità "AG1":

ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 1);

Per configurare il timeout del controllo di integrità, usare l'opzione HEALTH_CHECK_TIMEOUT nelle istruzioni CREATE o ALTERAVAILABILITY GROUP. Il comando seguente imposta il timeout del controllo di integrità su 60.000 millisecondi per AG AG1:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);

Riepilogo delle linee guida per i timeout

• Non è consigliabile ridurre i valori di timeout al di sotto dei valori predefiniti.

• L'intervallo di lease (½ * LeaseTimeout) deve essere più breve di SameSubnetThreshold * SameSubnetDelay

• SogliaSubnetStessa <= SogliaSubnetIncrociata

• SameSubnetDelay < = CrossSubnetDelay

Contenuto correlato

• Secondarie attive: backup su repliche secondarie (Gruppi di disponibilità Always On)
• ALTER AVAILABILITY GROUP (Transact-SQL)