Prestaties verbeteren voor NFS Azure-bestandsdelingen

Van toepassing op: ✔️ NFS-bestandsshares

Dit artikel biedt verschillende manieren om de prestaties voor netwerkbestandssystemen (NFS) Azure-bestandsdelingen te verbeteren. Onderwerpen zijn onder andere het configureren van de Linux-kernelparameter read_ahead_kb voor een betere sequentiële leesdoorvoer, het gebruik van de nconnect mount-optie om de doorvoer te schalen met minder clientmachines, en het plaatsen van je opslagaccount in dezelfde beschikbaarheidszone als je clients om de latentie te verminderen.

De vooruitloopgrootte vergroten om de leesdoorvoer te verbeteren

De read_ahead_kb kernelparameter in Linux vertegenwoordigt de hoeveelheid gegevens die 'vooruit lezen' moet zijn of die vooraf moeten worden opgehaald tijdens een sequentiële leesbewerking. Linux-kernelversies vóór 5.4 stellen de waarde voor lezen in op het equivalent van 15 keer de gekoppelde bestandssysteem rsize, die de koppelingsoptie aan de clientzijde vertegenwoordigt voor de leesbuffergrootte. Hiermee stelt u in de meeste gevallen de read-ahead waarde hoog genoeg in om de leesprestaties van de client te verbeteren.

Vanaf Linux-kernelversie 5.4 gebruikt de Linux NFS-client echter een standaardwaarde read_ahead_kb van 128 KiB. Deze kleinere waarde kan de leesdoorvoer voor grote bestanden verminderen. Gebruikers die upgraden van Linux-releases met een hogere readahead waarde naar releases met de standaard 128 KiB, kunnen een afname van sequentiële leesprestaties ervaren.

Voor Linux-kernels 5.4 of later, stel de read_ahead_kb continu in op 15 MiB voor betere prestaties.

Als u deze waarde wilt wijzigen, stelt u de leesgrootte in door een regel toe te voegen in udev, een Linux-kernelapparaatbeheer. Volg vervolgens deze stappen:

1. Maak in een teksteditor het bestand /etc/udev/rules.d/99-nfs.rules door de volgende tekst in te voeren en op te slaan:

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. Pas in een console de udev-regel toe door de opdracht udevadm uit te voeren als supergebruiker en de regelbestanden en andere databases opnieuw te laden. Je hoeft dit commando maar één keer uit te voeren om Udev op de hoogte te stellen van het nieuwe bestand.

   sudo udevadm control --reload
   

NFS nconnect

NFS nconnect is een client-side mount-optie voor NFS-bestandsdelingen die je gebruikt om meerdere TCP-verbindingen te maken tussen de client en je NFS-bestandsdeling. Het is vooral nuttig voor grootschalige workloads waarbij één enkele TCP-verbinding een bottleneck wordt.

nconnect-voordelen

Met nconnect kunt u de prestaties op schaal verbeteren met minder clientcomputers om de totale eigendomskosten (TCO) te verlagen. De nconnect-functie verhoogt de prestaties door meerdere TCP-kanalen op een of meer NIC's te gebruiken, met behulp van één of meerdere clients. Zonder nconnect heb je ongeveer 20 clientmachines nodig om de bandbreedtelimieten (10 GiB/sec) te bereiken die de grootste SSD-bestandsdelingsprovisioning size biedt. Met nconnect kunt u deze limieten bereiken met slechts 6-7 clients, waardoor de rekenkosten met bijna 70% worden verlaagd en tegelijkertijd aanzienlijke verbeteringen in I/O-bewerkingen per seconde (IOPS) en doorvoer op schaal worden geboden. Zie de onderstaande tabel.

nconnect-vereisten

• De nieuwste Linux-distributies bieden volledige ondersteuning voor nconnect. Voor oudere Linux-distributies moet u ervoor zorgen dat de Linux-kernelversie 5.3 of hoger is.
• Configuratie per mount wordt alleen ondersteund wanneer een enkele bestandsshare per opslagaccount via een privé-eindpunt wordt gebruikt.

Invloed op de prestaties

De volgende prestatieresultaten zijn gemeten met de nconnect mount-optie en Azure NFS-bestandsshares op Linux-clients op grote schaal. Voor meer informatie over hoe deze resultaten zijn bereikt, zie prestatietestconfiguratie.

nconnect aanbevelingen

Volg deze aanbevelingen om de beste resultaten te krijgen van nconnect.

Instellen nconnect=4

Hoewel Azure Files het instellen van nconnect ondersteunt tot de maximale instelling van 16, configureer je de mount-opties met de optimale instelling nconnect=4. Momenteel zijn er geen voordelen meer dan vier kanalen voor de Azure Files-implementatie van nconnect. In feite kan het overschrijden van vier kanalen tot één Azure-bestandsshare van één client de prestaties nadelig beïnvloeden vanwege de verzadiging van het TCP-netwerk.

Grootte van virtuele machines zorgvuldig aanpassen

Afhankelijk van uw workloadvereisten is het belangrijk om de grootte van de virtuele machines van de client (VM's) correct te bepalen om te voorkomen dat deze worden beperkt door de verwachte netwerkbandbreedte. U hebt geen meerdere netwerkinterfacecontrollers (NIC's) nodig om de verwachte netwerkdoorvoer te bereiken. Hoewel het gebruikelijk is om vm's voor algemeen gebruik te gebruiken met Azure Files, zijn er verschillende VM-typen beschikbaar, afhankelijk van uw workloadbehoeften en beschikbaarheid van regio's. Zie Azure VM Selector voor meer informatie.

Wachtrijdiepte kleiner dan of gelijk aan 64 houden

De wachtrijdiepte is het aantal in behandeling zijnde I/O-aanvragen dat een opslagresource kan verwerken. We raden u niet aan om de optimale wachtrijdiepte van 64 te overschrijden, omdat u geen prestatieverbeteringen meer ziet. Zie Wachtrijdiepte voor meer informatie.

Configuratie per koppeling

Als voor een workload meerdere shares vanaf één client moeten worden gekoppeld met één of meer opslagaccounts met verschillende nconnect-instellingen, wordt niet gegarandeerd dat die instellingen behouden blijven bij koppeling via het openbare eindpunt. De configuratie per mount ondersteunt slechts één Azure-bestandsdeling per opslagaccount over het private endpoint, zoals beschreven in scenario 1.

Scenario 1: configuratie per koppeling via privé-eindpunt met meerdere opslagaccounts (ondersteund)

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Scenario 2: configuratie per koppeling via openbaar eindpunt (niet ondersteund)

• StorageAccount.file.core.windows.net = 52.239.238.8
• StorageAccount2.file.core.windows.net = 52.239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Scenario 3: per koppelingsconfiguratie via privé-eindpunt met meerdere shares in één opslagaccount (niet ondersteund)

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Configuratie van prestatietest

Om de resultaten in dit artikel te bereiken en te meten, gebruik je de volgende bronnen en benchmarkingtools.

• Eén client: Azure VM (DSv4-serie) met één NIC
• OS: Linux (Ubuntu 20.04)
• NFS-opslag: SSD-bestandsdeling (geconfigureerd op 30 TiB, set nconnect=4)

Benchmarkinghulpprogramma's en tests

Deze tests maken gebruik van Flexible I/O Tester (FIO), een gratis, open-source schijf I/O-tool die zowel wordt gebruikt voor benchmarking als stress- of hardwareverificatie. Om FIO te installeren, zie de sectie Binaire Pakketten in het FIO README-bestand en volg de instructies voor het platform dat je kiest.

Hoewel deze tests zich richten op willekeurige I/O-toegangspatronen, krijgt u vergelijkbare resultaten wanneer u sequentiële I/O gebruikt.

Hoge IOPS: 100% leesbewerkingen

4k I/O-grootte - willekeurig lezen - 64 wachtrijdiepte

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

8k I/O-grootte - willekeurige leesbewerking - 64 wachtrijdiepte

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Hoge doorvoer: 100% leesoperaties

64 KiB I/O-grootte - willekeurig lezen - 64 wachtrijdiepte

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

1024 KiB I/O-grootte - 100% willekeurige lees- 64 wachtrijdiepte

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Hoge IOPS: 100% schrijfbewerkingen

4 KiB I/O-grootte - 100% willekeurige schrijfbewerking - 64 wachtrijdiepte

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

8 KiB I/O-grootte - 100% willekeurige schrijfbewerking - 64 wachtrijdiepte

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Hoge doorvoer: 100% schrijfacties

64 KiB I/O-grootte - 100% willekeurige schrijfbewerking - 64 wachtrijdiepte

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

1024 KiB I/O-grootte - 100% willekeurige schrijfbewerking - 64 wachtrijdiepte

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Prestatieoverwegingen voor nconnect

Wanneer u de nconnect koppelingsoptie gebruikt, moet u workloads met de volgende kenmerken nauwkeurig evalueren:

• Latentiegevoelige schrijfworkloads die enkelvoudig zijn en/of een lage wachtrijdiepte gebruiken (minder dan 16)
• Latentiegevoelige leesworkloads die uit één thread bestaan en/of een lage wachtrijdiepte gebruiken in combinatie met kleinere I/O-grootten

Niet alle workloads vereisen grootschalige IOPS of doorvoerprestaties. Voor kleinere workloads is het nconnect misschien niet voordelig. Gebruik de volgende tabel om te bepalen of nconnect het voordelig is voor uw workload. Scenario's die groen zijn gemarkeerd, worden aanbevolen, terwijl scenario's in rood niet zijn gemarkeerd. Scenario's die geel zijn gemarkeerd, zijn neutraal.

Zonegebonden plaatsing gebruiken

Voor klassieke bestandsshares die zijn gemaakt met de Resourceprovider Microsoft.Storage, raden we u aan zonegebonden plaatsing te gebruiken om de specifieke beschikbaarheidszone te selecteren waarin uw opslagaccount zich bevindt. Hierdoor kunt u uw VM's in dezelfde beschikbaarheidszone plaatsen als uw opslag, waardoor de latentie met maximaal 30 procent kan worden verminderd. Deze functie is momenteel alleen beschikbaar voor SSD-opslagaccounts die lokaal redundante opslag (LRS) gebruiken in ondersteunde regio's.

Zie ook

• NFS-bestandsshare koppelen aan Linux
• Lijst met koppelingsopties
• Inzicht in de prestaties van Azure Files