Krav, begränsningar och rekommendationer för AlwaysOn-tillgänglighetsgrupper

gäller för:SQL Server

I den här artikeln beskrivs överväganden för att distribuera AlwaysOn-tillgänglighetsgrupper, inklusive krav, begränsningar och rekommendationer för värddatorer, Windows Server-redundanskluster (WSFC), serverinstanser och tillgänglighetsgrupper. För var och en av dessa komponenter anges säkerhetsöverväganden och nödvändiga behörigheter, om sådana finns.

.NET-snabbkorrigeringar som stöder tillgänglighetsgrupper

Beroende på de SQL Server-komponenter och funktioner som du använder med AlwaysOn-tillgänglighetsgrupper kan du behöva installera ytterligare .NET-snabbkorrigeringar som identifieras i följande tabell. Snabbkorrigeringarna kan installeras i valfri ordning.

Checklista: Krav (Windows-system)

Om du vill stödja funktionen AlwaysOn-tillgänglighetsgrupper kontrollerar du att varje dator som ska delta i en eller flera tillgänglighetsgrupper uppfyller följande grundläggande krav:

Rekommendationer för datorer som värdar tillgänglighetsrepliker (Windows-system)

• Jämförbara system: För en viss tillgänglighetsgrupp bör alla tillgänglighetsrepliker köras på jämförbara system som kan hantera identiska arbetsbelastningar.

• Dedikerade nätverkskort: Använd ett dedikerat nätverkskort (nätverksgränssnittskort) för AlwaysOn-tillgänglighetsgrupper för bästa prestanda.

• Tillräckligt med diskutrymme: Varje dator där en serverinstans är värd för en tillgänglighetsreplik måste ha tillräckligt med diskutrymme för alla databaser i tillgänglighetsgruppen. Tänk på att i takt med att de primära databaserna växer ökar deras motsvarande sekundära databaser med samma mängd.

• Identisk disklayout: Varje dator där en serverinstans är värd för en tillgänglighetsreplik ska ha en identisk disklayout (med exakta diskenhetsbeteckningar och storlekar) för att säkerställa att filsökvägarna för databasfiler (mdf, ldf) speglas, vilket förhindrar komplikationer vid seedning och synkronisering. Granska begränsningar (tillgänglighetsdatabaser) för disklayouter som skiljer sig åt.

• Resource Governor-konfiguration: Om du använder resursguvernör använder du samma konfiguration av resursguvernören på alla instanser som är värdar för tillgänglighetsgruppsrepliker.

Behörigheter (Windows-system)

För att administrera en WSFC måste användaren vara systemadministratör på varje klusternod.

Mer information om kontot för att administrera klustret finns i Bilaga A: Krav för redundanskluster.

Relaterade uppgifter (Windows-system)

Ändra HostRecordTTL (med PowerShell)

1. Öppna PowerShell-fönstret via Kör som administratör.

2. Importera modulen FailoverClusters.

3. Använd cmdleten Get-ClusterResource för att hitta resursen Nätverksnamn och använd sedan Set-ClusterParameter cmdlet för att ange värdet HostRecordTTL enligt följande:

   Get-ClusterResource "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL <TidISekunder>

   I följande PowerShell-exempel anges HostRecordTTL till 300 sekunder för en nätverksnamnsresurs med namnet SQL Network Name (SQL35).

   Import-Module FailoverClusters
   
   $nameResource = "SQL Network Name (SQL35)"
   Get-ClusterResource $nameResource | Set-ClusterParameter HostRecordTTL 300
   

   Tips

   Varje gång du öppnar ett nytt PowerShell-fönster måste du importera modulen FailoverClusters.

Relaterat innehåll (PowerShell)

• Klustring för failover och hög tillgänglighet (teamblogg för failover-kluster och nätverkslastbalansering)

• Komma igång med Windows PowerShell på ett redundanskluster

• klusterresurskommandon och motsvarande Windows PowerShell-cmdletar

Relaterat innehåll (Windows-system)

• Konfigurera DNS-inställningar i ett redundanskluster med flera platser

• DNS-registrering med nätverksnamnresurs

Krav och begränsningar för SQL Server-instanser

Varje tillgänglighetsgrupp kräver en uppsättning redundanspartners, så kallade tillgänglighetsrepliker, som hanteras av instanser av SQL Server. En viss serverinstans kan vara en fristående instans eller en SQL Server redundansklusterinstans (FCI).

I det här avsnittet:

• Checklista: Förutsättningar
• trådanvändning efter tillgänglighetsgrupper
• Behörigheter
• Relaterade Uppgifter
• Relaterat Innehåll

Checklista: Förutsättningar (serverinstans)

En lista över funktioner som stöds av versionerna av SQL Server i Windows finns i:

• Utgåvor och funktioner som stöds i SQL Server 2022
• Utgåvor och funktioner som stöds i SQL Server 2019
• Utgåvor och funktioner som stöds i SQL Server 2017
• Utgåvor och funktioner som stöds i SQL Server 2016

Trådanvändning efter tillgänglighetsgrupper

AlwaysOn-tillgänglighetsgrupper har följande krav för arbetstrådar:

• På en inaktiv instans av SQL Server använder AlwaysOn-tillgänglighetsgrupper 0 trådar.

• Det maximala antalet trådar som används av tillgänglighetsgrupper är den konfigurerade inställningen för det maximala antalet servertrådar ("maximalt antal arbetstrådar") minus 40.

• Tillgänglighetsreplikerna som finns på en viss serverinstans delar en enda trådpool i SQL Server 2019 (15.x) och tidigare versioner.

  Trådar delas på begäran enligt följande:

  • Det finns vanligtvis 3–10 delade trådar, men det här antalet kan öka beroende på den primära replikarbetsbelastningen.

  • Om en viss tråd är inaktiv ett tag släpps den tillbaka till den allmänna SQL Server-trådpoolen. Normalt släpps en inaktiv tråd efter ~15 sekunders inaktivitet. Beroende på den senaste aktiviteten kan dock en inaktiv tråd behållas längre.

  • En SQL Server-instans använder upp till 100 trådar för parallell återställning för sekundära repliker. Varje databas använder upp till hälften av det totala antalet CPU-kärnor, men högst 16 trådar per databas. Om det totala antalet obligatoriska trådar för en enskild instans överskrider 100 använder SQL Server en enda om-tråd för varje återstående databas. Seriella gör-om-trådar frigörs efter cirka 15 sekunders inaktivitet.

• Dessutom använder tillgänglighetsgrupper odelade trådar enligt följande:

  • Varje primär replik använder en Log Capture-tråd för varje primär databas. Dessutom använder den 1 log send-tråd för varje sekundär databas. Loggöverföringstrådar släpps efter ~15 sekunders inaktivitet.

  • En säkerhetskopia på en sekundär replik innehåller en tråd på den primära repliken under hela säkerhetskopieringen.

• SQL Server 2022 (16.x) introducerade den parallella redo-trådpoolen, som är en trådpool på instansnivå som delas av alla databaser som gör om arbete. Med den här poolen kan samma uppsättning trådar bearbeta loggposterna för olika databaser samtidigt (parallellt). I SQL Server 2019 (15.x) och tidigare versioner är antalet tillgängliga trådar för redo begränsat till 100.

• SQL Server 2019 (15.x) introducerade parallell redo för minnesoptimerade databaser i tillgänglighetsgrupper. I SQL Server 2016 (13.x) och SQL Server 2017 (14.x) använder diskbaserade tabeller inte parallell redo om en databas i en tillgänglighetsgrupp också är minnesoptimerad.

Mer information finns i AlwaysOn – HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (en CSS SQL Server Engineers-blogg).

Behörigheter (serverinstans)

Relaterade uppgifter (serverinstans)

Relaterat innehåll (serverinstans)

• AlwaysOn – HADRON Learning Series: Användning av arbetspooler för HADRON-aktiverade databaser

Rekommendationer för nätverksanslutning

Vi rekommenderar starkt att du använder samma nätverkslänkar för kommunikation mellan WSFC-noder och kommunikation mellan tillgänglighetsrepliker. Att använda separata nätverkslänkar kan orsaka oväntade beteenden om vissa länkar misslyckas (även tillfälligt).

För att en tillgänglighetsgrupp ska kunna stödja automatisk redundans måste den sekundära repliken som är partner för automatisk redundans vara i tillståndet SYNKRONISERAD. Om nätverkslänken till den här sekundära repliken misslyckas (även tillfälligt) går repliken in i tillståndet UNSYNCHRONIZED och kan inte börja synkronisera om förrän länken har återställts. Om WSFC begär en automatisk failover medan den sekundära repliken är osynkroniserad, inträffar inte automatisk failover.

Stöd för klientanslutning

Information om stöd för AlwaysOn-tillgänglighetsgrupper för klientanslutning finns i Stöd för drivrutin och klientanslutning för tillgänglighetsgrupper.

Krav och begränsningar för att använda en SQL Server-redundansklusterinstans (FCI) som värd för en tillgänglighetsreplik

I det här avsnittet:

• Begränsningar
• Checklista: Förutsättningar
• relaterade uppgifter
• Relaterat Innehåll

Begränsningar (FCIs)

• Klusternoderna i en FCI kan bara vara värd för en replik för en viss tillgänglighetsgrupp: Om du lägger till en tillgänglighetsreplik på en FCI kan WSFC-noderna som är möjliga FCI-ägare inte vara värd för en annan replik för samma tillgänglighetsgrupp. För att undvika eventuella konflikter rekommenderar vi att du konfigurerar möjliga ägare för redundansklusterinstansen. Detta förhindrar risken att en enda WSFC skulle försöka vara värd för två tillgänglighetsrepliker inom samma tillgänglighetsgrupp.

  Dessutom måste alla andra repliker hanteras av en instans av SQL Server som finns på en annan klusternod i samma Windows Server-redundanskluster. Det enda undantaget är att när en tillgänglighetsgrupp migreras till ett annat kluster kan den tillfälligt korsa två kluster.

  Varning

  Om du använder Klusterhanteraren för växling vid fel för att flytta en FCI som är värd för en tillgänglighetsgrupp till en nod som redan som är 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 singel nod i ett failover-kluster kan inte hosta mer än en replik för samma tillgänglighetsgrupp. Mer information om hur detta inträffar och hur du återställer finns i bloggen Replica oväntat släppt i tillgänglighetsgruppen.

• FCI:er stöder inte automatisk redundans av tillgänglighetsgrupper: FCI:er stöder inte automatisk redundans av tillgänglighetsgrupper, så alla tillgänglighetsrepliker som hanteras av en FCI kan konfigureras endast för manuell redundans.

• Ändra FCI-nätverksnamn: Om du behöver ändra nätverksnamnet för en FCI som är värd för en tillgänglighetsreplik måste du ta bort repliken från dess tillgänglighetsgrupp och sedan lägga till repliken i tillgänglighetsgruppen igen. Du kan inte ta bort den primära repliken, så om du byter namn på en FCI som är värd för den primära repliken bör du redundansväxla till en sekundär replik och sedan ta bort den tidigare primära repliken och lägga till den igen. Om du byter namn på en FCI kan url:en för dess databasspeglingsslutpunkt ändras. När du lägger till repliken kontrollerar du att du anger den aktuella slutpunkts-URL:en.

Checklista: Förutsättningar (FCIs)

Relaterade uppgifter (FCIs)

Relaterat innehåll (FCIs)

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

• Always On-arkitekturguide: Skapa en lösning för hög tillgänglighet och katastrofåterhämtning med hjälp av failover-klusterinstanser och tillgänglighetsgrupper

Krav och begränsningar för tillgänglighetsgrupp

I det här avsnittet:

• Begränsningar
• Krav
• Säkerhet
• Relaterade Uppgifter

Begränsningar (tillgänglighetsgrupper)

• Tillgänglighetsrepliker måste hanteras av olika noder i en WSFC: För en viss tillgänglighetsgrupp måste tillgänglighetsrepliker hanteras av serverinstanser som körs på olika noder i samma WSFC. Det enda undantaget är att när en tillgänglighetsgrupp migreras till ett annat kluster kan den tillfälligt korsa två kluster.

  Not

  Virtuella datorer på samma fysiska dator kan var och en vara värd för en tillgänglighetsreplik för samma tillgänglighetsgrupp eftersom varje virtuell dator fungerar som en separat dator.

• Unikt namn på tillgänglighetsgrupp: Varje tillgänglighetsgruppsnamn måste vara unikt för WSFC. Den maximala längden för ett namn på en tillgänglighetsgrupp är 128 tecken.

• Tillgänglighetsrepliker: Varje tillgänglighetsgrupp stöder en primär replik och upp till åtta sekundära repliker. Alla repliker kan köras i asynkront incheckningsläge, eller så kan upp till fem av dem köras i synkront incheckningsläge (en primär replik med två synkrona sekundära repliker). Varje replik måste ha ett unikt servernamn i både Windows och SQL Server. Servernamnen mellan Windows och SQL Server måste matcha.

• Maximalt antal tillgänglighetsgrupper och tillgänglighetsdatabaser per dator: Det faktiska antalet databaser och tillgänglighetsgrupper som du kan placera på en dator (virtuell dator eller fysisk) beror på maskinvaran och arbetsbelastningen, men det finns ingen framtvingad gräns. Microsoft har testat upp till 10 AG:er och 100 DATABASER per fysisk dator, men detta är inte en bindningsgräns. Beroende på maskinvaruspecifikationen på servern och arbetsbelastningen kan du placera ett högre antal databaser och tillgänglighetsgrupper på en instans av SQL Server. Tecken på överbelastade system kan omfatta, men är inte begränsade till, överbelastning av arbetstrådar, långsamma svarstider för systemvyer och DMV:er för tillgänglighetsgrupper och/eller fördröjda systemdumpar för dispatcher. Se till att noggrant testa din miljö med en produktionsliknande arbetsbelastning för att säkerställa att den kan hantera den högsta arbetsbelastningskapaciteten i dina programavtal. När du överväger serviceavtal bör du överväga belastning under felförhållanden samt förväntade svarstider.

• Använd inte Failover-klusterhanteraren för att manipulera tillgänglighetsgrupper. Tillståndet för en SQL Server FCI delas mellan SQL Server och Windows Server-redundansklustret (WSFC), där SQL Server behåller mer detaljerad tillståndsinformation om instanserna än vad klustret bryr sig om. Hanteringsmodellen är att SQL Server måste driva transaktionerna och ansvarar för att hålla klustrets vy över tillståndet synkroniserad med SQL Server:s tillståndsvy. Om klustrets tillstånd ändras utanför SQL Server är det möjligt att tillståndet blir osynkroniserat mellan WSFC och SQL Server, vilket kan leda till oförutsägbart beteende.

  Till exempel:

  • Ändra inte några egenskaper för tillgänglighetsgrupper, till exempel möjliga ägare.

  • Använd inte Failover Cluster Manager för att växla över tillgänglighetsgrupper. Du måste använda Transact-SQL eller SQL Server Management Studio.

• Lägg inte till resurser eller ändra beroenden som är kopplade till tillgänglighetsgruppsrollen. Vi rekommenderar inte att du placerar några ytterligare resurser (inklusive användare eller tredje part) i tillgänglighetsgruppens roll eller ändrar rollberoendena eftersom dessa ändringar kan påverka redundansprestanda negativt.

Krav (tillgänglighetsgrupper)

När du skapar eller konfigurerar om en konfiguration av tillgänglighetsgrupper kontrollerar du att du följer följande krav.

Säkerhet (tillgänglighetsgrupper)

• Säkerhet ärvs från WSFC. Windows Server-failöverklustring ger två nivåer av användarsäkerhet på hela klustrets granularitetsnivå.

  • Skrivskyddad åtkomst

  • Fullständig kontroll

    AlwaysOn-tillgänglighetsgrupper behöver fullständig kontroll, och om du aktiverar AlwaysOn-tillgänglighetsgrupper på en instans av SQL Server får du fullständig kontroll över klustret (via tjänst-SID).

    Du kan inte lägga till eller ta bort säkerhet direkt för en serverinstans i Klusterhanteraren. Om du vill hantera klustersäkerhetssessioner använder du SQL Server Configuration Manager eller WMI-motsvarigheten från SQL Server.

• Varje instans av SQL Server måste ha behörighet att komma åt registret, klustret och så vidare.

• Vi rekommenderar att du använder kryptering för anslutningar mellan serverinstanser som är värdar för AlwaysOn-tillgänglighetsgruppers tillgänglighetsrepliker.

Behörigheter (tillgänglighetsgrupper)

Relaterade uppgifter (tillgänglighetsgrupper)

Krav och begränsningar för tillgänglighetsdatabas

För att vara berättigad att läggas till i en tillgänglighetsgrupp måste en databas uppfylla följande krav och begränsningar.

I det här avsnittet:

• Krav
• begränsningar
• Rekommendationer för datorer som är värdar för tillgänglighetsrepliker (Windows-system
• behörigheter
• relaterade uppgifter

Checklista: Krav (tillgänglighetsdatabaser)

För att vara berättigad att läggas till i en tillgänglighetsgrupp måste en databas:

Begränsningar (tillgänglighetsdatabaser)

• Om filsökvägen (inklusive enhetsbeteckningen) för en sekundär databas skiljer sig från sökvägen till motsvarande primära databas gäller följande begränsningar:

  • Guiden Ny tillgänglighetsgrupp/Guiden Lägg till databas i tillgänglighetsgrupp: Alternativet Fullständig stöds inte (på sidan Välj inledande datasynkronisering (Always On-tillgänglighetsgrupp-guider)).

  • RESTORE WITH MOVE: Om du vill skapa de sekundära databaserna måste databasfilerna återställas med MOVE på varje instans av SQL Server som har en sekundär replik.

  • Påverkan på tilläggsfilsåtgärder: En senare tilläggsfilåtgärd på den primära repliken kan misslyckas på de sekundära databaserna. Det här felet kan göra att de sekundära databaserna pausas. Detta leder i sin tur till att de sekundära replikerna hamnar i tillståndet inte synkroniserade.

    Not

    Information om hur du hanterar en misslyckad ad-fil-åtgärd finns i Felsökning av en misslyckad Add-File-åtgärd (AlwaysOn-tillgänglighetsgrupper).

• Du kan inte släppa en databas som för närvarande tillhör en tillgänglighetsgrupp.

Uppföljning av TDE-skyddade databaser

Om du använder transparent datakryptering (TDE) måste certifikatet eller den asymmetriska nyckeln för att skapa och dekryptera andra nycklar vara samma på varje serverinstans som är värd för en tillgänglighetsreplik för tillgänglighetsgruppen. Mer information finns i Flytta en TDE-skyddad databas till en annan SQL Server-.

Behörigheter (tillgänglighetsdatabaser)

Kräver ALTER-behörighet för databasen.

Relaterade uppgifter (tillgänglighetsdatabaser)

Relaterat innehåll

• Microsoft SQL Server Always On Solutions Guide för hög tillgänglighet och katastrofåterställning
• SQL Server Always On Team Blog: Den officiella SQL Server Always On Team-bloggen
• AlwaysOn – HADRON Learning Series: Användning av arbetspooler för HADRON-aktiverade databaser
• Vad är en AlwaysOn-tillgänglighetsgrupp?
• Failover-klustring och Always On-tillgänglighetsgrupper (SQL Server)
• Stöd för drivrutin och klientanslutning för tillgänglighetsgrupper