Delen via


Overwegingen voor bedrijfscontinuïteit en herstel na noodgevallen voor Oracle Database@Azure

Dit artikel breidt uit op de overwegingen en aanbevelingen voor bedrijfscontinuïteit en herstel na noodgevallen (BCDR), zoals beschreven in het ontwerpgebied voor de Azure-landingszone . Het bevat de Oracle Maximum Availability Architecture (MAA) principes voor Oracle Database@Azure met behulp van Oracle Exadata Database Service.

De eerste stap voor het bouwen van een flexibele architectuur voor uw Oracle-databases die worden uitgevoerd op Oracle Database@Azure is het identificeren van de beschikbaarheidsvereisten voor de oplossing. Het is van cruciaal belang om de beoogde hersteltijd (RTO) en RPO (Recovery Point Objective) vast te stellen voor verschillende niveaus van storingen, waaronder geplande en ongeplande gebeurtenissen. De RTO definieert de maximale downtime die een toepassing of bedrijf kan tolereren na een onderbreking. De RPO geeft de maximale duur aan van gegevensverlies die een toepassing of bedrijf kan tolereren. U moet aan deze vereisten tegemoet komen voordat u begint met het BCDR-ontwerp. Nadat u de vereisten van uw oplossing hebt vastgesteld, kunt u uw Oracle-Database@Azure-omgeving zo ontwerpen dat deze overeenkomt met uw RTO en RPO.

Zie de richtlijnen van Microsoft Azure Well-Architected Framework voor het ontwerpen van een DR-strategievoor meer informatie.

Ontwerpoverwegingen

  • De Oracle Exadata Database@Azure-service is beschikbaar in twee verschillende beschikbaarheidszones binnen een regio. Deze beschikbaarheid zorgt voor servicebetrouwbaarheid en herstel na noodgevallen. Als u de implementatielocatie van uw Oracle Exadata-Database@Azure wilt controleren, controleert u het cluster van uw virtuele machine (VM) in Azure Portal.

  • Oracle Exadata Database@Azure en de kernonderdelen zijn beperkt tot de beschikbaarheidszone waarin u het exemplaar maakt. De service heeft geen betrekking op meerdere zones of omvat meerdere regio's. Als u meerdere zones of multiregionale tolerantie wilt bereiken, kunt u nieuwe Oracle Exadata-Database@Azure-exemplaren implementeren voor doelbeschikbaarheidszones of regio's.

  • Oracle Exadata Database@Azure biedt systeemeigen Oracle-technologieën, zoals Oracle Real Application Clusters voor hoge beschikbaarheid (HA) en Oracle Data Guard voor DR. Data Guard en Active Data Guard worden ondersteund voor dr-architectuur.

  • Oracle Exadata Database@Azure biedt standaard hoge beschikbaarheid voor database-exemplaren en fouten op hardwareniveau. Deze architectuur is afgestemd op het MAA zilverniveau. Geplande onderhoudsbewerkingen kunnen op rollende wijze worden uitgevoerd. Een standaardarchitectuur met één zone heeft echter geen fouttolerantie voor site- of regionale fouten.

  • De oplossing biedt geautomatiseerde Data Guard-configuratie voor disaster recovery. Met deze installatie kunt u voorkomen dat er sitefouten optreden door een andere Oracle Exadata-Database@Azure-implementatie in een andere beschikbaarheidszone of regio te vereisen.

  • Netwerkconnectiviteit tussen primaire en stand-by Oracle Exadata Database@Azure-exemplaren kan tot stand worden gebracht via Azure-netwerken en OCI-netwerken (Oracle Cloud Infrastructure). De primaire route voor deze connectiviteit is standaard via Azure.

  • De drie back-upopties die beschikbaar zijn voor Oracle Exadata Database@Azure zijn:

    • door OCI beheerde back-up: Deze optie omvat twee geïntegreerde oplossingen: Oracle Database Autonomous Recovery Service en Oracle Cloud Infrastructure Object Storage. Deze oplossingen worden beheerd via de OCI-console.

      Autonome Herstelservice is ontworpen voor bedrijfskritieke workloads die strenge RTO- en RPO-vereisten hebben. Het biedt beschikbaarheid via serviceovereenkomsten. Zie voor meer informatie Oracle-platform als een service en infrastructuur als een service openbare cloudservicespijlerdocument.

      OCI Object Storage is een algemene back-upoplossing die geschikt is voor workloads met minder strenge RTO- of RPO-vereisten.

      Deze oplossingen maken automatische planning en beheer van databaseback-ups mogelijk met een vooraf gedefinieerde bewaarperiode. Zie Back-up en herstel van databases beheren op Exadata Database Service op toegewezen Oracle-infrastructuurvoor meer informatie.

    • zelfbeheerde back-up: U kunt Oracle Exadata-Database@Azure configureren voor het streamen van databaseback-ups naar Azure Storage-services, waaronder Azure Blob Storage, Azure Files (via privé-eindpunten) en Azure NetApp Files.

      Voor deze optie is handmatige configuratie en doorlopend onderhoud vereist.

      Voor het gebruik van privé-eindpunten met Oracle Database@Azure is een tussenliggende hop vereist via een routeringsapparaat, zoals een virtueel netwerkapparaat (NVA). Dit apparaat kan een hub NVA zijn, zoals Azure Firewall of een niet-Microsoft NVA. Voor niet-productieomgevingen kan het een toegewezen VM zijn die wordt gebruikt voor doorsturen van IP-adressen, zoals in Een lokale NVA-implementeren. Zie Netwerkplanning voor Oracle Database@Azurevoor meer informatie.

    • niet-Microsoft-back-upoplossingen: U kunt niet-Microsoft-back-upoplossingen gebruiken die beschikbaar zijn in Azure Marketplace, zoals Commvault-, om databaseback-ups te beheren en op te slaan.

Ontwerpaanaanvelingen

Als u een flexibele architectuur wilt bouwen die is afgestemd op uw specifieke vereisten, moet u rekening houden met de volgende BCDR-aanbevelingen voor Oracle Exadata Database@Azure.

U moet ten minste twee Oracle Exadata-Database@Azure-exemplaren configureren met Data Guard om te beschermen tegen storingen met één site. Deze opstelling komt overeen met de MAA goudstandaard.

BCDR met meerdere zones

De BCDR-architectuur met meerdere zones wordt aanbevolen voor klanten die een RPO van nul of bijna nul vereisen, gecombineerd met redundantie over meerdere zones, terwijl ze voldoen aan de vereisten voor gegevensresidentie in één regio.

Deze oplossing omvat een secundaire Implementatie van Oracle Exadata Database@Azure in een andere beschikbaarheidszone binnen dezelfde regio. Implementeer een standby-database in het secundaire exemplaar om veerkracht te garanderen tegen database-, cluster- of beschikbaarheidszonefouten. Deze installatie biedt bescherming tegen fouten op siteniveau.  

  • Data Guard-transportmodus opnieuw uitvoeren: Data Guard-transportmodus opnieuw configureren op basis van uw toepassingsservices en RPO-vereisten:

    • Gegevensintegriteit en nul gegevensverlies: Wanneer gegevensintegriteit en nul gegevensverlies de hoogste prioriteiten zijn, gebruikt u de modus Maximale beschikbaarheid (SYNC). Deze modus repliceert gegevens synchroon naar de stand-bydatabase, waardoor er geen gegevens verloren gaan.

    • Systeemprestaties: Wanneer systeemprestaties kritiek zijn en een kleine mate van gegevensverlies acceptabel is, gebruikt u de modus Maximale prestaties (ASYNC). Deze modus maakt gebruik van asynchrone replicatie, wat resulteert in een RPO die iets groter is dan nul (of bijna nul is).

  • Een symmetrisch stand-by-exemplaar onderhouden: U moet een symmetrisch stand-by-exemplaar onderhouden met resources die gelijk zijn aan de primaire database om consistente prestaties te garanderen tijdens overschakelings- en failoverbewerkingen. U kunt de standbydatabase ook configureren met minimale resources en indien nodig het VM-cluster dynamisch opschalen na een overschakeling of failover. Deze aanpak kan echter extra tijd toevoegen voor schaalbewerkingen en hun reflectie op databaseniveau.

    een diagram van BCDR-architectuur met meerdere zones voor Oracle Exadata Database@Azure Azure-landingszoneversneller.

  • Failoverbewerkingen automatiseren: Gebruik Oracle Data Guard Fast-Start failover- om failoverbewerkingen te automatiseren om RTO te minimaliseren en fouten te verminderen.

    Notitie

    Fast-Start Failover is geen beheerde service en vereist handmatige configuratie.

Voor deze installatie zijn extra VM's met Oracle Data Guard-waarnemers vereist om Data Guard Fast-Start Failover mogelijk te maken. Deze waarnemers-VM's bewaken de database- en replicatiestatus, waarmee het failoverproces wordt geautomatiseerd.

Een diagram van de Fast-Start Failover-architectuur voor Oracle Database@Azure Azure-landingszoneversneller.

Als u een symmetrische DR-architectuur nodig hebt als er een failover is, moet u een waarnemerexemplaar plaatsen op de locatie waar de secundaire Oracle Exadata-Database@Azure-implementatie is geconfigureerd.

Multiregionale BCDR

  • Voor een multiregionale BCDR-strategie implementeert u een secundaire Oracle Exadata Database@Azure implementatie met een stand-bydatabase in een andere regio waar de service beschikbaar is. Deze installatie biedt bescherming tegen volledige regionale storingen.

  • Configureer Data Guard om asynchroon te repliceren voor regionale herstel na noodgevallen die is gebaseerd op uw toepassingsvereisten en netwerklatentie tussen uw primaire en secundaire regio. Zie statistieken voor retourlatentie van Azure-netwerkvoor meer informatie.

    Notitie

    Geautomatiseerde Data Guard staat alleen de ASYNC-configuratie (Maximum Performance Mode) toe voor implementaties in meerdere regio's.

Een diagram van multiregionale BCDR-architectuur voor Oracle Exadata Database@Azure Azure-landingszoneversneller.

  • Aanbevelingen voor meerdere zones en multiregionale BCDR zijn gericht op de veerkracht van databaseservicediensten. Overweeg om azure-services en -functies zoals Azure Virtual Machine Scale Sets, Azure Site Recovery en Azure Front Door te gebruiken om robuuste architectuur in beschikbaarheidszones of regio's te ontwerpen om de algehele tolerantie van workloads te waarborgen.

Uitgebreide BCDR-scenario's

Lokale en externe stand-bydatabases

Om te voldoen aan vereisten voor robuuste servicebeschikbaarheid en tolerantie tegen regionale storingen, raden we u aan meerdere stand-bydatabases te implementeren voor bedrijfskritieke workloads.

Een lokale stand-bydatabase op een Oracle Exadata-Database@Azure-implementatie bevindt zich in een andere beschikbaarheidszone binnen dezelfde regio. Deze installatie biedt een levensvatbare oplossing voor latentiegevoelige toepassingen door te voldoen aan de vereisten voor failover van nul gegevensverlies via SYNC Data Guard-replicatie. Deze strategie zorgt ervoor dat servicebeschikbaarheid wordt gegarandeerd zonder dat dit van invloed is op de doorvoer van toepassingen of de totale reactietijd.

Een externe stand-bydatabase op een Oracle Exadata-Database@Azure-exemplaar dat zich in een andere regio bevindt, voldoet aan regionale dr-vereisten.

Een diagram van de lokale en externe BCDR-architectuur voor Oracle Exadata Database@Azure Azure-landingszoneversneller.

Deze architectuur is ideaal voor bedrijfskritieke workloads en vereist minimaal drie Oracle Exadata-implementaties Database@Azure.

Notitie

Als een symmetrische configuratie is vereist vanwege een failoverscenario, plaatst u een extra stand-bydatabase op Oracle Exadata Database@Azure in de secundaire regio, binnen een andere beschikbaarheidszone.

Data Guard Far Sync-architectuur

U kunt voldoen aan de vereiste om replicatie zonder gegevensverlies op elke afstand te implementeren met behulp van de Data Guard Far Sync-configuratie. Deze aanpak omvat het plaatsen van een ver synchronisatie-exemplaar dichter bij de primaire Oracle Exadata Database@Azure-implementatie, namelijk in een andere beschikbaarheidszone binnen dezelfde regio, om de redo-logboeken synchroon te verzenden. Het far sync-exemplaar draagt deze logboeken vervolgens asynchroon over naar de stand-bydatabase die wordt uitgevoerd in de secundaire Oracle Exadata Database@Azure implementatie in een andere regio. Deze opstelling resulteert effectief in replicatie zonder gegevensverlies tussen regio's.

Een diagram van far sync BCDR-architectuur voor Oracle Exadata Database@Azure Azure-landingszoneversneller.

Als u zoekt naar een symmetrische DR-architectuur als er een failover is, plaatst u een far sync-exemplaar in een afzonderlijke beschikbaarheidszone waarin de secundaire Oracle Exadata-Database@Azure-implementatie is geconfigureerd.

Notitie

De Far Sync-architectuur vereist een Active Data Guard-licentie en moet handmatig worden geconfigureerd.

Aanbevelingen voor back-ups

Als u back-ups wilt gebruiken als enige oplossing voor BCDR-vereisten, moet u er rekening mee houden dat RTO hoger is dan replicatiescenario's, omdat deze is gebaseerd op de databasegrootte en de back-upmethoden die u gebruikt.

  • Back-up maken van gegevens in Azure: Als u wilt voldoen aan de organisatievereisten die gegevens en back-ups in Azure verplicht stellen, kunt u de volgende oplossingen overwegen:

    • Autonome herstelservice (ARS) gebruiken in Azure: Tijdens de configuratie van het back-upbeleid kiest u ervoor om back-upgegevens op te slaan in dezelfde cloudprovider als de database om de ARS in Azure te gebruiken.

    • Storage-services gebruiken: Storage-services zoals Blob Storage, Azure Files en Azure NetApp Files gebruiken om opslag te koppelen als netwerksysteempunten op de databaseserver en RMAN-back-ups (Oracle Recovery Manager) naar Storage te streamen.

  • langetermijnretentie van back-ups: Als uw organisatie langetermijnretentie van back-ups vereist, kunt u zelfbeheerde RMAN-back-ups configureren naar Azure Storage.

  • Back-upconfiguraties voor opslagdiensten: Wanneer back-ups zijn geconfigureerd voor opslagdiensten, houd rekening met de volgende aanbevelingen:

    • Plannen met cron-taken: Cron-taken op databaseknooppuntniveau gebruiken om back-ups op specifieke tijdstippen te plannen op basis van uw back-upstrategie.

    • Back-ups repliceren: Onderliggende functies voor opslagreplicatie van Azure gebruiken, zoals zone-redundante opslag en geografisch redundante opslag om back-ups te repliceren.

  • back-up- en herstelbewerkingen: Handmatig een back-up maken van Oracle Exadata Database@Azure VM's om kritieke bestanden te herstellen als er onbedoelde verwijderingen of beschadigingen zijn. Zie Back-up- en herstelbewerkingen van Oracle Exadata Cloud Compute-knooppunten (document-id 2809393.1)voor meer informatie.

Andere aanbevelingen

  • Gegevens binnen Azure bewaren: Als het nodig is om gegevens exclusief binnen Azure te bewaren, routeert u Data Guard-verkeer via het Azure-netwerk en configureert u back-ups om in Azure te blijven.

  • DR: Test failover- en schakelbewerkingen om te waarborgen dat deze in een echt noodscenario functioneren.

  • realtime gegevens en replicatie: Voor actief-actieve omgevingen kunt u overwegen om Oracle GoldenGate- te gebruiken voor realtime gegevensintegratie- en replicatiemogelijkheden. Het vereist kennis op toepassingsniveau om conflictoplossing effectief af te handelen.

    Notitie

    GoldenGate is niet opgenomen in deze oplossing en kan extra licentiekosten in rekening worden gebracht.

  • Onderbrekingen minimaliseren: Om onderbrekingen voor uw workload te minimaliseren, plant u gepland onderhoud tijdens daluren. Wanneer u dat kunt, kunt u doorlopende updates gebruiken om een naadloos proces te garanderen.

  • Infrastructuur gebruiken als code (IaC): Implementeer de eerste Oracle Exadata-Database@Azure-instantie en VM-clusters met behulp van IaC voor meer betrouwbare infrastructuurautomatisering. Zie QuickStart Oracle Database@Azure met Terraform- of OpenTofu-modulesvoor meer informatie over Oracle Database@Azure automatisering.