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 Highly
Available 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.
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 highly available
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
