Granska storleksändring för SAP HANA-databaser på Azure NetApp Files

  • 7 minuter

Dataflödet för en Azure NetApp-volym är en funktion av volymstorleken och tjänstnivån, enligt beskrivningen i Tjänstnivå för Azure NetApp Files.

Det är viktigt att förstå prestandarelationen mellan volymstorleken och de fysiska gränserna för ett logiskt gränssnitt (LIF) för den virtuella lagringsdatorn (SVM).

Tabellen nedan visar möjliga fördelar med att skapa en stor "Standard"-volym för lagring av säkerhetskopior och att det inte är meningsfullt att skapa en "Ultra"-volym som är större än 12 TB eftersom den fysiska bandbreddskapaciteten för en enda LIF skulle överskridas.

Det maximala dataflödet för ett logiskt gränssnitt och en enda Linux-session är mellan 1,2 och 1,4 GB/s.

Storlek Dataflödesstandard Dataflödespremie Dataflöde Ultra
1 TB 16 MB/s 64 MB/s 128 MB/s
2 TB 32 MB/s 128 MB/s 256 MB/s
4 TB 64 MB/s 256 MB/s 512 MB/s
10 TB 160 MB/s 640 MB/s 1 280 MB/s
15 TB 240 MB/s 960 MB/s 1 400 MB/s
20 TB 320 MB/s 1 280 MB/s 1 400 MB/s
40 TB 640 MB/s 1 400 MB/s 1 400 MB/s

Kommentar

skriv- eller enstaka sessionsläsningsgränser (om NFS-monteringsalternativet nconnect inte används)

Det är viktigt att förstå att data skrivs till samma SSD i lagringsserverdelen. Prestandakvoten från kapacitetspoolen skapas för att kunna hantera miljön. Prestandaindikatorn för lagringsnyckel (KPI) är lika med alla SAP HANA-databasstorlekar. I de flesta fall återspeglar det här antagandet inte verkligheten och kundens förväntningar. Storleken på SAP HANA-system innebär inte nödvändigtvis att ett litet system kräver lågt dataflöde för lagring, eller att ett stort system kräver högt dataflöde för lagring. Men i allmänhet kan vi förvänta oss högre dataflödeskrav för större SAP HANA-databasinstanser. Som ett resultat av SAP:s storleksregler för den underliggande maskinvaran ger sådana större SAP HANA-instanser också fler CPU-resurser och högre parallellitet i uppgifter som att läsa in data efter en instans omstart. Därför bör volymstorlekarna anpassas efter kundens förväntningar och krav och inte bara drivas av rena kapacitetskrav.

När du utformar infrastrukturen för SAP i Azure bör du vara medveten om SAP:s minsta dataflödeskrav för lagring (för produktionssystem), vilket innebär minsta dataflödesegenskaper för:

Volymtyp och I/O-typ Minsta KPI som krävs av SAP Premium-tjänstnivå Ultra servicenivå
Loggvolymskrivning 250 MB/sek. 4 TB 2 TB
Skrivning av datavolym 250 MB/sek. 4 TB 2 TB
Läsa datavolym 400 MB/s 6,3 TB 3,2 TB

Eftersom alla tre KPI:er krävs måste /hana/datavolymen vara storleksanpassad mot den större kapaciteten för att uppfylla minimikraven för läsning.

För SAP HANA-system, som inte kräver hög bandbredd, kan volymstorlekarna för ANF (Azure NetApp Files) vara mindre. Och om ett SAP HANA-system kräver mer dataflöde skulle volymen kunna anpassas genom att ändra storlek på kapaciteten online. Inga KPI:er har definierats för säkerhetskopieringsvolymer. Dataflödet för säkerhetskopieringsvolymen är dock viktigt för en väl fungerande miljö. Logg – och datavolymprestanda måste utformas enligt kundens förväntningar.

Viktigt!

Oberoende av den kapacitet som du distribuerar på en enda NFS-volym förväntas dataflödet platå inom intervallet 1,2–1,4 GB/sek bandbredd som används av en konsument på en virtuell dator. Detta har att göra med den underliggande arkitekturen för ANF-erbjudandet och relaterade Linux-sessionsgränser kring NFS. Prestanda- och dataflödesnumren som beskrivs i artikeln Prestandamått för Azure NetApp Files för Linux utfördes mot en delad NFS-volym med flera virtuella klientdatorer och som ett resultat av flera sessioner. Det scenariot skiljer sig från det scenario som vi mäter i SAP, där vi mäter dataflöde från en enda virtuell dator mot en NFS-volym som finns på ANF.

För att uppfylla SAP:s minsta dataflödeskrav för data och logg, och enligt riktlinjerna för /hana/shared, skulle de rekommenderade storlekarna se ut så här:

volym Storlek (Premium Storage-nivå) Storlek (Ultra Storage-nivå) NFS-protokoll som stöds
/hana/log 4 TiB 2 TiB v4.1
/hana/data 6.3 TiB 3.2 TiB v4.1
/hana/delad uppskalning Min (1 TB, 1 x RAM) Min (1 TB, 1 x RAM) v3 eller v4.1
/hana/delad utskalning 1 x RAM-minne för arbetsnoder per 4 arbetsnoder 1 x RAM-minne för arbetsnoder per 4 arbetsnoder v3 eller v4.1
/hana/logbackup 3 x RAM 3 x RAM v3 eller v4.1
/hana/backup 2 x RAM 2 x RAM v3 eller v4.1

För alla volymer rekommenderas NFS v4.1 starkt.

Storlekarna för säkerhetskopieringsvolymerna är uppskattningar. Exakta krav måste definieras baserat på arbetsbelastnings- och åtgärdsprocesser. För säkerhetskopior kan du konsolidera många volymer för olika SAP HANA-instanser till en (eller två) större volymer, vilket kan ha en lägre servicenivå av ANF.

Kommentar

Storleksrekommendationerna för Azure NetApp Files som anges i det här dokumentet riktar sig till de minimikrav som SAP uttrycker mot sina infrastrukturleverantörer. I verkliga kunddistributioner och arbetsbelastningsscenarier kanske det inte räcker. Använd dessa rekommendationer som utgångspunkt och anpassa baserat på kraven för din specifika arbetsbelastning.

Därför kan du överväga att distribuera liknande dataflöde för ANF-volymerna som redan anges för Ultra Disk Storage. Tänk också på storlekarna för de storlekar som anges för volymerna för de olika virtuella dator-SKU:erna som redan gjorts i Ultra-disktabellerna.

Dricks

Du kan ändra storlek på Azure NetApp Files-volymer dynamiskt, utan att unmount behöva volymerna, stoppa de virtuella datorerna eller stoppa SAP HANA. Detta ger flexibilitet för att uppfylla kraven på programmets dataflöde, både förväntade och oförutsedda.

Dokumentation om hur du distribuerar en SAP HANA-utskalningskonfiguration med väntelägesnod med hjälp av NFS v4.1-volymer som finns i ANF publiceras i SAP HANA-utskalning med väntelägesnod på Azure Virtual Machines med Azure NetApp Files på SUSE Linux Enterprise Server.

Metodtips för storleksändring för SAP på Azure NetApp Files.