Architecturen voor Oracle-database op virtuele Azure-machines

  • Artikel

Van toepassing op: ✔️ Virtuele Linux-machines

Dit artikel bevat informatie over het implementeren van een maximaal beschikbare Oracle-database in Azure. Daarnaast wordt in deze handleiding dieper ingegaan op overwegingen voor herstel na noodgevallen. Deze architecturen zijn gemaakt op basis van klantimplementaties. Deze handleiding is alleen van toepassing op Oracle Database Enterprise Edition.

Als u meer wilt weten over het maximaliseren van de prestaties van uw Oracle-database, raadpleegt u Ontwerp en implementeer een Oracle-database in Azure.

Vereisten

  • Inzicht in de verschillende concepten van Azure, zoals beschikbaarheidszones
  • Oracle Database Enterprise Edition 12c of hoger
  • Kennis van de gevolgen voor licenties bij het gebruik van de oplossingen in dit artikel

Hoge beschikbaarheid voor Oracle-databases

Het bereiken van hoge beschikbaarheid in de cloud is een belangrijk onderdeel van de planning en het ontwerp van elke organisatie. Azure biedt beschikbaarheidszones en beschikbaarheidssets die moeten worden gebruikt in regio's waar beschikbaarheidszones niet beschikbaar zijn. Zie Beschikbaarheidsopties voor virtuele Azure-machines voor meer informatie over het ontwerpen van de cloud.

Naast cloudeigen hulpprogramma's en -aanbiedingen biedt Oracle oplossingen voor hoge beschikbaarheid die in Azure kunnen worden ingesteld:

Deze handleiding bevat referentiearchitecturen voor elk van deze oplossingen.

Wanneer u toepassingen voor de cloud migreert of maakt, wordt u aangeraden cloudeigen patronen te gebruiken, zoals patroon voor opnieuw proberen en circuitonderbrekers. Zie de handleiding cloudontwerppatronen voor andere patronen die u kunnen helpen uw toepassing toleranter te maken.

Oracle RAC in de cloud

Oracle Real Application Cluster (RAC) is een oplossing van Oracle om klanten te helpen hoge doorvoer te bereiken door veel exemplaren toegang te geven tot één databaseopslag. Dit patroon is een gedeelde architectuur. Hoewel Oracle RAC kan worden gebruikt voor on-premises hoge beschikbaarheid, kan Oracle RAC alleen niet worden gebruikt voor hoge beschikbaarheid in de cloud. Oracle RAC beschermt alleen tegen storingen op exemplaarniveau en niet tegen storingen op rack- of datacenterniveau. Daarom raadt Oracle aan Oracle Data Guard te gebruiken met uw database, ongeacht of er één exemplaar of RAC is, voor hoge beschikbaarheid.

Klanten hebben over het algemeen een hoge SLA nodig om bedrijfskritieke toepassingen uit te voeren. Oracle certificeert of biedt momenteel geen ondersteuning voor Oracle RAC in Azure. Azure biedt echter functies zoals beschikbaarheidszones en geplande onderhoudsvensters om te beschermen tegen storingen op exemplaarniveau. Naast deze aanbiedingen kunt u Oracle Data Guard, Oracle GoldenGate en Oracle Sharding gebruiken voor hoge prestaties en tolerantie. Met deze technologieën kunt u uw databases beschermen tegen storingen op rackniveau, datacenterniveau en geo-politieke fouten.

Wanneer u Oracle Databases uitvoert op meerdere beschikbaarheidszones met Oracle Data Guard of GoldenGate, kunt u een SLA voor uptime van 99,99% krijgen. In Azure-regio's waar nog geen beschikbaarheidszones aanwezig zijn, kunt u beschikbaarheidssets gebruiken en een SLA voor uptime van 99,95% bereiken.

Notitie

U kunt een uptimedoel hebben dat veel hoger is dan de SLA voor uptime van Microsoft.

Herstel na noodgevallen voor Oracle-databases

Bij het hosten van uw bedrijfskritieke toepassingen in de cloud, is het belangrijk om te ontwerpen voor hoge beschikbaarheid en herstel na noodgevallen.

Voor Oracle Database Enterprise Edition is Oracle Data Guard een handige functie voor herstel na noodgevallen. U kunt een stand-bydatabase-exemplaar instellen in een gekoppelde Azure-regio en een Data Guard-failover instellen voor herstel na noodgevallen. Voor nul gegevensverlies raden we u aan een Oracle Data Guard Far Sync-exemplaar te implementeren naast Active Data Guard.

Als uw toepassing de latentie toestaat, kunt u overwegen om het Data Guard Far Sync-exemplaar in een andere beschikbaarheidszone in te stellen dan uw primaire Oracle-database. Test de configuratie grondig. Gebruik de modus Maximale beschikbaarheid om synchrone transport van uw redo-bestanden in te stellen op het far sync-exemplaar. Deze bestanden worden vervolgens asynchroon overgebracht naar de stand-bydatabase.

Het is mogelijk dat uw toepassing het prestatieverlies niet toestaat bij het instellen van een Far Sync-exemplaar in een andere beschikbaarheidszone in de modus Maximale beschikbaarheid (synchroon). Als dat niet het geval is, kunt u een Far Sync-exemplaar instellen in dezelfde beschikbaarheidszone als uw primaire database. Voor extra beschikbaarheid kunt u overwegen om meerdere Far Sync-exemplaren in te stellen dicht bij uw primaire database en ten minste één exemplaar dicht bij uw stand-bydatabase, als de rol overgaat. Zie Oracle Active Data Guard Far Sync voor meer informatie.

Wanneer u Oracle Standard Edition-databases gebruikt, zijn er ISV-oplossingen waarmee u hoge beschikbaarheid en herstel na noodgevallen kunt instellen, zoals DBVisit Standby.

Referentiearchitecturen

Oracle Data Guard

Oracle Data Guard zorgt voor hoge beschikbaarheid, gegevensbescherming en herstel na noodgevallen voor bedrijfsgegevens. Data Guard onderhoudt stand-bydatabases als transactioneel consistente kopieën van de primaire database. Afhankelijk van de afstand tussen de primaire en secundaire databases en de toepassingstolerantie voor latentie, kunt u synchrone of asynchrone replicatie instellen. Als de primaire database niet beschikbaar is vanwege een geplande of niet-geplande storing, kan Data Guard elke stand-bydatabase overschakelen naar de primaire rol, waardoor downtime wordt geminimaliseerd.

Wanneer u Oracle Data Guard gebruikt, kunt u uw secundaire database ook openen voor alleen-lezendoeleinden. Deze configuratie wordt Active Data Guard genoemd. Oracle Database 12c heeft een functie geïntroduceerd met de naam Data Guard Far Sync Instance. Met dit exemplaar kunt u een configuratie voor gegevensverlies van nul instellen voor uw Oracle-database zonder dat u inbreuk hoeft te maken op de prestaties.

Notitie

Active Data Guard vereist extra licenties. Deze licentie is ook vereist voor het gebruik van de functie Far Sync. Neem contact op met uw Oracle-vertegenwoordiger om de gevolgen van licenties te bespreken.

Oracle Data Guard met fast-startfailover

Oracle Data Guard met Fast-Start Failover (FSFO) kan meer tolerantie bieden door de broker op een afzonderlijke computer in te stellen. De Data Guard-broker en de secundaire database voeren de waarnemer uit en observeren de primaire database voor downtime. Met deze methode kunt u ook redundantie in uw Data Guard-waarnemer instellen.

Met Oracle Database versie 12.2 en hoger is het ook mogelijk om meerdere waarnemers te configureren met één Oracle Data Guard-brokerconfiguratie. Deze installatie biedt extra beschikbaarheid, voor het geval één waarnemer en de secundaire database uitvaltijd ondervinden. Data Guard Broker is lichtgewicht en kan worden gehost op een relatief kleine virtuele machine. Zie Oracle Data Guard Broker Concepts voor meer informatie over Data Guard Broker en de voordelen ervan.

Het volgende diagram is een aanbevolen architectuur voor het gebruik van Oracle Data Guard in Azure met beschikbaarheidszones. Met deze architectuur kunt u een SLA voor vm-uptime van 99,99% verkrijgen.

Diagram that shows a recommended architecture for using Oracle Data Guard on Azure with availability zones.

In het voorgaande diagram heeft het clientsysteem toegang tot een aangepaste toepassing met Oracle-back-end met behulp van het web. De webfront-end is geconfigureerd in een load balancer. De webfront-end roept de juiste toepassingsserver aan om het werk af te handelen. De toepassingsserver voert een query uit op de primaire Oracle-database. De Oracle-database is geconfigureerd met behulp van een voor hyperthreaded geheugen geoptimaliseerde virtuele machine met beperkte kern-vCPU's om te besparen op licentiekosten en de prestaties te maximaliseren. Er worden meerdere premium- of ultraschijven (Managed Disks) gebruikt voor prestaties en hoge beschikbaarheid.

De Oracle-databases worden in meerdere beschikbaarheidszones geplaatst voor hoge beschikbaarheid. Elke zone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke voeding, koeling en netwerken. Om tolerantie te garanderen, worden minimaal drie afzonderlijke zones ingesteld in alle ingeschakelde regio's. De fysieke scheiding van beschikbaarheidszones binnen een regio beschermt de gegevens tegen storingen in het datacenter. Bovendien worden twee FSFO-waarnemers ingesteld in twee beschikbaarheidszones om de database te initiëren en een failover naar de secundaire database uit te voeren wanneer er een storing optreedt.

U kunt andere waarnemers of stand-bydatabases instellen in een andere beschikbaarheidszone, AZ 1, in dit geval, dan de zone die in de voorgaande architectuur wordt weergegeven. Ten slotte bewaakt Oracle Enterprise Manager (OEM) Oracle-databases voor uptime en prestaties. Met OEM kunt u ook verschillende prestatie- en gebruiksrapporten genereren.

In regio's waar beschikbaarheidszones niet worden ondersteund, kunt u beschikbaarheidssets gebruiken om uw Oracle Database op een maximaal beschikbare manier te implementeren. Met beschikbaarheidssets kunt u een vm-uptime van 99,95% bereiken. Het volgende diagram is een referentiearchitectuur van dit gebruik:

Diagram that shows Oracle Database using availability sets with Data Guard Broker - FSFO.

Notitie

  • Omdat er slechts één exemplaar van OEM wordt geïmplementeerd, hoeft u de Oracle Enterprise Manager-VM niet in een beschikbaarheidsset te plaatsen.
  • Ultraschijven worden momenteel niet ondersteund in een configuratie van een beschikbaarheidsset.

Oracle Data Guard Far Sync

Oracle Data Guard Far Sync biedt geen bescherming tegen gegevensverlies voor Oracle-databases. Met deze mogelijkheid kunt u zich beschermen tegen gegevensverlies als uw databasecomputer uitvalt. Oracle Data Guard Far Sync moet worden geïnstalleerd op een afzonderlijke VIRTUELE machine. Far Sync is een lichtgewicht Oracle-exemplaar dat alleen een besturingsbestand, wachtwoordbestand, spfile en stand-bylogboeken heeft. Er zijn geen gegevensbestanden of logboekbestanden opnieuw.

Voor beveiliging tegen gegevensverlies moet er synchrone communicatie zijn tussen uw primaire database en het far sync-exemplaar. De Far Sync-instantie ontvangt op een synchrone manier opnieuw van de primaire instantie en stuurt deze onmiddellijk door naar alle stand-bydatabases op een asynchrone manier. Deze installatie vermindert ook de overhead voor de primaire database, omdat deze alleen de redo naar het far sync-exemplaar hoeft te verzenden in plaats van alle stand-bydatabases. Als een Far Sync-exemplaar mislukt, gebruikt Data Guard automatisch asynchroon transport naar de secundaire database van de primaire database om gegevensverlies bijna nul te beschermen. Voor extra tolerantie kunnen klanten meerdere Far Sync-exemplaren per database-exemplaar implementeren, inclusief primaire en secundaire exemplaren.

Het volgende diagram is een architectuur met hoge beschikbaarheid met Oracle Data Guard Far Sync:

Diagram that shows Oracle database using availability zones with Data Guard Far Sync & Broker - FSFO.

In de voorgaande architectuur is er een Far Sync-exemplaar geïmplementeerd in dezelfde beschikbaarheidszone als het database-exemplaar om de latentie tussen de twee te verminderen. In gevallen waarin de toepassing latentiegevoelig is, kunt u overwegen om uw database en Far Sync-exemplaar of exemplaren in een nabijheidsplaatsingsgroep te implementeren.

Het volgende diagram is een architectuur die gebruikmaakt van Oracle Data Guard FSFO en Far Sync voor hoge beschikbaarheid en herstel na noodgevallen:

Diagram that shows Oracle Database using availability zones for disaster recovery with Data Guard Far Sync and Broker - FSFO.

Oracle GoldenGate

GoldenGate maakt het mogelijk om gegevens op transactieniveau uit te wisselen en te manipuleren tussen meerdere heterogene platforms in de hele onderneming. Het verplaatst vastgelegde transacties met transactie-integriteit en minimale overhead voor uw bestaande infrastructuur. De modulaire architectuur biedt u de flexibiliteit om geselecteerde gegevensrecords, transactionele wijzigingen en wijzigingen in DDL (Data Definition Language) in verschillende topologieën te extraheren en te repliceren.

Met Oracle GoldenGate kunt u uw database configureren voor hoge beschikbaarheid door bidirectionele replicatie te bieden. Met deze methode kunt u een configuratie met meerdere masters of actief-actief instellen. Het volgende diagram is een aanbevolen architectuur voor oracle GoldenGate actief-actief instellen in Azure. In de volgende architectuur is de Oracle-database geconfigureerd met behulp van een voor hyperthreaded geheugen geoptimaliseerde virtuele machine met beperkte kern-vCPU's om te besparen op licentiekosten en de prestaties te maximaliseren. De architectuur maakt gebruik van meerdere Premium- of Ultra-schijven (beheerde schijven) voor prestaties en beschikbaarheid.

Diagram that shows Oracle Database using availability zones with Data Guard Broker - FSFO.

Notitie

Een vergelijkbare architectuur kan worden ingesteld met behulp van beschikbaarheidssets in regio's waar momenteel geen beschikbaarheidszones beschikbaar zijn.

Oracle GoldenGate heeft processen zoals Extract, Pump en Replicat waarmee u uw gegevens asynchroon kunt repliceren van de ene Oracle-databaseserver naar de andere. Met deze processen kunt u een bidirectionele replicatie instellen om hoge beschikbaarheid van uw database te garanderen als er downtime op zoneniveau beschikbaar is.

In het voorgaande diagram wordt het extractproces uitgevoerd op dezelfde server als uw Oracle-database. De gegevenspomp- en replicatprocessen worden uitgevoerd op een afzonderlijke server in dezelfde beschikbaarheidszone. Het Replicat-proces wordt gebruikt voor het ontvangen van gegevens uit de database in de andere beschikbaarheidszone en het doorvoeren van de gegevens naar de Oracle-database in de beschikbaarheidszone. Op dezelfde manier verzendt het gegevenspompproces gegevens die door het extractproces worden geëxtraheerd naar het Replicat-proces in de andere beschikbaarheidszone.

Terwijl in het voorgaande architectuurdiagram de gegevenspomp- en replicatprocessen worden weergegeven die zijn geconfigureerd op een afzonderlijke server, kunt u alle Oracle GoldenGate-processen op dezelfde server instellen op basis van de capaciteit en het gebruik van uw server. Raadpleeg altijd uw AWR-rapport en de metrische gegevens in Azure om inzicht te hebben in het gebruikspatroon van uw server.

Bij het instellen van Oracle GoldenGate bidirectionele replicatie in verschillende beschikbaarheidszones of verschillende regio's, is het belangrijk om ervoor te zorgen dat de latentie tussen de verschillende onderdelen acceptabel is voor uw toepassing. De latentie tussen beschikbaarheidszones en regio's kan variëren. Latentie is afhankelijk van meerdere factoren. U wordt aangeraden prestatietests in te stellen tussen uw toepassingslaag en uw databaselaag in verschillende beschikbaarheidszones of regio's. De tests kunnen bevestigen dat de configuratie voldoet aan de prestatievereisten van uw toepassing.

De toepassingslaag kan worden ingesteld in een eigen subnet en de databaselaag kan worden gescheiden in een eigen subnet. Overweeg indien mogelijk Azure-toepassing Gateway te gebruiken om verkeer tussen uw toepassingsservers te verdelen. Application Gateway is een robuuste load balancer voor webverkeer. Het biedt sessieaffiniteit op basis van cookies die een gebruikerssessie op dezelfde server bewaart, waardoor de conflicten in de database worden geminimaliseerd. Alternatieven voor Application Gateway zijn Azure Load Balancer en Azure Traffic Manager.

Oracle Sharding

Sharding is een gegevenslaagpatroon dat is geïntroduceerd in Oracle 12.2. Hiermee kunt u uw gegevens horizontaal partitioneren en schalen in onafhankelijke databases. Het is een share-nothing-architectuur waarin elke database wordt gehost op een toegewezen virtuele machine. Dit patroon maakt een hoge lees- en schrijfdoorvoer mogelijk, naast tolerantie en verbeterde beschikbaarheid.

Dit patroon elimineert single points of failure, biedt foutisolatie en maakt rolling upgrades zonder downtime mogelijk. De downtime van een shard of een storing op datacenterniveau heeft geen invloed op de prestaties of beschikbaarheid van de andere shards in andere datacenters.

Sharding is geschikt voor OLTP-toepassingen met hoge doorvoer die geen downtime kunnen betalen. Alle rijen met dezelfde shardingsleutel zijn altijd gegarandeerd op dezelfde shard. Dit feit verhoogt de prestaties en biedt hoge consistentie. Toepassingen die gebruikmaken van sharding moeten een goed gedefinieerd gegevensmodel en een strategie voor gegevensdistributie hebben, zoals consistente hash, bereik, lijst of samengesteld. De strategie heeft voornamelijk toegang tot gegevens met behulp van een sharding-sleutel, bijvoorbeeld customerId of accountNum. Met sharding kunt u ook bepaalde gegevenssets dichter bij de eindklanten opslaan, zodat u aan uw prestatie- en nalevingsvereisten kunt voldoen.

U wordt aangeraden uw shards te repliceren voor hoge beschikbaarheid en herstel na noodgevallen. Deze installatie kan worden uitgevoerd met behulp van Oracle-technologieën zoals Oracle Data Guard of Oracle GoldenGate. Een replicatie-eenheid kan een shard, een deel van een shard of een groep shards zijn. Een storing of vertraging van een of meer shards heeft geen invloed op de beschikbaarheid van een shard-database.

Voor hoge beschikbaarheid kunnen de stand-by-shards worden geplaatst in dezelfde beschikbaarheidszone waar de primaire shards worden geplaatst. Voor herstel na noodgevallen kunnen de stand-by-shards zich in een andere regio bevinden. U kunt ook shards implementeren in meerdere regio's om verkeer in die regio's te verwerken. Zie Hoge beschikbaarheid op Shard-niveau voor meer informatie over het configureren van hoge beschikbaarheid en replicatie van uw shard-database.

Oracle Sharding bestaat voornamelijk uit de volgende onderdelen. Zie Oracle Sharding Overview voor meer informatie:

  • Shard-catalogus. Speciale Oracle-database die een permanent archief is voor alle configuratiegegevens van de Shard-database. Alle configuratiewijzigingen, zoals het toevoegen of verwijderen van shards, het toewijzen van de gegevens en DDLs in een sharddatabase, worden gestart in de shardcatalogus. De shard-catalogus bevat ook de hoofdkopie van alle gedupliceerde tabellen in een SDB.

    De shard-catalogus maakt gebruik van gerealiseerde weergaven om wijzigingen in gedupliceerde tabellen in alle shards automatisch te repliceren. De shard-catalogusdatabase fungeert ook als een querycoördinator die wordt gebruikt voor het verwerken van multi-shardquery's en query's die geen shardingsleutel opgeven.

    We raden u aan Oracle Data Guard te gebruiken met beschikbaarheidszones of beschikbaarheidssets voor hoge beschikbaarheid van shard-catalogussen als best practice. De beschikbaarheid van de shard-catalogus heeft geen invloed op de beschikbaarheid van de shard-database. Een downtime in de shardcatalogus is alleen van invloed op onderhoudsbewerkingen en multishardquery's gedurende de korte periode dat de Data Guard-failover is voltooid. De SDB blijft onlinetransacties routeren en uitvoeren. Een catalogusstoring heeft geen invloed op deze storingen.

  • Shard-directeuren. Lichtgewicht services die moeten worden geïmplementeerd in elke regio/beschikbaarheidszone waarin uw shards zich bevinden. Shard-directeuren zijn Global Service Managers die zijn geïmplementeerd in de context van Oracle Sharding. Voor hoge beschikbaarheid raden we u aan ten minste één shard-directeur te implementeren in elke beschikbaarheidszone waarin uw shards aanwezig zijn.

    Wanneer de shard-directeur in eerste instantie verbinding maakt met de database, stelt de shard-directeur de routeringsinformatie in en slaat de gegevens in de cache op voor volgende aanvragen, waardoor de shard-director wordt overgeslagen. Zodra de sessie tot stand is gebracht met een shard, worden alle SQL-query's en DML's ondersteund en uitgevoerd in het bereik van de opgegeven shard. Deze routering is snel en wordt gebruikt voor alle OLTP-workloads die intra-shardtransacties uitvoeren. U wordt aangeraden directe routering te gebruiken voor alle OLTP-workloads waarvoor de hoogste prestaties en beschikbaarheid zijn vereist. De routeringscache wordt automatisch vernieuwd wanneer een shard niet beschikbaar is of als er wijzigingen optreden in de shardingtopologie.

    Voor hoogwaardige gegevensafhankelijke routering raadt Oracle aan om een verbindingsgroep te gebruiken bij het openen van gegevens in de shard-database. Oracle-verbindingsgroepen, taalspecifieke bibliotheken en stuurprogramma's ondersteunen Oracle Sharding. Zie Oracle Sharding Overview (Overzicht van Oracle Sharding) voor meer informatie.

  • Wereldwijde service. De globale service is vergelijkbaar met de reguliere databaseservice. Naast alle eigenschappen van een databaseservice heeft een globale service eigenschappen voor shard-databases. Deze eigenschappen omvatten regioaffiniteit tussen clients en shard- en replicatievertragingstolerantie. Er hoeft slechts één globale service te worden gemaakt om gegevens naar en van een shard-database te lezen/schrijven. Wanneer u Active Data Guard gebruikt en alleen-lezenreplica's van de shards instelt, kunt u een andere globale service maken voor alleen-lezen workloads. De client kan deze globale services gebruiken om verbinding te maken met de database.

  • Sharddatabases. Sharddatabases zijn uw Oracle-databases. Elke database wordt gerepliceerd met Oracle Data Guard in een Broker-configuratie waarvoor FSFO is ingeschakeld. U hoeft geen Data Guard-failover en replicatie in te stellen voor elke shard. Dit aspect wordt automatisch geconfigureerd en geïmplementeerd wanneer de gedeelde database wordt gemaakt. Als een bepaalde shard mislukt, voert Oracle Sharing een failover uit van databaseverbindingen van de primaire naar de stand-by.

U kunt Shard-databases van Oracle implementeren en beheren met twee interfaces: oracle Enterprise Manager Cloud Control GUI en het GDSCTL opdrachtregelhulpprogramma. U kunt zelfs de verschillende shards bewaken voor beschikbaarheid en prestaties met behulp van cloudbeheer. Met GDSCTL DEPLOY de opdracht worden automatisch de shards en hun respectieve listeners gemaakt. Bovendien implementeert deze opdracht automatisch de replicatieconfiguratie die wordt gebruikt voor hoge beschikbaarheid op shardniveau die is opgegeven door de beheerder.

Er zijn verschillende manieren om een database te sharden:

  • Door het systeem beheerde sharding: verdeelt automatisch over shards met behulp van partitionering
  • Door de gebruiker gedefinieerde sharding: hiermee kunt u de toewijzing van de gegevens aan de shards opgeven. Dit werkt goed wanneer er wettelijke vereisten of vereisten voor gegevenslokalisatie zijn
  • Samengestelde sharding: een combinatie van door het systeem beheerde en door de gebruiker gedefinieerde sharding voor verschillende shardspaces
  • Tabelsubpartities: vergelijkbaar met een normale gepartitioneerde tabel

Zie Sharding Methods voor meer informatie.

Een shard-database ziet eruit als één database voor toepassingen en ontwikkelaars. Wanneer u migreert naar een shard-database, moet u zorgvuldig bepalen welke tabellen worden gedupliceerd versus sharded.

Gedupliceerde tabellen worden opgeslagen op alle shards, terwijl shard-tabellen worden verdeeld over verschillende shards. U wordt aangeraden kleine en dimensionale tabellen te dupliceren en de feitentabellen te verdelen/sharden. Gegevens kunnen in uw shard-database worden geladen met behulp van de shardcatalogus als de centrale coördinator of door Gegevenspomp uit te voeren op elke shard. Zie Gegevens migreren naar een Shard-database voor meer informatie.

Oracle Sharding met Data Guard

Oracle Data Guard kan worden gebruikt voor sharding met door het systeem beheerde, door de gebruiker gedefinieerde en samengestelde shardingmethoden.

Het volgende diagram is een referentiearchitectuur voor Oracle Sharding met Oracle Data Guard die wordt gebruikt voor hoge beschikbaarheid van elke shard. In het architectuurdiagram ziet u een samengestelde shardingmethode. Het architectuurdiagram verschilt waarschijnlijk voor toepassingen met verschillende vereisten voor gegevenslocatie, taakverdeling, hoge beschikbaarheid en herstel na noodgevallen. Toepassingen kunnen een andere methode gebruiken voor sharding. Met Oracle Sharding kunt u aan deze vereisten voldoen en horizontaal en efficiënt schalen door deze opties te bieden. Een vergelijkbare architectuur kan zelfs worden geïmplementeerd met Oracle GoldenGate.

Diagram that shows Oracle Database Sharding using availability zones with Data Guard Broker - FSFO.

Door het systeem beheerde sharding is het eenvoudigst te configureren en te beheren. Door de gebruiker gedefinieerde sharding of samengestelde sharding is geschikt voor scenario's waarin uw gegevens en toepassing geografisch zijn gedistribueerd of in scenario's waarin u controle moet hebben over de replicatie van elke shard.

In de voorgaande architectuur wordt samengestelde sharding gebruikt om de gegevens te distribueren en uw toepassingslagen horizontaal uit te schalen. Samengestelde sharding is een combinatie van door het systeem beheerde en door de gebruiker gedefinieerde sharding en biedt dus het voordeel van beide methoden. In het voorgaande scenario worden gegevens eerst verdeeld over meerdere shardruimten, gescheiden door regio's. Vervolgens worden de gegevens verder gepartitioneerd met behulp van consistente hash voor meerdere shards in de shardspace.

Elke shardspace bevat meerdere shardgroepen. Elke shardgroep heeft meerdere shards en is een replicatie-eenheid. Elke shardgroep bevat alle gegevens in de shardspace. Shardgroups A1 en B1 zijn primaire shardgroups, terwijl shardgroups A2 en B2 stand-bys zijn. U kunt ervoor kiezen om afzonderlijke shards te gebruiken als replicatie-eenheid in plaats van een shardgroep.

In de voorgaande architectuur wordt een Global Service Manager (GSM)/shard director geïmplementeerd in elke beschikbaarheidszone voor hoge beschikbaarheid. U wordt aangeraden ten minste één GSM/shard-directeur per datacenter/regio te implementeren. Daarnaast wordt een exemplaar van de toepassingsserver geïmplementeerd in elke beschikbaarheidszone die een shardgroep bevat. Met deze installatie kan de toepassing de latentie tussen de toepassingsserver en de database/shardgroup laag houden. Als een database mislukt, kan de toepassingsserver in dezelfde zone als de stand-bydatabase aanvragen verwerken zodra de overgang van de databaserol plaatsvindt. Azure-toepassing Gateway en de shard-directeur houden de latentie van aanvragen en antwoorden en routeaanvragen dienovereenkomstig bij.

Vanuit het oogpunt van een toepassing doet het clientsysteem een aanvraag voor Azure-toepassing Gateway of andere taakverdelingstechnologieën in Azure, waarmee de aanvraag wordt omgeleid naar de regio die het dichtst bij de client ligt. Azure-toepassing Gateway ondersteunt ook plaksessies, zodat aanvragen die afkomstig zijn van dezelfde client, worden doorgestuurd naar dezelfde toepassingsserver. De toepassingsserver maakt gebruik van groepsgewijze verbindingen in stuurprogramma's voor gegevenstoegang. Deze functie is beschikbaar in stuurprogramma's zoals JDBC, ODP.NET en OCI. De stuurprogramma's kunnen shardingsleutels herkennen die zijn opgegeven als onderdeel van de aanvraag. Oracle Universal Verbinding maken ion Pool (UCP) voor JDBC-clients kan niet-Oracle-toepassingsclients, zoals Apache Tomcat en IIS, inschakelen voor gebruik met Oracle Sharding. Zie Overzicht van gedeelde UCP-pool voor database-sharding voor meer informatie.

Tijdens de eerste aanvraag maakt de toepassingsserver verbinding met de shard-director in de regio om routeringsgegevens op te halen voor de shard waarnaar de aanvraag moet worden gerouteerd. Op basis van de doorgegeven shardingsleutel stuurt de directeur de toepassingsserver naar de respectieve shard. De toepassingsserver slaat deze informatie in de cache op door een kaart te maken en voor volgende aanvragen wordt de shard-directeur omzeild en worden aanvragen rechtstreeks naar de shard gerouteerd.

Oracle Sharding met GoldenGate

Het volgende diagram is een referentiearchitectuur voor Oracle Sharding met Oracle GoldenGate voor hoge beschikbaarheid in regio's van elke shard. In tegenstelling tot de voorgaande architectuur geeft deze architectuur alleen hoge beschikbaarheid weer binnen één Azure-regio, met meerdere beschikbaarheidszones. U kunt een shard-database met meerdere regio's met hoge beschikbaarheid implementeren, vergelijkbaar met het voorgaande voorbeeld, met behulp van Oracle GoldenGate.

Diagram that shows Oracle Database Sharding using availability zones with GoldenGate.

De voorgaande referentiearchitectuur maakt gebruik van de door het systeem beheerde shardingmethode om de gegevens te sharden. Omdat Oracle GoldenGate-replicatie wordt uitgevoerd op segmentniveau, kunnen de helft van de gegevens die naar één shard worden gerepliceerd, worden gerepliceerd naar een andere shard. De andere helft kan worden gerepliceerd naar een andere shard.

De manier waarop de gegevens worden gerepliceerd, is afhankelijk van de replicatiefactor. Met een replicatiefactor van twee hebt u twee kopieën van elk segment gegevens in uw drie shards in de shardgroup. Op dezelfde manier worden met een replicatiefactor van drie en drie shards in uw shardgroep alle gegevens in elke shard gerepliceerd naar elke andere shard in de shardgroep. Elke shard in de shardgroep kan een andere replicatiefactor hebben. Met deze installatie kunt u uw ontwerp voor hoge beschikbaarheid en herstel na noodgevallen efficiënt definiëren binnen een shardgroep en meerdere shardgroepen.

In de voorgaande architectuur bevatten shardgroup A en shardgroup B beide dezelfde gegevens, maar bevinden ze zich in verschillende beschikbaarheidszones. Als zowel shardgroup A als shardgroup B dezelfde replicatiefactor van drie hebben, wordt elke rij/segment van uw shardtabel zes keer gerepliceerd in de twee shardgroepen. Als shardgroup A een replicatiefactor van drie heeft en shardgroup B een replicatiefactor van twee heeft, wordt elke rij/segment vijf keer gerepliceerd in de twee shardgroepen.

Deze installatie voorkomt gegevensverlies als er een fout op exemplaarniveau of beschikbaarheidszoneniveau optreedt. De toepassingslaag kan lezen van en schrijven naar elke shard. Om conflicten te minimaliseren, wijst Oracle Sharding een hoofdsegment aan voor elk bereik van hash-waarden. Deze functie zorgt ervoor dat schrijfaanvragen voor een bepaald segment worden omgeleid naar het bijbehorende segment. Daarnaast biedt Oracle GoldenGate automatische conflictdetectie en -oplossing voor het afhandelen van conflicten die zich kunnen voordoen. Zie Oracle GoldenGate gebruiken met een Sharded-database voor meer informatie en beperkingen voor het implementeren van GoldenGate met Oracle Sharding.

In de voorgaande architectuur wordt een GSM/shard-directeur geïmplementeerd in elke beschikbaarheidszone voor hoge beschikbaarheid. U wordt aangeraden ten minste één GSM/shard-directeur per datacenter of regio te implementeren. Een exemplaar van de toepassingsserver wordt geïmplementeerd in elke beschikbaarheidszone die een shardgroep bevat. Met deze installatie kan de toepassing de latentie tussen de toepassingsserver en de database/shardgroup laag houden. Als een database mislukt, kan de toepassingsserver in dezelfde zone als de stand-bydatabase aanvragen verwerken zodra de databaserol overgaat. Azure-toepassing Gateway en de shard-directeur houden de latentie van aanvragen en antwoorden en routeaanvragen dienovereenkomstig bij.

Vanuit het oogpunt van een toepassing doet het clientsysteem een aanvraag voor Azure-toepassing Gateway of andere taakverdelingstechnologieën in Azure, waarmee de aanvraag wordt omgeleid naar de regio die het dichtst bij de client ligt. Azure-toepassing Gateway ondersteunt ook plaksessies, zodat aanvragen die afkomstig zijn van dezelfde client, worden doorgestuurd naar dezelfde toepassingsserver. De toepassingsserver maakt gebruik van groepsgewijze verbindingen in stuurprogramma's voor gegevenstoegang. Deze functie is beschikbaar in stuurprogramma's zoals JDBC, ODP.NET en OCI. De stuurprogramma's kunnen shardingsleutels herkennen die zijn opgegeven als onderdeel van de aanvraag. Oracle Universal Verbinding maken ion Pool (UCP) voor JDBC-clients kan niet-Oracle-toepassingsclients, zoals Apache Tomcat en IIS, inschakelen voor gebruik met Oracle Sharding.

Tijdens de eerste aanvraag maakt de toepassingsserver verbinding met de shard-director in de regio om routeringsgegevens op te halen voor de shard waarnaar de aanvraag moet worden gerouteerd. Op basis van de doorgegeven shardingsleutel stuurt de directeur de toepassingsserver naar de respectieve shard. De toepassingsserver slaat deze informatie in de cache op door een kaart te maken en voor volgende aanvragen wordt de shard-directeur omzeild en worden aanvragen rechtstreeks naar de shard gerouteerd.

Patchen en onderhoud

Wanneer u uw Oracle-workloads implementeert in Azure, zorgt Microsoft voor patching op hostbesturingssysteemniveau. Microsoft communiceert vooraf gepland onderhoud op besturingssysteemniveau aan klanten. Twee servers van twee verschillende beschikbaarheidszones worden nooit tegelijkertijd gepatcht. Zie Beschikbaarheidsopties voor virtuele Azure-machines voor meer informatie over VM-onderhoud en patching.

Het patchen van het besturingssysteem van uw virtuele machine kan worden geautomatiseerd met behulp van Azure Automation UpdateBeheer. Het patchen en onderhouden van uw Oracle-database kan worden geautomatiseerd en gepland met behulp van Azure Pipelines of Azure Automation Update Management om downtime te minimaliseren. Zie Progressive exposure techniques (Progressive exposure techniques ) voor meer informatie over continue levering en blauw/groen implementaties.

Overwegingen voor architectuur en ontwerp

  • Overweeg het gebruik van voor hyperthreaded geheugen geoptimaliseerde virtuele machine met beperkte kern-vCPU's voor uw Oracle Database-VM om te besparen op licentiekosten en de prestaties te maximaliseren. Gebruik meerdere Premium- of Ultra-schijven (beheerde schijven) voor prestaties en beschikbaarheid.
  • Wanneer u beheerde schijven gebruikt, kan de naam van de schijf/het apparaat worden gewijzigd bij opnieuw opstarten. U wordt aangeraden de UUID van het apparaat te gebruiken in plaats van de naam om ervoor te zorgen dat de koppeling behouden blijft in sprite van opnieuw opstarten. Zie Het nieuwe bestandssysteem toevoegen aan /etc/fstab voor meer informatie.
  • Gebruik beschikbaarheidszones om hoge beschikbaarheid in de regio te bereiken.
  • Overweeg ultraschijven te gebruiken wanneer deze beschikbaar zijn of Premium-schijven voor uw Oracle-database.
  • Overweeg om een stand-by Oracle-database in een andere Azure-regio in te stellen met Oracle Data Guard.
  • Overweeg nabijheidsplaatsingsgroepen te gebruiken om de latentie tussen uw toepassing en databaselaag te verminderen.
  • De maximale netwerkbandbreedte van Azure-VM's is (doorgaans) hoger dan de maximale schijfdoorvoer op dezelfde SKU. U kunt hogere doorvoer bereiken op dezelfde VM-SKU of een kleinere VM-SKU gebruiken met behulp van hoogwaardige, lage latentie netwerkopslag zoals Azure NetApp Files. voor de database.
  • Oracle Enterprise Manager instellen voor beheer, bewaking en logboekregistratie.
  • Overweeg het gebruik van Oracle Automatic Storage Management voor gestroomlijnd opslagbeheer voor uw database.
  • Gebruik Azure Pipelines om patches en updates voor uw database te beheren zonder uitvaltijd.
  • Pas uw toepassingscode aan om cloudeigen patronen toe te voegen die uw toepassing kunnen helpen toleranter te zijn. Overweeg patronen zoals patroon voor opnieuw proberen, circuitonderbrekerpatroon en andere patronen die zijn gedefinieerd in de handleiding Cloudontwerppatronen.

Volgende stappen

Bekijk de volgende Oracle-referentieartikelen die van toepassing zijn op uw scenario.