Metodtips för Linux NFS-monteringsalternativ för Azure NetApp Files

  • Artikel

Den här artikeln hjälper dig att förstå monteringsalternativ och metodtips för att använda dem med Azure NetApp Files.

Nconnect

Med monteringsalternativet nconnect kan du ange antalet anslutningar (nätverksflöden) som ska upprättas mellan NFS-klienten och NFS-slutpunkten upp till en gräns på 16. Traditionellt använder en NFS-klient en enda anslutning mellan sig själv och slutpunkten. Genom att öka antalet nätverksflöden ökar de övre gränserna för I/O och dataflöde avsevärt. Testningen har visat nconnect=8 sig vara den mest högpresterande.

När du förbereder en SAS GRID-miljö med flera noder för produktion kanske du ser en upprepningsbar minskning på 30 % av körningstiden från 8 timmar till 5,5 timmar:

Monteringsalternativ Körningstider för jobb
Nej nconnect 8 timmar
nconnect=8 5,5 timmar

Båda testuppsättningarna använde samma E32-8_v4 virtuella dator och RHEL8.3, med read-ahead inställt på 15 MiB.

Tänk på följande regler när du använder nconnect:

  • nconnect stöds av Azure NetApp Files på alla större Linux-distributioner men endast på nyare versioner:

    Linux-version NFSv3 (lägsta version) NFSv4.1 (lägsta version)
    Redhat Enterprise Linux RHEL8.3 RHEL8.3
    SUSE SLES12SP4 eller SLES15SP1 SLES15SP2
    Ubuntu Ubuntu18.04

    Kommentar

    SLES15SP2 är den lägsta SUSE-versionen som nconnect stöds av Azure NetApp Files för NFSv4.1. Alla andra versioner som anges är de första versionerna som introducerade nconnect funktionen.

  • Alla monteringar från en enskild slutpunkt ärver inställningen för den nconnect första exportmonteringen, enligt följande scenarier:

    Scenario 1: nconnect används av den första monteringen. Därför använder nconnect=8alla monteringar mot samma slutpunkt .

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.10.10.10:/volume2 /mnt/volume2
    • mount 10.10.10.10:/volume3 /mnt/volume3

    Scenario 2: nconnect används inte av den första monteringen. Därför kan inga monteringar mot samma slutpunkt användas nconnect även om nconnect det kan anges därpå.

    • mount 10.10.10.10:/volume1 /mnt/volume1
    • mount 10.10.10.10:/volume2 /mnt/volume2 -o nconnect=8
    • mount 10.10.10.10:/volume3 /mnt/volume3 -o nconnect=8

    Scenario 3: nconnect inställningarna sprids inte över separata lagringsslutpunkter. nconnect används av monteringen som kommer från 10.10.10.10 men inte av monteringen som kommer från 10.12.12.12.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.12.12.12:/volume2 /mnt/volume2

  • nconnect kan användas för att öka samtidigheten i lagringen från en viss klient.

Mer information finns i Metodtips för samtidighet i Linux för Azure NetApp Files.

Nconnect Överväganden

Vi rekommenderar inte att du använder nconnect och sec=krb5* monterar alternativ tillsammans. Prestandaförsämring har observerats när du använder de två alternativen i kombination.

GSS-API (Generic Security Standard Application Programming Interface) är ett sätt för program att skydda data som skickas till peer-program. Dessa data kan skickas från en klient på en dator till en server på en annan dator. 

När nconnect används i Linux delas GSS-säkerhetskontexten nconnect mellan alla anslutningar till en viss server. TCP är en tillförlitlig transport som stöder paketleverans utan beställning för att hantera out-of-order-paket i en GSS-ström med hjälp av ett skjutfönster med sekvensnummer. När paket som inte finns i sekvensfönstret tas emot ignoreras säkerhetskontexten och en ny säkerhetskontext förhandlas. Alla meddelanden som skickas med i den nu borttagna kontexten är inte längre giltiga, vilket kräver att meddelandena skickas igen. Ett större antal paket i en nconnect konfiguration orsakar ofta utgående paket, vilket utlöser det beskrivna beteendet. Inga specifika försämringsprocent kan anges med det här beteendet.

Rsize och Wsize

Exempel i det här avsnittet innehåller information om hur du närmar dig prestandajustering. Du kan behöva göra justeringar för att passa dina specifika programbehov.

Flaggorna rsize och wsize anger den maximala överföringsstorleken för en NFS-åtgärd. Om rsize eller wsize inte anges på monteringen förhandlar klienten och servern om den största storlek som stöds av de två. För närvarande stöder både Azure NetApp Files och moderna Linux-distributioner läs- och skrivstorlekar så stora som 1 048 576 byte (1 MiB). För bästa övergripande dataflöde och svarstid rekommenderar Azure NetApp Files dock att du anger både rsize och wsize inte större än 262 144 byte (256 K). Du kan observera att både ökad svarstid och minskat dataflöde vid användning rsize och wsize större än 256 KiB.

Distribuera till exempel ett SAP HANA-utskalningssystem med väntelägesnod på virtuella Azure-datorer med hjälp av Azure NetApp Files på SUSE Linux Enterprise Server visar 256-KiB rsize och wsize maximalt enligt följande:

sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001  nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-shared/shared /hana/shared  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0

SAS Viya rekommenderar till exempel en läs- och skrivstorlek på 256 KiB, och SAS GRID begränsar r/wsize till 64 KiB samtidigt som läsprestanda utökas med ökad läsning framåt för NFS-monteringarna. Mer information finns i Metodtips för läsning i NFS för Azure NetApp Files .

Följande överväganden gäller för användning av rsize och wsize:

  • Slumpmässiga I/O-åtgärdsstorlekar är ofta mindre än monteringsalternativen rsize och wsize . Därför kommer de i själva verket inte att begränsas på så sätt.
  • När du använder filsystemcachen sker sekventiell I/O vid den storlek som baseras på alternativen och monteringenrsize, såvida inte filstorleken är mindre än rsize och wsize.wsize
  • Åtgärder som kringgår filsystemcacheminnet, även om de rsize fortfarande begränsas av alternativen och wsize monteringen, kommer inte nödvändigtvis att utfärda så stora som det högsta som anges av rsize eller wsize. Det här är viktigt när du använder arbetsbelastningsgeneratorer som har alternativet directio .

Bästa praxis med Azure NetApp Files är att för bästa övergripande dataflöde och svarstid ange rsize och wsize inte större än 262 144 byte.

Nära öppen konsekvens och cache-attributtimers

NFS använder en lös konsekvensmodell. Konsekvensen är lös eftersom programmet inte behöver gå till delad lagring och hämta data varje gång för att använda den, ett scenario som skulle ha en enorm inverkan på programmets prestanda. Det finns två mekanismer som hanterar den här processen: cacheattributtimers och nära öppen konsekvens.

Om klienten har fullständigt ägarskap för data, dvs. den inte delas mellan flera noder eller system, finns det garanterad konsekvens. I så fall kan du minska åtkomståtgärderna getattr till lagring och påskynda programmet genom att stänga av konsekvensen från nära till öppen (cto) (nocto som monteringsalternativ) och genom att aktivera tidsgränserna för cachehantering av attribut (actimeo=600 som ett monteringsalternativ ändras timern till 10 m jämfört med standardvärdena acregmin=3,acregmax=30,acdirmin=30,acdirmax=60). I vissa tester nocto minskar cirka 65–70 % av åtkomstanropen getattr , och om du justerar actimeo minskar dessa anrop ytterligare 20–25 %.

Så här fungerar attributcachetimers

Attributen acregmin, acregmax, acdirminoch acdirmax styr cachens samtidighet. De två tidigare attributen styr hur länge attributen för filer är betrodda. De två senare attributen styr hur länge attributen för själva katalogfilen är betrodda (katalogstorlek, katalogägarskap, katalogbehörigheter). Attributen min och max definierar minsta och högsta varaktighet för vilka attribut för en katalog, attribut för en fil och cacheinnehåll i en fil anses vara tillförlitliga. Mellan min och maxanvänds en algoritm för att definiera hur lång tid en cachelagrad post är betrodd.

Tänk till exempel på standardvärdena acregmin och acregmax värdena, 3 respektive 30 sekunder. Attributen utvärderas till exempel upprepade gånger för filerna i en katalog. Efter 3 sekunder efterfrågas NFS-tjänsten för färskhet. Om attributen bedöms vara giltiga fördubblar klienten den betrodda tiden till 6 sekunder, 12 sekunder, 24 sekunder, då det maximala värdet är 30, 30 sekunder. Från och med då, tills de cachelagrade attributen anses vara inaktuella (då cykeln börjar om), definieras pålitlighet som 30 sekunder som det värde som anges av acregmax.

Det finns andra fall som kan dra nytta av en liknande uppsättning monteringsalternativ, även om det inte finns något fullständigt ägarskap av klienterna, till exempel om klienterna använder data som skrivskyddade och datauppdateringen hanteras via en annan sökväg. För program som använder rutnät av klienter som EDA, webbvärd och filmrendering och har relativt statiska datamängder (EDA-verktyg eller bibliotek, webbinnehåll, texturdata) är det vanliga beteendet att datauppsättningen till stor del cachelagras på klienterna. Det finns få läsningar och inga skrivningar. Det kommer att finnas många getattr/access-samtal som kommer tillbaka till lagringen. Dessa datauppsättningar uppdateras vanligtvis via en annan klient som monterar filsystemen och skickar regelbundet innehållsuppdateringar.

I dessa fall finns det en känd fördröjning i att hämta nytt innehåll och programmet fungerar fortfarande med potentiellt inaktuella data. I dessa fall nocto och actimeo kan användas för att styra den period där inaktuellt datum kan hanteras. I EDA-verktyg och - actimeo=600 bibliotek fungerar det till exempel bra eftersom dessa data vanligtvis uppdateras sällan. För små webbvärdar där klienter behöver se sina datauppdateringar i rätt tid när de redigerar sina webbplatser kan actimeo=10 det vara acceptabelt. För storskaliga webbplatser där innehåll skickas till flera filsystem actimeo=60 kan det vara acceptabelt.

Om du använder de här monteringsalternativen minskar arbetsbelastningen avsevärt till lagring i dessa fall. (Till exempel har en nyligen genomförd EDA-upplevelse minskat IOPs till verktygsvolymen från >150 K till ~6 K.) Program kan köras betydligt snabbare eftersom de kan lita på data i minnet. (Minnesåtkomsttiden är nanosekunder jämfört med hundratals mikrosekunder för getattr/access i ett snabbt nätverk.)

Konsekvens nära öppen

Nära-till-öppen konsekvens (monteringsalternativet cto ) säkerställer att oavsett cachens tillstånd, visas alltid de senaste data för en fil för programmet när de öppnas.

  • När en katalog crawlas (lstill ls -l exempel) utfärdas en viss uppsättning RPC:er (fjärrproceduranrop).
    NFS-servern delar sin vy över filsystemet. Så länge som används av alla NFS-klienter som cto har åtkomst till en viss NFS-export ser alla klienter samma lista över filer och kataloger däri. Aktualiteten för attributen för filerna i katalogen styrs av attributcachetimers. Så länge som cto används visas filer med andra ord för fjärrklienter så snart filen har skapats och filen hamnar på lagringen.
  • När en fil öppnas garanteras innehållet i filen från NFS-serverns perspektiv.
    Om det finns ett konkurrenstillstånd där innehållet inte har rensats från dator 1 när en fil öppnas på dator 2, tar dator 2 bara emot data som finns på servern vid tidpunkten för öppningen. I det här fallet hämtar dator 2 inte mer data från filen förrän timern har nåtts acreg och Machine 2 kontrollerar cachesammansekvensen från servern igen. Det här scenariot kan observeras med hjälp av en svans -f från dator 2 när filen fortfarande skrivs till från dator 1.

Ingen nära-till-öppen konsekvens

När ingen nära-till-öppen konsekvens (nocto) används, kommer klienten att lita på färskheten i den aktuella vyn av filen och katalogen tills tidsinställda cacheattribut har brutits.

  • När en katalog crawlas (lstill ls -l exempel) utfärdas en viss uppsättning RPC:er (fjärrproceduranrop).
    Klienten utfärdar endast ett anrop till servern för en aktuell lista över filer när acdir cachetimerns värde har överträtts. I det här fallet visas inte nyligen skapade filer och kataloger och nyligen borttagna filer och kataloger visas fortfarande.

  • När en fil öppnas, så länge filen fortfarande finns i cacheminnet, returneras dess cachelagrade innehåll (om det finns något) utan att verifiera konsekvensen med NFS-servern.

Nästa steg