Serviceguard NFS Toolkit A.11.11.06, A.11.23.05 and A.11.31.05 Administrator's Guide HP-UX 11i v1, v2, and v3

NOTE: The implementation of a load balancer or DNS round-robin scheme is optional and is
beyond the scope of this publication. For more information about DNS round-robin addressing
refer to the BIND Name Service Overview section in the HP-US IP Address and Client
Administrator's Guide.
Figure 1-2 SG NFS Servers over VxFS — High Availability
Figure 1-3 SG NFS Servers over CFS — High Availability, Scalability, Load Balancing
Limitations and Issues 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 remounted during package failover, which should
reduce failover time.
Limitations and Issues with the current CFS implementation 15