PowerScale: OneFS: Metodtips för NFS-klientinställningar
概要: I den här artikeln beskrivs bästa praxis och rekommendationer för inställningar och monteringsalternativ på klientsidan när NFS-protokollet används för att ansluta till ett PowerScale-kluster. Den gäller för alla versioner av OneFS som stöds för närvarande. ...
現象
OneFS: Metodtips för NFS-klientinställningar
原因
Protokollversioner som stöds
För närvarande har PowerScale OneFS stöd för NFS 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 allmänt ha den bredaste klient- och filanvändningen. Här är de viktigaste komponenterna 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, så vidare
- 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. Vi 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. För närvarande är NFSv4 vanligtvis sämre prestanda än v3 mot samma arbetsflöde på grund av den större mängden identitetsmappnings- och sessionsspårningsarbete som krävs för att svara. 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, utan gör det i stället till en typ av anrop som vanligtvis ä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
解決方法
Monteringsalternativ
Även om vi inte har några hårda krav för monteringsalternativ ger vi några rekommendationer om hur klienterna ansluter. Vi har inte angett 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 behålla dokumentationen för distributionsansvariga för specifik monteringssyntax.
Definiera återförsök och tidsgränser
Även om PowerScale i allmänhet svarar på klientkommunikation mycket snabbt, kan det ta några sekunder för nodens IP-adresser att flyttas till en fungerande nod när en nod har förlorat ström eller nätverksanslutning. Därför är det viktigt att ha korrekt definierade värden för timeout och återförsök. PowerScale rekommenderar vanligtvis en tidsgräns 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, osv., för att avsluta vänteprocessen om klustret slutar svara, inklusive interrupt monteringsalternativet gör att dessa signaler kan passera normalt istället.
Lokal jämförelse med fjärrlåsning
När du monterar en NFS-export kan du ange om en like ska utföra 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 ska ha å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.