Affärskontinuitet och haveriberedskap för Oracle på Azure Virtual Machines accelerator för landningszoner

2025-06-21

Den här artikeln bygger på de överväganden och rekommendationer som definieras i designområdet för Azure-landningszonen för affärskontinuitet och haveriberedskap (BCDR). Den här artikeln följer den vägledningen och beskriver designöverväganden och metodtips för BCDR-alternativ för Oracle-arbetsbelastningsdistributioner på virtuella datorer i Azure-infrastrukturen (VM).

Azure tillhandahåller tjänster som du kan använda för att utforma motståndskraftiga arkitekturer med hög tillgänglighet. Den här guiden beskriver olika alternativ och metodtips som hjälper dig att utforma hög tillgänglighet och haveriberedskap för Oracle-databaser på Azure Virtual Machines accelerator för landningszoner. Den beskriver också hur du konfigurerar tillhörande Azure-tjänster för att hjälpa dig att uppnå hög tillgänglighet från slutpunkt till slutpunkt för din lösning.

Kom igång

Om du vill skapa en motståndskraftig arkitektur för din arbetsbelastningsmiljö fastställer du tillgänglighetskraven för din lösning baserat på målet för återställningstid (RTO) och målet för återställningspunkt (RPO) för olika felnivåer. RTO är den maximala tid som ett program förblir otillgängligt efter att en incident har inträffat. RPO är den maximala mängden dataförlust under en katastrof. När du har fastställt kraven för din lösning utformar du arkitekturen så att den ger de etablerade återhämtnings- och tillgänglighetsnivåerna.

Oracle på Azure-arbetsbelastningar använder främst Oracle Data Guard, som är en inbyggd Oracle Database Enterprise Edition-funktion som använder replikeringsteknik. Du kan använda Data Guard för att uppfylla behoven av hög tillgänglighet och haveriberedskap. Data Guard erbjuder tre skyddslägen: maximal prestanda, maximal tillgänglighet och maximalt skydd. Välj ditt skyddsläge baserat på din arkitektoniska design och dina specifika RPO- och RTO-krav.

Konfigurera din arbetsbelastning för hög tillgänglighet

Azure Virtual Machines-instanser som kör Oracle-arbetsbelastningar drar nytta av Azure Virtual Machine Scale Sets-arkitekturen, särskilt det flexibla orkestreringsläget. En konfiguration med hög tillgänglighet ger datareplikering i nära realtid med potentiellt snabba redundansfunktioner. En konfiguration med hög tillgänglighet ger inte skydd för fel på Azure-datacenternivå eller regionnivå.

Välj rätt alternativ för hög tillgänglighet

Använd följande flödesschema för att välja det bästa alternativet för hög tillgänglighet för din Oracle-databas.

Använda Data Guard i läget för maximal tillgänglighet för hög tillgänglighet

Data Guard i läget för maximal tillgänglighet ger högsta tillgänglighet med ett löfte om noll dataförlust (RPO=0) för normal drift. För en konfiguration med hög tillgänglighet av två Oracle-databasservrar som skapas i en flexibel orkestrering av Virtual Machine Scale Sets tillhandahåller Azure 99,95% tjänsttillgänglighet för ett serviceavtal (SLA) för instanser som är spridda över feldomäner. Azure tillhandahåller 99,99% tjänsttillgänglighet för instanser som är spridda över tillgänglighetszoner. Mer information finns i Hög tillgänglighet för Virtual Machine Scale Sets.

En stegvis konfiguration av Data Guard på Azure finns i Implementera Oracle Data Guard på en Linux-baserad virtuell Azure-dator.

Använd Data Guard i maximalt skyddsläge för hög tillgänglighet

Om du behöver en transaktionsmässigt konsekvent kopia av databasen bör du överväga att använda Data Guard i maximalt skyddsläge. Maximalt skyddsläge tillåter dock inte att transaktioner fortsätter när väntelägesdatabasen inte är tillgänglig. Trots att du använder flexibel orkestrering av Virtual Machines Scale Sets reduceras därför ditt serviceavtal till 99,9% x 99,9% = 99,8% när du använder maximalt skyddsläge. Den här konfigurationen säkerställer en konsekvent kopia av data men ökar inte nödvändigtvis tillgängligheten.

Andra attribut för den här arkitekturen är desamma som läget för maximal tillgänglighet. RPO är till exempel noll och RTO är mindre än eller lika med två minuter.

Överväg andra sätt att implementera hög tillgänglighet

I följande avsnitt beskrivs särskilda överväganden för hög tillgänglighet.

Använda tillgänglighetszoner för förbättrad hög tillgänglighet

Azure-tillgänglighetszoner är Azure-datacenter som finns inom samma Azure-region. Tillgänglighetszoner har en svarstid tur och retur på mindre än två millisekunder. Du använder vanligtvis tillgänglighetszoner i haveriberedskapssyfte, men du kan använda dem för att förbättra hög tillgänglighet. Om du gör det måste du se till att din lösning kan köras med den mängd svarstid och dataflöde som dina tillgänglighetszoner tillhandahåller.

En fördel med tillgänglighetszoner med en flexibel orkestrering av Virtual Machine Scale Sets är att serviceavtalet för VM-tillgänglighet ökar till 99,99%.

Använda delad lagringsklustring för hög tillgänglighet

Tekniker för delad lagringsklustring ger unika attribut som kan hjälpa dig att uppnå dina affärsmål. Du kan till exempel implementera ett PCS-kluster (Pacemaker- och Corosync) med delad lagring. Du kan använda hanterade diskar eller Azure NetApp Files som delad lagring för PCS-klusterinstanser. Ett PCS-kluster duplicerar inte data. Den tillhandahåller en virtuell IP-tjänst med en statisk IP-adress eller ett IP-nätverksnamn som inte ändras vid redundans.

Anmärkning

Ett PCS-kluster är inte en Oracle-certifierad lösning. Tänk på den här faktorn när du väljer din arkitektur med hög tillgänglighet.

Använda närhetsplaceringsgrupper

För att ge lägsta möjliga svarstid placerar du virtuella datorer så nära som möjligt. Du kan distribuera dem i en närhetsplaceringsgrupp. En närhetsplaceringsgrupp är en logisk gruppering som säkerställer att Azure-beräkningsresurser finns fysiskt nära varandra. Närhetsplaceringsgrupper är användbara för arbetsbelastningar som kräver låg latens.

Konfigurera din arbetsbelastning för haveriberedskap

En haveriberedskapsarkitektur ger återhämtning mot fel som påverkar Azure-datacenter eller regioner eller mot fel som hindrar programfunktioner i en hel region. I ett sådant scenario bör du flytta hela arbetsbelastningen till ett annat datacenter eller en annan region.

Välj din haveriberedskapsarkitektur baserat på dina lösningskrav. Du fastställer dina krav baserat på ditt RTO och RPO. Haveriberedskapsarkitekturer är avsedda för exceptionella felfall, så redundansprocesser är manuella. I designen med hög tillgänglighet är redundansprocesser automatiska. I en haveriberedskapsarkitektur bör du ha mer avslappnade krav på RTO och RPO, vilket sparar pengar.

Den här artikeln fokuserar på scenarier där både den primära servern och de sekundära servrarna finns i Azure. Du kan också ha en primär server lokalt och en sekundär server i Azure i haveriberedskapssyfte. Mer information finns i Primär plats lokalt och haveriberedskapsplats i Azure.

Välj rätt alternativ för haveriberedskap

Använd följande flödesschema för att välja det bästa haveriberedskapsalternativet för din Oracle-databas.

Använda Data Guard för haveriberedskap

Du kan använda Data Guard för att replikera data till din haveriberedskapsplats. Använd webbplatsen som en annan tillgänglighetszon i samma region eller i en annan region beroende på dina krav på dataskydd. Konfigurationen beror också på tillgänglighetszonstrukturen på produktionsplatsen. En Data Guard-implementering i ett haveriberedskapsscenario liknar det scenario med hög tillgänglighet som diskuterats tidigare, med några viktiga skillnader. Till exempel:

När du redundansväxlar till en sekundär replik i scenariot med hög tillgänglighet konfigurerar du Azure Load Balancer för att omdirigera begäranden till den nya primära databasinstansen.
När du redundansväxlar till haveriberedskapsplatsen redundansväxlar du hela lösningen till den nya platsen. För att undvika svarstidsutmaningar behöver du vanligtvis konfigurera redundans för programtjänster.

Om haveriberedskapsplatsen finns i en annan region måste du utforma platsen för redundansväxlingen beroende på dina krav.

Svarstiden i ett enda datacenter är mindre än svarstiden mellan datacenter som är separerade långt från varandra och mycket mindre än svarstiden mellan olika regioner. Därför är det minst komplexa och billigaste alternativet att använda Data Guard i maximalt prestandaläge för haveriberedskap. Om den potentiella dataförlusten i läget för maximal prestanda är för hög kan du använda läget för maximal tillgänglighet med Oracle Data Guard Far Sync-mekanismen. Men en Far Sync-instans utlöser Active Data Guard-licensiering i den primära miljön och väntelägesmiljön. Mer information finns i Oracle-licensinformation.

När du skickar data mellan Azure-regioner eller datacenter betalar du dessutom utgående kostnader för data, till exempel gör om loggar, som skickas till en haveriberedskapsplats. Om du inte behöver replikera alla data i databasen kan du använda Oracle Golden Gate-baserad replikering för att endast replikera partiella data efter behov, vilket minskar utgående kostnader.

En stegvis konfiguration av Data Guard på Azure finns i Implementera Data Guard på en Linux-baserad virtuell Azure Linux-dator.

Använda Golden Gate för haveriberedskap

Golden Gate är en programvara för logisk replikering som du kan använda för replikering, filtrering och omvandling av data i realtid från en källdatabas till en måldatabas eller mellan flera primära databaser. Den här funktionen säkerställer att ändringar i källdatabasen replikeras nästan i realtid så att måldatabasen är uppdaterad med de senaste data.

Du kan använda Golden Gate för att replikera data från en primär databas till en sekundär databas i en haveriberedskapskonfiguration. Golden Gate är särskilt praktiskt om du bara behöver skydda en del av dina data. För att undvika replikering av onödiga data använder du Golden Gate för att selektivt replikera tabeller och filtrera bort tabellrader under replikeringen.

En steg-för-steg-guide om hur du implementerar Golden Gate på Azure finns i Implementera Golden Gate på en Linux-baserad virtuell Azure-dator.

Använda säkerhetskopiering för haveriberedskap

Säkerhetskopiering och återställning är en traditionell metod för en haveriberedskapsarkitektur. Det finns två huvudkomponenter för säkerhetskopiering som en haveriberedskapsmetod för Oracle-databaser i Azure:

Extrahera och flytta säkerhetskopian av data från en databas för att säkerställa att haveriberedskapsplatsen har up-todatumdata.
Se till att distributionen är up-todatum på haveriberedskapsplatsen. Om du vill uppdatera platsen replikerar du samma distribution av alla nätverkskomponenter, programservrar och konfigurationer till haveriberedskapsplatsen.

Det finns flera alternativ för säkerhetskopiering som du kan använda för att replikera data. Mer information finns i Strategier för säkerhetskopiering för Oracle Database på Azure.

Överväg att använda någon av följande metoder för att underhålla en haveriberedskapsplats:

Tillvägagångssätt 1: För att undvika extra underhållsarbete och kostnader ska du inte underhålla någon fysisk distribution på haveriberedskapsplatsen. Du kan använda infrastruktur som kod och tekniska metoder för platstillförlitlighet för att utveckla och underhålla en lagringsplats. Den här lagringsplatsen kan replikera distributionen som konfiguration till en haveriberedskapsplats vid tidpunkten för redundansväxlingen. Den här metoden optimerar kostnaden eftersom den inte använder några fysiska resurser förrän redundansväxlingen inträffar.

Viktigt!

Om du skapar en hel distribution från grunden under en redundansväxling måste du se till att distributionen kan uppfylla lösningens RTO-krav. För att säkerställa att distributionskoden inte är bruten måste du rutinmässigt simulera och testa haveriberedskapsscenariot.

Tillvägagångssätt 2: Distribuera och underhålla en skalad version av produktionsmiljön. Ha en version som kan fungera korrekt för en liten arbetsbelastning och som du potentiellt kan skala upp efter behov under en redundansväxling för att hantera produktionsbelastningen. Den här metoden används ofta, särskilt för komplexa distributioner där du inte vill riskera att skapa en hel miljö eller om du vill redundansväxla snabbt för att ge en låg RTO.

Tillvägagångssätt 3: Distribuera och underhåll hela lösningen på haveriberedskapsplatsen för de snabbaste RTO- och redundanstiderna. Den här metoden ökar kostnaderna på grund av att du kör en helt redundant infrastruktur.

Överväg andra sätt att implementera haveriberedskap

I följande avsnitt beskrivs särskilda överväganden för haveriberedskap.

Använd Far Sync

Far Sync förbättrar inte funktionerna för hög tillgänglighet, men du kan använda den för att uppnå funktioner för skydd mot dataförlust för Oracle-databaser. Din arbetsbelastning kan kräva ingen dataförlust om den primära databasen misslyckas. Mer information finns i Oracle-referensarkitekturer i Azure.

Välj rätt teknik för datareplikering

Förutom teknikerna i den här artikeln kan du använda valfri teknik som underlättar datareplikering över två Oracle-databaser för att upprätthålla en replik med hög tillgänglighet och en haveriberedskapsreplik för dina Oracle-databaser i Azure. Den teknik som du väljer måste uppfylla dina lösningskrav i dessa kategorier.

Latens: Den tid det tar att replikera en uppdatering från en primär databas till sekundära databaser för hög tillgänglighet och haveriberedskap bör uppfylla lösningens krav.

Bandbredd: Mängden och kostnaden för bandbredd som du behöver för att replikera data till sekundära databaser för hög tillgänglighet och haveriberedskap. Azure tillhandahåller en nätverksinfrastruktur med hög hastighet mellan tillgänglighetszoner. När du överväger replikering till andra Azure-regioner i haveriberedskapssyfte bör du överväga mängden bandbredd och utgående kostnader för data som lämnar Azure-datacentret.

Effekt: Den nivå av påverkan som replikeringen har på transaktionsbearbetningen på den primära databasen bör uppfylla lösningens krav.

Förlust av data: Mängden dataförlust som du förväntar dig under ett plötsligt fel i den primära databasen bör uppfylla lösningens krav.

Total ägandekostnad: Överväg kostnaden för förvärv för en replikeringslösning som inte kommer från Microsoft och hur mycket arbete du behöver för att konfigurera och underhålla replikeringslösningen. Kontrollera att dessa faktorer uppfyller lösningens krav.

Optimera en redundansinstans

När du använder Data Guard i läge för hög tillgänglighet eller högt skydd kan du konfigurera för automatisk redundans så att den sekundära servern öppnas automatiskt när den primära servern misslyckas. När du konfigurerar programservrar korrekt kan du se till att du nästan inte har några programavbrott under en redundansväxling.

I den här implementeringen måste en databas köras på samma sätt efter en redundansväxling. Därför måste du konfigurera en sekundär server med samma CPU, minne och indata-/utdatakapacitet (I/O) som den primära servern. Du måste upprätthålla en hög kapacitet med en sekundär server, vilket ökar dina Azure-kostnader och Oracle Database-licenskostnader. Den sekundära servern bearbetar vanligtvis inte användarförfrågningar.

Azure tillhandahåller 99,9% tillgänglighet för virtuella datorer i en tillgänglighetszon. Mer information finns i Serviceavtal för VM-drifttid. När du använder en datareplikeringsteknik för att underhålla en sekundär replik av databasen i samma tillgänglighetszon, en annan tillgänglighetszon eller en annan region kan du optimera den sekundära kapaciteten.

Med den här metoden konfigureras den sekundära databasen med den kapacitet som den behöver för att hålla sig uppdaterad. När ett fel inträffar ändras storleken på den sekundära databasen till samma kapacitet som den primära databasen. Den här åtgärden utförs bara om det uppstår ett fel. Så under normal drift betalar du bara för en bråkdel av kostnaden för den primära servern. Den primära databasen fungerar inte under felet, så du behöver inga andra Oracle-databaslicenser.

Vilken kapacitet du behöver för att använda en sekundär databas som replikeringsmål beror på vilken replikeringsteknik du använder. I princip har en arbetsbelastning som finns i ett OLTP-system (Transactional Online Transaction Processing) huvudsakligen läsbegäranden. Till exempel är 90% läs- och 10% skrivåtgärder eller 95% läs- och 5% skrivåtgärder vanliga i OLTP-program. Datareplikering replikerar i princip resultatet av att skriva begäranden i källdatabasen. Med den här konfigurationen kan du förvänta dig att den sekundära databasen fungerar med 1/10 (om du har ett läs- och skrivförhållande på 90% 10%) av den primära databasens kapacitet.

Automatisera redundansprocedurer för att säkerställa att du uppfyller företagets standarder under redundansväxlingsprocessen. Du kan konfigurera redundansprocedurerna så att de omfattar åtgärder för att ändra storlek på servern som effektiviserar processen från slutpunkt till slutpunkt.

Konfigurera nätverkstopologin för tjänstskydd och dataskydd

För att uppnå hög tillgänglighet och haveriberedskap måste du fatta ekonomiska och affärsmässiga beslut som balanserar återställningstiden, eller RTO, och den potentiella dataförlusten, eller RPO, mot andra Oracle-licensierings-, VM-service- och dataöverföringskostnader. När du är värd för en arbetsbelastning på en enda virtuell Azure-dator får du grundläggande skydd för vanliga maskinvarufel till en låg kostnad. Men ett fel på en enskild virtuell dator orsakar troligen driftstopp och dataförlust. I dina produktionsmiljöer bör du därför inkludera minst en sekundär Oracle-databas som finns på en separat virtuell dator med Data Guard. Beroende på dina krav använder du en eller flera av följande Data Guard-konfigurationer för datareplikering:

Optimal RTO och RPO. För att minimera svarstiden bör du införliva en sekundär Oracle-databas på en separat virtuell dator i samma flexibla orkestrering av Virtual Machine Scale Sets och i samma tillgänglighetszon som den primära databasen. Den här konfigurationen ger hög tillgänglighet och skydd mot ett fel med en enda instans.
Dataskydd mot ett datacenterfel. Placera den sekundära Oracle-databasen i en andra tillgänglighetszon för att tillhandahålla en konfiguration med hög tillgänglighet och för att ge skydd om en hel tillgänglighetszon misslyckas. Den här konfigurationen kan ha upp till två millisekunders svarstid mellan den primära och sekundära databasen, vilket kan påverka prestanda, RTO:er och RPO:er.
Dataskydd mot ett regionalt fel. För att skydda mot potentiell dataförlust på grund av ett regionalt Azure-fel kan du placera den sekundära databasen i en annan region. Den här konfigurationen kan ha mellan 30 millisekunder och 300 millisekunders svarstid mellan regioner, så du kanske inte uppfyller dina RTO- och RPO-mål. Den här lösningen är bäst för regional haveriberedskap i stället för hög tillgänglighet.

Affärskontinuitet kräver en integrerad metod som omfattar alla komponenter i en arbetsbelastning. Nätverksinfrastrukturen är en primär komponent för alla arbetsbelastningar i Azure. Nätverksinfrastrukturen måste anpassas till din arkitektur för hög tillgänglighet eller haveriberedskap. Tänk på följande faktorer för nätverksinfrastruktur:

Data Guard ger hög tillgänglighet och ger i de flesta scenarier tillräckligt med stöd för vanliga fel. Du kan placera virtuella datorer i en flexibel orkestrering av Virtual Machine Scale Sets. För att minska nätverksfördröjningen bör alla tjänster i en enda lösning finnas i samma tillgänglighetszon och tjänsterna bör dela samma virtuella nätverk.

För ytterligare skydd kan du strategiskt placera virtuella datorer i separata tillgänglighetszoner i stället för en enda tillgänglighetszon. Den här metoden kan förhindra driftstopp vid fel i datacentret.
För maximalt skydd kan du placera en sekundär databas i en annan Azure-region än den primära databasregionen. Om du vill tillämpa kontinuerliga uppdateringar kan du använda Data Guard för att implementera global peering för virtuella nätverk. Använd den här metoden för att tillämpa datauppdateringar på den sekundära regionen privat via Microsofts stamnät. Resurser kommunicerar direkt utan gatewayer, extra hopp eller överföring via det offentliga Internet.

Det här nätverksalternativet ger en anslutning med hög bandbredd och låg latens över peerkopplade virtuella nätverk i olika regioner. Du kan använda global peering för virtuella nätverk för att ansluta din primära plats till en haveriberedskapsplats i en annan region via ett höghastighetsnätverk.

Sammanfattning av återhämtning mot olika feltyper

Scenario för misslyckande	Oracle på Azure-scenario med hög tillgänglighet eller haveriberedskap	RPO/RTO
Fel på en enskild komponent, t.ex. en värd, ett rack, ett kyl-, nätverks- eller strömavbrott	Data Guard med två noder i samma Virtual Machine Scale Sets flexibel orkestrering i samma datacenter: - Skyddar mot ett fel i en enskild instans. - Orsakar driftstopp om ett helt datacenter misslyckas.	Om du använder Observer för snabbstart, redundans och MAX_AVAILABILITY- eller MAX_PROTECTION-läge för Data Guard: - RPO är noll. - RTO är mindre än eller lika med 2 min.
Fel i datacentret	Data Guard med två noder i separata tillgänglighetszoner: - Skyddar mot ett datacenterfel. - Orsakar driftstopp om en hel region misslyckas. - Kräver mer redundanskonfiguration för appservrar för att hantera nätverksfördröjningen.	- RPO är mindre än eller lika med 5 min. - RTO är mindre än eller lika med 5 min. Om du använder MAX_PERFORMANCE läge och MAX_AVAILABILITY läge för Data Guard: - RPO är noll. - RTO är mindre än eller lika med 5 min.
Regionalt fel	Data Guard med två noder i separata Azure-regioner: - Skyddar mot regionala fel. - Kräver mer redundanskonfiguration för appservrar för att hantera nätverksfördröjningen.	Om du använder MAX_PERFORMANCE läge för Data Guard: - RPO är större än eller lika med 10 min. - RTO är större än eller lika med 15 min.
Alla scenarier: ett fel med en enskild komponent, datacenter och region	Säkerhetskopior som skickas till en annan Azure-region: - Skydda mot regionala fel. - Kräv att en hel Azure-miljö konfigureras i målregionen under en redundansväxling.	- RPO är större än eller lika med 24 timmar. - RTO är större än eller lika med 4 h.

Nästa steg

Lär dig mer om designöverväganden för Oracle på Virtual Machines acceleratorsäkerhet för landningszoner i ett scenario i företagsskala.

Säkerhetsriktlinjer för Oracle på Virtual Machines accelerator för landningszoner