Arkitekturer för Oracle Database Enterprise Edition i Azure

Artikel
04/14/2023

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

Azure är hemma för alla Oracle-arbetsbelastningar, inklusive arbetsbelastningar som måste fortsätta att köras optimalt i Azure med Oracle. Om du har Oracle Diagnostic Pack eller AWR ( Automatic Workload Repository ) kan du samla in data om dina arbetsbelastningar. Använd dessa data för att utvärdera Oracle-arbetsbelastningen, ändra storleken på resursbehoven och migrera arbetsbelastningen till Azure. De olika mått som tillhandahålls av Oracle i dessa rapporter kan ge en förståelse för programprestanda och plattformsanvändning.

Den här artikeln hjälper dig att förbereda en Oracle-arbetsbelastning för körning i Azure och utforska de bästa arkitekturlösningarna för att ge optimala molnprestanda. De data som tillhandahålls av Oracle i Statspack och ännu mer i dess ättling, AWR, hjälper dig att utveckla tydliga förväntningar. Dessa förväntningar omfattar gränserna för fysisk justering genom arkitektur, fördelarna med logisk justering av databaskod och den övergripande databasdesignen.

Skillnader mellan de två miljöerna

När du migrerar lokala program till Azure bör du tänka på några viktiga skillnader mellan de två miljöerna.

En viktig skillnad är att i en Azure-implementering delas resurser som virtuella datorer, diskar och virtuella nätverk mellan andra klienter. Dessutom kan resurser begränsas baserat på kraven. I stället för att fokusera på att undvika fel fokuserar Azure mer på att överleva felet. Den första metoden försöker öka genomsnittlig tid mellan fel (MTBF) och den andra försöker minska genomsnittlig tid till återställning (MTTR).

I följande tabell visas några av skillnaderna mellan en lokal implementering och en Azure-implementering av en Oracle-databas.

	Lokal implementering	Azure-implementering
Nätverk	LAN/WAN	Programvarudefinierade nätverk (SDN)
Säkerhetsgrupp	Verktyg för begränsning av IP-/portar	Nätverkssäkerhetsgrupp (NSG)
Motståndskraft	MTBF	MTTR
Planerat underhåll	Korrigeringar/uppgraderingar	Tillgänglighetsuppsättningar med korrigeringar/uppgraderingar som hanteras av Azure
Resurs	Dedikerad	Delas med andra klienter
Regioner	Datacenter	Regionpar
Storage	SAN/fysiska diskar	Azure-hanterad lagring
Skalning	Lodrät skala	Horisontell skalning

Krav

Överväg följande krav innan du påbörjar migreringen:

Fastställa den verkliga CPU-användningen. Oracle-licenser i grunden, vilket innebär att storleksändring av dina vCPU-behov kan vara viktigt för att hjälpa dig att minska kostnaderna.
Fastställa databasens storlek, lagring av säkerhetskopior och tillväxttakt.
Fastställ I/O-kraven, som du kan beräkna baserat på Oracle Statspack och AWR-rapporterna. Du kan också beräkna kraven från lagringsövervakningsverktyg som är tillgängliga från operativsystemet.

Konfigurationsalternativ

Det är en bra idé att generera en AWR-rapport och hämta några mått från den som hjälper dig att fatta beslut om konfiguration. Det finns sedan fyra potentiella områden som du kan justera för att förbättra prestanda i en Azure-miljö:

Storlek för virtuell dator
Dataflöde för nätverk
Disktyper och konfigurationer
Inställningar för diskcache

Generera en AWR-rapport

Om du har en befintlig Oracle-Enterprise Edition-databas och planerar att migrera till Azure har du flera alternativ. Om du har diagnostikpaketet för dina Oracle-instanser kan du köra Oracle AWR-rapporten för att hämta måtten, till exempel IOPS, Mbit/s och GiBs. För dessa databaser utan licensen för diagnostikpaket eller för en Oracle Standard Edition-databas kan du samla in samma viktiga mått med en Statspack-rapport när du har samlat in manuella ögonblicksbilder. De största skillnaderna mellan dessa två rapporteringsmetoder är att AWR samlas in automatiskt och att det ger mer information om databasen än statspack.

Överväg att köra AWR-rapporten under både vanliga och högsta arbetsbelastningar, så att du kan jämföra. Om du vill samla in den mer exakta arbetsbelastningen bör du överväga en utökad fönsterrapport på en vecka, till skillnad från en dag. AWR tillhandahåller medelvärden som en del av sina beräkningar i rapporten. Som standard behåller AWR-lagringsplatsen åtta dagars data och tar ögonblicksbilder med timintervall.

För en datacentermigrering bör du samla in rapporter för storleksändring på produktionssystemen. Beräkna återstående databaskopior som används för användartestning, testning och utveckling i procent. Uppskatta till exempel 50 procent av produktionsstorleken.

Om du vill köra en AWR-rapport från kommandoraden använder du följande kommando:

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

Viktiga mått

I rapporten uppmanas du att ange följande information:

Rapporttyp: HTML eller TEXT. HTML-typen innehåller mer information.
Antalet dagar med ögonblicksbilder som ska visas. För entimmesintervall genererar till exempel en enveckasrapport 168 ögonblicksbilds-ID:t.
Början SnapshotID för rapportfönstret.
Slutet SnapshotID för rapportfönstret.
Namnet på rapporten som AWR-skriptet skapar.

Om du kör AWR-rapporten på ett verkligt programkluster (RAC) är kommandoradsrapporten filen awrgrpt.sql i stället för awrrpt.sql. Rapporten g skapar en rapport för alla noder i RAC-databasen i en enda rapport. Den här rapporten eliminerar behovet av att köra en rapport på varje RAC-nod.

Du kan hämta följande mått från AWR-rapporten:

Databasnamn, instansnamn och värdnamn
Databasversion för support av Oracle
CPU/kärnor
SGA/PGA och rådgivare som meddelar dig om de är underdimensionerade
Totalt minne i GB
Cpu-procent upptagen
DB-processorer
IOPS (läsa/skriva)
Mbit/s (läsa/skriva)
Dataflöde för nätverk
Svarstid för nätverk (låg/hög)
De vanligaste väntehändelserna
Parameterinställningar för databasen
Oavsett om databasen är RAC, Exadata eller använder avancerade funktioner eller konfigurationer

Storlek för virtuell dator

Här följer några steg som du kan vidta för att konfigurera storleken på den virtuella datorn för optimala prestanda.

Beräkna storleken på den virtuella datorn baserat på cpu-, minnes- och I/O-användning från AWR-rapporten

Titta på de fem mest tidsindelade förgrundshändelserna som anger var systemets flaskhalsar finns. I följande diagram är till exempel loggfilssynkroniseringen överst. Den anger hur många väntetider som krävs innan loggskrivaren skriver loggbufferten till omloggfilen. Dessa resultat indikerar att det krävs bättre lagring eller diskar. Diagrammet visar också antalet CPU-kärnor och mängden minne.

Skärmbild som visar loggfilssynkroniseringen överst i tabellen.

Följande diagram visar det totala I/O för läsning och skrivning. Det skrevs 59 GB läsning och 247,3 GB under rapportens tid.

Välj en virtuell dator

Baserat på den information som du har samlat in från AWR-rapporten är nästa steg att välja en virtuell dator med liknande storlek som uppfyller dina krav. Mer information om tillgängliga virtuella datorer finns i Storlekar på minnesoptimerade virtuella datorer.

Finjustera storleken på den virtuella datorn med en liknande VM-serie baserat på ACU:n

När du har valt den virtuella datorn bör du vara uppmärksam på Azure-beräkningsenheten (ACU) för den virtuella datorn. Du kan välja en annan virtuell dator baserat på det ACU-värde som passar dina behov bättre. Mer information finns i Azure-beräkningsenhet.

Skärmbild av sidan ACU-enheter.

Nätverksdataflöde

Följande diagram visar relationen mellan dataflöde och IOPS:

Diagram som visar relationen mellan dataflöde och IOPS, vilket är IOPS gånger I/O-storleken är lika med dataflödet.

Det totala nätverkets dataflöde beräknas baserat på följande information:

SQL*Net-trafik
Mbit/s gånger antalet servrar (utgående dataström, till exempel Oracle Data Guard)
Andra faktorer, till exempel programreplikering

Skärmbild av SQL*Net-dataflödet.

Baserat på kraven på nätverksbandbredd finns det olika gatewaytyper som du kan välja mellan. Dessa typer omfattar basic, VpnGw och Azure ExpressRoute. Mer information finns i VPN Gateway prissättning.

Rekommendationer

Nätverksfördröjningen är högre jämfört med en lokal distribution. Att minska nätverkets tur- och returresor kan avsevärt förbättra prestandan.
Om du vill minska antalet turer konsoliderar du program som har höga transaktioner eller trafikintensiva appar på samma virtuella dator.
Använd virtuella datorer med accelererat nätverk för bättre nätverksprestanda.
För vissa Linux-distributioner bör du överväga att aktivera TRIM/UNMAP-stöd.
Installera Oracle Enterprise Manager på en separat virtuell dator.
Stora sidor är inte aktiverade i Linux som standard. Överväg att aktivera stora sidor och konfigurera use_large_pages = ONLY på Oracle DB. Den här metoden kan hjälpa till att öka prestandan. Mer information finns i USE_LARGE_PAGES.

Disktyper och konfigurationer

Här följer några tips när du överväger diskar.

Standard-OS-diskar: Dessa disktyper erbjuder beständiga data och cachelagring. De är optimerade för åtkomst till operativsystemet vid start och är inte utformade för vare sig transaktions- eller informationslagerarbetsbelastningar (analytiska).
Hanterade diskar: Azure hanterar de lagringskonton som du använder för dina virtuella datordiskar. Du anger disktypen och storleken på den disk som du behöver. Typen är oftast Premium (SSD) för Oracle-arbetsbelastningar. Azure skapar och hanterar disken åt dig. En Premium SSD-hanterad disk är endast tillgänglig för minnesoptimerade och utformade VM-serier. När du har valt en viss VM-storlek visar menyn endast tillgängliga SKU:er för Premium Storage som baseras på den virtuella datorns storlek.

När du har konfigurerat lagringen på en virtuell dator kanske du vill belastningstesta diskarna innan du skapar en databas. Genom att känna till I/O-frekvensen både när det gäller svarstid och dataflöde kan du avgöra om de virtuella datorerna stöder det förväntade dataflödet med svarstidsmål. Det finns flera verktyg för belastningstestning av program, till exempel Oracle Orion, Sysbench, SLOB och Fio.

Kör belastningstestet igen när du har distribuerat en Oracle-databas. Starta dina vanliga och högsta arbetsbelastningar och resultatet visar baslinjen för din miljö. Var realistisk i arbetsbelastningstestet. Det är inte meningsfullt att köra en arbetsbelastning som inte liknar det du kör på den virtuella datorn i verkligheten.

Eftersom Oracle kan vara en I/O-intensiv databas är det viktigt att storleken på lagringen baseras på IOPS-hastigheten i stället för lagringsstorleken. Om det obligatoriska IOPS-värdet till exempel är 5 000, men du bara behöver 200 GB, kan du fortfarande få P30-klass premiumdisken även om den levereras med mer än 200 GB lagringsutrymme.

Du kan hämta IOPS-priset från AWR-rapporten. Frekvensen för att göra om loggen, fysiska läsningar och skrivningar avgör IOPS-hastigheten. Kontrollera alltid att den VM-serie du väljer har möjlighet att hantera I/O-efterfrågan för arbetsbelastningen. Om den virtuella datorn har en lägre I/O-gräns än lagringen anger den virtuella datorn maxgränsen.

Skärmbild av AWR-rapportsidan.

Om du till exempel gör om är storleken 12 200 000 byte per sekund, vilket är lika med 11,63 Mbit/s. IOPS-värdet är 12 200 000 /2 358 = 5 174.

När du har en tydlig bild av I/O-kraven kan du välja en kombination av enheter som passar bäst för att uppfylla dessa krav.

Rekommendationer för disktyp

För datatabellutrymme sprider du I/O-arbetsbelastningen över flera diskar med hjälp av hanterad lagring eller Oracle Automatic Storage Management (ASM).
Använd Oracles avancerade komprimering för att minska I/O för både data och index.
Separata gör om loggar, temporära och ångra tablespaces på separata datadiskar.
Placera inga programfiler på standardoperativsystemdiskar. Dessa diskar är inte optimerade för snabba starttider för virtuella datorer och de kanske inte ger bra prestanda för ditt program.
När du använder virtuella datorer i M-serien på Premium Storage aktiverar du skrivaccelerator på omloggdisken.
Överväg att flytta omloggar med hög svarstid till ultradisken.

Inställningar för diskcache

Även om du har tre alternativ för cachelagring av värdar rekommenderas endast skrivskyddad cachelagring för en databasarbetsbelastning på en Oracle-databas. Läsning/skrivning kan medföra betydande sårbarheter för en datafil, eftersom målet med en databasskrivning är att registrera den i datafilen, inte att cachelagrat informationen. Med skrivskyddad cachelagras alla begäranden för framtida läsningar. Alla skrivningar fortsätter att skrivas till disken.

Rekommendationer för diskcache

För att maximera dataflödet börjar du med skrivskyddad för cachelagring av värden när det är möjligt. När det gäller Premium Storage måste du inaktivera barriärerna när du monterar filsystemet med skrivskyddade alternativ. Uppdatera / etc/fstab-filen med den universellt unika identifieraren för diskarna.

För operativsystemdiskar använder du Premium SSD med cachelagring av skrivskyddade värdar.
För datadiskar som innehåller följande använder du Premium SSD med skrivskyddad cachelagring av värden: Oracle-datafiler, temporära filer, kontrollfiler, blockändringsspårningsfiler, BFILEs, filer för externa tabeller och flashback-loggar.
För datadiskar som innehåller Oracle online gör om loggfiler använder du Premium SSD eller UltraDisk utan cachelagring av värden, alternativet Ingen . Oracle gör om loggfiler som arkiveras och Oracle Recovery Manager säkerhetskopieringsuppsättningar, kan också finnas med loggfilerna för online-redo. Cachelagring av värd är begränsad till 4 095 GiB, så allokera inte en Premium SSD som är större än P50 med cachelagring av värden. Om du behöver mer än 4 TiB lagringsutrymme kan du strimla flera premium-SSD:er med RAID-0. Använd Linux LVM2 eller Oracle Automatic Storage Management.

Om arbetsbelastningarna varierar kraftigt mellan dagen och kvällen och I/O-arbetsbelastningen kan stödja det, kan P1-P20 Premium SSD med bursting ge den prestanda som krävs vid batchbelastningar nattetid eller begränsade I/O-krav.

Säkerhet

När du har konfigurerat din Azure-miljö måste du skydda nätverket. Här följer några rekommendationer:

NSG-princip: Du kan definiera din NSG via ett undernät eller ett nätverkskort. Det är enklare att styra åtkomsten på undernätsnivå, både för säkerhet och för tvingad routning av programbrandväggar.
Jumpbox: För säkrare åtkomst bör administratörer inte ansluta direkt till programtjänsten eller databasen. Använd en jumpbox mellan administratörsdatorn och Azure-resurser.

Administratörsdatorn bör endast erbjuda IP-begränsad åtkomst till jumpboxen. Jumpbox-miljön bör ha åtkomst till programmet och databasen.
Privat nätverk (undernät): Det är en bra idé att ha programtjänsten och databasen i separata undernät, så att NSG-principen kan ge bättre kontroll.