Azure Storage-typer för SAP-arbetsbelastning

Azure har många lagringstyper som skiljer sig mycket åt i funktioner, dataflöde, svarstid och priser. Vissa av lagringstyperna är inte eller av begränsad användbarhet för SAP-scenarier. Flera Azure-lagringstyper är väl lämpade eller optimerade för specifika SAP-arbetsbelastningsscenarier. Särskilt för SAP HANA har vissa Azure-lagringstyper certifierats för användning med SAP HANA. I det här dokumentet går vi igenom de olika typerna av lagring och beskriver deras kapacitet och användbarhet med SAP-arbetsbelastningar och SAP-komponenter.

Kommentar om de enheter som används i den här artikeln. De offentliga molnleverantörerna flyttade för att använda GiB (Gibibyte) eller TiB (Tebibyte som storleksenheter, i stället för Gigabyte eller Terabyte. Därför använder all Azure-dokumentation och prizing dessa enheter. I hela dokumentet refererar vi enbart till dessa storleksenheter för MiB-, GiB- och TiB-enheter. Du kan behöva planera med MB, GB och TB. Tänk därför på några små skillnader i beräkningarna om du behöver storlek för ett dataflöde på 400 MiB/sek i stället för ett dataflöde på 250 MiB/sek.

Återhämtning i Microsoft Azure Storage

Microsoft Azure-lagring av Standard HDD, Standard SSD, Azure Premium Storage, Premium SSD v2 och Ultra disk behåller den grundläggande virtuella hårddisken (med OS) och vm-anslutna datadiskar eller virtuella hårddiskar (virtuell hårddisk) i tre kopior på tre olika lagringsnoder. Växla över till en annan replik och seeding av en ny replik om det uppstår ett fel i lagringsnoden, är transparent. Som ett resultat av den här redundansen är det INTE nödvändigt att använda någon form av lagringsredundanslager på flera Azure-diskar. Det här är ett faktum som kallas lokal redundant lagring (LRS). LRS är standard för dessa typer av lagring i Azure. Azure NetApp Files ger tillräcklig redundans för att uppnå samma serviceavtal (serviceavtal) som andra interna Azure-lagringsenheter.

Det finns flera fler redundansmetoder, som alla beskrivs i artikeln Azure Storage-replikering som gäller för några av de olika lagringstyper som Azure har att erbjuda.

Tänk också på att olika Azure-lagringstyper påverkar serviceavtalen för enskild VM-tillgänglighet enligt SLA för virtuella datorer.

Azure-hanterade diskar

Hanterade diskar är en resurstyp i Azure Resource Manager som kan användas i stället för virtuella hårddiskar som lagras i Azure Storage-konton. Hanterade diskar överensstämmer automatiskt med [tillgänglighetsuppsättningen][virtual-machines-manage-availability] för den virtuella dator som de är anslutna till. Med en sådan justering kan du uppleva en förbättring av tillgängligheten för din virtuella dator och de tjänster som körs på den virtuella datorn. Mer information finns i översiktsartikeln.

Lagringsscenarier med SAP-arbetsbelastningar

Sparad lagring krävs i SAP-arbetsbelastningen i olika komponenter i stacken som du distribuerar i Azure. De här scenarierna listar minst:

• Beständiga den virtuella datorns bas-VHD som innehåller operativsystemet och annan programvara som du installerar på den disken. Den här disken/den virtuella hårddisken är roten på den virtuella datorn. Alla ändringar som görs i den måste sparas. Så att nästa gång du stoppar och startar om den virtuella datorn, finns alla ändringar som gjorts innan fortfarande. Särskilt i fall där den virtuella datorn distribueras av Azure till en annan värd än den kördes ursprungligen
• Lagrade datadiskar. Dessa diskar är virtuella hårddiskar som du kopplar för att lagra programdata i. Dessa programdata kan vara data och logga/göra om filer för en databas, säkerhetskopior eller programvaruinstallationer. Innebär alla diskar utanför din grundläggande virtuella hårddisk som innehåller operativsystemet
• Filresurser eller delade diskar som innehåller din globala transportkatalog för NetWeaver eller S/4HANA. Innehållet i dessa resurser förbrukas antingen av programvara som körs på flera virtuella datorer eller används för att skapa redundansklusterscenarier med hög tillgänglighet
• Katalogen /sapmnt eller gemensamma filresurser för EDI-processer (Electronic Data Interchange) eller liknande. Innehållet i dessa resurser förbrukas antingen av programvara som körs på flera virtuella datorer eller används för att skapa redundansklusterscenarier med hög tillgänglighet

I de kommande avsnitten diskuteras de olika Azure-lagringstyperna och deras användbarhet för de fyra SAP-arbetsbelastningsscenarierna. En allmän kategorisering av hur de olika Azure-lagringstyperna ska användas dokumenteras i artikeln Vilka disktyper är tillgängliga i Azure?. Rekommendationerna för att använda de olika Azure-lagringstyperna för SAP-arbetsbelastningar kommer inte att skilja sig avsevärt.

Om du vill ha supportbegränsningar för Azure-lagringstyper för SAP NetWeaver/application layer of S/4HANA läser du SAP-supportanteckningen 2015553. För SAP HANA-certifierade och azure-lagringstyper som stöds läser du artikeln sap hana azure virtual machine storage configurations.

Avsnitten som beskriver de olika Azure-lagringstyperna ger dig mer bakgrund om begränsningar och möjligheter med hjälp av SAP-lagring som stöds.

Lagringsalternativ när du använder DBMS-replikering

Våra referensarkitekturer förutser användningen av DBMS-funktioner (Database Management System) som SQL Server Always On, HANA System Replication, Db2 HADR eller Oracle Data Guard. Om du använder dessa tekniker mellan två eller flera virtuella Azure-datorer måste de lagringstyper som valts för var och en av de virtuella datorerna vara desamma. Innebär att lagringskonfigurationen mellan den aktiva noden och repliknoden i DBMS HA-konfigurationen måste vara densamma.

Lagringsrekommendationer för SAP-lagringsscenarier

Innan vi går in på informationen presenterar vi sammanfattningen och rekommendationerna redan i början av dokumentet. Informationen för de specifika typerna av Azure Storage följer det här avsnittet i dokumentet. När vi sammanfattar lagringsrekommendationerna för SAP-lagringsscenarier i en tabell ser det ut så här:

¹ Med användning av Azure Write Accelerator för M/Mv2 VM-familjer för logg-/omloggvolymer

Egenskaper som du kan förvänta dig från listan med olika lagringstyper som:

¹ Med användning av Azure Write Accelerator för M/Mv2 VM-familjer för logg-/omloggvolymer

² Skapandet av olika Azure NetApp Files-kapacitetspooler garanterar inte distribution av kapacitetspooler till olika lagringsenheter

³ (inkrementella) ögonblicksbilder av en Premium SSD v2 eller en Ultra-disk kan inte användas omedelbart efter att de har skapats. Bakgrundskopian måste slutföras innan du kan skapa en disk från ögonblicksbilden

Azure Premium Storage

Azure Premium SSD-lagring introducerades med målet att tillhandahålla:

• Låg I/O-svarstid
• Serviceavtal för IOPS och dataflöde
• Mindre variabilitet i I/O-svarstid

Den här typen av lagring riktar sig till DBMS-arbetsbelastningar, lagringstrafik som kräver kort svarstid på ensiffriga millisekunder och serviceavtal för IOPS och dataflöde. Kostnadsbasen för Azure Premium Storage är inte den faktiska datavolymen som lagras på sådana diskar, utan storlekskategorin för en sådan disk, oberoende av mängden data som lagras på disken. Du kan också skapa diskar på Premium Storage som inte direkt mappas till de storlekskategorier som visas i artikeln Premium SSD. Slutsatser av den här artikeln är:

• Lagringen är ordnad i intervall. Till exempel delar en disk i intervallet 513 GiB till 1 024 GiB-kapacitet samma funktioner och samma månatliga kostnader
• IOPS per GiB spårar inte linjärt i storlekskategorierna. Mindre diskar under 32 GiB har högre IOPS-priser per GiB. För diskar över 32 GiB till 1 024 GiB är IOPS-hastigheten per GiB mellan 4–5 IOPS per GiB. För större diskar upp till 32 767 GiB går IOPS-hastigheten per GiB under 1
• I/O-dataflödet för det här lagringsutrymmet är inte linjärt med storleken på diskkategorin. För mindre diskar, som kategorin mellan 65 GiB- och 128 GiB-kapacitet, är dataflödet cirka 780 KB per GiB. För extremt stora diskar som en 32 767 GiB-disk är dataflödet cirka 28 KB per GiB
• Serviceavtalen för IOPS och dataflöde kan inte ändras utan att diskens kapacitet ändras

Funktionsmatrisen för SAP-arbetsbelastningen ser ut så här:

Azure Premium Storage uppfyller inte KPI:er för SAP HANA-lagringsfördröjning med de vanliga cachelagringstyperna som erbjuds med Azure Premium Storage. För att uppfylla KPI:erna för lagringsfördröjning för SAP HANA-loggskrivningar måste du använda Cachelagring av Azure Write Accelerator enligt beskrivningen i artikeln Aktivera skrivaccelerator. Azure Write Accelerator gynnar alla andra DBMS-system för deras transaktionsloggskrivningar och gör om loggskrivningar. Därför rekommenderar vi att du använder det i alla SAP DBMS-distributioner. För SAP HANA är användningen av Azure Write Accelerator för /hana/log med Azure Premium Storage obligatorisk.

Sammanfattning: Azure Premium Storage är en av de Azure-lagringstyper som rekommenderas för SAP-arbetsbelastning. Den här rekommendationen gäller för icke-produktions- och produktionssystem. Azure Premium Storage passar för att hantera databasarbetsbelastningar. Användningen av Azure Write Accelerator kommer att förbättra skrivfördröjningen avsevärt mot Azure Premium-diskar. För DBMS-system med höga IOPS- och dataflödeshastigheter måste du dock antingen överetablera lagringskapaciteten. Eller så måste du använda funktioner som Windows-lagringsutrymmen eller logiska volymhanterare i Linux för att skapa stripe-uppsättningar som ger dig önskad kapacitet på ena sidan. Men också nödvändigt IOPS eller dataflöde till bästa kostnadseffektivitet.

Azure Burst-funktioner för Premium Storage

För Azure Premium-lagringsdiskar som är mindre eller lika med 512 GiB i kapacitet erbjuds burst-funktioner. Exakt hur disksprängningar fungerar beskrivs i artikeln Disksprängning. När du läser artikeln förstår du begreppet ackumulerat IOPS och dataflöde i de tider då din I/O-arbetsbelastning ligger under diskarnas nominella IOPS och dataflöde (mer information om det nominella dataflödet finns i Prissättning för hanterade diskar). Du kommer att ackumulera deltat i IOPS och dataflödet mellan din aktuella användning och diskens nominella värden. Bursts är begränsade till högst 30 minuter.

De idealiska fall där den här burst-funktionen kan planeras i kommer sannolikt att vara de volymer eller diskar som innehåller datafiler för de olika DBMS. Den I/O-arbetsbelastning som förväntas mot dessa volymer, särskilt med små till medelstora system förväntas se ut så här:

• Låg till måttlig läsarbetsbelastning eftersom data helst cachelagras i minnet. Eller som med SAP HANA bör vara helt i minnet
• Skrivningstoppar som utlöses av databaskontrollpunkter eller sparandepunkter som utfärdas regelbundet
• Säkerhetskopieringsarbetsbelastning som läser i en kontinuerlig ström i fall där säkerhetskopieringar inte körs via ögonblicksbilder av lagring
• För SAP HANA läser du in data i minnet efter en omstart av instansen

Särskilt i mindre DBMS-system där din arbetsbelastning endast hanterar några hundra transaktioner per sekund kan en sådan burst-funktion vara lämplig även för de diskar eller volymer som lagrar transaktionen eller gör om loggen. Förväntad arbetsbelastning mot en sådan disk eller volymer ser ut så här:

• Regelbundna skrivningar till disken som är beroende av arbetsbelastningen och typen av arbetsbelastning eftersom varje incheckning som utfärdas av programmet sannolikt utlöser en I/O-åtgärd
• Högre arbetsbelastning i dataflöde för driftsaktiviteter, till exempel att skapa eller återskapa index
• Läs bursts när du utför transaktionsloggar eller gör om loggsäkerhetskopior

Azure Premium SSD v2

Azure Premium SSD v2 Storage är en ny version av Premium Storage som introducerades med målet att tillhandahålla:

• I/O-svarstid för undermillisekunder för mindre I/O-storlekar för läsning och skrivning
• Serviceavtal för IOPS och dataflöde
• Betala kapacitet av etablerade GB
• Ange en standarduppsättning med IOPS och lagringsdataflöde per disk
• Ge möjlighet att lägga till mer IOPS och dataflöde till varje disk och betala separat för dessa extra etablerade resurser
• Skicka SAP HANA-certifiering utan hjälp av andra funktioner som Azure Write Accelerator eller andra cacheminnen

Den här typen av lagring riktar sig till DBMS-arbetsbelastningar, lagringstrafik som kräver svarstid på undermillisekunder och serviceavtal för IOPS och dataflöde. Premium SSD v2-diskarna levereras med en standarduppsättning på 3 000 IOPS- och 125 MBIT/s-dataflöde. Och möjligheten att lägga till mer IOPS och dataflöde till enskilda diskar. Prissättningen för lagringen är strukturerad på ett sätt som gör att mer dataflöde eller IOPS inte påverkar priset. Men vi låter dig bestämma hur lagringskonfigurationen för Premium SSD v2 ska se ut. En basstart finns i SAP HANA Azure virtual machine Premium SSD v2 storage configurations (Azure Azure-lagringskonfigurationer för premium SSD v2).

För de faktiska regionerna är den här nya blocklagringstypen tillgänglig och de faktiska begränsningarna läser dokumentet Premium SSD v2.

Funktionsmatrisen för SAP-arbetsbelastningen ser ut så här:

¹ (inkrementella) ögonblicksbilder av en Premium SSD v2 eller en Ultra-disk kan inte användas omedelbart efter att de har skapats. Bakgrundskopian måste slutföras innan du kan skapa en disk från ögonblicksbilden

I motsats till Azure Premium Storage uppfyller Azure Premium SSD v2 KPI:er för SAP HANA-lagringsfördröjning. Därför behöver du inte använda Cachelagring av Azure Write Accelerator enligt beskrivningen i artikeln Aktivera skrivaccelerator.

Sammanfattning: Azure Premium SSD v2 är blocklagringen som passar det bästa pris-/prestandaförhållandet för SAP-arbetsbelastningar. Azure Premium SSD v2 passar för att hantera databasarbetsbelastningar. Svarstiden för undermillisekunder är idealisk lagring för krävande DBMS-arbetsbelastningar. Även om det är en nyare lagringstyp som släpptes i november 2022. Därför kan det fortfarande finnas vissa begränsningar som kommer att försvinna under de närmaste månaderna.

Azure Ultra-disk

Azures ultradiskar tillhandahåller disklagring med ett snabbt dataflöde, hög IOPS och konsekvent snabba svarstider för virtuella Azure IaaS-datorer. Några fördelar med ultradiskar är möjligheten att dynamiskt ändra IOPS och dataflödet för disken, tillsammans med dina arbetsbelastningar, utan att behöva starta om dina virtuella datorer (VM). Ultradiskar passar för dataintensiva arbetsbelastningar, till exempel SAP DBMS-arbetsbelastning. Ultradiskar kan bara användas som datadiskar och kan inte användas som bas-VHD-disk som lagrar operativsystemet. Vi rekommenderar användning av Azure Premium Storage som baserad VHD-disk.

När du skapar en ultradisk har du tre dimensioner som du kan definiera:

• Diskens kapacitet. Intervall är från 4 GiB till 65 536 GiB
• Etablerad IOPS för disken. Olika maxvärden gäller för diskens kapacitet. Läs artikeln Ultra disk för mer information
• Etablerad lagringsbandbredd. Olika maximal bandbredd gäller beroende på diskens kapacitet. Läs artikeln Ultra disk för mer information

Kostnaden för en enskild disk bestäms av de tre dimensioner som du kan definiera för de specifika diskarna separat.

Funktionsmatrisen för SAP-arbetsbelastningen ser ut så här:

¹ (inkrementella) ögonblicksbilder av en Premium SSD v2 eller en Ultra-disk kan inte användas omedelbart efter att de har skapats. Bakgrundskopian måste slutföras innan du kan skapa en disk från ögonblicksbilden

Sammanfattning: Azure-ultradiskar är ett lämpligt lagringsutrymme med låg svarstid på undermillisekunder för alla typer av SAP-arbetsbelastningar. Hittills kan Ultra-disk endast användas i kombinationer med virtuella datorer som har distribuerats via tillgänglighetszoner (zonindelad distribution). I motsats till allt annat lagringsutrymme kan Ultra-disk inte användas för den grundläggande VHD-disken. Ultradisk är perfekt för fall där I/O-arbetsbelastningen varierar mycket och du vill anpassa distribuerat lagringsdataflöde eller IOPS till lagringsarbetsbelastningsmönster i stället för storlek för maximal användning av bandbredd och IOPS.

Azure NetApp Files

Azure NetApp Files är en azure-inbyggd, förstklassig fillagringstjänst i företagsklass med höga prestanda som är certifierad för användning med SAP HANA. Den tillhandahåller Volymer som en tjänst där du skapar NetApp-konton, kapacitetspooler och volymer. Med Azure NetApp Files väljer du tjänst- och prestandanivåer och hanterar dataskydd för att skapa och hantera högpresterande, högtillgängliga och skalbara filresurser med hjälp av samma protokoll och verktyg som du är bekant med och förlitar dig på lokalt.

Följande typer av SAP-arbetsbelastningar stöds på Azure NetApp Files-volymer:

• SAP DBMS-arbetsbelastning
• SAPMNT-resurs
• Global transportkatalog

Azure NetApp Files är tillgängligt på tre tjänstnivåer, var och en med sitt eget dataflöde och prisspecifikationer. Vilken som passar för distributionen beror på distributionens storlek. Anpassade storleksrekommendationer är tillgängliga i SAP på Azure NetApp Files TCO Estimator.

Information om tjänstnivåer finns i Tjänstnivåer för Azure NetApp Files.

Distribuera volymer

För optimala resultat använder du Programvolymgrupp för SAP HANA för att distribuera volymerna. Programvolymgruppen placerar volymer på optimala platser i Azure-infrastrukturen med hjälp av tillhörighets- och antitillhörighetsregler för att minska konkurrensen och för att möjliggöra bästa dataflöde och lägsta svarstid.

Azure NetApp Files stöds för flera SAP-arbetsbelastningsscenarier:

• SAP HANA-distributioner med hjälp av NFS-resurser för /hana/data och /hana/log-volymer för /hana/delade volymer enligt beskrivningen i konfigurationerna för sap hana azure-lagring
• Tillhandahålla SMB- eller NFS-resurser för SAP:s globala transportkatalog
• Resursen sapmnt i scenarier med hög tillgänglighet enligt beskrivningen i:
  • Hög tillgänglighet för SAP NetWeaver på virtuella Azure-datorer i Windows med Azure NetApp Files (SMB) för SAP-program
  • Hög tillgänglighet för SAP NetWeaver på virtuella Azure-datorer på SUSE Linux Enterprise Server med Azure NetApp Files för SAP-program
  • Azure Virtual Machines hög tillgänglighet för SAP NetWeaver på Red Hat Enterprise Linux med Azure NetApp Files för SAP-program
• IBM Db2 i Suse eller Red Hat Linux-baserad virtuell Azure-dator
• SAP på Oracle-distributioner i Oracle Linux-gästoperativsystem med dNFS för Oracle-data och gör om loggvolymer. Mer information finns i artikeln Azure Virtual Machines Oracle DBMS-distribution för SAP-arbetsbelastning
• SAP på ASE i Suse eller Red Hat Linux gästoperativsystem
• AP på MAXDB i Suse eller Red Hat Linux gästoperativsystem
• SAP på Microsoft SQL Server med SMB-volymer

Avkoppling av dataflöde från volymstorlek

Lagring för databasprogram har vanligtvis dataflödeskrav som inte skalas linjärt med storleken på volymerna, dvs. loggvolymer är relativt små i storlek men kräver höga dataflödesnivåer.

Med Azure NetApp Files kan du allokera volymdataflöde oberoende av volymstorlekar när du använder en kapacitetspool av typen manuell QoS.

Här är ett exempel:

• En volym för databasfiler kräver 500 MiB/s-dataflöde och 39 TiB-kapacitet
• En volym för loggfiler kräver 2 000 MiB/s-dataflöde och 1 TiB-kapacitet

Du kan skapa en manuell QoS-kapacitetspool för det här scenariot och allokera dataflöde oberoende av volymstorlekarna. Den totala kapacitet som krävs är 40 TiB och den totala dataflödesbudgeten är 2 500 MiB/s. En kapacitetspool på Premium-tjänstnivån (64 MiB/s per allokerad TiB) rymmer både prestanda- och kapacitetskrav (40 MiB * 64 iB/s/TiB = 2 560 MiB).

Linjär prestandaskalning skulle kräva betydande överetablering av loggvolymen för att uppnå dataflödeskravet. För att uppnå dataflödet 2 000 MiB/s för loggvolymen skulle du behöva distribuera en kapacitetspool på Ultra-nivån (128 MiB/s per allokerad TiB) på 16 TiB, vilket resulterar i en överetablering och därmed en bortkastad kapacitet på 15 TiB.

Använd Prestandakalkylatorn för Azure NetApp Files för att få en uppskattning för ditt scenario.

Funktionsmatrisen för SAP-arbetsbelastningen i Azure NetApp Files ser ut så här:

Andra inbyggda funktioner i Azure NetApp Files Storage:

• Möjlighet att utföra programkonsekventa ögonblicksbilder av volymen med AzAcSnap
• Kloning av Azure NetApp Files-volymer från ögonblicksbilder för testning och utveckling
• Återställa volymer från ögonblicksbilder (snapåterställning) för snabba återställningar från skador och fel

Motivationen att ha den här typen av tillgänglighetszonjustering är att minska riskytan genom att ha NFS-resurserna i samma tillgänglighetszon som de virtuella programdatorerna.

• Distribuera Azure NetApp Files-volymer för din SAP HANA-distribution med hjälp av programvolymgruppen för SAP HANA. Fördelen med programvolymgruppen är att datavolymer distribueras via flera lagringsslutpunkter, vilket minskar nätverkskonkurrationen och förbättrar prestandan.

Sammanfattning: Azure NetApp Files är en certifierad lagringslösning med låg svarstid för SAP HANA. Tjänsten tillhandahåller volymer som är utskurna från en eller flera kapacitetspooler. Kapacitetspooler är tillgängliga på tre tjänstnivåer som definierar den totala kapaciteten och det allokerade dataflödet. Volymerna kan ändras och allokerat dataflöde kan justeras utan avbrott i tjänsten för att tillgodose ändrade krav och för att kontrollera kostnaderna. Tjänsten tillhandahåller funktioner för att replikera volymer till andra regioner eller zoner för haveriberedskap och affärskontinuans.

Azure Premium Files

Azure Premium Files är en delad lagringsplats som erbjuder SMB och NFS till ett måttligt pris och tillräcklig svarstid för att hantera resurser i SAP-programlagret. Dessutom erbjuder Azure Premium Files synkron zonreplikering av resurserna med en automatism som ifall en replik misslyckas kan en annan replik i en annan zon ta över. I motsats till Azure NetApp Files finns det inga prestandanivåer. Det finns inte heller något behov av en kapacitetspool. Debitering baseras på den faktiska etablerade kapaciteten för de olika resurserna. Azure Premium Files har inte testats som DBMS-lagring för SAP-arbetsbelastning alls. Men i stället fokuserade användningsscenariot för SAP-arbetsbelastningen på alla typer av SMB- och NFS-resurser när de används på SAP-programskiktet. Azure Premium Files passar även för användning för /hana/shared.

SAP-scenarier som stöds i Azure Premium Files-listan, till exempel:

• Tillhandahålla SMB- eller NFS-resurser för SAP:s globala transportkatalog
• Användning som resurs för gränssnitt till SAP-system och EDI-processer
• Resursen sapmnt i scenarier med hög tillgänglighet enligt beskrivningen i:
  • Hög tillgänglighet för SAP NetWeaver på virtuella Azure-datorer på SUSE Linux Enterprise Server med NFS på Azure Files
  • Hög tillgänglighet för SAP NetWeaver på Red Hat Enterprise Linux med NFS på Azure Files
  • Hög tillgänglighet för SAP NetWeaver på virtuella Azure-datorer i Windows med Azure Files Premium SMB för SAP-program
  • Hög tillgänglighet för SAP HANA-utskalningssystem med HSR på SUSE Linux Enterprise Server

Azure Premium Files börjar med en större mängd IOPS med en minsta resursstorlek på 100 GB jämfört med Azure NetApp Files. Det här högre fältet i IOPS kan undvika överetablering av kapacitet för att uppnå vissa IOPS- och dataflödesvärden. För IOPS och dataflöde för lagring läser du avsnittet Skalningsmål för Azure-filresurs i Skalbarhets- och prestandamål för Azure Files.

Funktionsmatrisen för SAP-arbetsbelastningen ser ut så här:

Sammanfattning: Azure Premium Files är en lagring med låg svarstid som gör det möjligt att distribuera NFS- och SMB-volymer eller resurser. Azure Premium Files ger utmärkt pris/prestanda för SAP-programlagerresurser. Det ger också synkron zonreplikering för dessa resurser. Hittills har vi inte stöd för den här lagringstypen för SAP DBMS-arbetsbelastning. Även om den kan användas för /hana/delade volymer.

Azure Standard SSD-lagring

Jämfört med Azure Standard HDD Storage ger Azure Standard SSD-lagring bättre tillgänglighet, konsekvens, tillförlitlighet och svarstid. Den är optimerad för arbetsbelastningar som behöver konsekventa prestanda på lägre IOPS-nivåer. Den här lagringen är den minsta lagring som används för sap-system som inte är produktionsprodukter och som har låga krav på IOPS och dataflöde. Funktionsmatrisen för SAP-arbetsbelastningen ser ut så här:

Sammanfattning: Azure Standard SSD-lagring är den minsta rekommendationen för virtuella datorer som inte är produktioner för bas-VHD, eventuella DBMS-distributioner med relativ svarstidsokänslighet och/eller låga IOPS- och dataflödeshastigheter. Den här Azure-lagringstypen stöds inte längre för att vara värd för SAP Global Transport Directory.

Azure Standard HDD Storage

Azure Standard HDD-lagringen var den enda lagringstypen när Azure-infrastrukturen certifierades för SAP NetWeaver-arbetsbelastningen år 2014. År 2014 var de virtuella Azure-datorerna små och låg i dataflödet för lagring. Därför kunde den här lagringstypen bara hänga med i kraven. Lagringen är perfekt för svarstidsokänsliga arbetsbelastningar, som du knappt upplever i SAP-utrymmet. Med det ökande dataflödet för virtuella Azure-datorer och den ökade arbetsbelastningen som dessa virtuella datorer producerar beaktas inte längre den här lagringstypen för användning med SAP-scenarier. Funktionsmatrisen för SAP-arbetsbelastningen ser ut så här:

Sammanfattning: Standard HDD är en Azure-lagringstyp som endast ska användas för att lagra SAP-säkerhetskopior. Den bör endast användas som bas-VHD för ganska inaktiva system, till exempel tillbakadragna system som används för att söka efter data här och där. Men inga aktiva utvecklings-, QA- eller produktions-VM:ar bör baseras på den lagringen. Databasfiler bör inte heller finnas på lagringsplatsen

Begränsningar för virtuella Azure-datorer i lagringstrafik

I motsats till lokala scenarier spelar den enskilda vm-typ som du väljer en viktig roll i den lagringsbandbredd som du kan uppnå. För de olika lagringstyperna måste du tänka på följande:

Som begränsningar måste du notera att:

• Ju mindre den virtuella datorn är, desto färre diskar kan du ansluta. Den här begränsningen gäller inte för Azure NetApp Files. Eftersom du monterar NFS- eller SMB-resurser finns det ingen gräns för hur många delade volymer som ska kopplas
• Virtuella datorer har I/O-dataflöde och IOPS-gränser som enkelt kan överskridas med premiumlagringsdiskar och Ultra-diskar
• Med Azure NetApp Files och Azure Premium Files förbrukar trafiken till de delade volymerna den virtuella datorns nätverksbandbredd och inte lagringsbandbredden
• Med stora NFS-volymer i det tvåsiffriga TiB-kapacitetsutrymmet kommer dataflödet som kommer åt en sådan volym från en enda virtuell dator att platå baserat på gränserna för Linux för en enda session som interagerar med den delade volymen.

När du ökar storleken på virtuella Azure-datorer i livscykeln för ett SAP-system bör du utvärdera IOPS- och lagringsdataflödesgränserna för den nya och större vm-typen. I vissa fall kan det också vara klokt att justera lagringskonfigurationen till de nya funktionerna i den virtuella Azure-datorn.

Striping eller inte striping

Genom att skapa en stripe-uppsättning av flera Azure-diskar i en större volym kan du ackumulera IOPS och dataflödet för de enskilda diskarna till en volym. Den används endast för Azure Standard Storage och Azure Premium Storage. Azure Ultra-disk där du kan konfigurera dataflödet och IOPS oberoende av diskkapaciteten kräver inte användning av stripe-uppsättningar. Delade volymer som baseras på NFS eller SMB kan inte vara randiga. På grund av att Azure Premium Storage-dataflödet och IOPS inte är linjära kan du etablera mindre kapacitet med samma IOPS och dataflöde än stora enskilda Azure Premium-lagringsdiskar. Det är metoden för att uppnå högre dataflöde eller IOPS till lägre kostnad med Azure Premium Storage. Om du till exempel remsar över två P15 Premium-lagringsdiskar får du ett dataflöde på:

• 250 MiB/s. En sådan volym kommer att ha 512 GiB-kapacitet. Om du vill ha en enda disk som ger dig 250 MiB-dataflöde per sekund måste du välja en P40-disk med 2 TiB-kapacitet.
• 400 MiB/s genom att ta bort fyra P10 Premium-lagringsdiskar med en total kapacitet på 512 GiB genom striping. Om du vill ha en enda disk med minst 500 MiB-dataflöde per sekund måste du välja en P60 Premium Storage-disk med 8 TiB. Eftersom kostnaden för premiumlagring är nästan linjär med kapaciteten kan du känna av kostnadsbesparingarna med hjälp av striping.

Vissa regler måste följas vid stripning:

• Ingen konfigurerad lagringsredundans på den virtuella datorn ska användas eftersom Azure Storage håller datadisken redundant redan på Azure Storage-serverdelen
• Diskarna som stripe-uppsättningen tillämpas på måste vara av samma storlek
• Med Premium SSD v2 och Ultra Disk måste kapaciteten, etablerade IOPS och etablerat dataflöde vara samma

Striping över flera mindre diskar är det bästa sättet att uppnå ett bra pris/prestanda-förhållande med Azure Premium Storage. Det är underförstått att striping kan ha lite extra distributions- och hanteringskostnader.

För specifika rekommendationer för stripe-storlek läser du dokumentationen för de olika DBMS,t.ex . lagringskonfigurationerna för virtuella SAP HANA Azure-datorer.

Nästa steg

Läs artiklarna:

• Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning
• Lagringskonfigurationer för virtuella SAP HANA Azure-datorer