Architecturen voor Oracle Database Enterprise Edition in Azure

Artikel
06/14/2024

Van toepassing op: ✔️ Virtuele Linux-machines

Azure is de thuisbasis voor alle Oracle-workloads, inclusief workloads die optimaal moeten blijven werken in Azure met Oracle. Als u het Oracle Diagnostic Pack of de AWR (Automatic Workload Repository) hebt, kunt u gegevens over uw workloads verzamelen. Gebruik deze gegevens om de Oracle-workload te evalueren, de resourcebehoeften te bepalen en de workload naar Azure te migreren. De verschillende metrische gegevens van Oracle in deze rapporten kunnen inzicht bieden in de prestaties en het platformgebruik van toepassingen.

Dit artikel helpt u bij het voorbereiden van een Oracle-workload voor uitvoering in Azure en het verkennen van de beste architectuuroplossingen om optimale cloudprestaties te bieden. De gegevens van Oracle in het Statspack en nog meer in afstamming, de AWR, helpen u bij het ontwikkelen van duidelijke verwachtingen. Deze verwachtingen omvatten de limieten voor fysieke afstemming via architectuur, de voordelen van het logisch afstemmen van databasecode en het algehele databaseontwerp.

Verschillen tussen de twee omgevingen

Houd rekening met enkele belangrijke verschillen tussen de twee omgevingen wanneer u on-premises toepassingen naar Azure migreert.

Een belangrijk verschil is dat in een Azure-implementatie resources zoals VM's, schijven en virtuele netwerken worden gedeeld tussen andere clients. Daarnaast kunnen resources worden beperkt op basis van de vereisten. In plaats van te focussen op het vermijden van falen, richt Azure zich meer op het overleven van de fout. De eerste benadering probeert de gemiddelde tijd tussen storingen (MBTF) te verhogen en de tweede probeert de gemiddelde tijd voor herstel (MTTR) te verminderen.

De volgende tabel bevat enkele verschillen tussen een on-premises implementatie en een Azure-implementatie van een Oracle-database.

	On-premises implementatie	Azure-implementatie
Netwerken	LAN/WAN	Software-Defined Networking (SDN)
Beveiligingsgroep	Hulpprogramma's voor IP-/poortbeperking	Netwerkbeveiligingsgroep (NSG)
Veerkracht	Gemiddelde tijd tussen fouten	MTTR
Gepland onderhoud	Patchen/upgrades	Beschikbaarheidssets met patches/upgrades die worden beheerd door Azure
Resource	Toegewezen	Gedeeld met andere clients
Regio's	Datacenters	Regioparen
Storage	SAN/fysieke schijven	Door Azure beheerde opslag
Schaal wijzigen	Verticale schaal	Horizontaal schalen

Vereisten

Houd rekening met de volgende vereisten voordat u de migratie start:

Bepaal het werkelijke CPU-gebruik. Oracle-licenties per kern, wat betekent dat het aanpassen van de grootte van uw vCPU-behoeften essentieel kan zijn om u te helpen de kosten te verlagen.
Bepaal de grootte van de database, de back-upopslag en de groeisnelheid.
Bepaal de I/O-vereisten, die u kunt schatten op basis van Oracle Statspack en de AWR-rapporten. U kunt ook een schatting maken van de vereisten van hulpprogramma's voor opslagbewaking die beschikbaar zijn via het besturingssysteem.

Configuratieopties

Het is een goed idee om een AWR-rapport te genereren en er enkele metrische gegevens van te verkrijgen om u te helpen beslissingen te nemen over de configuratie. Vervolgens zijn er vier mogelijke gebieden die u kunt afstemmen om de prestaties in een Azure-omgeving te verbeteren:

Grootte van de virtuele machine
Netwerkdoorvoer
Schijftypen en -configuraties
Instellingen voor schijfcache

Een AWR-rapport genereren

Als u een bestaande Oracle Enterprise Edition-database hebt en van plan bent om te migreren naar Azure, hebt u verschillende opties. Als u het Diagnosepakket voor uw Oracle-exemplaren hebt, kunt u het Oracle AWR-rapport uitvoeren om de metrische gegevens op te halen, zoals IOPS, Mbps en GiBs. Voor die databases zonder de licentie voor Diagnostics Pack of voor een Oracle Standard Edition-database kunt u dezelfde belangrijke metrische gegevens verzamelen met een Statspack-rapport nadat u handmatige momentopnamen hebt verzameld. De belangrijkste verschillen tussen deze twee rapportagemethoden zijn dat AWR automatisch wordt verzameld en dat het meer informatie biedt over de database dan Statspack.

Overweeg om uw AWR-rapport uit te voeren tijdens zowel normale als piekworkloads, zodat u het kunt vergelijken. Als u de nauwkeurigere workload wilt verzamelen, kunt u een uitgebreid vensterrapport van één week overwegen, in plaats van één dag. AWR levert gemiddelden als onderdeel van de berekeningen in het rapport. De AWR-opslagplaats bewaart standaard acht dagen aan gegevens en maakt momentopnamen op uurintervallen.

Voor een migratie van een datacenter moet u rapporten verzamelen voor het aanpassen van de grootte van de productiesystemen. Maak een schatting van de resterende databasekopieën die worden gebruikt voor het testen, testen en ontwikkelen van gebruikers op percentages. Stel bijvoorbeeld een schatting van 50 procent van de grootte van de productie.

Gebruik de volgende opdracht om een AWR-rapport uit te voeren vanaf de opdrachtregel:

sqlplus / as sysdba
@$ORACLE_HOME/rdbms/admin/awrrpt.sql;

Belangrijke metrische gegevens

In het rapport wordt u gevraagd om de volgende informatie:

Rapporttype: HTML of TEKST. Het HTML-type biedt meer informatie.
Het aantal dagen dat momentopnamen moeten worden weergegeven. Voor intervallen van één uur produceert een rapport van één week bijvoorbeeld 168 momentopname-id's.
Het begin SnapshotID voor het rapportvenster.
Het einde SnapshotID voor het rapportvenster.
De naam van het rapport dat het AWR-script maakt.

Als u het AWR-rapport uitvoert op een Real Application Cluster (RAC), is het opdrachtregelrapport het awrgrpt.sql bestand in plaats van awrrpt.sql. Het g rapport maakt een rapport voor alle knooppunten in de RAC-database in één rapport. Dit rapport elimineert de noodzaak om één rapport uit te voeren op elk RAC-knooppunt.

U kunt de volgende metrische gegevens verkrijgen uit het AWR-rapport:

Databasenaam, instantienaam en hostnaam
Databaseversie voor ondersteuning door Oracle
CPU/kernen
SGA/PGA en adviseurs om u te laten weten of deze te weinig zijn
Totaal geheugen in GB
CPU-percentage bezet
DB-CPU's
IOPS (lezen/schrijven)
MBP's (lezen/schrijven)
Netwerkdoorvoer
Netwerklatentiefrequentie (laag/hoog)
Belangrijkste wachtevenementen
Parameterinstellingen voor database
Of de database nu RAC, Exadata of geavanceerde functies of configuraties gebruikt

Grootte van de virtuele machine

Hier volgen enkele stappen die u kunt uitvoeren om de grootte van virtuele machines te configureren voor optimale prestaties.

Vm-grootte schatten op basis van CPU-, geheugen- en I/O-gebruik uit het AWR-rapport

Bekijk de vijf belangrijkste getimede voorgrondgebeurtenissen die aangeven waar de knelpunten van het systeem zich bevinden. In het volgende diagram bevindt de synchronisatie van logboekbestanden zich bijvoorbeeld bovenaan. Het geeft het aantal wachttijden aan dat is vereist voordat de logboekschrijver de logboekbuffer naar het opnieuw logboekbestand schrijft. Deze resultaten geven aan dat betere prestaties van opslag of schijven vereist zijn. Daarnaast toont het diagram ook het aantal CPU-kernen en de hoeveelheid geheugen.

Schermopname van de synchronisatie van logboekbestanden boven aan de tabel.

In het volgende diagram ziet u de totale I/O van lezen en schrijven. Er zijn 59 GB gelezen en 247,3 GB geschreven tijdens het rapport.

Een VIRTUELE machine kiezen

Op basis van de informatie die u hebt verzameld uit het AWR-rapport, is de volgende stap het kiezen van een virtuele machine met een vergelijkbare grootte die aan uw vereisten voldoet. Zie Voor meer informatie over beschikbare VM's de grootten van virtuele machines die zijn geoptimaliseerd voor geheugen.

De grootte van de VM aanpassen met een vergelijkbare VM-serie op basis van de ACU

Nadat u de VIRTUELE machine hebt gekozen, moet u letten op de Azure-rekeneenheid (ACU) voor de VIRTUELE machine. U kunt een andere VIRTUELE machine kiezen op basis van de ACU-waarde die beter aan uw vereisten voldoet. Zie De Rekeneenheid van Azure voor meer informatie.

Schermopname van de pagina ACU-eenheden.

Netwerkdoorvoer

In het volgende diagram ziet u de relatie tussen doorvoer en IOPS:

Diagram waarin de relatie tussen doorvoer en IOPS wordt weergegeven. Dit is IOPS-tijds IO-grootte die gelijk is aan doorvoer.

De totale netwerkdoorvoer wordt geschat op basis van de volgende informatie:

SQL*Net-verkeer
MBps keert het aantal servers (uitgaande stream, zoals Oracle Data Guard)
Andere factoren, zoals toepassingsreplicatie

Schermopname van de SQL*Net-doorvoer.

Op basis van uw netwerkbandbreedtevereisten zijn er verschillende gatewaytypen waaruit u kunt kiezen. Deze typen omvatten basic, VpnGw en Azure ExpressRoute. Zie prijzen voor VPN Gateway voor meer informatie.

Aanbevelingen

Netwerklatentie is hoger in vergelijking met een on-premises implementatie. Het verminderen van netwerkrondes kan de prestaties aanzienlijk verbeteren.
Als u retouren wilt verminderen, consolideert u toepassingen met hoge transacties of chatty-apps op dezelfde virtuele machine.
Gebruik virtuele machines met versneld netwerken voor betere netwerkprestaties.
Voor bepaalde Linux-distributies kunt u TRIM/UNMAP-ondersteuning inschakelen.
Installeer Oracle Enterprise Manager op een afzonderlijke virtuele machine.
Enorme pagina's zijn niet standaard ingeschakeld in Linux. Overweeg om grote pagina's in te schakelen en in te stellen use_large_pages = ONLY op de Oracle DB. Deze aanpak kan helpen de prestaties te verbeteren. Zie USE_LARGE_PAGES voor meer informatie.

Schijftypen en -configuraties

Hier volgen enkele tips voor het overwegen van schijven.

Standaardbesturingssystemen: deze schijftypen bieden permanente gegevens en caching. Ze zijn geoptimaliseerd voor toegang tot het besturingssysteem bij het opstarten en zijn niet ontworpen voor transactionele of datawarehouseworkloads (analytische) workloads.
Beheerde schijven: Azure beheert de opslagaccounts die u gebruikt voor uw VM-schijven. U geeft het schijftype en de grootte op van de schijf die u nodig hebt. Het type is meestal Premium (SSD) voor Oracle-workloads. Azure maakt en beheert de schijf voor u. Een premium SSD-beheerde schijf is alleen beschikbaar voor de vm-serie die is geoptimaliseerd voor geheugen en ontworpen. Nadat u een bepaalde VM-grootte hebt gekozen, worden in het menu alleen de beschikbare Premium Storage-SKU's weergegeven die zijn gebaseerd op die VM-grootte.

Nadat u de opslag op een virtuele machine hebt geconfigureerd, wilt u de schijven mogelijk laden voordat u een database maakt. Als u de I/O-snelheid kent in termen van zowel latentie als doorvoer, kunt u bepalen of de VM's de verwachte doorvoer ondersteunen met latentiedoelen. Er zijn verschillende hulpprogramma's voor het testen van toepassingsbelastingen, zoals Oracle Orion, Sysbench, SLOB en Fio.

Voer de belastingstest opnieuw uit nadat u een Oracle-database hebt geïmplementeerd. Start uw normale en piekworkloads en de resultaten tonen u de basislijn van uw omgeving. Wees realistisch in de workloadtest. Het is niet zinvol om een workload uit te voeren die niet lijkt op wat u in werkelijkheid op de virtuele machine uitvoert.

Omdat Oracle een I/O-intensieve database kan zijn, is het belangrijk om de opslag te vergroten op basis van de IOPS-snelheid in plaats van de opslaggrootte. Als de vereiste IOPS-waarde bijvoorbeeld 5.000 is, maar u slechts 200 GB nodig hebt, krijgt u mogelijk nog steeds de P30-klasse Premium-schijf, zelfs als deze wordt geleverd met meer dan 200 GB opslagruimte.

U kunt het IOPS-tarief ophalen uit het AWR-rapport. Het opnieuw logboek, de fysieke lees- en schrijfsnelheid bepalen de IOPS-snelheid. Controleer altijd of de VM-serie die u kiest, de mogelijkheid heeft om de I/O-vraag van de workload af te handelen. Als de VM een lagere I/O-limiet heeft dan de opslag, stelt de VIRTUELE machine de limiet in.

Schermopname van de AWR-rapportpagina.

De nieuwe grootte is bijvoorbeeld 12.200.000 bytes per seconde, wat gelijk is aan 11,63 MBP's. De IOPS-waarde is 12.200.000 / 2.358 = 5.174.

Nadat u een duidelijk beeld hebt van de I/O-vereisten, kunt u een combinatie van stations kiezen die het meest geschikt zijn om aan deze vereisten te voldoen.

Aanbevelingen voor schijftypen

Voor gegevenstabelruimte spreidt u de I/O-workload over verschillende schijven met behulp van beheerde opslag of Oracle Automatic Storage Management (ASM).
Gebruik Geavanceerde compressie van Oracle om I/O te verminderen voor zowel gegevens als indexen.
Afzonderlijke heropmaaklogboeken, tijdelijke en ongedaan maken van tabelruimten op afzonderlijke gegevensschijven.
Plaats geen toepassingsbestanden op standaardbesturingssysteemschijven. Deze schijven zijn niet geoptimaliseerd voor snelle VM-opstarttijden en bieden mogelijk geen goede prestaties voor uw toepassing.
Wanneer u VM's uit de M-serie in Premium Storage gebruikt, schakelt u schrijfversneller in op de schijf met opnieuw logboeken.
Overweeg opnieuw logboeken met hoge latentie naar de ultraschijf te verplaatsen.

Instellingen voor schijfcache

Hoewel u drie opties hebt voor hostcaching, wordt alleen-lezencache aanbevolen voor een databaseworkload in een Oracle-database. Lezen/schrijven kan aanzienlijke beveiligingsproblemen met een gegevensbestand veroorzaken, omdat het doel van een database-schrijfbewerking is om deze op te nemen in het gegevensbestand, niet om de informatie in de cache op te slaan. Met alleen-lezen worden alle aanvragen in de cache opgeslagen voor toekomstige leesbewerkingen. Alle schrijfbewerkingen worden nog steeds naar de schijf geschreven.

Aanbevelingen voor schijfcache

Als u de doorvoer wilt maximaliseren, begint u indien mogelijk met het kenmerk Alleen-lezen voor hostcaching. Houd er voor Premium Storage rekening mee dat u de obstakels moet uitschakelen wanneer u het bestandssysteem koppelt met de opties voor alleen-lezen. Werk het bestand /etc/fstab bij met de universeel unieke id voor de schijven.

Voor besturingssysteemschijven gebruikt u Premium SSD met cacheopslag van lees-/schrijfhosts.
Voor gegevensschijven die het volgende bevatten, gebruikt u Premium SSD met alleen-lezen hostcaching: Oracle-gegevensbestanden, tijdelijke bestanden, besturingsbestanden, blok bestanden voor wijzigingen bijhouden, BFILEs, bestanden voor externe tabellen en flashbacklogboeken.
Gebruik premium SSD of UltraDisk zonder hostcaching voor gegevensschijven die Oracle online bevatten, de optie Geen . Oracle redo log files that are archived and Oracle Recovery Manager backup sets, can also reside with the online redo log files. Hostcaching is beperkt tot 4095 GiB, dus wijs geen premium SSD toe die groter is dan P50 met hostcaching. Als u meer dan 4 TiB aan opslag nodig hebt, stript u verschillende premium SSD's met RAID-0. Gebruik Linux LVM2 of Oracle Automatic Storage Management.

Als workloads sterk variëren tussen de dag en avond en de I/O-workload deze kan ondersteunen, kan P1-P20 Premium SSD met bursting de prestaties bieden die vereist zijn tijdens nachtbelastingen of beperkte I/O-vereisten.

Beveiliging

Nadat u uw Azure-omgeving hebt ingesteld en geconfigureerd, moet u uw netwerk beveiligen. Hier volgen enkele aanbevelingen:

NSG-beleid: u kunt uw NSG definiëren door een subnet of een netwerkinterfacekaart. Het is eenvoudiger om de toegang op subnetniveau te beheren, zowel voor beveiliging als voor toepassingsfirewalls voor geforceerde routering.
Jumpbox: Beheerders mogen voor veiligere toegang niet rechtstreeks verbinding maken met de toepassingsservice of -database. Gebruik een jumpbox tussen de beheercomputer en Azure-resources.

De beheercomputer mag alleen ip-beperkte toegang bieden tot de jumpbox. De jumpbox moet toegang hebben tot de toepassing en database.
Privénetwerk (subnetten): het is een goed idee om de toepassingsservice en -database op afzonderlijke subnetten te hebben, zodat NSG-beleid betere controle kan instellen.

Delen via