| If you go back and look at the output from cmviewcl , you will notice that the package is not started by default, even though we had an option in the configuration file called AUTO_RUN and the default value was YES . Serviceguard will not start the application when it is first added to the cluster. After a subsequent restart of the cluster, applications with AUTO_START set to YES will automatically start on the first available node. Before we actually start the package, we need to have a quick word about two switching parameters: AUTO_RUN and NODE SWITCHING . -
AUTO_RUN : Every package has an attribute called AUTO_RUN , which determines if a package can be run automatically among nodes in the cluster. If AUTO_RUN is disabled, the package will not move to other nodes, even if the node was enabled to receive the package. -
Node Switching : Every node has an attribute per package called SWITCHING , which determines if that package can be received (switched to) by that node. If SWITCHING is disabled on a node for a particular package, that package will not move to that particular node, even though the package is enabled for package switching. With AUTO_RUN and NODE_SWITCHING in mind, we actually have two options to start the package. Let's consider both by revisiting the output from cmviewcl “v “p clockwatch :
root@hpeos001[clockwatch] # cmviewcl -v -p clockwatch UNOWNED_PACKAGES PACKAGE STATUS STATE AUTO_RUN NODE clockwatch down halted disabled unowned Policy_Parameters: POLICY_NAME CONFIGURED_VALUE Failover configured_node Failback manual Script_Parameters: ITEM STATUS NODE_NAME NAME Subnet up hpeos001 192.168.0.0 Subnet up hpeos002 192.168.0.0 Node_Switching_Parameters: NODE_TYPE STATUS SWITCHING NAME Primary up enabled hpeos001 Alternate up enabled hpeos002 root@hpeos001[clockwatch] #
As we can see, AUTO_RUN is disabled . When enabled, the package will automatically run on the first node that is enabled to run it (also the package will fail over to an adoptive node should it have to). If we look near the bottom of the output from cmviewcl , we can see that both nodes have SWITCHING enabled for this package. This means that both nodes are able to receive the package when it is started. To start the package, I could either use cmrunpkg “v clockwatch simply to run the package on the first available node, or cmmodpkg “v “e clockwatch to enable package switching, i.e., set AUTO_RUN to enable. So the question is "Should I use cmrunpkg , which seems the obvious choice, or should I run cmmodpkg ?" I agree that cmrunpkg does seem the obvious choice, but if we use cmrunpkg we will be left with the situation that package switching ( AUTO_RUN ) is still disabled. In the event of a failure, the application will not fail over to an adoptive node. If we are to use cmrunpkg , we will have to use cmmodpkg as well, as in this example:
# cmrunpkg v clockwatch # cmmodpkg v e clockwatch
The alternative is simply to run cmmodpkg to enable package switching. If we think about it and review the output from cmviewcl , everything else is in place and ready to go. If we simply enable package switching, Serviceguard will realize that the package is currently not running and there are nodes able to receive it. The result will be that the package is switched to the first available node, i.e., it is started. This is what I chose to do, and here is the output from cmmodpkg and cmviewcl .
root@hpeos001[clockwatch] # cmmodpkg -v -e clockwatch Enabling switching for package clockwatch. cmmodpkg : Successfully enabled package clockwatch. cmmodpkg : Completed successfully on all packages specified. root@hpeos001[clockwatch] # root@hpeos001[clockwatch] # cmviewcl -v -p clockwatch PACKAGE STATUS STATE AUTO_RUN NODE clockwatch up running enabled hpeos001 Policy_Parameters: POLICY_NAME CONFIGURED_VALUE Failover configured_node Failback manual Script_Parameters: ITEM STATUS MAX_RESTARTS RESTARTS NAME Service up 0 0 clock_mon Subnet up 192.168.0.0 Node_Switching_Parameters: NODE_TYPE STATUS SWITCHING NAME Primary up enabled hpeos001 (current) Alternate up enabled hpeos002 root@hpeos001[clockwatch] #
We can also check the logfile /etc/cmcluster/clockwatch/clockwatch.cntl.log to ensure that all the necessary steps were undertaken and executed properly. Here is an extract from my logfile:
root@hpeos001[clockwatch] # more clockwatch.cntl.log ########### Node "hpeos001": Starting package at Sat Aug 9 01:42:22 BST 2003 ########### Aug 9 01:42:22 - "hpeos001": Activating volume group /dev/vg01 with exclusive option. Activated volume group in Exclusive Mode. Volume group "/dev/vg01" has been successfully changed. Aug 9 01:42:23 - Node "hpeos001": Checking filesystems: /dev/vg01/db /dev/vg01/progs /dev/vg01/rdb:file system is clean - log replay is not required /dev/vg01/rprogs:file system is clean - log replay is not required Aug 9 01:42:25 - Node "hpeos001": Mounting /dev/vg01/db at /clockwatch/logs Aug 9 01:42:26 - Node "hpeos001": Mounting /dev/vg01/progs at clockwatch/bin Aug 9 01:42:27 - Node "hpeos001": Adding IP address 192.168.0.220 to subnet 192.168.0.0 Attempting to start clockwatch Starting Clockwatch ; logfile = /clockwatch/logs/watchlog Aug 9 01:42:28 - Node "hpeos001": Starting service clock_mon using "/etc/cmcluster/clockwatch/CLOCKWATCH.sh monitor" ########### Node "hpeos001": Package start completed at Sat Aug 9 01:42:28 BST  2003 ###########
If you spend some time studying the control script, you will uncover toward the end of the script the sequence of events that the control script goes through in order to start an application. Here is an excerpt from my control script:
if [[ = "start" ]] then print "\n\t########### Node \"$(hostname)\": Starting package at $(date) ###########" verify_physical_data_replication # add hook for MetroCluster activate_volume_group activate_disk_group check_and_mount verify_ha_nfs # add hook for NFS add_ip_address get_ownership_dtc customer_defined_run_cmds start_services start_resources
When stopping a package, the control script essentially performs the same steps but in reverse order:
elif [[ = "stop" ]] then print "\n\t########### Node \"$(hostname)\": Halting package at $(date) ###########" stop_resources halt_services customer_defined_halt_cmds disown_dtc remove_ip_address verify_ha_nfs # add hook for NFS umount_fs deactivate_volume_group deactivate_disk_group
Pretty neat, don't you think? Let's move on to start testing whether the package will behave as we expect. | 