Failoverclustering en AlwaysOn-beschikbaarheidsgroepen (SQL Server)

Artikel
01/02/2025

van toepassing op:SQL Server- - alleen Windows

AlwaysOn-beschikbaarheidsgroepen, de oplossing voor hoge beschikbaarheid en herstel na noodgevallen die is geïntroduceerd in SQL Server 2012 (11.x), vereist Windows Server Failover Clustering (WSFC). Hoewel AlwaysOn-beschikbaarheidsgroepen niet afhankelijk zijn van SQL Server-failoverclustering, kunt u een failoverclusteringexemplaar (FCI) gebruiken om een beschikbaarheidsreplica voor een beschikbaarheidsgroep te hosten. Het is belangrijk om de rol van elke clustertechnologie te kennen en om te weten welke overwegingen nodig zijn bij het ontwerpen van uw AlwaysOn-beschikbaarheidsgroepenomgeving.

Notitie

Zie Overzicht van AlwaysOn-beschikbaarheidsgroepen (SQL Server)voor informatie over concepten van AlwaysOn-beschikbaarheidsgroepen.

Windows Server-failoverclustering en -beschikbaarheidsgroepen

Voor het implementeren van AlwaysOn-beschikbaarheidsgroepen is een Windows Server-failovercluster (WSFC) vereist. Als u alwayson-beschikbaarheidsgroepen wilt inschakelen, moet een exemplaar van SQL Server zich op een WSFC-knooppunt bevinden en moet de WSFC en het knooppunt online zijn. Bovendien moet elke beschikbaarheidsreplica van een bepaalde beschikbaarheidsgroep zich op een ander knooppunt van hetzelfde WSFC bevinden. De enige uitzondering hierop is dat een beschikbaarheidsgroep tijdens de migratie naar een andere WSFC tijdelijk twee clusters kan verwisselen.

AlwaysOn-beschikbaarheidsgroepen zijn afhankelijk van het Windows Server-failovercluster (WSFC) om de huidige rollen van de beschikbaarheidsreplica's die deel uitmaken van een bepaalde beschikbaarheidsgroep te bewaken en te beheren en om te bepalen hoe een failover-gebeurtenis van invloed is op de beschikbaarheidsreplica's. Er wordt een WSFC-resourcegroep gemaakt voor elke beschikbaarheidsgroep die u maakt. De WSFC bewaakt deze resourcegroep om de status van de primaire replica te evalueren.

Het quorum voor AlwaysOn-beschikbaarheidsgroepen is gebaseerd op alle knooppunten in de WSFC, ongeacht of een bepaald clusterknooppunt als host fungeert voor beschikbaarheidsreplica's. In tegenstelling tot databasespiegeling is er geen witness-rol in AlwaysOn-beschikbaarheidsgroepen.

De algehele status van een WSFC wordt bepaald door de stemmen van het quorum van knooppunten in het cluster. Als de WSFC offline gaat vanwege een ongeplande ramp of als gevolg van een permanente hardware- of communicatiefout, is handmatige administratieve interventie vereist. Een Windows Server- of WSFC-beheerder moet een quorum afdwingen en vervolgens de overlevende clusterknooppunten weer online brengen in een niet-fouttolerante configuratie.

Belangrijk

Registersleutels voor AlwaysOn-beschikbaarheidsgroepen zijn subsleutels van de WSFC. Als u een WSFC verwijdert en opnieuw maakt, moet u de functie AlwaysOn-beschikbaarheidsgroepen uitschakelen en opnieuw inschakelen op elk exemplaar van SQL Server waarop een beschikbaarheidsreplica op de oorspronkelijke WSFC wordt gehost.

Zie Windows Server Failover Clustering (WSFC) met SQL Servervoor informatie over het uitvoeren van SQL Server op WSFC-knooppunten en over WSFC-quorum.

SQL Server-failoverclusterexemplaren (CCI's) en beschikbaarheidsgroepen

U kunt een tweede failoverlaag instellen op serverexemplaarniveau door SQL Server en FCI samen met de WSFC te implementeren. Een beschikbaarheidsreplica kan worden gehost door een zelfstandig exemplaar van SQL Server of een FCI-exemplaar. Slechts één FCI-partner kan een replica voor een bepaalde beschikbaarheidsgroep hosten. Wanneer een beschikbaarheidsreplica draait op een FCI, zal de lijst met mogelijke eigenaren voor de beschikbaarheidsgroep alleen het actieve FCI-knooppunt bevatten.

AlwaysOn-beschikbaarheidsgroepen zijn niet afhankelijk van een vorm van gedeelde opslag. Als u echter een exemplaar van een SQL Server-failovercluster (FCI) gebruikt om een of meer beschikbaarheidsreplica's te hosten, is voor elk van deze CFA's gedeelde opslag vereist volgens de standaardinstallatie van het SQL Server-failoverclusterexemplaar.

Zie de sectie 'Vereisten en beperkingen voor het gebruik van een SQL Server-failoverclusterexemplaar (FCI) om een beschikbaarheidsreplica te hosten' in de handleiding 'Vereisten, beperkingen en aanbevelingen voor Always On-beschikbaarheidsgroepen (SQL Server)voor meer informatie over aanvullende vereisten.

Vergelijking van failoverclusterexemplaren en beschikbaarheidsgroepen

Ongeacht het aantal knooppunten in de FCI host een hele FCI één replica binnen een beschikbaarheidsgroep. In de volgende tabel worden de verschillen in concepten tussen knooppunten in een FCI en replica's binnen een beschikbaarheidsgroep beschreven.

	Knooppunten binnen een FCI	Replica's binnen een beschikbaarheidsgroep
WSFC- gebruikt	Ja	Ja
beveiligingsniveau	Instantie	Databank
opslagtype	Gedeeld	Niet gedeeld Hoewel de replica's in een beschikbaarheidsgroep geen opslag delen, gebruikt een replica die wordt gehost door een FCI een gedeelde opslagoplossing zoals vereist voor die FCI. De opslagoplossing wordt alleen gedeeld door knooppunten binnen de FCI en niet tussen replica's van de beschikbaarheidsgroep.
Storage-oplossingen	Direct gekoppeld, SAN, koppelpunten, SMB	Afhankelijk van het knooppunttype
Leesbare secundaire	Nee*	Ja
Toepasselijke instellingen voor failoverbeleid	WSFC-quorum FCI-specifiek Instellingen voor beschikbaarheidsgroep**	WSFC-quorum Instellingen voor beschikbaarheidsgroep
resources waarvoor een failover is uitgevoerd,	Server, instance en database	Database alleen

*Terwijl synchrone secundaire replica's in een beschikbaarheidsgroep altijd worden uitgevoerd op hun respectieve SQL Server-exemplaren, zijn secundaire knooppunten in een FCI daadwerkelijk niet gestart met hun respectieve SQL Server-exemplaren en kunnen ze daarom niet worden gelezen. In een FCI start een secundair knooppunt het SQL Server-exemplaar alleen wanneer de eigendomsoverdracht van de resourcegroep tijdens een FCI-failover plaatsvindt. Wanneer een door FCI gehoste database echter deel uitmaakt van een beschikbaarheidsgroep op het actieve FCI-knooppunt, is de database leesbaar als de lokale beschikbaarheidsreplica wordt uitgevoerd als een leesbare secundaire replica.

**Failoverbeleidsinstellingen voor de beschikbaarheidsgroep zijn van toepassing op alle replica's, ongeacht of deze worden gehost in een zelfstandig exemplaar of een FCI-exemplaar.

Notitie

Zie functies die worden ondersteund door de edities van SQL Server 2012 () voor meer informatie over aantal knooppunten binnen FCIs en https://go.microsoft.com/fwlink/?linkid=232473 .

Overwegingen voor het hosten van een beschikbaarheidsreplica op een FCI

Belangrijk

Als u van plan bent om een beschikbaarheidsreplica te hosten op een SQL Server Failover Cluster Instance (FCI), moet u ervoor zorgen dat de Windows Server 2008-hostknooppunten voldoen aan de vereisten en beperkingen voor Failover Cluster-exemplaren (FCI's). Zie vereisten, beperkingen en aanbevelingen voor AlwaysOn-beschikbaarheidsgroepen (SQL Server)voor meer informatie.

SQL Server Failover Cluster Instances (CFA's) bieden geen ondersteuning voor automatische failover per beschikbaarheidsgroepen, dus elke beschikbaarheidsreplica die wordt gehost door een FCI kan alleen worden geconfigureerd voor handmatige failover.

Mogelijk moet u een WSFC configureren om gedeelde schijven op te nemen die niet beschikbaar zijn op alle knooppunten. Denk bijvoorbeeld aan een WSFC in twee datacenters met drie knooppunten. Twee van de knooppunten hosten een exemplaar van een SQL Server-failovercluster (FCI) in het primaire datacenter en hebben toegang tot dezelfde gedeelde schijven. Het derde knooppunt fungeert als host voor een zelfstandig exemplaar van SQL Server in een ander datacenter en heeft geen toegang tot de gedeelde schijven vanuit het primaire datacenter. Deze WSFC-configuratie ondersteunt de implementatie van een beschikbaarheidsgroep als de FCI als host fungeert voor de primaire replica en het zelfstandige exemplaar als host voor de secundaire replica.

Bij het kiezen van een FCI voor het hosten van een beschikbaarheidsreplica voor een bepaalde beschikbaarheidsgroep, zorg ervoor dat een FCI-failover niet kan leiden tot een situatie waarbij een enkel WSFC-knooppunt probeert twee beschikbaarheidsreplica's voor dezelfde beschikbaarheidsgroep te hosten.

In het volgende voorbeeldscenario ziet u hoe deze configuratie kan leiden tot problemen:

U configureert een WSFC met twee knooppunten, NODE01 en NODE02. U installeert een exemplaar van een SQL Server-failovercluster, fciInstance1, op zowel NODE01 als NODE02 waar NODE01 de huidige eigenaar van fciInstance1is.
Op NODE02installeert u een ander exemplaar van SQL Server, Instance3, een zelfstandig exemplaar.
In NODE01schakelt u fciInstance1 in voor AlwaysOn-beschikbaarheidsgroepen. In NODE02schakelt u Instance3 in voor AlwaysOn-beschikbaarheidsgroepen. Vervolgens stelt u een beschikbaarheidsgroep in waarvoor fciInstance1 als host fungeert voor de primaire replica en Instance3 als host fungeert voor de secundaire replica.
Op een bepaald moment is fciInstance1 niet meer beschikbaar op NODE01en veroorzaakt de WSFC een failover van fciInstance1 naar NODE02. Na de failover is fciInstance1 een instantie met Always On-beschikbaarheidsgroepen die actief is onder de primaire rol op NODE02. Instance3 bevindt zich nu echter op hetzelfde WSFC-knooppunt als fciInstance1. Dit schendt de beperking van AlwaysOn-beschikbaarheidsgroepen.
Als u het probleem wilt oplossen dat in dit scenario wordt weergegeven, moet de zelfstandige instantie, Instance3, zich op een ander knooppunt in dezelfde WSFC bevinden als NODE01 en NODE02.

Zie Always On Failover Cluster Instances (SQL Server)voor meer informatie over SQL Server-FCI's.

Beperkingen voor het gebruik van WSFC-failoverclusterbeheer met beschikbaarheidsgroepen

Gebruik failoverclusterbeheer niet om beschikbaarheidsgroepen te bewerken, bijvoorbeeld:

Voeg geen resources toe en verwijder geen resources in de geclusterde service (resourcegroep) voor de beschikbaarheidsgroep.
Wijzig geen eigenschappen van beschikbaarheidsgroepen, zoals de mogelijke eigenaren en voorkeurseigenaren. Deze eigenschappen worden automatisch ingesteld door de beschikbaarheidsgroep.
Gebruik failoverclusterbeheer niet om beschikbaarheidsgroepen naar verschillende knooppunten te verplaatsen of om een failover van beschikbaarheidsgroepen uit te voeren. Failoverclusterbeheer is niet op de hoogte van de synchronisatiestatus van de beschikbaarheidsreplica's, en dit kan leiden tot uitgebreide uitvaltijd. U moet Transact-SQL of SQL Server Management Studio gebruiken.

Waarschuwing

Als u failoverclusterbeheer gebruikt om een failoverclusterexemplaren te verplaatsen een beschikbaarheidsgroep host naar een knooppunt dat al al als host fungeert voor een replica van dezelfde beschikbaarheidsgroep, kan dit leiden tot verlies van de replica van de beschikbaarheidsgroep, waardoor deze niet online kan worden gebracht op het doelknooppunt. Eén knooppunt van een failovercluster kan niet meer dan één replica hosten voor dezelfde beschikbaarheidsgroep. Zie de blog Replica onverwacht verwijderd in de beschikbaarheidsgroepvoor meer informatie over hoe dit gebeurt en hoe u deze herstelt.

Verwante inhoud

Zie ook

overzicht van AlwaysOn-beschikbaarheidsgroepen (SQL Server)
AlwaysOn-beschikbaarheidsgroepen (SQL Server) in- en uitschakelen
Beschikbaarheidsgroepen (Transact-SQL) controleren
AlwaysOn-failoverclusterexemplaren (SQL Server)

Delen via