As with all ServiceGuard packages, the control script starts
and stops the NFS package and determines how the package will operate
once it becomes available on a particular node. The control script
contains two sets of code that operate depending on whether the
script is called with the start parameter or the stop parameter.
A template control script
is provided in /opt/cmcluster/nfs/nfs.cntl. “Editing the Control
Script (nfs.cntl)” tells you how to
modify this template file for your own NFS packages.
Starting the NFS Services |
 |
When called with the start parameter, the control script does the following:
Activates the volume group or volume
groups associated with the package.
Mounts each file system associated with the package.
Initiates the NFS monitor script to check periodically
on the health of NFS services, if you have configured your NFS package
to use the monitor script.
Exports each file system associated with the package
so that it can later be NFS-mounted by clients.
Assigns a package IP address to the LAN card on
the current node.
After this sequence, the NFS server is active, and clients
can NFS-mount the exported file systems associated with the package.
Halting the NFS Services |
|
When called with the stop parameter, the control script does the following:
Removes the package IP address from
the LAN card on the current node.
Un-exports all file systems associated with the
package so that they can no longer be NFS-mounted by clients.
Halts the monitor process.
Halts the rpc.lockd and rpc.statd daemons to release file locks so that file systems
can be unmounted. If the server is also an NFS client, any file
locks it holds will be lost.
Restarts the rpc.lockd and rpc.statd daemons so that they can manage the file locks
for other NFS packages still running on the server.
Unmounts each file system associated with the package.
Deactivates each volume group associated with the
package.
After this sequence, the NFS package is inactive on the current
node and may start up on an alternate node or be restarted later
on the same node.
Monitoring the NFS Services |
|
The monitor script /etc/cmcluster/nfs/nfs.mon works by periodically checking the status of NFS
services using the rpcinfo command. If any service fails to respond, the
script exits, causing a switch to an adoptive node.
The monitor script monitors only those NFS services configured
in the /etc/rc.config.d/nfsconf file to be started at system boot. If you set the NFS_SERVER variable to 1, the monitor script monitors the nfsd, rpc.lockd, and rpc.statd processes. (If one nfsd process dies or is killed, the package fails over,
even if other nfsd processes are still running.) If you set the PCNFS_SERVER variable to 1, the monitor script monitors the pcnfsd process, and if you set the START_MOUNTD variable to 1, it monitors the rpc.mountd process.
The default NFS control script does not invoke the monitor
script. You do not have to run the NFS monitor script to use MC/ServiceGuard
NFS. If your NFS package configuration file specifies PKG_SWITCHING_ENABLED YES and NET_SWITCHING_ENABLED YES (the defaults), the package will switch to the
next adoptive node or to a standby network interface in the event
of a node or network failure. However, if one of the NFS services goes
down while the node and network remain up, you need the NFS monitor
script to detect the problem and to switch the package to an adoptive
node.
Whenever the monitor script detects an event, it logs it to
a file with the same name as your NFS control script but with a .log extension. Each NFS package has its own log file.
For example, if your control script is called /etc/cmcluster/nfs/nfs1.cntl, the log file is called /etc/cmcluster/nfs/nfs1.cntl.log.
|
| |
|
 | TIP: Starting with A.11.00.03, you can specify the number
of retry attempts for the following three daemons in the nfs.mon file in the Control Script: |
|
| |
|
On the Client Side |
|
The client should NFS-mount a file system using the package
name in the mount command. The package name is associated with the
package's relocatable IP address. On client systems, be
sure to use a hard mount and set the proper retry values for the
mount. Alternatively, set the proper timeout for automounter. The
timeout should be greater than the total end-to-end recovery time
for the MC/ServiceGuard NFS package—that is, running fsck, mounting file systems, and exporting file systems
on the new node. (With journalled file systems, this time should
be between one and two minutes.) Setting the timeout to a value greater
than the recovery time allows clients to reconnect to the file system
after it returns to the cluster on the new node.
Printable version
