Bedrijfscontinuïteit en HADR voor SQL Server op virtuele Azure-machines

Van toepassing op: SQL Server op Azure VM

Bedrijfscontinuïteit betekent dat u uw bedrijf kunt voortzetten in het geval van een noodgeval, het plannen van herstel en ervoor zorgt dat uw gegevens maximaal beschikbaar zijn. SQL Server op Azure Virtual Machines kan helpen de kosten van een HADR-databaseoplossing (High Availability and Disaster Recovery) te verlagen.

De meeste SQL Server HADR-oplossingen worden ondersteund op virtuele machines (VM's), als zowel Azure-only als hybride oplossingen. In een azure-oplossing wordt het hele HADR-systeem uitgevoerd in Azure. In een hybride configuratie wordt een deel van de oplossing uitgevoerd in Azure en wordt het andere onderdeel on-premises uitgevoerd in uw organisatie. Dankzij de flexibiliteit van de Azure-omgeving kunt u gedeeltelijk of volledig naar Azure gaan om te voldoen aan de budget- en HADR-vereisten van uw SQL Server-databasesystemen.

Dit artikel vergelijkt en contrasteert de oplossingen voor bedrijfscontinuïteit die beschikbaar zijn voor SQL Server op Virtuele Azure-machines.

Overzicht

Het is aan u om ervoor te zorgen dat uw databasesysteem beschikt over de HADR-mogelijkheden die de SLA (Service Level Agreement) vereist. Het feit dat Azure mechanismen voor hoge beschikbaarheid biedt, zoals serviceherstel voor cloudservices en detectie van herstel na fouten voor virtuele machines, garandeert niet zelf dat u aan de SLA kunt voldoen. Hoewel deze mechanismen helpen bij het beveiligen van de hoge beschikbaarheid van de virtuele machine, beschermen ze de beschikbaarheid van SQL Server die in de VIRTUELE machine wordt uitgevoerd niet.

Het is mogelijk dat het SQL Server-exemplaar mislukt terwijl de virtuele machine online en in orde is. Zelfs de mechanismen voor hoge beschikbaarheid van Azure zorgen voor downtime van de VM's vanwege gebeurtenissen zoals herstel van software- of hardwarefouten en upgrades van het besturingssysteem.

Geografisch redundante opslag (GRS) in Azure wordt geïmplementeerd met een functie met de naam geo-replicatie. GRS is mogelijk geen geschikte oplossing voor herstel na noodgevallen voor uw databases. Omdat geo-replicatie gegevens asynchroon verzendt, kunnen recente updates verloren gaan in een noodgeval. Meer informatie over beperkingen voor geo-replicatie vindt u in de sectie Ondersteuning voor geo-replicatie.

Notitie

Het is nu mogelijk om uw failoverclusterexemplaren en beschikbaarheidsgroepoplossing te verplaatsen naar SQL Server op Azure-VM's met behulp van Azure Migrate.

Implementatiearchitecturen

ondersteuning voor Azure deze SQL Server-technologieën voor bedrijfscontinuïteit:

• AlwaysOn-beschikbaarheidsgroepen
• AlwaysOn-failoverclusterexemplaren (CFA's)
• Logboekverzending
• Back-up en herstel van SQL Server met Azure Blob Storage
• Databasespiegeling - afgeschaft in SQL Server 2016
• Azure Site Recovery

U kunt de technologieën combineren voor het implementeren van een SQL Server-oplossing met zowel hoge beschikbaarheid als mogelijkheden voor herstel na noodgevallen. Afhankelijk van de technologie die u gebruikt, is voor een hybride implementatie mogelijk een VPN-tunnel met het virtuele Azure-netwerk vereist. In de volgende secties ziet u enkele voorbeeldimplementatiearchitecturen.

Alleen Azure: oplossingen voor hoge beschikbaarheid

U kunt een oplossing voor hoge beschikbaarheid voor SQL Server hebben op databaseniveau met AlwaysOn-beschikbaarheidsgroepen. U kunt ook een oplossing voor hoge beschikbaarheid maken op exemplaarniveau met AlwaysOn-failoverclusterexemplaren. Voor extra beveiliging kunt u redundantie op beide niveaus maken door beschikbaarheidsgroepen te maken op failoverclusterexemplaren.

Technologie	Voorbeeldarchitecturen
Beschikbaarheidsgroepen	Beschikbaarheidsreplica's die worden uitgevoerd in Virtuele Azure-machines in dezelfde regio bieden hoge beschikbaarheid. U moet een domeincontroller-VM configureren, omdat Voor Windows-failoverclustering een Active Directory-domein is vereist. Voor hogere redundantie en beschikbaarheid kunnen de Azure-VM's worden geïmplementeerd in verschillende beschikbaarheidszones, zoals beschreven in het overzicht van de beschikbaarheidsgroep. Raadpleeg de zelfstudie over de beschikbaarheidsgroep om aan de slag te gaan.
Exemplaren van failoverclusters	Failoverclusterexemplaren worden ondersteund op SQL Server-VM's. Omdat voor de FCI-functie gedeelde opslag is vereist, werken vijf oplossingen met SQL Server op Azure-VM's: - Gedeelde Azure-schijven gebruiken voor Windows Server 2019. Gedeelde beheerde schijven zijn een Azure-product waarmee een beheerde schijf tegelijkertijd aan meerdere virtuele machines kan worden gekoppeld. VM's in het cluster kunnen lezen of schrijven naar de gekoppelde schijf op basis van de reservering die is gekozen door de geclusterde toepassing via permanente SCSI-reserveringen (SCSI PR). SCSI PR is een industriestandaard opslagoplossing die wordt gebruikt door toepassingen die on-premises worden uitgevoerd op een SAN (Storage Area Network). Als u SCSI-pull inschakelt op een beheerde schijf, kunt u deze toepassingen naar Azure migreren zoals dat is. - Het gebruik van Opslagruimten Direct (S2D) om een op software gebaseerd virtueel SAN voor Windows Server 2016 en hoger te bieden. - Een Premium-bestandsshare gebruiken voor Windows Server 2012 en hoger. Premium-bestandsshares worden ondersteund door SSD, hebben consistent lage latentie en worden volledig ondersteund voor gebruik met FCI. - Opslag gebruiken die wordt ondersteund door een partneroplossing voor clustering. Zie het blogbericht Failoverclustering en SIOS DataKeeper voor een specifiek voorbeeld dat gebruikmaakt van SIOS DataKeeper. - Gedeelde blokopslag gebruiken voor een extern iSCSI-doel via Azure ExpressRoute. NetApp Private Storage (NPS) biedt bijvoorbeeld een iSCSI-doel aan voor Azure-VM's via ExpressRoute met Equinix. In het geval van oplossingen van Microsoft-partners voor gedeelde opslag en gegevensreplicatie neemt u contact op met de leverancier als er problemen zijn met de toegang tot gegevens bij failover. Bereid uw VIRTUELE machine voor op FCI om aan de slag te gaan

Alleen Azure: oplossingen voor herstel na noodgevallen

U kunt een noodhersteloplossing voor uw SQL Server-databases in Azure hebben met behulp van beschikbaarheidsgroepen, databasespiegeling of back-up en herstel met opslagblobs.

Technologie	Voorbeeldarchitecturen
Beschikbaarheidsgroepen	Beschikbaarheidsreplica's die worden uitgevoerd in meerdere datacenters in Azure-VM's voor herstel na noodgevallen. Deze oplossing voor meerdere regio's helpt u te beschermen tegen een volledige site-storing. Binnen een regio moeten alle replica's zich binnen dezelfde cloudservice en hetzelfde virtuele netwerk bevinden. Omdat elke regio een afzonderlijk virtueel netwerk heeft, is voor deze oplossingen netwerk-naar-netwerkconnectiviteit vereist. Zie Een netwerk-naar-netwerkverbinding configureren met behulp van Azure Portal voor meer informatie. Zie Een SQL Server AlwaysOn-beschikbaarheidsgroep configureren in verschillende Azure-regio's voor gedetailleerde instructies.
Databasespiegeling	Principal en mirror en servers die worden uitgevoerd in verschillende datacenters voor herstel na noodgevallen. U moet ze implementeren met behulp van servercertificaten.
Back-up maken en herstellen met Azure Blob Storage	Er wordt rechtstreeks een back-up gemaakt van productiedatabases naar Blob Storage in een ander datacenter voor herstel na noodgevallen. Zie Back-up en herstel voor SQL Server op Azure-VM's voor meer informatie.
SQL Server repliceren en een failover uitvoeren naar Azure met Azure Site Recovery	Productie-SQL Server-exemplaar in één Azure-datacenter dat rechtstreeks wordt gerepliceerd naar Azure Storage in een ander Azure-datacenter voor herstel na noodgevallen. Zie SQL Server beveiligen met behulp van HERSTEL na noodgevallen van SQL Server en Azure Site Recovery voor meer informatie.

Hybride IT: oplossingen voor herstel na noodgevallen

U kunt een noodhersteloplossing voor uw SQL Server-databases in een hybride IT-omgeving hebben met behulp van beschikbaarheidsgroepen, databasespiegeling, logboekverzending en back-up en herstel met Azure Blob Storage.

Technologie	Voorbeeldarchitecturen
Beschikbaarheidsgroepen	Sommige beschikbaarheidsreplica's die worden uitgevoerd op Virtuele Azure-machines en andere replica's die on-premises worden uitgevoerd voor herstel na noodgevallen op meerdere locaties. De productiesite kan on-premises of in een Azure-datacenter zijn. Omdat alle beschikbaarheidsreplica's zich in hetzelfde failovercluster moeten bevinden, moet het cluster beide netwerken (een failovercluster met meerdere subnetten) omvatten. Voor deze configuratie is een VPN-verbinding tussen Azure en het on-premises netwerk vereist. Voor een geslaagd herstel na noodgevallen van uw databases moet u ook een replicadomeincontroller installeren op de site voor herstel na noodgevallen. Raadpleeg de zelfstudie over de beschikbaarheidsgroep om aan deslag te gaan.
Databasespiegeling	Eén partner die wordt uitgevoerd op een Virtuele Azure-machine en de andere die on-premises wordt uitgevoerd voor herstel na noodgevallen tussen sites met behulp van servercertificaten. Partners hoeven zich niet in hetzelfde Active Directory-domein te bevinden en er is geen VPN-verbinding vereist. Een ander scenario voor databasespiegeling omvat één partner die wordt uitgevoerd op een Azure-VM en de andere die on-premises wordt uitgevoerd in hetzelfde Active Directory-domein voor herstel na noodgevallen tussen sites. Er is een VPN-verbinding tussen het virtuele Azure-netwerk en het on-premises netwerk vereist. Voor een geslaagd herstel na noodgevallen van uw databases moet u ook een replicadomeincontroller installeren op de site voor herstel na noodgevallen.
Logboekverzending	De ene server die wordt uitgevoerd op een Virtuele Azure-machine en de andere server die on-premises wordt uitgevoerd voor herstel na noodgevallen op meerdere locaties. De verzending van logboeken is afhankelijk van het delen van Windows-bestanden, dus een VPN-verbinding tussen het virtuele Azure-netwerk en het on-premises netwerk is vereist. Voor een geslaagd herstel na noodgevallen van uw databases moet u ook een replicadomeincontroller installeren op de site voor herstel na noodgevallen.
Back-up maken en herstellen met Azure Blob Storage	Er is rechtstreeks een back-up gemaakt van on-premises productiedatabases naar Azure Blob Storage voor herstel na noodgevallen. Zie Back-up en herstel voor SQL Server op virtuele Azure-machines voor meer informatie.
SQL Server repliceren en een failover uitvoeren naar Azure met Azure Site Recovery	On-premises SQL Server-exemplaar voor productie is rechtstreeks gerepliceerd naar Azure Storage voor herstel na noodgevallen. Zie SQL Server beveiligen met behulp van HERSTEL na noodgevallen van SQL Server en Azure Site Recovery voor meer informatie.

Gratis DR-replica in Azure

Als u Software Assurance hebt, kunt u hybride noodherstelplannen (DR) implementeren met SQL Server zonder extra licentiekosten te maken voor het passieve noodherstelexemplaren. U komt ook in aanmerking voor dr-replica's zonder licentie met betalen per gebruik-licentie als alle replica's worden gehost in Azure.

U kunt bijvoorbeeld twee gratis passieve secundaire secundaire databases hebben wanneer alle drie de replica's worden gehost in Azure:

U kunt ook een hybride failover-omgeving configureren, met een primaire on-premises licentie, één gratis passief voor hoge beschikbaarheid, één gratis passief voor dr on-premises en één gratis passief voor dr in Azure:

Zie de licentievoorwaarden voor producten voor meer informatie.

Als u dit voordeel wilt inschakelen, gaat u naar de resource van uw virtuele SQL Server-machine. Selecteer Configureren onder Instellingen en kies vervolgens de optie HA/DR onder SQL Server-licentie. Schakel het selectievakje in om te bevestigen dat deze VIRTUELE SQL Server-machine wordt gebruikt als passieve replica en selecteer Vervolgens Toepassen om uw instellingen op te slaan. Wanneer alle drie de replica's worden gehost in Azure, hebben klanten met betalen per gebruik ook recht op het gebruik van het licentietype HA/DR .

Belangrijke overwegingen voor SQL Server HADR in Azure

Virtuele Azure-machines, opslag en netwerken hebben verschillende operationele kenmerken dan een on-premises, niet-gevirtualiseerde IT-infrastructuur. Een geslaagde implementatie van een HADR SQL Server-oplossing in Azure vereist dat u deze verschillen begrijpt en uw oplossing ontwerpt om deze te kunnen gebruiken.

Knooppunten met hoge beschikbaarheid in een beschikbaarheidsset

Met beschikbaarheidssets in Azure kunt u de knooppunten met hoge beschikbaarheid in afzonderlijke foutdomeinen plaatsen en domeinen bijwerken. Het Azure-platform wijst een updatedomein en een foutdomein toe aan elke virtuele machine in uw beschikbaarheidsset. Deze configuratie binnen een datacenter zorgt ervoor dat tijdens een geplande of ongeplande onderhoudsgebeurtenis ten minste één virtuele machine beschikbaar is en voldoet aan de Azure SLA van 99,95 procent.

Als u een installatie met hoge beschikbaarheid wilt configureren, plaatst u alle deelnemende virtuele SQL Server-machines in dezelfde beschikbaarheidsset om toepassings- of gegevensverlies tijdens een onderhoudsgebeurtenis te voorkomen. Alleen knooppunten in dezelfde cloudservice kunnen deelnemen aan dezelfde beschikbaarheidsset. Zie voor meer informatie De beschikbaarheid van virtuele machines beheren.

Knooppunten met hoge beschikbaarheid in een beschikbaarheidszone

Beschikbaarheidszones zijn unieke, fysieke locaties binnen een Azure-regio. Elke zone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke voeding, koeling en netwerken. De fysieke scheiding van beschikbaarheidszones binnen een regio helpt toepassingen en gegevens te beschermen tegen datacenterfouten door ervoor te zorgen dat ten minste één virtuele machine beschikbaar is en voldoet aan de Azure SLA van 99,99 procent.

Als u hoge beschikbaarheid wilt configureren, plaatst u deelnemende virtuele SQL Server-machines verspreid over beschikbaarheidszones in de regio. Er worden extra kosten in rekening gebracht voor netwerk-naar-netwerkoverdracht tussen beschikbaarheidszones. Zie Beschikbaarheidszones voor meer informatie.

Netwerklatentie in hybride IT

Implementeer uw HADR-oplossing met de veronderstelling dat er perioden van hoge netwerklatentie tussen uw on-premises netwerk en Azure kunnen zijn. Wanneer u replica's implementeert in Azure, gebruikt u asynchrone doorvoer in plaats van synchrone doorvoer voor de synchronisatiemodus. Wanneer u databasespiegelingsservers zowel on-premises als in Azure implementeert, gebruikt u de modus met hoge prestaties in plaats van de modus voor hoge veiligheid.

Zie de best practices voor HADR-configuratie voor cluster- en HADR-instellingen die u kunnen helpen bij de cloudomgeving.

Ondersteuning voor geo-replicatie

Geo-replicatie in Azure-schijven biedt geen ondersteuning voor het gegevensbestand en logboekbestand van dezelfde database die moeten worden opgeslagen op afzonderlijke schijven. GRS repliceert wijzigingen op elke schijf onafhankelijk en asynchroon. Dit mechanisme garandeert de schrijfvolgorde binnen één schijf op de geo-gerepliceerde kopie, maar niet op geo-gerepliceerde kopieën van meerdere schijven. Als u een database configureert voor het opslaan van het gegevensbestand en het logboekbestand op afzonderlijke schijven, bevatten de herstelde schijven na een noodgeval mogelijk een recentere kopie van het gegevensbestand dan het logboekbestand, waardoor het write-ahead-logboek in SQL Server en de ACID-eigenschappen (atomiciteit, consistentie, isolatie en duurzaamheid) van transacties worden verbroken.

Als u geen optie hebt om geo-replicatie uit te schakelen voor het opslagaccount, bewaart u alle gegevens en logboekbestanden voor een database op dezelfde schijf. Als u meer dan één schijf moet gebruiken vanwege de grootte van de database, implementeert u een van de eerder vermelde oplossingen voor herstel na noodgevallen om gegevensredundantie te garanderen.

Volgende stappen

Bepaal of een beschikbaarheidsgroep of een exemplaar van een failovercluster de beste bedrijfscontinuïteitsoplossing voor uw bedrijf is. Bekijk vervolgens de aanbevolen procedures voor het configureren van uw omgeving voor hoge beschikbaarheid en herstel na noodgevallen.