Dela via

Redundanskluster och AlwaysOn-tillgänglighetsgrupper (SQL Server)

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-redundansklustring kan du använda en FCI (failover clustering instance) för att vara 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änglighetsgruppsmiljö.

Not

Information om begrepp för AlwaysOn-tillgänglighetsgrupper finns i Vad är en AlwaysOn-tillgänglighetsgrupp?

Windows Server-redundanskluster 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 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. Antingen kan en fristående instans av SQL Server eller en FCI-instans vara värd för en tillgänglighetsreplik. 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 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 lösning för delad lagring 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. Men på den aktiva FCI-noden, när en FCI-värdbaserad databas tillhör en tillgänglighetsgrupp, kan databasen läsas om 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.

Överväganden för att vara värd för en tillgänglighetsreplik 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 (FCI). 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 en FCI-värd bara kan 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 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 distribution 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 fciInstance1 blir otillgänglig på NODE01, och WSFC orsakar en redundansväxling 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.

Den fristående instansen Instance3måste finnas på en annan nod i samma WSFC som och NODE02för att åtgärda problemet i NODE01 det här scenariot.

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

Begränsningar för användning av WSFC Manager med tillgänglighetsgrupper

Använd inte klusterhanteraren för växling vid fel för att ändra 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, och det kan leda till längre stilleståndstid. 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 är värd för en replik av samma tillgänglighetsgrupp kan det leda till att tillgänglighetsgrupprepliken förloras, vilket förhindrar att den tas online på målnoden. En enskild nod i ett redundanskluster kan inte vara värd för fler än en replik för samma tillgänglighetsgrupp. Mer information om hur detta inträffar och hur du återställer finns i bloggrepliken som oväntat har släppts i tillgänglighetsgruppen.

Relaterat innehåll