2.5.5. Setting Up NFS Over GFS2
Due to the added complexity of the GFS2 locking subsystem and its clustered nature, setting up NFS over GFS2 requires taking many precautions and careful configuration. This section describes the caveats you should take into account when configuring an NFS service over a GFS2 file system.
Warning
If the GFS2 file system is NFS exported, and NFS client applications use POSIX locks, then you must mount the file system with the
localflocks option. The intended effect of this is to force POSIX locks from each server to be local: that is, non-clustered, independent of each other. (A number of problems exist if GFS2 attempts to implement POSIX locks from NFS across the nodes of a cluster.) For applications running on NFS clients, localized POSIX locks means that two clients can hold the same lock concurrently if the two clients are mounting from different servers. If all clients mount NFS from one server, then the problem of separate servers granting the same locks independently goes away. If you are not sure whether to mount your file system with the localflocks option, you should not use the option; it is always safer to have the locks working on a clustered basis.
In addition to the locking considerations, you should take the following into account when configuring an NFS service over a GFS2 file system.
- Red Hat supports only Red Hat High Availability Add-On configurations using NFSv3 with locking in an active/passive configuration with the following characteristics:
- The back-end file system is a GFS2 file system running on a 2 to 16 node cluster.
- An NFSv3 server is defined as a service exporting the entire GFS2 file system from a single cluster node at a time.
- The NFS server can fail over from one cluster node to another (active/passive configuration).
- No access to the GFS2 file system is allowed except through the NFS server. This includes both local GFS2 file system access as well as access through Samba or Clustered Samba.
- There is no NFS quota support on the system.
This configuration provides HA for the file system and reduces system downtime since a failed node does not result in the requirement to execute thefsckcommand when failing the NFS server from one node to another. - The
fsid=NFS option is mandatory for NFS exports of GFS2. - If problems arise with your cluster (for example, the cluster becomes inquorate and fencing is not successful), the clustered logical volumes and the GFS2 file system will be frozen and no access is possible until the cluster is quorate. You should consider this possibility when determining whether a simple failover solution such as the one defined in this procedure is the most appropriate for your system.
