Bedrijfscontinuïteit en HADR voor SQL Server in Azure Virtual Machines
VAN TOEPASSING OP: 
SQL Server op virtuele Azure-machine
Bedrijfscontinuïteit betekent dat u uw bedrijf kunt voortzetten in het geval van een noodlottige gebeurtenis, dat u herstel plant en ervoor zorgt dat uw gegevens zeer beschikbaar zijn. SQL Server azure-Virtual Machines kunt u de kosten van een HADR-databaseoplossing (High Availability and Disaster Recovery) verlagen.
De SQL Server HADR-oplossingen worden ondersteund op virtuele machines (VM's), als zowel Azure-oplossingen als hybride oplossingen. In een alleen-Azure-oplossing wordt het hele HADR-systeem uitgevoerd in Azure. In een hybride configuratie wordt een deel van de oplossing uitgevoerd in Azure en het andere deel on-premises in uw organisatie. Dankzij de flexibiliteit van de Azure-omgeving kunt u gedeeltelijk of volledig naar Azure verplaatsen om te voldoen aan de budget- en HADR-vereisten van uw SQL Server databasesystemen.
In dit artikel worden de oplossingen voor bedrijfscontinuïteit vergeleken en vergeleken die beschikbaar zijn SQL Server azure-VM's.
Overzicht
Het is aan u om ervoor te zorgen dat uw databasesysteem beschikt over de HADR-mogelijkheden die vereist zijn voor de SLA (Service Level Agreement). Het feit dat Azure mechanismen voor hoge beschikbaarheid biedt, zoals serviceherstel voor cloudservices en detectie van foutherstel voor virtuele machines, garandeert zelf niet dat u aan de SLA kunt voldoen. Hoewel deze mechanismen helpen bij het beveiligen van de hoge beschikbaarheid van de virtuele machine, beschermen ze niet de beschikbaarheid van SQL Server worden uitgevoerd binnen de virtuele machine.
Het is mogelijk dat het SQL Server mislukt terwijl de VM online is en in orde is. Zelfs de mechanismen voor hoge beschikbaarheid van Azure maken downtime van de VM's mogelijk vanwege gebeurtenissen zoals herstel na 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 noodherstel voor uw databases. Omdat geo-replicatie gegevens asynchroon verzendt, kunnen recente updates verloren gaan in een noodscenario. Meer informatie over geo-replicatiebeperkingen vindt u in de sectie Ondersteuning voor geo-replicatie.
Notitie
Het is nu mogelijk om zowel uw failovercluster-exemplaar als de beschikbaarheidsgroepoplossing te verplaatsen naar SQL Server azure-VM's met behulp van Azure Migrate.
Implementatiearchitecten
Azure ondersteunt deze SQL Server voor bedrijfscontinuïteit:
- AlwaysOn-beschikbaarheidsgroepen
- Always On-failovercluster-exemplaren (FCIs)
- Logboekbestanden
- SQL Server back-up en herstel maken met Azure Blob Storage
- Databasespiegeling- afgeschaft in SQL Server 2016
- Azure Site Recovery
U kunt de technologieën combineren om een SQL Server oplossing te implementeren die zowel hoge beschikbaarheid als mogelijkheden voor herstel na noodgevallen heeft. 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 voorbeeldimplementatiearchitecten.
Alleen Azure: oplossingen met hoge beschikbaarheid
U kunt een oplossing voor hoge beschikbaarheid voor SQL Server databaseniveau met Always On-beschikbaarheidsgroepen. U kunt ook een oplossing voor hoge beschikbaarheid op exemplaarniveau maken met Always On-failovercluster-exemplaren. Voor extra beveiliging kunt u redundantie op beide niveaus maken door beschikbaarheidsgroepen te maken op exemplaren van failovercluster.
| Technologie | Voorbeeldarchitecten |
|---|---|
| Beschikbaarheidsgroepen | Beschikbaarheidsreplica's die worden uitgevoerd in Azure-VM's in dezelfde regio bieden hoge beschikbaarheid. U moet een domeincontroller-VM configureren, omdat Windows failoverclustering een Active Directory-domein 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. Als de SQL Server-VM's in een beschikbaarheidsgroep zijn geïmplementeerd in beschikbaarheidszones, gebruikt u Azure Standard Load Balancer voor de listener, zoals beschreven in de artikelen Azure SQL VM CLI en Azure Quickstart-sjablonen.  Zie Beschikbaarheidsgroepen configureren in Azure (GUI) voor meer informatie. |
| Exemplaren van failoverclusters | Exemplaren van failoverclusters worden ondersteund op SQL Server-VM's. Omdat voor de FCI-functie gedeelde opslag is vereist, werken vijf oplossingen met SQL Server azure-VM's: - Gedeelde Azure-schijven gebruiken voor Windows Server 2019. Gedeelde beheerde schijven zijn een Azure-product waarmee een beheerde schijf aan meerdere virtuele machines tegelijk kan worden gekoppeld. VM's in het cluster kunnen lezen of schrijven naar uw gekoppelde schijf op basis van de reservering die is gekozen door de geclusterde toepassing via SCSI Permanente reserveringen (SCSI PR). SCSI PR is een industriestandaard opslagoplossing die wordt gebruikt door toepassingen die on-premises worden uitgevoerd in een Storage Area Network (SAN). Als u SCSI-pr inschakelen op een beheerde schijf, kunt u deze toepassingen naar Azure migreren. - Gebruik Opslagruimten Direct ( S2D om ) een virtuele SAN op basis van software te bieden voor Windows Server 2016 en hoger. - Een Premium-bestands share gebruiken voor Windows Server 2012 en hoger. Premium bestands shares worden ondersteund door SSD, consistent lage latentie hebben en volledig worden ondersteund voor gebruik met FCI. - Opslag gebruiken die wordt ondersteund door een partneroplossing voor clustering. Zie het blogbericht Failoverclustering en SIOS DataKeepervoor 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. |
Alleen Azure: Oplossingen voor herstel na noodherstel
U kunt een noodhersteloplossing hebben voor uw SQL Server databases in Azure met behulp van beschikbaarheidsgroepen, databasespiegeling of back-up en herstel met opslagblobs.
| Technologie | Voorbeeldarchitecten |
|---|---|
| Beschikbaarheidsgroepen | Beschikbaarheidsreplica's die worden uitgevoerd in meerdere datacenters in Azure-VM's voor herstel na noodherstel. Deze oplossing tussen regio's helpt u te beschermen tegen een volledige storing in de site.  Binnen een regio moeten alle replica's binnen dezelfde cloudservice en hetzelfde virtuele netwerk zijn. Omdat elke regio een afzonderlijk virtueel netwerk heeft, is voor deze oplossingen netwerk-naar-netwerk-connectiviteit vereist. Zie Configure a network-to-network connection by using the Azure Portal (Een netwerk-naar-netwerk-verbinding configurerenmet behulp van de Azure Portal. Zie Configure a SQL Server Always On availability group across different Azure regions (Een Always On-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 noodherstel. U moet deze implementeren met behulp van servercertificaten. SQL Server databasespiegeling wordt niet ondersteund voor SQL Server 2008 of SQL Server 2008 R2 op een Azure-VM.  |
| Back-up en herstel met Azure Blob Storage | Productiedatabases maken rechtstreeks een back-up naar Blob-opslag in een ander datacenter voor herstel na noodherstel. Zie Backup and restore for SQL Server on Azure VMs (Back-ups maken en herstellen SQL Server azure-VM's) voor meer informatie. |
| Replicatie en fail over SQL Server naar Azure met Azure Site Recovery | Productie-SQL Server in één Azure-datacenter rechtstreeks gerepliceerd naar Azure Storage in een ander Azure-datacenter voor herstel na noodherstel. Zie Voor meer informatie Protect SQL Server using SQL Server disaster recovery and Azure Site Recovery. |
Hybride IT: Oplossingen voor herstel na noodherstel
U kunt een noodhersteloplossing hebben voor uw SQL Server-databases in een hybride IT-omgeving met behulp van beschikbaarheidsgroepen, databasespiegeling, logboekverzending en back-up en herstel met Azure Blob Storage.
| Technologie | Voorbeeldarchitecten |
|---|---|
| Beschikbaarheidsgroepen | Sommige beschikbaarheidsreplica's die worden uitgevoerd in Azure-VM's en andere replica's die on-premises worden uitgevoerd voor herstel na noodherstel tussen locaties. De productiesite kan zich on-premises of in een Azure-datacenter bevinden. Omdat alle beschikbaarheidsreplica's zich in hetzelfde failovercluster moeten hebben, moet het cluster beide netwerken overspannen (een failovercluster met meerdere subnetten). Voor deze configuratie is een VPN-verbinding tussen Azure en het on-premises netwerk vereist. Voor een geslaagd herstel na noodherstel van uw databases moet u ook een replicadomeincontroller installeren op de site voor herstel na noodherstel. |
| Databasespiegeling | De ene partner die wordt uitgevoerd op een Azure-VM en de andere partner die on-premises wordt uitgevoerd voor herstel na noodherstel tussen locaties met behulp van servercertificaten. Partners hoeven zich niet in hetzelfde Active Directory-domein te hebben en er is geen VPN-verbinding vereist. Een ander databasespiegelingsscenario omvat één partner die wordt uitgevoerd op een Azure-VM en de andere partner die on-premises wordt uitgevoerd in hetzelfde Active Directory-domein voor herstel na noodherstel op meerdere locaties. Er is een VPN-verbinding tussen het virtuele Azure-netwerk en het on-premises netwerk vereist. Voor een geslaagd herstel na noodherstel van uw databases moet u ook een replicadomeincontroller installeren op de site voor herstel na noodherstel. SQL Server databasespiegeling wordt niet ondersteund voor SQL Server 2008 of SQL Server 2008 R2 op een Azure-VM. |
| Logboekbestanden | De ene server die wordt uitgevoerd op een Azure-VM en de andere op een on-premises server voor herstel na noodherstel tussen locaties. De logboekverzending is afhankelijk Windows het delen van bestanden. Daarom is een VPN-verbinding tussen het virtuele Azure-netwerk en het on-premises netwerk vereist. Voor een geslaagd herstel na noodherstel van uw databases moet u ook een replicadomeincontroller installeren op de site voor herstel na noodherstel. |
| Back-up en herstel met Azure Blob Storage | On-premises productiedatabases maken rechtstreeks een back-up naar Azure Blob-opslag voor herstel na noodherstel. Zie Backup and restore for SQL Server on Azure Virtual Machines (Back-up en herstel voor back-ups Virtual Machines) voor meer Virtual Machines. |
| Replicatie en fail over SQL Server naar Azure met Azure Site Recovery | On-premises productie-SQL Server exemplaar rechtstreeks gerepliceerd naar Azure Storage voor herstel na noodherstel. Zie Voor meer informatie Protect SQL Server using SQL Server disaster recovery and Azure Site Recovery. |
Gratis DR-replica in Azure
Als u een Software Assurance,kunt u plannen voor hybride herstel na noodherstel (DR) implementeren met SQL Server zonder extra licentiekosten voor het passieve noodherstel-exemplaar.
U kunt bijvoorbeeld twee gratis passieve secondaries hebben wanneer alle drie de replica's worden gehost in Azure:
U kunt ook een hybride failoveromgeving configureren, met een gelicentieerde primaire on-premises, één gratis passieve voor ha, één gratis passieve voor dr-premises en één gratis passief voor DR in Azure:
Zie Licentievoorwaarden voor het product voor meer informatie.
Als u dit voordeel wilt inschakelen, gaat u naar SQL Server virtuele-machineresource. Selecteer Configureren onder Instellingen en kies vervolgens de optie Herstel na noodherstel onder SQL Server licentie. Schakel het selectievakje in om te bevestigen dat SQL Server VM wordt gebruikt als een passieve replica en selecteer vervolgens Toepassen om uw instellingen op te slaan.
Belangrijke overwegingen voor SQL Server HADR in Azure
Virtuele Azure-machines, opslag en netwerken hebben andere operationele kenmerken dan een on-premises, niet-gevirtualiseerde IT-infrastructuur. Voor een geslaagde implementatie van een HADR SQL Server-oplossing in Azure moet u deze verschillen begrijpen en uw oplossing hiervoor ontwerpen.
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, moet u alle deelnemende virtuele machines SQL Server in dezelfde beschikbaarheidsset plaatsen om te voorkomen dat toepassingen of gegevens verloren gaan tijdens een onderhoudsgebeurtenis. 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 storingen in datacenters 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, moet u deelnemende SQL Server machines verspreid over beschikbaarheidszones in de regio. Er worden extra kosten in rekening gebracht voor netwerk-naar-netwerk-overdrachten tussen beschikbaarheidszones. Zie Beschikbaarheidszones voor meer informatie.
Netwerklatentie in hybride IT
Implementeer uw HADR-oplossing met de veronderstelling dat er perioden met hoge netwerklatentie kunnen zijn tussen uw on-premises netwerk en Azure. Wanneer u replica's implementeert in Azure, gebruikt u asynchrone commit in plaats van synchrone commit voor de synchronisatiemodus. Wanneer u databasespiegelingsservers zowel on-premises als in Azure implementeert, gebruikt u de high performance-modus in plaats van de modus voor hoge veiligheid.
Zie de best practices voor HADR-configuratie voor cluster- en HADR-instellingen die geschikt zijn voor de cloudomgeving.
Ondersteuning voor geo-replicatie
Geo-replicatie in Azure-schijven biedt geen ondersteuning voor het gegevensbestand en logboekbestand van dezelfde database dat op afzonderlijke schijven moet worden opgeslagen. GRS repliceert wijzigingen op elke schijf onafhankelijk en asynchroon. Dit mechanisme garandeert de schrijfvolgorde binnen één schijf op de geografisch gerepliceerde kopie, maar niet tussen 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 noodlottige ramp mogelijk een actuelere 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 breekt.
Als u niet de mogelijkheid hebt om geo-replicatie uit te schakelen voor het opslagaccount, moet u alle gegevens en logboekbestanden voor een database op dezelfde schijf bewaren. 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 noodherstel om gegevens redundantie te garanderen.
Volgende stappen
Bepaal of een beschikbaarheidsgroep of een exemplaar van een failovercluster de beste oplossing voor bedrijfscontinuïteit voor uw bedrijf is. Bekijk vervolgens de best practices voor het configureren van uw omgeving voor hoge beschikbaarheid en herstel na noodherstel.