Herstel na noodgevallen instellen voor SQL Server

Artikel
03/08/2024

In dit artikel wordt beschreven hoe u de BACK-end van SQL Server van een toepassing kunt beveiligen. U doet dit met behulp van een combinatie van BCDR-technologieën (Business Continuity and Disaster Recovery) van SQL Server en Azure Site Recovery.

Voordat u begint, moet u de mogelijkheden voor herstel na noodgevallen van SQL Server begrijpen. Hierbij gaat het onder andere om de volgende mogelijkheden:

Failoverclustering
AlwaysOn-beschikbaarheidsgroepen
Databasespiegeling
Back-upfunctie voor logboekbestanden
Actieve geo-replicatie
Automatische failover-groepen

BCDR-technologieën combineren met Site Recovery

Uw keuze voor een BCDR-technologie voor het herstellen van SQL Server-exemplaren moet zijn gebaseerd op uw RTO-behoeften (Recovery Time Objective) en RPO (Recovery Point Objective), zoals beschreven in de volgende tabel. Combineer Site Recovery met de failoverbewerking van uw gekozen technologie om het herstel van uw hele toepassing te organiseren.

Implementatietype	BCDR-technologie	Verwachte RTO voor SQL Server	Verwachte RPO voor SQL Server
SQL Server op een virtuele IaaS-machine (Infrastructure as a Service) of on-premises.	AlwaysOn-beschikbaarheidsgroep	De tijd die nodig is om de secundaire replica als primair te maken.	Omdat replicatie naar de secundaire replica asynchroon is, is er sprake van gegevensverlies.
SQL Server op een Azure IaaS-VM of on-premises.	Failoverclustering (Always On FCI)	De tijd die nodig is om een failover uit te schakelen tussen de knooppunten.	Omdat Always On FCI gebruikmaakt van gedeelde opslag, is dezelfde weergave van het opslagexemplaar beschikbaar bij failover.
SQL Server op een Azure IaaS-VM of on-premises.	Databasespiegeling (modus met hoge prestaties)	De tijd die nodig is om de service af te dwingen, die gebruikmaakt van de mirror-server als een warme stand-byserver.	Replicatie is asynchroon. De mirrordatabase kan iets achterblijven bij de hoofddatabase. De vertraging is meestal klein. Maar het kan groot worden als het systeem van de principal of mirrorserver zwaar wordt belast. Logboekverzending kan een aanvulling zijn op databasespiegeling. Het is een gunstig alternatief voor asynchrone databasespiegeling.
SQL as a Service (PaaS) in Azure. Dit implementatietype omvat individuele databases en elastische pools.	Actieve geo-replicatie	30 seconden nadat de failover is geactiveerd. Wanneer failover wordt geactiveerd voor een van de secundaire databases, worden alle andere secundaire databases automatisch gekoppeld aan de nieuwe primaire database.	RPO van vijf seconden. Actieve geo-replicatie maakt gebruik van de AlwaysOn-technologie van SQL Server. Het repliceert asynchroon vastgelegde transacties op de primaire database naar een secundaire database met behulp van momentopname-isolatie. De secundaire gegevens hebben gegarandeerd nooit gedeeltelijke transacties.
SQL als PaaS geconfigureerd met actieve geo-replicatie in Azure. Dit implementatietype omvat beheerde exemplaren, elastische pools en individuele databases.	Automatische failover-groepen	RTO van één uur.	RPO van vijf seconden. Groepen voor automatische failover bieden de groepssemantiek boven op actieve geo-replicatie. Maar hetzelfde asynchrone replicatiemechanisme wordt gebruikt.
SQL Server op een Azure IaaS-VM of on-premises.	Replicatie met Azure Site Recovery	RTO is doorgaans minder dan 15 minuten. Lees de RTO SLA van Site Recovery voor meer informatie.	Eén uur voor toepassingsconsistentie en vijf minuten voor crashconsistentie. Als u op zoek bent naar een lagere RPO, gebruikt u andere BCDR-technologieën.

Notitie

Enkele belangrijke overwegingen bij het beveiligen van SQL-workloads met Site Recovery:

Site Recovery is toepassingsneutraal. Site Recovery kan helpen bij het beveiligen van elke versie van SQL Server die is geïmplementeerd op een ondersteund besturingssysteem. Zie de ondersteuningsmatrix voor herstel van gerepliceerde machines voor meer informatie.
U kunt ervoor kiezen om Site Recovery te gebruiken voor elke implementatie in Azure, Hyper-V, VMware of fysieke infrastructuur. Volg de richtlijnen aan het einde van dit artikel over het beveiligen van een SQL Server-cluster met Site Recovery.
Zorg ervoor dat de waargenomen snelheid van gegevenswijziging op de machine binnen de Site Recovery-limieten valt. De wijzigingssnelheid wordt gemeten in schrijfbytes per seconde. Voor computers met Windows kunt u deze wijzigingssnelheid bekijken door het tabblad Prestaties in Taakbeheer te selecteren. Bekijk de schrijfsnelheid voor elke schijf.
Site Recovery ondersteunt replicatie van failoverclusterexemplaren op Opslagruimten Direct. Zie voor meer informatie hoe u Opslagruimten Directe replicatie inschakelt.

Wanneer u uw SQL-workload naar Azure migreert, wordt u aangeraden de prestatierichtlijnen voor SQL Server op Virtuele Azure-machines toe te passen.

Herstel na noodgevallen van een toepassing

Site Recovery organiseert de testfailover en de failover van uw hele toepassing met behulp van herstelplannen.

Er zijn enkele vereisten om ervoor te zorgen dat uw herstelplan volledig is aangepast aan uw behoeften. Elke SQL Server-implementatie heeft doorgaans een Active Directory-implementatie nodig. Er is ook verbinding nodig voor uw toepassingslaag.

Stap 1: Active Directory instellen

Active Directory instellen op de secundaire herstelsite zodat SQL Server correct kan worden uitgevoerd.

Kleine ondernemingen: u hebt een paar toepassingen en één domeincontroller voor de on-premises site. Als u een failover wilt uitvoeren voor de hele site, gebruikt u Site Recovery-replicatie. Met deze service wordt de domeincontroller gerepliceerd naar het secundaire datacenter of naar Azure.
Middelgrote tot grote ondernemingen: mogelijk moet u extra domeincontrollers instellen.
- Als u een groot aantal toepassingen hebt, een Active Directory-forest hebt en een failover wilt uitvoeren per toepassing of workload, moet u een andere domeincontroller instellen in het secundaire datacenter of in Azure.
- Als u AlwaysOn-beschikbaarheidsgroepen gebruikt om te herstellen naar een externe site, stelt u een andere domeincontroller in op de secundaire site of in Azure. Deze domeincontroller wordt gebruikt voor het herstelde SQL Server-exemplaar.

In de instructies in dit artikel wordt ervan uitgegaan dat een domeincontroller beschikbaar is op de secundaire locatie. Zie de procedures voor het beveiligen van Active Directory met Site Recovery voor meer informatie.

Stap 2: Connectiviteit met andere lagen garanderen

Nadat de databaselaag wordt uitgevoerd in de Azure-doelregio, moet u ervoor zorgen dat u verbinding hebt met de toepassings- en weblagen. Voer de benodigde stappen uit om de connectiviteit met testfailover te valideren.

Zie de volgende voorbeelden voor meer informatie over het ontwerpen van toepassingen voor connectiviteitsoverwegingen:

Stap 3: Samenwerken met AlwaysOn, actieve geo-replicatie en groepen voor automatische failover

BCDR-technologieën AlwaysOn, actieve geo-replicatie en groepen voor automatische failover hebben secundaire replica's van SQL Server die worden uitgevoerd in de Azure-doelregio. De eerste stap voor de failover van uw toepassing is het opgeven van deze replica als primair. In deze stap wordt ervan uitgegaan dat u al een domeincontroller in de secundaire hebt. De stap is mogelijk niet nodig als u ervoor kiest om een automatische failover uit te voeren. Voer alleen een failover uit van uw web- en toepassingslagen nadat de databasefailover is voltooid.

Notitie

Als u de SQL-machines hebt beveiligd met Site Recovery, hoeft u alleen een herstelgroep van deze machines te maken en de failover toe te voegen in het herstelplan.

Maak een herstelplan met virtuele machines voor toepassingen en weblagen. De volgende stappen laten zien hoe u failover van de databaselaag toevoegt:

Importeer de scripts om een failover uit te voeren voor sql-beschikbaarheidsgroep in zowel een virtuele Resource Manager-machine als een klassieke virtuele machine. Importeer de scripts in uw Azure Automation-account.
Voeg het ASR-SQL-FailoverAG-script toe als een preactie van de eerste groep van het herstelplan.
Volg de instructies die beschikbaar zijn in het script om een automatiseringsvariabele te maken. Deze variabele bevat de naam van de beschikbaarheidsgroepen.

Stap 4: Een testfailover uitvoeren

Sommige BCDR-technologieën, zoals SQL Always On, bieden geen systeemeigen ondersteuning voor testfailover. We raden de volgende methode alleen aan wanneer u dergelijke technologieën gebruikt.

Stel Azure Backup in op de virtuele machine die als host fungeert voor de replica van de beschikbaarheidsgroep in Azure.
Voordat u een testfailover van het herstelplan activeert, herstelt u de VM van de back-up die u in de vorige stap hebt gemaakt.
Forceer een quorum in de VIRTUELE machine die is hersteld vanuit een back-up.
Werk het IP-adres van de listener bij als een adres dat beschikbaar is in het testfailovernetwerk.
Breng de listener online.
Zorg ervoor dat de load balancer in het failovernetwerk één IP-adres heeft, van de front-end-IP-adresgroep die overeenkomt met elke listener voor beschikbaarheidsgroepen en met de SQL Server-VM in de back-endpool.
Voeg in latere herstelgroepen failover toe van uw toepassingslaag, gevolgd door uw weblaag voor dit herstelplan.
Voer een testfailover uit van het herstelplan om end-to-end-failover van uw toepassing te testen.

Stappen voor het uitvoeren van een failover

Nadat u het script in stap 3 hebt toegevoegd en het in stap 4 hebt gevalideerd, kunt u een failover uitvoeren van het herstelplan dat u in stap 3 hebt gemaakt.

De failoverstappen voor toepassings- en weblagen moeten hetzelfde zijn in zowel testfailover als failoverherstelplannen.

Een SQL Server-cluster beveiligen

Voor een cluster met SQL Server Standard edition of SQL Server 2008 R2 raden we u aan Site Recovery-replicatie te gebruiken om SQL Server te beveiligen.

Azure naar Azure en on-premises naar Azure

Site Recovery biedt geen ondersteuning voor gastclusters bij het repliceren naar een Azure-regio. SQL Server Standard Edition biedt ook geen voordelige oplossing voor herstel na noodgevallen. In dit scenario raden we u aan het SQL Server-cluster te beveiligen op een zelfstandig SQL Server-exemplaar op de primaire locatie en het te herstellen in de secundaire locatie.

Configureer een ander zelfstandig SQL Server-exemplaar in de primaire Azure-regio of op de on-premises site.
Configureer het exemplaar als een spiegel voor de databases die u wilt beveiligen. Spiegeling configureren in de modus voor hoge veiligheid.
Configureer Site Recovery op de primaire site voor Azure-, Hyper-V- of VMware-VM's en fysieke servers.
Gebruik Site Recovery-replicatie om het nieuwe SQL Server-exemplaar te repliceren naar de secundaire site. Omdat het een spiegelkopie met hoge veiligheid is, wordt deze gesynchroniseerd met het primaire cluster, maar gerepliceerd met behulp van Site Recovery-replicatie.

Overwegingen voor failback

Voor SQL Server Standard-clusters is voor failback na een niet-geplande failover een BACK-up en herstel van SQL Server vereist. Deze bewerking wordt uitgevoerd van het spiegelexemplaren naar het oorspronkelijke cluster met het opnieuw instellen van de spiegel.

Veelgestelde vragen

Hoe krijgt SQL Server een licentie wanneer deze wordt gebruikt met Site Recovery?

Site Recovery-replicatie voor SQL Server valt onder het herstel na noodgevallen van Software Assurance. Deze dekking is van toepassing op alle Site Recovery-scenario's: on-premises voor herstel na noodgevallen van Azure en regiooverschrijdende Azure IaaS-herstel na noodgevallen. Zie prijzen voor Azure Site Recovery voor meer informatie.

Ondersteunt Site Recovery mijn SQL Server-versie?

Site Recovery is toepassingsneutraal. Site Recovery kan helpen bij het beveiligen van elke versie van SQL Server die is geïmplementeerd op een ondersteund besturingssysteem. Zie de ondersteuningsmatrix voor herstel van gerepliceerde machines voor meer informatie.

Werkt Azure Site Recovery met transactionele SQL-replicatie?

Vanwege Azure Site Recovery met behulp van kopie op bestandsniveau kan SQL niet garanderen dat de servers in een bijbehorende SQL-replicatietopologie worden gesynchroniseerd op het moment van azure Site Recovery-failover. Dit kan ertoe leiden dat de logboeklezer en/of distributieagents mislukken omdat LSN niet overeenkomt, waardoor de replicatie kan worden verbroken. Als u een failover uitvoert van de uitgever, distributeur of abonnee in een replicatietopologie, moet u de replicatie opnieuw opbouwen. Het is raadzaam om het abonnement opnieuw te initialiseren op SQL Server.

Volgende stappen

Meer informatie over de Site Recovery-architectuur.
Voor SQL Server in Azure vindt u meer informatie over oplossingen voor hoge beschikbaarheid voor herstel in een secundaire Azure-regio.
Voor SQL Database vindt u meer informatie over de opties voor bedrijfscontinuïteit en hoge beschikbaarheid voor herstel in een secundaire Azure-regio.
Voor ON-premises SQL Server-machines vindt u meer informatie over de opties voor hoge beschikbaarheid voor herstel in Azure Virtual Machines.

Delen via