För närvarande har Isilon OneFS stöd för NFS-version 3 och 4. NFS version 2 har inte stöd sedan 7.2.X-kodfamiljen flyttades.
NFS version 3 är den mest använda versionen av NFS-protokollet idag och anses allmänt ha den bredaste klienten och filer-implementeringen. Här är viktiga komponenter i den här versionen:
NFS version 4 är den nyaste större versionen av NFS-protokollet och har ökat under implementeringen. För närvarande är NFSv4 i allmänhet mindre performant än v3 mot samma arbetsflöde på grund av det större mängd identitetsmappning och sessionsspårning som krävs för att svara. Här är några av de viktigaste skillnaderna mellan v3 och v4
För närvarande har OneFS inte stöd för NFS-version 4.1. Om du behöver specifika funktioner i version 4.1 kan du prata med ditt kontoteam för att se om det är något vi kan tillhandahålla via OneFS-unika funktionsuppsättning som NFS-filer.
För kunder som har använt Isilon OneFS sedan version 7.1 eller tidigare kan ändringar som gjorts i 7.2.0-versionen av OneFS och stannat kvar tills OneFS 8.1.1 påverka hur klienter som använder kodning som skiljer sig från klustret kan visa och interagera med kataloglistor. Mer information finns i ETA 483840.
Det här är inte ett problem om du började använda OneFS i version 7.2 eller senare.
Även om vi inte har hårda krav på monteringsalternativ, gör vi vissa rekommendationer om hur klienter ansluts. Vi har inte tillhandahållit specifika monteringssträngar eftersom syntaxen som används för att definiera dessa alternativ varierar beroende på vilket operativsystem som används. Du bör läsa dokumentationen för distributionsansvarig för specifik monteringssyntax.
Isilon svarar vanligtvis på klientkommunikation mycket snabbt, men under fall när en nod har förlorat strömförsörjning eller nätverksanslutning kan det ta några sekunder för dess IP-adresser att flytta till en fungerande nod, eftersom det är viktigt att ha korrekt definierade timeout- och omförsöksvärden. Isilon rekommenderar i allmänhet en timeout på 60 sekunder för att stå för ett värsta scenario med redundans, inställd på att försöka igen två gånger innan ett fel rapporteras.
Hårda monteringar gör att klienten försöker utföra s-åtgärder på obestämd tid vid timeout eller fel. Detta säkerställer att klienten inte kopplar bort monteringen i de fall där Isilon-klustret flyttar IP-adresser från en nod till en annan. En mjuk montering gör istället ett fel och förfaller monteringen som kräver en återmontering för att återställa åtkomsten när IP-adressen har flyttats.
Som standard tillåter de flesta klienter inte att du avbryter en indata/utdata- eller I/O-väntetid, vilket innebär att du inte kan använda ctrl+c
osv. för att avsluta vänteprocessen om klustret hänger sig, inklusive interrupt
monteringsalternativet gör att signalerna kan passera normalt istället.
När du monterar en NFS-export kan du ange om en liknande ska utföra den lokalt eller använda låskoordinatorn i klustret. De flesta klienter använder fjärrlåsning som standard, och det är i allmänhet det bästa alternativet när flera klienter får å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 den katalog 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.