Arkitekturer för Oracle Database Enterprise Edition i Azure

Artikel
10/03/2024

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, storleksanpassa 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 att köras 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 underordnade, 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)
Elasticitet	GTMF	MTTR
Planerat underhåll	Korrigering/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
Skala	Lodrät skala	Horisontell skalning

Krav

Tänk på följande krav innan du påbörjar migreringen:

Fastställa den verkliga CPU-användningen. Oracle-licenser per kärna, vilket innebär att storleksändring av dina vCPU-behov kan vara avgörande 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 uppskatta baserat på Oracle Statspack och AWR-rapporterna. Du kan också uppskatta 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. Sedan finns det fyra potentiella områden som du kan justera för att förbättra prestanda i en Azure-miljö:

Storlek för virtuell dator
Nätverksdataflöde
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 diagnostikpaketet 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 dess 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 med procentandelar. 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;

Nyckelmå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 den awrgrpt.sql filen 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 undersydda
Totalt minne i GB
Cpu-procent upptagen
DB-processorer
IOPS (läsa/skriva)
Mbit/s (läsa/skriva)
Nätverksdataflöde
Nätverkssvarstid (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 vm-storlek baserat på CPU-, minnes- och I/O-användning från AWR-rapporten

Titta på de fem främsta tidsförgrundshändelserna som anger var systemets flaskhalsar finns. I följande diagram är till exempel loggfilsynkroniseringen överst. Det anger antalet väntetider som krävs innan loggskrivaren skriver loggbufferten till loggfilen för att göra om. Dessa resultat indikerar att lagring eller diskar med bättre prestanda krävs. Dessutom visar diagrammet också antalet CPU-kärnor och mängden minne.

Skärmbild som visar loggfilsynkroniseringen ö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 en 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ä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ödet och IOPS:

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

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

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

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

Baserat på dina krav 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 priser för VPN Gateway.

Rekommendationer

Nätverksfördröjningen är högre jämfört med en lokal distribution. Att minska nätverkets tur och retur-resor kan avsevärt förbättra prestandan.
Om du vill minska antalet turer konsoliderar du program som har höga transaktioner eller chattiga 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.
Enorma sidor är inte aktiverade i Linux som standard. Överväg att aktivera stora sidor och ange 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 operativsystemåtkomst vid start och är inte utformade för arbetsbelastningar för transaktions- eller informationslager (analys).
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 läsa in testdiskarna innan du skapar en databas. Om du känner till I/O-hastigheten 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 testning av programbelastning, 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-frekvensen från AWR-rapporten. Omloggen, fysiska läsningar och skrivningar avgör IOPS-frekvensen. Kontrollera alltid att den virtuella datorserie som 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.

Till exempel är omstorleken 12 200 000 byte per sekund, vilket är lika med 11,63 MBPs. 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 datatabellområdet 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.
Separera omloggar, temporära och ångra tabellområden 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 i 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 cachelagrad information. Med skrivskyddad cachelagras alla begäranden för framtida läsningar. Alla skrivningar fortsätter att skrivas till disk.

Rekommendationer för diskcache

För att maximera dataflödet börjar du med skrivskyddad för cachelagring av värd när det är möjligt. För premiumlagring bör du komma ihåg att du måste inaktivera hindren när du monterar filsystemet med skrivskyddade alternativ. Uppdatera /etc/fstab-filen med den universellt unika identifieraren till 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ärdar: Oracle-datafiler, temporära filer, kontrollfiler, spårningsfiler för blockändringar, 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ärd, alternativet Ingen . Oracle gör om loggfiler som är arkiverade och Oracle Recovery Manager-säkerhetskopieringsuppsättningar, kan också finnas med loggfilerna för att göra om online. 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 lagring, stripe flera Premium SSD med RAID-0. Använd Linux LVM2 eller Oracle Automatic Storage Management.

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

Säkerhet

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

NSG-princip: Du kan definiera din NSG med 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: Administratörer bör inte ansluta direkt till programtjänsten eller databasen för säkrare åtkomst. Använd en jumpbox mellan administratörsdatorn och Azure-resurser.

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

Dela via