PowerScale: OneFS: Metodtips för NFS-klientinställningar

Summary: I den här artikeln beskrivs bästa praxis och rekommendationer för inställningar och monteringsalternativ på klientsidan när NFS-protokollet (Network File System) används för att ansluta till ett PowerScale-kluster. Den gäller för alla versioner av OneFS som stöds. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

OneFS: Metodtips för NFS-klientinställningar (Network File System)

Cause

Protokollversioner som stöds

PowerScale OneFS har för närvarande stöd för NFS (Network File System) version 3 och 4. NFS version 2 stöds inte.

NFSv3

NFS version 3 är den mest använda versionen av NFS-protokollet idag och anses ha den bredaste klient- och filanvändningen. Här är några viktiga komponenter i den här versionen:

  • Tillståndslös – En klient upprättar inte tekniskt sett en ny session om den har rätt information för att be om filer och så vidare. Detta möjliggör enkel failover mellan OneFS-noder med dynamiska IP-pooler.
  • Användar- och gruppinformation presenteras numeriskt – klient och server kommunicerar användarinformation med numeriska identifierare, vilket gör att samma användare visas som olika namn mellan klient och server.
  • Fillåsning är out-of-band – Version 3 av NFS använder ett hjälpprotokoll som kallas NLM för att utföra lås. Detta kräver att klienten svarar på RPC-meddelanden från servern för att bekräfta att lås har beviljats.
  • Kan köras över TCP eller UDP – Den här versionen av protokollet kan köras över UDP istället för TCP, vilket lämnar hantering av förlust och återöverföring till programvaran istället för operativsystemet. Dell Technologies rekommenderar alltid att du använder TCP.

NFSv4

NFS version 4 är den senaste större revisionen av NFS-protokollet och används allt oftare.  Här är några av de viktigaste skillnaderna mellan v3 och v4.

  • Tillståndskänslig – NFSv4 använder sessioner för att hantera kommunikation, vilket innebär att både klienten och servern måste spåra sessionstillståndet för att fortsätta kommunicera.
    • Före OneFS 8.X innebar detta att NFSv4-klienter krävde statiska IP-pooler på PowerScale eller kunde stöta på problem.
  • Användar- och gruppinformation visas som strängar – Både klienten och servern måste matcha namnen på den numeriska information som lagras. Servern måste slå upp namn som ska presenteras, medan klienten måste mappa om dem till siffror på sin sida.
  • Fillåsning är i band – Version 4 använder inte längre ett separat protokoll för fillåsning, vilket i stället gör det till en typ av anrop som är sammansatt med OPENs, CREATESeller WRITES.
  • Sammansatta samtal - Version 4 kan samla en serie samtal i ett enda paket, vilket gör att servern kan bearbeta dem alla och svara i slutet. Detta används för att minska antalet samtal som ingår i vanliga operationer.
  • Stöder endast TCP – Version 4 av NFS har lämnat förlust och återöverföring upp till det underliggande operativsystemet.

NFSv4.1 och senare

NFSv4.1 och v4.2 är tillgängliga från och med OneFS version 9.3.

Här är den officiella versionsinformationen för 9.3:

PowerScale OneFS Info Hubs
 

Resolution

Monteringsalternativ

Även om Dell Technologies inte har några hårda krav för monteringsalternativ ger Dell Technologies några rekommendationer om hur klienter ansluter. Dell Technologies har inte tillhandahållit några specifika monteringssträngar, eftersom syntaxen som används för att definiera dessa alternativ varierar beroende på vilket operativsystem som används. Du måste följa distributionsunderhållarnas dokumentation för specifik monteringssyntax.

 

PowerScale-supporten rekommenderar även följande informationsdokument som primär referens för NFS-klientkonfiguration med PowerScale, inklusive rekommenderade alternativ för wsize/rize, attributcachelagring med mera:

 

Designöverväganden och bästa praxis
för PowerScale OneFShttps://infohub.delltechnologies.com/en-us/t/powerscale-onefs-nfs-design-considerations-and-best-practices-3/

 

Läs- och skrivstorlek (rsize/wsize)

När det gäller alternativen wsize/rsize rekommenderar PowerScale-supporten en wsize och rsize på minst 128K, baserat på vår inbyggda blockstorlek.

 

Men för de flesta moderna Linux-distributioner rekommenderar PowerScale-stödet att du inte uttryckligen konfigurerar en inställning (det vill säga att du inte anger en läs-/skrivstorlek i klientmonteringsalternativen) och låter klienten omförhandla justeringarna. Moderna Linux-distributioner har stöd för NFS-blockstorlekar på upp till 1 MB och förhandlar automatiskt om den optimala blockstorleken med PowerScale NFS-servern. De förhandlade värdena är idealiska för de mest korrekt konfigurerade nätverken med höga prestanda och låg latens. Undantaget är om du inte har ett program eller en leverantör som specifikt kräver den mindre storleken.

 

När detta inte uttryckligen anges använder NFS-klienten FSINFO-data för PowerScale NFS-servern, enligt definitionen i NFS-exporten som konfigurerats på ditt PowerScale-kluster.

 

Standardinställningarna för PowerScale är följande:

 

NFSv3: 512KB writes / 1MB reads
NFSv4: 1MB writes/ 1MB reads

 

Obs! Genom laboratorietester har Dell Technologies inte sett någon märkbar prestandaförändring genom att justera läs-/skrivstorleken på NFS-klienten. När du väl uppfyller vår inbyggda blockstorlek (som är 128K) har vi inte observerat någon märkbar prestandaförändring.

 

Se sidorna 12 och 19 i nedanstående informationsdokument för mer detaljerad information om "rsize" och "wsize":

 

Designöverväganden och bästa praxis
för PowerScale OneFShttps://infohub.delltechnologies.com/en-us/t/powerscale-onefs-nfs-design-considerations-and-best-practices-3/ 

Definiera återförsök och tidsgränser

PowerScale svarar i allmänhet snabbt på klientkommunikation, men när en nod har förlorat ström eller nätverksanslutning kan det ta några sekunder innan IP-adresserna flyttas till en fungerande nod. Därför är det viktigt att ha korrekt definierade värden för timeout och återförsök. PowerScale rekommenderar vanligtvis en timeout på 60 sekunder för att ta hänsyn till ett värsta tänkbara redundansscenario, inställt på att försöka igen två gånger innan ett fel rapporteras.

Mjuka vs hårda fästen

Hårda monteringar gör att klienten försöker utföra sina åtgärder igen på obestämd tid vid timeout eller fel. Detta säkerställer att klienten inte kopplar bort fästet under omständigheter där PowerScale-klustret flyttar IP-adresser från en nod till en annan. En mjuk montering kommer att göra fel och göra monteringen ogiltig, vilket kräver en återmontering för att återställa åtkomsten när IP-adressen har flyttats.

 

Tillåta avbrott

 

Som standard tillåter de flesta klienter inte att du avbryter en indata/utdata eller I/O-vänteläge, vilket innebär att du inte kan använda ctrl+c för att avsluta vänteprocessen om klustret slutar svara, inklusive interrupt monteringsalternativet gör att dessa signaler kan passera normalt istället.

 

Lokal låsning jämfört med fjärrlåsning

När du monterar en NFS-export kan du ange om en klient genererar sina lås lokalt eller med hjälp av låskoordinatorn i klustret. De flesta klienter använder fjärrlåsning som standard, och det här är vanligtvis det bästa alternativet när flera klienter har åtkomst till samma katalog, men det kan finnas prestandafördelar med att utföra lokal låsning när en klient inte behöver dela åtkomst till katalogen som den arbetar med. Dessutom kommer vissa databaser och programvaror att begära att du använder lokal låsning, eftersom de har en egen koordinator.

 

Cachelagring av attribut (ac/noac)

När det gäller "aktiva cache-tidsgränser" betraktas detta som beteende på klientsidan. Det innebär att PowerScale-supporten inte ger några rekommendationer om de här inställningarna eftersom det beror på vilka behov du har. Kunder kan dock hitta viss allmän vägledning om dessa inställningar på sidan 22 i nedanstående informationsdokument:

 

Designöverväganden och bästa praxis
för PowerScale OneFShttps://infohub.delltechnologies.com/en-us/t/powerscale-onefs-nfs-design-considerations-and-best-practices-3/ 

 

Per sida 22 från ovanstående:


Cachelagring av attribut (ac/noac)

Använd monteringsalternativet noac för att uppnå koherens för attributcache mellan flera klienter. Nästan alla filsystemåtgärder kontrollerar filattributinformation. Klienten behåller den här informationen cachelagrad under en period för att minska nätverks- och serverbelastningen. När noac är i kraft är en klients filattributcache inaktiverad, så varje åtgärd som måste kontrollera en fils attribut tvingas gå tillbaka till servern. Dessutom tvingar noac-alternativet programskrivningar att bli synkrona så att en klient ser ändringar i en fil när den öppnas, på bekostnad av många extra nätverksåtgärder. Som standard är attributcachelagring aktiverat när du monterar NFS. Aktivera cachelagring av attribut för att förbättra prestanda för attributkontroll och minska svarstiden för NFS-åtgärden.

 

Prestanda för NFSv3 jämfört med NFSv4

Baserat på labbtester har PowerScale-supporten inte hittat några märkbara prestandaskillnader mellan olika versioner av NFS i de senaste versionerna av OneFS som stöds. 

Additional Information

Om du vill se wsize/rsize-värdena för en viss NFS-export kan du köra följande kommandon på valfri PowerScale-nod:

 

# isi nfs exports ls -v  --zone <zone name>

 Om du vill söka efter ett specifikt export-ID kan kunderna köra följande:

# isi nfs export view <export id>

 Exempel:

Read Transfer Max Size: 1.00M
     Read Transfer Size: 128.00k
Write Transfer Max Size: 1.00M
 Write Transfer Size: 512.00k

Affected Products

Isilon, PowerScale OneFS

Products

Isilon, PowerScale OneFS
Article Properties
Article Number: 000063022
Article Type: Solution
Last Modified: 02 Jan 2026
Version:  7
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.