Förstå prestanda för Azure Files

Artikel
09/03/2023

Azure Files kan uppfylla prestandakraven för de flesta program och användningsfall. Den här artikeln förklarar de olika faktorer som kan påverka filresursprestanda och hur du optimerar prestanda för Azure-filresurser för din arbetsbelastning.

Gäller för

Typ av filresurs	SMB	NFS
Standardfilresurser (GPv2), LRS/ZRS
Standardfilresurser (GPv2), GRS/GZRS
Premiumfilresurser (FileStorage), LRS/ZRS

Ordlista

Innan du läser den här artikeln är det bra att förstå några viktiga termer som rör lagringsprestanda:

I/O-åtgärder per sekund (IOPS)

IOPS, eller indata-/utdataåtgärder per sekund, mäter antalet filsystemsåtgärder per sekund. Termen "I/O" kan ändras med termerna "operation" och "transaction" i Azure Files dokumentationen.
I/O-storlek

I/O-storlek, som ibland kallas blockstorlek, är storleken på den begäran som ett program använder för att utföra en enda indata-/utdataåtgärd (I/O) på lagringen. Beroende på programmet kan I/O-storleken variera från mycket små storlekar, till exempel 4 KiB till mycket större storlekar. I/O-storlek spelar en viktig roll i uppnåeligt dataflöde.
Dataflöde

Dataflödet mäter antalet bitar som läses från eller skrivs till lagringen per sekund och mäts i mebibyte per sekund (MiB/s). Om du vill beräkna dataflödet multiplicerar du IOPS med I/O-storlek. Till exempel 10 000 IOPS * 1 MiB I/O-storlek = 10 GiB/s, medan 10 000 IOPS * 4 KiB I/O-storlek = 38 MiB/s.
Svarstid

Svarstid är en synonym till fördröjning och mäts vanligtvis i millisekunder (ms). Det finns två typer av svarstider: svarstid från slutpunkt till slutpunkt och tjänstfördröjning. Mer information finns i Svarstid.
Ködjup

Ködjup är antalet väntande I/O-begäranden som en lagringsresurs kan hantera samtidigt. Mer information finns i Ködjup.

Välja en prestandanivå baserat på användningsmönster

Azure Files tillhandahåller en mängd olika lagringsnivåer som hjälper dig att minska kostnaderna genom att du kan lagra data på lämplig prestanda- och prisnivå. På den högsta nivån erbjuder Azure Files två prestandanivåer: standard och premium. Standardfilresurser finns i ett lagringssystem som backas upp av hårddiskar (HDD), medan premiumfilresurser backas upp av SSD-enheter (Solid State Drives) för bättre prestanda. Standardfilresurser har flera lagringsnivåer (transaktionsoptimerad, frekvent och lågfrekvent) som du sömlöst kan flytta mellan för att maximera lagrings- och transaktionspriserna för vilande data. Du kan dock inte flytta mellan standard- och premiumnivåer utan att fysiskt migrera dina data mellan olika lagringskonton.

När du väljer mellan standard- och premiumfilresurser är det viktigt att förstå kraven för det förväntade användningsmönstret som du planerar att köra på Azure Files. Om du behöver stora mängder IOPS, extremt snabba dataöverföringshastigheter eller mycket låg svarstid bör du välja Premium Azure-filresurser.

I följande tabell sammanfattas de förväntade prestandamålen mellan standard och premium. Mer information finns i Azure Files skalbarhets- och prestandamål.

Krav för användningsmönster	Standard	Premium
Skrivsvarstid (ensiffriga millisekunder)	Ja	Yes
Lässvarstid (ensiffriga millisekunder)	Inga	Ja

Premium-filresurser erbjuder en etableringsmodell som garanterar följande prestandaprofil baserat på resursstorlek. Mer information finns i Etablerad modell. Burst-krediter ackumuleras i en burst-bucket när trafiken för filresursen ligger under baslinje-IOPS. Intjänade krediter används senare för att aktivera burst-överföring när åtgärder skulle överskrida baslinje-IOPS.

Kapacitet (GiB)	Baslinje-IOPS	Burst-IOPS	Burst-krediter	Dataflöde (ingress + utgående)
100	3,100	Upp till 10 000	24,840,000	110 MiB/s
500	3 500	Upp till 10 000	23,400,000	150 MiB/s
1,024	4,024	Upp till 10 000	21,513,600	203 MiB/s
5,120	8,120	Upp till 15 360	26,064,000	613 MiB/s
10,240	13,240	Upp till 30 720	62,928,000	1 125 MiB/s
33,792	36,792	Upp till 100 000	227,548,800	3 480 MiB/s
51,200	54,200	Upp till 100 000	164,880,000	5 220 MiB/s
102,400	100 000	Upp till 100 000	0	10 340 MiB/s

Checklista för prestanda

Oavsett om du utvärderar prestandakrav för en ny eller befintlig arbetsbelastning kan du få förutsägbara prestanda genom att förstå dina användningsmönster. Kontakta lagringsadministratören eller programutvecklaren för att fastställa följande användningsmönster.

Känslighet för svarstid: Öppnar eller interagerar användare med virtuella skrivbord som körs på Azure Files? Det här är exempel på arbetsbelastningar som är känsliga för läsfördröjning och som även har hög synlighet för slutanvändare. Dessa typer av arbetsbelastningar är lämpligare för Premium Azure-filresurser, vilket kan ge svarstid på en millisekunder för både läs- och skrivåtgärder (< 2 ms för liten I/O-storlek).
Krav för IOPS och dataflöde: Premium-filresurser stöder större IOPS- och dataflödesgränser än standardfilresurser. Mer information finns i skalningsmål för filresurser .
Varaktighet och frekvens för arbetsbelastning: Korta (minuter) och sällan förekommande (timvisa) arbetsbelastningar är mindre benägna att uppnå de övre prestandagränserna för standardfilresurser jämfört med långvariga, ofta förekommande arbetsbelastningar. På Premium-filresurser är arbetsbelastningens varaktighet användbar när du fastställer rätt prestandaprofil som ska användas baserat på etableringsstorleken. Beroende på hur länge arbetsbelastningen behöver brista och hur länge den spenderar under baslinje-IOPS kan du avgöra om du samlar tillräckligt med burst-krediter för att konsekvent uppfylla din arbetsbelastning vid hög belastning. Att hitta rätt saldo minskar kostnaderna jämfört med överetablering av filresursen. Ett vanligt misstag är att köra prestandatester i bara några minuter, vilket ofta är missvisande. För att få en realistisk bild av prestanda bör du testa med tillräckligt hög frekvens och varaktighet.
Parallellisering av arbetsbelastningar: För arbetsbelastningar som utför åtgärder parallellt, till exempel genom flera trådar, processer eller programinstanser på samma klient, ger Premium-filresurser en tydlig fördel jämfört med standardfilresurser: SMB Multichannel. Mer information finns i Förbättra prestanda för SMB Azure-filresurser .
DISTRIBUTION av API-åtgärder: Är arbetsbelastningsmetadata tunga med åtgärder för att öppna/stänga filer? Detta är vanligt för arbetsbelastningar som utför läsåtgärder mot ett stort antal filer. Se Hög arbetsbelastning för metadata eller namnområde.

Svarstid

När du tänker på svarstider är det viktigt att först förstå hur svarstiden bestäms med Azure Files. De vanligaste måtten är svarstiden som är associerad med mått för svarstid från slutpunkt till slutpunkt och svarstid för tjänster . Med hjälp av dessa transaktionsmått kan du identifiera svarstid och/eller nätverksproblem på klientsidan genom att fastställa hur lång tid programtrafiken spenderar under överföring till och från klienten.

Svarstid från slutpunkt till slutpunkt (SuccessE2ELatency) är den totala tid det tar för en transaktion att utföra en fullständig tur och retur-resa från klienten, över nätverket, till Azure Files-tjänsten och tillbaka till klienten.
Tjänstsvarstid (SuccessServerLatency) är den tid det tar för en transaktion att endast turas om inom Azure Files-tjänsten. Detta omfattar inte någon klient- eller nätverksfördröjning.

Skillnaden mellan värdena SuccessE2ELatency och SuccessServerLatency är den svarstid som troligen orsakas av nätverket och/eller klienten.

Det är vanligt att förväxla klientfördröjning med tjänstfördröjning (i det här fallet Azure Files prestanda). Om tjänstsvarstiden till exempel rapporterar låg svarstid och slutpunkt till slutpunkt rapporterar mycket lång svarstid för begäranden, tyder det på att all tid som överförs till och från klienten och inte i Azure Files-tjänsten.

Dessutom, som diagrammet illustrerar, ju längre bort du är från tjänsten, desto långsammare blir svarstiden och desto svårare blir det att uppnå prestandaskalningsgränser med alla molntjänster. Detta gäller särskilt vid åtkomst till Azure Files från en lokal plats. Även om alternativ som ExpressRoute är idealiska för lokala miljöer, matchar de fortfarande inte prestanda för ett program (beräkning och lagring) som körs exklusivt i samma Azure-region.

Tips

Att använda en virtuell dator i Azure för att testa prestanda mellan den lokala miljön och Azure är ett effektivt och praktiskt sätt att baslinjebasera nätverksfunktionerna för anslutningen till Azure. Ofta kan en arbetsbelastning saktas ned av en underdimensionerad eller felaktigt dirigerad ExpressRoute-krets eller VPN-gateway.

Ködjup

Ködjup är antalet utestående I/O-begäranden som en lagringsresurs kan hantera. Eftersom de diskar som används av lagringssystem har utvecklats från HDD-spindlar (IDE, SATA, SAS) till SSD-enheter (NVMe) har de också utvecklats för att stödja högre ködjup. En arbetsbelastning som består av en enda klient som seriellt interagerar med en enda fil i en stor datamängd är ett exempel på lågt ködjup. Däremot kan en arbetsbelastning som stöder parallellitet med flera trådar och flera filer enkelt uppnå ett högt ködjup. Eftersom Azure Files är en distribuerad filtjänst som omfattar tusentals Azure-klusternoder och är utformad för att köra arbetsbelastningar i stor skala rekommenderar vi att du skapar och testar arbetsbelastningar med högt ködjup.

Hög ködjup kan uppnås på flera olika sätt i kombination med klienter, filer och trådar. För att fastställa ködjupet för din arbetsbelastning multiplicerar du antalet klienter med antalet filer med antalet trådar (klienter * filer * trådar = ködjup).

I tabellen nedan visas de olika kombinationer som du kan använda för att uppnå ett högre ködjup. Även om du kan överskrida det optimala ködjupet på 64 rekommenderar vi det inte. Du ser inga fler prestandavinster om du gör det, och du riskerar att få längre svarstider på grund av TCP-mättnad.

Klienter	Filer	Trådar	Ködjup
1	1	1	1
1	1	2	2
1	2	2	4
2	2	2	8
2	2	4	16
2	4	4	32
1	8	8	64
4	4	2	64

Tips

För att uppnå övre prestandagränser kontrollerar du att arbetsbelastnings- eller benchmarkingtestet är flertrådat med flera filer.

Program med en eller flera trådar

Azure Files passar bäst för flertrådade program. Det enklaste sättet att förstå den prestandapåverkan som flera trådar har på en arbetsbelastning är att gå igenom scenariot med I/O. I följande exempel har vi en arbetsbelastning som behöver kopiera 10 000 små filer så snabbt som möjligt till eller från en Azure-filresurs.

Den här tabellen beskriver den tid som krävs (i millisekunder) för att skapa en enda 16 KiB-fil på en Azure-filresurs, baserat på ett entrådsprogram som skrivs i 4 KiB-blockstorlekar.

I/O-åtgärd	Skapa	4 KiB-skrivning	4 KiB-skrivning	4 KiB-skrivning	4 KiB-skrivning	Stäng	Totalt
Tråd 1	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms

I det här exemplet skulle det ta cirka 14 ms att skapa en enda 16 KiB-fil från de sex åtgärderna. Om ett entrådigt program vill flytta 10 000 filer till en Azure-filresurs översätts det till 140 000 ms (14 ms * 10 000) eller 140 sekunder eftersom varje fil flyttas sekventiellt en i taget. Tänk på att tiden för att betjäna varje begäran främst bestäms av hur nära beräkning och lagring finns till varandra, enligt beskrivningen i föregående avsnitt.

Genom att använda åtta trådar i stället för en kan ovanstående arbetsbelastning minskas från 140 000 ms (140 sekunder) ned till 17 500 ms (17,5 sekunder). Som tabellen nedan visar kan du flytta samma mängd data på 87,5 % mindre tid när du flyttar åtta filer parallellt i stället för en fil i taget.

I/O-åtgärd	Skapa	4 KiB-skrivning	4 KiB-skrivning	4 KiB-skrivning	4 KiB-skrivning	Stäng	Totalt
Tråd 1	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Tråd 2	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Tråd 3	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Tråd 4	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Tråd 5	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Tråd 6	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Tråd 7	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Tråd 8	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms