Förbättra prestanda för NFS Azure-filresurser

Gäller för: ✔️ NFS-fildelningar

Den här artikeln ger olika sätt att förbättra prestandan för nätverksfilsystem (NFS) Azure-fildelningar. Ämnen inkluderar att konfigurera Linux-kärnans read_ahead_kb parameter för bättre sekventiell läsgenomströmning, använda nconnect mount-alternativet för att skala genomströmning med färre klientmaskiner, samt placera ditt lagringskonto i samma tillgänglighetszon som dina klienter för att minska latensen.

Öka förladdningsstorleken för att förbättra läsgenomströmningen

Kernelparametern read_ahead_kb i Linux anger mängden data som ska förladdas under en sekventiell läsåtgärd. Linux-kernelversioner före 5.4 anger läs-före-värdet till motsvarande 15 gånger det monterade filsystemets rsize, vilket representerar monteringsalternativet på klientsidan för läsbuffertstorlek. Detta ställer in läs-framåt-värdet tillräckligt högt för att förbättra klientens sekventiella läsdataflöde i de flesta fall.

Från och med Linux-kernel version 5.4 använder Linux NFS-klienten dock ett standardvärde read_ahead_kb på 128 KiB. Detta mindre värde kan minska mängden läsgenomströmning för stora filer. Användare som uppgraderar från Linux-versioner med högre läsvärde till versioner med standardvärdet 128 KiB kan uppleva en minskning av sekventiell läsprestanda.

För Linux-kärnor 5.4 eller senare ska read_ahead_kb ställas in permanent till 15 MiB för förbättrad prestanda.

Om du vill ändra det här värdet anger du läsföreläsningsstorleken genom att lägga till en regel i udev, en Linux-kernelenhetshanterare. Följ dessa steg:

1. I en textredigerare skapar du filen /etc/udev/rules.d/99-nfs.rules genom att ange och spara följande text:

   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. I en konsol tillämpar du udev-regeln genom att köra kommandot udevadm som en superanvändare och läsa in regelfilerna och andra databaser igen. Du behöver bara köra detta kommando en gång för att göra Udev medveten om den nya filen.

   sudo udevadm control --reload
   

NFS nconnect

NFS nconnect är ett klientbaserat monteringsalternativ för NFS-fildelningar som du använder för att skapa flera TCP-anslutningar mellan klienten och din NFS-fildelning. Det är särskilt användbart för storskaliga arbetsbelastningar där en enda TCP-anslutning blir en flaskhals.

nconnect-fördelar

Med nconnect kan du öka prestandan i stor skala med färre klientdatorer för att minska den totala ägandekostnaden (TCO). Nconnect-funktionen ökar prestandan genom att använda flera TCP-kanaler på en eller flera nätverkskort med hjälp av en eller flera klienter. Utan nconnect behöver du ungefär 20 klientmaskiner för att uppnå de bandbreddsskalningsgränser (10 GiB/s) som erbjuds av den största SSD-fildelningsprovisioneringsstorleken. Med nconnect kan du uppnå dessa gränser med endast 6–7 klienter, vilket minskar beräkningskostnaderna med nästan 70% samtidigt som du ger betydande förbättringar i I/O-åtgärder per sekund (IOPS) och dataflöde i stor skala. Se följande tabell.

nconnect-förutsättningar

• De senaste Linux-distributionerna har fullt stöd för nconnect. För äldre Linux-distributioner kontrollerar du att Linux-kernelversionen är 5.3 eller senare.
• Konfiguration per monteringspunkt stöds endast när endast en filresurs används för varje lagringskonto över en privat nätverksslutpunkt.

Prestandapåverkan

Följande prestandaresultat mättes med nconnect mount-alternativet med NFS Azure-fildelningar på Linux-klienter i stor skala. För mer information om hur dessa resultat uppnåddes, se prestandatestkonfiguration.

nconnect rekommendationer

Följ dessa rekommendationer för att få bästa resultat från nconnect.

Ange nconnect=4

Medan Azure Files stöder inställningen av nconnect upp till maxinställningen 16, konfigurera monteringsalternativen med den optimala inställningen nconnect=4. För närvarande finns det inga vinster utöver fyra kanaler för Azure Files-implementeringen av nconnect. Att överskrida fyra kanaler till en enda Azure-fildelning från en enda klient kan faktiskt påverka prestanda negativt på grund av mättnad i TCP-nätverket.

Ändra storlek på virtuella datorer noggrant

Beroende på dina arbetsbelastningskrav är det viktigt att du har rätt storlek på de virtuella klientdatorerna för att undvika att begränsas av deras förväntade nätverksbandbredd. Du behöver inte flera nätverksgränssnittsstyrenheter (NIC) för att uppnå det förväntade nätverkets dataflöde. Det är vanligt att använda virtuella datorer för generell användning med Azure Files, men olika typer av virtuella datorer är tillgängliga beroende på dina arbetsbelastningsbehov och regionens tillgänglighet. Mer information finns i Azure VM Selector(Azure VM Selector).

Håll ködjupet mindre än eller lika med 64

Ködjup är antalet väntande I/O-begäranden som en lagringsresurs kan betjäna. Vi rekommenderar inte att du överskrider det optimala ködjupet på 64 eftersom du inte ser några fler prestandavinster. Mer information finns i Ködjup.

Per monteringskonfiguration

Om en arbetsbelastning kräver att flera delningar monteras från ett enda klientsystem med ett eller flera lagringskonton som har olika nconnect-inställningar, är det inte garanterat att inställningarna består vid montering via den offentliga slutpunkten. Konfiguration per mount stödjer endast en enda Azure-fildelning per lagringskonto över den privata slutpunkten som beskrivs i scenario 1.

Scenario 1: per monteringskonfiguration över privat slutpunkt med flera lagringskonton (stöds)

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

Scenario 2: per monteringskonfiguration via offentlig slutpunkt (stöds inte)

• 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 monteringskonfiguration över en privat slutpunkt med flera resurser på ett enda lagringskonto (stöds inte)

• 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

Konfiguration av prestandatest

För att uppnå och mäta de resultat som beskrivs i denna artikel, använd följande resurser och benchmarkingverktyg.

• Enskild klient: Virtuell Azure-dator (DSv4-serien) med ett enda nätverkskort
• OS: Linux (Ubuntu 20.04)
• NFS-lagring: SSD-filandel (provisionerad 30 TiB, ställ in nconnect=4)

Verktyg och tester för benchmarking

Dessa tester använder Flexible I/O Tester (FIO), ett gratis, öppet disk-I/O-verktyg som används både för benchmarking och för stress eller hårdvaruverifiering. För att installera FIO, se avsnittet Binära paket i FIO README-filen och följ instruktionerna för den plattform du väljer.

Även om dessa tester fokuserar på slumpmässiga I/O-åtkomstmönster får du liknande resultat när du använder sekventiell I/O.

Hög IOPS: 100% läsningar

4k I/O-storlek – slumpläsning – 64 ködjup

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-storlek – slumpmässig läsning – 64 ködjup

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

Högt genomflöde: 100% läsningar

64 KiB I/O-storlek – slumpmässig läsning – 64 ködjup

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

1 024 KiB I/O-storlek – 100 slumpmässiga läsningar% – kövärdedjup på 64

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

Hög IOPS: 100% skrivningar

4 KiB I/O-storlek – 100% slumpmässig skrivning – 64 ködjup

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-storlek – 100% slumpmässig skrivning – 64 ködjup

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

Högt dataflöde: 100% skrivningar

64 KiB I/O-storlek – 100% slumpmässig skrivning – ködjup på 64

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-storlek – 100% slumpmässig skrivning – 64 kö-djup

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

Prestandaöverväganden för nconnect

När du använder monteringsalternativet nconnect bör du noggrant utvärdera arbetsbelastningar som har följande egenskaper:

• Svarstidskänsliga skrivarbetsbelastningar som är enkla trådade och/eller använder ett lågt ködjup (mindre än 16)
• Svarstidskänsliga läsarbetsbelastningar som är enkla trådade och/eller använder ett lågt ködjup i kombination med mindre I/O-storlekar

Alla arbetsbelastningar kräver inte högskalig IOPS eller genomströmningsprestanda. För mindre arbetsbelastningar kanske det nconnect inte är så fördelaktigt. Använd följande tabell för att avgöra om nconnect det är fördelaktigt för din arbetsbelastning. Scenarier som är markerade i grönt rekommenderas, medan scenarier som är markerade i rött inte är det. Scenarier markerade i gult är neutrala.

Använda zonindelad placering

För klassiska fildelningar som skapats med resursleverantören Microsoft.Storage rekommenderar vi att du använder zonplacering för att välja den specifika tillgänglighetszon där lagringskontot befinner sig. På så sätt kan du placera dina virtuella datorer i samma tillgänglighetszon som lagringen, vilket kan minska svarstiden med upp till 30 procent. Den här funktionen är för närvarande endast tillgänglig för SSD-lagringskonton med lokalt redundant lagring (LRS) i regioner som stöds.

Se även

• Montera NFS-filresurser på Linux
• Lista över monteringsalternativ
• Förstå Prestanda för Azure Files