Creating the Package Configuration

The package configuration process defines a set of application services that are run by the package manager when a package starts up on a node in the cluster. The configuration also includes a prioritized list of cluster nodes on which the package can run together with definitions of the acceptable types of failover allowed for the package.

You can create a package using SAM or using HP-UX commands and editors. The following section describes SAM configuration. If you are using MC/LockManager commands, skip ahead to the section entitled "Using MC/LockManager Commands to Create a Package."

Using SAM to Configure a Package

To configure a high availability package use the following steps on the configuration node (ftsys9):

In SAM, choose the "Clusters" area, then the High Availability Clusters option.
Choose the Package Configuration option. SAM displays a Package Configuration screen. If no packages have yet been configured, the list area will be empty. If there are one or more MC/LockManager packages already configured on clusters in your network, you will see them listed.
Select the Actions menu, and choose Create/Add a Package. A step menu appears.
Choose each required step in sequence, filling in the dialog boxes with required information, or accepting the default values shown. For information about each step, choose Help.
When finished with all steps, select OK at the Step Menu screen. This action creates (or modifies) the package configuration file and then copies the file to all the nodes in the cluster. This action also creates a package control script which is copied to all nodes.
When the file copying is finished, you return to the Package Configuration screen.
Exit from the Package Configuration screen, returning to the High Availability Clusters menu.

Skip ahead to the section on "Writing the Package Control Script."

Using MC/LockManager Commands to Create a Package

Use the following procedure to create packages by editing and processing a package configuration file.

First, create a subdirectory for each package you are configuring in the /etc/cmcluster directory:
# mkdir /etc/cmcluster/pkg1
You can use any directory names you wish.
Next, generate a package configuration template for the package:
# cmmakepkg -p /etc/cmcluster/pkg1/pkg1conf.ascii
You can use any file names you wish for the ASCII templates.
Edit these template files to specify package name, prioritized list of nodes, the location of the control script, and failover parameters for each package. Include the data recorded on the Package Configuration Worksheet.

Configuring in Stages

It is recommended to configure packages on the cluster in stages, as follows:

Configure volume groups and mount points only.
Apply the configuration.
Distribute the control script to all nodes.
Run the cluster and ensure that packages can be moved from node to node.
Halt the cluster.
Configure package IP addresses and application services in the control script.
Distribute the control script to all nodes.
Run the cluster and ensure that applications run as expected and that packages fail over correctly when services are disrupted.

Package Configuration Template File

The following is a sample package configuration file template customized for a typical package.

# **********************************************************************
# ****** HIGH AVAILABILITY PACKAGE CONFIGURATION FILE (template) *******
# **********************************************************************
# ******* Note: This file MUST be edited before it can be used. ********
# * For complete details about package parameters and how to set them, *
# * consult the MC/LockManager or MC/LockManager manpages or manuals. *
# **********************************************************************
 
# Enter a name for this package.  This name will be used to identify the
# package when viewing or manipulating it.  It must be different from
# the other configured package names.
 
PACKAGE_NAME  pkg1
 
# Enter the failover policy for this package. This policy will be used
# to select an adoptive node whenever the package needs to be started.
# The default policy unless otherwise specified is CONFIGURED_NODE.
# This policy will select nodes in priority order from the list of
# NODE_NAME entries specified below.
 
# The alternative policy is MIN_PACKAGE_NODE. This policy will select
# the node, from the list of NODE_NAME entries below, which is
# running the least number of packages at the time of failover.
 
#FAILOVER_POLICY        CONFIGURED_NODE
 
# Enter the failback policy for this package. This policy will be used
# to determine what action to take during failover when a a package
# is not running on its primary node and its primary node is capable
# of running the package. Default is MANUAL which means no attempt
# will be made to move the package back to it primary node when it is
# running on an alternate node. The alternate policy is AUTOMATIC which
# means the package will be moved back to its primary node whenever the
# primary node is capable of running the package.
 
#FAILBACK_POLICY           MANUAL
 
# Enter the names of the nodes configured for this package.  Repeat
# this line as necessary for additional adoptive nodes.
# Order IS relevant.  Put the second Adoptive Node AFTER the first
# one.
# Example : NODE_NAME  original_node  
#           NODE_NAME  adoptive_node  
 
NODE_NAME ftsys9
NODE_NAME ftsys10
 
 
# Enter the complete path for the run and halt scripts.  In most cases
# the run script and halt script specified here will be the same script,
# the package control script generated by the cmmakepkg command.  This
# control script handles the run(ning) and halt(ing) of the package.
# If the script has not completed by the specified timeout value,
# it will be terminated.  The default for each script timeout is
# NO_TIMEOUT.  Adjust the timeouts as necessary to permit full 
# execution of each script.
# Note: The HALT_SCRIPT_TIMEOUT should be greater than the sum of
# all SERVICE_HALT_TIMEOUT specified for all services.
 
RUN_SCRIPT   /etc/cmcluster/pkg1/control.sh
RUN_SCRIPT_TIMEOUT      NO_TIMEOUT
HALT_SCRIPT  /etc/cmcluster/pkg1/control.sh
HALT_SCRIPT_TIMEOUT     NO_TIMEOUT
 
 
# Enter the SERVICE_NAME, the SERVICE_FAIL_FAST_ENABLED and the
# SERVICE_HALT_TIMEOUT values for this package.  Repeat these  
# three lines as necessary for additional service names.  All  
# service names MUST correspond to the service names used by   
# cmrunserv and cmhaltserv commands in the run and halt scripts.
#
# The value for SERVICE_FAIL_FAST_ENABLED can be either YES or 
# NO.  If set to YES, in the event of a service failure, the   
# cluster software will halt the node on which the service is  
# running.  If SERVICE_FAIL_FAST_ENABLED is not specified, the 
# default will be NO.                                          
#
# SERVICE_HALT_TIMEOUT is represented in the number of seconds.
# This timeout is used to determine the length of time (in     
# seconds) the cluster software will wait for the service to   
# halt before a SIGKILL signal is sent to force the termination
# of the service.  In the event of a service halt, the cluster 
# software will first send a SIGTERM signal to terminate the   
# service.  If the service does not halt, after waiting for the
# specified SERVICE_HALT_TIMEOUT, the cluster software will send
# out the SIGKILL signal to the service to force its termination.
# This timeout value should be large enough to allow all cleanup
# processes associated with the service to complete.  If the   
# SERVICE_HALT_TIMEOUT is not specified, a zero timeout will be
# assumed, meaning the cluster software will not wait at all   
# before sending the SIGKILL signal to halt the service.       
#
# Example: SERVICE_NAME                   DB_SERVICE           
#          SERVICE_FAIL_FAST_ENABLED      NO                   
#          SERVICE_HALT_TIMEOUT           300                  
#
# To configure a service, uncomment the following lines and    
# fill in the values for all of the keywords.                  
#
SERVICE_NAME                   service1 
SERVICE_FAIL_FAST_ENABLED      NO 
SERVICE_HALT_TIMEOUT           300 
 
 
# Enter the network subnet name that is to be monitored for this package.
# Repeat this line as necessary for additional subnet names.  If any of
# the subnets defined goes down, the package will be switched to another
# node that is configured for this package and has all the defined subnets
# available.
 
#SUBNET   15.16.168.0
 
 
# The following keywords (RESOURCE_NAME, RESOURCE_POLLING_INTERVAL, and
# RESOURCE_UP_VALUE) are used to specify Package Resource Dependencies.  To 
# define a Package Resource Dependency, a RESOURCE_NAME line with a fully
# qualified resource path name, and one or more RESOURCE_UP_VALUE lines are 
# required.  A RESOURCE_POLLING_INTERVAL line (how often in seconds the resource
# is to be monitored) is optional and defaults to 60 seconds.  An operator and 
# a value are used with RESOURCE_UP_VALUE to define when the resource is to be 
# considered up.  The operators are =, !=, >, <, >=, and <=, depending on the 
# type of value.  Values can be string or numeric.  If the type is string, then
# only = and != are valid operators.  If the string contains whitespace, it
# must be enclosed in quotes.  String values are case sensitive.  For example,
#
# 					Resource is up when its value is
# 					
# 	RESOURCE_UP_VALUE	= UP			"UP"
# 	RESOURCE_UP_VALUE	!= DOWN			Any value except "DOWN"
# 	RESOURCE_UP_VALUE	= "On Course"		"On Course"
# 
# If the type is numeric, then it can specify a threshold, or a range to
# define a resource up condition.  If it is a threshold, then any operator
# may be used.  If a range is to be specified, then only > or >= may be used
# for the first operator, and only < or <= may be used for the second operator.
# For example,
# 					Resource is up when its value is
# 					
# 	RESOURCE_UP_VALUE     = 5		5		    (threshold)
# 	RESOURCE_UP_VALUE     > 5.1		greater than 5.1    (threshold)
# 	RESOURCE_UP_VALUE     > -5 and < 10	between -5 and 10   (range)
# 
# Note that "and" is required between the lower limit and upper limit
# when specifying a range.  The upper limit must be greater than the lower 
# limit.  If RESOURCE_UP_VALUE is repeated within a RESOURCE_NAME block, then 
# they are inclusively OR'd together.  Package Resource Dependencies may be 
# defined by repeating the entire RESOURCE_NAME block.
# 
# Example : RESOURCE_NAME		/net/lan/lan0/res1
# 	    RESOURCE_POLLING_INTERVAL	120
# 	    RESOURCE_UP_VALUE		= RUNNING 
# 	    RESOURCE_UP_VALUE		= ONLINE 
# 
# 	    Means that the value of resource /net/lan/lan0/res1 will be
#	    checked every 120 seconds, and is considered to be 'up' when
#	    its value is "RUNNING" or "ONLINE".
# 
# Uncomment the following lines to specify Package Resource Dependencies.
#
#RESOURCE_NAME		    <Full_path_name>
#RESOURCE_POLLING_INTERVAL  <numeric_seconds>
#RESOURCE_UP_VALUE	    <op> <string_or_numeric> [and <op> <numeric>]
 
 
# The default for PKG_SWITCHING_ENABLED is YES. In the event of a
# failure, this permits the cluster software to transfer the package 
# to an adoptive node.  Adjust as necessary.
 
PKG_SWITCHING_ENABLED   YES
 
 
# The default for NET_SWITCHING_ENABLED is YES.  In the event of a
# failure, this permits the cluster software to switch LANs locally 
# (transfer to a standby LAN card).  Adjust as necessary.
 
NET_SWITCHING_ENABLED   YES
 
 
# The default for NODE_FAIL_FAST_ENABLED is NO.  If set to YES,
# in the event of a failure, the cluster software will halt the node 
# on which the package is running.  Adjust as necessary.
 
NODE_FAIL_FAST_ENABLED   NO

Use the information on the Package Configuration worksheet to complete the file. Refer also to the comments on the configuration template for additional explanation of each parameter. You may include the following information:

NODE_NAME. Enter the name of each node in the cluster on a separate line.
RUN_SCRIPT and HALT_SCRIPT. Specify the pathname of the package control script (described in the next section). No default is provided.
If your package contains services, enter the SERVICE_NAME, SERVICE_FAIL_FAST_ENABLED and SERVICE_HALT_TIMEOUT. values. Enter a group of these three for each service. You can configure no more than 30 services per package.
If your package has IP addresses associated wtih it, enter the SUBNET. This must be a subnet that is already specified in the cluster confiugration.
NODE_FAIL_FAST_ENABLED parameter. Enter YES or NO.

To configure monitoring within the package for a registered resource, enter values for the following parameters. Use the "Additional Package Resources" part of the "Package Configuration" subarea in SAM to obtain a list of resource names, polling intervals, and up values that you can set up as dependencies for your packages.

RESOURCE_NAME. Enter the name of a registered resource that is to be monitored by MC/LockManager.
RESOURCE_POLLING_INTERVAL. Enter the time between attempts to assure that the resource is healthy.
RESOURCE_UP_VALUE. Enter the value or values that determine when the resource is considered to be up. During monitoring, if a different value is found for the resource, the package will fail.

This package configuration data is later combined with the cluster configuration data in the binary cluster configuration file.

Creating Packages to Launch OPS Instances (OPS 8.0.5)

To coordinate the startup and shutdown of OPS instances with cluster node startup and shutdown, you create a one-node (non-failover) package for each node that runs an OPS instance. In the package configuration file, you should specify only the single node on which the instance will run and specify the control script that is to be executed every time the instance node or the entire OPS cluster starts up or shuts down.

Set the PACKAGE_SWITCHING_ENABLED parameter to NO to disallow package switching, since OPS instances do not fail over from node to node. NODE_FAILFAST_ENABLED should also be set to NO.

Configuring Packages that Access the OPS Database

You can also use packages to start up applications that access the OPS instances. If an application is intended to fail over among cluster nodes, then you must set it up as a distinct package, separate from the package that starts and stops the OPS instance. Use the following procedures for packages that contain applications which access the OPS database:

In the ASCII package configuration file, set the PKG_SWITCHING_ENABLED parameter to NO, or if you are using SAM to configure packages, set Automatic Switching to Disabled. This keeps the package from starting up immediately when the node joins the cluster.
You can then manually start the package using the cmmodpkg -e packagename command after OPS is started. Alternatively, you can choose to automate the process of package activation by writing your own script, and copying it to all nodes that can run the package. This script should contain the cmmodpkg -e command and activate the package after OPS and the cluster manager have started.