Prestandamått för stora volymer för Azure NetApp Files för Linux
Den här artikeln beskriver de testade prestandafunktionerna för en enda Stor Azure NetApp Files-volym som gäller för Linux-användningsfall. Testerna utforskade scenarier för både utskalning och uppskalning av läs- och skrivarbetsbelastningar, med en och flera virtuella datorer (VM). Genom att känna till prestandakuvertet för stora volymer kan du underlätta volymstorleken.
Testsammanfattning
Funktionen Stora volymer i Azure NetApp Files erbjuder tre tjänstnivåer, var och en med dataflödesgränser. Tjänstnivåerna kan skalas upp eller ned utan avbrott när dina prestandabehov ändras.
- Ultra servicenivå: 12 800 MiB/s
- Premium servicenivå: 6 400 MiB/s
- Standardtjänstnivå: 1 600 MiB/s
Ultra-tjänstnivån användes i dessa tester.
Sekventiella skrivningar: 100 % sekventiella skrivningar maxade på ~8 500 MiB/sekund i dessa riktmärken. (En enda stor volyms maximala dataflöde begränsas till 12 800 MiB/sekund av tjänsten, så mer potentiellt dataflöde är möjligt.)
Sekventiella läsningar: 100 % sekventiella läsningar maxade på ~12 761 MiB/sekund i dessa riktmärken. (En enda stor volyms dataflöde är begränsat till 12 800 MiB/sekund. Det här resultatet är nära det maximala möjliga dataflödet just nu.)
Slumpmässig I/O: Samma stora volym levererar över 700 000 åtgärder per sekund.
Metadataintensiva arbetsbelastningar är fördelaktiga för stora Volymer i Azure NetApp File på grund av den stora volymens ökade parallellitet. Prestandafördelar märks i arbetsbelastningar som är tunga vid filskapande, avlänkning och filbyten som typiska för VCS-program och EDA-arbetsbelastningar där det finns höga filantal. Mer information om prestanda för höga metadataarbetsbelastningar finns i Fördelar med att använda Azure NetApp Files för automatisering av elektronisk design.
FIO, en syntetisk arbetsbelastningsgenerator som utformats som ett stresstest för lagring, användes för att köra dessa testresultat. Det finns i grunden två modeller för testning av lagringsprestanda:
- Skalbar beräkning, som refererar till att använda flera virtuella datorer för att generera maximal belastning på en enda Azure NetApp Files-volym.
- Uppskalningsberäkning, som refererar till att använda en stor virtuell dator för att testa de övre gränserna för en enskild klient på en enda Azure NetApp Files-volym.
Utskalningstest för Linux
Tester observerade prestandatrösklar för en enda stor volym vid utskalning och genomfördes med följande konfiguration:
| Komponent | Konfiguration |
|---|---|
| Storlek på Azure-VM | E32s_v5 |
| Gräns för utgående bandbredd för virtuella Azure-datorer | 2000MiB/s (2GiB/s) |
| Operativsystem | RHEL 8.4 |
| Stor volymstorlek | 101 TiB Ultra (12 800 MiB/s-dataflöde) |
| Monteringsalternativ | hard,rsize=65536,wsize=65536,vers=3 Obs! Användning av både 262144 och 65536 hade liknande prestandaresultat. |
256-KiB sekventiella arbetsbelastningar (MiB/s)
Diagrammet representerar en sekventiell arbetsbelastning på 256 KiB med 12 virtuella datorer som läser och skriver till en enda stor volym med hjälp av en 1 TiB-arbetsuppsättning. Diagrammet visar att en enda stor Azure NetApp Files-volym kan hantera mellan cirka 8 518 MiB/s rena sekventiella skrivningar och 12 761 MiB/s rena sekventiella läsningar.
8-KiB slumpmässig arbetsbelastning (IOPS)
Diagrammet representerar en slumpmässig arbetsbelastning med 8 KiB och en 1 TiB-arbetsuppsättning. Diagrammet visar att en stor Azure NetApp Files-volym kan hantera mellan cirka 474 000 rena slumpmässiga skrivningar och cirka 709 000 rena slumpmässiga läsningar.
Uppskalningstester för Linux
Medan utskalningstester är utformade för att hitta gränserna för en enda stor volym, är uppskalningstester utformade för att hitta de övre gränserna för en enda instans mot den stora volymen. Azure placerar utgående gränser för nätverket på sina virtuella datorer. för nätverksansluten lagring innebär det att skrivbandbredden begränsas per virtuell dator. Dessa uppskalningstester visar funktioner med tanke på det stora tillgängliga bandbreddstaket och med tillräckligt med processorer för att driva nämnda arbetsbelastning.
Testerna i det här avsnittet kördes med följande konfiguration:
| Komponent | Konfiguration |
|---|---|
| Storlek på Azure-VM | E104id_v5 |
| Gräns för utgående bandbredd för virtuella Azure-datorer | 12 500MiB/s (12,2GiB/s) |
| Operativsystem | RHEL 8.4 |
| Stor volymstorlek | 101 TiB Ultra (12 800 MiB/s-dataflöde) |
| Monteringsalternativ | hard,rsize=65536,wsize=65536,vers=3 Obs! Användning av både 262144 och 65536 hade liknande prestandaresultat |
Diagram i det här avsnittet visar resultatet för monteringsalternativet nconnect på klientsidan med NFSv3. Mer information finns i Metodtips för Linux NFS-monteringsalternativ för Azure NetApp File.
I följande diagram jämförs fördelarna nconnect med med en NFS-monterad volym utan nconnect. I testerna genererade FIO arbetsbelastningen från en enda E104id-v5-instans i Azure-regionen USA, östra med en sekventiell arbetsbelastning på 64 KiB. en storlek på 256 I/0 användes, vilket är den största I/O-storlek som rekommenderas av Azure NetApp Files, vilket resulterade i jämförbara prestandasiffror. Mer information finns i rsize och wsize.
Linux-läsdataflöde
Följande diagram visar sekventiella 256 KiB-läsningar på cirka 10 000 M iB/s med nconnect, vilket är ungefär tio gånger det dataflöde som uppnås utan nconnect.
Observera att 10 000 MiB/s är ungefär linjehastigheten för nätverksgränssnittskortet på 100 Gbit/s som är kopplat till E104id_v5.
Linux-skrivdataflöde
Följande diagram visar sekventiella skrivningar. Användning nconnect ger observerbara fördelar för sekventiella skrivningar på 6 600 MiB/s, ungefär fyra gånger fler än monteringar utan nconnect.
Linux-läs-IOPS
Följande diagram visar slumpmässiga läsningar på 8 KiB på ~426 000 lästa IOPS med nconnect, ungefär sju gånger så mycket som observeras utan nconnect.
Linux-skriv-IOPS
Följande diagram visar slumpmässiga skrivningar av ~405 000 skrivnings-IOPS med nconnect, ungefär 7,2 gånger så mycket som det som observeras utan nconnect.
