The Node State Manager (NSM) reacts to notifications from the Cluster Membership Manager (CMM) by executing user-provided scripts. This is a simple way to include an application that is not high availability-aware (non-HA-aware) in a cluster. For information about NSM notifications, see the following sections.

Introduction to the Node State Manager

On a running cluster, any new master or vice-master node is signaled to the applications that subscribed to receive notifications. To permit a non-HA-aware application to react to these notifications, the NSM will subscribe to the notifications and execute the user-provided scripts associated with each particular situation.Scripts will be executed when the node on which the nhnsmd daemon is running becomes master or vice-master, but also when it stops being either of these. Scripts executed when a node enters a role are called Ennxxxxxx. Scripts executed when a node leaves a role are called Lnnxxxxxx. In both cases nn is a two-digit number and xxxxxx is the name of the script. Scripts are executed in alphabetical order, which means that the scripts E01backup, E01server, and E02client will be executed in that order.

The scripts must be located in the directories specified by the NSM.Exec.MasterDir and NSM.Exec.ViceMasterDir properties in the /etc/opt/SUNWcgha/nhfs.conf file on the Solaris OS, or in the /etc/opt/sun/nhas/nhfs.conf file on Linux.On a role change, if the node was master or vice-master, it will first execute the Lnnxxxxxx scripts for the old role, and only then the Ennxxxxxx scripts for the new role. This procedure works in the same way as the system initialization rc.d Snnxxxxxx and Knnxxxxxx scripts.

Writing Scripts

Scripts can perform whatever action is needed to launch or stop a service as long as their behavior doesn’t interfere with the normal behavior of the Netra HA Suite software. For more information, see the nhnsmd1M man page on the Solaris OS or the nhnsmd8 on Linux.

Two arguments are passed to the scripts you provide. The first is the action being executed, for which possible values are enter and leave. The second argument received by a user-provided script is the role of the node. The value for this argument can only be master or vicemaster. Using these arguments, the same script can be used for entering and leaving any of the roles.

Services must run on the master node. The script you provide that is invoked when the node enters the master role should launch the service (or activate it, if it is in standby state). The user-provided script that is invoked when a node leaves the master role should stop the service (or put it into standby state).

A script is not usually needed for nodes that are entering or leaving the vice-master role, but they are available for special cases where some special actions are needed on the vice-master node.

Note - You should not use the script that is invoked when a node enters the vice-master role to stop the services that are started when a node enters the master role. This script will not be invoked if the master node does not become vice-master (it is disqualified), which prevents the services from being stopped.

Scripts must have the “executable” flag set.

Output From User-Defined Scripts

Any output (stdout and stderr) produced by these scripts will be directed to the log files. The log files will be placed in the directories that are specified in the NSM.Log.MasterDir and NSM.Log.ViceMasterDir properties and will be named with the script’s name, followed by the .log extension.The logging directories must be writable by the superuser.