Architectuur en scenario's met hoge beschikbaarheid voor SAP NetWeaver

  • Artikel

Terminologiedefinities

Hoge beschikbaarheid: verwijst naar een set technologieën die IT-onderbrekingen minimaliseren door bedrijfscontinuïteit van IT-services te bieden via redundante, fouttolerante of failover-beveiligde onderdelen in hetzelfde datacenter. In ons geval bevindt het datacenter zich in één Azure-regio.

Herstel na noodgevallen: verwijst ook naar het minimaliseren van it-servicesonderbreking en hun herstel, maar in verschillende datacenters die mogelijk honderden kilometers van elkaar verwijderd zijn. In ons geval bevinden de datacenters zich mogelijk in verschillende Azure-regio's binnen dezelfde geopolitieke regio of op locaties die door u als klant zijn ingesteld.

Overzicht van hoge beschikbaarheid

Hoge beschikbaarheid van SAP in Azure kan worden onderverdeeld in drie typen:

  • Hoge beschikbaarheid van Azure-infrastructuur:

    Hoge beschikbaarheid kan bijvoorbeeld rekenkracht (VM's), netwerk of opslag en de voordelen hiervan zijn voor het verhogen van de beschikbaarheid van SAP-toepassingen.

  • Gebruik van het opnieuw opstarten van azure-infrastructuur-VM's om SAP-toepassingen te beveiligen:

    Als u besluit geen gebruik te maken van functies zoals Windows Server Failover Clustering (WSFC) of Pacemaker op Linux, wordt het opnieuw opstarten van azure-VM gebruikt. Het herstelt de functionaliteit in de SAP-systemen als er geplande en ongeplande downtime van de fysieke Azure-serverinfrastructuur en het algehele onderliggende Azure-platform is.

  • Hoge beschikbaarheid van SAP-toepassingen:

    Als u een volledige hoge beschikbaarheid van het SAP-systeem wilt bereiken, moet u alle essentiële SAP-systeemonderdelen beveiligen. Bijvoorbeeld:

    • Redundante SAP-toepassingsservers.
    • Unieke onderdelen. Een voorbeeld hiervan is een SPOF-onderdeel (Single Point of Failure), zoals een SAP ASCS/SCS-exemplaar of een databasebeheersysteem (DBMS).

Hoge beschikbaarheid van SAP in Azure verschilt van hoge beschikbaarheid van SAP in een on-premises fysieke of virtuele omgeving.

Er is geen sapinst-geïntegreerde SAP-configuratie voor hoge beschikbaarheid voor Linux, zoals er is voor Windows. Zie informatie over hoge beschikbaarheidspartnerinformatie over hoge beschikbaarheid voor Linux voor informatie over on-premises SAP-beschikbaarheid.

Hoge beschikbaarheid van Azure-infrastructuur

SLA voor virtuele machines met één exemplaar

Er is momenteel een SLA met één VM van 99,9% met Premium-opslag. Als u een idee wilt krijgen van wat de beschikbaarheid van één VIRTUELE machine kan zijn, kunt u het product van de verschillende beschikbare Azure Service Level Agreements bouwen.

De basis voor de berekening is 30 dagen per maand of 43.200 minuten. Een downtime van 0,05% komt bijvoorbeeld overeen met 21,6 minuten. Zoals gebruikelijk wordt de beschikbaarheid van de verschillende services op de volgende manier berekend:

(Beschikbaarheidsservice #1/100) x (Beschikbaarheidsservice #2/100) x (Beschikbaarheidsservice #3/100) *...

Bijvoorbeeld:

(99,95/100) x (99,9/100) x (99,9/100) = 0,9975 of een totale beschikbaarheid van 99,75%.

Meerdere exemplaren van virtuele machines in dezelfde beschikbaarheidsset

Voor alle virtuele machines waarop twee of meer exemplaren in dezelfde beschikbaarheidsset zijn geïmplementeerd, garanderen we dat u een virtuele-machineverbinding hebt met ten minste één exemplaar ten minste 99,95% van de tijd.

Wanneer twee of meer VM's deel uitmaken van dezelfde beschikbaarheidsset, wordt aan elke virtuele machine in de beschikbaarheidsset een updatedomein en een foutdomein toegewezen door het onderliggende Azure-platform.

  • Updatedomeinen garanderen dat meerdere VM's niet tegelijkertijd opnieuw worden opgestart tijdens het geplande onderhoud van een Azure-infrastructuur. Er wordt slechts één VIRTUELE machine tegelijk opnieuw opgestart.
  • Foutdomeinen garanderen dat VM's worden geïmplementeerd op hardwareonderdelen die geen gemeenschappelijke voedingsbron en netwerkswitch delen. Wanneer servers, een netwerkswitch of een voedingsbron een ongeplande downtime ondergaan, wordt er slechts één VM beïnvloed.

Zie de beschikbaarheid van virtuele machines in Azure beheren met behulp van een beschikbaarheidsset voor meer informatie.

Azure-beschikbaarheidszones

Azure is bezig met het implementeren van een concept van Azure Beschikbaarheidszones in verschillende Azure-regio's. In Azure-regio's waar Beschikbaarheidszones worden aangeboden, hebben de Azure-regio's meerdere datacenters, die onafhankelijk zijn van de voeding, koeling en het netwerk. Reden voor het aanbieden van verschillende zones binnen één Azure-regio is om u in staat te stellen toepassingen te implementeren in twee of drie Beschikbaarheidszones aangeboden. Ervan uitgaande dat problemen in energiebronnen en/of netwerken alleen van invloed zijn op één infrastructuur voor beschikbaarheidszones, is uw toepassingsimplementatie binnen een Azure-regio nog steeds volledig functioneel. Uiteindelijk met een verminderde capaciteit omdat sommige VM's in één zone mogelijk verloren gaan. Maar VM's in de andere twee zones zijn nog steeds actief. De Azure-regio's met zones worden vermeld in Azure Beschikbaarheidszones.

Bij het gebruik van Beschikbaarheidszones zijn er enkele dingen die u moet overwegen. De lijst met overwegingen zoals:

  • U kunt Azure-beschikbaarheidssets niet implementeren binnen een beschikbaarheidszone. Alleen de mogelijkheid om beschikbaarheidssets te combineren en Beschikbaarheidszones is met nabijheidsplaatsingsgroepen. Zie het artikel Beschikbaarheidssets en beschikbaarheidszones combineren met nabijheidsplaatsingsgroepen voor meer informatie.
  • U kunt de Basic Load Balancer niet gebruiken om failoverclusteroplossingen te maken op basis van Windows Failover Cluster Services of Linux Pacemaker. In plaats daarvan moet u de Azure Standard Load Balancer-SKU gebruiken.
  • Azure Beschikbaarheidszones biedt geen garanties voor bepaalde afstand tussen de verschillende zones binnen één regio.
  • De netwerklatentie tussen verschillende Azure-Beschikbaarheidszones binnen de verschillende Azure-regio's kan verschillen van Azure-regio tot regio. Er zijn gevallen waarin u als klant de SAP-toepassingslaag redelijkerwijs kan uitvoeren die in verschillende zones is geïmplementeerd, omdat de netwerklatentie van één zone naar de actieve DBMS-VM nog steeds acceptabel is vanuit een impact op het bedrijfsproces. Er kunnen klantscenario's zijn waarbij de latentie tussen de actieve DBMS-VM in één zone en een SAP-toepassingsexemplaren in een VM in een andere zone te intrusief en niet acceptabel kan zijn voor de SAP-bedrijfsprocessen. Als gevolg hiervan moeten de implementatiearchitecturen verschillen met een actieve/actieve architectuur voor de toepassing of actieve/passieve architectuur als de latentie te hoog is.
  • Het gebruik van beheerde Azure-schijven is verplicht voor implementatie in Azure Beschikbaarheidszones.

Virtuele-machineschaalset met flexibele indeling

In Azure bieden virtuele-machineschaalsets met flexibele indeling een middel om hoge beschikbaarheid voor SAP-workloads te bereiken, net zoals andere implementatieframeworks, zoals beschikbaarheidssets en beschikbaarheidszones. Met flexibele schaalsets kunnen VM's worden gedistribueerd over verschillende beschikbaarheidszones en foutdomeinen, waardoor het een geschikte optie is voor het implementeren van maximaal beschikbare SAP-workloads.

Virtuele-machineschaalset met flexibele indeling biedt de flexibiliteit om de schaalset binnen een regio te maken of deze over meerdere beschikbaarheidszones te strekken. Bij het maken wordt de flexibele schaalset binnen een regio met platformFaultDomainCount>1 (FD>1) gedistribueerd over het opgegeven aantal foutdomeinen in dezelfde regio. Aan de andere kant, het maken van de flexibele schaalset in beschikbaarheidszones met platformFaultDomainCount=1 (FD=1) distribueert de VM's over verschillende zones en de schaalset distribueert ook VM's over verschillende foutdomeinen binnen elke zone op basis van de beste inspanning. Voor SAP-werkbelasting wordt alleen flexibele schaalset met FD=1 ondersteund.

Het voordeel van het gebruik van flexibele schaalsets met FD=1 voor zoneoverschrijdende implementatie, in plaats van traditionele implementatie van beschikbaarheidszones is dat de VM's die met de schaalset zijn geïmplementeerd, op een optimale manier over verschillende foutdomeinen binnen de zone worden verdeeld. Om de beperkingen te voorkomen die zijn gekoppeld aan het gebruik van nabijheidsplaatsingsgroep om ervoor te zorgen dat VM's beschikbaar zijn in alle Azure-datacenters of onder elke netwerkstekel, is het raadzaam om SAP-workload te implementeren in verschillende beschikbaarheidszones met flexibele schaalset met FD=1. Deze implementatiestrategie zorgt ervoor dat VM's die in elke zone worden geïmplementeerd, niet beperkt zijn tot één datacenter of netwerkstekel en alle SAP-systeemonderdelen, zoals databases, ASCS/ERS en toepassingslaag, zijn gericht op zonegebonden niveau.

Voor de implementatie van nieuwe SAP-werkbelasting in verschillende beschikbaarheidszones adviseren we daarom om flexibele schaalsets te gebruiken met FD=1. Zie virtuele-machineschaalset voor SAP-werkbelastingdocument voor meer informatie.

Gepland en ongepland onderhoud van virtuele machines

Twee typen Azure-platformevenementen kunnen van invloed zijn op de beschikbaarheid van uw virtuele machines:

  • Geplande onderhoudsevenementen zijn periodieke updates van Microsoft naar het onderliggende Azure-platform. De updates verbeteren de algehele betrouwbaarheid, prestaties en beveiliging van de platforminfrastructuur waarop uw virtuele machines worden uitgevoerd.
  • Ongeplande onderhoudsgebeurtenissen treden op wanneer de hardware of fysieke infrastructuur van uw virtuele machine op een of andere manier is mislukt. Het kan lokale netwerkfouten, lokale schijffouten of andere fouten op rackniveau bevatten. Wanneer een dergelijke fout wordt gedetecteerd, migreert het Azure-platform uw virtuele machine automatisch van de beschadigde fysieke server die als host fungeert voor uw virtuele machine naar een gezonde fysieke server. Dergelijke gebeurtenissen zijn zeldzaam, maar ze kunnen er ook voor zorgen dat uw virtuele machine opnieuw wordt opgestart.

Zie het onderhoud van virtuele machines in Azure voor meer informatie.

Azure Storage-redundantie

De gegevens in uw opslagaccount worden altijd gerepliceerd om duurzaamheid en hoge beschikbaarheid te garanderen en te voldoen aan de SLA van Azure Storage, zelfs als er tijdelijke hardwarefouten optreden.

Omdat Azure Storage standaard drie installatiekopieën van de gegevens bewaart, is het gebruik van RAID 5 of RAID 1 op meerdere Azure-schijven overbodig.

Zie Azure Storage-replicatie voor meer informatie.

Azure Managed Disks

Managed Disks is een resourcetype in Azure Resource Manager, is een aanbevolen opslagoptie in plaats van virtuele harde schijven (VHD's) die zijn opgeslagen in Azure-opslagaccounts. Beheerde schijven worden automatisch uitgelijnd met een Azure-beschikbaarheidsset van de virtuele machine waaraan ze zijn gekoppeld. Ze verhogen de beschikbaarheid van uw virtuele machine en de services die erop worden uitgevoerd.

Zie Azure Managed Disks overview (Overzicht van Azure Managed Disks) voor meer informatie.

U wordt aangeraden beheerde schijven te gebruiken omdat ze de implementatie en het beheer van uw virtuele machines vereenvoudigen.

Vergelijking van verschillende implementatietypen voor SAP-workload

Hier volgt een kort overzicht van de verschillende implementatietypen die beschikbaar zijn voor SAP-workloads.

Functies Virtuele-machineschaalset met flexibele indeling (FD=1) Beschikbaarheidszone Beschikbaarheidsset
Implementatiegedrag Exemplaren landen over 1, 2 of 3 beschikbaarheidszones en verdeeld over verschillende racks binnen elke zone op basis van de beste inspanning Exemplaren landen in 1, 2 of 3 beschikbaarheidszones Exemplaren landen binnen regio's en verdeeld over verschillende fout-/updatedomein
VM's en beheerde schijven toewijzen aan een specifieke beschikbaarheidszone Ja Ja Nee
Foutdomein: maximale verspreiding (Azure zal maximaal verspreide exemplaren) Ja Nee Ja, op basis van het aantal foutdomeinen dat tijdens het maken is gedefinieerd.
Uitlijning van rekenproces naar opslagfoutdomein Nee Nee Ja
Capaciteitsreservering Ja (capaciteitsreservering toewijzen op VM-niveau) Ja Nr.

Notitie

  • Updatedomeinen zijn afgeschaft in de flexibele indelingsmodus. Zie Implementaties en resources migreren naar Virtuele-machineschaalsets in Flexibele indeling voor meer informatie
  • Zie Het kiezen van het juiste aantal foutdomeinen voor virtuele-machineschaalsets en hoe werken beschikbaarheidssets voor meer informatie over de uitlijning van reken- en opslagfoutendomein.
  • Als u capaciteitsreservering wilt inschakelen, is het belangrijk om de beperkingen en beperkingen van de capaciteitsreservering te controleren.

Implementatieopties voor hoge beschikbaarheid voor SAP-werkbelasting

Bij het implementeren van een SAP-workload met hoge beschikbaarheid in Azure is het belangrijk om rekening te houden met de verschillende beschikbare implementatietypen en hoe ze kunnen worden toegepast in verschillende Azure-regio's (zoals in meerdere zones, in één zone of in een regio zonder zones). In de volgende tabel ziet u verschillende opties voor hoge beschikbaarheid voor SAP-systemen in Azure-regio's.

Systeemtype In verschillende zones in een regio In een zangzone van een regio In een regio zonder zones
SAP-systeem met hoge beschikbaarheid Flexibele schaalset met FD=1 Beschikbaarheidssets met nabijheidsplaatsingsgroepen Beschikbaarheidssets
Beschikbaarheidssets en Beschikbaarheidszones met nabijheidsplaatsingsgroepen Flexibele schaalset met FD=1 (selecteer slechts één zone) Flexibele schaalset met FD=1 (er zijn geen zones gedefinieerd)
Beschikbaarheidszones Beschikbaarheidssets
  • Implementatie in verschillende zones in een regio: Voor de hoogste beschikbaarheid moeten SAP-systemen worden geïmplementeerd in verschillende zones in een regio. Dit zorgt ervoor dat als één zone niet beschikbaar is, het SAP-systeem beschikbaar blijft in een andere zone. Als u een nieuwe SAP-workload implementeert in beschikbaarheidszones, is het raadzaam om flexibele virtuele-machineschaalsets te gebruiken met de implementatieoptie FD=1. Hiermee kunt u meerdere VM's implementeren in verschillende zones in een regio zonder dat u zich zorgen hoeft te maken over capaciteitsbeperkingen of plaatsingsgroepen. Het schaalsetframework zorgt ervoor dat de VM's die zijn geïmplementeerd met de schaalset, op een optimale manier worden verdeeld over verschillende foutdomeinen binnen de zone. Alle maximaal beschikbare SAP-onderdelen, zoals SAP ASCS/ERS, SAP-databases worden verdeeld over verschillende zones, terwijl meerdere toepassingsservers in elke zone op basis van best effort over verschillende foutdomeinen worden verdeeld.
  • Implementatie in één zone van een regio: als u uw SAP-systeem met hoge beschikbaarheid regionaal wilt implementeren op een locatie met meerdere beschikbaarheidszones en als dit essentieel is voor alle onderdelen van het systeem in één zone, wordt u aangeraden beschikbaarheidssets te gebruiken met de implementatieoptie Nabijheidsplaatsingsgroepen. Met deze methode kunt u alle SAP-systeemonderdelen in één beschikbaarheidszone groeperen, zodat de virtuele machines in de beschikbaarheidsset worden verdeeld over verschillende fout- en updatedomeinen. Hoewel deze implementatie rekenkracht uitlijnt op opslagfoutdomeinen, is nabijheid niet gegarandeerd. Omdat deze implementatieoptie echter regionaal is, biedt deze geen ondersteuning voor Azure Site Recovery voor herstel na een zone-naar-zone. Bovendien beperkt deze optie de hele SAP-implementatie tot één datacenter, wat kan leiden tot capaciteitsbeperkingen als u de SKU-grootte of uitschaaltoepassingsexemplaren moet wijzigen.
  • Implementatie in een regio zonder zones: als u uw SAP-systeem implementeert in een regio die geen zones heeft, is het raadzaam beschikbaarheidssets te gebruiken. Deze optie biedt redundantie en fouttolerantie door VM's in verschillende foutdomeinen en updatedomeinen te plaatsen.

Belangrijk

Er moet worden opgemerkt dat de implementatieopties voor Azure-regio's alleen suggesties zijn. De meest geschikte implementatiestrategie voor uw SAP-systeem is afhankelijk van uw specifieke vereisten en omgeving.

Hoge beschikbaarheid van Azure-infrastructuur gebruiken om SAP-toepassingen te beveiligen

Als u besluit geen functionaliteiten zoals WSFC of Pacemaker op Linux te gebruiken (ondersteund voor SUSE Linux Enterprise Server 12 en hoger en Red Hat Enterprise Linux 7 en hoger), wordt opnieuw opstarten van azure-VM gebruikt. Het herstelt de functionaliteit in de SAP-systemen als er geplande en ongeplande downtime van de fysieke Azure-serverinfrastructuur en het algehele onderliggende Azure-platform is.

Zie Azure Infrastructure VM opnieuw opstarten gebruiken voor een hogere beschikbaarheid van het SAP-systeem voor meer informatie over de aanpak.

Hoge beschikbaarheid van SAP-toepassingen op Azure IaaS

Als u een volledige hoge beschikbaarheid van het SAP-systeem wilt bereiken, moet u alle essentiële SAP-systeemonderdelen beveiligen. Bijvoorbeeld:

  • Redundante SAP-toepassingsservers.
  • Unieke onderdelen. Een voorbeeld hiervan is een SPOF-onderdeel (Single Point of Failure), zoals een SAP ASCS/SCS-exemplaar of een databasebeheersysteem (DBMS).

In de volgende secties wordt besproken hoe u hoge beschikbaarheid kunt bereiken voor alle drie de essentiële SAP-systeemonderdelen.

Architectuur met hoge beschikbaarheid voor SAP-toepassingsservers

Windows logo. Windows en Linux logo. Linux

Meestal hebt u geen specifieke oplossing met hoge beschikbaarheid nodig voor de SAP-toepassingsserver en dialoogvensterexemplaren. U bereikt hoge beschikbaarheid door redundantie en u configureert meerdere dialoogvensterexemplaren in verschillende exemplaren van virtuele Azure-machines. U moet ten minste twee SAP-toepassingsexemplaren hebben geïnstalleerd in twee exemplaren van virtuele Azure-machines.

Afhankelijk van het implementatietype (flexibele schaalset met FD=1, beschikbaarheidszone of beschikbaarheidsset), moet u uw SAP-toepassingsserverexemplaren dienovereenkomstig distribueren om redundantie te bereiken.

  • Flexibele schaalset met platformFaultDomainCount=1 (FD=1): SAP-toepassingsservers die zijn geïmplementeerd met flexibele schaalset (FD=1) verdelen de virtuele machines over verschillende beschikbaarheidszones en de schaalset distribueert ook VM's over verschillende foutdomeinen binnen elke zone op basis van de beste inspanning. Dit zorgt ervoor dat als één zone niet beschikbaar is, de SAP-toepassingsservers die in een andere zone zijn geïmplementeerd, beschikbaar blijven.
  • Beschikbaarheidszone: SAP-toepassingsservers die zijn geïmplementeerd in beschikbaarheidszones zorgen ervoor dat VM's zich over verschillende zones bevinden om redundantie te bereiken. Dit zorgt ervoor dat als één zone niet beschikbaar is, de SAP-toepassingsservers die in een andere zone zijn geïmplementeerd, beschikbaar blijven. Zie SAP-workloadconfiguraties met Azure Beschikbaarheidszones voor meer informatie
  • Beschikbaarheidsset: SAP-toepassingsservers die zijn geïmplementeerd in de beschikbaarheidsset zorgen ervoor dat VM's worden gedistribueerd over verschillende foutdomeinen en updatedomeinen. Bij het plaatsen van VM's in verschillende updatedomeinen moet u ervoor zorgen dat VM's niet tegelijkertijd worden bijgewerkt tijdens gepland onderhoud. Overwegende dat het plaatsen van VM's in een ander foutdomein ervoor zorgt dat vm wordt beschermd tegen hardwarestoringen of stroomonderbrekingen in een datacenter. Maar het aantal fout- en updatedomeinen dat u in een Azure-beschikbaarheidsset binnen een Azure-schaaleenheid kunt gebruiken, is eindig. Als u VM's blijft toevoegen aan één beschikbaarheidsset, zouden twee of meer VM's uiteindelijk in hetzelfde fout- of updatedomein terechtkomen. Zie de sectie Azure-beschikbaarheidssets van de planning en implementatie van virtuele Azure-machines voor SAP NetWeaver voor meer informatie.

Alleen niet-beheerde schijven: wanneer u niet-beheerde schijven met een beschikbaarheidsset gebruikt, is het belangrijk om te herkennen dat het Azure-opslagaccount een single point of failure wordt. Daarom is het noodzakelijk om minimaal twee Azure-opslagaccounts in te stellen, waarbij ten minste twee virtuele machines worden gedistribueerd. In een ideale installatie worden de schijven van elke virtuele machine waarop een SAP-dialoogvensterexemplaren worden uitgevoerd, geïmplementeerd in een ander opslagaccount.

Belangrijk

We raden u ten zeerste aan om beheerde Azure-schijven te gebruiken voor uw SAP-installaties met hoge beschikbaarheid. Omdat beheerde schijven automatisch overeenkomen met de beschikbaarheidsset van de virtuele machine waaraan ze zijn gekoppeld, verhogen ze de beschikbaarheid van uw virtuele machine en de services die erop worden uitgevoerd.

Architectuur met hoge beschikbaarheid voor een SAP ASCS/SCS-exemplaar in Windows

Windows logo. Windows

U kunt een WSFC-oplossing gebruiken om het SAP ASCS/SCS-exemplaar te beveiligen. Op basis van het type clustershareconfiguratie (bestandsshare of gedeelde schijf) kunt u verwijzen naar de juiste oplossing op basis van uw opslagtype.

Architectuur met hoge beschikbaarheid voor een SAP ASCS/SCS-exemplaar in Linux

Linux logo. Linux

In Linux is de configuratie van SAP ASCS/SCS-exemplaarclustering afhankelijk van de distributie van het besturingssysteem en het type opslag dat wordt gebruikt. Het wordt aanbevolen om de geschikte oplossing te implementeren op basis van uw specifieke framework voor het besturingssysteemcluster.

SAP NetWeaver multi-SID-configuratie voor een geclusterd SAP ASCS/SCS-exemplaar

Windows logo. Venster

Multi-SID wordt ondersteund met WSFC, met behulp van bestandsshare en gedeelde schijf. Zie voor meer informatie over architectuur met hoge beschikbaarheid met meerdere SID's in Windows:

Linux logo. Linux

Clustering met meerdere SID's wordt ondersteund op Linux Pacemaker-clusters voor SAP ASCS/ERS, beperkt tot vijf SAP-SID's in hetzelfde cluster. Zie voor meer informatie over architectuur met hoge beschikbaarheid met meerdere SID's in Linux:

Hoge beschikbaarheid van DBMS-exemplaar

In een SAP-systeem zijn de DBMS-servers ook het single point of failure. Het is dus belangrijk om de database te beveiligen door een oplossing voor hoge beschikbaarheid te implementeren. De oplossing voor hoge beschikbaarheid van DBMS varieert op basis van de database die wordt gebruikt voor het SAP-systeem. Volg op basis van uw database de richtlijnen om hoge beschikbaarheid voor uw database te bereiken.

Database Aanbeveling voor herstel na noodgevallen
SAP HANA HANA-systeemreplicatie (HSR)
Oracle Oracle Data Guard
IBM DB2 Herstel na noodgevallen met hoge beschikbaarheid (HADR)
Microsoft SQL Microsoft SQL AlwaysOn
SAP ASE ASE HADR Always On