Standaardbenchmarks voor volumeprestaties van Azure NetApp Files voor Linux
In dit artikel worden prestatiebenchmarks beschreven die azure NetApp Files levert voor Linux met een normaal volume.
Workloads voor het streamen van hele bestanden (scale-out benchmarktests)
Het doel van een uitschaaltest is om de prestaties van een Azure NetApp File-volume weer te geven bij het uitschalen (of verhogen) van het aantal clients dat gelijktijdige workload naar hetzelfde volume genereert. Deze tests kunnen over het algemeen een volume naar de rand van de prestatielimieten pushen en wijzen op workloads zoals mediarendering, AI/ML en andere workloads die gebruikmaken van grote rekenfarms om werk uit te voeren.
High I/OP scale-out benchmarkconfiguratie
Deze benchmarks hebben het volgende gebruikt:
- Eén normaal volume van Azure NetApp Files 100-TiB met een 1 TiB-gegevensset met behulp van de Ultra-prestatielaag
- FIO (met en zonder randrepeat=0)
- 4-KiB en 8-KiB blokgrootten
- 6 D32s_v5 virtuele machines met RHEL 9.3
- NFSv3
- Handmatige QoS
- Koppelopties: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Configuratie van scale-out-benchmark voor hoge doorvoer
Deze benchmarks hebben het volgende gebruikt:
- Eén normaal Azure NetApp Files-volume met een 1-TiB-gegevensset met behulp van de FIO met ultraprestaties (met en zonder randrepeat=0)
- FIO (met en zonder randrepeat=0)
- 64-KiB en blokgrootte 256-KiB
- 6 D32s_v5 virtuele machines met RHEL 9.3
- NFSv3
- Handmatige QoS
- Koppelopties: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Benchmarkconfiguratie voor parallelle netwerkverbindingen (nconnect)
Deze benchmarks hebben het volgende gebruikt:
- Eén normaal Azure NetApp Files-volume met een 1-TiB-gegevensset met behulp van de Ultra-prestatielaag
- FIO (met en zonder randrepeat=0)
- 4-KiB en 64-KiB wsize/rsize
- Eén D32s_v4 virtuele machine met RHEL 9.3
- NFSv3 met en zonder
nconnect - Koppelopties: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg
Benchmarktests omhoog schalen
De intentie van de opschaaltest is om de prestaties van een Azure NetApp File-volume weer te geven bij het omhoog schalen (of verhogen) van het aantal taken dat gelijktijdige workload genereert voor meerdere TCP-verbindingen op één client met hetzelfde volume (zoals met nconnect).
Zonder nconnectkunnen deze workloads de limieten van de maximale prestaties van een volume niet pushen, omdat de client niet voldoende IO- of netwerkdoorvoer kan genereren. Deze tests geven over het algemeen aan wat de ervaring van één gebruiker kan zijn in workloads zoals mediarendering, databases, AI/ML en algemene bestandsshares.
Hoge I/OP scale-outbenchmarks
De volgende benchmarks tonen de prestaties die zijn behaald voor Azure NetApp Files met een hoge I/OP-workload met behulp van:
- 32 clients
- 4-KiB en 8-KiB willekeurige lees- en schrijfbewerkingen
- 1-TiB-gegevensset
- Lees-/schrijfverhoudingen als volgt: 100%:0%, 90%:10%, 80%:20%, enzovoort
- Met en zonder bestandssysteemcaching betrokken (gebruik
randrepeat=0in FIO)
Zie Testmethodologie voor meer informatie.
Resultaten: 4 KiB, willekeurige, clientcaching opgenomen
In deze benchmark werd FIO uitgevoerd zonder de randrepeat optie om gegevens willekeurig te maken. Er is dus een onbepaalde hoeveelheid caching in het spel gekomen. Deze configuratie resulteert in iets betere algemene prestatienummers dan tests worden uitgevoerd zonder caching, waarbij de volledige IO-stack wordt gebruikt.
In de volgende grafiek ziet u dat een normaal Volume van Azure NetApp Files tussen ongeveer 130.000 pure willekeurige 4 KiB-schrijfbewerkingen en ongeveer 460.000 pure willekeurige 4 KiB-leesbewerkingen tijdens deze benchmark kan verwerken. Mix van lezen/schrijven voor de workload aangepast met 10% voor elke uitvoering.
Naarmate de I/OP-mix voor lezen/schrijven toeneemt naar schrijfintensief, neemt de totale I/OPS af.
Resultaten: 4 KiB, willekeurig, clientcaching uitgesloten
In deze benchmark werd FIO uitgevoerd met de instelling randrepeat=0 om gegevens willekeurig te maken, waardoor de invloed van caching op de prestaties wordt verminderd. Dit heeft geleid tot een vermindering van ongeveer 8% in schrijf-I/OPS en een vermindering van ongeveer 17% in lees-I/OPS, maar geeft prestatienummers weer die beter representatief zijn voor wat de opslag daadwerkelijk kan doen.
In de volgende grafiek ziet u dat een normaal Azure NetApp Files-volume tussen ongeveer 120.000 pure willekeurige 4 KiB-schrijfbewerkingen en ongeveer 388.000 pure willekeurige 4-KiB-leesbewerkingen kan verwerken. Mix van lezen/schrijven voor de workload aangepast met 25% voor elke uitvoering.
Naarmate de I/OP-mix voor lezen/schrijven toeneemt naar schrijfintensief, neemt de totale I/OPS af.
Resultaten: 8 KiB, willekeurig, clientcaching uitgesloten
Grotere lees- en schrijfgrootten resulteren in minder totale I/OPS, omdat er bij elke bewerking meer gegevens kunnen worden verzonden. Een lees- en schrijfgrootte van 8 KiB is gebruikt om nauwkeuriger te simuleren wat de meeste moderne toepassingen gebruiken. Veel EDA-toepassingen maken bijvoorbeeld gebruik van 8-KiB-lees- en schrijfbewerkingen.
In deze benchmark werd FIO uitgevoerd om randrepeat=0 gegevens willekeurig te maken, zodat de impact op de cache van de client is verminderd. In de volgende grafiek ziet u dat een normaal Azure NetApp Files-volume tussen ongeveer 111.000 pure willekeurige 8 KiB-schrijfbewerkingen en ongeveer 293.000 pure willekeurige 8 KiB-leesbewerkingen kan verwerken. Mix van lezen/schrijven voor de workload aangepast met 25% voor elke uitvoering.
Naarmate de I/OP-mix voor lezen/schrijven toeneemt naar schrijfintensief, neemt de totale I/OPS af.
Vergelijkingen naast elkaar
Om te illustreren hoe caching invloed kan hebben op de prestatiebenchmarktests, toont de volgende grafiek het totale aantal I/OPS voor 4 KiB-tests met en zonder cachemechanismen. Zoals u ziet, biedt caching een lichte prestatieverbeteringen voor I/OPS redelijk consistente trending.
Specifieke offset, willekeurige lees-/schrijfworkloads streamen: omhoog schalen met behulp van parallelle netwerkverbindingen (nconnect)
De volgende tests tonen een hoge I/OP-benchmark met één client met 4-KiB-willekeurige workloads en een 1 TiB-gegevensset. De gegenereerde workloadmix maakt elke keer gebruik van een andere I/O-diepte. Om de prestaties voor één clientworkload te verbeteren, werd de nconnect koppelingsoptie gebruikt om parallellisme te verbeteren in vergelijking met clientkoppelingen zonder de nconnect koppelingsoptie.
Wanneer u een standaard-TCP-verbinding gebruikt die slechts één pad naar de opslag biedt, worden er minder totale bewerkingen per seconde verzonden dan wanneer een koppeling meer TCP-verbindingen (zoals met nconnect) per koppelpunt kan gebruiken. Bij gebruik nconnectis de totale latentie voor de bewerkingen over het algemeen lager. Deze tests worden ook uitgevoerd om randrepeat=0 opzettelijk caching te voorkomen. Zie Testmethodologie voor meer informatie over deze optie.
Resultaten: 4 KiB, willekeurig, met en zonder nconnect, caching uitgesloten
In de volgende grafieken ziet u een vergelijking van 4 KiB-lees- en schrijfbewerkingen met en zonder nconnect om de prestatieverbeteringen te markeren die worden gezien bij het gebruik nconnectvan: hogere algemene I/OPS, lagere latentie.
Benchmarks voor hoge doorvoer
De volgende benchmarks tonen de prestaties die zijn behaald voor Azure NetApp Files met een hoge doorvoerworkload.
Workloads met een hoge doorvoer zijn meer opeenvolgend en zijn vaak veel lees-/schrijfbewerkingen met lage metagegevens. Doorvoer is over het algemeen belangrijker dan I/OPS. Deze workloads maken doorgaans gebruik van grotere lees-/schrijfgrootten (64K tot 256K), die hogere latenties genereren dan kleinere lees-/schrijfgrootten, omdat grotere nettoladingen natuurlijk langer duren om te worden verwerkt.
Voorbeelden van workloads met hoge doorvoer zijn:
- Mediaopslagplaatsen
- Krachtig rekenvermogen
- AI/ML/LLP
De volgende tests tonen een benchmark voor hoge doorvoer met zowel 64-KiB als 256-KiB sequentiële workloads en een 1-TiB-gegevensset. De gegenereerde workloadmix vermindert een bepaald percentage tegelijk en laat zien wat u kunt verwachten wanneer u verschillende lees-/schrijfverhoudingen gebruikt (bijvoorbeeld 100%:0%, 90%:10%, 80%:20%, enzovoort).
Resultaten: 64 KiB sequentiële I/O, caching inbegrepen
In deze benchmark werd FIO uitgevoerd met behulp van luslogica die de cache agressiever vulde, dus een onbepaalde hoeveelheid caching beïnvloedde de resultaten. Dit resulteert in iets betere algemene prestatienummers dan tests worden uitgevoerd zonder caching.
In de onderstaande grafiek ziet u dat een normaal Volume van Azure NetApp Files tussen ongeveer 4.500MiB/s pure sequentiële 64-KiB-leesbewerkingen en ongeveer 1.600MiB/s pure sequentiële 64-KiB-schrijfbewerkingen kan verwerken. De mix voor lezen/schrijven voor de workload is voor elke uitvoering met 10% aangepast.
Resultaten: 64 KiB sequentiële I/O, leesbewerkingen versus schrijven, basislijn zonder caching
In deze basislijnbenchmark ziet u dat een normaal Azure NetApp Files-volume tussen ongeveer 3.600 MiB/s zuivere 64-KiB-leesbewerkingen en ongeveer 2.400 MiB/seconde zuivere 64-KiB-schrijfbewerkingen kan verwerken. Tijdens de tests toonde een mix van 50/50 de totale doorvoer op hetzelfde als een pure sequentiële leesworkload.
Wat puur lezen betreft, presteerde de 64-KiB-basislijn iets beter dan de 256-KiB-basislijn. Als het gaat om pure schrijf- en alle gemengde werkbelastingen voor lezen/schrijven, presteerde de 256-KiB-basislijn echter beter dan 64 KiB, wat aangeeft dat een grotere blokgrootte van 256 KiB over het algemeen effectiever is voor workloads met hoge doorvoer.
De mix voor lezen/schrijven voor de workload is voor elke uitvoering aangepast met 25%.
Resultaten: 256 KiB sequentiële I/O zonder caching
In de volgende twee basislijnbenchmarks werd FIO gebruikt om de hoeveelheid sequentiële I/O (lezen en schrijven) te meten die één normaal volume in Azure NetApp Files kan leveren. Om een basislijn te produceren die overeenkomt met de werkelijke bandbreedte die een volledig niet-opgeslagen leesworkload kan bereiken, is FIO geconfigureerd voor uitvoering met de parameter randrepeat=0 voor het genereren van gegevenssets. Elke testiteratie werd verschoven door een volledig afzonderlijke grote gegevensset te lezen die geen deel uitmaakt van de benchmark om caching te wissen die mogelijk is opgetreden met de benchmarkgegevensset.
In deze grafiek ziet u dat een reguliere Azure NetApp Files-volume kan verwerken tussen ongeveer 3500 MiB/s pure sequentiële 256-KiB-leesbewerkingen en ongeveer 2500 MiB/s pure sequentiële 256-KiB-schrijfbewerkingen. Tijdens de tests vertoonde een mix van 50/50 een piek in de totale doorvoer die hoger was dan een pure sequentieel leesworkload.
Parallelle netwerkverbindingen (nconnect)
De volgende tests tonen een hoge I/OP-benchmark met één client met willekeurige workloads van 64 KiB en een 1 TiB-gegevensset. De gegenereerde workloadmix maakt elke keer gebruik van een andere I/O-diepte. Om de prestaties voor één clientworkload te verbeteren, werd de nconnect koppelingsoptie gebruikt voor betere parallelle uitvoering in vergelijking met clientkoppelingen die de nconnect koppelingsoptie niet gebruikten. Deze tests werden alleen uitgevoerd met caching uitgesloten.
Resultaten: 64KiB sequentiële I/O, vergelijking van doorvoercache lezen
Om te laten zien hoe caching invloed heeft op de prestatieresultaten, is FIO gebruikt in de volgende micro-benchmarkvergelijking om de hoeveelheid sequentiële I/O (lezen en schrijven) één normaal volume in Azure NetApp Files te meten. Deze test wordt gecontrast met de voordelen die een gedeeltelijk cachebare workload kan bieden.
In het resultaat zonder caching is testen ontworpen om te voorkomen dat caching plaatsvindt, zoals beschreven in de bovenstaande basislijnbenchmarks.
In het andere resultaat werd FIO gebruikt voor reguliere Azure NetApp Files-volumes zonder de randrepeat=0 parameter en met behulp van een herhalende test-iteratielogica die de cache langzaam in de loop van de tijd vulde. De combinatie van deze factoren heeft een onbepaalde hoeveelheid caching geproduceerd, waardoor de totale doorvoer wordt gestimuleerd. Deze configuratie resulteerde in iets betere algemene leesprestaties dan tests worden uitgevoerd zonder caching.
De testresultaten die in de grafiek worden weergegeven, geven de vergelijking van leesprestaties naast elkaar weer met en zonder de invloed van caching, waarbij caching tot ~4500 MiB/seconde leesdoorvoer heeft geproduceerd, terwijl er geen caching rond ~3600 MiB/seconde is bereikt.
Vergelijking naast elkaar (met en zonder nconnect)
In de volgende grafieken ziet u een vergelijking van 64 KiB-sequentiële lees- en schrijfbewerkingen met en zonder nconnect de prestatieverbeteringen te markeren die worden gezien bij het gebruik nconnectvan: hogere totale doorvoer, lagere latentie.
