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 Serviceguard Manager or using HP-UX commands and editors. The following section describes Serviceguard Manager configuration. If you are using the Serviceguard command line, skip ahead to “Using Serviceguard Commands to Configure a Package ”.

Using Serviceguard Manager to Configure a Package

Serviceguard Manager configuration is available in Serviceguard Version A.11.16 and later when using Serviceguard Manager A.04.00 or later. To configure a high availability failover package use the following steps on the configuration node (ftsys9).

Connect to a session server node that has Serviceguard version A.11.16 or A.11.17 installed. Discover a cluster that has version A.11.16 or A.11.17. To begin configuration, you will be prompted to enter the root password for a node in the target cluster, unless your login already provided it.
To create a package, select the cluster on the map or tree. From the Actions menu, choose Configuration -> Create Package. To modify, select the package itself and choose Configuration -> Modify Package <pkgname>.
System multi-node packages and multi-node packages do not display on the map; their properties and menus are available only through the cluster icon. You cannot create or modify their configuration with Serviceguard Manager; you must use the command line.
Creating the Package Configuration and its Control Script, the interface will guide you through the steps. Online Help is available along the way. You can use the suggestions in “Configuring a Failover Package in Stages”, because many steps do not have to be done in sequence. The control script can be created automatically if you want.
“Verifying the Package Configuration”: Click the Check button. If you don’t see the log window, open one from the View menu.
“Distributing the Configuration”: Click Apply. The binary configuration file will be created, then it and the generated control script will be distributed to the package’s nodes.

If you want, you can configure your control script yourself. This may be necessary if you do not use a standard control script. However, once you edit a control script yourself, Serviceguard Manager will never be able to see or modify it again. If you choose to edit the control script, you must also distribute it yourself.

Using Serviceguard Commands to Configure a Package

There are three types of packages:

SYSTEM_MULTI_NODE packages: These special-purpose packages run simultaneously on every node in the cluster. The CFS system multi-node package is configured using the cfscluster command, not by editing configuration files.
MULTI_NODE packages: These special-purpose packages run simultaneously on more than one node in the cluster. The CFS multi-node packages are configured using the cfsdgadm and cfsmntadm commands, not by editing configuration files.
FAILOVER packages: These packages run on one node at a time. If there is a failure, Serviceguard (or a user) can halt them, and then start them up on another node from their configuration list. They are configured by entering specifications into their configuration files.

Configuring System Multi-node Packages

There are two system multi-node packages that regulate VERITAS CVM Cluster Volume Manager. These packages ship with the Serviceguard product. There are two versions of the package files: VxVM-CVM-pkg for CVM Version 3.5, and SG-CFS-pkg for CVM Version 4.1.

The SG-CFS-pkg for CVM Version 4.1 has the following responsibilities:

Maintain VERITAS configuration files /etc/llttab, /etc/llthosts, /etc/gabtab
Launch required services: cmvxd, cmvxpingd, vxfsckd
Start/halt VERITAS processes in the proper order: llt, gab, vxfen, odm, cvm, cfs




	CAUTION: Serviceguard manages VERITAS processes, specifically gab and LLT, through system multi-node packages. As a result, the VERITAS administration commands such as gabconfig, llthosts, and lltconfig should only be used in the display mode, such as gabconfig -a. You could crash nodes or the entire cluster if you use VERITAS commands such as the gab* or llt* commands to configure these components or affect their runtime behavior.

For CVM, use the cmapplyconf command to add the system multi-node packages to your cluster. If you are using the VERITAS Cluster File System, use the cfscluster command to activate and halt the system multi-node package in your cluster.




	NOTE: Do not create or modify these packages by editing an ASCII configuration file. Never edit their control script files.

The CFS admin commands are listed in Appendix A.

Configuring Multi-node Packages

There are two types of multi-node packages that work with the VERITAS cluster file system: SG-CFS-DG-id# for disk groups, which you configure with the cfsdgadm command, and SG-CFS-MP-id# for mount points, which you configure with the cfsmntadm command. Each package name will have a unique number, appended by Serviceguard at creation. Serviceguard automatically creates each package’s configuration file, its run and halt scripts, and its control script.

Serviceguard automatically applies the configuration when you enter cfsdgadm or cfsmntadm..




	CAUTION: Once you create the disk group and mount point packages, it is critical that you administer these packages with the cfs commands, including cfsdgadm, cfsmntadm, cfsmount, and cfsumount. These non-cfs commands could cause conflicts with subsequent command operations on the file system or Serviceguard packages. Use of these other forms of mount will not create an appropriate multi-node package which means that the cluster packages are not aware of the file system changes.

The package can be configured to run on a subset of the cluster nodes. It can be halted or started on a specific node or nodes.




	NOTE: Please note that the disk group and mount point multi-node packages do not monitor the health of the disk group and mount point. They check that the packages that depend on them have access to the disk groups and mount points. If the dependent application package loses access and cannot read and write to the disk, it will fail; however that will not cause the DG or MP multi-node package to fail.Do not create or edit ASCII configuration files for the Serviceguard supplied packages `VxVM-CVM-pkg`, `SG-CFS-pkg`, `SG-CFS-DG-id#`, or `SG-CFS-MP-id#.` Create `VxVM-CVM-pkg` and `SG-CFS-pkg` by issuing the cmapplyconf command. Create and modify `SG-CFS-DG-id#` and `SG-CFS-MP-id#` using the cfs* commands listed in Appendix A.

With a multi-node package, if you set AUTO_RUN to YES, then an instance can start on a new node joining the cluster. Otherwise, it will not.

Configuring Failover Packages

Use the following procedure to create failover 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 (with 31 bytes or less in the name), the location of the control script, and failover parameters for each package. Include the data recorded on the Package Configuration Worksheet.

Configuring a Failover Package in Stages

It is recommended you configure failover packages in stages, as follows:

Configure volume groups and mount points only.
Distribute the control script to all nodes.
Apply the configuration.
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. Edit this file for failover packages. It is strongly recommended that you never edit the package configuration file of a CVM/CFS multi-node or system multi-node package, although Serviceguard does not prohibit it.

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:

#**********************************************************************
# ****** 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 Serviceguard Extension for RAC 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			
 
# whether this package is to run as a FAILOVER, MULTI_NODE, 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.
#
#   MULTI_NODE   package runs on multiple nodes at the same time and
#                can be independently started and halted on
#                individual nodes. Failures of package components such
#                as services, EMS resources  or subnets, will cause
#                the package to be halted only on the node on which the
#                failure occurred. Relocatable IP addresses cannot be
#                assigned to MULTI_NODE packages.
#
#   SYSTEM_MULTI_NODE
#                package runs on all cluster 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 MULTI_NODE and 
#       SYSTEM_MULTI_NODE are not failover packages and are only
#       supported for use by applications provided by Hewlett-Packard.
#
#       Since MULTI_NODE and SYSTEM_MULTI_NODE packages can run on more
#       than one node at a time and do not failover in the event of a 
#       package failure, the following parameters cannot be
#       specified when configuring packages of these types:
#
#          FAILOVER_POLICY
#          FAILBACK_POLICY
#
#       Since an IP address can not be assigned to more than node at a
#       time, relocatable IP addresses can not be assigned in the
#       package control script for MULTI_NODE packages. If volume
#       groups are used in a MULTI_NODE package, they must be
#       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   MULTI_NODE
#            PACKAGE_TYPE   SYSTEM_MULTI_NODE
#
#
 
PACKAGE_TYPE			  FAILOVER
 
 
# Enter the failover policy for this package. This policy will be used 
# toselect 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 its primary node when it is running on an adoptive node. 
# 
# The alternative 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			  
 
 
# 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 automatically 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 run(ning) and halt(ing) of the 
# package. 
# 
# Enter the timeout, specified in seconds, for the run and halt 
# scripts. 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 values specified for all services. 
# 
# The file where the output of the scripts is logged can be specified 
# via the SCRIPT_LOG_FILE parameter. If not set, script output is sent 
# to a file named by appending '.log' to the script path. 
# 
#SCRIPT_LOG_FILE
 
RUN_SCRIPT			
RUN_SCRIPT_TIMEOUT	   	NO_TIMEOUT
HALT_SCRIPT			
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. 
# 
# Storage groups are only used with CVM disk groups. Neither 
# VxVM disk groups or LVM volume groups should be listed here. 
# By specifying a CVM disk group with the STORAGE_GROUP keyword 
# this package will not run until the CVM system multi node package is 
# running and thus the CVM shared disk groups are ready for 
# activation. 
# 
# NOTE: Should only be used by applications provided by
#       Hewlett-Packard.
#
# Example : STORAGE_GROUP  dg01
#           STORAGE_GROUP  dg02
#           STORAGE_GROUP  dg03
#           STORAGE_GROUP  dg04
#
#
# Enter the names of the dependency condition for this package. 
# Dependencies are used to describe the relationship between packages 
# To define a dependency, all three attributes are required. 
#
# DEPENDENCY_NAME must have a unique identifier for the dependency. 
#
# DEPENDENCY_CONDITION
#          This is an expression describing what must be true for
#          the dependency to be satisfied.
#
#          The syntax is: <package name> = UP , where <package name>
#          is the name of multi-node or system multi-node package.
#
# DEPENDENCY_LOCATION
#           This describes where the condition must be satisfied.
#           The only possible value for this attribute is SAME_NODE
#
# NOTE: 
# Dependencies should be used only for a CFS cluster, or by 
# applications specified by Hewlett-Packard. 
# These are  automatically set up in the SYSTEM-MULTI-NODE 
# and MULTI-NODE packages created for disk groups and mount points. 
# Customers configure dependencies for FAILOVER type 
# packages only; and the dependency would be on a MULTI+NODE mount
# point (MP) package. 
# 
# Example : 
#           DEPENDENCY_NAME         SG-CFS-MP-1 
#           DEPENDENCY_CONDITION    SG-CFS-MP-1=UP
#           DEPENDENCY_LOCATION     SAME_NODE
#
#DEPENDENCY_NAME
#DEPENDENCY_CONDITION
#DEPENDENCY_LOCATION SAME_NODE
#
# 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_NAME[] entries in 
# the package control script. 
# 
# 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 as a 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> 
 
 
# 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. 
# The subnet names could be IPv4 or IPv6. The network subnet names 
# that are to be monitored for this package could be a mix of IPv4 or IPv6 
# subnet names

#SUBNET

# 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>]
 
# Access Control Policy Parameters.
#
# Three entries set the access control policy for the package: 
# First line must be USER_NAME, second USER_HOST, and third USER_ROLE. 
# Enter a value after each. 
#
# 1. USER_NAME can either be ANY_USER, or a maximum of 
#    8 login names from the /etc/passwd file on user host.
# 2. USER_HOST is where the user can issue Serviceguard commands. 
#    If using Serviceguard Manager, it is the COM server.
#    Choose one of these three values: ANY_SERVICEGUARD_NODE, or 
#    (any) CLUSTER_MEMBER_NODE, or a specific node. For node, 
#    use the official hostname from domain name server, and not 
#    an IP addresses or fully qualified name.
# 3. USER_ROLE must be PACKAGE_ADMIN. This role grants permission
#    to MONITOR, plus for administrative commands for the package.
#
# These policies do not effect root users. Access Policies here 
# should not conflict with policies defined in the cluster configuration file. 
# 
# Example: to configure a role for user john from node noir to 
# administer the package, enter:
# USER_NAME  john 
# USER_HOST  noir 
# USER_ROLE  PACKAGE_ADMIN

PACKAGE_TYPE. The traditional Serviceguard package is the FAILOVER package. It runs on one node at a time. If there is a failure on the node where the package is running, Serviceguard can fail the work over to another node.

MULTI_NODE packages can run on several nodes at the same time. SYSTEM_MULTI_NODE run on all the nodes in the cluster at the same time. Both multi-node and system multi-node packages are only supported for applications specified by HP. For example, Serviceguard A.11.17 supplies one system multi-node package and two multi-node packages to be used in VERITAS Cluster File System configurations.




	NOTE: Do not create or edit ASCII configuration files for the Serviceguard supplied packages `VxVM-CVM-pkg`, `SG-CFS-pkg`, `SG-CFS-DG-id#`, or `SG-CFS-MP-id#` Create `VxVM-CVM-pkg` and `SG-CFS-pkg` by issuing the cmapplyconf command. Create and modify `SG-CFS-DG-id#` and `SG-CFS-MP-id#` using the cfs commands listed in Appendix A.

FAILOVER_POLICY. Enter CONFIGURED_NODE if you want Serviceguard to attempt to start (or restart) the package in the order nodes are listed. Enter MIN_PACKAGE_NODE if you want Serviceguard to restart a failed package on whichever node has the least packages running at the time. (Failover type packages only.)
FAILBACK_POLICY. If a package’s primary node fails, enter AUTOMATIC if you want Serviceguard to automatically fail the package back to the primary node as soon as the primary node is running again. Enter MANUAL if you do not want Serviceguard to move the package back. (Failover packages only.)
NODE_NAME. Enter the name of each node in the cluster on a separate line. For all cluster nodes, use the “*” wildcard. (For system multi-node packages, you must specify NODE_NAME *.)
AUTO_RUN. For failover packages, enter YES to allow Serviceguard to start the package on the first available node, and to automatically restart it later if it fails. Enter NO to keep Serviceguard from automatically starting the package. (For system multi-node packages, you must enter YES.)
LOCAL_LAN_FAILOVER_ALLOWED. Enter YES to permit switching of the package IP address to a standby LAN, or NO to keep the package address from switching locally. (Must be NO for multi-node and system multi-node packages.)
NODE_FAIL_FAST_ENABLED. If you enter YES, a node will be halted with a TOC any time a package fails on that node. This prevents Serviceguard from repeatedly trying (and failing) to start a package on that node. For system multi-node packages, this must be set to YES.
RUN_SCRIPT and HALT_SCRIPT. Specify the pathname of the package control script (described in the next section). No default is provided.
TIMEOUT: For the run and halt scripts, enter the number of seconds Serviceguard should try to complete the script before it acknowledges failure. If you have timeouts for the halt script, this value must be larger than all the halt script timeouts added together.
SCRIPT_LOG_FILE. (optional). You can specify a place for the run and halt script to place log messages. If you do not specify a path, Serviceguard will create a file with “.log” appended to each script path, and put the messages in that file.
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 has IP addresses associated with it, enter the SUBNET. This must be a subnet that is already specified in the cluster configuration, and it can be either an IPv4 or an IPv6 subnet. Link-local package IPs are not allowed, hence link-local subnets must not be entered in the package ASCII 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.

To configure monitoring within the package for a registered resource, enter values for the following parameters.

RESOURCE_NAME. Enter the name of a registered resource that is to be monitored by 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          = UP
 
RESOURCE_NAME              /net/interfaces/lan/status/lan1
RESOURCE_POLLING_INTERVAL  60
RESOURCE_START             DEFERRED
RESOURCE_UP_VALUE          = UP
 
RESOURCE_NAME              /net/interfaces/lan/status/lan2
RESOURCE_POLLING_INTERVAL  60
RESOURCE_START             AUTOMATIC
RESOURCE_UP_VALUE          = UP

ACCESS_CONTROL_POLICY begins with Serviceguard version A.11.16. With it, you can allow non-root users to monitor the cluster and to administer packages. Configuration still requires root.
The only role in the package configuration file is that of PACKAGE_ADMIN over the one configured package. Cluster-wide roles are defined in the cluster configuration file.
There must be no conflict in roles. If there is, configuration will fail and you will get a message. It is a good idea, therefore, to look at the cluster configuration file (use the cmgetconf command) before creating any roles in the package’s file.
If a role is configured in the cluster, do not specify a role for the same username/hostnode in the package configuration.
Data about Access Control Policies in the package configuration files and the cluster configuration file are later combined in the binary cluster configuration file.
See “Access Roles” for more information.
Simple package dependencies are a new feature in Serviceguard A.11.17. At the release of Serviceguard A.11.17, dependencies are only supported for use by applications specified by Hewlett-Packard, such as the ones for clusters with the VERITAS Cluster File System. This ensures that the failover application package will not start on a node unless the CFS packages are already running on that node.
For example, if you have CFS installed, you can add a dependency to your failover package configuration. There are three attributes; specify them in this order:
- DEPENDENCY_NAME. Enter a unique name for your dependency.
- DEPENDENCY_CONDITION. The only condition supported in this release is pkg_name=UP. For a failover package that uses CFS this is: SG-CFS-pkg = UP
- DEPENDENCY_LOCATION. For Serviceguard A.11.17, the only location supported is SAME_NODE.

Adding or Removing Packages on a Running Cluster

You can add or remove packages while the cluster is running, subject to the value of MAX_CONFIGURED_PACKAGES in the cluster configuration file. To add or remove packages online, refer to Chapter 7 “Cluster and Package Maintenance”.