Dela via

Kapacitetsplanering för migrering av Oracle-arbetsbelastningar till Azure

  • Artikel

Den här artikeln bygger på Vägledning för Azure Cloud Adoption Framework och innehåller överväganden om infrastrukturkapacitetsplanering för Oracle-arbetsbelastningar i Microsoft Azure. Artikeln innehåller rekommendationer och verktyg som hjälper dig med den här planeringsprocessen.

Kapacitetsplanering är viktigt för effektiv prestanda- och kostnadshantering när du kör Oracle-databasarbetsbelastningar i Azure. Den här artikeln beskriver riktlinjer, metoder och verktyg för att korrekt allokera resurser, balansera prestandabehov och optimera kostnader. De specifika kapacitetskraven beror på databasarbetsbelastningens prestandaegenskaper. Dessa egenskaper är transaktionella, analytiska eller blandade. De begränsande faktorerna för Oracle-databasarbetsbelastningar bearbetar vanligtvis energi, minne och dataflöde.

Kapacitetsplanering hjälper dig att välja lämplig infrastruktur för Oracle-arkitektur i Azure. Du måste förstå databaslagringskapaciteten för att effektivt implementera den här processen.

Överväganden vid kapacitetsplanering

Kapacitetsplanering för Oracle-arbetsbelastningar i Azures infrastruktur som en tjänst (IaaS) är en process som kräver en djup förståelse för arbetsbelastningskraven och tillgängliga Azure-resurser.

Kommentar

Följande överväganden gäller Oracle-databaser som körs på virtuella Azure-datorer. För Oracle Database@Azure kan du kontakta ditt lokala Oracle-säljteam för att få vägledning om storleksändring.

Övergripande prestandaöverväganden

  • Din befintliga miljö kanske inte fungerar som ett korrekt storleksmått för arbetsbelastningskrav för Oracle-databaser i Azure. Använd AWR-rapporter (Oracle Automatic Workload Repository) för att förstå prestandaegenskaperna för arbetsbelastningen eller arbetsbelastningarna för migrering. AWR-rapporter innehåller prestandastatistik för dina Oracle-databasarbetsbelastningar.

  • Du kan använda din befintliga miljö som ett storleksmått för programservrar när det inte finns någon tillgänglig AWR-prestandastatistik. Du bör samla in prestandamått från programservrar för att säkerställa att programservrarna och alla PaaS-lösningar (plattform som en tjänst) har rätt storlek.

    Kommentar

    Om du vill samla in AWR-rapporter måste du köpa Oracle Diagnostic Pack-licensen för din databasarbetsbelastning. Du kan använda Statspack-rapporter som ett alternativ till AWR-rapporter. Statspack-rapporter är en delmängd av AWR-rapporter och kräver inte diagnostikpaketlicensen.

  • Samla in AWR-rapporter för din databasarbetsbelastning:

    • När belastningen är som störst för arbetsbelastningen. Om du inte känner till den högsta belastningstiden använder du skriptet busiest_awr för att fastställa den mest trafikerade AWR-filen.

    • Under en period som är representativ för hög belastning. Generera till exempel AWR-rapporten under månadsslutsprocessen om den högsta belastningen är en månadsslutsprocess. Tidsperioden bör endast innehålla tider för högsta belastning och exkludera längre perioder med låg belastning. Om du inkluderar perioder med låg belastning i AWR-rapporten representerar prestandastatistiken ett genomsnitt och inte de faktiska prestandakraven för arbetsbelastningen.

    • För aktiviteter som batchprocesser eller andra aktiviteter som utgör betydande belastning på databasen.

  • Samla in AWR-rapporter vid hög belastning och liknande scenarier. Information om hur du fastställer lämplig SKU för virtuella datorer (VM) och lagringskonfiguration finns i Storleksanpassa Azure-resurser baserat på en Oracle AWR-rapport. Om du hanterar flera Oracle-databasarbetsbelastningar och överväger att konsolidera flera arbetsbelastningar på samma virtuella datorer använder du Oracle Migration Assistant Tool (OMAT). OMAT är ett automatiserat verktyg för storleksbedömning som genererar en infrastrukturutvärdering baserat på AWR-rapporter och ger förslag på möjliga konfigurationer för virtuella datorer och lagring.

Beräkningsöverväganden

När du har fastställt de grundläggande prestandakraven för databasarbetsbelastningen bör du överväga följande rekommendationer för VM-planering:

  • Använd begränsade kärnor om det är tillämpligt. Begränsade kärnor ger minne och dataflödeskapacitet för en större VM SKU med vCPU-kapacitet för en mindre VM SKU. Begränsade kärnor är att föredra ur ett Oracle-licensieringskostnadsperspektiv eftersom Oracle-licensiering baseras på processorkärnorna. Mer information om hur Oracle-licensiering fungerar i Azure finns i Licensiering av Oracle-programvara i molnbaserad databehandlingsmiljö. Mer information om begränsade kärnor finns i Storlekar på virtuella Azure-datorer.

  • Använd minnesoptimerade virtuella datorer för Oracle-arbetsbelastningar. Minnesoptimerade virtuella datorer har ett högre förhållande mellan minne och vCPU än virtuella datorer för generell användning. Dessa virtuella datorer föredras för Oracle-arbetsbelastningar, som vanligtvis är minnesintensiva. Mer information om minnesoptimerade virtuella datorer finns i Minnesoptimerade VM-storlekar.

  • När du utvärderar din övergripande arkitektur ska du inkludera andra virtuella datorer som krävs för hög tillgänglighet, icke-produktionsmiljöer med mera.

Överväganden för lagring

Prestanda och tillförlitlighet för Oracle-databasarbetsbelastningar är starkt beroende av utformningen och konfigurationen av den underliggande lagringsinfrastrukturen. Överväg följande vägledning för lagringsplanering:

  • Om du använder hanterade diskar måste du använda Azure Premium SSD, Azure Premium SSD v2 eller Azure Ultra Disk Storage för Oracle-arbetsbelastningar. Vi rekommenderar inte Azure Standard SSD eller Azure Standard HDD för Oracle-produktionsarbetsbelastningar. Mer information om begränsningar för Premium v2 SSD och Ultra Disk Storage finns i Azure-hanterade diskar.

  • Diskfördröjning kan vara ett problem beroende på arbetsbelastningens egenskaper. Mer information om diskfördröjning finns i Azure-hanterade disktyper.

  • Om du använder Premium SSD konfigurerar du cachelagring av värd till ReadOnly för alla datadiskar och till ReadWrite för OSDisk-klassen. Värddiskcachelagring stöds inte för diskar som är större än 4 095 GB. Om du vill skapa volymer som är större än en P50-parameter, eller 4 TB, allokerar du flera Premium SSD-diskar för att skapa stripade logiska RAID-0-volymer. Använd en volymhanterare som Linux Logical Volume Manger version 2 (LVM2) eller allokera flera Premium SSD-diskar för att skapa Oracle-diskgrupper för automatisk lagringshantering (ASM) för att uppfylla önskad kapacitet eller nödvändigt dataflöde.

  • När du använder hanterade diskar avgör det kumulativa dataflödet för alla diskar som är anslutna till den virtuella datorn och som begränsas av vm-SKU:n diskens dataflöde. Mer information finns i Virtuella datorer och diskprestanda.

  • När du använder hanterade diskar med en skrivintensiv arbetsbelastning bör du överväga att använda Ultra Disk Storage för att göra om loggar.

  • Om dataflödeskraven överskrider det maximala dataflödet för en enskild virtuell dator bör du överväga att använda nätverkslagring, till exempel Azure NetApp Files , eftersom den virtuella datorn är begränsad till nätverkets dataflöde eller utgående dataflöde i stället för diskdataflöde för en sådan konfiguration.

  • Om du använder temporära Oracle-filer ofta kan du välja en VM-SKU med en tillfällig disk och placera de temporära filerna på den tillfälliga disken. Den här konfigurationen minskar in- och utdatabelastningen (I/O) på datadiskarna.

Nästa steg