Överväganden för affärskontinuitet och haveriberedskap för Oracle Database@Azure
Denna artikel utökar de överväganden och rekommendationer för affärskontinuitet och haveriberedskap (BCDR) som beskrivs i Azure-landningszonen designområde . Den innehåller principerna Oracle Maximum Availability Architecture (MAA) för Oracle Database@Azure med hjälp av Oracle Exadata Database Service.
Det första steget för att skapa en elastisk arkitektur för dina Oracle-databaser som körs på Oracle Database@Azure är att identifiera tillgänglighetskraven för lösningen. Det är viktigt att fastställa mål för återställningstid (RTO) och mål för återställningspunkter (RPO) för olika nivåer av fel, inklusive planerade och oplanerade händelser. RTO definierar den maximala stilleståndstid som ett program eller företag kan tolerera efter ett avbrott. RPO anger den maximala varaktigheten för dataförlust som ett program eller företag kan tolerera. Du bör åtgärda den här förutsättningen innan du påbörjar BCDR-designen. När du har fastställt kraven för din lösning kan du utforma din Oracle-Database@Azure miljö så att den överensstämmer med din RTO och RPO.
Mer information finns i Riktlinjerna för Microsoft Azure Well-Architected Framework om hur du utforma en DR-strategi.
Utformningsbeaktanden
Oracle Exadata Database@Azure-tjänsten är tillgänglig i två olika tillgänglighetszoner i en region. Den här tillgängligheten hjälper till att säkerställa tjänstens tillförlitlighet och DR. Kontrollera distributionsplatsen för Oracle Exadata-Database@Azure genom att kontrollera klustret för den virtuella datorn (VM) i Azure-portalen.
Oracle Exadata Database@Azure och dess kärnkomponenter är begränsade till tillgänglighetszonen där du skapar instansen. Tjänsten omfattar inte flera zoner eller sträcker sig över flera regioner. För att uppnå återhämtning med flera zoner eller flera regioner kan du distribuera nya Oracle Exadata-Database@Azure instanser till måltillgänglighetszoner eller regioner.
Oracle Exadata Database@Azure tillhandahåller inbyggda Oracle-tekniker, till exempel Oracle Real Application Clusters för hög tillgänglighet (HA) och Oracle Data Guard för DR. Data Guard och Active Data Guard stöds för DR-arkitektur.
Oracle Exadata Database@Azure tillhandahåller hög tillgänglighet för databasinstanser och maskinvarunivåfel som en standardfunktion. Den här arkitekturen överensstämmer med MAA silvernivå. Planerade underhållsåtgärder kan utföras löpande. En standardarkitektur med en zon har dock noll feltolerans mot platsfel eller regionala fel.
Lösningen tillhandahåller automatiserad Data Guard-konfiguration för DR. Den här konfigurationen skyddar mot platsfel genom att kräva en annan Oracle Exadata-Database@Azure distribution i en annan tillgänglighetszon eller region.
Nätverksanslutning mellan primära och standbyinstanser av Oracle Exadata Database@Azure kan upprättas via Azure-nätverk och OCI-nätverk. Som standard är den primära vägen för den här anslutningen via Azure.
De tre säkerhetskopieringsalternativ som är tillgängliga för Oracle Exadata Database@Azure är:
OCI-hanterad säkerhetskopiering: Det här alternativet innehåller två integrerade lösningar, som är Oracle Database Autonomous Recovery Service och Oracle Cloud Infrastructure Object Storage. Dessa lösningar hanteras via OCI-konsolen.
Autonomous Recovery Service är utformad för verksamhetskritiska arbetsbelastningar på företagsnivå som har strikta krav på RTO och RPO. Det ger tillgänglighet via serviceavtal. Mer information finns i Oracle-plattform som en tjänst och infrastruktur som en tjänst för offentliga molntjänster.
OCI Object Storage är en generell säkerhetskopieringslösning som är lämplig för arbetsbelastningar som har mindre strikta RTO- eller RPO-krav.
De här lösningarna möjliggör automatisk schemaläggning och hantering av säkerhetskopior av databaser med en fördefinierad kvarhållningsperiod. Mer information finns i Hantera säkerhetskopiering och återställning av databaser på Exadata Database Service på Oracles dedikerade infrastruktur.
självhanterad säkerhetskopiering: Du kan konfigurera Oracle Exadata Database@Azure för att strömma databassäkerhetskopior till Azure Storage-tjänster, inklusive Azure Blob Storage, Azure Files (via privata slutpunkter) och Azure NetApp Files.
Det här alternativet kräver manuell konfiguration och löpande underhåll.
Användning av privata slutpunkter med Oracle Database@Azure kräver ett mellanliggande hopp via en routningsenhet, till exempel en virtuell nätverksinstallation (NVA). Den här enheten kan vara en hubb-NVA, till exempel Azure Firewall, eller en icke-Microsoft NVA. För icke-produktionsmiljöer kan det vara en dedikerad virtuell dator som används för IP-adressvidarebefordring som i Distribuera en lokal NVA-. Mer information finns i Nätverksplanering för Oracle Database@Azure.
säkerhetskopieringslösningar som inte kommer från Microsoft: Du kan använda säkerhetskopieringslösningar som inte är microsoft-lösningar som är tillgängliga på Azure Marketplace, till exempel Commvault, för att hantera och lagra säkerhetskopior av databaser.
Designrekommendationer
Om du vill skapa en elastisk arkitektur som är anpassad efter dina specifika krav bör du överväga följande BCDR-rekommendationer för Oracle Exadata Database@Azure.
Du bör konfigurera minst två Oracle Exadata-Database@Azure-instanser med Data Guard för att skydda mot fel på en enda plats. Den här konfigurationen överensstämmer med MAA Gold Standard.
BCDR med flera zoner
BCDR-arkitekturen med flera zoner rekommenderas för kunder som behöver ett noll- eller nästan noll-RPO med redundans med flera zoner när de uppfyller datahemvistkraven för en region.
Den här lösningen innehåller en sekundär Oracle Exadata-Database@Azure distribution i en annan tillgänglighetszon inom samma region. För att säkerställa motståndskraft mot databas-, kluster- eller tillgänglighetszonfel implementerar du en väntelägesdatabas som finns i den sekundära instansen. Den här konfigurationen ger skydd mot fel på platsnivå.
Data Guard gör om transportläget: Konfigurera Data Guard gör om transportläget enligt dina programtjänster och RPO-krav:
Dataintegritet och noll dataförlust: När dataintegritet och noll dataförlust är de högsta prioriteterna använder du SYNC (Maximum Availability Mode). Det här läget replikerar synkront data till väntelägesdatabasen, vilket säkerställer att inga data går förlorade.
Systemprestanda: När systemets prestanda är kritisk och en liten grad av dataförlust är acceptabel använder du ASYNC (Maximum Performance Mode). Det här läget använder asynkron replikering, vilket resulterar i ett RPO som är något större än noll (eller är nära noll).
Underhåll en symmetrisk standby-instans: Du bör underhålla en symmetrisk standby-instans med resurser som motsvarar den primära databasen för att säkerställa konsekventa prestanda under växlings- och redundansåtgärder. Du kan också konfigurera väntelägesdatabasen med minimala resurser och skala upp det virtuella datorklustret dynamiskt efter växling eller redundansväxling. Den här metoden kan dock lägga till extra tid för skalningsåtgärder och deras reflektion på databasnivå.
Automatisera övergångsoperationer: Använd Oracle Data Guard Fast-Start övergång för att automatisera övergångsoperationen för att minimera RTO och minska fel.
Anteckning
Fast-Start Failover är inte en hanterad tjänst och kräver manuell konfiguration.
För den här konfigurationen krävs extra virtuella datorer som kör Oracle Data Guard-observatörer för att aktivera Data Guard Fast-Start failover. Dessa virtuella övervakningsdatorer övervakar databasen och replikeringsstatusen, vilket automatiserar redundansväxlingsprocessen.
Om du behöver en symmetrisk DR-arkitektur vid en failover-situation bör du placera en observatörsinstans på den plats där den sekundära Oracle Exadata Database@Azure-implementeringen har konfigurerats.
Multiregional BCDR
För en BCDR-strategi för flera regioner implementerar du en sekundär Oracle Exadata-Database@Azure distribution med en väntelägesdatabas som finns i en annan region där tjänsten är tillgänglig. Den här konfigurationen ger skydd mot fullständiga regionala avbrott.
Konfigurera Data Guard för att replikera asynkront för regional dr som baseras på dina programkrav och nätverksfördröjning mellan din primära och sekundära region. För mer information, se statistik för svarstidsfördröjning i Azure-nätverket.
Notera
Automatiserad Data Guard tillåter endast konfigurationen för maximalt prestandaläge (ASYNC) för distributioner mellan regioner.
- BCDR-rekommendationer för flera zoner och flera regioner fokuserar på återhämtning av databastjänster. För att säkerställa övergripande återhämtning av arbetsbelastningen kan du överväga att använda Azure-tjänster och funktioner som Azure Virtual Machine Scale Sets, Azure Site Recovery och Azure Front Door för att utforma robust arkitektur mellan tillgänglighetszoner eller regioner.
Utökade BCDR-scenarier
Lokala databaser och fjärranslutna väntelägesdatabaser
För att uppfylla kraven för robust tjänsttillgänglighet och motståndskraft mot regionala avbrott rekommenderar vi att du implementerar flera väntelägesdatabaser för verksamhetskritiska arbetsbelastningar.
En lokal väntelägesdatabas på en Oracle Exadata-Database@Azure distribution finns i en annan tillgänglighetszon i samma region. Den här konfigurationen ger en fungerande lösning för svarstidskänsliga program genom att hantera redundanskraven för noll dataförlust via SYNC Data Guard-replikering. Den här strategin hjälper till att säkerställa tjänsttillgänglighet utan att påverka programmets dataflöde eller övergripande svarstid.
En fjärransluten väntelägesdatabas på en Oracle Exadata-Database@Azure-instans som finns i en annan region uppfyller regionala DR-krav.
Den här arkitekturen är perfekt för verksamhetskritiska arbetsbelastningar och kräver minst tre Oracle Exadata-Database@Azure distributioner.
Obs.
Om en symmetrisk konfiguration krävs på grund av ett redundansscenario placerar du en extra väntelägesdatabas på Oracle Exadata Database@Azure i den sekundära regionen inom en annan tillgänglighetszon.
Data Guard Far Sync-arkitektur
Du kan uppfylla kravet på att implementera replikering utan dataförlust på valfritt avstånd med hjälp av Data Guard Far Sync-konfigurationen. Den här metoden omfattar att placera en fjärrsynkron instans närmare den primära distributionen av Oracle Exadata-databasen på Azure, i princip i en annan tillgänglighetszon inom samma region, för att synkront skicka redo-loggarna. Den fjärransynkrona synkroniseringsinstansen överför sedan loggarna asynkront till väntelägesdatabasen som körs i den sekundära Oracle Exadata-Database@Azure distributionen i en annan region. Den här konfigurationen resulterar i en replikering utan dataförlust mellan regioner.
Om du behöver en symmetrisk DR-arkitektur vid redundansväxling, placerar du en instans för fjärrsynkronisering i en separat tillgänglighetszon där den sekundära Oracle Exadata-Database@Azure-distributionen är konfigurerad.
Notera
Far Sync-arkitekturen kräver en Active Data Guard-licens och måste konfigureras manuellt.
Rekommendationer för säkerhetskopiering
Om du planerar att använda säkerhetskopior som din enda lösning för BCDR-krav bör du tänka på att RTO är högre jämfört med replikeringsscenarier eftersom det baseras på databasens storlek och de säkerhetskopieringsmetoder som du använder.
Säkerhetskopiera data i Azure: Om du vill uppfylla organisationens krav som kräver att data och säkerhetskopior finns kvar i Azure bör du överväga följande lösningar:
Använd Autonomous Recovery Service (ARS) i Azure: Under konfigurationen av säkerhetskopieringsprinciper väljer du att lagra säkerhetskopierade data i samma molnleverantör som databasen för att använda ARS i Azure.
Använd lagringstjänster: Använda lagringstjänster som Blob Storage, Azure Files och Azure NetApp Files för att montera lagring som nätverksfilsystempunkter på databasservern och strömma RMAN-säkerhetskopior (Oracle Recovery Manager) till Storage.
Långsiktig kvarhållning av säkerhetskopior: Om din organisation kräver långsiktig kvarhållning av säkerhetskopior kan du konfigurera självhanterade RMAN-säkerhetskopieringar till Azure Storage.
Konfigurationer för lagringssäkerhetskopiering: När säkerhetskopior konfigureras för lagringstjänster bör du överväga följande rekommendationer:
Schemalägg med cron-jobb: Använd cron-jobb på databasnodnivå för att schemalägga säkerhetskopieringar vid specifika tidpunkter baserat på din säkerhetskopieringsstrategi.
Replikera säkerhetskopior: Använd underliggande lagringsreplikeringsfunktioner från Azure som zonredundant lagring och geo-redundant lagring för att replikera säkerhetskopior.
Säkerhetskopierings- och återställningsåtgärder: Säkerhetskopiera manuellt Oracle Exadata Database@Azure virtuella datorer för att återställa kritiska filer om det finns oavsiktliga borttagningar eller filskador. Mer information finns i Oracle Exadata Cloud Compute-nodsäkerhets- och återställningsåtgärder (dokument-ID 2809393.1).
Andra rekommendationer
Behåll data i Azure: Om du behöver lagra data exklusivt i Azure dirigerar du Data Guard-trafik via Azure-nätverket och konfigurerar säkerhetskopior så att de finns kvar i Azure.
Test DR: Testa redundans- och växlingsåtgärder för att säkerställa att de fungerar i ett verkligt katastrofscenario.
Använd Oracle Fast-Start Redundansväxling för att automatisera redundansväxling när det är möjligt att minimera fel.
Använd Oracle-programkontinuitet för att sömlöst maskera avbrott på programnivån.
Realtidsdata och replikering: För aktiva miljöer bör du överväga att använda Oracle GoldenGate- för dataintegrering och replikeringsfunktioner i realtid. Det kräver medvetenhet på programnivå för att hantera konfliktlösning effektivt.
Not
GoldenGate ingår inte i den här lösningen och kan medföra extra licenskostnader.
Minimera avbrott: Om du vill minimera avbrott för din arbetsbelastning bör du schemalägga planerat underhåll under låg belastning. När det är möjligt, använd löpande uppdateringar för att säkerställa en sömlös process.
Använd infrastruktur som kod (IaC): Distribuera de första Oracle Exadata-Database@Azure-instans- och VM-kluster med hjälp av IaC för mer tillförlitlig infrastrukturautomatisering. Mer information om Oracle Database@Azure automation finns i Snabbstart Oracle Database@Azure med Terraform- eller OpenTofu-moduler.
Använd Azure-verifierade moduler för att distribuera Oracle Exadata Database@Azure-instanser och VM-kluster. Mer information finns i följande resurser:
Använd IaC för att distribuera databaser i OCI-kontrollplanet. Du kan använda IaC för att replikera samma distribution till en DR-plats och minimera risken för mänskliga fel.