Serviceguard NFS Toolkit A.11.11.06, A.11.23.05 and A.11.31.05 Administrator's Guide HP-UX 11i v1, v2, and v3
Table Of Contents
- Serviceguard NFS Toolkit A.11.11.06, A.11.23.05 and A.11.31.05 Administrator's Guide
- Table of Contents
- 1 Overview of Serviceguard NFS
- Limitations of Serviceguard NFS
- Overview of Serviceguard NFS Toolkit A.11.31.05 with Serviceguard A.11.18 (or later) and Veritas Cluster File System Support
- Overview of the Serviceguard NFS Modular Package
- Overview of the NFS File Lock Migration Feature
- Overview of NFSv4 File Lock Migration Feature
- Overview of Serviceguard NFS with Serviceguard A.11.17 Support
- Integrating Support for Cluster File Systems into Serviceguard NFS Toolkit
- Overview of Cluster File Systems in Serviceguard NFS Toolkit
- Limitations and Issues with the current CFS implementation
- Supported Configurations
- How the Control and Monitor Scripts Work
- 2 Installing and Configuring Serviceguard NFS Legacy Package
- Installing Serviceguard NFS Legacy Package
- Before Creating a Serviceguard NFS Legacy Package
- Configuring a Serviceguard NFS Legacy Package
- Copying the Template Files
- Editing the Control Script (nfs.cntl)
- Editing the NFS Control Script (hanfs.sh)
- Editing the File Lock Migration Script (nfs.flm)
- Editing the NFS Monitor Script (nfs.mon)
- Editing the Package Configuration File (nfs.conf)
- Configuring Server-to-Server Cross-Mounts (Optional)
- Creating the Cluster Configuration File and Bringing Up the Cluster
- Configuring Serviceguard NFS Legacy Package over CFS Packages
- 3 Installing and Configuring Serviceguard NFS Modular Package
- Installing Serviceguard NFS Modular Package
- Before Creating a Serviceguard NFS Modular Package
- Configuring a Serviceguard NFS Modular Package
- Configuring Serviceguard NFS Modular Package over CFS Packages
- 4 Migration of Serviceguard NFS Legacy Package to Serviceguard NFS Modular Package
- 5 Sample Configurations for Legacy Package
- Example One - Three-Server Mutual Takeover
- Example Two - One Adoptive Node for Two Packages with File Lock Migration
- Cluster Configuration File for Adoptive Node for Two Packages with File Lock Migration
- Package Configuration File for pkg01
- NFS Control Scripts for pkg01
- NFS File Lock Migration and Monitor Scripts for pkg01
- Package Configuration File for pkg02
- NFS Control Scripts for pkg02
- NFS File Lock Migration and Monitor Scripts for pkg02
- Example Three - Three-Server Cascading Failover
- Example Four - Two Servers with NFS Cross-Mounts
- 6 Sample Configurations for Modular Package
- Index

NOTE: The file name of the NFS_FLM_SCRIPT script must be limited to 13 characters or fewer.
Editing the File Lock Migration Script (nfs.flm)
The File Lock Migration script, nfs.flm, handles the majority of the work involved in maintaining
file lock integrity that follows an HA/NFS failover. The nfs.flm script includes the following
configurable parameters:
• NFS_FLM_HOLDING_DIR - Name of a unique directory created in one of the shared volumes
associated with this package. This directory holds copies of the /var/nfs4/v4_state
files for this package. You must create this directory in one of the shared volumes associated
with this package so that it can migrate with the package (from the primary server to the
adoptive server).
You must dedicate this directory for holding v4_state entries only. In addition, you must
keep it empty. This directory should not have other files or subdirectories when starting the
cluster. All files in this directory are deleted after a failover. . This directory must be located
in the same shared volume as NFS_FLM_HOLDING_DIR.
An example for this parameter is as follows:
NFSv4_FLM_HOLDING_DIR="/pkg1a/v4_state"
• PROPAGATE_INTERVAL - Number of seconds between the attempts of the script to copy
files from the /var/statmon/sm directory into the holding directory, specified by
NFS_FLM_HOLDING_DIR. The default value of this parameter is five seconds.
An example for this parameter is as follows:
PROPAGATE_INTERVAL=5
NOTE: If you enable the File Lock Migration feature, an NFS client (or group of clients)
may hit a corner case of requesting a file lock on the HA/NFS server and not receiving a
crash recovery notification message when the HA/NFS package migrates to an adoptive
node. This occurs only when the NFS client sends its initial lock request to the HA/NFS
server and then the HA/NFS package moves to an adoptive node before the FLM script
copies the /var/statmon/sm entry for this client to the package holding directory.
The probability of hitting this corner-case problem is not very high, because the SM file copy
interval is very short (by default, five seconds). The chances of an NFS client (or group of
NFS clients) sending its initial lock request (it must be the initial request, since this request
generates the /var/statmon/sm file) to the HA/NFS server and having the package migrate
within this same five seconds window are extremely unlikely.
If you repeatedly experience a problem with this corner-case scenario, reduce the copy time
interval by setting the PROPAGATE_INTERVAL parameter to a lower value.
Editing the NFS Monitor Script (nfs.mon)
The NFS monitor script, nfs.mon, contains NFS-specific monitor variables and functions. The
nfs.mon script is an optional component of HA/NFS. The hanfs.sh file specifies whether the
NFS monitor script is used. The following steps describe how to configure the NFS monitor
script:
1. To monitor the File Lock Migration script (nfs.flm), set the NFS_FILE_LOCK_MIGRATION
variable to 1, and set the NFS_FLM_SCRIPT name to match the hanfs.sh script value for
this variable:
NFS_FILE_LOCK_MIGRATION=1 NFS_FLM_SCRIPT="${0%/*}nfs1.flm"
Configuring a Serviceguard NFS Legacy Package 33