Förstå och optimera Azure-fildelningsprestanda

✔️ Gäller för: Klassiska SMB- och NFS-filresurser som skapats med Microsoft.Storage-resursprovidern

✔️ Gäller för: Fildelningar som skapats med resursprovidern Microsoft.FileShares

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

Ordlista för lagringsprestanda

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 filsystemåtgärder per sekund. I Azure Files dokumentationen är termen "IO" utbytbar med termerna "operation" och "transaction".

• 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 små storlekar som 4 KiB till större storlekar. I/O-storlek spelar en viktig roll för uppnåeligt dataflöde.

• Genomströmning

  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.

• Svarstider

  Svarstid är synonymt för fördröjning och mäts 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 medienivå baserat på användningsmönster

Azure Files tillhandahåller två lagringsmedianivåer som du kan använda för att balansera prestanda och pris: SSD och HDD. Du väljer åtkomstnivå för fildelningen på lagringskontonivån. När du har skapat ett lagringskonto på en viss medienivå kan du inte flytta till den andra medienivån utan att migrera till en ny filresurs manuellt.

När du väljer mellan SSD- och HDD-filresurser bör du överväga 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, snabba dataöverföringshastigheter eller låg svarstid väljer du SSD-filresurser.

I följande tabell sammanfattas de förväntade prestandamålen mellan SSD- och HDD-filresurser. Mer information finns i Skalbarhets- och prestandamål för Azure Files.

SSD-filresurser använder en etableringsmodell som garanterar följande prestandaprofil baserat på resursstorlek. Mer information finns i den etablerade v1-modellen.

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

• Svarstidskänslighet: Arbetsbelastningar som är känsliga för läsfördröjning och har hög synlighet för slutanvändare är mer lämpliga för SSD-filresurser, vilket kan ge svarstid på en millisekunder för både läs- och skrivåtgärder (mindre än 2 ms för liten I/O-storlek).

• Krav för IOPS och dataflöde: SSD-filresurser stöder större IOPS- och dataflödesgränser än HDD-filresurser. 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 nå de övre prestandagränserna för HDD-filresurser jämfört med långvariga, ofta förekommande arbetsbelastningar. På SSD-filresurser hjälper arbetsbelastningens varaktighet till att fastställa rätt prestandaprofil som ska användas baserat på etablerad lagring, IOPS och dataflöde. 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 prestandan, se till att du testar vid tillräckligt hög frekvens och längd.

• Parallellisering av arbetsbelastning: För arbetsbelastningar som utför åtgärder parallellt, till exempel genom flera trådar, processer eller programinstanser på samma klient, ger SSD-filresurser en klar fördel jämfört med HDD-filresurser: SMB Multichannel. Mer information finns i Förbättra prestandan för Azure-filresurser för SMB.

• API-åtgärdsdistribution: Metadataintensiva arbetsbelastningar, till exempel arbetsbelastningar som utför läsåtgärder mot ett stort antal filer, passar bättre för SSD-filresurser. Mer information finns i Hög arbetsbelastning för metadata eller namnområden.

• Zonindelning: Använd zonindelning för att välja den specifika tillgänglighetszon där ditt lagringskonto finns. Med den här funktionen kan du placera dina virtuella datorer i samma tillgänglighetszon som lagringen, vilket kan minska svarstiden med upp till 30 procent. Den här funktionen är för närvarande endast tillgänglig för SSD-lagringskonton med lokalt redundant lagring (LRS) i regioner som stöds.

Svarstid

När du tänker på svarstid bör du först förstå hur Azure Files avgör svarstiden. De vanligaste måtten är svarstiden som är associerad med svarstid från slutpunkt till slutpunkt och mått för tjänstfördröjning . Med hjälp av dessa transaktionsmått kan du identifiera svarstids- och nätverksproblem på klientsidan genom att visa hur mycket 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änstlatens (SuccessServerLatency) är den tid det tar för en transaktion att skickas tur och retur enbart inom Azure Files. Den här mätningen omfattar inte någon klient- eller nätverksfördröjning.

  

Skillnaden mellan värdena SuccessE2ELatency och SuccessServerLatency är den svarstid som sannolikt 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änstens svarstid till exempel rapporterar låg svarstid och den heltäckande svarstiden rapporterar mycket hög svarstid för begäranden, går all tid åt till överföring till och från klienten, och inte i Azure Files-tjänsten.

Dessutom, som diagrammet visar, ju längre du kommer från tjänsten, desto långsammare blir svarstiden och desto svårare är det att uppnå prestandaskalningsgränser med alla molntjänster. Det här villkoret gäller särskilt vid åtkomst till Azure Files lokalt. Även om alternativ som Azure ExpressRoute är idealiska för lokalt, matchar de fortfarande inte prestandan för ett program (beräkning + lagring) som körs uteslutande i samma Azure region.

Ködjup

Ködjup är antalet utestående I/O-begäranden som en lagringsresurs kan betjäna. Eftersom de diskar som används av lagringssystem utvecklades från HDD-spindlar (IDE, SATA, SAS) till solid state-enheter (SSD, NVMe), utvecklades de också 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å högt ködjup. Eftersom Azure Files är en distribuerad filtjänst som sträcker sig över tusentals Azure klusternoder och är utformad för att köra arbetsbelastningar i stor skala, skapa och testa arbetsbelastningar med högt ködjup.

Du kan uppnå högt ködjup på flera olika sätt. 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 följande tabell 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 rekommenderas det inte. Du ser inga fler prestandavinster om du gör det, och du riskerar att öka svarstiden på grund av TCP-mättnad.

Program med enkel tråd jämfört med flertrådsprogram

Azure Files fungerar bäst med flertrådade program. Det enklaste sättet att förstå prestandapåverkan som multitrådning har på en arbetsbelastning är att gå igenom scenariot med I/O. I följande exempel har du 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 delar upp 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 det här exemplet tar det cirka 14 ms att skapa en enda 16 KiB-fil från de sex åtgärderna. Om ett entrådat program vill flytta 10 000 filer till en Azure filresurs översätts åtgärden till 140 000 ms (14 ms × 10 000) eller 140 sekunder eftersom varje fil flyttas sekventiellt en i taget. Tiden för att hantera varje begäran bestäms främst av hur nära beräkningen och lagringen finns till varandra, enligt beskrivningen i föregående avsnitt.

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

Se även

• Felsöka prestandaproblem i Azure-fildelningar
• Övervaka Azure Files
• Planera för en Azure Files-distribution
• Förstå Azure Files-fakturering
• Priser för Azure Files