4. Overview
Current SG-NFS over VxFS Support
In a Serviceguard environment, a Serviceguard NFS over VxFS (failover) package is defined as a collection of resources including relocatable IP addresses and logical volume groups (data disks) associated with NFS services. If the server on which a package is running fails, then Serviceguard will automatically start the NFS package on the adoptive node. The adoptive node takes control of the IP addresses and disks and starts the NFS services.
CFS vs. Non-CFS Implementation
The Serviceguard A.11.18 release supports CFS which provides data and lock coherency and allows files and filesystems to be shared and accessed concurrently by multiple servers.
Figure 1 shows how files and filesystems are accessed differently in a non-CFS environment versus a CFS environment. In a non-CFS environment, the highly available filesystems move from one node to another when there is a failover. The solid lines show which primary node provides access to which filesystem and the dotted lines show which adoptive node provides access in the event of a failover. The volumes are exclusively activated only on the server that currently runs the package, which prevents files and filesystems from being altered concurrently by multiple nodes. The Serviceguard NFS package control scripts ensure that upon package failure or shutdown the storage is made inaccessible on the node where the package failed or was halted.
|
|
|
|
| /CFS |
|
|
|
|
|
|
|
| ||
|
|
|
|
| Storage | ||
Cluster |
|
|
|
|
| Cluster | |
Node A |
| /mnt1 |
|
| Node B | ||
|
|
|
|
|
| ||
VxFS
/mnt2 VxFS
A cluster file system is concurrently accessed by all cluster nodes.
A
Figure 1. CFS Vs. Non-CFS (VxFS) Implementation
In a Serviceguard CFS environment, files and filesystems are concurrently accessible on multiple nodes. When a package fails over, the adoptive systems do not have to mount the disks from the failed system because they are already mounted. There is a new
4
