Monteringsalternativ och konfigurationer av virtuella klientdatorer

5 minuter

I den här modulen diskuterar vi monteringsalternativ och konfigurationer av virtuella klientdatorer som förbättrar prestanda när du kör HPC- eller EDA-program på Azure NetApp Files.

Not

Metodtips för NFS-klienter beror på vilka program som används. Följande förslag är inte absoluta och kan åsidosättas av programrekommendationer eller arbetsbelastningstestning. Vi rekommenderar starkt att du testar dessa metoder innan du distribuerar i produktion.

Använd monteringsalternativen actimeo och nocto för att förbättra prestanda

Du kan använda följande monteringsalternativ för att förbättra prestanda i relativt statiska datamängder och massiva lässcenarier:

actimeo: Styr NFS-klientens cacheattribut för en katalog. Om du inte anger det använder NFS-klienten ett maxvärde på 60 sekunder.
nocto: Står för "no close-to-open", vilket innebär att en fil kan stängas innan en skrivning har slutförts för att spara tid. Som standard anges inte nocto i NFS-monteringsalternativen. Det innebär att alla filer väntar på att slutföra skrivningar innan en stängning tillåts.

De flesta HPC-program, inklusive EDA i vårt scenario, har relativt statiska datamängder (vilket innebär att data inte ändras ofta). I så fall kan du använda nocto och actimeo för att minska getattr eller åtkomståtgärder till lagring, vilket kan hjälpa till att påskynda programmet.

Vi rekommenderar till exempel att du ställer in "nocto,actimeo=600" (600 sekunder eller 10 minuter) för EDA-verktyg och biblioteksvolymer. Eftersom filerna inte ändras finns det ingen cachesammanhållning att underhålla. Om du ställer in dessa monteringsalternativ minskar metadataanropen, vilket förbättrar den övergripande prestandan.

Justera systemparametrar för optimal prestanda

Tuned är en daemon som kan användas för att övervaka och konfigurera anslutna enheter på Linux-klienter. I de flesta fall installeras tuned som standard. Om den inte är installerad kan den läggas till och aktiveras för att förenkla justeringsparametrarna på klientsidan med inbyggda standardmallar.

Kör följande kommandon för att tillämpa grundläggande serverjustering och typisk svarstidsjustering för dina virtuella klientdatorer:

sudo systemctl enable --now tuned
sudo tuned-adm profile latency-performance

Vissa eller alla av följande systemparametrar (/etc/sysctl.conf) kan vara till hjälp på virtuella Linux-klientdatorer för optimala prestanda. Om du har virtuella klientdatorer med stora mängder RAM-minne eller högre nätverksbandbredd som InfiniBand kanske du vill ange några värden som är ännu högre än vad som visas i följande exempel.

#
# Recommended client tuning 
#
# For more information, see sysctl.conf(5) and sysctl.d(5)
# Network parameters, in units of bytes
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048576 8388608 16777216
net.ipv4.tcp_wmem = 1048576 8388608 16777216
net.core.optmem_max = 2048000
net.core.somaxconn = 65535
#
# These settings are in 4-KiB chunks, in bytes:
# Min=16MiB, Def=350MiB, Max=16GiB
# In units of 4K pages
net.ipv4.tcp_mem = 4096 89600 4194304
#
# Miscellaneous network options and flags
#
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_slow_start_after_idle = 0
net.core.netdev_max_backlog = 300000
#
# Various file system and page cache options
#
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
#
# Recommended by: https://cromwell-intl.com/open-source/performance-tuning/tcp.html
#
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

Om du vill göra dessa justeringar beständiga kör du kommandot:

sudo sysctl -P

Använd monteringsalternativet nconnect för att expandera nätverksanslutningar när det är tillämpligt

Alternativet nconnect NFS-montering blev allmänt tillgängligt i Linux-kärnan 5.3 eller senare. Om du vill kontrollera den virtuella klientdatorns Linux-kernel kör du:

uname -r

Syftet med nconnect är att tillhandahålla flera transportanslutningar per TCP-anslutning eller monteringspunkter på en klient. Den här tekniken hjälper till att öka parallellitet och prestanda för NFS-monteringar.

Ju lägre antalet klienter, desto mer värde nconnect ger för att öka prestandan, eftersom det potentiellt kan använda all tillgänglig nätverksbandbredd. Dess värde minskar gradvis när antalet klienter ökar; Det finns bara en viss mängd bandbredd totalt att gå runt, och det maximala antalet TCP-anslutningar kan förbrukas snabbare, vilket kan leda till överbelastning tills TCP-anslutningar frigörs.

Eftersom Azure NetApp Files tillåter högst 128 samtidiga förfrågningar under flygning per TCP-anslutning innan en begränsning uppstår (där nya begäranden placeras i kö tills resurser görs tillgängliga), kan nconnect hjälpa till att utöka antalet begäranden under flygning som tillåts genom att öka de tillgängliga TCP-anslutningarna per monteringspunkt. Om nconnect till exempel är inställd på att använda åtta TCP-anslutningar är 1 024 begäranden (8x128) potentiellt tillgängliga för klienten.

Moderna Linux-klienter tillåter upp till 65 535 begäranden per anslutning (ett dynamiskt värde). Detta kan potentiellt överskrida en Azure NetApp Files-volyms tillgängliga kö för begäran under flygning och leda till oönskade prestandaresultat, där klienter skickar fler förfrågningar än vad som kan uppfyllas vid en viss tidpunkt. Om du vill minska risken för prestandapåverkan på grund av det här beteendet kan du överväga att ange sunrpc.tpc_max_slot_table_entries=256 eller 512 om du använder nconnect=8 eller 16 till ett lägre statiskt värde. Använd följande tabell som vägledning.

Not

Olika typer av Linux-klientoperativsystem kan ha olika metoder för att ange det här värdet. Mer information finns i os-dokumentationen.

`nconnect` värde	Rekommenderade maximala TCP-slotstabellposter
0-1	128
2-4	256
6-8	512
>8	Ingen ändring krävs

Anteckning

Alternativet nconnect är endast tillgängligt för virtuella Linux-kernel 5.3+-datorer. Du kan behöva starta om den virtuella datorn när du uppgraderar kerneln. Det innebär att det kanske inte är tillämpligt i vissa fall.

Använd NFSv3 i stället för NFSv4.1 när du endast överväger prestanda

NFSv3 är ett tillståndslöst protokoll, vilket innebär att klienten och servern inte kommunicerar med varandra om filer som används. Låsning utförs utanför protokollstacken av Network Lock Manager (NLM), som medför vissa utmaningar när låsen blir inaktuella och måste rensas manuellt. Lås upprättas endast på begäran av programmet, så det kan finnas scenarier där lås inte behöver förhandlas. Eftersom det inte finns några klient-ID:n, tillstånds-ID:n, sessions-ID:n, låstillstånd osv. för att hålla reda på, tenderar NFSv3 att prestera lite bättre än NFSv4.1 i vissa arbetsbelastningar – särskilt i hög filantal/höga metadataarbetsbelastningar, till exempel EDA och programvaruutveckling.

NFSv4.1 håller reda på tillstånd för filer, inklusive lås. När många filer används samtidigt i NFSv4.1 tilldelas varje fil ett tillstånds-ID och får ett lås. Att vara tillståndskänslig lägger till omkostnader för arbetsbelastningens prestanda, eftersom varje tillstånd och lås måste bearbetas av NFS-servern. I vissa arbetsbelastningar (till exempel EDA) kan NFSv4.1-prestanda påverkas var som helst från 25% till 75%. Andra arbetsbelastningar, till exempel stora filer, strömmande I/O eller databaser, ser inte prestandaförsämring när du använder NFSv4.1 och kan till och med dra nytta av de sammansatta åtgärder som protokollet använder.

Azure NetApp Files stöder både NFSv3 och NFSv4.1. Du bör verifiera vilken version ditt program kräver genom att jämföra likheterna och skillnaderna mellan NFS-versionerna (samt testa) och skapa volymen med hjälp av lämplig version. Vid behov kan Azure NetApp Files-volymer konfigureras till en annan protokollversion när de har skapats.

Välj rätt värden för monteringsalternativen rsize och wsize

Monteringsalternativen rsize (lässtorlek) och wsize (skrivstorlek) avgör hur mycket data som skickas mellan NFS-klienten och servern för varje paket som skickas. Om du till exempel anger rsize eller wsize till 65 536 kan upp till 64 K data skickas per paket. Om ett program skickar data i mindre segment (till exempel 8 K) beror mängden data som skickas på de monteringsalternativ som används (till exempel sync).

Det bästa sättet för Azure NetApp Files är att ange rsize och wsize till samma värde. Vi rekommenderar vanligtvis att du anger både rsize och wsize värden som 262144 (256 K) i monteringsalternativen.

Förstå alternativ för synkronisering och asynkron montering

Om sync används skickas varje WRITE-anrop med ett FILE_SYNC kommando. Det innebär att varje WRITE måste bekräftas av servern och skrivas till disken innan nästa WRITE kan inträffa. Sync används när ett program måste garantera att alla data skrivs till disken. WRITE-anrop skickar endast den mängd data som anges av programmets blockstorlek, vilket innebär att mindre blockstorlekar genererar mer NFS-trafik oavsett wsize och rsize värden för monteringen, vilket orsakar prestandapåverkan.

Om du använder (standard) async monteringsåtgärden kan en klient skicka flera WRITE anrop via NFS med kommandot UNSTABLE. I det här scenariot skrivs data till disk efter en tidsgräns. Eftersom NFS-klienten inte alltid väntar på att servern ska checka in data till disken innan nästa WRITE startas är jobbavslutstiderna för skrivningar till asynkrona monteringar mycket lägre än vid synkronisering. När mindre blockstorlekar används med större rsize och wsize värden skickar WRITE-anrop så mycket data som tillåts i ett enda NFS-anrop. Om till exempel 8 K blockstorlekar används med en 64 K wsize/rsizeskickar varje NFS WRITE-anrop åtta block per paket (64 K/8 K). När skrivningen töms till disk skickar NFS-servern ett FILE_SYNC svar tillbaka till NFS-klienten. Detta minskar det totala antalet WRITE-anrop och svar via ett nätverk som behövs för att slutföra ett jobb, vilket förbättrar prestandan.

I ett test där en 1-GiB-fil skapades med en blockstorlek på 8 K genererades till exempel 262 144 WRITE anrop och svar och avslutades på 70 sekunder när alternativet sync montering användes. Samma filskapande med en blockstorlek på 8 K och monteringsalternativet async skickade endast 16 384 SKRIV-anrop och svar och slutfördes på sex sekunder.

Azure NetApp Files använder batteribaserad NVRAM-lagring som buffertcache för inkommande NFS-skrivningar. Data i NVRAM töms till disk var 10:e sekund eller tills buffertcachen är fylld (beroende på vilket som inträffar först). Eftersom NVRAM backas upp av ett batteri kan det överleva oväntade avbrott i minst 72 timmar samtidigt som data bevaras, till exempel den osannolika händelsen då ett Azure-datacenter förlorar ström. Kombinationen av datamotsåndskraften hos Azure NetApp Files och prestandapåverkan av att använda sync som monteringsalternativ gör asynkront till det föredragna valet i nästan alla användningsfall.

Förstå effekten av wsize- och rsize-värden

När du monterar över NFS avgör wsize- och rsize-värdena hur mycket data som kan skickas per NFS-anrop till en NFS-server. Om de inte anges i monteringsalternativen, sätts värdena till vad NFS-servern har konfigurerats med. Azure NetApp Files använder en maximal överföringsstorlek för både wsize och rsize på 1 MB (1048576). Det här värdet kan inte ändras i Azure NetApp Files. Det innebär att om NFS-monteringar inte anger värdena för wsize och rsize, är monteringarna standardvärdet 1 MB. De rekommenderade wsize- och rsize-värdena för NFS-monteringar i EDA-arbetsbelastningar är 256 K.

Om ett program behöver skapa en 1-GiB-fil på en Azure NetApp Files NFS-montering måste den skriva 1048 576 KiB till lagring. En matematisk övning kan visa varför prestanda kan förbättras med effektivare wsize eller rsize värden.

Om wsize är inställt på 64 K är antalet åtgärder/paket som krävs för att skriva 1-GiB-filen 1048576/64=16384.
Om wsize är inställt på 256 K är antalet åtgärder/paket som krävs för att skriva 1-GiB-filen 1048576/256=4096.

Färre paket/åtgärder innebär att nätverksfördröjningen (vilket påverkar RTT) har mindre påverkan på arbetsbelastningar, vilket kan vara kritiskt vid molndistributioner. Men om programmet skriver filer som är mindre än de wsize/rsize värdena har de större wsize/rsize-värdena ingen effekt på prestandan.

Större datasegment innebär fler bearbetningscykler på klienten och servern, men de flesta moderna processorer är tillräckligt utrustade för att hantera dessa begäranden effektivt.

Det bästa sättet för Azure NetApp Files är att ange rsize och wsize till samma värde. Vi rekommenderar att du anger värden för både rsize och wsize till 262144 (256 K) i monteringsalternativen. Den här inställningen omfattar en matris med värden för läs- och skrivstorlek för program.

Välj rätt inställningar för de hårda, mjuka och intr-monteringsalternativen

Monteringsalternativen hard och soft anger om programmet som använder en fil som använder NFS ska utföra någon av följande åtgärder:

Stoppa och vänta (hard) så att servern är online igen om NFS-servern inte är tillgänglig. Det här alternativet visas som en monteringslåsning på klienten, men ser till att driften under flygning inte går förlorad i händelse av nätverksfel. I stället fortsätter klienten att försöka begära igen tills servern är tillgänglig eller tills programmet överskrider tidsgränsen.
Rapportera ett fel (soft). Monteringar hänger sig inte, men operationer under flygningen kan gå förlorade.

Med alternativet intr montering kan NFS-processer avbrytas när en montering anges som en hard montering (till exempel CTRL+C). Vi rekommenderar att du använder intr med hard fästen när det är tillämpligt för bästa möjliga kombination av datatillförlitlighet och hanterbarhet.

Överväg att inte ändra MTU:er

Standardvärdet för maximala överföringsenheter (MTU:er) för virtuella Azure-datorer är 1 500 byte. Vi uppmuntrar inte kunderna att öka antalet virtuella dator-MTU:er för jumboramar.

Monteringsexempel

Följande exempelkod monterar en Azure NetApp Files-volym med hjälp av föregående metodtips för actimeo, nocto, NFSv3, nconnect, rsize, wsize, hard, intr, tcpoch standard-MTU:er (1 500):

sudo mount -t nfs -o rw,nconnect=16,nocto,actimeo=600,hard,intr,rsize=262144,wsize=262144,vers=3,tcp 10.1.x.x:/ultravol ultravol