Dela via

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

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. Om du ökar antalet nätverksflöden ökar de övre gränserna för I/O och dataflödet 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örtider 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-utgåva NFSv3 (lägsta version) NFSv4.1 (lägsta version)
    Red Hat Enterprise Linux RHEL8.3 RHEL8.3
    SUSE SLES12SP4 eller SLES15SP1 SLES15SP2
    Ubuntu Ubuntu18.04

    Anteckning

    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 av den första export som är monterad, som du ser i följande scenarier:

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

    • 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 används inga monteringar mot samma slutpunkt nconnect, även om nconnect kan anges där.

    • 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 fästet som kommer från 10.10.10.10, men det används inte av fästet 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

Det rekommenderas inte att använda monteringsalternativen nconnect och sec=krb5* tillsammans. Om du använder de här alternativen tillsammans kan prestanda försämras.

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 att paket hamnar utanför fönstret, 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 både ökad svarstid och minskat dataflöde när man använder rsize och wsize som är 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 är de inte begränsningar.
  • När du använder filsystemcachen kommer sekventiell I/O ske i den storlek som baseras på rsize och wsize monteringsalternativen, såvida inte filstorleken är mindre än rsize och wsize.
  • Åtgärder som kringgår filsystemcachen, även om de fortfarande begränsas av monteringsalternativen rsize och wsize, är inte lika stora som det maximala 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.

Konsekvent nära-till-öppen och cacheattributstimers

NFS använder en lös konsistensmodell. 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: cache-attributtimers och close-to-open-konsekvens.

Om klienten har fullständigt ägarskap för data, dvs. den inte delas mellan flera noder eller system, finns det garanterad konsekventhet. I så fall kan du minska åtkomstoperationerna getattr till lagringen och påskynda programmet genom att stänga av stäng-till-öppna (cto) konsistens (nocto som ett monteringsalternativ) och genom att öka tidsgränserna för cachehantering av attribut (actimeo=600 som ett monteringsalternativ ändrar 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 %.

Hur attributcache-timers fungerar

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 kontrolleras NFS-tjänstens aktualitet. 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 de klienterna, till exempel om klienterna använder data för endast läsning och om 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äsoperationer och inga skrivoperationer. Det finns 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 mindre webbhotell där klienter behöver se sina datauppdateringar omedelbart medan de redigerar sina webbplatser, kan actimeo=10 vara acceptabelt. För storskaliga webbplatser där innehåll skickas till flera filsystem actimeo=60 kan det vara acceptabelt.

Användning av dessa monteringsalternativ minskar arbetsbelastningen på lagringen avsevärt 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.)

Närhet-till-öppen konsekvens

nära-till-öppen-konsekvens (monteringsalternativet cto ) säkerställer att, oavsett tillståndet i cachen, den senaste datan för en fil alltid presenteras för applikationen när den ö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 cto används av alla NFS-klienter som har åtkomst till en viss NFS-export, ser alla klienter samma lista över filer och kataloger där. Färskheten hos filernas attribut i katalogen styrs av attributcache-timers. 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 det att innehållet är aktuellt 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 den data som finns på servern vid tiden för öppningen. I det här fallet hämtar inte Machine 2 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 genom att använda ett tail-kommando -f från Maskin 2 när filen fortfarande skrivs till av Maskin 1.

Ingen övergång från stängd till öppen

När ingen nära-till-öppen konsekvens (nocto) används, litar klienten på färskheten i den aktuella vyn av filen och katalogen tills cacheattributens tidsgränser har överskridits.

  • 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. Nyligen borttagna filer och kataloger visas.

  • 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