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, caching uitgesloten
In deze benchmark werd FIO uitgevoerd met behulp van luslogica die de cache minder agressief vulde. Clientcaching heeft geen invloed gehad op de resultaten. Deze configuratie resulteert in iets betere schrijfprestaties, maar lagere leesnummers dan tests zonder caching.
In de volgende grafiek laat testen zien dat een normaal Volume van Azure NetApp Files tussen ongeveer 3.600MiB/s pure 64-KiB-leesbewerkingen en ongeveer 2.400MiB/s pure 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.
De mix voor lezen/schrijven voor de workload is voor elke uitvoering aangepast met 25%.
Resultaten: 256 KiB sequentiële I/O, uitgesloten caching
In deze benchmark werd FIO uitgevoerd met behulp van luslogica die de cache minder agressief vulde, zodat caching niet van invloed was op de resultaten. Deze configuratie resulteert in iets minder schrijfprestaties dan 64 KiB-tests, maar hogere leesnummers dan dezelfde 64 KiB-tests worden uitgevoerd zonder caching.
In de onderstaande grafiek ziet u dat een normaal Volume van Azure NetApp Files tussen ongeveer 3500MiB/s pure sequentiële 256-KiB-leesbewerkingen en ongeveer 2500MiB/s pure sequentiële 256-KiB-schrijfbewerkingen kan verwerken. Tijdens de tests vertoonde een mix van 50/50 een piek in de totale doorvoer die hoger was dan een pure sequentieel leesworkload.
De mix voor lezen/schrijven voor de workload is aangepast in stappen van 25% voor elke uitvoering.
Vergelijking naast elkaar
Om beter te laten zien hoe caching invloed kan hebben op de prestatiebenchmarktests, toont de volgende grafiek het totale aantal MiB/s voor 64 KiB-tests met en zonder cachemechanismen. Caching biedt een eerste lichte prestatieverbeteringen voor het totale aantal MiB/s, omdat caching in het algemeen meer leesbewerkingen verbetert dan schrijfbewerkingen. Naarmate de lees-/schrijfmix verandert, overschrijdt de totale doorvoer zonder caching de resultaten die gebruikmaken van clientcaching.
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: 64 KiB, sequentiële, uitgesloten caching, met en zonder nconnect
De volgende resultaten tonen de resultaten van een opschaaltest bij het lezen en schrijven in 4 KiB-segmenten op een NFSv3-koppeling op één client met en zonder parallellisatie van bewerkingen (nconnect). In de grafieken ziet u dat naarmate de I/O-diepte groeit, de I/OPS ook toeneemt. Maar 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 per koppelpunt kan gebruiken. Daarnaast is de totale latentie voor de bewerkingen over het algemeen lager bij gebruik nconnect.
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.
