Bedrijfscontinuïteit en herstel na noodgevallen voor Oracle op Azure Virtual Machines-landingszoneversneller

Artikel
08/01/2024

Dit artikel is gebaseerd op de overwegingen en aanbevelingen die zijn gedefinieerd in het ontwerpgebied van de Azure-landingszone voor bedrijfscontinuïteit en herstel na noodgevallen (BCDR). Dit artikel volgt deze richtlijnen en beschrijft ontwerpoverwegingen en best practices over BCDR-opties voor Oracle-workloadimplementaties op virtuele Machines (VM's) van azure-infrastructuur.

Azure biedt services die u kunt gebruiken om maximaal beschikbare en flexibele architecturen te ontwerpen. In deze handleiding vindt u een overzicht van verschillende opties en aanbevolen procedures om u te helpen bij het ontwerpen van hoge beschikbaarheid en herstel na noodgevallen voor Oracle-databases in de landingszoneversneller van Azure Virtual Machines. Ook wordt beschreven hoe u bijbehorende Azure-services configureert om u te helpen bij het bereiken van een hoge end-to-end beschikbaarheid voor uw oplossing.

Aan de slag

Als u een flexibele architectuur voor uw workloadomgeving wilt bouwen, bepaalt u de beschikbaarheidsvereisten voor uw oplossing op basis van de beoogde hersteltijd (RTO) en RPO (Recovery Point Objective) voor verschillende storingsniveaus. RTO is de maximale tijd dat een toepassing niet beschikbaar blijft nadat een incident zich voordoet. RPO is de maximale hoeveelheid gegevensverlies tijdens een noodgeval. Nadat u de vereisten voor uw oplossing hebt vastgesteld, ontwerpt u uw architectuur om de vastgestelde niveaus van tolerantie en beschikbaarheid te bieden.

Oracle op Azure-workloads maken voornamelijk gebruik van Oracle Data Guard. Dit is een ingebouwde Oracle Database Enterprise Edition-functie die gebruikmaakt van replicatietechnologie. U kunt Data Guard gebruiken om te voldoen aan de behoeften voor hoge beschikbaarheid en herstel na noodgevallen. Data Guard biedt drie beveiligingsmodi: maximale prestaties, maximale beschikbaarheid en maximale beveiliging. Kies uw beveiligingsmodus op basis van uw architectuurontwerp en uw specifieke RPO- en RTO-vereisten.

Uw workload configureren voor hoge beschikbaarheid

Azure Virtual Machines-exemplaren waarop Oracle-workloads worden uitgevoerd, profiteren van de Azure Virtual Machine Scale Sets-architectuur, met name de flexibele indelingsmodus. Een configuratie met hoge beschikbaarheid biedt bijna realtime gegevensreplicatie met mogelijk snelle failovermogelijkheden. Een configuratie met hoge beschikbaarheid biedt geen beveiliging voor fouten op azure-datacenterniveau of op regioniveau.

De juiste optie voor hoge beschikbaarheid kiezen

Gebruik het volgende stroomdiagram om de beste optie voor hoge beschikbaarheid voor uw Oracle-database te kiezen.

Data Guard gebruiken in de maximale beschikbaarheidsmodus voor hoge beschikbaarheid

Data Guard in de maximale beschikbaarheidsmodus biedt de hoogste beschikbaarheid met een belofte voor gegevensverlies zonder gegevensverlies (RPO=0) voor normale bewerkingen. Voor een maximaal beschikbare configuratie van twee Oracle-databaseservers die zijn gemaakt binnen een flexibele indeling van virtuele-machineschaalsets, biedt Azure 99,95% servicebeschikbaarheid voor een SLA (Service Level Agreement) voor exemplaren die zijn verspreid over foutdomeinen. Azure biedt 99,99% service-beschikbaarheid voor exemplaren die zijn verspreid over beschikbaarheidszones. Zie Hoge beschikbaarheid voor virtuele-machineschaalsets voor meer informatie.

Zie Oracle Data Guard implementeren op een Azure-VM op basis van Linux voor een stapsgewijze configuratie van Data Guard in Azure.

Data Guard gebruiken in de maximale beveiligingsmodus voor hoge beschikbaarheid

Als u een transactioneel consistente kopie van uw database nodig hebt, kunt u Overwegen Om Data Guard te gebruiken in de maximale beveiligingsmodus. De maximale beveiligingsmodus staat echter niet toe dat transacties worden voortgezet wanneer de stand-bydatabase niet beschikbaar is. Daarom wordt uw SLA, ondanks het gebruik van flexibele indeling van virtuele-machinesschaalsets, gereduceerd tot 99,9% x 99,9% = 99,8% wanneer u de maximale beveiligingsmodus gebruikt. Deze configuratie zorgt voor een consistente kopie van gegevens, maar verhoogt niet noodzakelijkerwijs de beschikbaarheid.

Andere kenmerken van deze architectuur zijn hetzelfde als de maximale beschikbaarheidsmodus. De RPO is bijvoorbeeld nul en de RTO is kleiner dan of gelijk aan twee minuten.

Overweeg andere manieren om hoge beschikbaarheid te implementeren

In de volgende secties worden speciale overwegingen voor hoge beschikbaarheid beschreven.

Beschikbaarheidszones gebruiken voor verbeterde hoge beschikbaarheid

Azure-beschikbaarheidszones zijn Azure-datacenters die zich binnen dezelfde Azure-regio bevinden. Beschikbaarheidszones hebben een retourlatentie van minder dan twee milliseconden. Doorgaans gebruikt u beschikbaarheidszones voor herstel na noodgevallen, maar u kunt ze gebruiken om hoge beschikbaarheid te verbeteren. Als u dit doet, moet u ervoor zorgen dat uw oplossing kan worden uitgevoerd met de hoeveelheid latentie en doorvoer die uw beschikbaarheidszones bieden.

Een voordeel van beschikbaarheidszones met een flexibele indeling van virtuele-machineschaalsets is dat de SLA voor beschikbaarheid van uw VM toeneemt tot 99,99%.

Gedeelde opslagclustering gebruiken voor hoge beschikbaarheid

Clusteringtechnologieën voor gedeelde opslag bieden unieke kenmerken waarmee u uw bedrijfsdoelen kunt bereiken. U kunt bijvoorbeeld een Pacemaker- en Corosync-cluster (PCS) implementeren met gedeelde opslag. U kunt beheerde schijven of Azure NetApp Files gebruiken als gedeelde opslag voor PCS-clusterexemplaren. In een PCS-cluster worden geen gegevens gedupliceerd. Het biedt een virtuele IP-service met een statisch IP-adres of IP-netwerknaam die niet wordt gewijzigd tussen failovers.

Notitie

Een PCS-cluster is geen oracle-gecertificeerde oplossing. Houd rekening met deze factor wanneer u uw architectuur voor hoge beschikbaarheid kiest.

Nabijheidsplaatsingsgroepen gebruiken

Als u de laagst mogelijke latentie wilt bieden, plaatst u VM's zo dicht mogelijk. U kunt ze implementeren binnen een nabijheidsplaatsingsgroep. Een nabijheidsplaatsingsgroep is een logische groepering die ervoor zorgt dat Azure-rekenresources zich fysiek dicht bij elkaar bevinden. Nabijheidsplaatsingsgroepen zijn handig voor workloads waarvoor lage latentie is vereist.

Uw workload configureren voor herstel na noodgevallen

Een architectuur voor herstel na noodgevallen biedt tolerantie tegen storingen die van invloed zijn op Azure-datacenters of -regio's of op fouten die de functionaliteit van toepassingen in een hele regio belemmeren. In een dergelijk scenario moet u uw hele workload verplaatsen naar een ander datacenter of een andere regio.

Kies uw architectuur voor herstel na noodgevallen op basis van uw oplossingsvereisten. U bepaalt uw vereisten op basis van uw RTO en RPO. Architecturen voor herstel na noodgevallen zijn voor uitzonderlijke fouten, dus failoverprocessen zijn handmatig. In het ontwerp voor hoge beschikbaarheid worden failoverprocessen automatisch uitgevoerd. In een architectuur voor herstel na noodgevallen moet u meer ontspannen vereisten hebben voor RTO en RPO, waardoor u geld bespaart.

Dit artikel is gericht op scenario's waarin de primaire server en secundaire servers zich beide in Azure bevinden. U kunt ook een primaire server on-premises en een secundaire server in Azure hebben voor herstel na noodgevallen. Zie de on-premises primaire site en de site voor herstel na noodgevallen in Azure voor meer informatie.

De juiste optie voor herstel na noodgevallen kiezen

Gebruik het volgende stroomdiagram om de beste optie voor herstel na noodgevallen te kiezen voor uw Oracle-database.

Data Guard gebruiken voor herstel na noodgevallen

U kunt Data Guard gebruiken om gegevens te repliceren naar uw site voor herstel na noodgevallen. Gebruik die site als een andere beschikbaarheidszone in dezelfde regio of in een andere regio, afhankelijk van uw vereisten voor gegevensbescherming. Uw configuratie is ook afhankelijk van de structuur van de beschikbaarheidszone op uw productiesite. Een Data Guard-implementatie in een scenario voor herstel na noodgevallen is vergelijkbaar met het eerder besproken scenario met hoge beschikbaarheid, met enkele belangrijke verschillen. Voorbeeld:

Wanneer u een failover uitvoert naar een secundaire replica in het scenario met hoge beschikbaarheid, configureert u Azure Load Balancer om aanvragen om te leiden naar het nieuwe primaire database-exemplaar.
Wanneer u een failover uitvoert naar de site voor herstel na noodgevallen, voert u een failover uit van de hele oplossing naar de nieuwe site. Om latentieproblemen te voorkomen, moet u doorgaans failover configureren voor toepassingsservices.

Als de site voor herstel na noodgevallen zich in een andere regio bevindt, moet u de site ontwerpen voor de failover, afhankelijk van uw vereisten.

De latentie binnen één datacenter is minder dan de latentie tussen datacenters die ver van elkaar zijn gescheiden en veel minder dan de latentie tussen verschillende regio's. Daarom is de minst complexe en minst dure optie om Data Guard te gebruiken in de maximale prestatiemodus voor herstel na noodgevallen. Als het potentiële gegevensverlies in de maximale prestatiemodus te hoog is, kunt u de maximale beschikbaarheidsmodus gebruiken met het Oracle Data Guard Far Sync-mechanisme. Een Far Sync-exemplaar activeert echter Active Data Guard-licenties op de primaire omgeving en stand-byomgeving. Zie Oracle-licentiegegevens voor meer informatie.

Bovendien betaalt u, wanneer u gegevens verzendt tussen Azure-regio's of -datacenters, uitgaande kosten voor gegevens, zoals opnieuw uitvoeren van logboeken, die worden verzonden naar een site voor herstel na noodgevallen. Als u niet alle gegevens in uw database hoeft te repliceren, kunt u op Oracle Golden Gate gebaseerde replicatie gebruiken om alleen gedeeltelijke gegevens te repliceren als dat nodig is, waardoor de kosten voor uitgaand verkeer worden verminderd.

Zie Data Guard implementeren op een Linux-VM voor een stapsgewijze configuratie van Data Guard in Azure.

Golden Gate gebruiken voor herstel na noodgevallen

Golden Gate is een logische replicatiesoftware die u kunt gebruiken voor realtime replicatie, filtering en transformatie van gegevens van een brondatabase naar een doeldatabase of tussen meerdere primaire databases. Deze functie zorgt ervoor dat wijzigingen in de brondatabase bijna in realtime worden gerepliceerd, zodat de doeldatabase up-to-date is met de meest recente gegevens.

U kunt Golden Gate gebruiken om gegevens van een primaire database te repliceren naar een secundaire database in een configuratie voor herstel na noodgevallen. Golden Gate is vooral praktisch als u slechts enkele van uw gegevens moet beveiligen. Om replicatie van onnodige gegevens te voorkomen, gebruikt u Golden Gate om tabellen selectief te repliceren en tabelrijen tijdens de replicatie uit te filteren.

Zie Golden Gate implementeren op een Op Linux gebaseerde Azure-VM voor een stapsgewijze handleiding over het implementeren van Golden Gate in Azure.

Back-up gebruiken voor herstel na noodgevallen

Back-up en herstel is een traditionele methode voor een architectuur voor herstel na noodgevallen. Er zijn twee hoofdonderdelen voor back-ups als herstelmethode voor Oracle-databases in Azure:

Extraheer en verplaats de back-up van gegevens uit een database om ervoor te zorgen dat de site voor herstel na noodgevallen up-to-date gegevens bevat.
Zorg voor een up-to-date implementatie op de site voor herstel na noodgevallen. Als u de site wilt bijwerken, repliceert u dezelfde implementatie van alle netwerkonderdelen, toepassingsservers en configuraties naar de site voor herstel na noodgevallen.

Er zijn verschillende back-upopties die u kunt gebruiken om gegevens te repliceren. Zie Back-upstrategieën voor Oracle Database in Azure voor meer informatie.

Overweeg een van de volgende methoden te gebruiken om een site voor herstel na noodgevallen te onderhouden:

Aanpak 1: Als u extra onderhoudswerkzaamheden en -kosten wilt voorkomen, moet u geen fysieke implementatie onderhouden op de site voor herstel na noodgevallen. U kunt infrastructuur gebruiken als code- en sitebetrouwbaarheidstechniek om een opslagplaats te ontwikkelen en te onderhouden. Deze opslagplaats kan de implementatie repliceren als configuratie naar een site voor herstel na noodgevallen op het moment van de failover. Met deze methode worden de kosten geoptimaliseerd omdat er pas fysieke resources worden gebruikt als de failover plaatsvindt.

Belangrijk

Als u een volledig nieuwe implementatie maakt tijdens een failover, moet u ervoor zorgen dat uw implementatie kan voldoen aan de RTO-vereisten van de oplossing. Om ervoor te zorgen dat de implementatiecode niet wordt verbroken, moet u het scenario voor herstel na noodgevallen regelmatig simuleren en testen.

Benadering 2: Een geschaalde versie van uw productieomgeving implementeren en onderhouden. Een versie hebben die goed kan functioneren voor een kleine workload en die u mogelijk zo nodig omhoog kunt schalen tijdens een failover voor productiebelasting. Deze methode wordt vaak gebruikt, met name voor complexe implementaties waarin u geen risico wilt lopen om een hele omgeving te maken of als u snel een failover wilt uitvoeren om een lage RTO te bieden.

Benadering 3: Implementeer en onderhoud uw volledige oplossing op de site voor herstel na noodgevallen voor de snelste RTO- en failovertijden. Deze methode verhoogt de kosten als gevolg van het uitvoeren van een volledig redundante infrastructuur.

Overweeg andere manieren om herstel na noodgevallen te implementeren

In de volgende secties worden speciale overwegingen voor herstel na noodgevallen beschreven.

Far Sync gebruiken

Far Sync verbetert de mogelijkheden voor hoge beschikbaarheid niet, maar u kunt deze gebruiken om geen mogelijkheden voor gegevensverlies te bereiken voor Oracle-databases. Uw workload vereist mogelijk geen gegevensverlies als uw primaire database mislukt. Zie Oracle-referentiearchitecturen in Azure voor meer informatie.

De juiste technologie voor gegevensreplicatie kiezen

Naast de technologieën in dit artikel kunt u elke technologie gebruiken die gegevensreplicatie in twee Oracle-databases vereenvoudigt om een replica met hoge beschikbaarheid en een replica voor herstel na noodgevallen te onderhouden voor uw Oracle-databases in Azure. De technologie die u kiest, moet voldoen aan uw oplossingsvereisten in deze categorieën.

Latentie: De hoeveelheid tijd die nodig is om een update van een primaire database naar secundaire databases te repliceren voor hoge beschikbaarheid en herstel na noodgevallen, moet voldoen aan de vereisten van uw oplossing.

Bandbreedte: de hoeveelheid en kosten van bandbreedte die u nodig hebt om gegevens te repliceren naar secundaire databases voor hoge beschikbaarheid en herstel na noodgevallen. Azure biedt een snelle netwerkinfrastructuur tussen beschikbaarheidszones. Wanneer u replicatie naar andere Azure-regio's overweegt voor herstel na noodgevallen, moet u rekening houden met de hoeveelheid bandbreedte en de kosten voor uitgaand verkeer voor gegevens die het Azure-datacenter verlaten.

Impact: Het impactniveau dat replicatie heeft op transactieverwerking op de primaire database moet voldoen aan de vereisten van uw oplossing.

Gegevensverlies: de hoeveelheid gegevensverlies die u verwacht tijdens een plotselinge fout van de primaire database moet voldoen aan de vereisten van uw oplossing.

Totale eigendomskosten: Houd rekening met de aanschafkosten voor een niet-Microsoft-replicatieoplossing en de hoeveelheid inspanning die u nodig hebt om de replicatieoplossing te configureren en te onderhouden. Controleer of deze factoren voldoen aan de vereisten van uw oplossing.

Een failover-exemplaar optimaliseren

Wanneer u Data Guard gebruikt in de modus voor hoge beschikbaarheid of de modus voor hoge beveiliging, kunt u configureren voor automatische failover, zodat wanneer de primaire server mislukt, de secundaire server automatisch wordt weergegeven. Wanneer u toepassingsservers correct configureert, kunt u ervoor zorgen dat er bijna geen downtime van toepassingen is tijdens een failover.

In deze implementatie moet een database hetzelfde uitvoeren na een failover. U moet dus een secundaire server configureren met dezelfde CPU-, geheugen- en I/O-capaciteit (input/output) als de primaire server. U moet een hoge capaciteit onderhouden met een secundaire server, waardoor uw Azure-kosten en Oracle Database-licentiekosten worden verhoogd. De secundaire server verwerkt meestal geen gebruikersaanvragen.

Azure biedt 99,9% beschikbaarheid voor VM's in een beschikbaarheidszone. Zie SLA voor VM-uptime voor meer informatie. Wanneer u een technologie voor gegevensreplicatie gebruikt om een secundaire replica van uw database in dezelfde beschikbaarheidszone, een andere beschikbaarheidszone of een andere regio te onderhouden, kunt u de secundaire capaciteit optimaliseren.

Met deze methode wordt de secundaire database geconfigureerd met de capaciteit die nodig is om up-to-date te blijven. Wanneer er een fout optreedt, wordt de grootte van de secundaire database gewijzigd in dezelfde capaciteit als de primaire database. Deze bewerking treedt alleen op als er een fout optreedt. Tijdens de normale werking betaalt u dus alleen voor een fractie van de kosten van de primaire server. De primaire database is niet operationeel tijdens de fout, dus u hebt geen andere Oracle-databaselicenties nodig.

De capaciteit die u nodig hebt om een secundaire database als replicatiebestemming te gebruiken, is afhankelijk van de replicatietechnologie die u gebruikt. In wezen heeft een workload die zich in een OLTP-systeem (Transactional Online Transaction Processing) bevindt voornamelijk leesaanvragen. Zo zijn 90% lees- en 10% schrijfbewerkingen of 95% leesbewerkingen en 5% schrijfbewerkingen gebruikelijk in OLTP-toepassingen. Gegevensreplicatie repliceert in feite het resultaat van het schrijven van aanvragen in de brondatabase. Met deze installatie kunt u verwachten dat de secundaire database met 1/10e werkt (als u een lees- en 10% schrijfverhouding van 90% hebt) van de capaciteit van de primaire database.

Automatiseer failoverprocedures om ervoor te zorgen dat u voldoet aan bedrijfsstandaarden tijdens het failoverproces. U kunt de failoverprocedures configureren voor het opnemen van bewerkingen voor het wijzigen van de grootte van servers die het end-to-endproces stroomlijnen.

Uw netwerktopologie configureren voor servicebeveiliging en gegevensbeveiliging

Als u hoge beschikbaarheid en herstel na noodgevallen wilt bereiken, moet u financiële en zakelijke beslissingen nemen die de hersteltijd in balans brengen, of RTO, en het potentiële gegevensverlies, of RPO, ten opzichte van andere Oracle-licenties, VM-onderhoud en kosten voor gegevensoverdracht. Wanneer u een workload host op één Azure-VM, krijgt u basisbeveiliging voor veelvoorkomende hardwarefouten tegen lage kosten. Maar een fout op één VIRTUELE machine veroorzaakt waarschijnlijk downtime en gegevensverlies. Neem in uw productieomgevingen dus ten minste één secundaire Oracle-database op die wordt gehost op een afzonderlijke VIRTUELE machine met Data Guard. Gebruik, afhankelijk van uw vereisten, een of meer van de volgende Data Guard-configuraties voor gegevensreplicatie:

Optimale RTO en RPO. Als u de latentie wilt minimaliseren, moet u een secundaire Oracle-database opnemen op een afzonderlijke VIRTUELE machine binnen dezelfde flexibele indeling van virtuele-machineschaalsets en in dezelfde beschikbaarheidszone als de primaire database. Deze configuratie biedt hoge beschikbaarheid en beveiliging tegen een fout met één exemplaar.
Gegevensbescherming tegen een storing in een datacenter. Plaats de secundaire Oracle-database in een tweede beschikbaarheidszone om een installatie met hoge beschikbaarheid te bieden en om beveiliging te bieden als een volledige beschikbaarheidszone uitvalt. Deze configuratie kan maximaal twee milliseconden latentie hebben tussen de primaire en secundaire database, wat van invloed kan zijn op prestaties, RPO's en RPO's.
Gegevensbescherming tegen een regionale storing. U kunt de secundaire database in een andere regio plaatsen om u te beschermen tegen mogelijk gegevensverlies als gevolg van een regionale fout in Azure. Deze configuratie kan tussen 30 milliseconden en 300 milliseconden latentie tussen regio's hebben, zodat u mogelijk niet voldoet aan uw RTO- en RPO-doelen. Deze oplossing is het beste voor regionaal herstel na noodgevallen in plaats van hoge beschikbaarheid.

Bedrijfscontinuïteit vereist een geïntegreerde benadering die alle onderdelen van een workload omvat. Netwerkinfrastructuur is een primair onderdeel voor elke workload in Azure. Uw netwerkinfrastructuur moet worden afgestemd op uw architectuur voor hoge beschikbaarheid of herstel na noodgevallen. Houd rekening met de volgende factoren voor de netwerkinfrastructuur:

Data Guard biedt hoge beschikbaarheid en biedt in de meeste scenario's voldoende ondersteuning voor veelvoorkomende fouten. U kunt virtuele machines in een flexibele indeling van virtuele-machineschaalsets plaatsen. Om de netwerklatentie te verminderen, moeten alle services in één oplossing zich in dezelfde beschikbaarheidszone bevinden en moeten de services hetzelfde virtuele netwerk delen.

Voor verdere beveiliging kunt u vm's strategisch in afzonderlijke beschikbaarheidszones plaatsen in plaats van één beschikbaarheidszone. Deze aanpak kan downtime voorkomen tijdens een storing in een datacenter.
Voor maximale beveiliging kunt u een secundaire database in een andere Azure-regio plaatsen dan de primaire databaseregio. Als u doorlopende updates wilt toepassen, kunt u Data Guard gebruiken om wereldwijde peering voor virtuele netwerken te implementeren. Gebruik deze methode om gegevensupdates privé toe te passen op de secundaire regio via de Microsoft-backbone. Resources communiceren rechtstreeks zonder gateways, extra hops of transit via het openbare internet.

Deze netwerkoptie biedt een verbinding met hoge bandbreedte en lage latentie tussen gekoppelde virtuele netwerken in verschillende regio's. U kunt globale peering voor virtuele netwerken gebruiken om uw primaire site te verbinden met een site voor herstel na noodgevallen in een andere regio via een snel netwerk.

Samenvatting van tolerantie tegen verschillende fouttypen

Foutscenario	Scenario voor hoge beschikbaarheid of herstel na noodgevallen in Oracle in Azure	RPO/RTO
Fout met één onderdeel, zoals een host, rek, koeling, netwerken of stroomstoring	Data Guard met twee knooppunten in dezelfde flexibele indeling van virtuele-machineschaalsets in hetzelfde datacenter: - Beschermt tegen één exemplaarfout. - Veroorzaakt downtime als een volledig datacenter uitvalt.	Als u Waarnemer gebruikt voor snel starten van failover en MAX_AVAILABILITY of MAX_PROTECTION modus voor Data Guard: - RPO is nul. - RTO is kleiner dan of gelijk aan 2 min.
Datacenterfout	Data Guard met twee knooppunten in afzonderlijke beschikbaarheidszones: - Beschermt tegen een storing in een datacenter. - Veroorzaakt downtime als een hele regio uitvalt. - Vereist meer failoverconfiguratie voor app-servers om netwerklatentie te beheren.	- RPO is kleiner dan of gelijk aan 5 min. - RTO is kleiner dan of gelijk aan 5 min. Als u de MAX_PERFORMANCE- en MAX_AVAILABILITY modus voor Data Guard gebruikt: - RPO is nul. - RTO is kleiner dan of gelijk aan 5 min.
Regionale fout	Data Guard met twee knooppunten in afzonderlijke Azure-regio's: - Beschermt tegen regionale storingen. - Vereist meer failoverconfiguratie voor app-servers om netwerklatentie te beheren.	Als u MAX_PERFORMANCE-modus gebruikt voor Data Guard: - RPO is groter dan of gelijk aan 10 min. - RTO is groter dan of gelijk aan 15 min.
Alle scenario's: één onderdeel, datacenter en regiofout	Back-ups die naar een andere Azure-regio worden verzonden: - Bescherming tegen regionale storingen. - Vereisen dat een volledige Azure-omgeving tijdens een failover in de doelregio wordt ingesteld.	- RPO is groter dan of gelijk aan 24 h. - RTO is groter dan of gelijk aan 4 h.

Volgende stap

Meer informatie over ontwerpoverwegingen voor de beveiliging van de landingszoneversneller van Oracle op virtuele machines in een scenario op ondernemingsniveau.

Beveiligingsrichtlijnen voor Oracle op de landingszoneversneller voor virtuele machines

Delen via