Inzicht in en optimalisatie van prestaties van Azure-bestandsshares
Azure Files kan 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 'IO' is interwisselbaar met de termen 'operation' en 'transaction' in de Documentatie van Azure Files.
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 (Input/Output) uit te voeren in de opslag. Afhankelijk van de toepassing kan de I/O-grootte variëren van zeer kleine grootten, zoals 4 KiB tot veel grotere maten. I/O-grootte speelt een belangrijke rol bij haalbare doorvoer.
Doorvoer
Doorvoer meet het aantal bits dat is gelezen van of geschreven naar de opslag per seconde en wordt gemeten in mebibytes per seconde (MiB/s). Als u 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 typen latentie: end-to-end latentie en servicelatentie. Zie Latentie voor meer informatie.
Wachtrijdiepte
De 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 gegevens op het juiste niveau van prestaties en prijzen op te slaan. Op het hoogste niveau biedt Azure Files twee prestatielagen: Standard en Premium. Standard-bestandsshares worden gehost op een opslagsysteem dat wordt ondersteund door harde schijven (HDD), terwijl Premium-bestandsshares worden ondersteund door SSD's (Solid-State Drives) voor betere prestaties. Standard-bestandsshares hebben verschillende opslaglagen (geoptimaliseerd voor transacties, dynamisch en statisch) die u naadloos kunt verplaatsen om de data-at-rest-opslag en transactieprijzen te maximaliseren. U kunt echter niet schakelen tussen standard- en Premium-lagen zonder uw gegevens fysiek tussen verschillende opslagaccounts te migreren.
Wanneer u kiest tussen Standard- en Premium-bestandsshares, is het belangrijk om inzicht te hebben in de vereisten van het verwachte gebruikspatroon dat u wilt uitvoeren in Azure Files. Als u grote hoeveelheden IOPS, zeer snelle gegevensoverdrachtsnelheden of zeer lage latentie nodig hebt, moet u premium Azure-bestandsshares kiezen.
De volgende tabel bevat een overzicht van de verwachte prestatiedoelen tussen Standard en Premium. Zie De schaalbaarheids- en prestatiedoelen van Azure Files voor meer informatie.
| Vereisten voor gebruikspatronen | Standaard | Premium |
|---|---|---|
| Schrijflatentie (milliseconden met één cijfer) | Ja | Ja |
| Leeslatentie (milliseconden met één cijfer) | Nr. | Ja |
Premium-bestandsshares bieden een inrichtingsmodel dat het volgende prestatieprofiel garandeert op basis van de grootte van de share. Zie Ingericht model voor meer informatie. Burst-tegoed wordt verzameld in een burst-bucket wanneer verkeer voor uw bestandsshare lager is dan de basislijn-IOPS. Verdiende tegoeden worden later gebruikt om bursting in te schakelen wanneer bewerkingen de basislijn-IOPS overschrijden.
| Capaciteit (GiB) | IOPS basislijn | Burst IOPS | Burst-tegoed | Doorvoer (inkomend en uitgaand verkeer) |
|---|---|---|---|---|
| 100 | 3,100 | Tot 10.000 | 24,840,000 | 110 MiB/s |
| 500 | 3500 | Tot 10.000 | 23,400,000 | 150 MiB/s |
| 1024 | 4,024 | Tot 10.000 | 21,513,600 | 203 MiB/s |
| 5,120 | 8120 | Tot 15.360 | 26,064,000 | 613 MiB/s |
| 10,240 | 13,240 | Tot 30.720 | 62,928,000 | 1.125 MiB/s |
| 33,792 | 36,792 | Maximaal 100.000 | 227,548,800 | 3480 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 prestatievereisten voor een nieuwe of bestaande workload beoordeelt, door inzicht te krijgen in uw gebruikspatronen, 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 worden uitgevoerd in Azure Files? Dit zijn voorbeelden van workloads die gevoelig zijn voor leeslatentie en die ook een hoge zichtbaarheid hebben voor eindgebruikers. Deze typen workloads zijn geschikter voor Premium Azure-bestandsshares, die latentie van één milliseconde 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 workloads: korte (minuten) en onregelmatige workloads (elk uur) zullen minder waarschijnlijk de hoogste prestatielimieten van standaardbestandsshares bereiken in vergelijking met langlopende, vaak voorkomende workloads. Bij Premium-bestandsshares is de duur van de werkbelasting handig bij het bepalen van het juiste prestatieprofiel dat moet worden gebruikt op basis van de inrichtingsgrootte. Afhankelijk van hoe lang de workload moet bursten en hoe lang deze onder de IOPS van de basislijn wordt besteed, kunt u bepalen of u voldoende bursting-tegoeden verzamelt om consistent te voldoen aan uw workload op piekmomenten. Door het juiste saldo te vinden, worden de kosten verlaagd ten opzichte van het over inrichten van de bestandsshare. Een veelvoorkomende fout is het uitvoeren van prestatietests voor slechts een paar minuten, wat vaak misleidend is. Als u een realistisch beeld wilt krijgen van de prestaties, moet u testen met een voldoende hoge frequentie en duur.
Parallellisatie van workloads: Voor workloads die gelijktijdig bewerkingen 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.
API-bewerkingsdistributie: Zijn de metagegevens van de werkbelasting zwaar met bewerkingen voor het openen/sluiten van bestanden? Dit is gebruikelijk voor workloads die leesbewerkingen uitvoeren op een groot aantal bestanden. Zie de werkbelasting 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 . Door deze metrische gegevens over transacties te gebruiken, kunt u latentie- en/of netwerkproblemen aan de clientzijde identificeren door te bepalen hoeveel tijd uw toepassingsverkeer in transit naar en van de client besteedt.
End-to-endlatentie (SuccessE2ELatency) is de totale tijd die nodig is voor een transactie om een volledige retour van de client, via het netwerk, naar de Azure Files-service en terug naar de client uit te voeren.
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 successE2ELatency- en SuccessServerLatency-waarden 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 prestaties van Azure Files). Als de servicelatentie bijvoorbeeld een lage latentie rapporteert en de end-to-end zeer hoge latentie rapporteert voor aanvragen, betekent dit dat alle tijd wordt besteed aan transit naar en van de client en niet in de Azure Files-service.
Bovendien, zoals in het diagram wordt geïllustreerd, hoe verder u zich niet bij de service bevindt, hoe trager de latentie-ervaring zal zijn en hoe moeilijker het is om prestatieschaallimieten te bereiken met elke cloudservice. Dit geldt met name voor toegang tot Azure Files vanaf on-premises. Hoewel opties zoals ExpressRoute ideaal zijn voor on-premises, komen ze nog steeds niet overeen met de prestaties van een toepassing (compute en opslag) die exclusief in dezelfde Azure-regio worden 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 basislijn te maken. Vaak kan een workload worden vertraagd door een te weinig gerouteerd Of onjuist gerouteerd ExpressRoute-circuit of VPN-gateway.
Wachtrijdiepte
De wachtrijdiepte is het aantal openstaande I/O-aanvragen dat een opslagresource kan verwerken. Naarmate de schijven die door opslagsystemen worden gebruikt, zijn ontwikkeld van HDD-spindles (IDE, SATA, SAS) naar ssd-, NVMe-apparaten (SSD, NVMe), hebben ze zich ook ontwikkeld ter ondersteuning van een hogere wachtrijdiepte. Een workload die bestaat uit één client die serieel interactie heeft met één bestand in een grote gegevensset, is een voorbeeld van een lage wachtrijdiepte. Een workload die ondersteuning biedt voor parallelle uitvoering met meerdere threads en meerdere bestanden, 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.
Een 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 dit doet, ziet u geen prestatieverbeteringen en loopt u het risico dat de latentie toeneemt vanwege 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 benchmarkingtest meerdere threads met meerdere bestanden bevat.
Toepassingen met één versus meerdere threads
Azure Files is het meest geschikt voor toepassingen met meerdere threads. De eenvoudigste manier om inzicht te hebben in de invloed van meerdere threads 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 moet kopiëren naar of van een Azure-bestandsshare.
Deze tabel bevat de benodigde tijd (in milliseconden) voor het maken van één KiB-bestand op een Azure-bestandsshare, op basis van een toepassing met één thread die in vier KiB-blokgrootten schrijft.
| 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 KiB-bestand van 16 kiB 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 sequentieel één voor één wordt verplaatst. Houd er rekening mee dat de tijd die nodig is om elke aanvraag te verwerken, voornamelijk wordt bepaald door hoe dicht de rekenkracht en opslag zich bij elkaar bevinden, zoals besproken in de vorige sectie.
Door acht threads te gebruiken in plaats van één, kan de bovenstaande workload worden verminderd 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 tegelijk verplaatst in plaats van één bestand tegelijk, dezelfde hoeveelheid gegevens in minder dan 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 |