Konfigurera haveriberedskap för SQL Server

Artikel
03/10/2024

Den här artikeln beskriver hur du skyddar SQL Server-serverdelen för ett program. Du gör det med hjälp av en kombination av TEKNIKER för affärskontinuitet och haveriberedskap för SQL Server (BCDR) och Azure Site Recovery.

Kontrollera att du förstår funktionerna för haveriberedskap i SQL Server innan du börjar. Dessa funktioner omfattar:

Redundansklustring
AlwaysOn-tillgänglighetsgrupper
Databasspegling
Loggöverföring
Aktiv geo-replikering
Automatiska redundansgrupper

Kombinera BCDR-tekniker med Site Recovery

Ditt val av BCDR-teknik för att återställa SQL Server-instanser bör baseras på dina mål för återställningstid (RTO) och mål för återställningspunkt (RPO) enligt beskrivningen i följande tabell. Kombinera Site Recovery med redundansåtgärden för den valda tekniken för att orkestrera återställningen av hela programmet.

Distributionstyp	BCDR-teknik	Förväntad RTO för SQL Server	Förväntat RPO för SQL Server
SQL Server på en virtuell IaaS-dator (Azure Infrastructure as a Service) eller lokalt.	Always On-tillgänglighetsgrupp	Den tid det tar att göra den sekundära repliken till primär.	Eftersom replikeringen till den sekundära repliken är asynkron går det inte att förlora data.
SQL Server på en virtuell Azure IaaS-dator eller lokalt.	Redundansklustring (Always On FCI)	Den tid det tar att redundansväxla mellan noderna.	Eftersom Always On FCI använder delad lagring är samma vy av lagringsinstansen tillgänglig vid redundansväxling.
SQL Server på en virtuell Azure IaaS-dator eller lokalt.	Databasspegling (högpresterande läge)	Den tid det tar att tvinga tjänsten, som använder speglingsservern som en varm väntelägesserver.	Replikeringen är asynkron. Speglingsdatabasen kan ligga något efter huvuddatabasen. Fördröjningen är vanligtvis liten. Men det kan bli stort om huvud- eller speglingsserverns system är hårt belastat. Loggleverans kan vara ett tillägg till databasspegling. Det är ett bra alternativ till asynkron databasspegling.
SQL som plattform som en tjänst (PaaS) i Azure. Den här distributionstypen innehåller enskilda databaser och elastiska pooler.	Aktiv geo-replikering	30 sekunder efter att redundansväxlingen har utlösts. När redundansväxling aktiveras för en av de sekundära databaserna länkas alla andra sekundärfiler automatiskt till den nya primära databasen.	RPO på fem sekunder. Aktiv geo-replikering använder AlwaysOn-tekniken för SQL Server. Den replikerar asynkront incheckade transaktioner på den primära databasen till en sekundär databas med hjälp av ögonblicksbildisolering. Sekundära data kommer garanterat aldrig att ha partiella transaktioner.
SQL som PaaS konfigurerat med aktiv geo-replikering i Azure. Den här distributionstypen innehåller en hanterad instans, elastiska pooler och enskilda databaser.	Automatiska redundansgrupper	RTO på en timme.	RPO på fem sekunder. Grupper för automatisk redundans tillhandahåller gruppsemantik ovanpå aktiv geo-replikering. Men samma asynkrona replikeringsmekanism används.
SQL Server på en virtuell Azure IaaS-dator eller lokalt.	Replikering med Azure Site Recovery	RTO är vanligtvis mindre än 15 minuter. Mer information finns i RTO SLA som tillhandahålls av Site Recovery.	En timme för programkonsekvens och fem minuter för kraschkonsekvens. Om du letar efter lägre RPO använder du andra BCDR-tekniker.

Kommentar

Några viktiga överväganden när du hjälper till att skydda SQL-arbetsbelastningar med Site Recovery:

Site Recovery är programagnostisk. Site Recovery kan hjälpa till att skydda alla versioner av SQL Server som distribueras på ett operativsystem som stöds. Mer information finns i supportmatrisen för återställning av replikerade datorer.
Du kan välja att använda Site Recovery för alla distributioner i Azure, Hyper-V, VMware eller fysisk infrastruktur. Följ riktlinjerna i slutet av den här artikeln om hur du skyddar ett SQL Server-kluster med Site Recovery.
Se till att dataändringsfrekvensen som observeras på datorn ligger inom Site Recovery-gränserna. Ändringsfrekvensen mäts i skrivbyte per sekund. För datorer som kör Windows kan du visa den här ändringsfrekvensen genom att välja fliken Prestanda i Aktivitetshanteraren. Observera skrivhastigheten för varje disk.
Site Recovery stöder replikering av redundansklusterinstanser på Lagringsdirigering. Mer information finns i aktivera Lagringsdirigering replikering.

När du migrerar din SQL-arbetsbelastning till Azure rekommenderar vi att du tillämpar riktlinjerna för prestanda för SQL Server på virtuella Azure-datorer.

Haveriberedskap för ett program

Site Recovery samordnar redundanstestet och redundansväxlingen för hela programmet med hjälp av återställningsplaner.

Det finns vissa förutsättningar för att säkerställa att återställningsplanen är helt anpassad efter dina behov. Alla SQL Server-distributioner behöver vanligtvis en Active Directory-distribution. Den behöver också anslutning för programnivån.

Steg 1: Konfigurera Active Directory

Konfigurera Active Directory på den sekundära återställningsplatsen så att SQL Server körs korrekt.

Litet företag: Du har några program och en enda domänkontrollant för den lokala platsen. Om du vill redundansväxla hela platsen använder du Site Recovery-replikering. Den här tjänsten replikerar domänkontrollanten till det sekundära datacentret eller till Azure.
Medelstort till stort företag: Du kan behöva konfigurera ytterligare domänkontrollanter.
- Om du har ett stort antal program, har en Active Directory-skog och vill redundansväxla efter program eller arbetsbelastning konfigurerar du en annan domänkontrollant i det sekundära datacentret eller i Azure.
- Om du använder AlwaysOn-tillgänglighetsgrupper för att återställa till en fjärrplats konfigurerar du en annan domänkontrollant på den sekundära platsen eller i Azure. Den här domänkontrollanten används för den återställda SQL Server-instansen.

Anvisningarna i den här artikeln förutsätter att en domänkontrollant är tillgänglig på den sekundära platsen. Mer information finns i procedurerna för att skydda Active Directory med Site Recovery.

Steg 2: Kontrollera anslutningen till andra nivåer

När databasnivån körs i Azure-målregionen kontrollerar du att du har anslutning till program- och webbnivåerna. Vidta nödvändiga åtgärder i förväg för att verifiera anslutningen med redundanstest.

Information om hur du kan utforma program för anslutningsöverväganden finns i följande exempel:

Steg 3: Samverka med AlwaysOn, aktiva geo-replikeringsgrupper och grupper för automatisk redundans

BCDR-teknikerna AlwaysOn, aktiv geo-replikering och automatiska redundansgrupper har sekundära repliker av SQL Server som körs i azure-målregionen. Det första steget för programmets redundans är att ange den här repliken som primär. Det här steget förutsätter att du redan har en domänkontrollant i den sekundära. Steget kanske inte är nödvändigt om du väljer att göra en automatisk redundansväxling. Redundansväxla dina webb- och programnivåer först efter att databasredundansväxlingen har slutförts.

Kommentar

Om du har hjälpt till att skydda SQL-datorerna med Site Recovery behöver du bara skapa en återställningsgrupp med dessa datorer och lägga till redundansväxlingen i återställningsplanen.

Skapa en återställningsplan med virtuella datorer på program- och webbnivå. Följande steg visar hur du lägger till redundans för databasnivån:

Importera skripten för att redundansväxla SQL-tillgänglighetsgruppen på både en virtuell Resource Manager-dator och en klassisk virtuell dator. Importera skripten till ditt Azure Automation-konto.
Lägg till ASR-SQL-FailoverAG-skriptet som en förhandsåtgärd för den första gruppen i återställningsplanen.
Följ anvisningarna i skriptet för att skapa en automatiseringsvariabel. Den här variabeln innehåller namnet på tillgänglighetsgrupperna.

Steg 4: Utföra ett redundanstest

Vissa BCDR-tekniker, till exempel SQL Always On, stöder inte redundanstest. Vi rekommenderar följande metod endast när du använder sådana tekniker.

Konfigurera Azure Backup på den virtuella dator som är värd för tillgänglighetsgrupprepliken i Azure.
Innan du utlöser redundanstestet för återställningsplanen kan du återställa den virtuella datorn från den säkerhetskopia som gjordes i föregående steg.
Framtvinga ett kvorum i den virtuella datorn som återställdes från säkerhetskopian.
Uppdatera IP-adressen för lyssnaren så att den är en tillgänglig adress i redundansnätverket för test.
Ta lyssnaren online.
Se till att lastbalanseraren i redundansnätverket har en IP-adress från klientdelens IP-adresspool som motsvarar varje tillgänglighetsgrupplyssnare och med den virtuella SQL Server-datorn i serverdelspoolen.
I senare återställningsgrupper lägger du till redundans för programnivån följt av webbnivån för den här återställningsplanen.
Gör ett redundanstest för återställningsplanen för att testa redundans från slutpunkt till slutpunkt för ditt program.

Steg för att utföra en redundansväxling

När du har lagt till skriptet i steg 3 och verifierat det i steg 4 kan du göra en redundansväxling av återställningsplanen som skapades i steg 3.

Redundansstegen för program- och webbnivåer bör vara desamma i både redundanstest och återställningsplaner för redundans.

Så här skyddar du ett SQL Server-kluster

För ett kluster som kör SQL Server Standard Edition eller SQL Server 2008 R2 rekommenderar vi att du använder Site Recovery-replikering för att skydda SQL Server.

Azure till Azure och lokalt till Azure

Site Recovery tillhandahåller inte stöd för gästkluster när du replikerar till en Azure-region. SQL Server Standard Edition tillhandahåller inte heller någon lösning för haveriberedskap till låg kostnad. I det här scenariot rekommenderar vi att du skyddar SQL Server-klustret till en fristående SQL Server-instans på den primära platsen och återställer det på den sekundära platsen.

Konfigurera en annan fristående SQL Server-instans i den primära Azure-regionen eller på den lokala platsen.
Konfigurera instansen så att den fungerar som en spegling för de databaser som du vill skydda. Konfigurera spegling i högsäkerhetsläge.
Konfigurera Site Recovery på den primära platsen för virtuella Azure-, Hyper-V- eller VMware-datorer och fysiska servrar.
Använd Site Recovery-replikering för att replikera den nya SQL Server-instansen till den sekundära platsen. Eftersom det är en speglingskopia med hög säkerhet synkroniseras den med det primära klustret men replikeras med Hjälp av Site Recovery-replikering.

Överväganden för återställning efter fel

För SQL Server Standard-kluster kräver återställning efter en oplanerad redundansväxling en SQL Server-säkerhetskopiering och återställning. Den här åtgärden utförs från speglingsinstansen till det ursprungliga klustret med ometablering av speglingen.

Vanliga frågor och svar

Hur licensieras SQL Server när den används med Site Recovery?

Site Recovery-replikering för SQL Server omfattas av software assurance-haveriberedskapsförmånen. Den här täckningen gäller för alla Site Recovery-scenarier: lokalt för Haveriberedskap i Azure och haveriberedskap mellan regioner i Azure IaaS. Mer information finns i Priser för Azure Site Recovery.

Stöder Site Recovery min SQL Server-version?

Site Recovery är programagnostisk. Site Recovery kan hjälpa till att skydda alla versioner av SQL Server som distribueras på ett operativsystem som stöds. Mer information finns i supportmatrisen för återställning av replikerade datorer.

Fungerar ASR med SQL Transactional Replication?

På grund av att ASR använder kopiering på filnivå kan SQL inte garantera att servrarna i en associerad SQL-replikeringstopologi är synkroniserade vid tidpunkten för ASR-redundansväxling. Detta kan orsaka att logreader- och/eller distributionsagenterna misslyckas på grund av LSN-matchningsfel, vilket kan bryta replikeringen. Om du redundansväxlar utgivaren, distributören eller prenumeranten i en replikeringstopologi måste du återskapa replikeringen. Vi rekommenderar att du initierar om prenumerationen till SQL Server.

Nästa steg

Läs mer om Site Recovery-arkitektur.
För SQL Server i Azure kan du läsa mer om lösningar med hög tillgänglighet för återställning i en sekundär Azure-region.
För SQL Database kan du läsa mer om affärskontinuitet och alternativ för hög tillgänglighet för återställning i en sekundär Azure-region.
För SQL Server-datorer lokalt kan du läsa mer om alternativen för hög tillgänglighet för återställning i Azure Virtual Machines.