HP Serviceguard Toolkit for NFS instruction

NFS

Client1

NFS

Client2

Load

Balancer

NFS

Client3

NFS Server1

/cfs1,/cfs2,/cfs3

Serviceguard NFS servers

NFS Server2

/cfs1,/cfs2,/cfs3

Cluster File System

NFS Server3

/cfs1,/cfs2,/cfs3

Shared Storage	/cfs1 /cfs2 /cfs3

Figure 3. SG NFS Servers over CFS – High Availability, Scalability, Load

Balancing

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.