Azure NetApp Files- benchmarks voor grote volumeprestaties voor Linux
In dit artikel worden de geteste prestatiemogelijkheden van één Grote Azure NetApp Files-volumes beschreven, omdat deze betrekking hebben op Linux-use cases. De tests hebben scenario's verkend voor zowel uitschalen als omhoog schalen van lees- en schrijfworkloads, waarbij één en veel virtuele machines (VM's) betrokken zijn. Als u de prestatieenvelop van grote volumes kent, kunt u de grootte van volumes vergemakkelijken.
Samenvatting testen
De azure NetApp Files-functie voor grote volumes biedt drie serviceniveaus, elk met doorvoerlimieten. De serviceniveaus kunnen niet-afgebroken omhoog of omlaag worden geschaald naarmate uw prestatiebehoeften veranderen.
- Ultraserviceniveau: 12.800 MiB/s
- Premium-serviceniveau: 6.400 MiB/s
- Standaardserviceniveau: 1.600 MiB/s
Het Ultra-serviceniveau is in deze tests gebruikt.
Sequentiële schrijfbewerkingen: 100% sequentiële schrijfbewerkingen zijn maximaal 8500 MiB/seconde in deze benchmarks. (De maximale doorvoer van één groot volume wordt beperkt tot 12.800 MiB/seconde door de service, zodat er meer potentiële doorvoer mogelijk is.)
Sequentiële leesbewerkingen: 100% sequentiële leesbewerkingen zijn maximaal 12.761 MiB/seconde in deze benchmarks. (De doorvoer van één groot volume wordt beperkt tot 12.800 MiB/seconde. Dit resultaat is op dit moment bijna de maximale haalbare doorvoer.)
Willekeurige I/O: Hetzelfde grote volume levert meer dan 700.000 bewerkingen per seconde.
Workloads met veel metagegevens zijn voordelig voor grote volumes van Azure NetApp File vanwege de toegenomen parallelle uitvoering van het grote volume. De prestatievoordelen zijn merkbaar in workloads die zwaar zijn bij het maken, ontkoppelen en hernoemen van bestanden, zoals gebruikelijk bij VCS-toepassingen en EDA-workloads waar grote aantallen bestanden aanwezig zijn. Zie Voordelen van het gebruik van Azure NetApp Files voor elektronische ontwerpautomatisering voor meer informatie over de prestaties van workloads met hoge metagegevens.
FIO, een synthetische workloadgenerator die is ontworpen als een opslagstresstest, werd gebruikt om deze testresultaten te besturen. Er zijn fundamenteel twee modellen voor het testen van opslagprestaties:
- Uitschalen van rekenkracht, die verwijst naar het gebruik van meerdere VM's om de maximale belasting te genereren op één Azure NetApp Files-volume.
- Scale-up compute, dat verwijst naar het gebruik van een grote VIRTUELE machine om de bovengrenzen van één client op één Azure NetApp Files-volume te testen.
Uitschaaltest voor Linux
Tests waargenomen prestatiedrempels van één groot volume op uitschalen en werden uitgevoerd met de volgende configuratie:
| Onderdeel | Configuratie |
|---|---|
| Azure VM-grootte | E32s_v5 |
| Bandbreedtelimiet voor uitgaand verkeer van Azure-VM | 2000MiB/s (2GiB/s) |
| Besturingssysteem | RHEL 8.4 |
| Grote volumegrootte | 101 TiB Ultra (doorvoer van 12.800 MiB/s) |
| Koppelingsopties | hard,rsize=65536,wsize=65536,vers=3 OPMERKING: Het gebruik van zowel 262144 als 65536 had vergelijkbare prestatieresultaten. |
256-KiB sequentiële workloads (MiB/s)
De grafiek vertegenwoordigt een 256-KiB-sequentieel workload met behulp van 12 virtuele machines die naar één groot volume lezen en schrijven met behulp van een 1-TiB-werkset. In de grafiek ziet u dat één groot volume van Azure NetApp Files tussen ongeveer 8.518 MiB/s pure sequentiële schrijfbewerkingen en 12.761 MiB/s pure sequentiële leesbewerkingen kan verwerken.
8-KiB random workload (IOPS)
De grafiek vertegenwoordigt een willekeurige werkbelasting van 8 KiB en een 1 TiB-werkset. In de grafiek ziet u dat een groot volume van Azure NetApp Files tussen ongeveer 474.000 pure willekeurige schrijfbewerkingen en ongeveer 709.000 pure willekeurige leesbewerkingen kan verwerken.
Opschalen van Linux-tests
Terwijl uitschalingstests zijn ontworpen om de limieten van één groot volume te bepalen, zijn opschalingstests ontworpen om de bovengrens van één exemplaar te vinden ten opzichte van dit grote volume. Azure plaatst netwerkuitgangslimieten op de VM's; voor opslag die is gekoppeld aan het netwerk, wat betekent dat de schrijfbandbreedte per VIRTUELE machine wordt beperkt. Deze opschaaltests demonstreren mogelijkheden gezien de grote beschikbare bandbreedtelimiet en met voldoende processors om deze workload te stimuleren.
De tests in deze sectie zijn uitgevoerd met de volgende configuratie:
| Onderdeel | Configuratie |
|---|---|
| Azure VM-grootte | E104id_v5 |
| Bandbreedtelimiet voor uitgaand verkeer van Azure-VM | 12.500MiB/s (12.2GiB/s) |
| Besturingssysteem | RHEL 8.4 |
| Grote volumegrootte | 101 TiB Ultra (doorvoer van 12.800 MiB/s) |
| Koppelingsopties | hard,rsize=65536,wsize=65536,vers=3 OPMERKING: Het gebruik van zowel 262144 als 65536 had vergelijkbare prestatieresultaten |
In de grafieken in deze sectie ziet u de resultaten voor de koppelingsoptie aan de clientzijde van nconnect NFSv3. Zie de aanbevolen procedures voor koppelen van Linux NFS voor Azure NetApp File voor meer informatie.
De volgende grafieken vergelijken de voordelen van nconnect een NFS-gekoppeld volume zonder nconnect. In de tests heeft FIO de workload gegenereerd van één E104id-v5-exemplaar in de Azure-regio VS - oost met behulp van een 64-KiB-sequentieel workload; Er is een grootte van 256 I/0 gebruikt. Dit is de grootste I/O-grootte die door Azure NetApp Files wordt aanbevolen, resulteert in vergelijkbare prestatienummers. Zie voor meer informatie rsize en wsize.
Leesdoorvoer voor Linux
De volgende grafieken tonen 256-KiB sequentiële leesbewerkingen van ongeveer 10.000 M iB/s met nconnect, wat ongeveer tien keer de doorvoer is bereikt zonder nconnect.
Houd er rekening mee dat 10.000 MiB/s ongeveer de lijnsnelheid is van de 100 Gbps-netwerkinterfacekaart die is gekoppeld aan de E104id_v5.
Linux-schrijfdoorvoer
In de volgende grafieken worden sequentiële schrijfbewerkingen weergegeven. Het gebruik nconnect biedt waarneembare voordelen voor sequentiële schrijfbewerkingen op 6.600 MiB/s, ongeveer vier keer dat van koppels zonder nconnect.
IOPS lezen in Linux
De volgende grafieken tonen 8-KiB willekeurige leesbewerkingen van ~426.000 lees-IOPS met nconnect, ongeveer zeven keer wat wordt waargenomen zonder nconnect.
Linux-schrijf-IOPS
De volgende grafieken tonen 8-KiB willekeurige schrijfbewerkingen van ~405.000 schrijf-IOPS met nconnect, ongeveer 7,2 keer dat wat wordt waargenomen zonder nconnect.
