Dela via

Arkitekturer för Oracle-databas på virtuella Azure-datorer

  • Artikel

Gäller för: ✔️ Virtuella Linux-datorer

Den här artikeln innehåller information om hur du distribuerar en Oracle-databas med hög tillgänglighet i Azure. Dessutom går den här guiden in på haveriberedskapsöverväganden. Arkitekturerna som beskrivs i den här artikeln skapades baserat på kunddistributioner. Den här guiden gäller endast för Oracle Database Enterprise Edition.

Om du är intresserad av att lära dig mer om att maximera prestandan för din Oracle-databas kan du läsa Designa och implementera en Oracle-databas i Azure.

Förutsättningar

  • En förståelse för de olika begreppen i Azure, till exempel tillgänglighetszoner
  • Oracle Database Enterprise Edition 12c eller senare
  • Medvetenhet om licenskonsekvenserna när du använder lösningarna i den här artikeln

Hög tillgänglighet för Oracle-databaser

Att uppnå hög tillgänglighet i molnet är en viktig del av varje organisations planering och design. Azure erbjuder tillgänglighetszoner och tillgänglighetsuppsättningar som ska användas i regioner där tillgänglighetszoner inte är tillgängliga. Mer information om hur du utformar för molnet finns i Tillgänglighetsalternativ för Virtuella Azure-datorer.

Förutom molnbaserade verktyg och erbjudanden tillhandahåller Oracle lösningar för hög tillgänglighet som kan konfigureras i Azure:

Den här guiden beskriver referensarkitekturer för var och en av dessa lösningar.

När du migrerar eller skapar program för molnet rekommenderar vi att du använder molnbaserade mönster, till exempel mönster för återförsök och kretsbrytarmönster. Andra mönster som kan hjälpa dig att göra ditt program mer motståndskraftigt finns i guiden För molndesignmönster.

Oracle RAC i molnet

Oracle Real Application Cluster (RAC) är en lösning från Oracle som hjälper kunderna att uppnå höga dataflöden genom att ha många instanser som har åtkomst till en databaslagring. Det här mönstret är en arkitektur som delas av alla. Oracle RAC kan användas för hög tillgänglighet lokalt, men enbart Oracle RAC kan inte användas för hög tillgänglighet i molnet. Oracle RAC skyddar endast mot fel på instansnivå och inte mot fel på racknivå eller datacenternivå. Därför rekommenderar Oracle att du använder Oracle Data Guard med din databas, oavsett om det är en enskild instans eller RAC, för hög tillgänglighet.

Kunder kräver vanligtvis ett högt serviceavtal för att köra verksamhetskritiska program. Oracle certifierar eller stöder för närvarande inte Oracle RAC på Azure. Azure erbjuder dock funktioner som tillgänglighetszoner och planerade underhållsfönster för att skydda mot fel på instansnivå. Utöver dessa erbjudanden kan du använda Oracle Data Guard, Oracle GoldenGate och Oracle Sharding för höga prestanda och återhämtning. Dessa tekniker kan hjälpa dig att skydda dina databaser från racknivå, datacenternivå och geopolitiska fel.

När du kör Oracle Databases i flera tillgänglighetszoner med Oracle Data Guard eller GoldenGate kan du få ett serviceavtal för drifttid på 99,99 %. I Azure-regioner där tillgänglighetszoner ännu inte finns kan du använda tillgänglighetsuppsättningar och uppnå ett serviceavtal för drifttid på 99,95 %.

Kommentar

Du kan ha ett drifttidsmål som är mycket högre än det serviceavtal för drifttid som tillhandahålls av Microsoft.

Haveriberedskap för Oracle-databaser

När du är värd för dina verksamhetskritiska program i molnet är det viktigt att utforma för hög tillgänglighet och haveriberedskap.

Oracle Data Guard är en användbar funktion för haveriberedskap för Oracle Database Enterprise Edition. Du kan konfigurera en standby-databasinstans i en länkad Azure-region och konfigurera Data Guard-redundans för haveriberedskap. För noll dataförlust rekommenderar vi att du distribuerar en Oracle Data Guard Far Sync-instans utöver Active Data Guard.

Om ditt program tillåter svarstiden kan du överväga att konfigurera Data Guard Far Sync-instansen i en annan tillgänglighetszon än din primära Oracle-databas. Testa konfigurationen noggrant. Använd läget Maximal tillgänglighet för att konfigurera synkron transport av dina omgjorda filer till Far Sync-instansen. Dessa filer överförs sedan asynkront till väntelägesdatabasen.

Programmet kanske inte tillåter prestandaförlust när du konfigurerar Far Sync-instansen i en annan tillgänglighetszon i läget Maximal tillgänglighet (synkron). Annars kan du konfigurera en Far Sync-instans i samma tillgänglighetszon som din primära databas. Överväg att konfigurera flera Far Sync-instanser nära din primära databas och minst en instans nära väntelägesdatabasen om rollen övergår.

När du använder Oracle Standard Edition-databaser finns det ISV-lösningar som gör att du kan konfigurera hög tillgänglighet och haveriberedskap, till exempel DBVisit Standby.

Referensarkitekturer

Oracle Data Guard

Oracle Data Guard säkerställer hög tillgänglighet, dataskydd och haveriberedskap för företagsdata. Data Guard underhåller väntelägesdatabaser som transaktionsmässigt konsekventa kopior av den primära databasen. Beroende på avståndet mellan de primära och sekundära databaserna och programtoleransen för svarstid kan du konfigurera synkron eller asynkron replikering. Om den primära databasen inte är tillgänglig på grund av ett planerat eller oplanerat avbrott kan Data Guard växla valfri väntedatabas till den primära rollen, vilket minimerar stilleståndstiden.

När du använder Oracle Data Guard kan du även öppna den sekundära databasen i skrivskyddat syfte. Den här konfigurationen kallas Active Data Guard. Oracle Database 12c introducerade en funktion som heter Data Guard Far Sync Instance. Med den här instansen kan du konfigurera en konfiguration utan dataförlust för Oracle-databasen utan att behöva påverka prestandan.

Kommentar

Active Data Guard kräver ytterligare licensiering. Den här licensen krävs också för att använda funktionen Far Sync. Kontakta din Oracle-representant för att diskutera licenskonsekvenserna.

Oracle Data Guard med snabbstartsredundans

Oracle Data Guard med snabbstartsredundans (FSFO) kan ge mer återhämtning genom att konfigurera asynkron meddelandekö på en separat dator. Både Data Guard-koordinatorn och den sekundära databasen kör övervakaren och observerar den primära databasen för stilleståndstid. Med den här metoden kan du även redundans i din Data Guard-övervakningskonfiguration.

Med Oracle Database version 12.2 och senare är det också möjligt att konfigurera flera observatörer med en enda Oracle Data Guard-koordinatorkonfiguration. Den här konfigurationen ger extra tillgänglighet, om en övervakare och den sekundära databasen upplever stilleståndstid. Data Guard Broker är enkelt och kan hanteras på en relativt liten virtuell dator. Mer information om Data Guard Broker och dess fördelar finns i Oracle Data Guard Broker Concepts.

Följande diagram är en rekommenderad arkitektur för användning av Oracle Data Guard i Azure med tillgänglighetszoner. Med den här arkitekturen kan du få ett serviceavtal för drifttid för virtuella datorer på 99,99 %.

Diagram som visar en rekommenderad arkitektur för användning av Oracle Data Guard i Azure med tillgänglighetszoner.

I föregående diagram får klientsystemet åtkomst till ett anpassat program med Oracle-serverdelen med hjälp av webben. Webbklientdelen har konfigurerats i en lastbalanserare. Webbklientdelen anropar lämplig programserver för att hantera arbetet. Programservern frågar den primära Oracle-databasen. Oracle-databasen konfigureras med hjälp av en hypertrådad minnesoptimerad virtuell dator med begränsade virtuella kärn-vCPU:er för att spara på licenskostnader och maximera prestanda. Flera premium- eller ultradiskar (hanterade diskar) används för prestanda och hög tillgänglighet.

Oracle-databaserna placeras i flera tillgänglighetszoner för hög tillgänglighet. Varje zon består av ett eller flera datacenter som är utrustade med oberoende ström, kylning och nätverk. För att säkerställa återhämtning konfigureras minst tre separata zoner i alla aktiverade regioner. Den fysiska separationen av tillgänglighetszoner i en region skyddar data från datacenterfel. Dessutom konfigureras två FSFO-observatörer i två tillgänglighetszoner för att initiera och redundansväxla databasen till den sekundära när ett avbrott inträffar.

Du kan konfigurera andra observatörer eller väntelägesdatabaser i en annan tillgänglighetszon, AZ 1, i det här fallet än den zon som visas i föregående arkitektur. Slutligen övervakar Oracle Enterprise Manager (OEM) Oracle-databaser för drifttid och prestanda. Med OEM kan du även generera olika prestanda- och användningsrapporter.

I regioner där tillgänglighetszoner inte stöds kan du använda tillgänglighetsuppsättningar för att distribuera Oracle Database på ett sätt med hög tillgänglighet. Med tillgänglighetsuppsättningar kan du uppnå en vm-drifttid på 99,95 %. Följande diagram är en referensarkitektur för den här användningen:

Diagram som visar Oracle Database med hjälp av tillgänglighetsuppsättningar med Data Guard Broker – FSFO.

Kommentar

  • Eftersom det bara finns en instans av OEM-tillverkare som distribueras behöver du inte placera den virtuella Oracle Enterprise Manager-datorn i en tillgänglighetsuppsättning.
  • Ultradiskar stöds för närvarande inte i en konfiguration av tillgänglighetsuppsättningar.

Oracle Data Guard Far Sync

Oracle Data Guard Far Sync ger noll funktioner för skydd mot dataförlust för Oracle Databases. Med den här funktionen kan du skydda mot dataförlust om databasdatorn misslyckas. Oracle Data Guard Far Sync måste installeras på en separat virtuell dator. Far Sync är en enkel Oracle-instans som bara har en kontrollfil, lösenordsfil, spfile och väntelägesloggar. Det finns inga datafiler eller gör om loggfiler.

För skydd mot dataförlust utan dataförlust måste det finnas synkron kommunikation mellan din primära databas och Far Sync-instansen. Far Sync-instansen tar emot omgjorda från den primära på ett synkront sätt och vidarebefordrar den omedelbart till alla väntelägesdatabaser på ett asynkront sätt. Den här konfigurationen minskar också kostnaderna för den primära databasen, eftersom den bara behöver skicka omeringen till Far Sync-instansen i stället för alla väntelägesdatabaser. Om en Far Sync-instans misslyckas använder Data Guard automatiskt asynkron transport till den sekundära databasen från den primära databasen för att upprätthålla nästan noll skydd mot dataförlust. För ökad återhämtning kan kunder distribuera flera Far Sync-instanser per varje databasinstans, inklusive primära och sekundärfiler.

Följande diagram är en arkitektur med hög tillgänglighet med Oracle Data Guard Far Sync:

Diagram som visar Oracle-databasen med hjälp av tillgänglighetszoner med Data Guard Far Sync & Broker – FSFO.

I den föregående arkitekturen finns det en Far Sync-instans distribuerad i en annan tillgänglighetszon som databasinstans för att säkerställa noll dataförlust och automatisk redundans om det uppstår ett fel i tillgänglighetszonen. Om programmet är svarstidskänsligt bör du överväga att distribuera databasen och Far Sync-instansen eller instanserna i samma tillgänglighetszon i en närhetsplaceringsgrupp.

Följande diagram är en arkitektur som använder Oracle Data Guard FSFO och Far Sync för att uppnå hög tillgänglighet och haveriberedskap:

Diagram som visar Oracle Database med hjälp av tillgänglighetszoner för haveriberedskap med Data Guard Far Sync och Broker – FSFO.

Oracle GoldenGate

GoldenGate möjliggör utbyte och manipulering av data på transaktionsnivå mellan flera heterogena plattformar i företaget. Den flyttar incheckade transaktioner med transaktionsintegritet och minimala omkostnader för din befintliga infrastruktur. Dess modulära arkitektur ger dig flexibiliteten att extrahera och replikera valda dataposter, transaktionsändringar och ändringar i datadefinitionsspråk (DDL) i olika topologier.

Med Oracle GoldenGate kan du konfigurera databasen för hög tillgänglighet genom att tillhandahålla dubbelriktad replikering. Med den här metoden kan du konfigurera en konfiguration med flera original eller aktiv-aktiv. Följande diagram är en rekommenderad arkitektur för active-active-installation i Oracle GoldenGate i Azure. I följande arkitektur konfigureras Oracle-databasen med hjälp av en hypertrådad minnesoptimerad virtuell dator med begränsade kärn-vCPU:er för att spara på licenskostnader och maximera prestanda. Arkitekturen använder flera premium- eller ultradiskar (hanterade diskar) för prestanda och tillgänglighet.

Diagram som visar Oracle Database med hjälp av tillgänglighetszoner med Data Guard Broker – FSFO.

Kommentar

En liknande arkitektur kan konfigureras med hjälp av tillgänglighetsuppsättningar i regioner där tillgänglighetszoner för närvarande inte är tillgängliga.

Oracle GoldenGate har processer som Extract, Pump och Replicat som hjälper dig att asynkront replikera dina data från en Oracle-databasserver till en annan. Med de här processerna kan du konfigurera en dubbelriktad replikering för att säkerställa hög tillgänglighet för databasen om det finns driftstopp på zonnivå för tillgänglighet.

I föregående diagram körs extraheringsprocessen på samma server som Oracle-databasen. Processer för datapump och replikering körs på en separat server i samma tillgänglighetszon. Replikprocessen används för att ta emot data från databasen i den andra tillgänglighetszonen och checka in data till Oracle-databasen i dess tillgänglighetszon. På samma sätt skickar datapumpsprocessen data som extraheringsprocessen extraherar till replikprocessen i den andra tillgänglighetszonen.

I föregående arkitekturdiagram visas de datapumps- och replikeringsprocesser som konfigurerats på en separat server, men du kan konfigurera alla Oracle GoldenGate-processer på samma server, baserat på serverns kapacitet och användning. Läs alltid AWR-rapporten och måtten i Azure för att förstå serverns användningsmönster.

När du konfigurerar dubbelriktad Oracle GoldenGate-replikering i olika tillgänglighetszoner eller olika regioner är det viktigt att se till att svarstiden mellan de olika komponenterna är acceptabel för ditt program. Svarstiden mellan tillgänglighetszoner och regioner kan variera. Svarstiden beror på flera faktorer. Vi rekommenderar att du konfigurerar prestandatester mellan programnivån och databasnivån i olika tillgänglighetszoner eller regioner. Testerna kan bekräfta att konfigurationen uppfyller programmets prestandakrav.

Programnivån kan konfigureras i ett eget undernät och databasnivån kan delas upp i ett eget undernät. När det är möjligt bör du överväga att använda Azure Application Gateway för att belastningsutjämningstrafik mellan dina programservrar. Application Gateway är en robust lastbalanserare för webbtrafik. Den tillhandahåller cookiebaserad sessionstillhörighet som håller en användarsession på samma server, vilket minimerar konflikterna i databasen. Alternativ till Application Gateway är Azure Load Balancer och Azure Traffic Manager.

Oracle-horisontell partitionering

Horisontell partitionering är ett datanivåmönster som introducerades i Oracle 12.2. Med den kan du horisontellt partitionera och skala dina data mellan oberoende databaser. Det är en share-nothing-arkitektur där varje databas finns på en dedikerad virtuell dator. Det här mönstret möjliggör högt läs- och skrivflöde utöver återhämtning och ökad tillgänglighet.

Det här mönstret eliminerar enskilda felpunkter, ger felisolering och aktiverar löpande uppgraderingar utan driftstopp. Stilleståndstiden för en shard eller ett fel på datacenternivå påverkar inte prestanda eller tillgänglighet för de andra shardsna i andra datacenter.

Horisontell partitionering är lämplig för OLTP-program med högt dataflöde som inte har råd med driftstopp. Alla rader med samma partitioneringsnyckel är alltid garanterade på samma shard. Detta faktum ökar prestandan, vilket ger hög konsekvens. Program som använder horisontell partitionering måste ha en väldefinierad datamodell och en strategi för datadistribution, till exempel konsekvent hash, intervall, lista eller sammansatt. Strategin kommer främst åt data med hjälp av en partitioneringsnyckel, till exempel customerId eller accountNum. Med horisontell partitionering kan du också lagra vissa datauppsättningar närmare slutkunderna, vilket hjälper dig att uppfylla dina prestanda- och efterlevnadskrav.

Vi rekommenderar att du replikerar dina shards för hög tillgänglighet och haveriberedskap. Den här konfigurationen kan göras med Oracle-tekniker som Oracle Data Guard eller Oracle GoldenGate. En replikeringsenhet kan vara en shard, en del av en shard eller en grupp med shards. Ett avbrott eller en inbromsning av en eller flera shards påverkar inte tillgängligheten för en fragmenterad databas.

För hög tillgänglighet kan standby-shards placeras i samma tillgänglighetszon där de primära shardsna placeras. För haveriberedskap kan standby-shards finnas i en annan region. Du kan också distribuera shards i flera regioner för att hantera trafik i dessa regioner. Mer information om hur du konfigurerar hög tillgänglighet och replikering av din shardade databas finns i Hög tillgänglighet på Shard-nivå.

Oracle Sharding består främst av följande komponenter. Mer information finns i Översikt över Oracle Sharding:

  • Shard-katalog. Särskild Oracle-databas som är ett beständigt lager för alla Shard-databaskonfigurationsdata. Alla konfigurationsändringar som att lägga till eller ta bort shards, mappa data och DDL:er i en sharddatabas initieras i fragmentkatalogen. Shard-katalogen innehåller också den primära kopian av alla duplicerade tabeller i en SDB.

    Shard-katalogen använder materialiserade vyer för att automatiskt replikera ändringar till duplicerade tabeller i alla shards. Shard-katalogdatabasen fungerar också som en frågekoordinator som används för att bearbeta frågor och frågor med flera fragment som inte anger en partitioneringsnyckel.

    Vi rekommenderar att du använder Oracle Data Guard med tillgänglighetszoner eller tillgänglighetsuppsättningar för horisontell katalog med hög tillgänglighet som bästa praxis. Tillgängligheten för shardkatalogen påverkar inte tillgängligheten för den fragmenterade databasen. En stilleståndstid i shardkatalogen påverkar endast underhållsåtgärder och frågor med flera partitioner under den korta period som Data Guard-redundansväxlingen slutförs. SDB fortsätter att dirigera och köra onlinetransaktioner. Ett katalogstopp påverkar dem inte.

  • Shard-regissörer. Förenklade tjänster som måste distribueras i varje region/tillgänglighetszon som dina shards finns i. Shard Directors är globala servicechefer som distribueras i samband med Oracle Sharding. För hög tillgänglighet rekommenderar vi att du distribuerar minst en shard-direktör i varje tillgänglighetszon som fragmenten finns i.

    När du ansluter till databasen från början konfigurerar shard-chefen routningsinformationen och cachelagrar informationen för efterföljande begäranden, vilket kringgår shard-direktören. När sessionen har upprättats med en shard stöds och körs alla SQL-frågor och DML:er i omfånget för den angivna sharden. Den här routningen är snabb och används för alla OLTP-arbetsbelastningar som utför transaktioner inom fragment. Vi rekommenderar att du använder direktdirigering för alla OLTP-arbetsbelastningar som kräver högsta prestanda och tillgänglighet. Routningscache uppdateras automatiskt när ett fragment blir otillgängligt eller ändringar sker i fragmenteringstopologin.

    För databeroende routning med höga prestanda rekommenderar Oracle att du använder en anslutningspool när du kommer åt data i den fragmenterade databasen. Oracle-anslutningspooler, språkspecifika bibliotek och drivrutiner stöder Oracle Sharding. Mer information finns i Översikt över Oracle Sharding.

  • Global tjänst. Den globala tjänsten liknar den vanliga databastjänsten. Förutom alla egenskaper för en databastjänst har en global tjänst egenskaper för fragmenterade databaser. Dessa egenskaper omfattar regiontillhörighet mellan klienter och shard- och replikeringsfördröjningstolerans. Endast en global tjänst behöver skapas för att läsa/skriva data till och från en fragmenterad databas. När du använder Active Data Guard och konfigurerar skrivskyddade repliker av shards kan du skapa en annan global tjänst för skrivskyddade arbetsbelastningar. Klienten kan använda dessa globala tjänster för att ansluta till databasen.

  • Shard-databaser. Shard-databaser är dina Oracle-databaser. Varje databas replikeras med Oracle Data Guard i en Broker-konfiguration med FSFO aktiverat. Du behöver inte konfigurera Data Guard-redundans och replikering på varje shard. Den här aspekten konfigureras och distribueras automatiskt när den delade databasen skapas. Om en viss shard misslyckas redundansväxlar Oracle-delning databasanslutningar från den primära till vänteläget.

Du kan distribuera och hantera Oracle-shardade databaser med två gränssnitt: Oracle Enterprise Manager Cloud Control GUI och GDSCTL kommandoradsverktyget. Du kan till och med övervaka de olika fragmenten för tillgänglighet och prestanda med hjälp av molnkontroll. Kommandot GDSCTL DEPLOY skapar automatiskt fragmenten och deras respektive lyssnare. Dessutom distribuerar det här kommandot automatiskt replikeringskonfigurationen som används för hög tillgänglighet på shardnivå som angetts av administratören.

Det finns olika sätt att fragmentera en databas:

  • Systemhanterad horisontell partitionering: Distribueras automatiskt över shards med partitionering
  • Användardefinierad horisontell partitionering: Gör att du kan ange mappning av data till shards, vilket fungerar bra när det finns krav på regel- eller datalokalisering
  • Sammansatt horisontell partitionering: En kombination av systemhanterad och användardefinierad horisontell partitionering för olika shardspaces
  • Tabellunderpartitioner: Liknar en vanlig partitionerad tabell

Mer information finns i Sharding-metoder.

En fragmenterad databas ser ut som en enkel databas för program och utvecklare. När du migrerar till en fragmenterad databas planerar du noggrant att förstå vilka tabeller som dupliceras jämfört med shardade.

Duplicerade tabeller lagras på alla shards, medan fragmenterade tabeller distribueras över olika shards. Vi rekommenderar att du duplicerar små och dimensionella tabeller och distribuerar/shardar faktatabellerna. Data kan läsas in i din fragmenterade databas med hjälp av antingen shardkatalogen som central koordinator eller genom att köra Datapump på varje shard. Mer information finns i Migrera data till en shardad databas.

Oracle Sharding med Data Guard

Oracle Data Guard kan användas för horisontell partitionering med systemhanterade, användardefinierade och sammansatta horisontell partitioneringsmetoder.

Följande diagram är en referensarkitektur för Oracle Sharding med Oracle Data Guard som används för hög tillgänglighet för varje shard. Arkitekturdiagrammet visar en sammansatt horisontell partitioneringsmetod. Arkitekturdiagrammet skiljer sig troligen åt för program med olika krav för datalokalitet, belastningsutjämning, hög tillgänglighet och haveriberedskap. Program kan använda en annan metod för horisontell partitionering. Med Oracle Sharding kan du uppfylla dessa krav och skala horisontellt och effektivt genom att tillhandahålla dessa alternativ. En liknande arkitektur kan till och med distribueras med Oracle GoldenGate.

Diagram som visar Oracle Database Sharding med hjälp av tillgänglighetszoner med Data Guard Broker – FSFO.

Systemhanterad horisontell partitionering är det enklaste att konfigurera och hantera. Användardefinierad horisontell partitionering eller sammansatt horisontell partitionering passar bra för scenarier där dina data och program är geo-distribuerade eller i scenarier där du behöver ha kontroll över replikeringen av varje shard.

I den föregående arkitekturen används sammansatt horisontell partitionering för att geo-distribuera data och skala ut dina programnivåer horisontellt. Sammansatt horisontell partitionering är en kombination av systemhanterad och användardefinierad horisontell partitionering och ger därmed fördelen med båda metoderna. I föregående scenario partitioneras data först över flera shardspaces avgränsade efter region. Sedan partitioneras data ytterligare med hjälp av konsekvent hash över flera shards i shardområdet.

Varje shardspace innehåller flera shardgroups. Varje shardgroup har flera shards och är en replikeringsenhet. Varje shardgrupp innehåller alla data i shardområdet. Shardgroups A1 och B1 är primära shardgroups, medan shardgroups A2 och B2 är vänteläge. Du kan välja att enskilda shards ska vara replikeringsenheten i stället för en shardgrupp.

I den föregående arkitekturen distribueras en Global Service Manager (GSM)/shard-direktör i varje tillgänglighetszon för hög tillgänglighet. Vi rekommenderar att du distribuerar minst en GSM/shard-direktör per datacenter/region. Dessutom distribueras en instans av programservern i varje tillgänglighetszon som innehåller en shardgroup. Med den här konfigurationen kan programmet hålla svarstiden mellan programservern och databasen/shardgruppen låg. Om en databas misslyckas kan programservern i samma zon som väntelägesdatabasen hantera begäranden när övergången till databasrollen sker. Azure Application Gateway och shard-chefen håller reda på svarsfördröjningen och routningsbegäranden i enlighet med detta.

Från programsynpunkt skickar klientsystemet en begäran till Azure Application Gateway eller andra belastningsutjämningstekniker i Azure, som omdirigerar begäran till den region som är närmast klienten. Azure Application Gateway har också stöd för klibbiga sessioner, så alla begäranden som kommer från samma klient dirigeras till samma programserver. Programservern använder anslutningspooler i dataåtkomstdrivrutiner. Den här funktionen är tillgänglig i drivrutiner som JDBC, ODP.NET och OCI. Drivrutinerna kan identifiera partitioneringsnycklar som angetts som en del av begäran. Oracle Universal Connection Pool (UCP) för JDBC-klienter kan göra det möjligt för icke-Oracle-programklienter som Apache Tomcat och IIS att arbeta med Oracle Sharding. Mer information finns i Översikt över delad UCP-pool för databassharding.

Under den första begäran ansluter programservern till shard-chefen i regionen för att hämta routningsinformation för den shard som begäran måste dirigeras till. Baserat på den partitioneringsnyckel som skickades dirigerar regissören programservern till respektive shard. Programservern cachelagrar den här informationen genom att skapa en karta, och för efterföljande begäranden kringgår du shard-direktören och dirigerar begäranden direkt till fragmentet.

Oracle Sharding med GoldenGate

Följande diagram är en referensarkitektur för Oracle Sharding med Oracle GoldenGate för hög tillgänglighet i regionen för varje shard. I motsats till den föregående arkitekturen visar den här arkitekturen endast hög tillgänglighet i en enda Azure-region med flera tillgänglighetszoner. Du kan distribuera en fragmenterad databas med hög tillgänglighet i flera regioner, ungefär som i föregående exempel, med hjälp av Oracle GoldenGate.

Diagram som visar Oracle Database Sharding med hjälp av tillgänglighetszoner med GoldenGate.

Den föregående referensarkitekturen använder den systemhanterade horisontell partitioneringsmetoden för att fragmentera data. Eftersom Oracle GoldenGate-replikering görs på segmentnivå kan hälften av data som replikeras till en shard replikeras till en annan shard. Den andra hälften kan replikeras till en annan shard.

Hur data replikeras beror på replikeringsfaktorn. Med en replikeringsfaktor på två har du två kopior av varje segment av data över dina tre shards i shardgruppen. På samma sätt, med en replikeringsfaktor på tre och tre shards i din shardgrupp, replikeras alla data i varje shard till alla andra shard i shardgruppen. Varje shard i shardgruppen kan ha en annan replikeringsfaktor. Den här konfigurationen hjälper dig att definiera din design för hög tillgänglighet och haveriberedskap effektivt i en shardgroup och över flera shardgrupper.

I den föregående arkitekturen innehåller shardgroup A och shardgroup B båda samma data men finns i olika tillgänglighetszoner. Om både shardgroup A och shardgroup B har samma replikeringsfaktor på tre replikeras varje rad/segment i den fragmenterade tabellen sex gånger över de två shardgrupperna. Om shardgroup A har en replikeringsfaktor på tre och shardgroup B har en replikeringsfaktor på två, replikeras varje rad/segment fem gånger över de två shardgrupperna.

Den här konfigurationen förhindrar dataförlust om ett fel på instansnivå eller tillgänglighetsnivå uppstår på zonnivå. Programlagret kan läsa från och skriva till varje shard. För att minimera konflikter anger Oracle Sharding ett huvudsegment för varje hash-värdeintervall. Den här funktionen säkerställer att skrivbegäranden för ett visst segment dirigeras till motsvarande segment. Dessutom tillhandahåller Oracle GoldenGate automatisk konfliktidentifiering och lösning för att hantera eventuella konflikter som kan uppstå. Mer information och begränsningar för att implementera GoldenGate med Oracle Sharding finns i Använda Oracle GoldenGate med en shardad databas.

I den föregående arkitekturen distribueras en GSM/shard-direktör i varje tillgänglighetszon för hög tillgänglighet. Vi rekommenderar att du distribuerar minst en GSM/shard-direktör per datacenter eller region. En instans av programservern distribueras i varje tillgänglighetszon som innehåller en shardgroup. Med den här konfigurationen kan programmet hålla svarstiden mellan programservern och databasen/shardgruppen låg. Om en databas misslyckas kan programservern i samma zon som väntelägesdatabasen hantera begäranden när databasrollen övergår. Azure Application Gateway och shard-chefen håller reda på svarsfördröjningen och routningsbegäranden i enlighet med detta.

Från programsynpunkt skickar klientsystemet en begäran till Azure Application Gateway eller andra belastningsutjämningstekniker i Azure, som omdirigerar begäran till den region som är närmast klienten. Azure Application Gateway har också stöd för klibbiga sessioner, så alla begäranden som kommer från samma klient dirigeras till samma programserver. Programservern använder anslutningspooler i dataåtkomstdrivrutiner. Den här funktionen är tillgänglig i drivrutiner som JDBC, ODP.NET och OCI. Drivrutinerna kan identifiera partitioneringsnycklar som angetts som en del av begäran. Oracle Universal Connection Pool (UCP) för JDBC-klienter kan göra det möjligt för icke-Oracle-programklienter som Apache Tomcat och IIS att arbeta med Oracle Sharding.

Under den första begäran ansluter programservern till shard-chefen i regionen för att hämta routningsinformation för den shard som begäran måste dirigeras till. Baserat på den partitioneringsnyckel som skickades dirigerar regissören programservern till respektive shard. Programservern cachelagrar den här informationen genom att skapa en karta, och för efterföljande begäranden kringgår du shard-direktören och dirigerar begäranden direkt till fragmentet.

Korrigering och underhåll

När du distribuerar dina Oracle-arbetsbelastningar till Azure tar Microsoft hand om alla korrigeringar på värdoperativsystemnivå. Microsoft kommunicerar alla planerade underhåll på operativsystemnivå till kunder i förväg. Två servrar från två olika tillgänglighetszoner korrigeras aldrig samtidigt. Mer information om underhåll och korrigering av virtuella datorer finns i Tillgänglighetsalternativ för virtuella Azure-datorer.

Korrigering av operativsystemet för den virtuella datorn kan automatiseras med hjälp av Azure Automation Update Management. Korrigering och underhåll av Oracle-databasen kan automatiseras och schemaläggas med hjälp av Azure Pipelines eller Azure Automation Update Management för att minimera driftstopp. Mer information om kontinuerlig leverans och blå/gröna distributioner finns i Progressiva exponeringstekniker.

Arkitektur- och designöverväganden

  • Överväg att använda hypertrådade minnesoptimerade virtuella datorer med begränsade virtuella kärnor för din virtuella Oracle Database-dator för att spara på licenskostnader och maximera prestanda. Använd flera premium- eller ultradiskar (hanterade diskar) för prestanda och tillgänglighet.
  • När du använder hanterade diskar kan namnet på disken/enheten ändras vid omstart. Vi rekommenderar att du använder enhetens UUID i stället för namnet för att se till att monteringarna bevaras i sprite för omstart. Mer information finns i Lägga till det nya filsystemet i /etc/fstab.
  • Använd tillgänglighetszoner för att uppnå hög tillgänglighet i regionen.
  • Överväg att använda ultradiskar när de är tillgängliga eller premiumdiskar för Oracle-databasen.
  • Överväg att konfigurera en Oracle-databas i vänteläge i en annan Azure-region med Oracle Data Guard.
  • Överväg att använda närhetsplaceringsgrupper för att minska svarstiden mellan program- och databasnivån.
  • Den maximala nätverksbandbredden för virtuella Azure-datorer är (vanligtvis) högre än det maximala diskdataflödet på samma SKU. Du kan uppnå högre dataflöde på samma vm-SKU eller använda en mindre SKU för virtuella datorer med hjälp av högpresterande nätverkslagring med låg latens, till exempel Azure NetApp Files. för databasen.
  • Konfigurera Oracle Enterprise Manager för hantering, övervakning och loggning.
  • Överväg att använda Oracle Automatic Storage Management för effektiv lagringshantering för din databas.
  • Använd Azure Pipelines för att hantera korrigeringar och uppdateringar av databasen utan avbrott.
  • Justera programkoden för att lägga till molnbaserade mönster som kan hjälpa ditt program att bli mer motståndskraftigt. Överväg mönster som återförsöksmönster, kretsbrytarmönster och andra som definieras i guiden För molndesignmönster.

Nästa steg

Läs följande Oracle-referensartiklar som gäller för ditt scenario.