Linux NFS Concepts

Internal

• Linux NFS

Locking Considerations

NFSv3 does not time out the lock held by a process that crashes. NFSv4 locks time out in the same situation.

Root Squash

Root squash represents reduction of the access rights for the remote superuser (root) when using identity authentication (local user is the same as remote user). If using root squash, the remote user is no longer super user on the NFS server. After implementing the root squash, the authorized superuser performs restricted actions after logging into an NFS server directly and not just by mounting the exported NFS folder.

NFS Caching

The nfs client mount option “ac” causes the client to cache file attributes. “ac” is the default as well. Changing it to not cache attributes “noac” incurs a significant performance penalty. The max time, by default that the nfs client caches file or directory attributes is 30 sec min, and 60 sec maximum, by default.

Asynchronous NFS

The default export behavior for both NFS Version 2 and Version 3 protocols, used by exportfs in nfs-utils versions prior to nfs-utils-1.0.1 is "asynchronous". This default permits the server to reply to client requests as soon as it has processed the request and handed it off to the local file system, without waiting for the data to be written to stable storage. This is indicated by the async option denoted in the server's export list. It yields better performance at the cost of possible data corruption if the server reboots while still holding unwritten data and/or metadata in its caches. This possible data corruption is not detectable at the time of occurrence, since the async option instructs the server to lie to the client, telling the client that all data has indeed been written to the stable storage, regardless of the protocol used.

More details: http://nfs.sourceforge.net/nfs-howto/ar01s05.html#sync_versus_async

HA

NFS v4 is a viable option for mission critical applications. Oracle, SAP, etc sell NFS v4 HA solutions. NFS HA requires resilient compute, networking and storage:

1. Create a multipath HA environment on 2 RHEL hosts with VIPs.

Multipath HA is a hardware configuration that provides redundancy for the path from each disk controller to every disk shelf in the configuration. More details in https://library.netapp.com/ecmdocs/ECMP1210206/html/GUID-C4630743-898E-4AB1-A321-E6E38532CEF6.html.

Multipath_Netapp

2. Make sure that the physical network is resilient.

3. Configure Resilient Storage add-on for two hosts for path redundancy. The Red Hat Resilient Storage Add-on creates a resilient storage feature.

4. The storage device needs to be able to handle multipath HA. The shared storage device needs at least two nodes or controllers that is compatible with Resilient Storage.

5. Use in-memory caching and commit with replication to other node, so it can flush that to whatever the datastore is if the path outage is intolerable to the application. That way the application can recover, and it would just show up to the use as a minor delay (usually failover can occur in less than a couple of seconds).