Before Creating an Serviceguard NFS Package

Before creating a Serviceguard NFS package, perform the following tasks:




	NOTE: The following procedures assume your environment is RedHat. If your environment is SLES, replace all occurrences of “`/usr/local`” with “`/opt`”.

Select the NFS Server package during Red Hat Linux installation and verify that the NFS is properly installed.
After RedHat installation is complete, check for the NFS utility to verify NFS installation:
- Verify the NFS utility, run the command:
  # rpm -qa | grep nfs
  If the output contains nfs-utils-<release_version> , the utility is installed.
Set up your Serviceguard cluster according to the instructions in the Managing Serviceguard for Linux user’s guide.
Configure the disk hardware for high availability. Data disks associated with Serviceguard NFS must be external disks. All the nodes that support the Serviceguard NFS package must have access to the external disks. For most disks this means they must be attached to a shared bus that is connected to all nodes which support the package. The disk on which NFS volume is configured can be either a single lun or a split site raid1 array, which provides a level of disaster tolerance to the NFS volume. This can be achieved by setting up a Serviceguard Extended Distance Cluster which uses the linux software RAID as the basic building block. For information on setting up the Extended Distance Cluster, see the HP Serviceguard Extended Distance Cluster for Linux Deployment Guide.
Use LVM commands to set up volume groups, logical volumes, and file systems as needed for the data that will be exported to clients. Refer to the Managing Serviceguard manual.
1. Create a directory for each NFS package. For example:
  /usr/local/cmcluster/nfs1
2. The names of the volume groups must be unique within the cluster, and the major and minor numbers associated with the volume groups must be the same on all nodes. In addition, the mounting points and exported file system names must be the same on all nodes.
  The preceding requirements exist because NFS uses the major number, minor number, inode number, and exported directory as part of a file handle to uniquely identify each NFS file. If differences exist between the primary and adoptive nodes, the client’s file handle would no longer point to the correct file location after movement of the package to a different node.
Make sure the user IDs and group IDs of those who access the Serviceguard NFS file system are the same on all nodes that can run the package.
Make sure the user IDs and group IDs in the /etc/passwd and /etc/group files are the same on the primary node and all adoptive nodes, or use NIS to manage the passwd and group databases.
Create an entry for the name of the package in the DNS or NIS name resolution files, or in /etc/hosts, so that users will mount the exported file systems from the correct node. This entry maps the package name to the package’s relocatable IP address.
Decide whether to place executables locally on each client or on the NFS server. There are a number of trade-offs to be aware of regarding the location of executables with Serviceguard NFS.
The advantages of keeping executables local to each client are as follows:
- No failover time. If the executables are local to the client, there is no delay if the NFS server fails.
- Faster access to the executables than accessing them through the network.
The advantage of putting the executables on the NFS server is as follows:
- Ease of management. If the executables are located in one centralized location, the administrator must update only one copy when changes are made.

Before Creating an Serviceguard NFS Package

Technical documentation

» Table of Contents

» Index