Delen via

Best practices voor HADR-configuratie (SQL Server op Azure-VM's)

  • Artikel

Van toepassing op:SQL Server op Azure VM-

Een Windows Server Failover Cluster wordt gebruikt voor hoge beschikbaarheid en herstel na noodgevallen (HADR) met SQL Server op Azure Virtual Machines (VM's).

Dit artikel bevat aanbevolen procedures voor clusterconfiguratie voor zowel failoverclusterexemplaren (CFA's) als beschikbaarheidsgroepen wanneer u ze gebruikt met SQL Server op Azure-VM's.

Zie de andere artikelen in deze reeks voor meer informatie: Checklist, VM-grootte, Storage, Security, HADR-configuratie, Basislijn verzamelen.

Controlelijst

Bekijk de volgende controlelijst voor een kort overzicht van de best practices van HADR die in de rest van het artikel in meer detail worden behandeld.

Functies voor hoge beschikbaarheid en herstel na noodgevallen (HADR), zoals de AlwaysOn-beschikbaarheidsgroep en het failoverclusterexemplaren zijn afhankelijk van onderliggende Windows Server-failovercluster technologie. Bekijk de aanbevolen procedures voor het wijzigen van uw HADR-instellingen om de cloudomgeving beter te ondersteunen.

Houd rekening met de volgende aanbevolen procedures voor uw Windows-cluster:

  • Implementeer uw SQL Server-VM's waar mogelijk naar meerdere subnetten om de afhankelijkheid van een Azure Load Balancer of een gedistribueerde netwerknaam (DNN) te voorkomen om verkeer naar uw HADR-oplossing te routeren.
  • Wijzig het cluster in minder agressieve parameters om onverwachte storingen te voorkomen bij tijdelijke netwerkfouten of onderhoud van Het Azure-platform. Zie heartbeat- en drempelwaarde-instellingenvoor meer uitleg. Gebruik voor Windows Server 2012 en hoger de volgende aanbevolen waarden:
    • SameSubnetDelay: 1 seconde
    • SameSubnetThreshold: 40 heartbeats
    • CrossSubnetDelay: 1 seconde
    • CrossSubnetThreshold: 40 hartslagen
  • Plaats uw VM's in een beschikbaarheidsset of verschillende beschikbaarheidszones. Zie vm-beschikbaarheidsinstellingenvoor meer informatie.
  • Gebruik één NIC per clusterknooppunt.
  • Configureer cluster quorumstemming om 3 of meer oneven aantal stemmen te gebruiken. Wijs geen stemmen toe aan DR-regio's.
  • Bewaak resourcelimieten zorgvuldig om onverwachte herstart of failovers te voorkomen vanwege resourcebeperkingen.
    • Zorg ervoor dat uw besturingssysteem, stuurprogramma's en SQL Server de nieuwste builds hebben.
    • Optimaliseer de prestaties voor SQL Server op Azure-VM's. Bekijk de andere secties in dit artikel voor meer informatie.
    • Verminder of verspreid de workload om resourcelimieten te voorkomen.
    • Ga naar een virtuele machine of schijf waarvoor zijn hogere limieten gelden om beperkingen te voorkomen.

Houd rekening met de volgende aanbevolen procedures voor uw SQL Server-beschikbaarheidsgroep of failoverclusterexemplaren:

  • Als u regelmatig onverwachte fouten ondervindt, volgt u de best practices voor prestaties die in de rest van dit artikel worden beschreven.
  • Als het optimaliseren van de prestaties van de SQL Server-VM uw onverwachte failovers niet oplost, kunt u overwegen de bewakings- voor de beschikbaarheidsgroep of het failoverclusterexemplaren te versoepelen. Als u dit doet, kan dit echter niet de onderliggende oorzaak van het probleem oplossen en symptomen maskeren door de kans op fouten te verminderen. Mogelijk moet u de onderliggende hoofdoorzaak nog steeds onderzoeken en aanpakken. Gebruik voor Windows Server 2012 of hoger de volgende aanbevolen waarden:
    • time-out voor lease: gebruik deze vergelijking om de maximale time-outwaarde voor lease te berekenen:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Begin met 40 seconden. Als u de ontspannen SameSubnetThreshold- en SameSubnetDelay-waarden gebruikt die eerder zijn aanbevolen, mag de lease time-out niet langer zijn dan 80 seconden.
    • Maximumfouten in een opgegeven periode: stel deze waarde in op 6.
  • Wanneer u de naam van het virtuele netwerk (VNN) en een Azure Load Balancer gebruikt om verbinding te maken met uw HADR-oplossing, geeft u MultiSubnetFailover = true op in de verbindingsreeks, zelfs als uw cluster slechts één subnet omvat.
    • Als de client geen ondersteuning biedt voor MultiSubnetFailover = True moet u mogelijk RegisterAllProvidersIP = 0 en HostRecordTTL = 300 instellen om clientreferenties voor kortere tijd in de cache op te cachen. Dit kan echter leiden tot extra query's op de DNS-server.
  • Als u verbinding wilt maken met uw HADR-oplossing met behulp van de DNN (Distributed Network Name), kunt u het volgende overwegen:
    • U moet een clientstuurprogramma gebruiken dat ondersteuning biedt voor MultiSubnetFailover = Trueen deze parameter moet in de verbindingsreeks staan.
    • Gebruik een unieke DNN-poort in de verbindingsreeks wanneer u verbinding maakt met de DNN-listener voor een beschikbaarheidsgroep.
  • Gebruik een databasespiegelingsverbindingsreeks voor een eenvoudige beschikbaarheidsgroep om de noodzaak van een load balancer of DNN te omzeilen.
  • Valideer de sectorgrootte van uw VHD's voordat u uw oplossing voor hoge beschikbaarheid implementeert om te voorkomen dat de I/Os verkeerd is uitgelijnd. Zie KB3009974 voor meer informatie.
  • Als de SQL Server-database-engine, Always On-beschikbaarheidsgroeplistener of statustest van het failoverclusterexemplaar zijn geconfigureerd om een poort tussen 49.152 en 65.536 (het standaard dynamische poortbereik voor TCP/IP-) te gebruiken, voeg een uitsluiting voor elke poort toe. Als u dit doet, voorkomt u dat andere systemen dynamisch dezelfde poort worden toegewezen. In het volgende voorbeeld wordt een uitsluiting voor poort 59999 gemaakt:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Als u de HADR-controlelijst wilt vergelijken met de andere best practices, raadpleegt u de uitgebreide controlelijst voor best practices voor prestaties.

Vm-beschikbaarheidsinstellingen

Als u het effect van downtime wilt verminderen, moet u rekening houden met de volgende instellingen voor de beste beschikbaarheid van de VM:

  • Gebruik nabijheidsplaatsingsgroepen samen met versneld netwerken voor de laagste latentie.
  • Plaats clusterknooppunten van virtuele machines in afzonderlijke beschikbaarheidszones om te beschermen tegen storingen op datacenterniveau of in één beschikbaarheidsset voor redundantie met een lagere latentie binnen hetzelfde datacenter.
  • Gebruik premium beheerde besturingssysteem- en gegevensschijven voor VM's in een beschikbaarheidsset.
  • Configureer elke toepassingslaag in afzonderlijke beschikbaarheidssets.

Quorum

Hoewel een cluster met twee knooppunten zonder een quorumresourcekan functioneren, zijn klanten strikt verplicht een quorumresource te gebruiken voor productieondersteuning. Bij clustervalidatie wordt geen cluster zonder quorumresource doorgegeven.

Technisch gezien kan een cluster met drie knooppunten één knooppuntverlies overleven (tot twee knooppunten) zonder quorumresource, maar nadat het cluster is neergezet op twee knooppunten, als er sprake is van een ander knooppuntverlies of communicatiefout, is er een risico dat de geclusterde resources offline gaan om een split-brain-scenario te voorkomen. Als u een quorumresource configureert, kan het cluster online blijven met slechts één knooppunt online.

De schijfwitness is de meest tolerante quorumoptie, maar als u een schijfwitness wilt gebruiken op een SQL Server op azure-VM, moet u een gedeelde Azure-schijf gebruiken, die enkele beperkingen voor de oplossing voor hoge beschikbaarheid met zich meebrengt. Gebruik daarom een schijfwitness wanneer u uw failoverclusterexemplaren configureert met Azure Shared Disks. Gebruik anders waar mogelijk een cloudwitness.

De volgende tabel bevat de quorumopties die beschikbaar zijn voor SQL Server op Azure-VM's:

Cloud witness schijfgetuige bestandssharewitness-
ondersteunde besturingssystemen Windows Server 2016+ Alle Alle
  • De cloudwitness- is ideaal voor implementaties op meerdere sites, meerdere zones en meerdere regio's. Gebruik waar mogelijk een cloudwitness, tenzij u een clusteroplossing voor gedeelde opslag gebruikt.
  • De schijfwitness is de meest tolerante quorumoptie en heeft de voorkeur voor elk cluster dat gebruikmaakt van Azure Shared Disks (of een gedeelde schijfoplossing, zoals gedeelde SCSI-, iSCSI- of fiber channel-SAN). Een geclusterd gedeeld volume kan niet worden gebruikt als schijfgetuige.
  • De deelbestandgetuige is geschikt in situaties waarin de schijfgetuige en cloudgetuige niet beschikbaar zijn.

Zie Clusterquorum configurerenom aan de slag te gaan.

Quorumstemmen

Het is mogelijk om de quorumstem te wijzigen van een knooppunt dat deelneemt aan een Windows Server-failovercluster.

Als u de steminstellingen voor knooppunten wijzigt, volgt u deze richtlijnen:

Richtlijnen voor quorumstemmen
Begin met elk knooppunt dat standaard geen stem heeft. Elk knooppunt mag alleen een stem met expliciete reden hebben.
Schakel stemrechten in voor clusterknooppunten die als host fungeren voor de primaire replica van een beschikbaarheidsgroep, of voor de voorkeurseigenaar van een failoverclusterexemplaar.
Stemmen inschakelen voor eigenaren van automatische failover. Elk knooppunt dat een primaire replica of FCI kan hosten als gevolg van een automatische failover, moet een stem hebben.
Als een beschikbaarheidsgroep meer dan één secundaire replica heeft, schakelt u alleen stemmen in voor de replica's met automatische failover.
Stemmen uitschakelen voor knooppunten die zich op secundaire sites voor herstel na noodgevallen bevinden. Knooppunten in secundaire sites mogen niet bijdragen aan het offline nemen van een cluster als er niets mis is met de primaire site.
Een oneven aantal stemmen hebben, met minimaal drie quorumstemmen. Voeg een quorum witness toe voor een extra stem in een cluster met twee knooppunten, indien nodig.
Stemtoewijzingen na failover opnieuw beoordelen. U wilt geen failover uitvoeren naar een clusterconfiguratie die geen ondersteuning biedt voor een goed functionerend quorum.

Connectiviteit

Implementeer uw SQL Server-VM's in meerdere subnetten binnen hetzelfde virtuele netwerk om de on-premises ervaring te evenaren bij het verbinden met de listener van uw beschikbaarheidsgroep of de instantie van uw failovercluster. Als u meerdere subnetten hebt, hoeft u niet meer afhankelijk te zijn van een Azure Load Balancer of een gedistribueerde netwerknaam om uw verkeer naar uw listener te routeren.

Als u uw HADR-oplossing wilt vereenvoudigen, implementeert u waar mogelijk uw SQL Server-VM's in meerdere subnetten. Zie multi-subnet AGen multi-subnet FCIvoor meer informatie.

Als uw SQL Server-VM's zich in één subnet bevinden, is het mogelijk om een naam van een virtueel netwerk (VNN) en een Azure Load Balancer of een gedistribueerde netwerknaam (DNN) te configureren voor zowel failoverclusterexemplaren als listeners voor beschikbaarheidsgroepen.

De gedistribueerde netwerknaam is de aanbevolen verbindingsoptie, indien beschikbaar:

  • De end-to-end-oplossing is robuuster omdat u de load balancer-resource niet meer hoeft te onderhouden.
  • Het elimineren van de load balancer-probes verkort de duur van de failover.
  • De DNN vereenvoudigt het inrichten en beheren van het failoverclusterexemplaar en de listener voor beschikbaarheidsgroepen met SQL Server op VM's op Azure.

Houd rekening met de volgende beperkingen:

Voor meer informatie, zie het overzicht van de Windows Server-failovercluster .

Raadpleeg de volgende artikelen om connectiviteit te configureren:

  • Beschikbaarheidsgroep: DNN-configureren, VNN- configureren
  • Failoverclusterexemplaren: DNN-configureren, VNN-configureren.

De meeste SQL Server-functies werken transparant met FCI- en beschikbaarheidsgroepen bij het gebruik van de DNN, maar er zijn bepaalde functies die mogelijk speciale overwegingen vereisen. Zie FCI- en DNN-interoperabiliteit en AG- en DNN-interoperabiliteit voor meer informatie.

Fooi

Stel de parameter MultiSubnetFailover = true in de verbindingsreeks in, zelfs voor HADR-oplossingen die één subnet omvatten om toekomstige spanning van subnetten te ondersteunen zonder verbindingsreeksen bij te werken.

Hartslag en drempelwaarde

Wijzig de heartbeat- en drempelwaarde-instellingen van het cluster naar minder strikte instellingen. De standaardinstellingen voor heartbeat- en drempelwaardeclusters zijn ontworpen voor sterk afgestemde on-premises netwerken en overwegen geen verhoogde latentie in een cloudomgeving. Het heartbeat-netwerk wordt onderhouden met UDP 3343, dat traditioneel veel minder betrouwbaar is dan TCP en gevoeliger is voor onvolledige gesprekken.

Wijzig daarom bij het uitvoeren van clusterknooppunten voor SQL Server op Azure VM-oplossingen voor hoge beschikbaarheid de clusterinstellingen in een meer ontspannen bewakingsstatus om tijdelijke fouten te voorkomen vanwege de verhoogde mogelijkheid van netwerklatentie of -storing, Azure-onderhoud of het raken van knelpunten in resources.

De instellingen voor vertraging en drempelwaarden hebben een cumulatief effect op de totale gezondheidsdetectie. Als u bijvoorbeeld CrossSubnetDelay instelt om elke 2 seconden een heartbeat te verzenden en de CrossSubnetThreshold- op 10 gemiste heartbeats in te stellen voordat het herstel wordt uitgevoerd, betekent dit dat het cluster een totale netwerktolerantie van 20 seconden kan hebben voordat de herstelactie wordt uitgevoerd. Over het algemeen verdient het de voorkeur om frequente hartslagen te blijven verzenden, maar hogere drempelwaarden worden geprefereerd.

Om te zorgen voor herstel tijdens legitieme storingen terwijl u meer tolerantie biedt voor tijdelijke problemen, versoepelt u de vertragings- en drempelwaarde-instellingen tot de aanbevolen waarden die in de volgende tabel worden beschreven:

Instelling Windows Server 2012 of hoger Windows Server 2008 R2
SameSubnetDelay 1 seconde 2 seconde
SameSubnetThreshold 40 hartslagen 10 hartslagen (max)
CrossSubnetDelay 1 seconde 2 seconde
Grenswaarde voor Subnetovergang 40 hartslagen 20 hartslagen (maximaal)

Gebruik PowerShell om de clusterparameters te wijzigen:

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

Gebruik PowerShell om uw wijzigingen te controleren:

get-cluster | fl *subnet*

Houd rekening met het volgende:

  • Deze wijziging is onmiddellijk; het opnieuw opstarten van het cluster of van resources is niet vereist.
  • Subnetwaarden binnen hetzelfde subnet mogen niet groter zijn dan waarden tussen verschillende subnetten.
  • SameSubnetThreshold <= CrossSubnetThreshold
  • SameSubnetDelay <= CrossSubnetDelay

Kies ontspannen waarden op basis van hoeveel rusttijd acceptabel is en hoe lang voordat een corrigerende actie moet plaatsvinden, afhankelijk van uw toepassing, bedrijfsbehoeften en uw omgeving. Als u de standaardwaarden voor Windows Server 2019 niet kunt overschrijden, probeer ze dan ten minste te evenaren, indien mogelijk.

Ter referentie bevat de volgende tabel de standaardwaarden:

Instelling Windows Server 2019 Windows Server 2016 Windows Server 2008 - 2012 R2
SameSubnetDelay 1 seconde 1 seconde 1 seconde
SameSubnetThreshold 20 hartslagen 10 hartslagen 5 hartslagen
CrossSubnetDelay 1 seconde 1 seconde 1 seconde
CrossSubnetThreshold 20 hartslagen 10 hartslagen 5 hartslagen

Zie Drempelwaarden voor failoverclusternetwerk afstemmenvoor meer informatie.

Minder strikte bewaking

Als het afstemmen van de heartbeat- en drempelwaarde-instellingen van uw cluster zoals aanbevolen onvoldoende tolerantie biedt en u nog steeds failovers ziet vanwege tijdelijke problemen in plaats van echte storingen, kunt u de bewaking van uw AG of FCI zo configureren dat deze minder streng is. In sommige scenario's kan het nuttig zijn om de bewaking tijdelijk te ontspannen op basis van het activiteitsniveau. U kunt bijvoorbeeld de bewaking versoepelen wanneer u I/O-intensieve workloads uitvoert, zoals databaseback-ups, indexonderhoud, DBCC CHECKDB, enzovoort. Zodra de activiteit is voltooid, stelt u uw bewaking in op minder ontspannen waarden.

Waarschuwing

Het wijzigen van deze instellingen kan een onderliggend probleem maskeren en moet worden gebruikt als tijdelijke oplossing om de kans op fouten te verminderen, in plaats van te elimineren. Onderliggende problemen moeten nog steeds worden onderzocht en opgelost.

Begin met het verhogen van de volgende parameters op basis van hun standaardwaarden voor ontspannen bewaking en pas deze indien nodig aan:

Parameter Standaardwaarde Ontspannen waarde Beschrijving
time-out voor gezondheidscontrole 30000 60000 Bepaalt de status van de primaire replica of knooppunt. Het DLL-bestand met clusterresources sp_server_diagnostics retourneert resultaten met een interval dat gelijk is aan 1/3 van de time-outdrempel voor statuscontrole. Als sp_server_diagnostics traag is of geen informatie retourneert, wacht de bron-DLL op het volledige interval van de time-outdrempel voor statuscontrole voordat wordt vastgesteld dat de resource niet reageert en voordat een automatische failover wordt geïnitieerd, als dit zo is ingesteld.
Failure-Condition Niveau 3 2 Voorwaarden die een automatische failover activeren. Er zijn vijf niveaus van foutvoorwaarden, die variëren van de minst beperkende (niveau één) tot de meest beperkende (niveau vijf)

Gebruik Transact-SQL (T-SQL) om de statuscontrole en foutvoorwaarden voor zowel AG's als FCI's te wijzigen.

Voor beschikbaarheidsgroepen:

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

Voor failoverclusterexemplaren:

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

Specifiek voor beschikbaarheidsgroepen, begin met de volgende aanbevolen parameters en pas deze indien nodig aan:

Parameter Standaardwaarde Flexibele waarde Beschrijving
time-out voor lease 20000 40000 Voorkomt een "split-brain" situatie.
Sessie-time-out 10.000 20000 Controleert communicatieproblemen tussen replica's. De sessietime-outperiode is een eigenschap van een replica die bepaalt hoe lang (in seconden) een beschikbaarheidsreplica wacht op een ping-reactie van een verbonden replica voordat wordt aangenomen dat de verbinding is mislukt. Standaard wacht een replica 10 seconden op een ping-antwoord. Deze replica-eigenschap is alleen van toepassing op de verbinding tussen een bepaalde secundaire replica en de primaire replica van de beschikbaarheidsgroep.
Maximum aantal fouten in de opgegeven periode 2 6 Wordt gebruikt om onbepaalde verplaatsing van een geclusterde resource binnen meerdere knooppuntfouten te voorkomen. Een te lage waarde kan ertoe leiden dat de beschikbaarheidsgroep op Mislukt staat. Verhoog de waarde om korte onderbrekingen te voorkomen die door prestatieproblemen worden veroorzaakt, omdat een te lage waarde kan leiden tot de beschikbaarheidsgroep in een mislukte staat.

Voordat u wijzigingen aanbrengt, moet u rekening houden met het volgende:

  • Verlaag geen time-outwaarden onder de standaardwaarden.
  • Gebruik deze vergelijking om de maximale lease time-out waarde te berekenen: Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
    Begin met 40 seconden. Als u de ontspannen SameSubnetThreshold- en SameSubnetDelay-waarden gebruikt die eerder zijn aanbevolen, mag u de lease-time-outwaarde niet overschrijden van 80 seconden.
  • Voor synchronous-commit replica's kan het wijzigen van de sessie-time-out naar een hoge waarde de HADR_sync_commit wachttijden verhogen.

time-out van de lease

Gebruik de Failoverclusterbeheer om de instellingen voor de leasesessie-time-out van uw beschikbaarheidsgroep te wijzigen. Zie de documentatie voor de leasegezondheidstest van de beschikbaarheidsgroep van SQL Server voor gedetailleerde stappen.

time-out voor sessie

Gebruik Transact-SQL (T-SQL) om de time-out van de sessie te wijzigen voor een beschikbaarheidsgroep:

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

Maximum aantal fouten in de opgegeven periode

Gebruik Failoverclusterbeheer om de maximumfouten in de opgegeven periode te wijzigen waarde:

  1. Selecteer Rollen in het navigatiedeelvenster.
  2. Klik onder Rollenmet de rechtermuisknop op de geclusterde resource en kies Eigenschappen.
  3. Selecteer het tabblad Failover en verhoog de waarde van Maximale fouten in de opgegeven periode naar wens.

Resourcelimieten

VM- of schijflimieten kunnen leiden tot een knelpunt in een resource die van invloed is op de status van het cluster en de statuscontrole belemmert. Als u problemen ondervindt met resourcelimieten, kunt u het volgende overwegen:

  • Gebruik I/O-analyse (preview) in Azure Portal om problemen met schijfprestaties te identificeren die een failover kunnen veroorzaken.
  • Zorg ervoor dat uw besturingssysteem, stuurprogramma's en SQL Server de nieuwste builds hebben.
  • SQL Server optimaliseren in een Azure VM-omgeving, zoals beschreven in de prestatierichtlijnen voor SQL Server op Azure Virtual Machines
  • Gebruik
  • De workload verminderen of verspreiden om het gebruik te verminderen zonder resourcelimieten te overschrijden
  • De SQL Server-workload optimaliseren wanneer er mogelijkheden zijn, zoals
    • Indexen toevoegen/optimaliseren
    • Statistieken bijwerken indien nodig en indien mogelijk, met volledige scan
    • Gebruik functies zoals resource governor (te beginnen met SQL Server 2014, alleen onderneming) om het resourcegebruik te beperken tijdens specifieke workloads, zoals back-ups of indexonderhoud.
  • Ga naar een VIRTUELE machine of schijf met hogere limieten om te voldoen aan de vereisten van uw workload of deze te overschrijden.

Netwerken

Implementeer uw SQL Server-VM's waar mogelijk naar meerdere subnetten om de afhankelijkheid van een Azure Load Balancer of een gedistribueerde netwerknaam (DNN) te voorkomen om verkeer naar uw HADR-oplossing te routeren.

Gebruik één NIC per server (clusterknooppunt). Azure-netwerken hebben fysieke redundantie, waardoor extra NIC's onnodig zijn op een gastcluster van een virtuele Azure-machine. Het clustervalidatierapport waarschuwt u dat de knooppunten alleen bereikbaar zijn in één netwerk. U kunt deze waarschuwing negeren op gastfailoverclusters van virtuele Azure-machines.

Bandbreedtelimieten voor een bepaalde VM worden gedeeld tussen NIC's en het toevoegen van een extra NIC verbetert de prestaties van de beschikbaarheidsgroep voor SQL Server op Virtuele Azure-machines niet. Daarom hoeft u geen tweede NIC toe te voegen.

De niet-RFC-compatibele DHCP-service in Azure kan ertoe leiden dat bepaalde failoverclusterconfiguraties mislukken. Deze fout treedt op omdat aan de clusternetwerknaam een dubbel IP-adres is toegewezen, zoals hetzelfde IP-adres als een van de clusterknooppunten. Dit is een probleem wanneer u beschikbaarheidsgroepen gebruikt, die afhankelijk zijn van de functie Windows-failovercluster.

Houd rekening met het scenario wanneer een cluster met twee knooppunten wordt gemaakt en online wordt gebracht:

  1. Het cluster is online en vervolgens vraagt NODE1 een dynamisch toegewezen IP-adres aan voor de naam van het clusternetwerk.
  2. De DHCP-service geeft geen ander IP-adres dan het eigen IP-adres van NODE1, omdat de DHCP-service herkent dat de aanvraag afkomstig is van NODE1 zelf.
  3. Windows detecteert dat een dubbel adres is toegewezen aan NODE1 en aan de netwerknaam van het failovercluster en dat de standaardclustergroep niet online komt.
  4. De standaardclustergroep wordt verplaatst naar NODE2. NODE2 behandelt het IP-adres van NODE1 als het IP-adres van het cluster en brengt de standaardclustergroep online.
  5. Wanneer NODE2 verbinding probeert te maken met NODE1, verlaten pakketten die zijn gericht op NODE1 node2 nooit omdat het IP-adres van NODE1 naar zichzelf wordt omgezet. NODE2 kan geen verbinding maken met NODE1 en verliest vervolgens quorum en sluit het cluster af.
  6. NODE1 kan pakketten verzenden naar NODE2, maar NODE2 kan niet reageren. NODE1 verliest quorum en sluit het cluster af.

U kunt dit scenario vermijden door een ongebruikt statisch IP-adres toe te wijzen aan de naam van het clusternetwerk om de naam van het clusternetwerk online te brengen en het IP-adres toe te voegen aan Azure Load Balancer-.

Als de SQL Server-database-engine, AlwaysOn-listener voor beschikbaarheidsgroepen, statustest voor failoverclusterexemplaren, eindpunt voor databasespiegeling, clusterkern-IP-resource of een andere SQL-resource is geconfigureerd voor het gebruik van een poort tussen 49.152 en 65.536 (het standaard dynamische poortbereik voor TCP/IP-), voegt u een uitsluiting toe voor elke poort. Als u dit doet, voorkomt u dat andere systeemprocessen dynamisch dezelfde poort worden toegewezen. In het volgende voorbeeld wordt een uitsluiting voor poort 59999 gemaakt:

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

Het is belangrijk om de poortuitsluiting te configureren wanneer de poort niet in gebruik is, anders mislukt de opdracht met een bericht als 'Het proces heeft geen toegang tot het bestand omdat het wordt gebruikt door een ander proces'.

Gebruik de volgende opdracht om te bevestigen dat de uitsluitingen correct zijn geconfigureerd: netsh int ipv4 show excludedportrange tcp.

Door deze uitsluiting in te stellen voor de IP-testpoort van de beschikbaarheidsgroep rol, zouden gebeurtenissen zoals gebeurtenis-id: 1069 met status 10048 moeten worden voorkomen. Deze gebeurtenis kan worden weergegeven in de Windows Failover-cluster gebeurtenissen met het volgende bericht:

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.

Dit kan worden veroorzaakt door een intern proces waarbij dezelfde poort wordt gebruikt die is gedefinieerd als de testpoort. Houd er rekening mee dat de probe-poort wordt gebruikt om de status van een back-endpoolexemplaar van de Azure Load Balancer te controleren.
Als de statustest er niet in slaagt om een antwoord te ontvangen van een back-endexemplaar, worden er geen nieuwe verbindingen naar dat back-endexemplaar verzonden totdat de statustest opnieuw is geslaagd.

Bekende problemen

Bekijk de oplossingen voor enkele veelvoorkomende problemen en fouten.

Resourceconflicten (IO in het bijzonder) veroorzaken failover

Een uitputting van de I/O- of CPU-capaciteit voor de VIRTUELE machine kan ertoe leiden dat uw beschikbaarheidsgroep een failover-overschakeling uitvoert. Het identificeren van de conflicten die zich direct vóór de failover voordoet, is de meest betrouwbare manier om te bepalen wat automatische failover veroorzaakt.

I/O-analyse gebruiken

Gebruik I/O-analyse (preview) in Azure Portal om problemen met schijfprestaties te identificeren die een failover kunnen veroorzaken.

Bewaken met io-metrische gegevens voor VM-opslag

Virtuele Azure-machines bewaken om de metrische gegevens van het io-gebruik van storage te bekijken om inzicht te hebben in de latentie van VM's of schijven.

Volg deze stappen om de Azure-VM algemene IO-uitputtingsgebeurtenis te bekijken:

  1. Navigeer naar uw virtuele machine in de Azure-portal, niet de SQL-virtuele machines.

  2. Selecteer metrische gegevens onder Bewaking om de pagina metrische gegevens te openen.

  3. Selecteer lokale tijd om het tijdsbereik op te geven waarin u geïnteresseerd bent, en de tijdzone, lokaal naar de virtuele machine of UTC/GMT.

    Schermopname van de pagina met metrische gegevens in de Azure-portal, waarbij het tijdsbestek van de grafiek wordt gewijzigd.

  4. Selecteer Voeg metriek toe om de volgende twee metrieken toe te voegen om de grafiek te zien:

    • verbruikt percentage verbruikte bandbreedte in de cache
    • Ongecacheerde bandbreedte verbruikt percentage VM

schermopname van de pagina Metrische gegevens in Azure Portal.

Azure VM HostEvents veroorzaakt failover

Het is mogelijk dat een Azure VM HostEvent ervoor zorgt dat uw beschikbaarheidsgroep een failover uitvoert. Als u denkt dat een Azure VM HostEvent een failover heeft veroorzaakt, kunt u het Azure Monitor-activiteitenlogboek en het overzicht van Azure VM Resource Health controleren.

Het Azure Monitor-activiteitenlogboek is een platformlogboek in Azure, dat inzicht biedt in gebeurtenissen op abonnementsniveau. Het activiteitenlogboek bevat informatie zoals wanneer een resource wordt gewijzigd of een virtuele machine wordt gestart. U kunt het activiteitenlogboek bekijken in Azure Portal of vermeldingen ophalen met PowerShell en de Azure CLI.

Voer de volgende stappen uit om het Activiteitenlogboek van Azure Monitor te controleren:

  1. Navigeer naar uw virtuele machine in Azure Portal

  2. Selecteer Activiteitenlogboek in het deelvenster Virtuele Machine

  3. Selecteer periode en kies vervolgens het tijdsbestek wanneer uw beschikbaarheidsgroep een failover heeft uitgevoerd. Selecteer entoepassen.

    schermopname van Azure Portal, waarin het activiteitenlogboek wordt weergegeven.

Als Azure meer informatie heeft over de hoofdoorzaak van een door het platform geïnitieerde onbeschikbaarheid, kan deze informatie worden gepost op de Azure VM - Resource Health-overzicht pagina tot 72 uur na de eerste onbeschikbaarheid. Deze informatie is momenteel alleen beschikbaar voor virtuele machines.

  1. Navigeer naar uw virtuele machine in Azure Portal
  2. Selecteer Resource Health in het venster Health.

nl-NL: schermopname van de pagina Resource Health in Azure portal.

U kunt op deze pagina ook waarschuwingen configureren op basis van gezondheidsevenementen.

Clusterknooppunt verwijderd uit lidmaatschap

Als de Windows Cluster heartbeat- en drempelwaarde-instellingen te agressief zijn voor uw omgeving, kunt u het volgende bericht regelmatig in het gebeurtenislogboek van het systeem zien.

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.

Raadpleeg Clusterprobleem oplossen met gebeurtenis-id 1135voor meer informatie.

Lease is verlopen/ Lease is niet meer geldig

Als monitoring te agressief is voor uw omgeving, kunt u mogelijk frequente herstarten van de beschikbaarheidsgroep of FCI's, storingen of failovers zien. Voor beschikbaarheidsgroepen ziet u mogelijk de volgende berichten in het foutenlogboek van 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.

Verbindingstijdoverschrijding

Als de time-out van de sessie te agressief is voor de omgeving van uw beschikbaarheidsgroep, ziet u mogelijk de volgende berichten vaak:

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.

Een failover van de groep wordt niet uitgevoerd

Als de waarde voor het maximum aantal fouten in de opgegeven periode te laag is en u onregelmatige fouten ondervindt vanwege tijdelijke problemen, kan uw beschikbaarheidsgroep in een mislukte staat terechtkomen. Verhoog deze waarde om tijdelijke fouten te tolereren.

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

Gebeurtenis 1196 - Registratie van gekoppelde DNS-naam is mislukt voor netwerknaamresource

  • Controleer de NIC-instellingen voor elk van uw clusterknooppunten om ervoor te zorgen dat er geen externe DNS-records aanwezig zijn
  • Zorg ervoor dat de A-record voor uw cluster bestaat op uw interne DNS-servers. Als dat niet het geval is, maak dan handmatig een nieuwe A-record in de DNS Server voor het clustertoegangsbeheerobject en vink de optie aan om geverifieerde gebruikers toe te staan DNS-records bij te werken met dezelfde eigenaarnaam.
  • Neem de resource 'Clusternaam' samen met de IP-resource offline en herstel deze.

Gebeurtenis 157 - Schijf is onverwacht verwijderd.

Dit kan gebeuren als de eigenschap Opslagruimten AutomaticClusteringEnabled is ingesteld op True voor een AG-omgeving. Wijzig deze in False. Als u een validatierapport met de opslagoptie uitvoert, kan ook de gebeurtenis voor het opnieuw instellen van de schijf of het onverwacht verwijderen van de schijf worden geactiveerd. Het opslagsysteem dosering kan ook de gebeurtenis van de onverwachte verwijdering van de schijf activeren.

Gebeurtenis 1206 - Resource voor clusternetwerknamen kan niet online worden gebracht.

Het computerobject dat aan de resource is gekoppeld, kan niet worden bijgewerkt in het domein. Zorg ervoor dat u over juiste machtigingen beschikt voor het domein

Windows Clustering-fouten

Er kunnen problemen optreden bij het instellen van een Windows-failovercluster of de bijbehorende connectiviteit als u geen Cluster Service-poorten hebt geopend voor communicatie.

Als u Windows Server 2019 gebruikt en u geen IP-adres van een Windows-cluster ziet, hebt u gedistribueerde netwerknaam geconfigureerd. Dit wordt alleen ondersteund op SQL Server 2019. Als u eerdere versies van SQL Server hebt, kunt u het cluster verwijderen en opnieuw maken met behulp van netwerknaam.

Bekijk hier andere fouten met Windows Failover Clustering Events en de bijbehorende oplossingen

Volgende stappen

Zie voor meer informatie: