Azure Storage-typer för SAP-arbetsbelastning

  • Artikel

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 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 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.

Kommentar

Med Azure Storage för att lagra databasdata och göra om loggfilen är LRS den enda återhämtningsnivå som stöds just nu

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.

Kommentar

Vi kräver att nya distributioner av virtuella datorer som använder Azure-blocklagring för sina diskar (all Azure-lagring utom Azure NetApp Files och Azure Files) måste använda Azure-hanterade diskar för de grundläggande VHD/OS-diskar och datadiskar som lagrar SAP-databasfiler. Oberoende av om du distribuerar de virtuella datorerna via tillgänglighetsuppsättningar, över Tillgänglighetszoner eller oberoende av uppsättningar och zoner. Diskar som används för att lagra säkerhetskopior behöver inte nödvändigtvis vara hanterade diskar.

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 vanliga filresurser för EDI-processer 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 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:

Användningsscenario Standard HDD Standard SSD Premium Storage Premium SSD v2 Ultradisk Azure NetApp Files Azure Premium Files
OS-disk Inte lämplig Begränsad lämplig (icke-prod) Rekommenderat Inte möjligt Inte möjligt Inte möjligt Inte möjligt
Global transportkatalog Stöds inte Stöds inte Rekommenderat Rekommenderat Rekommenderat Rekommenderat Rekommenderas starkt
/sapmnt Inte lämplig Begränsad lämplig (icke-prod) Rekommenderat Rekommenderat Rekommenderat Rekommenderat Rekommenderas starkt
DBMS-datavolymen SAP HANA M/Mv2 VM-familjer Stöds inte Stöds inte Rekommenderat Rekommenderat Rekommenderat Rekommenderas2 Stöds inte
DBMS-loggvolymen SAP HANA M/Mv2 VM-familjer Stöds inte Stöds inte Rekommenderas1 Rekommenderat Rekommenderat Rekommenderas2 Stöds inte
DBMS-datavolymen SAP HANA Esv3/Edsv4 VM-familjer Stöds inte Stöds inte Rekommenderat Rekommenderat Rekommenderat Rekommenderas2 Stöds inte
DBMS-loggvolymen SAP HANA Esv3/Edsv4 VM-familjer Stöds inte Stöds inte Stöds inte Rekommenderat Rekommenderat Rekommenderas2 Stöds inte
HANA-delad volym Stöds inte Stöds inte Rekommenderat Rekommenderat Rekommenderat Rekommenderat Rekommenderas3
DBMS-datavolym som inte är HANA Stöds inte Begränsad lämplig (icke-prod) Rekommenderat Rekommenderat Rekommenderat Endast för specifika Oracle-versioner på Oracle Linux, Db2 och SAP ASE på SLES/RHEL Linux Stöds inte
DBMS-loggvolymen icke-HANA M/Mv2 VM-familjer Stöds inte Begränsad lämplig (icke-prod) Rekommenderas1 Rekommenderat Rekommenderat Endast för specifika Oracle-versioner på Oracle Linux, Db2 och SAP ASE på SLES/RHEL Linux Stöds inte
DBMS-loggvolymen icke-HANA icke-M/Mv2 VM-familjer Stöds inte begränsad lämplig (icke-prod) Lämplig för upp till medelhög arbetsbelastning Rekommenderat Rekommenderat Endast för specifika Oracle-versioner på Oracle Linux, Db2 och SAP ASE på SLES/RHEL Linux Stöds inte

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

2 Användning av ANF kräver att /hana/data och /hana/log finns på ANF

3 Hittills har endast testats på SLES

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

Användningsscenario Standard HDD Standard SSD Premium Storage Premium SSD v2 Ultradisk Azure NetApp Files Azure Premium Files
Serviceavtal för dataflöde/IOPS Nej No Ja Ja Ja Ja Ja
Svarstidsläsningar Högst Medelhög till hög Lägst undermillisecond undermillisecond undermillisecond Låg
Svarstidsskrivningar Högst Medelhög till hög Låg (undermillisekunder1) undermillisecond undermillisecond undermillisecond Låg
HANA stöds Nej Nej Ja1 Ja Ja Ja Nej
Möjliga diskögonblicksbilder Ja Ja Ja Nej No Ja Nej
Allokering av diskar i olika lagringskluster när du använder tillgänglighetsuppsättningar Via hanterade diskar Via hanterade diskar Via hanterade diskar Disktyp stöds inte med virtuella datorer som distribueras via tillgänglighetsuppsättningar Disktyp stöds inte med virtuella datorer som distribueras via tillgänglighetsuppsättningar Nej3 Inga
Justerat efter Tillgänglighetszoner Ja Ja Ja Ja Ja Offentlig förhandsversion Inga
Synkron zonredundans Inte för hanterade diskar Inte för hanterade diskar Stöds inte för DBMS Nej No No Ja
Asynkron zonredundans Inte för hanterade diskar Inte för hanterade diskar Stöds inte för DBMS Nej Nej I förhandsversion Inga
Geo-redundans Inte för hanterade diskar Inte för hanterade diskar Nej No Nej Möjligt Inga

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

2 Kostnader beror på etablerad IOPS och dataflöde

3 Att skapa olika ANF-kapacitetspooler garanterar inte distribution av kapacitetspooler till olika lagringsenheter

Viktigt!

Kolla in avsnittet Azure NetApp Files i det här dokumentet för att hitta detaljer kring närhetsplacering av NFS-volymer och virtuella datorer när mindre än 1 millisekunders svarstider krävs.

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. En disk i intervallet 513 GiB till 1 024 GiB-kapacitet har till exempel 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 1024 GiB är IOPS-priset 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:

Kapacitet Kommentar Anteckningar/länkar
Os-bas-VHD Lämplig Alla system
Datadisk Lämplig Alla system – speciellt för SAP HANA
GLOBAL SAP-transportkatalog Ja Stöds
SAP sapmnt Lämplig Alla system
Lagring för säkerhetskopior Lämplig För kortsiktig lagring av säkerhetskopior
Resurser/delad disk Inte tillgängliga Behöver Azure Premium Files eller tredje part
Motståndskraft LRS Ingen GRS eller ZRS tillgänglig för diskar
Svarstid Låg till medelhög -
Serviceavtal för IOPS Ja -
IOPS linjär till kapacitet semi linjär inom hakparenteser Priser för hanterade diskar
Maximalt IOPS per disk 20 000 beroende av diskstorlek Överväg även VM-gränser
SLA för dataflöde Ja -
Dataflöde linjärt till kapacitet Semi linjär inom hakparenteser Priser för hanterade diskar
HANA-certifierad Ja speciellt för SAP HANA
Stöd för Azure Write Accelerator Inga -
Diskutvidgning Ja -
Möjliga diskögonblicksbilder Ja -
Azure Backup VM-ögonblicksbilder är möjliga Ja -
Kostnader Medium -

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 system som inte är 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:

Kapacitet Kommentar Anteckningar/länkar
Os-bas-VHD Stöds inte Inget system
Datadisk Lämplig Alla system
GLOBAL SAP-transportkatalog Ja Alla system
SAP sapmnt Lämplig Alla system
Lagring för säkerhetskopior Lämplig För kortsiktig lagring av säkerhetskopior
Resurser/delad disk Inte tillgängliga Behöver Azure Premium Files eller Azure NetApp Files
Motståndskraft LRS Ingen GRS eller ZRS tillgänglig för diskar
Svarstid undermillisecond -
Serviceavtal för IOPS Ja -
IOPS linjär till kapacitet semi linjär Priser för hanterade diskar
Maximalt IOPS per disk 80 000 beroende av diskstorlek Överväg även VM-gränser
SLA för dataflöde Ja -
Dataflöde linjärt till kapacitet Semi linjär Priser för hanterade diskar
HANA-certifierad Ja -
Stöd för Azure Write Accelerator Inga -
Diskutvidgning Inga -
Möjliga diskögonblicksbilder Inga -
Azure Backup VM-ögonblicksbilder är möjliga Inga -
Kostnader Medium -

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:

Kapacitet Kommentar Anteckningar/länkar
Os-bas-VHD Fungerar inte -
Datadisk Lämplig Alla system
GLOBAL SAP-transportkatalog Ja Stöds
SAP sapmnt Lämplig Alla system
Lagring för säkerhetskopior Lämplig För kortsiktig lagring av säkerhetskopior
Resurser/delad disk Inte tillgängliga Behöver tredje part
Motståndskraft LRS Ingen GRS eller ZRS tillgänglig för diskar
Svarstid Mycket låg -
Serviceavtal för IOPS Ja -
IOPS linjär till kapacitet Semi linjär inom hakparenteser Priser för hanterade diskar
Maximalt IOPS per disk 1 200 till 160 000 beroende av diskkapacitet
SLA för dataflöde Ja -
Dataflöde linjärt till kapacitet Semi linjär inom hakparenteser Priser för hanterade diskar
HANA-certifierad Ja -
Stöd för Azure Write Accelerator Inga -
Diskutvidgning Inga -
Möjliga diskögonblicksbilder Inga -
Azure Backup VM-ögonblicksbilder är möjliga Inga -
Kostnader Högre än Premium Storage -

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). Ultradisk stöder inte ögonblicksbilder av lagring. 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-filer (ANF)

Azure NetApp Files är resultatet av samarbetet mellan Microsoft och NetApp med målet att tillhandahålla högpresterande azure-interna NFS- och SMB-resurser. Betoningen är att tillhandahålla lagring med hög bandbredd och låg svarstid som möjliggör DBMS-distributionsscenarier och med tiden möjliggör typiska driftsfunktioner för NetApp Storage via Azure. NFS/SMB-resurser erbjuds i tre olika tjänstnivåer som skiljer sig åt i lagringsdataflödet och i priset. Tjänstnivåerna dokumenteras i artikeln Tjänstnivåer för Azure NetApp Files. För de olika typerna av SAP-arbetsbelastningar rekommenderas följande tjänstnivåer starkt:

  • SAP DBMS-arbetsbelastning: Prestanda, helst Ultra
  • SAPMNT-resurs: Prestanda, helst Ultra
  • Global transportkatalog: Prestanda, helst Ultra

Kommentar

Den minsta etableringsstorleken är en 4 TiB-enhet som kallas kapacitetspool. Sedan skapar du volymer ur den här kapacitetspoolen. Medan den minsta volymen du kan skapa är 100 GiB. Du kan expandera en kapacitetspool i TiB-steg. Priser finns i artikeln priser för Azure NetApp Files

ANF-lagring stöds för närvarande för flera SAP-arbetsbelastningsscenarier:

Kommentar

Hittills stöds inga DBMS-arbetsbelastningar på SMB baserat på Azure NetApp Files.

Som redan med Azure Premium Storage kan en fast eller linjär dataflödesstorlek per GB vara ett problem när du måste följa vissa miniminummer i dataflödet. Så här är fallet för SAP HANA. Med ANF kan det här problemet bli mer uttalat än med Azure Premium-disken. Med Azure Premium-disk kan du ta flera mindre diskar med ett relativt högt dataflöde per GiB och stripe över dem för att vara kostnadseffektiva och ha högre dataflöde med lägre kapacitet. Den här typen av striping fungerar inte för NFS- eller SMB-resurser som finns på ANF. Den här begränsningen resulterade i distribution av överkapacitet som:

  • För att till exempel uppnå ett dataflöde på 250 MiB/sek på en NFS-volym som finns på ANF måste du distribuera 1,95 TiB-kapacitet på Ultra-tjänstnivån.
  • För att uppnå 400 MiB/s behöver du distribuera 3.125 TiB-kapacitet. Men du kan behöva överetablering av kapaciteten för att uppnå det dataflöde som du behöver för volymen. Den här överetablering av kapaciteten påverkar prissättningen för mindre HANA-instanser.
  • Med NFS ovanpå ANF för KATALOGEN SAP /sapmnt går du vanligtvis långt med den minsta kapaciteten på 100 GiB till 150 GiB som tillämpas av Azure NetApp Files. Kundupplevelsen visade dock att det relaterade dataflödet på 12,8 MiB/s (med ultratjänstnivå) kanske inte räcker och kan ha en negativ inverkan på SAP-systemets stabilitet. I sådana fall kan kunder undvika problem genom att öka volymen för /sapmnt-volymen, så att mer dataflöde ges till volymen.

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

Kapacitet Kommentar Anteckningar/länkar
Os-bas-VHD Fungerar inte -
Datadisk Lämplig SAP HANA, Oracle på Oracle Linux, Db2 och SAP ASE på SLES/RHEL
GLOBAL SAP-transportkatalog Ja SMB och NFS
SAP sapmnt Lämplig Alla system SMB (endast Windows) eller NFS (endast Linux)
Lagring för säkerhetskopior Lämplig -
Resurser/delad disk Ja SMB 3.0, NFS v3 och NFS v4.1
Motståndskraft LRS och GRS GRS tillgängligt
Svarstid Mycket låg -
Serviceavtal för IOPS Ja -
IOPS linjär till kapacitet strikt linjär Beroende på tjänstnivå
SLA för dataflöde Ja -
Dataflöde linjärt till kapacitet Linjär Beroende på tjänstnivå
HANA-certifierad Ja -
Möjliga diskögonblicksbilder Ja -
Azure Backup VM-ögonblicksbilder är möjliga Inga -
Kostnader Högre än Premium Storage -

Andra inbyggda funktioner i ANF-lagring:

Viktigt!

Specifikt för databasdistributioner vill du uppnå låga svarstider för åtminstone dina omgjorda loggar. Särskilt för SAP HANA kräver SAP en svarstid på mindre än 1 millisekunder för HANA-omloggskrivningar av mindre storlekar. För att komma till sådana svarstider, se möjligheterna nedan.

Viktigt!

Även för icke-DBMS-användning bör du använda förhandsgranskningsfunktionen som gör att du kan skapa NFS-resursen i samma Azure-Tillgänglighetszoner som du placerade dina virtuella datorer som ska montera NFS-resurserna i. Den här funktionen finns dokumenterad i artikeln Hantera volymplacering i tillgänglighetszonen för Azure NetApp Files. Motivationen att ha den här typen av tillgänglighetszonjustering är att minska riskytan genom att ha NFS-resurserna ännu i en annan AvZone där du inte kör virtuella datorer i.

  • Du går till närmaste närhet mellan den virtuella datorn och NFS-resursen som kan ordnas med hjälp av programvolymgrupper. Fördelen med programvolymgrupper är att dina olika NFS-resurser för SAP HANA-distributioner distribueras över olika kontrollanter i Azure NetApp Files-serverdelskluster, förutom att allokera bästa närhet och med den lägsta svarstiden. Nackdelen med den här metoden är att du måste gå igenom en pinningsprocess igen. En process som slutar begränsa distributionen av den virtuella datorn till ett enda datacenter. I stället för en Tillgänglighetszoner som den första metoden introducerades. Det innebär mindre flexibilitet när det gäller att ändra VM-storlekar och VM-familjer för de virtuella datorer som har NFS-volymerna monterade.
  • Aktuell process för att inte använda tillgänglighetsplaceringsgrupper. Som hittills endast är tillgängliga för SAP HANA. Den här processen använder också samma manuella fästningsprocess som för tillgänglighetsvolymgrupper. Den här metoden är den metod som använts under de senaste tre åren. Den har samma flexibilitetsbegränsningar som processen har med tillgänglighetsvolymgrupper.

Som inställningar för att allokera NFS-volymer baserat på ANF för databasspecifik användning bör du försöka allokera NFS-volymen i samma zon som den virtuella datorn först. Särskilt för icke-HANA-databaser. Endast om svarstiden visar sig vara otillräcklig bör du gå igenom en manuell pinningsprocess. För mindre HANA-arbetsbelastningar eller icke-produktions-HANA-arbetsbelastningar bör du också följa en zonallokeringsmetod. Endast i de fall där prestanda och svarstid inte räcker bör du använda programvolymgrupper.

Sammanfattning: Azure NetApp Files är en HANA-certifierad lagring med låg svarstid som gör det möjligt att distribuera NFS- och SMB-volymer eller resurser. Lagringen levereras med tre olika tjänstnivåer som ger olika dataflöde och IOPS linjärt per GiB-kapacitet på volymen. ANF-lagringen gör det möjligt att distribuera SAP HANA-utskalningsscenarier med en väntelägesnod. Lagringen är lämplig för att tillhandahålla filresurser efter behov för den globala transportkatalogen /sapmnt eller SAP. ANF-lagring levereras med funktionstillgänglighet som är tillgänglig som inbyggd NetApp-funktion.

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.

Kommentar

Hittills stöds inga SAP DBMS-arbetsbelastningar på delade volymer baserat på Azure Premium Files.

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

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:

Kapacitet Kommentar Anteckningar/länkar
Os-bas-VHD Fungerar inte -
Datadisk Stöds inte för SAP-arbetsbelastningar -
GLOBAL SAP-transportkatalog Ja SMB och NFS
SAP sapmnt Lämplig Alla system SMB (endast Windows) eller NFS (endast Linux)
Lagring för säkerhetskopior Lämplig -
Resurser/delad disk Ja SMB 3.0, NFS v4.1
Motståndskraft LRS och ZRS Ingen GRS tillgänglig för Azure Premium Files
Svarstid Låg -
Serviceavtal för IOPS Ja -
IOPS linjär till kapacitet strikt linjär -
SLA för dataflöde Ja -
Dataflöde linjärt till kapacitet strikt linjär -
HANA-certifierad Inga -
Möjliga diskögonblicksbilder Inga -
Azure Backup VM-ögonblicksbilder är möjliga Inga -
Kostnader Låg -

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 i produktion och som har låga krav på IOPS och dataflöde. Funktionsmatrisen för SAP-arbetsbelastningen ser ut så här:

Kapacitet Kommentar Anteckningar/länkar
Os-bas-VHD Begränsad lämplig Icke-produktionssystem
Datadisk Begränsad lämplig Vissa icke-produktionssystem med låg IOPS- och svarstidskrav
GLOBAL SAP-transportkatalog Inga Stöds ej
SAP sapmnt Begränsad lämplig Icke-produktionssystem
Lagring för säkerhetskopior Lämplig -
Resurser/delad disk Inte tillgängliga Behöver tredje part
Motståndskraft LRS, GRS Ingen ZRS tillgänglig för diskar
Svarstid Hög För högt för SAP Global Transport-katalog eller produktionssystem
Serviceavtal för IOPS Inga -
Maximalt IOPS per disk 500 Oberoende av diskens storlek
SLA för dataflöde Inga -
HANA-certifierad Inga -
Möjliga diskögonblicksbilder Ja -
Azure Backup VM-ögonblicksbilder är möjliga Ja -
Kostnader LÅG -

Sammanfattning: Azure Standard SSD-lagring är den minsta rekommendationen för virtuella datorer som inte är produktionsbaserade 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:

Kapacitet Kommentar Anteckningar/länkar
Os-bas-VHD Inte lämplig -
Datadisk Inte lämplig -
GLOBAL SAP-transportkatalog Inga Stöds ej
SAP sapmnt NEJ Stöds inte
Lagring för säkerhetskopior Lämplig -
Resurser/delad disk Inte tillgängliga Behöver Azure Files eller tredje part
Motståndskraft LRS, GRS Ingen ZRS tillgänglig för diskar
Svarstid Hög För hög för DBMS-användning, SAP Global Transport-katalog eller sapmnt/saploc
Serviceavtal för IOPS Inga -
Maximalt IOPS per disk 500 Oberoende av diskens storlek
SLA för dataflöde Inga -
HANA-certifierad Inga -
Möjliga diskögonblicksbilder Ja -
Azure Backup VM-ögonblicksbilder är möjliga Ja -
Kostnader Lägst -

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:

Lagringstyp Linux Windows Kommentarer
Standard HDD Storlekar för virtuella Linux-datorer i Azure Storlekar för virtuella Windows-datorer i Azure Sannolikt svårt att röra lagringsgränserna för medelstora eller stora virtuella datorer
Standard SSD Storlekar för virtuella Linux-datorer i Azure Storlekar för virtuella Windows-datorer i Azure Sannolikt svårt att röra lagringsgränserna för medelstora eller stora virtuella datorer
Premium Storage Storlekar för virtuella Linux-datorer i Azure Storlekar för virtuella Windows-datorer i Azure Lätt att nå IOPS- eller lagringsdataflödesgränser för virtuella datorer med lagringskonfiguration
Premium SSD v2 Storlekar för virtuella Linux-datorer i Azure Storlekar för virtuella Windows-datorer i Azure Lätt att nå IOPS- eller lagringsdataflödesgränser för virtuella datorer med lagringskonfiguration
Ultradisklagring Storlekar för virtuella Linux-datorer i Azure Storlekar för virtuella Windows-datorer i Azure Lätt att nå IOPS- eller lagringsdataflödesgränser för virtuella datorer med lagringskonfiguration
Azure NetApp Files Storlekar för virtuella Linux-datorer i Azure Storlekar för virtuella Windows-datorer i Azure Lagringstrafiken använder bandbredd för nätverksdataflöde och inte lagringsbandbredd!
Azure Premium Files Storlekar för virtuella Linux-datorer i Azure Storlekar för virtuella Windows-datorer i Azure Lagringstrafiken använder bandbredd för nätverksdataflöde och inte lagringsbandbredd!

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 ANF. 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 ANF 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 lagring på den virtuella datorn ska användas eftersom Azure Storage redan håller dataredundanta
  • 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: