Lagringskonfigurationer för virtuella Azure-datorer för SAP HANA
Azure tillhandahåller olika typer av lagring som är lämpliga för virtuella Azure-datorer som kör SAP HANA. De SAP HANA azure-lagringstyper som kan övervägas för SAP HANA distributionslista som:
- Azure Premium SSD eller Premium Storage
- Ultradisk
- Azure NetApp Files
Mer information om dessa disktyper finns i artikeln Azure Storage för SAP-arbetsbelastning och Välj en disktyp
Azure erbjuder två distributionsmetoder för virtuella hårddiskar på Azure Standard och Premium Storage. Vi förväntar oss att du använder azure-hanterade diskar för blocklagringsdistributioner i Azure.
En lista över lagringstyper och deras serviceavtal i IOPS och lagringsgenomflöde finns i Azure-dokumentationen för hanterade diskar.
Viktigt
Oberoende av vilken Azure-lagringstyp som valts måste filsystemet som används på lagringen stödjas av SAP för det specifika operativsystemet och DBMS. I SAP-supportanteckningen #2972496 listas de filsystem som stöds för olika operativsystem och databaser, inklusive SAP HANA. Detta gäller för alla volymer SAP HANA kan komma åt för läsning och skrivning för vilken uppgift som helst. Ytterligare begränsningar för NFS-versioner SAP HANA NFS-versioner som anges senare i den här artikeln är specifika för användning av NFS på Azure för SAP HANA.
De minsta SAP HANA certifierade villkoren för de olika lagringstyperna är:
- Azure Premium Storage – /hana/log måste stödjas av Azure Skrivningsaccelerator. /hana/datavolymen kan placeras på premiumlagring utan Azure Skrivningsaccelerator eller på Ultra-disk
- Azure Ultra-disk minst för /hana/log-volymen. /hana/data-volymen kan antingen placeras på premiumlagring utan Azure Skrivningsaccelerator eller för att få snabbare omstartstider för Ultra-disk
- NFS v4.1-volymer ovanpå Azure NetApp Files för /hana/log och /hana/data. Volymen /hana/shared kan använda NFS v3- eller NFS v4.1-protokoll
Vissa av lagringstyperna kan kombineras. Det är till exempel möjligt att placera /hana/data på Premium Storage och /hana/log kan placeras på Ultra-disklagring för att få den nödvändiga korta svarstiden. Om du använder en volym som baseras på ANF för /hana/data måste /hana/log-volymen även baseras på NFS ovanpå ANF. Användning av NFS ovanpå ANF för en av volymerna (t.ex. /hana/data) och Azure Premium Storage eller Ultra-disk för den andra volymen (t.ex. /hana/log) stöds inte.
I den lokala världen behövde du sällan bry dig om I/O-undersystemen och dess funktioner. Orsaken var att enhetens leverantör behövde se till att minimikraven för lagring är uppfyllda för SAP HANA. När du skapar Azure-infrastrukturen själv bör du vara medveten om några av dessa SAP-utfärdade krav. Några av de minsta dataflödesegenskaper som SAP rekommenderar är:
- Läsning/skrivning på /hana/logg på 250 MB/s med 1 MB I/O-storlekar
- Läsaktivitet på minst 400 MB/sek för /hana/data för 16 MB och 64 MB I/O-storlekar
- Skrivaktivitet på minst 250 MB/sek för /hana/data med 16 MB och 64 MB I/O-storlekar
Med tanke på att låg lagringssvarstid är kritiskt för DBMS-system, även när DBMS, SAP HANA, kan du behålla data i minnet. Den kritiska sökvägen i lagringen är vanligtvis runt skrivningar i transaktionsloggen för DBMS-systemen. Men även åtgärder som att skriva savepoints eller läsa in data i minnet efter kraschåterställning kan vara viktiga. Därför är det obligatoriskt att använda Azure Premium Storage, Ultra disk eller ANF för /hana/data- och /hana/log-volymer.
Några riktlinjer för att välja lagringskonfiguration för HANA kan visas som:
- Bestäm typen av lagring baserat på Azure Storage för SAP-arbetsbelastning och Välj en disktyp
- Det totala I/O-dataflödet för virtuella datorer och IOPS-gränser i åtanke vid storleksändring eller beslut om en virtuell dator. Det övergripande dataflödet för VM-lagring dokumenteras i artikeln Minnesoptimerade virtuella datorstorlekar
- När du bestämmer dig för lagringskonfigurationen bör du försöka hålla dig under det totala dataflödet för den virtuella datorn med din /hana/datavolymkonfiguration. Att skriva sparapunkter, SAP HANA kan vara aggressiv utfärdande av I/O. Det är enkelt att push-flytta upp till dataflödesgränserna för din /hana/datavolym när du skriver en sparpunkt. Om dina diskar som skapar /hana/datavolymen har ett högre dataflöde än vad den virtuella datorn tillåter kan du få situationer där dataflödet som används av skrivning till sparpunkt stör dataflödeskraven för att göra om loggskrivningar. En situation som kan påverka programmets dataflöde
- Om du överväger att använda HANA-systemreplikering måste du använda exakt samma typ av Azure-lagring för /hana/data och /hana/log för alla virtuella datorer som deltar i konfigurationen för HANA-systemreplikering. Till exempel stöds inte användning av Azure Premium Storage för /hana/data med en virtuell dator och Azure Ultra-disk för /hana/log på en annan virtuell dator inom samma hana-systemreplikeringskonfiguration
Viktigt
Förslagen för lagringskonfigurationerna är avsedda som anvisningar att börja med. Om du kör arbetsbelastningen och analyserar mönster för lagringsanvändning kanske du inser att du inte använder all lagringsbandbredd eller IOPS som tillhandahålls. Då kan du överväga att ändra storlek på lagringen. Eller i stället kan din arbetsbelastning behöva mer lagringsdataflöde än vad som föreslås med de här konfigurationerna. Därför kan du behöva distribuera mer kapacitet, IOPS eller dataflöde. Azure erbjuder tillräckligt med olika lagringstyper med olika funktioner och olika prispunkter för att hitta och anpassa sig till rätt kompromettering för dig och DIN HANA-arbetsbelastning.
Stripe-uppsättningar jämfört SAP HANA partitionering av datavolym
Med Azure Premium Storage kan du få det bästa pris-/prestandaförhållandet när du strimlar volymen /hana/data och/eller /hana/log över flera Azure-diskar. I stället för att distribuera större diskvolymer som ger mer information om IOPS eller dataflöde som krävs. Hittills har detta utförts med LVM- och MDADM-volymhanterare som ingår i Linux. Metoden för striping av diskar är årtionden gammal och välkänd. En fördel som de stripe-volymerna är att få till de IOPS- eller dataflödesfunktioner som du kan behöva lägger till komplexitet kring hanteringen av de stripade volymerna. Särskilt i fall när volymerna behöver utökas i kapaciteten. Sap introducerade åtminstone en alternativ metod för /hana/data som uppnår samma mål som striping över flera Azure-diskar. Eftersom SAP HANA 2.0 SPS03 kan HANA-indexservern strimlar sin I/O-aktivitet över flera HANA-datafiler som finns på olika Azure-diskar. Fördelen är att du inte behöver ta hand om att skapa och hantera en stripe-volym på olika Azure-diskar. Funktionerna SAP HANA datavolympartitionering beskrivs i detalj i:
- HANA-administratörsguiden
- Blogg om SAP HANA – partitionering av datavolymer
- SAP-anteckning #2400005
- SAP-anteckning #2700123
Genom att läsa igenom informationen är det uppenbart att den här funktionen tar bort komplexiteten i volymhanteringsbaserade stripe-uppsättningar. Du inser också att HANA-datavolympartitionering inte bara fungerar för Azure-blocklagring, som Azure Premium Storage. Du kan även använda den här funktionen för att strimlar över NFS-resurser om dessa resurser har IOPS- eller dataflödesbegränsningar.
Linux I/O Scheduler-läge
Linux har flera olika I/O-schemaläggningslägen. Vanlig rekommendation via Linux-leverantörer och SAP är att konfigurera om I/O-schemaläggarläget för diskvolymer från mq-deadline- eller kyber-läget till noop(icke-multiqueue) eller inget för (multiqueue)-läge om det inte har gjorts ännu av SLES saptune-profilerna. Information refereras till i:
På Red Hat lämnar du inställningarna som de har upprättats av de specifika finjustera profilerna för de olika SAP-programmen.
Lösningar med Premium Storage och Azure Skrivningsaccelerator för virtuella datorer i Azure M-serien
Azure Skrivningsaccelerator är en funktion som endast är tillgänglig för virtuella datorer i Azure M-serien. Som namnet säger är syftet med funktionen att förbättra I/O-svarstiden för skrivningar mot Azure Premium Storage. För SAP HANA är Skrivningsaccelerator endast användas mot volymen /hana/log. Därför är /hana/data och /hana/log separata volymer med Azure Skrivningsaccelerator endast stöd för /hana/log-volymen.
Viktigt
När du använder Azure Premium Storage är användningen av Azure Skrivningsaccelerator för /hana/log-volymen obligatorisk. Skrivningsaccelerator är endast tillgängligt för premiumlagring och M-serien och Mv2-Series virtuella datorer. Skrivningsaccelerator fungerar inte i kombination med andra Azure VM-familjer, till exempel Esv3 eller Edsv4.
Rekommendationerna för cachelagring för Azure Premium-diskar nedan förutsätter I/O-egenskaperna för SAP HANA lista som:
- 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. Att skriva data under kraschåterställning är prestandakritiskt 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 i omstartsfasen av en HANA-instans.
- Huvudinläsningen mot SAP HANA är skrivningar. Beroende på typen av arbetsbelastning kan du ha I/Os 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
Rekommendation: Som ett resultat av dessa observerade I/O-mönster från SAP HANA bör cachelagringen för de olika volymerna som använder Azure Premium Storage anges så här:
- /hana/data – ingen cachelagring eller läscachelagring
- /hana/log – ingen cachelagring – undantag för M- och Mv2-Series virtuella datorer där Azure Skrivningsaccelerator ska vara aktiverat
- /hana/shared – läsa cachelagring
- OS-disk – ändra inte standardcachelagring som anges av Azure när den virtuella datorn skapas
Om du använder LVM eller mdadm för att skapa stripe-uppsättningar över flera Azure Premium-diskar måste du definiera stripe-storlekar. Dessa storlekar skiljer sig mellan /hana/data och /hana/log. Rekommendation: Eftersom stripe-storlekar rekommendationen är att använda:
- 256 kB för /hana/data
- 64 kB för /hana/log
Anteckning
Stripe-storleken för /hana/data ändrades från tidigare rekommendationer som anropade för 64 KB eller 128 kB till 256 kB baserat på kundupplevelser med nyaRe Linux-versioner. Storleken på 256 kB ger något bättre prestanda. Vi ändrade också rekommendationen för stripe-storlekar på /hana/log från 32 kB till 64 kB för att få tillräckligt dataflöde med större I/O-storlekar.
Anteckning
Du behöver inte konfigurera någon redundansnivå med RAID-volymer eftersom Azure-blocklagring behåller tre avbildningar av en virtuell hårddisk. Användningen av en stripe-uppsättning med Azure Premium-diskar är enbart för att konfigurera volymer som ger tillräckligt med IOPS och/eller I/O-dataflöde.
Ackumulering av ett antal virtuella Azure-hårddiskar under en stripe-uppsättning är ackumulativt från en IOPS- och lagringsgenomflödessida. Så om du lägger en strimleuppsättning över 3 x P30 Azure Premium Storage-diskar bör du få tre gånger IOPS och tre gånger lagringsgenomflödet för en enda Azure Premium Storage P30-disk.
Viktigt
Om du använder LVM eller mdadm som volymhanterare för att skapa stripe-uppsättningar över flera Azure Premium-diskar får de tre SAP HANA FileSystems /data, /log och /shared inte läggas i en standard- eller rotvolymgrupp. Vi rekommenderar starkt att du följer Vägledning för Linux-leverantörer, som vanligtvis är att skapa enskilda volymgrupper för /data, /log och /shared.
Azure Burst-funktioner för Premium Storage
För Azure Premium Storage-diskar som är mindre än eller lika med 512 GiB i kapacitet erbjuds burst-funktioner. Exakt hur disk bursting fungerar beskrivs i artikeln Disk bursting. När du läser artikeln förstår du begreppet att använda IOPS och dataflöde när din I/O-arbetsbelastning är lägre än det nominella IOPS- och dataflödet för diskarna (mer information om det nominella dataflödet finns i Prissättning för hanterad disk). Du kommer att ackumulera delta i IOPS och dataflödet mellan din aktuella användning och diskens nominella värden. Burst-felen är begränsade till högst 30 minuter.
De idealiska fall där den här burst-funktionen kan planeras i är förmodligen de volymer eller diskar som innehåller datafiler för 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 när det gäller HANA bör vara helt i minnet
- Skriv burst-fel som utlöses av databaskontrollpunkter eller sparpunkter som utfärdas regelbundet
- Säkerhetskopieringsarbetsbelastning som läser i en kontinuerlig dataström i fall där säkerhetskopior inte körs via ögonblicksbilder av lagring
- För SAP HANA inläsning av data i minnet efter en omstart av instansen
Särskilt i mindre DBMS-system där din arbetsbelastning bara hanterar några hundra transaktioner per sekund, kan en sådan burst-funktion vara meningsfull 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:
- Vanliga skrivningar till disken som är beroende av arbetsbelastningen och typen av arbetsbelastning eftersom varje genomförande som utfärdats av programmet sannolikt utlöser en I/O-åtgärd
- Högre arbetsbelastning i dataflöde för driftsuppgifter, till exempel att skapa eller återskapa index
- Läs burst-fel när du utför transaktionsloggar eller gör om loggsäkerhetskopior
Rekommenderad lagringslösning för produktion baserad på Azure Premium Storage
Viktigt
SAP HANA för virtuella datorer i Azure M-serien är exklusivt med Azure Skrivningsaccelerator för /hana/log-volymen. Därför förväntas produktionsscenariot SAP HANA distributioner på virtuella datorer i Azure M-serien konfigureras med Azure Skrivningsaccelerator för /hana/log-volymen.
Anteckning
I scenarier med Azure Premium Storage implementerar vi burst-funktioner i konfigurationen. När du använder lagringstestverktyg oavsett form bör du tänka på hur Azure Premium-disk bursting fungerar. När vi kör de lagringstester som levereras via SAP HWCCT eller HCMT-verktyget förväntar vi oss inte att alla tester ska klara kriterierna eftersom vissa av testerna överskrider de burst-krediter som du kan ackumulera. Särskilt när alla tester körs sekventiellt utan avbrott.
Anteckning
Med virtuella M32ts- och M32ls-datorer kan diskgenomflödet bli lägre än förväntat med HCMT/HWCCT-disktester. Även med disk bursting eller med tillräckligt etablerat I/O-dataflöde för de underliggande diskarna. Rotorsaken till det observerade beteendet var att HCMT/HWCCT-lagringstestfilerna cachelagrades helt i cacheminnet för Premium lagringsdatadiskar. Den här cachen finns på beräkningsvärden som är värd för den virtuella datorn och kan cachelagra testfilerna för HCMT/HWCCT helt. I sådana fall är kvoter som anges i kolumnen Maximalt cachelagrat och tillfälligt lagringsgenomflöde: IOPS/MBps (cachestorlek i GiB) i artikeln M-serien relevanta. Specifikt för M32ts och M32ls är dataflödeskvoten mot läscachen bara 400 MB/s. På grund av att testfilerna cachelagras helt är det möjligt att testerna, trots disk bursting eller högre etablerat I/O-dataflöde, ligger något under det maximala dataflödet på 400 MB/sek. Alternativt kan du testa utan att ha läscache aktiverat på Azure Premium lagringsdatadiskar.
Anteckning
För produktionsscenarier kontrollerar du om en viss typ av virtuell dator stöds för SAP HANA av SAP i SAP-dokumentationen för IAAS.
Rekommendation: De rekommenderade konfigurationerna med Azure Premium Storage för produktionsscenarier ser ut så här:
Konfiguration för SAP /hana/datavolym:
| VM-SKU | RAM | Max. VM I/O Dataflöde |
/hana/data | Etablerat dataflöde | Maximalt burst-dataflöde | IOPS | Burst IOPS |
|---|---|---|---|---|---|---|---|
| M32ts | 192 GiB | 500 MBps | 4 x P6 | 200 MBps | 680 MBps | 960 | 14,000 |
| M32ls | 256 GiB | 500 MBps | 4 x P6 | 200 MBps | 680 MBps | 960 | 14,000 |
| M64ls | 512 GiB | 1 000 MBps | 4 x P10 | 400 MBps | 680 MBps | 2 000 | 14,000 |
| M32dms_v2, M32ms_v2 | 875 GiB | 500 MBps | 4 x P15 | 500 MBps | 680 MBps | 4,400 | 14,000 |
| M64s, M64ds_v2, M64s_v2 | 1 024 GiB | 1 000 MBps | 4 x P15 | 500 MBps | 680 MBps | 4,400 | 14,000 |
| M64ms, M64dms_v2, M64ms_v2 | 1 792 GiB | 1 000 MBps | 4 x P20 | 600 MBps | 680 MBps | 9,200 | 14,000 |
| M128s, M128ds_v2, M128s_v2 | 2 048 GiB | 2 000 MBps | 4 x P20 | 600 MBps | 680 MBps | 9,200 | 14,000 |
| M192ids_v2, M192is_v2 | 2 048 GiB | 2 000 MBps | 4 x P20 | 600 MBps | 680 MBps | 9,200 | 14,000 |
| M128ms, M128dms_v2, M128ms_v2 | 3 892 GiB | 2 000 MBps | 4 x P30 | 800 MBps | ingen bursting | 20 000 | ingen bursting |
| M192ims, M192idms_v2 | 4 096 GiB | 2 000 MBps | 4 x P30 | 800 MBps | ingen bursting | 20 000 | ingen bursting |
| M208s_v2 | 2 850 GiB | 1 000 MBps | 4 x P30 | 800 MBps | ingen bursting | 20 000 | ingen bursting |
| M208ms_v2 | 5 700 GiB | 1 000 MBps | 4 x P40 | 1 000 MBps | ingen bursting | 30,000 | ingen bursting |
| M416s_v2 | 5 700 GiB | 2 000 MBps | 4 x P40 | 1 000 MBps | ingen bursting | 30,000 | ingen bursting |
| M416ms_v2 | 11 400 GiB | 2 000 MBps | 4 x P50 | 1 000 MBps | ingen bursting | 30,000 | ingen bursting |
För /hana/log-volymen. konfigurationen skulle se ut så här:
| VM-SKU | RAM | Max. VM I/O Dataflöde |
/hana/log volume | Etablerat dataflöde | Maximalt burst-dataflöde | IOPS | Burst IOPS |
|---|---|---|---|---|---|---|---|
| M32ts | 192 GiB | 500 MBps | 3 x P10 | 300 MBps | 510 MBps | 1500 | 10,500 |
| M32ls | 256 GiB | 500 MBps | 3 x P10 | 300 MBps | 510 MBps | 1500 | 10,500 |
| M64ls | 512 GiB | 1 000 MBps | 3 x P10 | 300 MBps | 510 MBps | 1500 | 10,500 |
| M32dms_v2, M32ms_v2 | 875 GiB | 500 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M64s, M64ds_v2, M64s_v2 | 1 024 GiB | 1 000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M64ms, M64dms_v2, M64ms_v2 | 1 792 GiB | 1 000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M128s, M128ds_v2, M128s_v2 | 2 048 GiB | 2 000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M192ids_v2, M192is_v2 | 2 048 GiB | 2 000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M128ms, M128dms_v2, M128ms_v2 | 3 892 GiB | 2 000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M192idms_v2, M192ims_v2 | 4 096 GiB | 2 000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M208s_v2 | 2 850 GiB | 1 000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M208ms_v2 | 5 700 GiB | 1 000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M416s_v2 | 5 700 GiB | 2 000 MBps | 3 x P15 | 375 MBps | 510 MBps | 3,300 | 10,500 |
| M416ms_v2 | 11 400 GiB | 2 000 MBps | 3 x P15 | 375 M/s | 510 M/s | 3,300 | 10,500 |
För de andra volymerna skulle konfigurationen se ut så här:
| VM-SKU | RAM | Max. I/O för virtuell dator Dataflöde |
/hana/shared | /root volume | /usr/sap |
|---|---|---|---|---|---|
| M32ts | 192 GiB | 500 M/s | 1 x P15 | 1 x P6 | 1 x P6 |
| M32ls | 256 GiB | 500 M/s | 1 x P15 | 1 x P6 | 1 x P6 |
| M64ls | 512 GiB | 1 000 M/s | 1 x P20 | 1 x P6 | 1 x P6 |
| M32dms_v2, M32ms_v2 | 875 GiB | 500 M/s | 1 x P30 | 1 x P6 | 1 x P6 |
| M64s, M64ds_v2, M64s_v2 | 1 024 GiB | 1 000 M/s | 1 x P30 | 1 x P6 | 1 x P6 |
| M64ms, M64dms_v2, M64ms_v2 | 1 792 GiB | 1 000 M/s | 1 x P30 | 1 x P6 | 1 x P6 |
| M128s, M128ds_v2, M128s_v2 | 2 048 GiB | 2 000 M/s | 1 x P30 | 1 x P10 | 1 x P6 |
| M192ids_v2, M192is_v2 | 2 048 GiB | 2 000 M/s | 1 x P30 | 1 x P10 | 1 x P6 |
| M128ms, M128dms_v2, M128ms_v2 | 3 892 GiB | 2 000 M/s | 1 x P30 | 1 x P10 | 1 x P6 |
| M192idms_v2, M192ims_v2 | 4 096 GiB | 2 000 M/s | 1 x P30 | 1 x P10 | 1 x P6 |
| M208s_v2 | 2 850 GiB | 1 000 M/s | 1 x P30 | 1 x P10 | 1 x P6 |
| M208ms_v2 | 5 700 GiB | 1 000 M/s | 1 x P30 | 1 x P10 | 1 x P6 |
| M416s_v2 | 5 700 GiB | 2 000 M/s | 1 x P30 | 1 x P10 | 1 x P6 |
| M416ms_v2 | 11 400 GiB | 2 000 M/s | 1 x P30 | 1 x P10 | 1 x P6 |
Kontrollera om lagringens dataflöde för de olika föreslagna volymerna uppfyller den arbetsbelastning som du vill köra. Om arbetsbelastningen kräver högre volymer för /hana/data och /hana/log måste du öka antalet virtuella hårddiskar för Azure Premium Storage. Genom att ändra storlek på en volym med fler virtuella hårddiskar än vad som anges i listan ökar IOPS- och I/O-dataflödet inom gränserna för typen av virtuell Azure-dator.
Azure Skrivningsaccelerator fungerar bara med Azure Managed Disks. Därför måste åtminstone Azure Premium Storage-diskarna som utgör /hana/log-volymen distribueras som hanterade diskar. Mer detaljerade anvisningar och begränsningar för Azure Skrivningsaccelerator finns i artikeln Skrivningsaccelerator.
För DE HANA-certifierade virtuella datorerna i Azure Esv3-familjen och Edsv4behöver du ANF för volymen /hana/data och /hana/log. Eller så behöver du bara använda Azure Ultra-disklagring i stället för Azure Premium Storage för /hana/log-volymen. Därför kan konfigurationerna för /hana/data-volymen på Azure Premium Storage se ut så här:
| VM-SKU | RAM | Max. I/O för virtuell dator Dataflöde |
/hana/data | Etablerat dataflöde | Maximalt burst-dataflöde | IOPS | Burst-IOPS |
|---|---|---|---|---|---|---|---|
| E20ds_v4 | 160 GiB | 480 M/s | 3 x P10 | 300 M/s | 510 M/s | 1500 | 10,500 |
| E32ds_v4 | 256 GiB | 768 M/s | 3 x P10 | 300 M/s | 510 M/s | 1500 | 10,500 |
| E48ds_v4 | 384 GiB | 1 152 M/s | 3 x P15 | 375 M/s | 510 M/s | 3,300 | 10,500 |
| E64ds_v4 | 504 GiB | 1 200 M/s | 3 x P15 | 375 M/s | 510 M/s | 3,300 | 10,500 |
| E64s_v3 | 432 GiB | 1 200 MB/s | 3 x P15 | 375 M/s | 510 M/s | 3,300 | 10,500 |
För de andra volymerna, inklusive /hana/log på Ultra-disken, kan konfigurationen se ut så här:
| VM-SKU | RAM | Max. I/O för virtuell dator Dataflöde |
/hana/loggvolym | /hana/log I/O-dataflöde | /hana/log IOPS | /hana/shared | /root volume | /usr/sap |
|---|---|---|---|---|---|---|---|---|
| E20ds_v4 | 160 GiB | 480 M/s | 80 GB | 250 M/s | 1800 | 1 x P15 | 1 x P6 | 1 x P6 |
| E32ds_v4 | 256 GiB | 768 M/s | 128 GB | 250 M/s | 1800 | 1 x P15 | 1 x P6 | 1 x P6 |
| E48ds_v4 | 384 GiB | 1 152 M/s | 192 GB | 250 M/s | 1800 | 1 x P20 | 1 x P6 | 1 x P6 |
| E64ds_v4 | 504 GiB | 1 200 M/s | 256 GB | 250 M/s | 1800 | 1 x P20 | 1 x P6 | 1 x P6 |
| E64s_v3 | 432 GiB | 1 200 MBps | 220 GB | 250 MBps | 1800 | 1 x P20 | 1 x P6 | 1 x P6 |
Azure Ultra Disk Storage-konfiguration för SAP HANA
En annan Typ av Azure-lagring kallas Azure Ultra-disk. Den stora skillnaden mellan Azure Storage som erbjuds hittills och Ultra disk är att diskfunktionerna inte längre är bundna till diskstorleken. Som kund kan du definiera dessa funktioner för Ultra-disk:
- Storleken på en disk mellan 4 GiB och 65 536 GiB
- IOPS sträcker sig från 100 IOPS till 160 000 IOPS (högst beroende av VM-typer också)
- Storage dataflöde från 300 MB/sek till 2 000 MB/sek
Ultradisk 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 köra en konfigurationsblandning mellan Ultra-disk och Premium-lagring. Därför kan du begränsa användningen av Ultra-diskar till de prestandakritiska /hana/data- och /hana/log-volymerna och täcka de andra volymerna med Azure Premium Storage
Andra fördelar med Ultra-diskar kan vara en bättre läsfördröjning jämfört med Premium Storage. Ju snabbare svarstid för läsning kan ha fördelar när du vill minska HANA-starttiderna och den efterföljande inläsningen av data i minnet. Fördelarna med Ultra Disk Storage kan också kännas när HANA skriver lagringspunkter.
Anteckning
Ultradisken finns ännu inte i alla Azure-regioner och har ännu inte stöd för alla typer av virtuella datorer som anges nedan. Detaljerad information om var Ultra-disken är tillgänglig och vilka VM-familjer som stöds finns i artikeln Vilka disktyper är tillgängliga i Azure?.
Rekommenderad lagringslösning för produktion med ren Ultra-diskkonfiguration
I den här konfigurationen behåller du volymerna /hana/data och /hana/log separat. De föreslagna värdena härleds från KPI:er som SAP måste certifiera VM-typer för SAP HANA- och lagringskonfigurationer enligt rekommendationer i SAP TDI-Storage whitepaper.
Rekommendationerna överskrider ofta minimikraven för SAP som angavs tidigare i den här artikeln. De angivna rekommendationerna är en kompromiss mellan storleksrekommendationerna från SAP och det maximala lagringsgenomflödet som de olika typerna av virtuella datorer tillhandahåller.
Anteckning
Azure Ultra-disken framtvingar minst 2 IOPS per Gigabyte-kapacitet för en disk
| VM-SKU | RAM | Max. VM I/O Dataflöde |
/hana/datavolym | /hana/data-I/O-dataflöde | /hana/data IOPS | /hana/loggvolym | /hana/log I/O-dataflöde | /hana/log IOPS |
|---|---|---|---|---|---|---|---|---|
| E20ds_v4 | 160 GiB | 480 MB/s | 200 GB | 400 MBps | 2 500 | 80 GB | 250 MB | 1800 |
| E32ds_v4 | 256 GiB | 768 MB/s | 300 GB | 400 MBps | 2 500 | 128 GB | 250 MBps | 1800 |
| E48ds_v4 | 384 GiB | 1152 MB/s | 460 GB | 400 MBps | 3 000 | 192 GB | 250 MBps | 1800 |
| E64ds_v4 | 504 GiB | 1 200 MB/s | 610 GB | 400 MBps | 3 500 | 256 GB | 250 MBps | 1800 |
| E64s_v3 | 432 GiB | 1 200 MB/s | 610 GB | 400 MBps | 3 500 | 220 GB | 250 MB | 1800 |
| M32ts | 192 GiB | 500 MB/s | 250 GB | 400 MBps | 2 500 | 96 GB | 250 MBps | 1800 |
| M32ls | 256 GiB | 500 MB/s | 300 GB | 400 M/s | 2 500 | 256 GB | 250 M/s | 1800 |
| M64ls | 512 GiB | 1 000 MB/s | 620 GB | 400 M/s | 3 500 | 256 GB | 250 M/s | 1800 |
| M32dms_v2, M32ms_v2 | 875 GiB | 500 MB/s | 1 200 GB | 600 M/s | 5 000 | 512 GB | 250 M/s | 2 500 |
| M64s, M64ds_v2, M64s_v2 | 1 024 GiB | 1 000 MB/s | 1 200 GB | 600 M/s | 5 000 | 512 GB | 250 M/s | 2 500 |
| M64ms, M64dms_v2, M64ms_v2 | 1 792 GiB | 1 000 MB/s | 2 100 GB | 600 M/s | 5 000 | 512 GB | 250 M/s | 2 500 |
| M128s, M128ds_v2, M128s_v2 | 2 048 GiB | 2 000 MB/s | 2 400 GB | 750 M/s | 7,000 | 512 GB | 250 M/s | 2 500 |
| M192ids_v2, M192is_v2 | 2 048 GiB | 2 000 MB/s | 2 400 GB | 750 M/s | 7,000 | 512 GB | 250 M/s | 2 500 |
| M128ms, M128dms_v2, M128ms_v2 | 3 892 GiB | 2 000 MB/s | 4 800 GB | 750 M/s | 9 600 | 512 GB | 250 M/s | 2 500 |
| M192idms_v2, M192ims_v2 | 4 096 GiB | 2 000 MB/s | 4 800 GB | 750 M/s | 9 600 | 512 GB | 250 M/s | 2 500 |
| M208s_v2 | 2 850 GiB | 1 000 MB/s | 3 500 GB | 750 M/s | 7,000 | 512 GB | 250 M/s | 2 500 |
| M208ms_v2 | 5 700 GiB | 1 000 MB/s | 7 200 GB | 750 M/s | 14,400 | 512 GB | 250 M/s | 2 500 |
| M416s_v2 | 5 700 GiB | 2 000 MB/s | 7 200 GB | 1 000 MBps | 14,400 | 512 GB | 400 MBps | 4 000 |
| M416ms_v2 | 11 400 GiB | 2 000 MB/s | 14 400 GB | 1 500 MBps | 28,800 | 512 GB | 400 MBps | 4 000 |
De värden som anges är avsedda att vara en startpunkt och måste utvärderas mot de verkliga kraven. Fördelen med Azure Ultra-disken är att värdena för IOPS och dataflöde kan anpassas utan att du behöver stänga av den virtuella datorn eller stoppa arbetsbelastningen som tillämpas på systemet.
Anteckning
Hittills är lagringsögonblicksbilder med Ultra-disklagring inte tillgängliga. Detta blockerar användningen av ögonblicksbilder av virtuella datorer med Azure Backup Services
NFS v4.1-volymer på Azure NetApp Files
Mer information om ANF för HANA finns i dokumentet NFS v4.1-volymer på Azure NetApp Files för SAP HANA
Kostnadsmedveten lösning med Azure Premium Storage
Hittills har Azure Premium Storage-lösningen som beskrivs i det här dokumentet i avsnittet Lösningar med Premium Storage och Azure Skrivningsaccelerator för virtuella datorer i Azure M-serien SAP HANA produktionsscenarier som stöds. En av egenskaperna hos produktionskonfigurationer som kan stödjas är uppdelningen av volymerna för SAP HANA data och gör om loggen till två olika volymer. Orsaken till en sådan separation är att arbetsbelastningens egenskaper på volymerna skiljer sig åt. Och med de föreslagna produktionskonfigurationerna kan olika typer av cachelagring eller till och med olika typer av Azure-blocklagring vara nödvändiga. För icke-produktionsscenarier kanske vissa av de överväganden som vidtas för produktionssystem inte gäller för mer system med låg slut än produktion. Det innebär att HANA-data och loggvolym kan kombineras. Även om det så småningom kan leda till vissa problem, som att till slut inte uppfylla vissa KPI:er för dataflöde eller svarstider som krävs för produktionssystem. En annan aspekt för att minska kostnaderna i sådana miljöer kan vara användningen av Azure Standard SSD storage. Tänk på att valet av Standard SSD eller Standard HDD Azure Storage påverkar dina enskilda SERVICEavtal för virtuella datorer enligt dokumenten i artikeln serviceavtal för Virtual Machines.
Ett billigare alternativ för sådana konfigurationer kan se ut så här:
| VM-SKU | RAM | Max. VM I/O Dataflöde |
/hana/data och /hana/log striped med LVM eller MDADM |
/hana/shared | /root volume | /usr/sap | kommentarer |
|---|---|---|---|---|---|---|---|
| DS14v2 | 112 GiB | 768 MB/s | 4 x P6 | 1 x E10 | 1 x E6 | 1 x E6 | Uppnår inte mindre än 1 ms lagringssvarstid1 |
| E16v3 | 128 GiB | 384 MB/s | 4 x P6 | 1 x E10 | 1 x E6 | 1 x E6 | VM-typen är inte HANA-certifierad Uppnår inte mindre än 1 ms lagringssvarstid1 |
| M32ts | 192 GiB | 500 MB/s | 3 x P10 | 1 x E15 | 1 x E6 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolymer begränsar du IOPS-hastigheten till 5 0002 |
| E20ds_v4 | 160 GiB | 480 MB/s | 4 x P6 | 1 x E15 | 1 x E6 | 1 x E6 | Uppnår inte mindre än 1 ms lagringssvarstid1 |
| E32v3 | 256 GiB | 768 MB/s | 4 x P10 | 1 x E15 | 1 x E6 | 1 x E6 | VM-typen är inte HANA-certifierad Uppnår inte mindre än 1 ms lagringssvarstid1 |
| E32ds_v4 | 256 GiB | 768 MBps | 4 x P10 | 1 x E15 | 1 x E6 | 1 x E6 | Uppnår inte mindre än 1 ms lagringssvarstid1 |
| M32ls | 256 GiB | 500 MB/s | 4 x P10 | 1 x E15 | 1 x E6 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolymer begränsar du IOPS-hastigheten till 5 0002 |
| E48ds_v4 | 384 GiB | 1 152 M/s | 6 x P10 | 1 x E20 | 1 x E6 | 1 x E6 | Uppnår inte mindre än 1 ms lagringssvarstid1 |
| E64v3 | 432 GiB | 1 200 MB/s | 6 x P10 | 1 x E20 | 1 x E6 | 1 x E6 | Uppnår inte mindre än 1 ms lagringssvarstid1 |
| E64ds_v4 | 504 GiB | 1 200 MB/s | 7 x P10 | 1 x E20 | 1 x E6 | 1 x E6 | Uppnår inte mindre än 1 ms lagringssvarstid1 |
| M64ls | 512 GiB | 1 000 MB/s | 7 x P10 | 1 x E20 | 1 x E6 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolymer begränsar du IOPS-hastigheten till 10 0002 |
| M32dms_v2, M32ms_v2 | 875 GiB | 500 MB/s | 6 x P15 | 1 x E30 | 1 x E6 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolymer begränsar du IOPS-hastigheten till 5 0002 |
| M64s, M64ds_v2, M64s_v2 | 1 024 GiB | 1 000 MB/s | 7 x P15 | 1 x E30 | 1 x E6 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolymer begränsar du IOPS-hastigheten till 10 0002 |
| M64ms, M64dms_v2, M64ms_v2 | 1 792 GiB | 1 000 MB/s | 6 x P20 | 1 x E30 | 1 x E6 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolymer begränsar du IOPS-hastigheten till 10 0002 |
| M128s, M128ds_v2, M128s_v2 | 2 048 GiB | 2 000 MB/s | 6 x P20 | 1 x E30 | 1 x E10 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolym begränsar du IOPS-hastigheten till 20 0002 |
| M192ids_v2, M192is_v2 | 2 048 GiB | 2 000 MB/s | 6 x P20 | 1 x E30 | 1 x E10 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolym begränsar du IOPS-hastigheten till 20 0002 |
| M128ms, M128dms_v2, M128ms_v2 | 3 800 GiB | 2 000 MB/s | 5 x P30 | 1 x E30 | 1 x E10 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolym begränsar du IOPS-hastigheten till 20 0002 |
| M192idms_v2, M192ims_v2 | 4 096 GiB | 2 000 MB/s | 5 x P30 | 1 x E30 | 1 x E10 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolym begränsar du IOPS-hastigheten till 20 0002 |
| M208s_v2 | 2 850 GiB | 1 000 MB/s | 4 x P30 | 1 x E30 | 1 x E10 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolymer begränsar du IOPS-hastigheten till 10 0002 |
| M208ms_v2 | 5 700 GiB | 1 000 MB/s | 4 x P40 | 1 x E30 | 1 x E10 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolymer begränsar du IOPS-hastigheten till 10 0002 |
| M416s_v2 | 5 700 GiB | 2 000 MB/s | 4 x P40 | 1 x E30 | 1 x E10 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolymer begränsar du IOPS-hastigheten till 20 0002 |
| M416ms_v2 | 11400 GiB | 2 000 MB/s | 7 x P40 | 1 x E30 | 1 x E10 | 1 x E6 | Om Skrivningsaccelerator för kombinerade data och loggvolymer begränsar du IOPS-hastigheten till 20 0002 |
1 Azure Skrivningsaccelerator kan inte användas med familjerna Ev4 och Ev4. När du använder Azure Premium Storage blir I/O-svarstiden inte mindre än 1 ms
2 VM-serien stöder Azure Skrivningsaccelerator, men det finns en risk att IOPS-gränsen för skrivningsacceleratorn kan begränsa diskkonfigurationens IOPS-funktioner
Om du kombinerar data- och loggvolymen för en SAP HANA diskarna som skapar den stripe volymen inte ha läscache eller läs-/skrivcache aktiverat.
Det finns vm-typer listade som inte är certifierade med SAP och därför inte visas i den så kallade SAP HANA maskinvarukatalogen. Feedback från kunder var att dessa icke-listade VM-typer användes korrekt för vissa icke-produktionsaktiviteter.
Nästa steg
Mer information finns i: