Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
Managing Serviceguard NFS for Linux > Chapter 1 Serviceguard NFS for LINUX Introduction

How the Control and Monitor Scripts Work

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Index

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 environments.

Refer to the Managing 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 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:

  • portmap

  • rpc.statd

  • nfsd

  • rpc.mountd

  • rpc.rquotad, , if QUOTO_MON is set to “YES” in hanfs.conf

  • lockd

If any of the services are dead or hangs, the nfs.mon. will cause the package to fail.

NOTE: To configure NFS for maximal availability, you must do the following:
  • To have the NFS package start automatically when the cluster starts up, and to start on an adoptive node after a failure, you need to specify AUTO_RUN=YES in the package configuration file.

  • Also, the default NFS control script does not invoke the NFS monitoring script, nfs.mon. To invoke this script (see Chapter 3 “Sample Configurations”) to trigger a failover if one of the package’s NFS services goes down while the node and network remain up.

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 toolkit, 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
Privacy statement Using this site means you accept its terms Feedback to webmaster
© Hewlett-Packard Development Company, L.P.