Een Oracle-database ontwerpen en implementeren in Azure

Van toepassing op: ✔️ Linux-VM's

Aannames

• U bent van plan om een Oracle-database te migreren van on-premises naar Azure.
• U hebt het diagnosepakket of de opslagplaats voor automatische workloads voor de Oracle Database die u wilt migreren
• U hebt inzicht in de verschillende metrische gegevens in Oracle.
• U hebt basiskennis van toepassingsprestaties en platformgebruik.

Doelstellingen

• Meer inzicht in het optimaliseren van uw Oracle-implementatie in Azure.
• Bekijk de opties voor het afstemmen van prestaties voor een Oracle-database in een Azure-omgeving.
• U hebt duidelijke verwachtingen tussen de limieten van fysieke afstemming via architectuur en voordelen of logische afstemming van databasecode (SQL) en het algehele databaseontwerp.

De verschillen tussen een on-premises implementatie en Een Azure-implementatie

Hier volgen enkele belangrijke zaken waar u rekening mee moet houden wanneer u on-premises toepassingen migreert naar Azure.

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 voorkomen van fouten (MTBF), is Azure meer gericht op het overleven van de fout (MTTR).

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

Vereisten

• Het bepalen van het werkelijke CPU-gebruik, omdat Oracle wordt gelicentieerd door de kern, kan het bepalen van de vCPU-behoeften een essentiële oefening zijn om kosten te besparen.
• Bepaal de databasegrootte, back-upopslag en groeisnelheid.
• Bepaal de I/O-vereisten, die u kunt schatten op basis van Oracle Statspack- en AWR-rapporten of van opslagbewakingshulpprogramma's op besturingssysteemniveau.

Configuratie-opties

Er zijn 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 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 (IOPS, Mbps, GiBs, etc.). Voor databases zonder de licentie Voor diagnosepakket of voor een Standard Edition-database kunnen dezelfde belangrijke metrische gegevens worden verzameld met een Statspack-rapport nadat handmatige momentopnamen zijn verzameld. Het belangrijkste verschil tussen deze twee rapportagemethoden is dat AWR automatisch wordt verzameld en meer informatie over de database biedt dan de vorige rapportageoptie van Statspack.

U kunt uw AWR-rapport uitvoeren tijdens zowel normale als piekworkloads, zodat u deze kunt vergelijken. Als u de nauwkeurigere workload wilt verzamelen, kunt u een uitgebreid vensterrapport van één week in plaats van een 24-uurs run gebruiken en u realiseren dat AWR gemiddelden biedt als onderdeel van de berekeningen in het rapport. Voor een datacentermigratie raden we u aan om rapporten te verzamelen voor het bepalen van de omvang op de productiesystemen en om de resterende databasekopien te schatten die worden gebruikt voor het testen, testen, ontwikkelen, enzovoort door percentages (UAT gelijk aan productie, test en ontwikkeling, 50% van de productie-omvang, enzovoort)

De AWR-opslagplaats bewaart standaard 8 dagen aan gegevens en maakt momentopnamen op intervallen van elk uur. Als u een AWR-rapport wilt uitvoeren vanaf de opdrachtregel, kunt u het volgende uitvoeren vanuit een terminal:

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

Belangrijke metrische gegevens

In het rapport wordt om de volgende informatie gevraagd:

• Rapporttype: HTML of TEXT (HTML in 12.1 en biedt aanvullende informatie dan de tekstindeling.)
• Het aantal dagen aan momentopnamen dat moet worden weergegeven (voor intervallen van één uur is een rapport van één week 168 verschillende momentopname-ID's)
• De begin-SnapshotID voor het rapportvenster.
• De eindmomentopname-id voor het rapportvenster.
• De naam van het rapport dat door het AWR-script moet worden gemaakt.

Als u de AWR op een echt toepassingscluster (RAC) wilt uitvoeren, is het opdrachtregelrapport awrgrpt.sql in plaats van awrrpt.sql. Het rapport 'g' maakt een rapport voor alle knooppunten in de RAC-database in één rapport versus dat er een moet worden uitgevoerd op elk RAC-knooppunt.

Hieronder vindt u de metrische gegevens die u kunt verkrijgen uit het AWR-rapport:

• Databasenaam, exemplaarnaam en hostnaam
• Databaseversie (ondersteuning door Oracle)
• CPU/kernen
• SGA/PGA (en adviseurs om u te laten weten als u te maken hebt met te veel)
• Totaal geheugen in GB
• CPU-%bezet
• DB-CPU's
• IOPS (lezen/schrijven)
• MBP's (lezen/schrijven)
• Netwerkdoorvoer
• Netwerklatentie (laag/hoog)
• Belangrijkste wachtgebeurtenissen
• Parameterinstellingen voor Database
• Is database-RAC, Exadata, met behulp van geavanceerde functies of configuraties

Grootte van de virtuele machine

1. De VM-grootte schatten op basis van CPU, geheugen en I/O-gebruik uit het AWR-rapport

Een van de dingen die u kunt bekijken, zijn de belangrijkste vijf gebeurtenissen op de voorgrond die aangeven waar de systeemknelpunten zich bevindt.

In het volgende diagram staat bijvoorbeeld de synchronisatie van het logboekbestand bovenaan. Het geeft het aantal wachttijden aan dat is vereist voordat de LGWR de logboekbuffer naar het redo-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.

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

2. Een VM kiezen

Op basis van de informatie die u hebt verzameld in het AWR-rapport, bestaat de volgende stap uit het kiezen van een VM met een vergelijkbare grootte die voldoet aan uw vereisten. U vindt een lijst met beschikbare VM's in het artikel Geoptimaliseerd voor geheugen.

3. De VM-grootten afstemmen met een vergelijkbare VM-serie op basis van de ACU

Nadat u de VM hebt gekozen, let dan op de ACU voor de VM. U kunt een andere VM kiezen op basis van de ACU-waarde die beter aansluit bij uw vereisten. Zie Azure Compute Unit voor meer informatie.

Netwerkdoorvoer

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

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

• SQL*Netverkeer
• MBps x aantal servers (uitgaande stroom zoals Oracle Data Guard)
• Andere factoren, zoals toepassingsreplicatie

Op basis van de vereisten voor uw netwerkbandbreedte kunt u kiezen uit verschillende gatewaytypen. Dit zijn onder andere Basic, VpnGw en Azure ExpressRoute. Zie de pagina met prijzen voor VPN Gateway voor meer informatie.

Aanbevelingen

• Netwerklatentie is hoger in vergelijking met een on-premises implementatie. Het verminderen van netwerkritten kan de prestaties sterk verbeteren.
• Als u retouren wilt verminderen, voegt u toepassingen met hoge transacties of 'chatty' apps op dezelfde virtuele machine samen.
• Gebruik Virtual Machines 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 standaard niet ingeschakeld in Linux. Overweeg het inschakelen van enorme pagina's en use_large_pages = ONLY stel deze in op Oracle DB. Dit kan helpen de prestaties te verbeteren. Zie voor meer informatie USE_LARGE_PAGES.

Schijftypen en configuraties

• Standaardbesturingssysteemschijven: 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 datawarehouse(analytische) workloads.

• Beheerde schijven: Azure beheert de opslagaccounts die u voor uw VM-schijven gebruikt. U geeft het schijftype op (meestal premium SSD voor Oracle-workloads) en de grootte van de schijf die u nodig hebt. Azure maakt en beheert de schijf voor u. Premium Beheerde SSD-schijf is alleen beschikbaar voor voor geheugen geoptimaliseerde en speciaal ontworpen VM-serie. 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 uw opslag op een VM hebt geconfigureerd, kunt u de schijven testen 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 ondersteuning bieden voor de verwachte doorvoer met latentiedoelen.

Er zijn een aantal hulpprogramma's voor het testen van de belasting van toepassingen, 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 laten de basislijn van uw omgeving zien. Wees realistisch in de workloadtest. Het is niet logisch om een workload uit te voeren die in werkelijkheid niet lijkt op wat u op de VM gaat uitvoeren.

Omdat Oracle voor veel I/O-intensieve databases is, is het heel belangrijk om de grootte van de opslag te verhogen op basis van de IOPS-snelheid in plaats van de opslaggrootte. Als de vereiste IOPS bijvoorbeeld 5000 is, maar u slechts 200 GB nodig hebt, krijgt u mogelijk nog steeds de Premium-schijf van de P30-klasse, ook al wordt deze geleverd met meer dan 200 GB aan opslagruimte.

De IOPS-snelheid kan worden verkregen via het AWR-rapport. Dit wordt bepaald door het redo-logboek, de fysieke lees- en schrijfsnelheid. Controleer altijd of de gekozen VM-reeks ook de IO-vraag van de workload kan verwerken. Als de VM een lagere I/O-limiet heeft dan de opslag, wordt de limiet ingesteld door de VM.

De redo-grootte is bijvoorbeeld 12.200.000 bytes per seconde, wat gelijk is aan 11,63 MBPs. De IOPS is 12.200.000 / 2.358 = 5.174.

Wanneer 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 gegevenstabelruimte verspreidt u de I/O-workload over een aantal schijven met behulp van beheerde opslag of Oracle ASM.
• Geavanceerde Compressie van Oracle gebruiken om I/O (voor zowel gegevens als indexen) te verminderen.
• Afzonderlijke redo-logboeken, tijdelijke en ongedaan maken tablespaces op afzonderlijke gegevensschijven.
• Plaats geen toepassingsbestanden op standaardbesturingssysteemschijven (/dev/sda). Deze schijven zijn niet geoptimaliseerd voor snelle opstarttijden van VM's en bieden mogelijk geen goede prestaties voor uw toepassing.
• Wanneer u VM's uit de M-serie gebruikt Premium opslag, moet Write Accelerator op de schijf met redo-logboeken inschakelen.
• Overweeg redo-logboeken met hoge latentie naar ultraschijven te verplaatsen.

Instellingen voor schijfcache

Er zijn drie opties voor host-caching, maar voor een Oracle-database wordt alleen lezenOnly caching aanbevolen voor een databaseworkload. ReadWrite kan aanzienlijke beveiligingsproblemen in een gegevensbestand introduceren, waarbij het doel van het schrijven van een database is om deze vast te registreren in het gegevensbestand, niet om de gegevens in de cache op te slaan.

In tegenstelling tot een bestandssysteem of toepassing is voor een database readOnly de aanbeveling voor hostcache: alle aanvragen worden in de cache opgeslagen voor toekomstige leesaanvragen. Alle schrijf schrijf schrijf schrijf schrijf naar schijf worden geschreven.

Aanbevelingen

Om de doorvoer te maximaliseren, raden we u aan om waar mogelijk te beginnen met ReadOnly voor host-caching. Houd Premium Storage rekening met het feit dat u de 'barrières' moet uitschakelen wanneer u het bestandssysteem aan de ReadOnly-opties kunt toevoegen. Werk het /etc/fstab bestand bij met de UUID naar de schijven.

• Voor besturingssysteemschijven gebruikt u Premium SSD met host-caching voor lezen/schrijven.
• Voor gegevensschijven die Oracle-gegevensbestanden, tempfiles, besturingsbestanden, bestanden voor het bijhouden van blokkeringen, BFIL's, bestanden voor externe tabellen en flashback-logboeken bevatten, gebruikt u Premium SSD met ReadOnly host caching.
• Voor gegevensschijven met Oracle Online Redo-logboekbestanden gebruikt u Premium SSD of UltraDisk zonder host-caching (geen). Gearchiveerde Redo-logboekbestanden en RMAN-back-ups kunnen zich ook in de online redo-logboekbestanden bevinden. Houd er rekening mee dat host caching beperkt is tot 4095 GiB, dus wijs geen Premium SSD toe die groter is dan P50 met host-caching. Als u meer dan 4 TiB aan opslag nodig hebt, stript RAID-0 een aantal Premium SSD's met Linux LVM2 of oracle ASM.

Als de werkbelastingen per dag en 's avonds sterk variëren en de I/O-workload dit kan ondersteunen, kan P1-P20 Premium SSD met bursting de prestaties bieden die vereist zijn tijdens batchbelastingen 's nachts of beperkte I/O-eisen.

Beveiliging

Nadat u uw Azure-omgeving hebt ingesteld en geconfigureerd, bestaat de volgende stap uit het beveiligen van uw netwerk. Hier volgen enkele aanbevelingen:

• NSG-beleid: NSG kan worden gedefinieerd door een subnet of NIC. Het is eenvoudiger om toegang op subnetniveau te beheren, zowel voor beveiliging als geforceer routering voor zaken zoals toepassingsfirewalls.

• Jumpbox: voor veiligere toegang moeten beheerders niet rechtstreeks verbinding maken met de toepassingsservice of database. Een jumpbox wordt gebruikt als media tussen de beheerdersmachine en Azure-resources.

  De beheerdersmachine mag alleen IP-beperkte toegang tot de jumpbox bieden. De jumpbox moet toegang hebben tot de toepassing en database.

• Privénetwerk (subnetten): u wordt aangeraden de toepassingsservice en database op afzonderlijke subnetten te hebben, zodat u beter beheer kunt instellen door het NSG-beleid.

Meer artikelen

• Oracle ASM configureren
• Oracle Data Guard configureren
• Oracle Golden Gate configureren
• Oracle-back-up en -herstel

Volgende stappen

• Zelfstudie: Virtuele VM's met hoge beschikbaarheid maken
• Azure CLI-voorbeelden voor VM-implementatie verkennen