As with all ServiceGuard packages, the package control scripts
start and stop the NFS package and determine how the package will
operate once it becomes available on a particular node. Each 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 package control script pkg.cntl can be generated by using cmmakepkg -s pkg.cntl. The template script hanfs.sh is provided in /usr/local/cmcluster/nfstoolkit directory for RedHat environments, and /opt/cmcluster/nfstoolkit for SLES 8/UL environments.
Refer to the Managing M/C ServiceGuard for Linux-Chapter
6 for additional information on creating the files. Refer to “Editing
the Package Control Scripts (pkg.cntl)” and “Editing
the NFS Control Script (hanfs.sh)” for information on how
to modify this package control script template file for your own
packages.
Starting
the NFS Services |
 |
When called with the start parameter, the package control script does the
following:
Activates MD devices that are used
by column groups.
Activates the volume group or volume groups associated
with the package.
Mounts each file system associated with the package.
Invoke toolkit.sh to run the NFS start script.
The NFS script hanfs.sh, exports each file system associated with the package
so that it can later be NFS-mounted by clients.
The NFS script 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.
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.
The package control script invokes the toolkit.sh
to run the NFS script and to halt the NFS related process.
The NFS script un-exports all file systems associated
with the package so that they can no longer be NFS-mounted by clients.
The NFS script halts the monitor process.
Unmounts each file system associated with the package.
Deactivates each volume group associated with the
package.
Deactivates each MD device.
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 nfs.mon, located in the file /usr/local/cmcluster/nfstoolkit for RedHat environments, and /opt/cmcluster/nfstoolkit for SLES 8/UL environments), 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 NFS services including:
If any of the services are dead or hangs, the nfs.mon. will cause the package to fail.
Whenever the monitor script detects an event, it logs information
to a file using the same name as your NFS control script adding
a .log extension. Each NFS package has its own log file. For
example, if your control script is called pkg1.cntl, the package log file is called pkg1.cntl.log. The NFS monitor log file, which is on the same directory
as the NFS control script, is always called hanfs.sh.log
Remote
mount table synchronization |
|
With NFS tool kit, a remote mount table synchronization binary
code is installed in /usr/bin/sync_rmtab. This program is provided for synchronizing the client
current mount table, /var/lib/nfs/rmtab, in the case of a NFS package failover. This synchronization
process ensures NFS clients access NFS seamlessly in the case of
the NFS package failover. The NFS control script, hanfs.sh, calls the synchronization program when the remote mount
table needs to be synchronized.
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 auto-mounter. The
timeout should be greater than the total end-to-end recovery time
for the ServiceGuard NFS package—that is, running fsck, mounting file systems, and exporting file systems
on the new node. 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
