Al momento, PowerScale OneFS supporta NFS versioni 3 e 4. NFS versione 2 non è supportato.
NFS 3 è la versione oggi più ampiamente utilizzata del protocollo NFS, con l'adozione di client e filer più diffusa. Di seguito sono riportati i componenti chiave di questa versione:
NFS versione 4 è la revisione principale più recente del protocollo NFS e la sua adozione è sempre più diffusa. Al momento, NFSv4 è generalmente meno performante rispetto a v3 sullo stesso flusso di lavoro a causa della maggiore quantità di mapping delle identità e del lavoro di monitoraggio delle sessioni richiesto per rispondere. Ecco alcune delle principali differenze tra v3 e v4
NFSv4.1 e v4.2 sono disponibili a partire da OneFS versione 9.3
Ecco le informazioni di rilascio ufficiali per 9.3:
https://dl.dell.com/content/docu105998_powerscale-onefs-9-3-0-0-release-notes.pdf?language=en_us
Anche se non abbiamo requisiti rigidi per le opzioni di mount, forniamo alcuni consigli su come si connettono i client. Non forniamo stringhe di mount specifiche, in quanto la sintassi utilizzata per definire queste opzioni varia a seconda del sistema operativo in uso. È necessario disporre della documentazione per i responsabili della distribuzione per la sintassi di mount specifica.
Sebbene PowerScale risponda in genere alla comunicazione client molto rapidamente, nei casi in cui un nodo abbia perso l'alimentazione o la connettività di rete, potrebbero essere necessari alcuni secondi affinché gli indirizzi IP passino a un nodo funzionale, pertanto è importante avere valori di timeout e tentativi correttamente definiti. In genere, PowerScale consiglia un timeout di 60 secondi per tenere conto di uno scenario di failover critico, impostato un nuovo tentativo due volte prima di segnalare un errore.
Con gli hard mount, il client ripete le operazioni a tempo indeterminato in base al timeout o all'errore. In questo modo il client non scollega il mount nei casi in cui il PowerScale Cluster sposti gli indirizzi IP da un nodo all'altro. Un soft mount determina un errore e il timeout del mount, richiedendo di ripetere l'operazione per ripristinare l'accesso dopo lo spostamento degli indirizzi IP.
Per impostazione predefinita, la maggior parte dei client non consente di interrompere l'attesa di un input/output (I/O), ovvero non è possibile utilizzare ctrl+c
e così via per terminare il processo di attesa se il cluster smette di rispondere. L'opzione di mount interrupt
consente invece il normale passaggio di tali segnali.
Durante il mounting di un'esportazione NFS, è possibile specificare se eseguire i blocchi in locale o utilizzando il coordinatore dei blocchi nel cluster. La maggior parte dei client utilizza per impostazione predefinita il blocco remoto e questa è in genere l'opzione migliore quando più client accedono alla stessa directory, tuttavia possono esserci vantaggi in termini di prestazioni nell'esecuzione di blocchi locali quando un client non deve condividere l'accesso alla directory in uso. Inoltre, alcuni database e software richiedono l'uso dei blocchi locali, in quanto dispongono di un proprio coordinatore.