Windows Server-failovercluster met SQL Server op Azure-VM's

Van toepassing op: SQL Server op Azure VM

In dit artikel worden de verschillen beschreven bij het gebruik van de functie Windows Server-failovercluster met SQL Server op Azure-VM's voor hoge beschikbaarheid en herstel na noodgevallen (HADR), zoals voor AlwaysOn-beschikbaarheidsgroepen (AG) of failoverclusterexemplaren (FCI).

Zie de documentatie van het Windows-failovercluster voor meer informatie over de Windows-functie zelf.

Overzicht

Oplossingen voor hoge beschikbaarheid van SQL Server in Windows, zoals AlwaysOn-beschikbaarheidsgroepen (AG) of exemplaren van failoverclusters (FCI), zijn afhankelijk van de onderliggende WSFC-service (Windows Server Failover Clustering).

De clusterservice bewaakt netwerkverbindingen en de status van knooppunten in het cluster. Deze bewaking is naast de statuscontroles die SQL Server uitvoert als onderdeel van de functie beschikbaarheidsgroep of failoverclusterexemplaren. Als de clusterservice het knooppunt niet kan bereiken of als de rol AG of FCI in het cluster beschadigd raakt, start de clusterservice de juiste herstelacties om toepassingen en services online te herstellen en online te brengen, op hetzelfde of op een ander knooppunt in het cluster.

Clusterstatuscontrole

Als u hoge beschikbaarheid wilt bieden, moet het cluster de status van de verschillende onderdelen garanderen waaruit de geclusterde oplossing bestaat. De clusterservice bewaakt de status van het cluster op basis van een aantal systeem- en netwerkparameters om fouten te detecteren en erop te reageren.

Het instellen van de drempelwaarde voor het declareren van een fout is belangrijk om een evenwicht te bereiken tussen het snel reageren op een fout en het voorkomen van valse fouten.

Er zijn twee strategieën voor bewaking:

Controle	Omschrijving
Agressieve	Biedt snelle foutdetectie en herstel van harde storingen, wat de hoogste beschikbaarheidsniveaus biedt. De clusterservice en SQL Server zijn beide minder vergevend van tijdelijke fouten en in sommige gevallen kunnen er voortijdig failover-overschakelingsbronnen worden uitgevoerd wanneer er tijdelijke storingen zijn. Zodra de fout is gedetecteerd, kan het extra tijd duren voordat de volgende corrigerende actie wordt uitgevoerd.
Ontspannen	Biedt meer vergevingsloze foutdetectie met een grotere tolerantie voor korte tijdelijke netwerkproblemen. Vermijd tijdelijke fouten, maar introduceert ook het risico dat de detectie van een echte fout wordt vertraagd.

Agressieve instellingen in een clusteromgeving in de cloud kunnen leiden tot voortijdige storingen en langere storingen. Daarom wordt een ontspannen bewakingsstrategie aanbevolen voor failoverclusters op Azure-VM's. Zie aanbevolen procedures voor clusters voor meer informatie om de drempelwaarden aan te passen.

Cluster-heartbeat

De primaire instellingen die van invloed zijn op het kloppen van clusterharten en statusdetectie tussen knooppunten:

Instelling	Omschrijving
Vertraging	Hiermee definieert u de frequentie waarmee cluster-heartbeats tussen knooppunten worden verzonden. De vertraging is het aantal seconden voordat de volgende heartbeat wordt verzonden. Binnen hetzelfde cluster kunnen er verschillende vertragingsinstellingen zijn geconfigureerd tussen knooppunten in hetzelfde subnet en tussen knooppunten in verschillende subnetten.
Drempel	De drempelwaarde is het aantal heartbeats dat kan worden gemist voordat het cluster herstelacties onderneemt. Binnen hetzelfde cluster kunnen er verschillende drempelwaarde-instellingen zijn geconfigureerd tussen knooppunten in hetzelfde subnet en tussen knooppunten die zich in verschillende subnetten bevinden.

De standaardwaarden voor deze instellingen zijn mogelijk te laag voor cloudomgevingen en kunnen leiden tot onnodige fouten vanwege tijdelijke netwerkproblemen. Als u toleranter wilt zijn, gebruikt u ontspannen drempelwaarde-instellingen voor failoverclusters in Azure-VM's. Zie aanbevolen procedures voor clusters voor meer informatie.

Quorum

Hoewel een cluster met twee knooppunten werkt zonder quorumresource, moeten klanten strikt een quorumresource gebruiken om productieondersteuning te bieden. Bij clustervalidatie wordt geen cluster zonder quorumresource doorgegeven.

Technisch gezien kan een cluster met drie knooppunten één knooppuntverlies (tot twee knooppunten) overleven zonder quorumresource. Maar nadat het cluster tot twee knooppunten is uitgevallen, bestaat het risico dat de geclusterde resources offline gaan om een split-brain-scenario te voorkomen als een knooppunt verloren gaat of er een communicatiefout is tussen de knooppunten. Als u een quorumresource configureert, kunnen de clusterresources 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 oplegt. 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:

	Cloudwitness	Schijfwitness	Bestandssharewitness
Ondersteund besturingssysteem	Windows Server 2016+	Alle	Alle
Beschrijving	Een cloudwitness is een type failoverclusterquorumwitness die gebruikmaakt van Microsoft Azure om een stem te geven over het clusterquorum. De standaardgrootte is ongeveer 1 MB en bevat alleen het tijdstempel. Een cloudwitness is ideaal voor implementaties op meerdere sites, meerdere zones en meerdere regio's. Gebruik waar mogelijk een cloudwitness, tenzij u een failoverclusteroplossing met gedeelde opslag hebt.	Een schijfwitness is een kleine geclusterde schijf in de cluster beschikbare opslaggroep. Deze schijf is maximaal beschikbaar en kan een failover uitvoeren tussen knooppunten. Het bevat een kopie van de clusterdatabase, met een standaardgrootte van minder dan 1 GB. De schijfwitness is de voorkeursquorumoptie voor elk cluster dat gebruikmaakt van Azure Shared Disks (of een oplossing voor gedeelde schijven, zoals gedeelde SCSI, iSCSI of Fibre Channel SAN). Een geclusterd gedeeld volume kan niet worden gebruikt als schijfwitness. Configureer een gedeelde Azure-schijf als schijfwitness.	Een bestandssharewitness is een SMB-bestandsshare die doorgaans is geconfigureerd op een bestandsserver met Windows Server. Het onderhoudt clustering-informatie in een witness.log-bestand, maar slaat geen kopie van de clusterdatabase op. In Azure kunt u een bestandsshare configureren op een afzonderlijke virtuele machine binnen hetzelfde virtuele netwerk. Gebruik een bestandssharewitness als een schijfwitness of cloudwitness niet beschikbaar is in uw omgeving.

Zie Clusterquorum configureren om aan de slag te gaan.

Naam van virtueel netwerk (VNN)

Implementeer uw SQL Server-VM's in meerdere subnetten binnen hetzelfde virtuele netwerk om verbinding te maken met de listener van uw beschikbaarheidsgroep of failoverclusterexemplaren, zodat deze overeenkomen met de on-premises ervaring voor het maken van verbinding met de listener van uw beschikbaarheidsgroep of failoverclusterexemplaren. Als u meerdere subnetten hebt, hoeft u geen extra afhankelijkheid te hebben van een Azure Load Balancer om verkeer naar uw HADR-oplossing te routeren. Zie Multi-subnet AG en Multi-subnet FCI voor meer informatie.

In een traditionele on-premises omgeving zijn geclusterde resources, zoals failoverclusterexemplaren of AlwaysOn-beschikbaarheidsgroepen, afhankelijk van de naam van het virtuele netwerk om verkeer naar het juiste doel te routeren: het failoverclusterexemplaren of de listener van de AlwaysOn-beschikbaarheidsgroep. De virtuele naam verbindt het IP-adres in DNS en clients kunnen de virtuele naam of het IP-adres gebruiken om verbinding te maken met hun doel voor hoge beschikbaarheid, ongeacht welk knooppunt momenteel eigenaar is van de resource. De VNN is een netwerknaam en -adres die worden beheerd door het cluster en de clusterservice verplaatst het netwerkadres van knooppunt naar knooppunt tijdens een failover-gebeurtenis. Tijdens een fout wordt het adres offline gehaald op de oorspronkelijke primaire replica en online gebracht op de nieuwe primaire replica.

Op virtuele Azure-machines in één subnet is een extra onderdeel nodig om verkeer van de client te routeren naar de naam van het virtuele netwerk van de geclusterde resource (failoverclusterexemplaren of de listener van een beschikbaarheidsgroep). In Azure bevat een load balancer het IP-adres voor de VNN waarop de geclusterde SQL Server-resources afhankelijk zijn en die nodig is om verkeer te routeren naar het juiste doel voor hoge beschikbaarheid. De load balancer detecteert ook fouten met de netwerkonderdelen en verplaatst het adres naar een nieuwe host.

De load balancer distribueert binnenkomende stromen die binnenkomen bij de front-end en stuurt dat verkeer vervolgens door naar de exemplaren die zijn gedefinieerd door de back-endpool. U configureert de verkeersstroom met behulp van taakverdelingsregels en statustests. Met SQL Server FCI zijn de exemplaren van de back-endpool de virtuele Machines van Azure waarop SQL Server wordt uitgevoerd en met beschikbaarheidsgroepen is de back-endpool de listener. Er is een lichte failoververtraging wanneer u de load balancer gebruikt, omdat de statustest standaard elke 10 seconden actief controleert.

Leer hoe u Azure Load Balancer configureert voor een exemplaar van een failovercluster of een beschikbaarheidsgroep om aan de slag te gaan.

Ondersteund besturingssysteem: alle
Ondersteunde SQL-versie: alle
Ondersteunde HADR-oplossing: failoverclusterexemplaren en beschikbaarheidsgroep

Configuratie van de VNN kan lastig zijn, het is een extra bron van fouten, het kan leiden tot een vertraging in de detectie van fouten en er is een overhead en kosten verbonden aan het beheren van de extra resource. Om een aantal van deze beperkingen aan te pakken, heeft SQL Server ondersteuning geïntroduceerd voor de functie Gedistribueerde netwerknaam.

Gedistribueerde netwerknaam (DNN)

Implementeer uw SQL Server-VM's in meerdere subnetten binnen hetzelfde virtuele netwerk om verbinding te maken met de listener van uw beschikbaarheidsgroep of failoverclusterexemplaren, zodat deze overeenkomen met de on-premises ervaring voor het maken van verbinding met de listener van uw beschikbaarheidsgroep of failoverclusterexemplaren. Als u meerdere subnetten hebt, hoeft u geen extra afhankelijkheid te hebben van een DNN om verkeer naar uw HADR-oplossing te routeren. Zie Multi-subnet AG en Multi-subnet FCI voor meer informatie.

Voor SQL Server-VM's die zijn geïmplementeerd in één subnet, biedt de functie gedistribueerde netwerknaam een alternatieve manier voor SQL Server-clients om verbinding te maken met het exemplaar van het SQL Server-failovercluster of de listener voor beschikbaarheidsgroepen zonder een load balancer te gebruiken. De DNN-functie is beschikbaar vanaf SQL Server 2016 SP3, SQL Server 2017 CU25, SQL Server 2019 CU8, op Windows Server 2016 en hoger.

Wanneer een DNN-resource wordt gemaakt, verbindt het cluster de DNS-naam met de IP-adressen van alle knooppunten in het cluster. De client probeert verbinding te maken met elk IP-adres in deze lijst om te vinden met welke resource verbinding moet worden gemaakt. U kunt dit proces versnellen door op te MultiSubnetFailover=True geven in de verbindingsreeks. Met deze instelling moet de provider alle IP-adressen parallel proberen, zodat de client direct verbinding kan maken met de FCI of listener.

Indien mogelijk wordt een gedistribueerde netwerknaam aanbevolen via een load balancer, omdat:

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

De meeste SQL Server-functies werken transparant met FCI en beschikbaarheidsgroepen bij het gebruik van de DNN, maar er zijn bepaalde functies waarvoor mogelijk speciale overwegingen nodig zijn.

Ondersteund besturingssysteem: Windows Server 2016 en hoger
Ondersteunde SQL-versie: SQL Server 2019 CU2 (FCI) en SQL Server 2019 CU8 (AG)
Ondersteunde HADR-oplossing: failoverclusterexemplaren en beschikbaarheidsgroep

Om aan de slag te gaan, leert u hoe u een gedistribueerde netwerknaamresource configureert voor een exemplaar van een failovercluster of een beschikbaarheidsgroep.

Er zijn aanvullende overwegingen bij het gebruik van de DNN met andere SQL Server-functies. Zie FCI- en DNN-interoperabiliteit en AG- en DNN-interoperabiliteit voor meer informatie.

Herstelacties

De clusterservice neemt corrigerende actie wanneer er een fout wordt gedetecteerd. Hierdoor kan de resource op het bestaande knooppunt opnieuw worden opgestart of een failover van de resource naar een ander knooppunt worden uitgevoerd. Zodra corrigerende maatregelen zijn gestart, duurt het enige tijd om te voltooien.

Een opnieuw gestarte beschikbaarheidsgroep komt bijvoorbeeld online volgens de volgende volgorde:

1. Listener IP komt online
2. De naam van het listenernetwerk is online
3. Beschikbaarheidsgroep is online
4. Afzonderlijke databases doorlopen het herstel, wat enige tijd kan duren, afhankelijk van een aantal factoren, zoals de lengte van het opnieuw logboek. Verbindingen worden slechts door de listener gerouteerd zodra de database volledig is hersteld. Zie RTO (Failover-tijd schatten) voor meer informatie.

Omdat herstel enige tijd kan duren, kan een agressieve bewakingsset voor het detecteren van een fout in 20 seconden leiden tot een storing van minuten als er een tijdelijke gebeurtenis plaatsvindt (zoals onderhoud met geheugenbehoud voor Azure-VM's). Het instellen van de bewaking op een meer ontspannen waarde van 40 seconden kan helpen bij het voorkomen van een langere onderbreking van de service.

Zie aanbevolen procedures voor clusters voor meer informatie om de drempelwaarden aan te passen.

Locatie van knooppunt

Knooppunten in een Windows-cluster op virtuele machines in Azure kunnen fysiek worden gescheiden binnen dezelfde Azure-regio of in verschillende regio's. De afstand kan netwerklatentie veroorzaken, net zoals het gebruik van clusterknooppunten tussen locaties in uw eigen faciliteiten. In cloudomgevingen is het verschil dat u zich in een regio mogelijk niet bewust bent van de afstand tussen knooppunten. Bovendien zijn er enkele andere factoren, zoals fysieke en virtuele onderdelen, het aantal hops, enzovoort. kan ook bijdragen aan een verhoogde latentie. Als latentie tussen de knooppunten een probleem is, kunt u overwegen de knooppunten van het cluster binnen een nabijheidsplaatsingsgroep te plaatsen om netwerknabijheid te garanderen.

Bronlimieten

Wanneer u een Virtuele Azure-machine configureert, bepaalt u de limieten voor rekenresources voor de CPU, het geheugen en de IO. Werkbelastingen waarvoor meer resources nodig zijn dan de aangeschafte Azure-VM, of schijflimieten kunnen prestatieproblemen met de VM veroorzaken. Prestatievermindering kan leiden tot een mislukte statuscontrole voor de clusterservice of voor de functie voor hoge beschikbaarheid van SQL Server. Resourceknelpunten kunnen ervoor zorgen dat het knooppunt of de resource omlaag wordt weergegeven in het cluster of SQL Server.

Intensieve SQL IO-bewerkingen of onderhoudsbewerkingen, zoals back-ups, index- of statistiekenonderhoud, kunnen ertoe leiden dat de VM of schijf IOPS- of MBPS-doorvoerlimieten bereikt, waardoor SQL Server niet meer reageert op een IsAlive/LooksAlive-controle.

Als uw SQL Server onverwachte failovers ondervindt, controleert u of u alle aanbevolen procedures voor prestaties volgt en controleert u de server op schijf- of VM-niveaulimieten.

Onderhoud van Azure-platform

Net als elke andere cloudservice werkt Azure het platform regelmatig bij om de betrouwbaarheid, prestaties en beveiliging van de hostinfrastructuur voor virtuele machines te verbeteren. Het doel van deze updates behelst zowel het uitvoeren van softwarepatches voor onderdelen in de hostomgeving als het upgraden van netwerkonderdelen of het buiten gebruik stellen van hardware.

De meeste platformupdates hebben geen invloed op vm's van klanten. Wanneer een update zonder impact niet mogelijk is, kiest Azure het updatemechanisme dat het minst van invloed is op de vm's van klanten. Het meeste niet-nul-impactonderhoud onderbreekt de VIRTUELE machine gedurende minder dan 10 seconden. In bepaalde gevallen maakt Azure gebruik van onderhoudsmechanismen met geheugenbehoud. Met deze mechanismen wordt de VM maximaal 30 seconden onderbroken en blijft het geheugen in het RAM-geheugen behouden. De VIRTUELE machine wordt vervolgens hervat en de klok wordt automatisch gesynchroniseerd.

Onderhoud met geheugenbehoud werkt voor meer dan 90 procent van de Virtuele Azure-machines. Het werkt niet voor de G-, M-, N- en H-serie. Azure maakt steeds vaker gebruik van technologieën voor livemigratie en verbetert onderhoudsmechanismen met geheugenbehoud om de onderbrekingsduur te verminderen. Wanneer de VIRTUELE machine live wordt gemigreerd naar een andere host, kunnen sommige gevoelige workloads, zoals SQL Server, een lichte prestatievermindering vertonen in de paar minuten die tot de VM-onderbreking hebben geleid.

Een resourceknelpunt tijdens het onderhoud van het platform kan ervoor zorgen dat de AG of FCI omlaag wordt weergegeven in de clusterservice. Zie de sectie Resourcelimieten van dit artikel voor meer informatie.

Als u agressieve clusterbewaking gebruikt, kan een uitgebreide VM-pauze een failover activeren. Een failover veroorzaakt vaak meer downtime dan de onderhoudspauze, dus het wordt aanbevolen om ontspannen bewaking te gebruiken om te voorkomen dat een failover wordt geactiveerd terwijl de VIRTUELE machine wordt onderbroken voor onderhoud. Zie de aanbevolen procedures voor clusters voor meer informatie over het instellen van clusterdrempels in Azure-VM's.

Beperkingen

Houd rekening met de volgende beperkingen wanneer u werkt met FCI of beschikbaarheidsgroepen en SQL Server op virtuele Azure-machines.

MSDTC

Virtuele Azure-machines bieden ondersteuning voor MSDTC (Microsoft Distributed Transaction Coordinator) in Windows Server 2019 met opslag op geclusterde gedeelde volumes (CSV) en Azure Standard Load Balancer of op VM's met SQL Server die gebruikmaken van gedeelde Azure-schijven.

MSDTC wordt vanwege deze redenen niet ondersteund op virtuele Azure-machines voor Windows Server 2016 of eerder met geclusterde gedeelde volumes:

• De geclusterde MSDTC-resource kan niet worden geconfigureerd voor het gebruik van gedeelde opslag. Als u in Windows Server 2016 een MSDTC-resource maakt, wordt er geen gedeelde opslag weergegeven die beschikbaar is voor gebruik, zelfs als dat wel het geval is. Dit probleem is opgelost in Windows Server 2019.
• De standaard load balancer biedt geen ondersteuning voor RPC-poorten.

Volgende stappen

Nu u vertrouwd bent met de verschillen bij het gebruik van een Windows-failovercluster met SQL Server op Azure-VM's, krijgt u meer informatie over de beschikbaarheidsgroepen met hoge beschikbaarheid of failoverclusterexemplaren. Als u klaar bent om aan de slag te gaan, controleert u de aanbevolen procedures voor configuratieaan aanbevelingen.