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

Den här artikeln bygger på de överväganden och rekommendationer som definieras i designområdet för Azure-landningszoner 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 Distribution av Oracle-arbetsbelastningar på virtuella Azure-infrastrukturdatorer (VM).

Azure tillhandahåller tjänster som du kan använda för att utforma arkitekturer med hög tillgänglighet och motståndskraft. 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-acceleratorn för landningszoner. Den beskriver också hur du konfigurerar tillhörande Azure-tjänster som hjälper 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 elastisk arkitektur för din arbetsbelastningsmiljö fastställer du tillgänglighetskrav för din lösning baserat på mål för återställningstid (RTO) och mål för återställningspunkter (RPO) för olika felnivåer. RTO är den maximala tid som ett program förblir otillgängligt efter en incident. 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 din arkitektur för att tillhandahålla de etablerade nivåerna av återhämtning och tillgänglighet.

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 för 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å arkitekturdesignen 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å Datacenter- eller regionnivå i Azure.

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

Använd följande flödesdiagram 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 normala åtgärder. För en konfiguration med hög tillgänglighet för två Oracle-databasservrar som skapas i en flexibel orkestrering av vm-skalningsuppsättningar 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 VM-skalningsuppsättningar.

En stegvis konfiguration av Data Guard i 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 vm-skalningsuppsättningar minskas 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 i den här arkitekturen är samma 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 i samma Azure-region. Tillgänglighetszoner har en svarstid för tur och retur på mindre än två millisekunder. Du använder vanligtvis tillgänglighetszoner för haveriberedskap, 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 svarstider och dataflöde som dina tillgänglighetszoner tillhandahåller.

En fördel med tillgänglighetszoner med en flexibel orkestrering av vm-skalningsuppsättningar är att serviceavtalet för vm-tillgänglighet ökar till 99,99 %.

Använda kluster för delad lagring för hög tillgänglighet

Klustertekniker för delad lagring ger unika attribut som kan hjälpa dig att uppnå dina affärsmål. Du kan till exempel implementera ett Pacemaker- och Corosync-kluster (PCS) 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 mellan redundansväxlingar.

Kommentar

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

Använda närhetsplaceringsgrupper

Om du vill ge lägsta möjliga svarstid placerar du virtuella datorer så nära som möjligt. Du kan distribuera dem inom 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 svarstid.

Konfigurera din arbetsbelastning för haveriberedskap

En arkitektur för haveriberedskap ger återhämtning mot fel som påverkar Azures 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 arkitektur för haveriberedskap baserat på dina lösningskrav. Du fastställer dina krav baserat på din RTO och RPO. Haveriberedskapsarkitekturer är för exceptionella felfall, så redundansprocesser är manuella. I designen för hög tillgänglighet sker redundans automatiskt. I en arkitektur för haveriberedskap bör du ha mer avslappnade krav för 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 Den primära platsen lokalt och haveriberedskapsplatsen i Azure.

Välj rätt alternativ för haveriberedskap

Använd följande flödesdiagram för att välja det bästa haveriberedskapsalternativet för Oracle-databasen.

Använda Data Guard för haveriberedskap

Du kan använda Data Guard för att replikera data till din haveriberedskapsplats. Använd den platsen som en annan tillgänglighetszon i samma region eller i en annan region beroende på dina krav för dataskydd. Konfigurationen beror också på tillgänglighetszonens struktur på produktionsplatsen. En Data Guard-implementering i ett haveriberedskapsscenario liknar scenariot med hög tillgänglighet som beskrevs 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 långt ifrå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 maximalt prestandaläge är för hög kan du använda maximalt tillgänglighetsläge 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 omloggar, 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 replikera endast partiella data efter behov, vilket minskar utgående kostnader.

En stegvis konfiguration av Data Guard i 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 logisk replikeringsprogramvara som du kan använda för replikering i realtid, filtrering och omvandling av data 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 vissa 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 stegvis guide om hur du implementerar Golden Gate i 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 arkitektur för haveriberedskap. Det finns två huvudkomponenter för säkerhetskopiering som en haveriberedskapsmetod för Oracle-databaser i Azure:

• Extrahera och flytta säkerhetskopieringen av data från en databas för att säkerställa att haveriberedskapsplatsen har uppdaterade data.

• Se till att distributionen är uppdaterad 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 Säkerhetskopieringsstrategier för Oracle Database i Azure.

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

Metod 1: Undvik extra underhållsarbete och kostnader genom att inte underhålla någon fysisk distribution på haveriberedskapsplatsen. Du kan använda infrastruktur som teknik för kod och 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 scenariot för haveriberedskap.

Metod 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 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.

Metod 3: Distribuera och underhålla hela lösningen på haveriberedskapsplatsen under de snabbaste RTO- och redundanstiderna. Den här metoden ökar kostnaden på grund av att en fullständigt redundant infrastruktur körs.

Överväg andra sätt att implementera haveriberedskap

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

Använda fjärransynkronisering

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

Välj rätt datareplikeringsteknik

Utöver teknikerna i den här artikeln kan du använda alla tekniker som underlättar datareplikering mellan 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 de här kategorierna.

Svarstid: 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 infrastruktur för höghastighetsnätverk 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 effekt som replikeringen har på transaktionsbearbetningen på den primära databasen bör uppfylla din lösnings krav.

Dataförlust: Den mängd dataförlust som du förväntar dig vid ett plötsligt fel i den primära databasen bör uppfylla lösningens krav.

Total ägandekostnad: Överväg kostnaden för anskaffning 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 din lösnings krav.

Optimera en redundansinstans

När du använder Data Guard i hög tillgänglighetsläge eller högskyddsläge kan du konfigurera för automatisk redundans så att den sekundära servern tas upp 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ågon programavbrottstid under en redundansväxling.

I den här implementeringen måste en databas köra samma efter en redundansväxling. Därför måste du konfigurera en sekundär server med samma processor-, minnes- och indata-/utdatakapacitet (I/O) som den primära servern. Du måste ha 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ändarbegäranden.

Azure tillhandahåller 99,9 % tillgänglighet för virtuella datorer i en tillgänglighetszon. Mer information finns i SLA 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 den sekundära databasen till samma kapacitet som den primära databasen. Den här åtgärden inträffar 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 inte 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 den 1/10:e (om du har ett 90 % läs- och 10 % skrivförhållande) av kapaciteten för den primära databasen.

Automatisera redundansprocedurer för att säkerställa att du uppfyller företagets standarder under redundansväxlingen. Du kan konfigurera redundansprocedurerna så att de omfattar åtgärder för serverändring 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ärsbeslut som balanserar återställningstiden, eller RTO, och den potentiella dataförlusten, eller RPO, mot andra Oracle-licensiering, VM-underhåll och dataöverföringskostnader. När du är värd för en arbetsbelastning på en enskild 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 sannolikt avbrott och dataförlust. I produktionsmiljöerna inkluderar du därför 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. Du minimerar svarstiden genom att lägga till en sekundär Oracle-databas på en separat virtuell dator i samma flexibla orkestrering av vm-skalningsuppsättningar 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 enskild 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 RRPOs.

• 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 millisekunder svarstid mellan regioner, så du kanske inte uppfyller dina RTO- och RPO-mål. Den här lösningen passar bäst för regional haveriberedskap i stället för hög tillgänglighet.

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

• Data Guard ger hög tillgänglighet och ger i de flesta fall tillräckligt stöd för vanliga fel. Du kan placera virtuella datorer i en flexibel orkestrering av vm-skalningsuppsättningar. 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 ska 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 ett datacenterfel.

• 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 svarstid mellan peer-kopplade 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 typer av fel

Felscenario	Scenario med hög tillgänglighet eller haveriberedskap i Oracle i Azure	RPO/RTO
Fel med en enskild komponent, till exempel en värd, ett rack, en kylning, ett nätverk eller ett strömavbrott	Data Guard med två noder i samma vm-skalningsuppsättningar flexibel orkestrering i samma datacenter: – Skyddar mot ett enda instansfel. – Orsakar stilleståndstid om ett helt datacenter misslyckas.	Om du använder Observer för snabbstartsredundans och MAX_AVAILABILITY eller MAX_PROTECTION läge för Data Guard: - RPO är noll. - RTO är mindre än eller lika med 2 min.
Datacenterfel	Data Guard med två noder i separata tillgänglighetszoner: – Skyddar mot ett datacenterfel. – Orsakar stilleståndstid om en hel region misslyckas. – Kräver mer redundanskonfiguration för att appservrar ska kunna hantera nätverksfördröjning.	– 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 att appservrar ska kunna hantera nätverksfördröjning.	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: en enskild komponent, ett datacenter och ett regionfel	Säkerhetskopior som levereras 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.

Gå vidare

Lär dig mer om designöverväganden för Oracle på virtual machines- och landningszonacceleratorsäkerhet i ett scenario i företagsskala.

Säkerhetsriktlinjer för Oracle på acceleratorn för landningszoner för virtuella datorer