Beräknings-, nätverks- och lagringsöverväganden för VIRTUELLA Azure-datorer för SAP-arbetsbelastningar

Slutförd

SAP Application Performance Standard-måttet (SAPS) utgör ett av de viktigaste kriterierna för att avgöra om en VM-storlek erbjuder ett dataflödeskrav som krävs för en viss SAP-arbetsbelastning. I praktiken representerar det också en av de viktigaste faktorerna som Microsoft och SAP överväger när de certifierar virtuella Azure-datorer för SAP NetWeaver och SAP HANA.

Anteckning

Observera att listan inte innehåller alla certifierade virtuella Azure-datorer. Den inkluderar inte heller vCPU:n och minnesdefinitionen för den virtuella datorn, utan snarare den teoretiska kapaciteten för fallet när Intel Hyperthreading har konfigurerats på värden. I praktiken bör du inte använda det i storlekssyfte eller dra några slutsatser om antalet virtuella processorer eller mängden minne för en viss storlek på den virtuella Azure-datorn.

När du jämför olika storlekar på virtuella Azure-datorer och beräknar förhållandet mellan SAPS och vCPU är det värt att notera att informationen från Microsoft och SAP alltid refererar till vCPU:er eller CPU-trådar i stället för CPU-kärnor. En Intel-processor utan metal-kärna kan representera en CPU-tråd om Hyper-V-värden är konfigurerad utan Hyperthreading eller två CPU-trådar med Hyperthreading aktiverat.

Hypertrådning på bare metal-server förbättrar det totala dataflödet. Ökningen är dock inte direkt proportionell mot antalet processortrådar på värden. Genomflödesförbättringen genom hypertrådning under en typisk SAP-arbetsbelastning sträcker sig från 30–40 %. Därför levererar en kärna med två hypertrådade CPU-trådar på värden 130–140 % av dataflödet som samma processorkärna levererar utan Hypertrådning. Det innebär att en enda CPU-tråd i en hypertrådad kärna levererar mellan 65–70 % av vad en icke-hypertrådad kärna levererar med en enda CPU-tråd.

Följande NetWeaver och/eller SAP HANA certifierade Azure VM-familjer körs på värdmaskinvara där Intel Hyperthreading är aktiverat:

  • D(S)v3

  • D(S)v4

  • E(S)v3

  • M-serien

När du ska ändra storlek på den avsedda distributionen måste du också överväga om du ska implementera den med hjälp av arkitekturen på 2 nivåer eller 3 nivåer.

Vm-typer har även vissa bandbreddsbegränsningar. I allmänhet kan vi ange att ju mindre den virtuella datorn i en VM-familj är, desto mindre är lagrings- och nätverksbandbredden. För stora virtuella datorer, till exempel M128s eller M128ms, eller ES64v3 är den virtuella datorn den enda virtuella datorn som körs på en värd. Det innebär att den drar nytta av den fullständiga nätverks- och lagringsbandbredd som värden har tillgänglig. När det gäller mindre virtuella datorer måste nätverks- och lagringsbandbredden delas upp mellan flera virtuella datorer. Särskilt för SAP HANA, men även för SAP NetWeaver, är det mycket viktigt att en virtuell dator som kör intensiv arbetsbelastning inte påverkar cpu, minne, nätverk och lagringsbandbredd på andra virtuella datorer som körs på samma värd. När du ska ändra storlek på en virtuell dator måste du därför också överväga den nätverks- och lagringsbandbredd som krävs.

För att maximera prestanda rekommenderar Microsoft att du använder ytterligare faktorer och överväganden när du har utför en SAP-storleksanalys. Vissa faktorer omfattas inte av SAP-storlekstekniker alls, till exempel användningen av SSD och stora mängder RAM-minne.

Det finns flera sätt att ändra storlek på SAP-system:

  • Referensbaserad storleksändring – ST03- och EarlyWatch-data analyseras och jämförs med en annan känd kund med liknande arbetsbelastning och en känd maskinvarukonfiguration

  • SAP Quicksizer – SAP-verktyg som beräknar SAPS, DB-storlek och RAM-minne baserat på många indata, inklusive volymer för affärsdokument och antal användare

  • T-shirt – storleksändring baserat på förväntat antal SAP-användare där exakt information inte är tillgänglig

Du kan välja att utvärdera prestanda för dina befintliga Azure-distributioner med hjälp av belastningstestningsverktyg (till exempel LoadRunner från Micro Focus, som är tillgängliga från Azure Marketplace).

Nätverksöverväganden

Nätverkets dataflöde påverkas inte av följande faktorer:

  • Antal nätverksgränssnitt: Bandbreddsgränsen är kumulativ för all utgående trafik från den virtuella datorn.

  • Accelererat nätverk: Funktionen kan vara användbar för att uppnå den publicerade gränsen, men den ändrar inte gränsen.

  • Trafikmål: Alla mål räknas mot den utgående gränsen.

  • Protokoll: All utgående trafik över alla protokoll räknas mot gränsen.

Följande metodtips för nätverk baseras på befintliga kunddistributioner:

  • De virtuella nätverk som SAP-programmet distribueras till har inte åtkomst till Internet.

  • De virtuella databas datorerna körs i samma virtuella nätverk som programlagret.

  • De virtuella datorerna i det virtuella nätverket har en statisk allokering av den privata IP-adressen. Detta är särskilt viktigt när du distribuerar SAP HANA eftersom vissa konfigurationsattribut för HANA-referens-IP-adresser.

  • Om du vill separera och isolera trafik till den virtuella DBMS-datorn tilldelar du olika nätverkskort till den virtuella datorn. Varje nätverkskort får olika IP-adresser och varje nätverkskort tilldelas till olika virtuella nätverksundernät. Ett nätverkskort kan till exempel ansluta till hanteringsundernätet och ett nätverkskort för att underlätta anslutningen från det lokala nätverket eller andra virtuella Azure-nätverk.

  • Trafikbegränsningar till och från virtuella Azure-datorer som är värdar för SAP-arbetsbelastningar styrs inte med hjälp av operativsystembrandväggen, utan genom att använda nätverkssäkerhetsgrupper (NSG:er).

  • Dela upp adressutrymmet för det virtuella nätverket i undernät. Varje undernät kan associeras med en NSG som definierar åtkomstprinciperna för undernätet. Placera programservrar i ett separat undernät så att du kan skydda dem enklare genom att hantera säkerhetsprinciperna för undernätet, inte de enskilda servrarna. Associera NSG:er med undernät i stället för enskilda nätverkskort för att minimera hanteringskostnader. När en NSG är associerad med ett undernät gäller den för alla virtuella Azure-datorer som är anslutna till det undernätet.

Tänk på att konfiguration av virtuella nätverksapparater i kommunikationsvägen mellan SAP-programmet och DBMS-lagret i ett SAP NetWeaver-, Hybris- eller S/4HANA-baserat SAP-system inte stöds. Den här begränsningen är av funktions- och prestandaskäl. Kommunikationsvägen mellan SAP-programlagret och DBMS-skiktet måste vara direkt. Begränsningen omfattar inte regler för programsäkerhetsgrupp (ASG) och NSG om dessa ASG- och NSG-regler tillåter en direkt kommunikationsväg.

Andra scenarier där virtuella nätverks installationer inte stöds är:

  • Kommunikationsvägar mellan virtuella Azure-datorer som representerar Linux Pacemaker-klusternoder och SBD-enheter.

  • Kommunikationsvägar mellan virtuella Azure-datorer och Windows Server Scale-Out Filserver (SOFS).

Virtuella Azure-datorer kan dra nytta av accelererade nätverks- och närhetsplaceringsgrupper. Använd dem när du distribuerar virtuella Azure-datorer för en SAP-arbetsbelastning, särskilt för SAP-programlagret och SAP DBMS-lagret.

Accelererat nätverk

  • Det går inte att starta accelererat nätverk för befintliga virtuella datorer. Accelererat nätverk måste aktiveras när en virtuell dator skapas. Det går att ta bort en virtuell dator (som standard behålls start- och datadiskarna) och skapa den virtuella datorn igen med samma diskar

  • SQL Server som körs med datafiler som lagras direkt på Blob Storage kan förmodligen dra stor nytta av accelererade nätverk

  • Det går att ha ett eller flera accelererade nätverkskort och ett traditionellt icke-accelererat nätverkskort på samma virtuella dator

  • Svarstiden för SAP-programserver till databasserver kan testas med ABAP/SSA/CAT -> ABAPMeter

  • Ineffektiv "trafikintensiva" ABAP eller särskilt intensiva åtgärder som stora lönejobb eller IS-Utilities-faktureringsjobb har uppvisat betydande förbättringar efter aktivering av accelererat nätverk

  • Om du vill dra nytta av accelererat nätverk i scenarier med belastningsutjämning bör du använda Standard Azure Load Balancer (i stället för Basic)

Överväganden för lagring

När du planerar disklayouten ska du hitta den optimala konfigurationen baserat på följande faktorer:

  • Antalet datafiler

  • Antalet diskar som innehåller filerna.

  • IOPS-kvoter för en enskild disk.

  • Dataflödet per disk.

  • Antalet ytterligare datadiskar som är möjliga per VM-storlek.

  • Det totala lagringsgenomflödet som en virtuell dator kan tillhandahålla.

  • Svarstiden kan Azure Storage olika typer av svarstider.

  • SERVICEavtal för virtuella datorer

Växlings-/växlingsfil

Använd följande rekommendationer när du konfigurerar växlings-/växlingsfilen:

  • Windows operativsystemets växlingsfil ska finnas på enheten D: (icke-beständig disk)

  • Linux-växlingsfilen ska finnas under /mnt/resource och konfigureras i konfigurationsfilen för Linux-agenten /etc/waagent.conf. Lägg till eller ändra följande inställningar:

    • ResourceDisk.EnableSwap=y

    • ResourceDisk.SwapSizeMB=<size_in_MBs>

  • Om du vill aktivera ändringarna måste du starta om Linux-agenten genom att köra:

    • sudo service waagent restart

Hanterade diskar

Användning av hanterade diskar rekommenderas för alla SAP-arbetsbelastningar.

Anteckning

Observera att hanterade diskar krävs för att implementera Skrivningsaccelerator. Som vi nämnde tidigare i den här Skrivningsaccelerator är en diskfunktion i virtuella Azure-datorer i M-serien med Premium lagringsbaserade Azure-hanterade diskar. Dess syfte är att förbättra I/O-svarstiden för skrivningar. Skrivningsaccelerator passar perfekt där loggfilsuppdateringar krävs för att bevaras på disk på ett mycket effektivt sätt för moderna databaser.

Premium Storage

Premium Storage ger betydligt bättre prestanda än Standard Storage, särskilt för kritiska skrivningar i transaktionsloggen. Microsoft rekommenderar att du använder Azure Standard SSD Storage som minimum för virtuella Azure-datorer som är värdar för SAP-programlagret och för icke-prestandakänslig DBMS-distribution och användning av Azure Premium SSD-lagring för alla andra DBMS-arbetsbelastningar för virtuella Azure-datorer.

För SAP-programservrar, inklusive virtuella datorer med Central Services, kan du potentiellt använda Azure Standard Storage för att minska kostnaderna, eftersom programkörningen sker i minnet och använder diskar endast för loggning. Som tidigare nämnts är dock Standard Storage endast certifierad för ohanterade diskar. Eftersom programservrar inte är värdar för några data kan du också använda de mindre P4- och P6-Premium Storage diskarna för att minimera kostnaderna.

Volymer med flera diskar

Antalet diskar som används för DBMS-datafilerna och typen av Azure Storage dessa diskar finns på bör fastställas av IOPS-kraven och den svarstid som krävs.

Anteckning

Det är viktigt att observera att IOPS-trafik till olika datafiler inte alltid är samma eftersom befintliga kundsystem kan ha datafiler av olika storlek som representerar deras databaser. I praktiken rekommenderar vi att du använder striping över flera diskar för att skapa volymer som är värdar för datafiler.

Storage svarstiden är kritisk för DBMS-system, även för SAP HANA, som i de flesta fall sparar data i minnet. Den kritiska sökvägen i lagringen är vanligtvis runt skrivningar i transaktionsloggen för DBMS-systemen. Åtgärder som att skriva sparapunkter eller läsa in data i minnet efter kraschåterställning kan dock också vara viktiga. Därför är det obligatoriskt att använda Azure Premium-diskar för /hana/data- och /hana/log-volymer. För att uppnå det minsta dataflödet för /hana/log och /hana/data som krävs av SAP skapar du en RAID 0-volym med hjälp av MDADM eller LVM över flera Azure Premium Storage-diskar. Som stripe-storlekar för RAID 0 rekommenderar vi att du använder:

  • 64 kB eller 128 kB för /hana/data

  • 32 kB för /hana/log

Cachelagring

När du monterar diskar på virtuella datorer kan du välja om I/O-trafiken mellan den virtuella datorn och de diskar som finns i Azure Storage cachelagras. Standard- Premium lagring använder två olika tekniker för den här typen av cache.

Följande cachelagringsrekommendationer förutsätter dessa I/O-egenskaper för dbms av standardstandard:

  • I/O består huvudsakligen av en läsarbetsbelastning mot datafiler i en databas. Dessa läsningar är prestandakritiska för DBMS-systemet.

  • Skrivning mot datafiler sker i burst-fel baserat på kontrollpunkter eller en konstant dataström. I genomsnitt under en dag finns det färre skrivningar än läsningar. Motsatsen till läsningar från datafiler är dessa skrivningar asynkrona och innehåller inte några användartransaktioner.

  • Det finns knappt några läsningar från transaktionsloggen eller redofiler. Undantag är stora I/O när du säkerhetskopierar transaktionsloggar.

  • Den huvudsakliga belastningen mot transaktions- eller redologgfiler är skrivningar. Beroende på typen av arbetsbelastning kan du ha I/O så litet som 4 kB eller i andra fall I/O-storlekar på 1 MB eller mer.

  • Alla skrivningar måste bevaras på disken på ett tillförlitligt sätt.

Premium Storage erbjuder följande cachelagringsalternativ:

  • Ingen

  • Läs

  • Läsning/skrivning

  • Ingen + Skrivningsaccelerator, som endast är för virtuella datorer i Azure M-serien

  • Läs + Skrivningsaccelerator, som endast är för virtuella datorer i Azure M-serien

Premium Storage rekommendationen är att använda Cachelagring av läsning för diskar som är värdar för SAP-databasdatafiler och Ingen cachelagring för diskar som innehåller SAP-databasloggfiler.

Samma princip gäller för SAP HANA, där cachelagringen för volymer som använder Azure Premium Storage anges på följande sätt:

  • /hana/data – ingen cachelagring

  • /hana/log – ingen cachelagring (med undantag för virtuella datorer i M-serien)

  • /hana/shared – läsa cachelagring

För distributioner i M-serien rekommenderar Microsoft att du använder Azure Skrivningsaccelerator för din DBMS-distribution. I själva verket kräver SAP HANA för virtuella datorer i Azure M-serien att Azure Skrivningsaccelerator vara aktiverat för /hana/log-volymen.

Anteckning

Observera att det finns begränsningar för virtuella Azure Premium Storage-hårddiskar per virtuell dator som kan stödjas av Azure Skrivningsaccelerator.

De aktuella gränserna är:

  • 16 virtuella hårddiskar för en virtuell dator med M128xx och M416xx

  • 8 virtuella hårddiskar för en virtuell M64xx- och M208xx-dator

  • 4 virtuella hårddiskar för en virtuell M32xx-dator

Dessa cachelagringsrekommendationer baseras på I/O-egenskaperna hos SAP HANA, inklusive:

  • Det finns nästan ingen läsarbetsbelastning mot HANA-datafilerna. Undantag är stora I/O efter omstart av HANA-instansen eller när data läses in i HANA. Ett annat fall med större läs-I/O mot datafiler kan vara HANA-databassäkerhetskopior. Därför är cachelagring av läsning huvudsakligen inte meningsfullt eftersom alla datafilvolymer i de flesta fall måste läsas helt.

  • Skrivningar mot datafilerna har burst-fel baserade på HANA-sparpunkter och HANA-kraschåterställning. Att skriva sparapunkter är asynkront och håller inte upp några användartransaktioner. Det är viktigt att skriva data under kraschåterställning för att systemet ska svara snabbt igen. Kraschåterställning bör dock vara ganska ovanliga situationer

  • Det finns nästan inga läsningar från HANA-redo-filerna. Undantag är stora I/O när du utför säkerhetskopieringar av transaktionsloggar, kraschåterställning eller omstartsfasen för en HANA-instans.

  • Den huvudsakliga inläsningen mot SAP HANA är skrivningar. Beroende på typen av arbetsbelastning kan du ha I/O så litet som 4 kB eller i andra fall I/O-storlekar på 1 MB eller mer. Skrivfördröjning mot SAP HANA är prestandakritisk.

  • Alla skrivningar måste bevaras på disk på ett tillförlitligt sätt

Ultra SSD

Microsoft introducerar nu en ny Azure-lagringstyp som kallas Azure Ultra SSD. Den största skillnaden mellan Azure Storage som erbjuds hittills Ultra SSD är att diskfunktionerna inte längre är bundna till diskstorleken. Som kund kan du definiera dessa funktioner för Ultra SSD:

  • Storleken på en disk mellan 4 GiB och 65 536 GiB

  • IOPS sträcker sig från 100 IOPS till 160 000 IOPS (max beror på DEN virtuella datorns SKU)

  • Storage dataflöde från 300 MB/sek till 2 000 MB/sek

UltraSSD ger dig möjlighet att definiera en enskild disk som uppfyller din storlek, IOPS och diskgenomflödesintervall, i stället för att använda logiska volymhanterare som LVM eller MDADM ovanpå Azure Premium Storage för att konstruera volymer som uppfyller IOPS- och lagringens dataflödeskrav. Du kan välja att ansluta både UltraSSD- och Premium Storage till samma virtuella Azure-datorer. Därför kan du begränsa användningen av UltraSSD för prestandakritiska /hana/data- och /hana/log-volymer och implementera andra volymer med Premium Storage

SAP HANA dynamisk nivå 2.0

SAP HANA dynamisk nivåindelad nivå 2.0 (DT 2.0) ger möjlighet att avlasta mindre ofta åtkomst till data från minnet till utökad lagring. SAP HANA Dynamisk nivå 2.0 stöds inte av SAP BW eller S4HANA. De primära användningsfallen består av interna HANA-program.

Det finns en uppsättning obligatoriska krav som måste följas för att säkerställa support för DT 2.0 på virtuella Azure-datorer:

  • DT 2.0 måste installeras på en dedikerad virtuell Azure-dator. Den kanske inte körs på samma virtuella dator där SAP HANA körs

  • SAP HANA och virtuella DT 2.0-datorer måste distribueras inom samma virtuella Azure-nätverk

  • De SAP HANA virtuella datorerna och DT 2.0 måste distribueras med Azure-accelererat nätverk aktiverat

  • Storage för de virtuella DT 2.0-datorerna måste vara Azure-Premium Storage

  • Flera Azure-diskar måste vara anslutna till den virtuella DT 2.0-datorn

  • Du måste skapa en stripe-volym (antingen via lvm eller mdadm) på Azure-diskarna

Vid redigeringen av den här kursen kan kunder använda följande två VM-storlekar för att köra SAP HANA DT 2.0:

  • M64-32 ms

  • E32sv3

Med tanke på den grundläggande förutsättningen för DT 2.0, som är att avlasta "varma" data för att spara kostnader, är det vanligtvis klokt att använda följande VM-storlekar:

SAP HANA typ av virtuell dator DT 2.0 VM-typ
M128ms M64-32 ms
M128s M64-32 ms
M64ms E32sv3
M64s E32sv3

Det finns dock ingen strikt regel för möjliga kombinationer. Valet är beroende av den specifika kundarbetsbelastningen och alla kombinationer av SAP HANA-certifierade virtuella datorer i M-serien med virtuella DT 2.0-datorer som stöds (M64-32ms och E32sv3) stöds.

Installation av DT 2.0 på en dedikerad virtuell dator kräver nätverksdataflöde mellan den virtuella datorn DT 2.0 och den virtuella datorn SAP HANA minst 10 GB. Därför är det obligatoriskt att placera alla virtuella datorer i samma virtuella Azure-nätverk och aktivera Azure-accelererat nätverk.

Enligt metodvägledningen för DT 2.0 bör disk-I/O-dataflödet vara minst 50 MB/sek per fysisk kärna. Enligt specifikationerna för de två typer av virtuella Azure-datorer som stöder DT 2.0 är deras värden för maximalt disk-I/S-dataflöde:

  • E32sv3: 768 MB/sek (inte frånkopplad), vilket innebär ett förhållande på 48 MB/sek per fysisk kärna

  • M64-32 ms: 1 000 MB/sek (icke-frånkopplad), vilket innebär ett förhållande på 62,5 MB/sek per fysisk kärna

Beroende på storlekskraven finns det olika alternativ för att nå det maximala dataflödet för en virtuell dator. Följande tabell innehåller diskkonfigurationer för datavolym för båda DT 2.0 VM-typerna som uppnår den övre dataflödesgränsen för virtuella datorer. Den virtuella datorn E32sv3 bör betraktas som en ingångsnivå för mindre arbetsbelastningar. Eftersom de virtuella M64–32-datorerna har mer minne kanske I/O-belastningen inte når gränsen, särskilt för läsintensiva arbetsbelastningar. Därför kan färre diskar i stripe-uppsättningen vara tillräckligt beroende på den kundspecifika arbetsbelastningen.

VM-SKU Diskkonfiguration 1 Diskkonfiguration 2 Diskkonfiguration 3 Diskkonfiguration 4 Diskkonfiguration 5
M64-32 ms 4 x P50 -> 16 TB 4 x P40 -> 8 TB 5 x P30 -> 5 TB 7 x P20 -> 3,5 TB 8 x P15 -> 2 TB
E32sv3 3 x P50 -> 12 TB 3 x P40 -> 6 TB 4 x P30 -> 4 TB 5 x P20 -> 2,5 TB 6 x P15 -> 1,5 TB

Baserat på heuristik är den rekommenderade storleken på loggvolymen 15 % av datavolymens storlek. Du kan skapa loggvolymen genom att använda olika Azure-disktyper beroende på kostnad och dataflödeskrav. Om du använder den virtuella datorn av typen M64-32ms Skrivningsaccelerator vara aktiverat.

Precis som SAP HANA utskalning måste katalogen /hana/shared delas mellan den virtuella SAP HANA-datorn och den virtuella datorn DT 2.0. Vi rekommenderar att du använder samma arkitektur som för SAP HANA utskalning, som förlitar sig på dedikerade virtuella datorer som fungerar som en NFS-server med hög tillgång. Identisk design kan användas för att tillhandahålla en delad säkerhetskopieringsvolym. Det är upp till kunden att avgöra om hög tillgänglighet är nödvändig eller om det räcker att använda en dedikerad virtuell dator med tillräckligt med lagringskapacitet för att fungera som en säkerhetskopieringsserver.