Delen via

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
  • Gedefinieerde RPO- en RTO-vereisten

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.

Voor replicatie van gegevens op lange afstand wordt u aangeraden gebruik te maken van Far Sync. Far Sync is een Oracle Active Data Guard-functie.

Notitie

Als u Far Sync inschakelt, hebt u een Active Data Guard-licentie nodig. Neem contact op met uw Oracle-vertegenwoordiger om de gevolgen van licenties te bespreken.

Oracle Far Sync heeft betrekking op een lange afstand tussen de primaire database en de secundaire database door een tussenliggende server te introduceren die bekend staat als een far sync-exemplaar. Deze server ontvangt opnieuw gegevens van de primaire database en stuurt deze vervolgens door naar de stand-bydatabase. Hierdoor wordt het Far Sync-exemplaar dichter bij de primaire instantie geplaatst om de communicatietijd te verminderen. De Far Sync-server draagt de gegevens vervolgens asynchroon over naar de secundaire database.

Notitie

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

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.

Oracle Data Guard met fast-startfailover

Data Guard kan worden geïmplementeerd met behulp van Fast Start Failover (FSFO). Fast-Start-Failover is een functie binnen de Data Guard Broker-configuratie. Met deze functie kunt u automatisch een failover uitvoeren in het geval van een fout. De standaardtijd die klanten gebruiken, zijn 30 seconden, maar kunnen worden aangepast aan uw vereisten. Deze zogenaamde OperationTimeout maakt deel uit van de Data Guard-eigenschappen die u tijdens uw implementatie definieert.

Hoe werkt Data Guard met deze eigenschap?

Data Guards-taak is het continu bewaken van de status en de status van de primaire en de secundaire database. Zodra u Fast-Start-Failover (FSFO) inschakelt, wordt het waarnemersproces geactiveerd en wordt de status regelmatig gecontroleerd om hoge beschikbaarheid op elk gewenst moment te garanderen.

Als de primaire database nu niet beschikbaar is, detecteert de waarnemer en Data Guard Broker deze onderbreking. Hierdoor geeft de parameter OperationTimeout van 30 seconden aan hoe lang de Broker moet wachten op een reactie van de primaire database voordat er verdere actie wordt ondernomen.

Wat vervolgens resulteert in als de primaire niet reageert binnen dit venster van 30 seconden, gaat de waarnemer ervan uit dat de primaire niet toegankelijk is en het failoverproces begint.

De Broker bevordert onmiddellijk de stand-bydatabase naar de primaire status, schakelt de rollen over en zorgt ervoor dat de toepassing snel kan worden hervat vanuit de stand-by.

Gedurende deze tijd zorgt de Broker er ook voor dat transacties up-to-date zijn op de stand-by. Met de modus die u configureert, die maximale beschikbaarheid of maximale beveiliging kan zijn, biedt een synchrone replicatie minimaal tot nul gegevensverlies. 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 failover naar de secundaire database te initiëren in geval van een storing. Nadat de failover is uitgevoerd en de vorige primaire database opnieuw beschikbaar is, kan deze opnieuw worden hersteld. De Data Guard Broker faciliteert dit proces.

Als de primaire database uiteindelijk niet beschikbaar is vanwege een geplande of niet-geplande storing, schakelt Data Guard over of voert u een failover uit naar uw stand-bydatabase.

Deze functie kan extra tolerantie bieden door de waarnemer in te stellen op een afzonderlijke virtuele machine. Hierdoor implementeert u de waarnemer op een lichtgewicht VM. Met deze aanpak kunnen hoge beschikbaarheid en tolerantie worden gebruikt.

Met Oracle Database versie 12.2 en hoger is het ook mogelijk om meerdere waarnemers te configureren met één Oracle Data Guard-brokerconfiguratie. Het biedt extra beschikbaarheid, voor het geval één waarnemer en de secundaire database uitvaltijd ervaren. Zie Oracle Data Guard Broker Concepts voor meer informatie over Data Guard Broker en de voordelen ervan.

In het volgende diagram ziet u een Oracle Data Guard-installatie zonder Far Sync met een hersteltijd van minder dan 5 minuten.

Diagram met een Oracle Data Guard-architectuur.

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 failover naar de secundaire database te initiëren in geval van een storing.

Notitie

Wanneer u een symmetrische Data Guard-implementatie plant, moet u nog één waarnemer in de beschikbaarheidszone drie nodig hebben.

Daarnaast raden we u ten zeerste aan de Oracle Enterprise Manager te implementeren om een overzicht van de databaselaag te houden. Azure Monitor wordt aanbevolen om te worden geïmplementeerd met de volgende metrische gegevens: De schijven bewaken:

  • Verbruikt percentage IOPS van besturingssysteemschijf
  • Verbruikt percentage gegevensschijf-IOPS
  • Bytes per seconde lezen van gegevensschijf
  • Gegevensschijf schrijft bytes per seconde
  • Diepte van schijfwachtrij
  • Schijfbandbreedte in % per lun

Naast het bovenstaande raden we u ten zeerste aan om ook de VM-inzichten in te schakelen.

De virtuele machine wordt gekozen op basis van uw AWR-evaluatie. Raadpleeg Oracle Capacity Planning voor meer informatie. We raden u ten zeerste aan gebruik te maken van beperkte kern-vCPU's om te besparen op licentiekosten en de prestaties te maximaliseren.

De keuze van het schijftype is afhankelijk van de uitvoer van uw AWR-evaluatie.

Zoals hierboven vermeld, is Far Sync een mogelijkheid die voornamelijk wordt gebruikt in scenario's waarin u repliceert tussen regio's die lange afstanden overwinnen. Naar dit scenario verwijst, biedt Oracle Active Data Guard Far Sync geen bescherming tegen gegevensverlies voor Oracle-databases. Oracle Far Sync-exemplaar moet worden geïnstalleerd op een afzonderlijke VIRTUELE machine.

Premium SSD v2 wordt niet ondersteund voor bestanden die verwijzen naar het besturingssysteem. Ga voor meer informatie naar Deploy Premium SSD v2.

Als Back-upbestemming wordt Azure Premium Files gebruikt. Deze oplossing is het meest presterende. U kunt Azure Blob Storage ook gebruiken als back-upbestemming. Zorg er altijd voor dat u test welke optie het beste bij u past. Ga ook naar Oracle Database Backup Strategies.

Oracle Data Guard Far Sync

Zoals hierboven vermeld, is Far Sync een mogelijkheid die voornamelijk wordt gebruikt in scenario's waarin u repliceert tussen regio's die lange afstanden overwinnen. Met betrekking tot dit scenario biedt Oracle Far Sync geen bescherming tegen gegevensverlies voor Oracle-databases. Het Oracle Far Sync-exemplaar moet worden geïnstalleerd op een afzonderlijke VIRTUELE machine.

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 Active Data Guard automatisch asynchroon transport naar de secundaire database van de primaire database om beveiliging tegen gegevensverlies vrijwel nul te behouden. Voor extra tolerantie kunnen klanten meerdere Far Sync-exemplaren per database-exemplaar implementeren, inclusief primaire en secundaire exemplaren.

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

Diagram met Oracle Database met far sync in een Active Data Guard-configuratie in verschillende regio's.

Notitie

Wanneer u een symmetrische Far Sync-implementatie plant, moet u er rekening mee houden dat u nog één far sync-exemplaar in de tweede regio nodig hebt.

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 aanpak kunt u een multimaster - of actief-actieve configuratie instellen waarvoor kennis op toepassingsniveau is vereist. 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 met Oracle Database met behulp van beschikbaarheidszones met 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 met Oracle Database Sharding met behulp van beschikbaarheidszones met 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. UCP (Oracle Universal Connection Pool) 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 met Oracle Database Sharding met behulp van beschikbaarheidszones met 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. UCP (Oracle Universal Connection Pool) 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.
  • Inleiding tot Oracle Data Guard
  • 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.