Inzicht in Azure Files prestaties

Artikel
07/15/2023

Azure Files voldoen aan de prestatievereisten voor de meeste toepassingen en gebruiksvoorbeelden. In dit artikel worden de verschillende factoren uitgelegd die van invloed kunnen zijn op de prestaties van bestandsshares en hoe u de prestaties van Azure-bestandsshares voor uw workload kunt optimaliseren.

Van toepassing op

Bestands sharetype	SMB	NFS
Standaardbestandsshares (GPv2), LRS/ZRS
Standaardbestandsshares (GPv2), GRS/GZRS
Premium bestandsshares (FileStorage), LRS/ZRS

Woordenlijst

Voordat u dit artikel leest, is het handig om enkele belangrijke termen met betrekking tot opslagprestaties te begrijpen:

IO-bewerkingen per seconde (IOPS)

IOPS, of invoer-/uitvoerbewerkingen per seconde, meet het aantal bestandssysteembewerkingen per seconde. De term 'I/O' kan worden verwisseld met de termen 'bewerking' en 'transactie' in de Azure Files documentatie.
I/O-grootte

I/O-grootte, ook wel blokgrootte genoemd, is de grootte van de aanvraag die een toepassing gebruikt om één I/O-bewerking (invoer/uitvoer) uit te voeren op opslag. Afhankelijk van de toepassing kan de I/O-grootte variëren van zeer kleine maten zoals 4 KiB tot veel grotere maten. I/O-grootte speelt een belangrijke rol in de haalbare doorvoer.
Doorvoer

Doorvoer meet het aantal bits dat wordt gelezen uit of geschreven naar de opslag per seconde en wordt gemeten in mebibytes per seconde (MiB/s). Als u de doorvoer wilt berekenen, vermenigvuldigt u IOPS met I/O-grootte. Bijvoorbeeld: 10.000 IOPS * 1 MiB I/O-grootte = 10 GiB/s, terwijl 10.000 IOPS * 4 KiB I/O-grootte = 38 MiB/s.
Latentie

Latentie is een synoniem voor vertraging en wordt meestal gemeten in milliseconden (ms). Er zijn twee soorten latentie: end-to-end latentie en servicelatentie. Zie Latentie voor meer informatie.
Diepte van wachtrij

Wachtrijdiepte is het aantal in behandeling zijnde I/O-aanvragen dat een opslagresource op elk gewenst moment kan verwerken. Zie Wachtrijdiepte voor meer informatie.

Een prestatielaag kiezen op basis van gebruikspatronen

Azure Files biedt een scala aan opslaglagen waarmee u de kosten kunt verlagen door u in staat te stellen gegevens op te slaan op het juiste prestatie- en prijsniveau. Op het hoogste niveau biedt Azure Files twee prestatielagen: Standard en Premium. Standaardbestandsshares worden gehost op een opslagsysteem dat wordt ondersteund door hardeschijfstations (HDD), terwijl premium-bestandsshares worden ondersteund door SSD's (Solid-State Drives) voor betere prestaties. Standaardbestandsshares hebben verschillende opslaglagen (geoptimaliseerd voor transacties, dynamisch en statisch) waartussen u naadloos kunt schakelen om de data-at-rest-opslag en transactieprijzen te maximaliseren. U kunt echter niet schakelen tussen de Standard- en Premium-laag zonder uw gegevens fysiek te migreren tussen verschillende opslagaccounts.

Wanneer u kiest tussen Standard- en Premium-bestandsshares, is het belangrijk om de vereisten te begrijpen van het verwachte gebruikspatroon dat u wilt uitvoeren op Azure Files. Als u grote hoeveelheden IOPS, extreem hoge gegevensoverdrachtssnelheden of een zeer lage latentie nodig hebt, moet u kiezen voor premium Azure-bestandsshares.

De volgende tabel bevat een overzicht van de verwachte prestatiedoelen tussen Standard en Premium. Zie Azure Files schaalbaarheids- en prestatiedoelen voor meer informatie.

Vereisten voor gebruikspatronen	Standard	Premium
Schrijflatentie (milliseconden met één cijfer)	Ja	Ja
Leeslatentie (milliseconden met één cijfer)	Nee	Ja

Premium-bestandsshares bieden een inrichtingsmodel dat het volgende prestatieprofiel garandeert op basis van de sharegrootte. Zie Ingericht model voor meer informatie. Bursttegoeden verzamelen zich in een burst-bucket wanneer het verkeer voor uw bestandsshare lager is dan de basis-IOPS. Verdiende tegoeden worden later gebruikt om bursting in te schakelen wanneer bewerkingen de IOPS van de basislijn overschrijden.

Capaciteit (GiB)	IOPS basislijn	Burst-IOPS	Bursttegoed	Doorvoer (inkomend en uitgaand verkeer)
100	3,100	Maximaal 10.000	24,840,000	110 MiB/s
500	3500	Maximaal 10.000	23,400,000	150 miB/s
1\.024	4,024	Maximaal 10.000	21,513,600	203 miB/s
5,120	8,120	Maximaal 15.360	26,064,000	613 miB/s
10,240	13,240	Maximaal 30.720	62,928,000	1.125 MiB/s
33,792	36,792	Maximaal 100.000	227,548,800	3.480 MiB/s
51,200	54,200	Maximaal 100.000	164,880,000	5.220 MiB/s
102,400	100.000	Maximaal 100.000	0	10.340 MiB/s

Controlelijst voor prestaties

Of u nu de prestatievereisten voor een nieuwe of bestaande workload beoordeelt, als u uw gebruikspatronen begrijpt, kunt u voorspelbare prestaties bereiken. Neem contact op met uw opslagbeheerder of toepassingsontwikkelaar om de volgende gebruikspatronen te bepalen.

Latentiegevoeligheid: Openen gebruikers bestanden of werken ze met virtuele bureaubladen die op Azure Files worden uitgevoerd? Dit zijn voorbeelden van workloads die gevoelig zijn voor leeslatentie en ook hoge zichtbaarheid hebben voor eindgebruikers. Deze typen workloads zijn meer geschikt voor premium Azure-bestandsshares, die latentie van één milliseconden kunnen bieden voor zowel lees- als schrijfbewerkingen (< 2 ms voor kleine I/O-grootte).
IOPS- en doorvoervereisten: Premium-bestandsshares ondersteunen grotere IOPS- en doorvoerlimieten dan standaardbestandsshares. Zie Schaaldoelen voor bestandsshares voor meer informatie.
Duur en frequentie van workload: Korte (minuten) en onregelmatige werkbelastingen (per uur) zullen minder snel de hoogste prestatielimieten van standaardbestandsshares bereiken in vergelijking met langlopende, vaak voorkomende workloads. Op Premium-bestandsshares is de duur van de workload handig bij het bepalen van het juiste prestatieprofiel dat moet worden gebruikt op basis van de grootte van de inrichting. Afhankelijk van hoe lang de workload moet bursten en hoe lang deze onder de basislijn-IOPS uitgeeft, kunt u bepalen of u voldoende bursttegoeden verzamelt om consistent te voldoen aan uw workload tijdens piekmomenten. Als u de juiste balans vindt, worden de kosten verlaagd in vergelijking met het over inrichten van de bestandsshare. Een veelvoorkomende fout is het uitvoeren van prestatietests gedurende slechts enkele minuten, wat vaak misleidend is. Als u een realistisch beeld van de prestaties wilt krijgen, moet u testen met een voldoende hoge frequentie en duur.
Parallellisatie van workloads: Voor workloads die bewerkingen parallel uitvoeren, zoals via meerdere threads, processen of toepassingsexemplaren op dezelfde client, bieden Premium-bestandsshares een duidelijk voordeel ten opzichte van standaardbestandsshares: SMB meerdere kanalen. Zie Prestaties van SMB Azure-bestandsshares verbeteren voor meer informatie.
Distributie van API-bewerkingen: zijn de metagegevens van de workload zwaar met bewerkingen voor het openen/sluiten van bestanden? Dit is gebruikelijk voor workloads die leesbewerkingen uitvoeren op een groot aantal bestanden. Zie De workload Metagegevens of naamruimte intensief.

Latentie

Wanneer u nadenkt over latentie, is het belangrijk om eerst te begrijpen hoe latentie wordt bepaald met Azure Files. De meest voorkomende metingen zijn de latentie die is gekoppeld aan end-to-end latentie en metrische gegevens over servicelatentie . Het gebruik van deze metrische transactiegegevens kan helpen bij het identificeren van latentie- en/of netwerkproblemen aan de clientzijde door te bepalen hoeveel tijd uw toepassingsverkeer besteedt aan de overdracht van en naar de client.

End-to-end-latentie (SuccessE2ELatency) is de totale tijd die een transactie nodig heeft om een volledige retour uit te voeren van de client, via het netwerk, naar de Azure Files service en terug naar de client.
Servicelatentie (SuccessServerLatency) is de tijd die nodig is om een transactie alleen binnen de Azure Files-service te afronden. Dit omvat geen client- of netwerklatentie.

Het verschil tussen de waarden SuccessE2ELatency en SuccessServerLatency is de latentie die waarschijnlijk wordt veroorzaakt door het netwerk en/of de client.

Het is gebruikelijk om clientlatentie te verwarren met servicelatentie (in dit geval Azure Files prestaties). Als de servicelatentie bijvoorbeeld lage latentie rapporteert en de end-to-end zeer hoge latentie voor aanvragen rapporteert, betekent dit dat alle tijd wordt besteed aan overdracht van en naar de client en niet in de Azure Files service.

Zoals in het diagram wordt geïllustreerd, is het bovendien zo dat hoe verder u weg bent van de service, hoe langzamer de latentie-ervaring zal zijn en hoe moeilijker het zal zijn om prestatieschaallimieten te bereiken met een cloudservice. Dit geldt met name voor toegang tot Azure Files on-premises. Hoewel opties zoals ExpressRoute ideaal zijn voor on-premises, komen ze nog steeds niet overeen met de prestaties van een toepassing (compute + opslag) die uitsluitend in dezelfde Azure-regio wordt uitgevoerd.

Tip

Het gebruik van een virtuele machine in Azure om de prestaties tussen on-premises en Azure te testen, is een effectieve en praktische manier om de netwerkmogelijkheden van de verbinding met Azure te basislijnen. Vaak kan een workload worden vertraagd door een ondermaats of onjuist gerouteerd ExpressRoute-circuit of VPN-gateway.

Wachtrijdiepte

Wachtrijdiepte is het aantal openstaande I/O-aanvragen dat een opslagresource kan verwerken. Omdat de schijven die door opslagsystemen worden gebruikt, zijn geëvolueerd van HDD-spindels (IDE, SATA, SAS) tot solid-state-apparaten (SSD, NVMe), zijn ze ook ontwikkeld om een hogere wachtrijdiepte te ondersteunen. Een workload die bestaat uit één client die serieel communiceert met één bestand in een grote gegevensset, is een voorbeeld van een lage wachtrijdiepte. Een workload die parallellisme met meerdere threads en meerdere bestanden ondersteunt, kan daarentegen eenvoudig een hoge wachtrijdiepte bereiken. Omdat Azure Files een gedistribueerde bestandsservice is die duizenden Azure-clusterknooppunten omvat en is ontworpen om workloads op schaal uit te voeren, raden we u aan workloads met een hoge wachtrijdiepte te bouwen en te testen.

Hoge wachtrijdiepte kan op verschillende manieren worden bereikt in combinatie met clients, bestanden en threads. Als u de wachtrijdiepte voor uw workload wilt bepalen, vermenigvuldigt u het aantal clients met het aantal bestanden met het aantal threads (clients * bestanden * threads = wachtrijdiepte).

In de onderstaande tabel ziet u de verschillende combinaties die u kunt gebruiken om een hogere wachtrijdiepte te bereiken. Hoewel u de optimale wachtrijdiepte van 64 kunt overschrijden, raden we dit niet aan. Als u dat wel doet, ziet u geen prestatieverbeteringen meer en loopt u het risico dat de latentie toeneemt als gevolg van TCP-verzadiging.

Clients	Bestanden	Threads	Wachtrijdiepte
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

Tip

Als u hogere prestatielimieten wilt bereiken, moet u ervoor zorgen dat uw workload of benchmarktest meerdere threads met meerdere bestanden bevat.

Toepassingen met één of meerdere threads

Azure Files is het meest geschikt voor toepassingen met meerdere threads. De eenvoudigste manier om inzicht te krijgt in de impact van multithreading op een workload is door het scenario per I/O te doorlopen. In het volgende voorbeeld hebben we een workload die zo snel mogelijk 10.000 kleine bestanden van of naar een Azure-bestandsshare moet kopiëren.

Deze tabel bevat de tijd die nodig is (in milliseconden) voor het maken van één 16 KiB-bestand op een Azure-bestandsshare, op basis van een toepassing met één thread die in 4 KiB-blokgrootten wordt geschreven.

I/O-bewerking	Maken	4 KiB schrijven	4 KiB schrijven	4 KiB schrijven	4 KiB schrijven	Sluiten	Totaal
Thread 1	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms

In dit voorbeeld duurt het ongeveer 14 ms om één 16 KiB-bestand te maken op basis van de zes bewerkingen. Als een toepassing met één thread 10.000 bestanden naar een Azure-bestandsshare wil verplaatsen, wordt dit omgezet in 140.000 ms (14 ms * 10.000) of 140 seconden, omdat elk bestand opeenvolgend één voor één wordt verplaatst. Houd er rekening mee dat de tijd voor het verwerken van elke aanvraag voornamelijk wordt bepaald door hoe dicht de rekenkracht en opslag zich bij elkaar bevinden, zoals in de vorige sectie is besproken.

Door acht threads te gebruiken in plaats van één, kan de bovenstaande workload worden teruggebracht van 140.000 ms (140 seconden) tot 17.500 ms (17,5 seconden). Zoals in de onderstaande tabel wordt weergegeven, kunt u, wanneer u acht bestanden parallel verplaatst in plaats van één bestand tegelijk, dezelfde hoeveelheid gegevens in 87,5% minder tijd verplaatsen.

I/O-bewerking	Maken	4 KiB schrijven	4 KiB schrijven	4 KiB schrijven	4 KiB schrijven	Sluiten	Totaal
Thread 1	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 2	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 3	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 4	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 5	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 6	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 7	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 8	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms