Dela via

Failoverklustring och Always On-tillgänglighetsgrupper (SQL Server)

  • Artikel

gäller för:SQL Server – endast Windows

AlwaysOn-tillgänglighetsgrupper, den lösning för hög tillgänglighet och haveriberedskap som introducerades i SQL Server 2012 (11.x), kräver Windows Server-redundansklustring (WSFC). Även om AlwaysOn-tillgänglighetsgrupper inte är beroende av SQL Server-redundanskluster, kan du använda en redundansklusterinstans (FCI) som värd för en tillgänglighetsreplik för en tillgänglighetsgrupp. Det är viktigt att känna till rollen för varje klustringsteknik och att veta vilka överväganden som krävs när du utformar din AlwaysOn-tillgänglighetsgruppermiljö.

Not

Information om begrepp för AlwaysOn-tillgänglighetsgrupper finns i Översikt över AlwaysOn-tillgänglighetsgrupper (SQL Server).

Windows Server-failoverklustring och tillgänglighetsgrupper

För att distribuera AlwaysOn-tillgänglighetsgrupper krävs ett Windows Server-redundanskluster (WSFC). För att aktiveras för AlwaysOn-tillgänglighetsgrupper måste en instans av SQL Server finnas på en WSFC-nod och WSFC och noden måste vara online. Dessutom måste varje tillgänglighetsreplik av en viss tillgänglighetsgrupp finnas på en annan nod i samma WSFC. Det enda undantaget är att när en tillgänglighetsgrupp migreras till en annan WSFC kan den tillfälligt korsa två kluster.

AlwaysOn-tillgänglighetsgrupper förlitar sig på Windows Server-redundanskluster (WSFC) för att övervaka och hantera de aktuella rollerna för tillgänglighetsreplikerna som tillhör en viss tillgänglighetsgrupp och för att avgöra hur en redundanshändelse påverkar tillgänglighetsreplikerna. En WSFC-resursgrupp skapas för varje tillgänglighetsgrupp som du skapar. WSFC övervakar den här resursgruppen för att utvärdera hälsotillståndet för den primära repliken.

Kvorumet för AlwaysOn-tillgänglighetsgrupper baseras på alla noder i WSFC oavsett om en viss klusternod är värd för några tillgänglighetsrepliker. Till skillnad från databasspegling finns det ingen vittnesroll i AlwaysOn-tillgänglighetsgrupper.

Den övergripande hälsan för en WSFC bestäms av rösterna för kvorum för noder i klustret. Om WSFC går offline på grund av en oplanerad katastrof, eller på grund av ett beständigt maskinvaru- eller kommunikationsfel, krävs manuella administrativa åtgärder. En Windows Server- eller WSFC-administratör måste framtvinga ett kvorum och sedan aktivera de kvarvarande klusternoderna igen i en icke-feltolerant konfiguration.

Viktig

AlwaysOn-tillgänglighetsgruppers registernycklar är undernycklar till WSFC. Om du tar bort och återskapar en WSFC måste du inaktivera och återaktivera funktionen AlwaysOn-tillgänglighetsgrupper på varje instans av SQL Server som var värd för en tillgänglighetsreplik i den ursprungliga WSFC:n.

Information om hur du kör SQL Server på WSFC-noder och om WSFC-kvorum finns i Windows Server-redundansklustring (WSFC) med SQL Server.

SQL Server-redundansklusterinstanser (FCIs) och tillgänglighetsgrupper

Du kan konfigurera ett andra lager redundans på serverinstansnivå genom att implementera SQL Server och FCI tillsammans med WSFC. En tillgänglighetsreplik kan vara värd för antingen en fristående instans av SQL Server eller en FCI-instans. Endast en FCI-partner kan hosta en replika för en viss tillgänglighetsgrupp. När en tillgänglighetsreplik körs på en FCI innehåller listan över möjliga ägare för tillgänglighetsgruppen endast den aktiva FCI-noden.

AlwaysOn-tillgänglighetsgrupper är inte beroende av någon form av delad lagring. Men om du använder en SQL Server-redundansklusterinstans (FCI) som värd för en eller flera tillgänglighetsrepliker, kräver var och en av dessa FCI:er delad lagring enligt standardinstallationen av SQL Server-redundansklusterinstansen.

Mer information om ytterligare förutsättningar finns i avsnittet "Krav och begränsningar för att använda en SQL Server-redundansklusterinstans (FCI) som värd för en tillgänglighetsreplik" i krav, begränsningar och rekommendationer för AlwaysOn-tillgänglighetsgrupper (SQL Server).

Jämförelse av redundansklusterinstanser och tillgänglighetsgrupper

Oavsett antalet noder i FCI är en hel FCI värd för en enskild replik i en tillgänglighetsgrupp. I följande tabell beskrivs skillnaderna i begrepp mellan noder i en FCI och repliker i en tillgänglighetsgrupp.

Noder inom en FCI Repliker i en tillgänglighetsgrupp
använder WSFC- Ja Ja
Skyddsnivå Instans Databas
Lagringstyp Delad Ej delad

Även om replikerna i en tillgänglighetsgrupp inte delar lagring, använder en replik som hanteras av en FCI en delad lagringslösning som krävs av den FCI:n. Lagringslösningen delas endast av noder i FCI:n och inte mellan repliker i tillgänglighetsgruppen.
Storage-lösningar Direktansluten, SAN, monteringspunkter, SMB Beror på nodtyp
läsbara sekundärfiler Nej* Ja
Tillämpliga inställningar för redundansprinciper WSFC-kvorum

FCI-specifik

Inställningar för tillgänglighetsgrupp**		 WSFC-kvorum

Inställningar för tillgänglighetsgrupp
Resurser som har tagit över Server, instans och databas Endast databas

*Medan synkrona sekundära repliker i en tillgänglighetsgrupp alltid körs på sina respektive SQL Server-instanser, har sekundära noder i en FCI faktiskt inte startat sina respektive SQL Server-instanser och är därför inte läsbara. I en FCI startar en sekundär nod endast sin SQL Server-instans när resursgruppens ägarskap överförs till den under en FCI-redundansväxling. På den aktiva FCI-noden, när en databasen som är värdad av FCI tillhör en tillgänglighetsgrupp, är databasen läsbar när den lokala tillgänglighetsrepliken körs som en läsbar sekundär replik.

**Inställningar för redundansprincip för tillgänglighetsgruppen gäller för alla repliker, oavsett om de finns i en fristående instans eller en FCI-instans.

Not

Mer information om Antal noder i FCIs och AlwaysOn-tillgänglighetsgrupper för olika utgåvor av SQL Server finns i funktioner som stöds av versionerna av SQL Server 2012 (https://go.microsoft.com/fwlink/?linkid=232473).

Överväganden för att hantera en tillgänglighetsreplika på en FCI

Viktig

Om du planerar att vara värd för en tillgänglighetsreplik på en SQL Server-redundansklusterinstans (FCI) kontrollerar du att Windows Server 2008-värdnoderna uppfyller kraven och begränsningarna för AlwaysOn för redundansklusterinstanser (FCIs). Mer information finns i krav, begränsningar och rekommendationer för AlwaysOn-tillgänglighetsgrupper (SQL Server).

SQL Server-redundansklusterinstanser (FCIs) stöder inte automatisk redundans av tillgänglighetsgrupper, så alla tillgänglighetsrepliker som hanteras av en FCI kan bara konfigureras för manuell redundansväxling.

Du kan behöva konfigurera en WSFC för att inkludera delade diskar som inte är tillgängliga på alla noder. Överväg till exempel en WSFC över två datacenter med tre noder. Två av noderna är värdar för en SQL Server-redundansklusterinstans (FCI) i det primära datacentret och har åtkomst till samma delade diskar. Den tredje noden är värd för en fristående instans av SQL Server i ett annat datacenter och har inte åtkomst till de delade diskarna från det primära datacentret. Den här WSFC-konfigurationen stöder distributionen av en tillgänglighetsgrupp om FCI är värd för den primära repliken och den fristående instansen är värd för den sekundära repliken.

När du väljer en FCI som värd för en tillgänglighetsreplik för en viss tillgänglighetsgrupp kontrollerar du att en FCI-redundans inte kan orsaka att en enda WSFC-nod försöker vara värd för två tillgänglighetsrepliker för samma tillgänglighetsgrupp.

I följande exempelscenario visas hur den här konfigurationen kan leda till problem:

Du konfigurerar en WSFC med två noder, NODE01 och NODE02. Du installerar en SQL Server-redundansklusterinstans fciInstance1på både NODE01 och NODE02 där NODE01 är den aktuella ägaren för fciInstance1.
På NODE02installerar du en annan instans av SQL Server, Instance3, som är en fristående instans.
På NODE01aktiverar du fciInstance1 för AlwaysOn-tillgänglighetsgrupper. På NODE02aktiverar du Instance3 för AlwaysOn-tillgänglighetsgrupper. Sedan konfigurerar du en tillgänglighetsgrupp där fciInstance1 är värd för den primära repliken och Instance3 är värd för den sekundära repliken.
Vid något tillfälle blir fciInstance1 otillgänglig på NODE01, och WSFC utlöser en failover av fciInstance1 till NODE02. Efter redundansväxlingen är fciInstance1 en AlwaysOn-tillgänglighetsgrupperaktiverad instans som körs under den primära rollen på NODE02. Men Instance3 finns nu på samma WSFC-nod som fciInstance1. Detta strider mot begränsningen för Always On-åtkomstgrupper.
För att åtgärda problemet i det här scenariot måste den fristående instansen, Instance3, finnas på en annan nod i samma WSFC som NODE01 och NODE02.

Mer information om SQL Server-FCI:er finns i AlwaysOn-redundansklusterinstanser (SQL Server).

Begränsningar för användning av klusterhanteraren för WSFC-redundanskluster med tillgänglighetsgrupper

Använd inte Failover Cluster-hanteraren för att hantera tillgänglighetsgrupper, till exempel:

  • Lägg inte till eller ta bort resurser i den klustrade tjänsten (resursgruppen) för tillgänglighetsgruppen.

  • Ändra inte några egenskaper för tillgänglighetsgrupper, till exempel möjliga ägare och önskade ägare. Dessa egenskaper anges automatiskt av tillgänglighetsgruppen.

  • Använd inte klusterhanteraren för växling vid fel för att flytta tillgänglighetsgrupper till olika noder eller redundansväxla tillgänglighetsgrupper. Klusterhanteraren för växling vid fel känner inte till synkroniseringsstatusen för tillgänglighetsreplikerna, vilket kan leda till längre driftstopp. Du måste använda Transact-SQL eller SQL Server Management Studio.

Varning

Om du använder Klusterhanteraren för växling vid fel för att flytta en redundansklusterinstans som är värd för en tillgänglighetsgrupp till en nod som redan värd för en replik av samma tillgänglighetsgrupp kan det leda till att tillgänglighetsgrupprepliken går förlorad, vilket förhindrar att den tas online på målnoden. En enskild nod i ett failoverkluster kan inte hysa fler än en replik för samma tillgänglighetsgrupp. Mer information om hur detta inträffar och hur du återställer finns i blogginlägget Replika oväntat borttagen inom tillgänglighetsgruppen.

Relaterat innehåll

Se även

översikt över AlwaysOn-tillgänglighetsgrupper (SQL Server)
Aktivera och inaktivera AlwaysOn-tillgänglighetsgrupper (SQL Server)
Övervaka tillgänglighetsgrupper (Transact-SQL)
Always On-redundansklusterinstanser (SQL Server)