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. På provisionerade fildelningar kan ett kort test mäta kreditbaserad burst-IOPS istället för provisionerad IOPS. För mer information, se Bursting.

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

Sprängning

Fildelningar som använder den provisionerade v2- eller provisioned v1-faktureringsmodellen stödjer kreditbaserad IOPS-bursting. Kreditbaserad bursting låter en fildelning använda fler IOPS än vad den har tilldelats under en begränsad tid. Kreditbaserad bursting är en funktion i fildelningen. Bursty trafik är ett arbetsbelastningsmönster med korta toppar i IOPS eller genomströmning. Kreditbaserad burstning kan absorbera korta IOPS-toppar från ojämn trafik med toppar.

Kreditbaserad bursting ingår i kostnaden för den provisionerade fildelningen och lägger inte till några avgifter på din räkning. Kreditbaserad bursting gäller endast för IOPS. Det ökar inte genomströmningen över den provisionerade genomströmningen.

Bursting gäller inte pay-as-you-go-fildelningar. Klassiska fildelningar som burstar omfattas fortfarande av lagringskontots IOPS-gränser. För mer information, se Klassiska dataplansgränser för fildelning. För information om hur bursting påverkar kostnaden, se Förstå Azure Files fakturering.

Provisionerad v2-bursting

Kreditbaserad IOPS-bursting ger ökad flexibilitet kring IOPS-användning. Använd den här flexibiliteten som en buffert mot oväntade I/O-toppar. För etablerade I/O-mönster, dimensionera för I/O-toppar.

Burst IOPS-krediter ackumuleras när trafiken för filresursen är mindre än etablerad (baslinje) IOPS. När en filresurss IOPS-användning överskrider den etablerade IOPS och det finns tillgängliga burst-IOPS-krediter kan filresursen överskrida gränsen för högsta tillåtna burst-IOPS. Filresurser kan fortsätta att utökas så länge det finns krediter kvar, baserat på antalet upplupna burstkrediter. Varje I/O utöver etablerad IOPS förbrukar en kredit. När alla krediter har förbrukats återgår andelen till den avgränsade IOPS. IOPS mot fildelningen behöver inte göra något speciellt för att använda bursting. Bursting fungerar efter bästa förmåga.

Aktiekrediter har tre stater.

• Ackumuleras när fildelningen använder mindre än de tilldelade IOPS.
• Nedgång sker när filresursen använder mer än etablerade IOPS och är i sprängläge.
• Konstant, när filresursen använder exakt den etablerade IOPS och det antingen inte finns några krediter som ackumuleras eller används.

En ny filresurs börjar med det fullständiga antalet krediter i sin burst-bucket. Burst-krediter ackumuleras inte om andel IOPS ligger under den tilldelade gränsen på grund av serverns begränsning. Följande formler används för att fastställa gränsen för burst-IOPS och antalet krediter som är möjliga för en filresurs:

I följande tabell visas några exempel på dessa formler för olika etablerade IOPS-belopp:

Tilldelad v1-bursting

Den provisionerade v1-modellen stöder två typer av bursting: kreditbaserad bursting, som ingår utan extra kostnad, och betald bursting, som du valfritt kan aktivera för att tillåta IOPS och genomströmning över den provisionerade mängden mot användningsbaserad debitering.

Provisionerad v1-kreditbaserad bursting

Kreditbaserad IOPS-bursting ger ökad flexibilitet kring IOPS-användning. Använd den här flexibiliteten som en buffert mot oväntade I/O-toppar. För etablerade I/O-mönster, dimensionera för I/O-toppar.

Burst IOPS-krediter ackumuleras när trafiken för den klassiska fildelningen är mindre än den provisionerade (baslinjen) IOPS. När en klassisk filresurss IOPS-användning överskrider den etablerade IOPS och det finns tillgängliga burst-IOPS-krediter kan den klassiska filresursen ökas till den högsta tillåtna IOPS-gränsen. Klassiska filresurser kan fortsätta att brista så länge det finns krediter kvar, baserat på antalet upplupna burst-krediter. Varje I/O utöver etablerad IOPS förbrukar en kredit. När alla krediter har förbrukats återgår den klassiska fildelningen till den provisionerade IOPS. IOPS mot den klassiska filresursen behöver inte göra något speciellt för att använda bursting. Bursting fungerar efter bästa förmåga.

Aktiekrediter har tre stater.

• Ackumuleras när den klassiska filresursen använder mindre än de provisionerade IOPS.
• Minskande, när den klassiska filresursen använder mer än den etablerade IOPS och i burst-läget.
• Konstant, när den klassiska filresursen använder exakt den etablerade IOPS och det antingen inte finns några krediter som ackumuleras eller används.

En ny klassisk fildelning börjar med det fulla antalet krediter i sin burst-bucket. Burst-krediter ackumuleras inte om andel IOPS ligger under den tilldelade gränsen på grund av serverns begränsning. Följande formler används för att fastställa gränsen för burst-IOPS och antalet krediter som är möjliga för en klassisk filresurs:

I följande tabell visas några exempel på dessa formler för de etablerade storlekarna:

Provisionerad v1 betalad burstkapacitet

Betald bursting är en avancerad funktion i den etablerade v1-modellen som är utformad för att stödja kunder som aldrig vill begränsas. Betald bursting lägger till extra användningsbaserad fakturering för alla IOPS- eller dataflöden ovanför den etablerade lagringen. Den här funktionen skiljer sig från kreditbaserad bursting, som ingår kostnadsfritt i allokerad lagring. Även om betald bursting kan ge kraftfull flexibilitet för hur du tilldelar din klassiska fildelning, kan det också leda till oväntade kostnader om det används felaktigt.

Precis som kreditbaserad överbelastning är betald överbelastning inte en ersättning för att tillhandahålla rätt mängd IOPS och dataflöde. I stället ger det ytterligare skydd mot begränsning om du stöter på oväntad efterfrågan. Om du har en konsekvent nivå av IOPS- eller dataflödesanvändning är det billigare att etablera tillräckligt med IOPS och dataflöde (genom lagringsetablering) för att täcka efterfrågan i stället för att förlita dig på betald bursting.

Betald bursting är inaktiverad som standard, men du kan aktivera den genom att följa anvisningarna för att ändra kostnads- och prestandaegenskaperna för en etablerad klassisk v1-filresurs (endast PowerShell och CLI). Om du aktiverar betald burst-användning övervakar du IOPS- och dataflödesanvändningen med hjälp av följande mått som är tillgängliga via Azure Monitor:

• Provisionerad IOPS för fildelning
• Tilldelad Bandbredd för Fildelning MiB/s (genomströmning)
• Transaktioner efter Max IOPS
• Bandbredd baserat på Max MiB/s (dataflöde)
• Burst-krediter för IOPS (kreditbaserad bursting)
• Betalda Burstning IOS (I/O-gränssnitt)
• Betald dynamisk bandbredd

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