Lagringskonfigurationer för virtuella Azure-datorer för SAP HANA

  • Artikel

Azure tillhandahåller olika typer av lagring som är lämpliga för virtuella Azure-datorer som kör SAP HANA. Den SAP HANA-certifierade Azure-lagringstypen som kan beaktas för SAP HANA-distributionslistan, till exempel:

Mer information om dessa disktyper finns i artikeln Azure Storage-typer för SAP-arbetsbelastning och Välj en disktyp

Azure erbjuder två distributionsmetoder för virtuella hårddiskar på Azure Standard och Premium Storage v1/v2. Vi förväntar oss att du drar nytta av azure-hanterad disk för Azure-blocklagringsdistributioner.

En lista över lagringstyper och deras serviceavtal i IOPS och lagringsdataflöde finns i Azure-dokumentationen för hanterade diskar.

Viktigt!

Oberoende av den valda Azure-lagringstypen måste det filsystem som används på lagringen stödjas av SAP för det specifika operativsystemet och DBMS. SAP-supportanteckning #2972496 listar de filsystem som stöds för olika operativsystem och databaser, inklusive SAP HANA. Detta gäller för alla volymer som SAP HANA kan komma åt för läsning och skrivning för vilken uppgift som helst. Mer specifikt med hjälp av NFS på Azure för SAP HANA gäller ytterligare begränsningar för NFS-versioner som anges senare i den här artikeln

De minsta SAP HANA-certifierade villkoren för de olika lagringstyperna är:

  • Azure Premium Storage v1 – /hana/log måste stödjas av Azure Write Accelerator. / hana/datavolymen kan placeras på Premium Storage v1 utan Azure Write Accelerator eller ultradisk. Azure Premium Storage v2 eller Azure Premium SSD v2 stöder inte användning av Azure Write Accelerator
  • Azure Ultra-disk minst för volymen /hana/log . / hana/datavolymen kan placeras på antingen Premium Storage v1/v2 utan Azure Write Accelerator eller för att få snabbare omstartstider ultradisk
  • 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

Baserat på erfarenhet från kunder har vi ändrat stödet för att kombinera olika lagringstyper mellan /hana/data och /hana/log. Det stöds för att kombinera användningen av de olika Azure-blocklagringar som är certifierade för HANA- och NFS-resurser baserat på Azure NetApp Files. Det är till exempel möjligt att placera /hana/data på Premium Storage v1 eller v2 och /hana/log kan placeras på Ultra-disklagring för att få den nödvändiga korta svarstiden. Om du använder en volym baserat på ANF för /hana/data kan även /hana/log-volymen placeras på någon av de HANA-certifierade Azure-blocklagringstyperna. Användning av NFS ovanpå ANF för en av volymerna (till exempel /hana/data) och Azure Premium Storage v1/v2 eller Ultra-disken för den andra volymen (till exempel /hana/log) stöds.

I den lokala världen behövde du sällan bry dig om I/O-undersystemen och dess funktioner. Orsaken var att leverantören av installationen 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 känna till några av dessa SAP-utfärdade krav. Några av de minsta dataflödesegenskaper som SAP rekommenderar är:

  • Läs/skriv på /hana/logg på 250 MB/sek med 1 MB I/O-storlekar
  • Läsaktivitet på minst 400 MB/s för /hana/data för 16 MB och 64 MB I/O-storlekar
  • Skrivaktivitet på minst 250 MB/s för /hana/data med I/O-storlekar på 16 MB och 64 MB

Med tanke på att svarstiden för låg lagring är viktig för DBMS-system, även om DBMS, som SAP HANA, håller data i minnet. Den kritiska sökvägen i lagringen finns vanligtvis runt transaktionsloggens skrivningar av DBMS-systemen. Men även åtgärder som att skriva savepoints eller läsa in data i minnet efter kraschåterställning kan vara kritiska. Därför är det obligatoriskt att använda Azure Premium Storage v1/v2, Ultra Disk eller ANF för /hana/data - och /hana/log-volymer .

Några vägledande principer för att välja din lagringskonfiguration för HANA kan visas som:

  • Bestäm vilken typ av lagring som baseras på Azure Storage-typer för SAP-arbetsbelastning och Välj en disktyp
  • Det övergripande I/O-dataflödet och IOPS-gränserna för den virtuella datorn i åtanke när du ändrar storlek på eller beslutar om en virtuell dator. Övergripande dataflöde för vm-lagring dokumenteras i artikeln Minnesoptimerade storlekar för virtuella datorer
  • När du bestämmer dig för lagringskonfigurationen kan du försöka hålla dig under det totala dataflödet för den virtuella datorn med din /hana/datavolymkonfiguration . SAP HANA skriver sparanden, HANA kan vara aggressiv utfärdande I/Os. Det är enkelt att push-överföra 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 stöta på situationer där dataflödet som används av skrivning av sparandepunkter stör dataflödeskraven för skrivningar av omgjorda loggar. En situation som kan påverka programmets dataflöde
  • Om du överväger att använda HANA-systemreplikering måste lagringen som används för /hana/data på varje replik vara densamma och lagringstypen som används för /hana/log på varje replik måste vara densamma. Till exempel stöds inte användning av Azure Premium Storage v1 för /hana/data med en virtuell dator och Azure Ultra-disk för /hana/data i en annan virtuell dator som kör en replik av samma HANA-systemreplikeringskonfiguration

Viktigt!

Förslagen för lagringskonfigurationerna i detta eller efterföljande dokument är avsedda som anvisningar till att börja med. När du kör arbetsbelastning och analyserar mönster för lagringsanvändning kanske du inser att du inte använder all lagringsbandbredd eller all IOPS som tillhandahålls. Du kan överväga att sänka lagringsstorleken då. Eller tvärtom kan din arbetsbelastning behöva mer dataflöde för lagring än vad som föreslås med dessa konfigurationer. Därför kan du behöva distribuera mer kapacitet, IOPS eller dataflöde. När det gäller spänningar mellan den lagringskapacitet som krävs, den nödvändiga lagringsfördröjningen, det dataflöde för lagring och IOPS som krävs och den billigaste konfigurationen erbjuder Azure tillräckligt med olika lagringstyper med olika funktioner och olika prispunkter för att hitta och anpassa sig till rätt kompromiss för dig och din HANA-arbetsbelastning.

Stripe-uppsättningar jämfört med partitionering av SAP HANA-datavolym

Med Azure Premium Storage v1 kan du nå det bästa pris-/prestandaförhållandet när du streckar 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 behövs. Du kan skapa en enskild volym på flera Azure-diskar med LVM- och MDADM-volymhanterare, som ingår i Linux. Metoden för att stripa diskar är årtionden gammal och välkänd. Lika fördelaktigt som de randiga volymerna är att komma till de IOPS- eller dataflödesfunktioner du kan behöva, lägger det till komplexitet kring hantering av dessa randiga volymer. Särskilt i de fall då volymerna behöver utökas i kapacitet. Sap introducerade åtminstone för /hana/data en alternativ metod som uppnår samma mål som striping över flera Azure-diskar. Eftersom SAP HANA 2.0 SPS03 kan HANA-indexservern strecka 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 randig volym på olika Azure-diskar. SAP HANA-funktionen för partitionering av datavolymer beskrivs i detalj i:

När du läser igenom informationen är det uppenbart att användningen av den här funktionen tar bort komplexiteten i volymhanterarens baserade stripe-uppsättningar. Du inser också att HANA-datavolympartitioneringen inte bara fungerar för Azure-blocklagring, som Azure Premium Storage v1/v2. Du kan även använda den här funktionen för att strecka ö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. En vanlig rekommendation via Linux-leverantörer och SAP är att konfigurera om I/O-schemaläggningsläget för diskvolymer från mq-deadline - eller kyber-läget till noop-läget (icke-multiqueue) eller inget för (multiqueue)-läget om det inte har gjorts ännu av SLES saptune-profilerna. Information refereras till i:

På Red Hat lämnar du inställningarna enligt de specifika justeringsprofilerna för de olika SAP-programmen.

Randstorlekar när logiska volymhanterare används

Om du använder LVM eller mdadm för att skapa stripe-uppsättningar över flera Azure Premium-diskar måste du definiera randstorlekar. Dessa storlekar skiljer sig mellan /hana/data och /hana/log. Rekommendation: Som randstorlekar är rekommendationen att använda:

  • 256 KB för /hana/data
  • 64 KB för /hana/log

Kommentar

Randstorleken 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 har också ändrat rekommendationen för randstorlekar på /hana/log från 32 KB till 64 KB för att få tillräckligt med dataflöde med större I/O-storlekar.

Kommentar

Du behöver inte konfigurera någon redundansnivå med RAID-volymer eftersom Azure Block Storage 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.

Att samla flera Azure-diskar under en stripe-uppsättning ackumuleras från en IOPS- och lagringsdataflödessida. Så om du sätter en stripe-uppsättning över över 3 x P30 Azure Premium Storage v1-diskar bör det ge dig tre gånger IOPS och tre gånger lagringsdataflödet för en enda Azure Premium Storage v1 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 placeras i en standard- eller rotvolymgrupp. Vi rekommenderar starkt att du följer vägledningen för Linux-leverantörer, som vanligtvis är att skapa enskilda volymgrupper för /data, /log och /shared.

Överväganden för DET HANA-delade filsystemet

Vid storleksändring av HANA-filsystemen ägnas mest uppmärksamhet åt HANA-systemen för data och loggfiler. Men /hana/shared spelar också en viktig roll i driften av ett stabilt HANA-system, eftersom det är värd för viktiga komponenter som HANA-binärfilerna.
Om den är underdelad kan /hana/shared bli I/O mättad på grund av överdrivna läs-/skrivåtgärder – till exempel när du skriver en stor dump eller under intensiv spårning, eller om säkerhetskopieringen skrivs till filsystemet /hana/shared . Svarstiden kan också öka.

Om HANA-systemet är i en HA-konfiguration kan långsamma svar från det delade filsystemet, d.v.s. /hana/shared , orsaka tidsgränser för klusterresurser. Dessa timeouter kan leda till onödiga redundansväxlingar, eftersom HANA-resursagenterna felaktigt kan anta att databasen inte är tillgänglig.

SAP-riktlinjerna för /hana/delade rekommenderade storlekar skulle se ut så här:

Volume Rekommenderad storlek
/hana/delad uppskalning Min(1 TB, 1 x RAM)
/hana/delad utskalning 1 x RAM-minne för arbetsnod
per fyra arbetsnoder

Mer information finns i följande SAP-anteckningar:
3288971 – Vanliga frågor och svar: SUSE HAE/RedHat HAA Pacemaker Cluster Resource Manager i SAP HANA-systemreplikeringsmiljöer
1999930 – Vanliga frågor och svar: SAP HANA I/O-analys

Vi rekommenderar att du storleksanpassar /hana/delas för att undvika flaskhalsar i prestanda. Kom ihåg att ett filsystem i storlek /hana/delat bidrar till stabiliteten och tillförlitligheten i ditt SAP HANA-system, särskilt i HA-scenarier.

Azure Premium Storage v1-konfigurationer för HANA

Detaljerade rekommendationer för HANA-lagringskonfiguration med Azure Premium Storage v1 finns i dokumentet sap hana azure virtuell dator Premium SSD lagringskonfigurationer.

Azure Premium SSD v2-konfigurationer för HANA

Detaljerade rekommendationer för HANA-lagringskonfiguration med azure premium ssd v2-lagring finns i dokumentet sap hana azure virtuell dator Premium SSD v2 lagringskonfigurationer.

Azure Ultra Disk Storage-konfiguration för SAP HANA

Detaljerade rekommendationer för HANA-lagringskonfiguration med Hjälp av Azure Ultra Disk finns i dokumentet sap hana azure virtuell dator Ultra Disk lagringskonfigurationer.

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.

Nästa steg

Mer information finns i: