Mechanica en richtlijnen voor time-outs voor lease, cluster en statuscontrole voor AlwaysOn-beschikbaarheidsgroepen

Verschillen in hardware-, software- en clusterconfiguraties en verschillende toepassingsvereisten voor uptime en prestaties vereisen specifieke configuratie voor time-outwaarden voor lease, cluster en statuscontrole. Voor bepaalde toepassingen en workloads is agressievere bewaking vereist om downtime te beperken na harde fouten. Andere vereisen meer tolerantie voor tijdelijke netwerkproblemen en wachttijden van hoog resourcegebruik en zijn in orde met tragere failovers.

Meerdere services op elk knooppunt werken om fouten te detecteren. De clusterservice kan quorumverlies detecteren, het bron-DLL-bestand kan een probleem detecteren dat wordt gedetecteerd door AlwaysOn-statusdetectie, of handmatige failover kan rechtstreeks op het primaire exemplaar worden gestart. De clusterservice, de resourcehost en het SQL Server-exemplaar worden met elkaar gesynchroniseerd via RPC, gedeeld geheugen en T-SQL. In de meeste scenario's communiceren deze services met succes, maar deze communicatie is niet perfect betrouwbaar, zelfs niet tussen services op dezelfde computer. Bovendien moet de beschikbaarheidsgroep (AG) bestand zijn tegen systeembrede gebeurtenissen, zoals netwerk- en schijffouten, waardoor communicatie of onderbrekingsfunctionaliteit mogelijk wordt voorkomen. Met veel foutgevallen en zonder volledig betrouwbare communicatie tussen services is de AG afhankelijk van verschillende mechanismen voor failoverdetectie om fouten onafhankelijk van elkaar te detecteren en erop te reageren, zodat de clusterstatus altijd consistent is voor alle knooppunten.

SQL Server 2025 verbeterde time-outdiagnose voor gezondheidscontrole

Resourcebeperkingen, zoals hoge CPU, schijflatentie of geheugenuitputting, kunnen een lease-time-out bij een Always On-beschikbaarheidsgroep activeren. Wanneer een lease-time-out wordt gerapporteerd in het clusterlogboek, worden de meest recente prestatiemetergegevens voor CPU-gebruik, geheugengebruik en schijf lees- en schrijfvertraging gerapporteerd in het Windows Failover Clusterlogboek, samen met de lease-time-out.

Op dezelfde manier kunnen resourcebeperkingen ook een time-out voor statuscontrole activeren. Vanaf SQL Server 2025 (17.x) Preview worden dezelfde prestatiemeteritems nu gerapporteerd in het windows-failoverclusterlogboek wanneer er een time-out voor statuscontrole wordt gedetecteerd, vergelijkbaar met de diagnostische uitvoer van de leasetime-out.

Hier volgt een voorbeeld van de verbeterde uitvoer van het Windows-failoverclusterlogboek voor een time-out voor statuscontrole:

[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

Clusterknooppunt en bronopsporing

Elk knooppunt in het cluster voert één clusterservice uit, die het failovercluster beheert en alle clusterbronnen bewaakt. De resourcehost werkt als een afzonderlijk proces en is de interface tussen de clusterservice en clusterresources. De resourcehost voert bewerkingen uit op clusterresources wanneer deze door de clusterservice wordt aangeroepen. Clusterbewuste toepassingen zoals SQL Server bieden aangepaste interfaces voor de resourcemonitor via resource-DLL's. De resource-DLL implementeert online- en offline-operaties en gezondheidsbewaking voor aangepaste resources. De resourcehost is een onderliggend proces van de clusterservice en wordt gedood wanneer de clusterservice wordt gedood.

Voor SQL Server bepaalt de AG resource DLL de status van de AG op basis van het lease-mechanisme van de beschikbaarheidsgroep en Always On-statusdetectie. De DLL van de AG-resource maakt de status van de resource beschikbaar via de IsAlive bewerking. De resourcemonitor peilt IsAlive op het heartbeatinterval van het cluster, dat wordt ingesteld door de CrossSubnetDelay en SameSubnetDelay clusterbrede waarden. Op een primair knooppunt initieert de clusterservice failovers wanneer de IsAlive-aanroep naar de bron-DLL retourneert dat de beschikbaarheidsgroep niet gezond is.

De clusterservice verzendt hartslagen naar andere knooppunten in het cluster en bevestigt de ontvangen hartslagen. Wanneer een knooppunt een communicatiefout detecteert door een reeks niet-bevestigde hartslagen, wordt er een bericht uitgezonden dat ervoor zorgt dat alle bereikbare knooppunten hun weergaven van de status van het clusterknooppunt afstemmen. Deze gebeurtenis, een gebeurtenis voor opnieuw groeperen genoemd, onderhoudt de consistentie van de clusterstatus tussen knooppunten. Als het quorum verloren gaat na een hergroeperingsgebeurtenis, worden alle clusterresources, inclusief AG's in deze partitie, offline gehaald. Alle knooppunten in deze partitie worden overgezet naar een oplossingsstatus. Als er een partitie bestaat die een quorum bevat, wordt de AG toegewezen aan één knooppunt in de partitie en fungeert als de primaire replica, terwijl alle andere knooppunten secundaire replica's worden.

AlwaysOn-statusdetectie

De ALWAYSOn-resource-DLL bewaakt de status van interne SQL Server-onderdelen. sp_server_diagnostics rapporteert de status van deze onderdelen SQL Server op een interval dat wordt beheerd door HealthCheckTimeout. sp_server_diagnostics rapporteert de status van vijf onderdelen op exemplaarniveau: systeem, resource, queryverwerking, io-subsysteem en gebeurtenissen. Ook wordt de gezondheid van elke AG gerapporteerd. Bij elke update werkt het DLL-bestand van de resource de status van de AG-resource bij, gebaseerd op het foutniveau van de AG. Wanneer gegevens worden geretourneerd door sp_server_diagnostics, wordt elk onderdeel weergegeven als een schone, waarschuwing, fout of onbekende status met een aantal XML-gegevens die de status van het onderdeel beschrijven. Voor gezondheiddetectie neemt de resource-DLL alleen actie als een component zich in een foutstatus bevindt.

Als statusdetectie gedurende meerdere intervallen een update naar het bron-DLL-bestand niet kan rapporteren, wordt de beschikbaarheidsgroep als beschadigd vastgesteld en worden er fouten IsAlive in aanroepen weergegeven.

Leasemechanisme

In tegenstelling tot andere failovermechanismen speelt het SQL Server-exemplaar een actieve rol in het leasemechanisme. Het lease-mechanisme wordt gebruikt als een Looks-Alive-validatie tussen de clusterresourcehost en het SQL Server-proces. Het mechanisme wordt gebruikt om ervoor te zorgen dat de twee zijden (de Cluster Service en SQL Server-service) regelmatig contact hebben, elkaars status controleren en uiteindelijk een split-brain-scenario voorkomen. Wanneer u de beschikbaarheidsgroep als primaire replica online brengt, roept het SQL Server-exemplaar een specifieke leaseworker-thread op voor de AG. De leasemedewerker deelt een klein geheugengebied met de resourcehost die leasevernieuwings- en leasestop-gebeurtenissen bevat. De leasemedewerker en de resourcehost werken in een circulaire volgorde: ze signaleren hun respectieve leasevernieuwing en slapen vervolgens, wachtend tot de andere partij een eigen leasevernieuwing of een stopgebeurtenis aangeeft. Zowel de resourcehost als de SQL Server-leasethread onderhouden een time-to-live-waarde, die telkens wordt bijgewerkt wanneer de thread wordt geactiveerd nadat deze door de andere thread is gesignaleerd. Als de time-to-live is bereikt tijdens het wachten op het signaal, verloopt de lease en gaat de replica over naar de oplossingsstatus voor die specifieke beschikbaarheidsgroep. Als het einde van de leaseperiode wordt gesignaleerd, verandert de replica naar een rol die problemen oplost.

Het leasemechanisme dwingt synchronisatie af tussen SQL Server en Windows Server Failover Cluster. Wanneer een failoveropdracht wordt uitgegeven, roept de clusterservice de Offline resource-DLL van de huidige primaire replica aan. De resource-DLL probeert eerst de AG offline te halen middels een opgeslagen procedure. Als deze opgeslagen procedure mislukt of een time-out optreedt, wordt de fout teruggegeven aan de clusterservice, die vervolgens een beëindigingsopdracht uitgeeft. Het beëindigingsproces probeert opnieuw dezelfde opgeslagen procedure uit te voeren, maar het cluster wacht deze keer niet op een rapportage van succes of mislukking van de resource DLL voordat de beschikbaarheidsgroep online wordt gebracht op een nieuwe replica. Als deze tweede procedure-aanroep mislukt, moet de resourcehost vertrouwen op het leasemechanisme om het exemplaar offline te halen. Wanneer de resource-DLL wordt aangeroepen om de beschikbaarheidsgroep offline te halen, signaleert de resource-DLL de leasestop-gebeurtenis, om de SQL Server-leaseworkerthread te activeren en de beschikbaarheidsgroep offline te halen. Zelfs als deze stopgebeurtenis niet wordt gesignaleerd, verloopt de lease en wordt de replica overgezet naar de oplossingsstatus.

De lease is voornamelijk een synchronisatiemechanisme tussen het primaire exemplaar en het cluster, maar het kan ook foutvoorwaarden maken waarbij er anders geen failover hoeft te worden uitgevoerd. Een hoog CPU-gebruik, onvoldoende geheugen (weinig virtueel geheugen, procespaginering), SQL-proces reageert niet tijdens het genereren van een geheugendump, het systeem reageert niet, het cluster (WSFC) dat offline gaat (bijvoorbeeld vanwege quorumverlies) kan de leasevernieuwing van het SQL-exemplaar verhinderen en een herstart of failover veroorzaken.

Richtlijnen voor time-outwaarden voor clusters

Houd zorgvuldig rekening met de afwegingen en begrijp de gevolgen van het gebruik van minder agressieve bewaking van uw SQL Server-cluster. Het verhogen van time-outwaarden voor clusters verhoogt de tolerantie van tijdelijke netwerkproblemen, maar vertraagt reacties op harde fouten. Het verhogen van de time-outs om om te gaan met resourcedruk of een grote geografische latentie, vergroot ook de tijd die nodig is om te herstellen van ernstige of onomkeerbare fouten. Hoewel dit acceptabel is voor veel toepassingen, is het in alle gevallen niet ideaal.

De standaardinstellingen zijn geoptimaliseerd voor snelle reactie op de symptomen van harde fouten en het beperken van downtime, maar deze instellingen kunnen ook te agressief zijn voor bepaalde workloads en configuraties. Het wordt afgeraden om LeaseTimeout, CrossSubnetDelay, CrossSubnetThreshold, SameSubnetDelay, SameSubnetThreshold of HealthCheckTimeout tot onder hun standaardwaarden te verlagen. De juiste instellingen voor elke implementatie variëren en het kost waarschijnlijk meer tijd om deze door middel van verfijning te ontdekken. Wanneer u wijzigingen aanbrengt in een van deze waarden, moet u deze geleidelijk en met inachtneming van de relaties en afhankelijkheden tussen deze waarden aanbrengen.

Relatie tussen time-out van cluster en lease-time-out

De primaire functie van het leasemechanisme is om de SQL Server-resource offline te halen als de clusterservice niet kan communiceren met het exemplaar tijdens het uitvoeren van een failover naar een ander knooppunt. Wanneer het cluster een offline bewerking uitvoert op de AG-clusterresource, maakt de clusterservice een RPC-aanroep naar rhs.exe om de resource offline te halen. De resource-DLL maakt gebruik van opgeslagen procedures om SQL Server te laten weten dat de beschikbaarheidsgroep offline moet worden gehaald, maar deze opgeslagen procedure kan mislukken of er een time-out optreedt. De resourcehost stopt ook zijn eigen thread voor leasevernieuwing tijdens de offline-aanroep. In het ergste geval laat SQL Server de lease verlopen in ½ * LeaseTimeout en brengt het exemplaar naar een oplossingsmodus. Failovers kunnen door meerdere verschillende partijen worden gestart, maar het is van cruciaal belang dat de weergave van de clusterstatus consistent is in het cluster en in SQL Server-exemplaren. Stel u een scenario voor waarbij de primaire instantie de verbinding met de rest van het cluster verliest. Elk knooppunt in het cluster bepaalt een fout op vergelijkbare tijdstippen vanwege de time-outwaarden van het cluster, maar alleen het primaire knooppunt kan communiceren met het primaire SQL Server-exemplaar om dit af te dwingen de primaire rol op te geven.

Vanuit het perspectief van het primaire knooppunt is het quorum van de clusterservice verbroken en begint de service zichzelf te beëindigen. De clusterservice geeft een RPC-aanroep naar de resourcehost uit om het proces te beëindigen. Deze beëindigingsoproep is verantwoordelijk voor het offline halen van de AG op het SQL Server-exemplaar. Deze offlineaanroep wordt uitgevoerd via T-SQL, maar kan niet garanderen dat de verbinding tot stand is gebracht tussen SQL en het bron-DLL-bestand.

Vanuit het perspectief van de rest van het cluster is er momenteel geen primaire replica, dus stemmen de clusterleden en stellen ze een nieuwe primaire replica in voor de resterende knooppunten in het cluster. Als de opgeslagen procedure die door de resource-DLL is aangeroepen, faalt of een time-out veroorzaakt, kan het cluster kwetsbaar zijn voor een split-brain scenario.

De lease-time-out voorkomt situaties van splitsing van hersenfuncties bij communicatiefouten. Zelfs wanneer alle communicatie faalt, zal het resource-DLL-proces beëindigd worden en zal het niet mogelijk zijn om de lease bij te werken. Zodra de lease is verlopen, wordt de beschikbaarheidsgroep automatisch offline gehaald. Het exemplaar van SQL Server moet er rekening mee houden dat deze niet langer als host fungeert voor de primaire replica voordat het cluster een nieuwe maakt. Omdat de rest van het cluster, dat verantwoordelijk is voor het kiezen van een nieuwe primaire replica, geen middelen heeft om te coördineren met de huidige primaire replica, zorgt de time-outwaarden ervoor dat er geen nieuwe primaire replica tot stand is gebracht voordat de huidige primaire replica offline gaat.

Wanneer een failover van het cluster wordt uitgevoerd, moet het exemplaar van SQL Server dat als host fungeert voor de vorige primaire replica overschakelen naar een oplossingsstatus voordat de nieuwe primaire replica online komt. De SQL Server-leasethread heeft op elk moment een resterende time-to-live van 1/2 * LeaseTimeout, omdat wanneer de lease wordt vernieuwd, de nieuwe time-to-live wordt bijgewerkt naar de LeaseInterval of 1/2 * LeaseTimeout. Als de clusterservice of de resourcehost vastloopt of wordt beëindigd zonder dat een signaal voor de beëindiging van de lease wordt gegeven, verklaart het cluster het primaire knooppunt dood na SameSubnetThreshold\ SameSubnetDelay milliseconden. Binnen deze tijd moet de lease verlopen, zodat de primaire server gegarandeerd offline zal zijn. Omdat de maximale time-to-live voor de lease-timeout ½ * LeaseTimeout is, moet ½ * LeaseTimeout kleiner zijn dan SameSubnetThreshold * SameSubnetDelay.

SameSubnetThreshold \<= CrossSubnetThreshold en SameSubnetDelay \<= CrossSubnetDelay moet waar zijn voor alle SQL Server-clusters.

Tijdslimietbewerkingen voor gezondheidscontrole

De time-out voor de statuscontrole is flexibeler omdat er geen ander failovermechanisme daar direct van afhankelijk is. De standaardwaarde van 30 seconden stelt het sp_server_diagnostics interval in op 10 seconden, met een minimumwaarde voor 15 seconden voor time-out en een interval van 5 seconden. Over het algemeen is het sp_server_diagnostics update-interval altijd 1/3 * HealthCheckTimeout. Wanneer de resource DLL geen nieuwe set statusgegevens binnen een interval ontvangt, worden de statusgegevens van het vorige interval blijven gebruikt om de huidige beschikbaarheidsgroep en de status van het exemplaar te bepalen. Het verhogen van de time-outwaarde voor de statuscontrole maakt de primaire toleranter voor CPU-druk, waardoor nieuwe gegevens niet per interval kunnen sp_server_diagnostics worden verstrekt, maar het is afhankelijk van verouderde gegevensstatuscontroles voor langere tijd. Ongeacht de time-outwaarde, wanneer gegevens zijn ontvangen die aangeven dat de replica niet in orde is, retourneert de volgende IsAlive aanroep dat het exemplaar niet in orde is en de clusterservice een failover start.

Het niveau van de foutvoorwaarden van de AG wijzigt de foutvoorwaarden voor de gezondheidscontrole. Als het AG-element bij elk foutniveau door sp_server_diagnostics als ongezond wordt gerapporteerd, mislukt de statuscontrole. Elk niveau neemt alle foutvoorwaarden over van de niveaus eronder.

Time-outwaarden voor cluster en AlwaysOn bijwerken

Clusterwaarden

Er zijn vier waarden in de WSFC-configuratie die verantwoordelijk zijn voor het bepalen van time-outwaarden voor clusters:

• SameSubnetDelay
• DrempelVoorDezelfdeSubnet
• Koppelingsvertraging tussen subnetten
• Grenswaarde voor Subnetovergang

De vertragingswaarden bepalen de wachttijd tussen de heartbeats van de clusterservice, en de drempelwaarden stellen het aantal heartbeats in dat geen bevestiging ontvangt van het doelknooppunt of de doelresource voordat het object door het cluster als dood wordt beschouwd. Als er gedurende meer dan SameSubnetDelay \* SameSubnetThreshold milliseconden geen geslaagde heartbeat is tussen knooppunten in hetzelfde subnet, wordt het knooppunt als dood beschouwd. Hetzelfde geldt voor communicatie tussen subnetten met behulp van de waarden voor meerdere subnetten.

Als u alle huidige clusterwaarden wilt weergeven, opent u op elk knooppunt in het doelcluster een PowerShell-terminal met verhoogde bevoegdheid. Voer de volgende opdracht uit:

 Get-Cluster | fl *

Als u een van deze waarden wilt bijwerken, voert u de volgende opdracht uit in een PowerShell-terminal met verhoogde bevoegdheid:

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

Wanneer u het product Vertraging * Drempelwaarde verhoogt om de time-out van het cluster toleranter te maken, is het effectiever om eerst de vertragingswaarde te verhogen voordat de drempelwaarde wordt verhoogd. Door de vertraging te verhogen, wordt de tijd tussen elke heartbeat verhoogd. Meer tijd tussen heartbeats geeft meer tijd voor tijdelijke netwerkproblemen om zichzelf op te lossen en netwerkcongestie te verminderen ten opzichte van het verzenden van meer heartbeats in dezelfde periode.

Lease-uitvaltijd

Het leasemechanisme wordt bepaald door één waarde die specifiek is voor elke AG in een WSFC-cluster. Een lease timeout kan leiden tot de volgende fouten:

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'

Als u de time-outwaarde voor de lease wilt wijzigen, gebruik dan de Failover Cluster Manager en voer de volgende stappen uit:

1. Zoek op het tabblad Rollen de gewenste AG-rol. Kies de AG-doelrol.

2. Klik met de rechtermuisknop op de AG-resource onderaan het venster en selecteer Eigenschappen.

   

3. Navigeer in het pop-upvenster naar het tabblad Eigenschappen om een lijst met waarden weer te geven die specifiek zijn voor deze beschikbaarheidsgroep. Selecteer de LeaseTimeout-waarde om deze te wijzigen.

   

   Afhankelijk van de configuratie van de beschikbaarheidsgroep (AG) kunnen er extra bronnen zijn voor listeners, gedeelde schijven, bestandsshares, enzovoort. Deze bronnen vereisen geen aanvullende configuratie.

Gezondheidscontrolewaarden

Twee waarden bepalen de alwayson-statuscontrole: FailureConditionLevel en HealthCheckTimeout. Het FailureConditionLevel geeft het tolerantieniveau aan voor specifieke foutcondities die door sp_server_diagnostics worden gerapporteerd en configureert de HealthCheckTimeout voor de tijd dat de resource-DLL kan doorgaan zonder dat er een update van sp_server_diagnostics wordt ontvangen. Het update-interval voor sp_server_diagnostics is altijd HealthCheckTimeout/3.

Als u het niveau van de failovervoorwaarde wilt configureren, gebruikt u de FAILURE_CONDITION_LEVEL = <n> optie van de CREATE of ALTERAVAILABILITY GROUP instructie, waarbij <n> een geheel getal tussen 1 en 5 is. De volgende opdracht stelt het foutniveau in op 1 voor AG 'AG1':

ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 1);

Als u de time-out van de statuscontrole wilt configureren, gebruikt u de HEALTH_CHECK_TIMEOUT optie van de CREATE of ALTERAVAILABILITY GROUP instructies. Met de volgende opdracht wordt de time-out voor statuscontrole ingesteld op 60.000 milliseconden voor AG AG1:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);

Samenvatting van time-outrichtlijnen

• Het is niet raadzaam om time-outwaarden onder hun standaardwaarden te verlagen.

• Het lease-interval (1/2 * LeaseTimeout) moet korter zijn dan SameSubnetThreshold * SameSubnetDelay

• SameSubnetThreshold <= CrossSubnetThreshold

• SameSubnetDelay <= CrossSubnetDelay

Verwante inhoud

• Actieve secundaire databases: back-up maken op secundaire replica's (AlwaysOn-beschikbaarheidsgroepen)
• ALTER AVAILABILITY GROUP (Transact-SQL)