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 ServiceGuard commands, skip ahead to the section "“Using ServiceGuard 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 ServiceGuard 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 "“Writing the Package Control Script”."

Using ServiceGuard 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/pkg1.config
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 package and ensure that it can be moved from node to node.
Halt the package.
Configure package IP addresses and application services in the control script.
Distribute the control script to all nodes.
Run the package and ensure that applications run as expected and that the package fails 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/ServiceGuard or ServiceGuard OPS Edition 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 package type for this package. PACKAGE_TYPE indicates
# whether this package is to run as a FAILOVER or SYSTEM_MULTI_NODE
# package.
#
#    FAILOVER     package runs on one node at a time and if a failure
#                 occurs it can switch to an alternate node.
#
#    SYSTEM_MULTI_NODE
#                 package runs on multiple nodes at the same time.
#                 It can not be started and halted on individual nodes.
#                 Both NODE_FAIL_FAST_ENABLED and AUTO_RUN must be set
#                 to YES for this type of package. All SERVICES must
#                 have SERVICE_FAIL_FAST_ENABLED set to YES.
#
# NOTE: Packages which have a PACKAGE_TYPE of SYSTEM_MULTI_NODE are
#       not failover packages and should only be used for applications
#       provided by Hewlett-Packard. 
#
#       Since SYSTEM_MULTI_NODE packages run on multiple nodes at
#       one time, following paramters are ignored:
#
#          FAILOVER_POLICY
#          FAILBACK_POLICY
#
#       Since an IP address cannot be assigned to more than one node at a
#       time, relocatable IP addresses cannot be assigned in the
#       package control script for multiple node packages. If
#       volume groups are assigned to multiple node packages they must
#       activated in a shared mode and data integrity is left to the
#       application. Shared access requires a shared volume manager.
#
#
# Examples : PACKAGE_TYPE   FAILOVER (default)
#            PACKAGE_TYPE   SYSTEM_MULTI_NODE
#
 
PACKAGE_TYPE                    FAILOVER
 
 
# 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 this package needs
# to start.
 
FAILOVER_POLICY        CONFIGURED_NODE
 
# Enter the failback policy for this package. This policy will be used
# to determine what action to take when a package is not running on
# its primary node and its primary node is capable of running the 
# package. The default policy unless otherwise specified is MANUAL.
# The MANUAL policy means no attempt will be made to move the package 
# back to it primary node when it is running on an adoptive node. 
# 
# The alternate policy is AUTOMATIC. This policy will attempt to
# move the package 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.
#
# NOTE:   The order is relevant.
#         Put the second Adoptive Node after the first one.
# 
# Example : NODE_NAME  original_node  
#           NODE_NAME  adoptive_node  
#
# If all nodes in the cluster are to be specified and order is not
# important, "NODE_NAME *" may be specified.
#
# Example : NODE_NAME  *
 
 
NODE_NAME                       ftsys9
NODE_NAME                       ftsys10
 
 
# Enter the value for AUTO_RUN. Possible values are YES and NO.
# The default for AUTO_RUN is YES. When the cluster is started the
# package will be automaticaly started. In the event of a failure the
# package will be started on an adoptive node. Adjust as necessary.
#
# AUTO_RUN replaces obsolete PKG_SWITCHING_ENABLED.
 
AUTO_RUN                        YES
 
 
# Enter the value for LOCAL_LAN_FAILOVER_ALLOWED.
# Possible values are YES and NO.
# The default for LOCAL_LAN_FAILOVER_ALLOWED 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.
#
# LOCAL_LAN_FAILOVER_ALLOWED replaces obsolete NET_SWITCHING_ENABLED.
 
LOCAL_LAN_FAILOVER_ALLOWED      YES
 
 
 
# Enter the value for NODE_FAIL_FAST_ENABLED.
# Possible values are YES and NO
# 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. All SYSTEM_MULTI_NODE packages must have
# NODE_FAIL_FAST_ENABLED set to YES.  Adjust as necessary.
 
NODE_FAIL_FAST_ENABLED          NO
 
# 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 running and halting 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 names of the storage groups configured for this package.
# Repeat this line as necessary for additional storage groups.
 
# NOTE: Should only be used by applications provided by
# Hewlett-Packard.
#
# Example : STORAGE_GROUP  vg01
#           STORAGE_GROUP  vg02
#           STORAGE_GROUP  dg03
#           STORAGE_GROUP  dg04
#
 
# 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                   <service name>
#SERVICE_FAIL_FAST_ENABLED      <YES/NO>
#SERVICE_HALT_TIMEOUT           <number of seconds
 
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 keywords RESOURCE_NAME, RESOURCE_POLLING_INTERVAL,
# RESOURCE_START, 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.  The
# RESOURCE_POLLING_INTERVAL and the RESOURCE_START are optional.
#
# The RESOURCE_POLLING_INTERVAL indicates how often, in seconds, the
# resource is to be monitored.  It will be defaulted to 60 seconds if
# RESOURCE_POLLING_INTERVAL is not specified.
#
# The RESOURCE_START option can be set to either AUTOMATIC or DEFERRED.
# The default setting for RESOURCE_START is AUTOMATIC.  If AUTOMATIC
# is specified, ServiceGuard will start up resource monitoring for
# these AUTOMATIC resources automatically when the node starts up.
# If DEFERRED is selected, ServiceGuard will not attempt to start
# resource monitoring for these resources during node start up.  User
# should specify all the DEFERRED resources in the package run script
# so that these DEFERRED resources will be started up from the package
# run script during package run time.
#
# RESOURCE_UP_VALUE requires an operator and a value.  This defines
# the resource 'UP' condition.  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/interfaces/lan/status/lan0
#           RESOURCE_POLLING_INTERVAL   120
#           RESOURCE_START              AUTOMATIC
#           RESOURCE_UP_VALUE           = RUNNING
#           RESOURCE_UP_VALUE           = ONLINE
#
#           Means that the value of resource /net/interfaces/lan/status/lan0
#           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_START             <AUTOMATIC/DEFERRED>
#RESOURCE_UP_VALUE          <op> <string_or_numeric> [and <op> <numeric>]

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:

FAILOVER_POLICY. Enter either CONFIGURED_NODE or MIN_PACKAGE_NODE.
FAILBACK_POLICY. Enter either MANUAL or AUTOMATIC.
NODE_NAME. Enter the name of each node in the cluster on a separate line.
AUTO_RUN. Enter YES to allow the package to start on the first available node, or NO to keep the package from automatic startup.
LOCAL_LAN_FAILOVER_ALLOWED. Enter YES to permit switching of the package IP address to a standby LAN, or NO to keep the package from switching locally.
RUN_SCRIPT and HALT_SCRIPT. Specify the pathname of the package control script (described in the next section). No default is provided.
STORAGE_GROUP. Specify the names of any CVM storage groups that will be used by this package. Enter each storage group (CVM disk group) on a separate line. Note that CVM storage groups are not entered in the cluster ASCII configuration file.
NOTE: You should not enter LVM volume groups or VxVM disk groups in this file.
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 configuration.
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/ServiceGuard.
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.

RESOURCE_START. The RESOURCE_START option is used to determine when ServiceGuard should start up resource monitoring for EMS resources. The RESOURCE_START option can be set to either AUTOMATIC or DEFERRED. If AUTOMATIC is specified, ServiceGuard will start up resource monitoring for these resources automatically when the ServiceGuard cluster daemon starts up on the node. If resources are configured AUTOMATIC, you do not need to define DEFERRED_RESOURCE_NAME in the package control script.

If DEFERRED is selected, ServiceGuard does not attempt to start resource monitoring for these DEFERRED resources during node start up. However, these DEFERRED resources must be specified in the package control script.

The following is an example of how to configure DEFERRED and AUTOMATIC resources. In the package configuration file, specify resources as follows:

RESOURCE_NAME              /net/interfaces/lan/status/lan0
RESOURCE_POLLING_INTERVAL  60
RESOURCE_START             DEFERRED
RESOURCE_UP_VALUE          = ONLINE
 
RESOURCE_NAME              /net/interfaces/lan/status/lan1
RESOURCE_POLLING_INTERVAL  60
RESOURCE_START             DEFERRED
RESOURCE_UP_VALUE          = ONLINE
 
RESOURCE_NAME              /net/interfaces/lan/status/lan2
RESOURCE_POLLING_INTERVAL  60
RESOURCE_START             AUTOMATIC
RESOURCE_UP_VALUE          = ONLINE

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

Creating Packages to Launch OPS Instances

To coordinate the startup and shutdown of OPS instances with cluster node startup and shutdown, you create a one-node 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.




	NOTE: You must create the OPS instance package with a `PACKAGE_TYPE` of `FAILOVER`, but the fact that you are entering only one node ensures that the instance will only run on that node.

To simplify the creation of OPS instance packages, you can use the Oracle template provided with the separately purchasable ECM Toolkits product (B5139BA). This file is found in /opt/cmcluster/tookit/DB/Oracle. Use the special oracle.sh script that is provided, and follow the instructions that appear in the README file. Also refer to the section "Customizing the Control Script for OPS Instances," below.

Set the AUTO_RUN parameter to YES, if you want the instance to start up as soon as the node joins the cluster. In addition, you should set the NODE_FAILFAST_ENABLED parameter to NO.

If you are using CVM disk groups for the OPS database, be sure to include the name of each disk group on a separate STORAGE_GROUP line in the configuration file.

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 AUTO_RUN 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, and before OPS is running.
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.

Adding or Removing Packages on a Running Cluster

You can add or remove packages while the cluster is running, subject to the limit of MAX_CONFIGURED_PACKAGES. To add or remove packages online, refer to the chapter on "Cluster and Package Maintenance."