White Paper

6
/cfs1
NFS Server1
/cfs1,/cfs2,/cfs3
NFS Server2
/cfs1,/cfs2,/cfs3
NFS Server3
/cfs1,/cfs2,/cfs3
Load
Balancer
Load
Balancer
/cfs2
NFS
Client3
Figure 3. SG NFS Servers over CFS – High Availability, Scalability, Load
Balancing
NFS
Client1
NFS
Client2
Cluster File System
/cfs3
Shared Storage
Serviceguard NFS servers
Issues and Limitations with the Current CFS Implementation
The main limitation with the current CFS implementation is that during package
failover, an NFS client may lose a file lock in the following situation. If Client1 locks a
CFS file on Server1, and Client2 attempts to lock the same CFS file on Server2, Client2
will wait for the lock to become available. If a failover occurs on Server1, Client1 will
lose the file lock and Client2 will be granted the lock. If file locking is required for this
situation, NFS failover packages must be used to export the CFS filesystems instead of
multi-node export packages. Each cluster filesystem must only be exported by one
node in the cluster. This configuration is similar to Serviceguard NFS over VxFS, as
shown in Figure 4, in that the file would just be accessible on one server and when that
package fails over the file locks would be restored properly after the package restarts.
One advantage this configuration has compared to the Serviceguard NFS over VxFS
configuration is that the filesystems do not need to be unmounted and re-mounted
during package failover, which should reduce failover time.