Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
Managing Serviceguard Fifteenth Edition > Chapter 6 Configuring Packages and Their Services

Choosing Package Modules

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Index

IMPORTANT: Before you start, you need to do the package-planning tasks described under “Package Configuration Planning ”.

To choose the right package modules, you need to decide the following things about the package you are creating:

When you have made these decisions, you are ready to generate the package configuration file; see “Generating the Package Configuration File”.

Types of Package: Failover, Multi-Node, System Multi-Node

There are three types of packages:

  • Failover packages. This is the most common type of package. Failover 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 selected from the package’s configuration list; see node_name.

    To generate a package configuration file that creates a failover package, include -m sg/failover on the cmmakepkg command line. See “Generating the Package Configuration File”.

  • Multi-node packages. These packages run simultaneously on more than one node in the cluster. Failures of package components such as applications, 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.

    Examples are the Veritas Cluster File System (CFS) system multi-node packages; but support for multi-node packages is no longer restricted to CVM/CFS; you can create a multi-node package for any purpose.

    IMPORTANT: But if the package uses volume groups, they must be activated in shared mode: vgchange -a s, which is available only if the SGeRAC add-on product is installed.
    NOTE: On systems that support CFS, you configure the CFS multi-node packages by means of the cfsdgadm and cfsmntadm commands, not by editing a package configuration file. See “Configuring Veritas Multi-node Packages”.

    To generate a package configuration file that creates a multi-node package, include -m sg/multi_node on the cmmakepkg command line. See “Generating the Package Configuration File”.

  • System multi-node packages. These packages run simultaneously on every node in the cluster. They cannot 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.

    System multi-node packages are supported only for applications supplied by HP, for example Veritas Cluster File System (CFS).

    NOTE: On systems that support CFS, you configure the CFS system multi-node package by means of the cfscluster command, not by editing a package configuration file. See “Configuring Veritas System Multi-node Packages”.
NOTE: The following parameters cannot be configured for multi-node or system multi-node packages:
  • failover_policy

  • failback_policy

  • ip_subnet

  • ip_address

Volume groups configured for packages of these types must be activated in shared mode.

For more information about types of packages and how they work, see “How the Package Manager Works”. For information on planning a package, see “Package Configuration Planning ”.

When you have decided on the type of package you want to create, the next step is to decide what additional package-configuration modules you need to include; see “Package Modules and Parameters”.

Package Modules and Parameters

The table that follows shows the package modules and the configuration parameters each module includes. Read this section in conjunction with the discussion under “Package Configuration Planning ”.

Use this information, and the parameter explanations that follow (“Package Parameter Explanations”), to decide which modules (if any) you need to add to the failover or multi-node module to create your package. If you are used to creating legacy packages, you will notice that parameters from the package control script (or their equivalents) are now in the package configuration file; these parameters are marked (S) in the table.

NOTE: If you are going to create a complex package that contains many modules, you may want to skip the process of selecting modules, and simply create a configuration file that contains all the modules:

cmmakepkg -m sg/all $SGCONF/sg-all

(The output will be written to $SGCONF/sg-all.)

Base Package Modules

At least one base module (or default or all, which include the base module) must be specified on the cmmakepkg command line. Parameters marked with an asterisk (*) are new or changed as of Serviceguard A.11.18. (S) indicates that the parameter (or its equivalent) has moved from the package control script to the package configuration file for modular packages. See the “Package Parameter Explanations” for more information.

 

Optional Package Modules

Add optional modules to a base module if you need to configure the functions in question. Parameters marked with an asterisk (*) are new or changed as of Serviceguard A.11.18. (S) indicates that the parameter (or its equivalent) has moved from the package control script to the package configuration file for modular packages. See the “Package Parameter Explanations” for more information.

Table 6-2 Optional Modules

Module NameParameters (page)Comments
dependency
dependency_name *
dependency_condition
dependency_location
Add to a base module to create a package that depends on one or more other packages.
monitor_subnet
local_lan_failover_allowed
monitored_subnet *
monitored_subnet_access *
cluster_interconnect_subnet *
Add to a base module to configure subnet monitoring for the package.
package_ip
ip_subnet * (S)
ip_subnet_node *
ip_address * (S)
Add to failover module to assign relocatable IP addresses to a failover package.
service
service_name * (S)
service_cmd (S)
service_restart * (S)
service_fail_fast_enabled
service_halt_timeout
Add to a base module to create a package that runs an application or service.
resource
resource_name *
resource_polling_interval
resource_start
resource_up_value
Add to a base module to create a package that monitors critical resources via the Event Monitoring Service (EMS).
volume_group
concurrent_vgchange_operations (S)
enable_threaded_vgchange *
vgchange_cmd * (S)
cvm_activation_cmd (S)
vxvol_cmd * (S)
vg (S)
cvm_dg (S)
vxvm_dg (S)
deactivation_retry_count (S)
kill_processes_accessing_raw_devices (S)
Add to a base module if the package needs to mount file systems on LVM or VxVM volumes, or uses CVM volumes but not CFS.
filesystem
concurrent_fsck_operations (S)
concurrent_mount_and_umount_operations (S)
fs_mount_retry_count (S)
fs_umount_retry_count * (S)
fs_name * (S)
fs_directory * (S)
fs_type (S)
fs_mount_opt (S)
fs_umount_opt (S)
fs_fsck_opt (S)
Add to a base module to configure filesystem options for the package.
pev
pev_ *
Add to a base module to configure environment variables to be passed to an external script.
external_pre
external_pre_script *
Add to a base module to specify additional programs to be run before volume groups and disk groups are activated while the package is starting and after they are deactivated while the package is halting.
external
external_script *
Add to a base module to specify additional programs to be run during package start and stopped at package halt time.
acp
user_name
user_host
user_role
Add to a base module to configure Access Control Policies for the package.
allall parametersUse if you are creating a complex package that requires most or all of the optional parameters; or if you want to see the specifications and comments for all available parameters.

default

(all parameters)

A symbolic link to the all module; used if a base module is not specified on the cmmakepkg command line; see “cmmakepkg Examples”.

 

NOTE: The default form for parameter names in the modular package configuration file is lower case; for legacy packages the default is upper case. There are no compatibility issues; Serviceguard is case-insensitive as far as the parameter names are concerned. This manual uses lower case, unless the parameter in question is used only in legacy packages, or the context refers exclusively to such a package.

Package Parameter Explanations

Brief descriptions of the package configuration parameters follow.

NOTE: For more information, see the comments in the editable configuration file output by the cmmakepkg command, and the cmmakepkg manpage.

If you are going to browse these explanations deciding which parameters you need, you may want to generate and print out a configuration file that has the comments for all of the parameters; you can create such a file as follows:

cmmakepkg -m sg/all $SGCONF/sg-all

or simply

cmmakepkg $SGCONF/sg-all

This creates a file /etc/cmcluster/sg-all that contains all the parameters and comments.

More detailed instructions for running cmmakepkg are in the next section, “Generating the Package Configuration File”. See also “Package Configuration Planning ”.

package_name

Any name, up to a maximum of 39 characters, that:

  • starts and ends with an alphanumeric character

  • otherwise contains only alphanumeric characters or dot (.), dash (-), or underscore (_)

  • is unique among package names in this cluster

    IMPORTANT: Restrictions on package names in previous Serviceguard releases were less stringent. Packages whose names do not conform to the above rules will continue to run, but if you reconfigure them, you will need to change the name; cmcheckconf and cmapplyconf will enforce the new rules.
module_name

The module name (for example, failover, service, etc.) Do not change it. Used in the form of a relative path (for example sg/failover) as a parameter to cmmakepkg to specify modules to be used in configuring the package. (The files reside in the $SGCONF/modules directory; see “Learning Where Serviceguard Files Are Kept” for an explanation of Serviceguard directories.)

New for modular packages.

module_version

The module version. Do not change it.

New for modular packages.

package_type

The type can be failover, multi_node, or system_multi_node. Default is failover. You can configure only failover or multi-node packages; see “Types of Package: Failover, Multi-Node, System Multi-Node”.

node_name

The node on which this package can run, or a list of nodes in order of priority, or an asterisk (*) to indicate all nodes. The default is *.

For system multi-node packages, you must specify *.

If you use a list, specify each node on a new line, preceded by the literal node_name, for example:

node_name <node1>node_name <node2>node_name <node3>

The order in which you specify the node names is important. First list the primary node name (the node where you normally want the package to start), then the first adoptive node name (the best candidate for failover), then the second adoptive node name, followed by additional node names in order of preference.

In case of a failover, control of the package will be transferred to the next adoptive node name listed in the package configuration file, or (if that node is not available or cannot run the package at that time) to the next node in the list, and so on.

IMPORTANT: See “Cluster Configuration Parameters ” for important information about node names.

See “About Cross-Subnet Failover” for considerations when configuring cross-subnet packages, which are further explained under “Cross-Subnet Configurations”.

auto_run

Can be set to yes or no. The default is yes.

For failover packages, yes allows Serviceguard to start the package (on the first available node listed under node_name) on cluster start-up, and to automatically restart it on an adoptive node if it fails. no prevents Serviceguard from automatically starting the package, and from restarting it on another node.

This is also referred to as package switching, and can be enabled or disabled while the package is running, by means of the cmmodpkg (1m) command.

auto_run should be set to yes if the package depends on another package, or is depended on; see “About Package Dependencies”.

For system multi-node packages, auto_run must be set to yes. In the case of a multi-node package, setting auto_run to yes allows an instance to start on a new node joining the cluster; no means it will not.

node_fail_fast_enabled

Can be set to yes or no. The default is no.

yes means the node on which the package is running will be halted (HP-UX system reset) if the package fails; no means Serviceguard will not halt the system.

If this parameter is set to yes and one of the following events occurs, Serviceguard will halt the system (HP-UX system reset) on the node where the control script fails:

  • A package subnet fails and no backup network is available

  • An EMS resource fails

  • Serviceguard is unable to execute the halt function

  • The start or halt function times out

NOTE: If the package halt function fails with “exit 1”, Serviceguard does not halt the node, but sets no_restart for the package, which disables package switching (auto_run), thereby preventing the package from starting on any adoptive node.

Setting node_fail_fast_enabled to yes prevents Serviceguard from repeatedly trying (and failing) to start the package on the same node.

For system multi-node packages, node_fail_fast_enabled must be set to yes.

run_script_timeout

The amount of time, in seconds, allowed for the package to start; or no_timeout. The default is no_timeout. The maximum is 4294.

If the package does not complete its startup in the time specified by run_script_timeout, Serviceguard will terminate it and prevent it from switching to another node. In this case, if node_fail_fast_enabled is set to yes, the node will be halted (HP-UX system reset).

If no timeout is specified (no_timeout), Serviceguard will wait indefinitely for the package to start.

If a timeout occurs:

  • Switching will be disabled.

  • The current node will be disabled from running the package.

    NOTE: VxVM disk groups are imported at package run time and exported at package halt time. If a package uses a large number of VxVM disk, the timeout value must be large enough to allow all of them to finish the import or export.
halt_script_timeout

The amount of time, in seconds, allowed for the package to halt; or no_timeout. The default is no_timeout. The maximum is 4294.

If the package’s halt process does not complete in the time specified by halt_script_timeout, Serviceguard will terminate the package and prevent it from switching to another node. In this case, if node_fail_fast_enabled is set to yes, the node will be halted (HP-UX system reset).

If a halt_script_timeout is specified, it should be greater than the sum of all the values set for service_halt_timeout for this package.

If a timeout occurs:

  • Switching will be disabled.

  • The current node will be disabled from running the package.

If a halt-script timeout occurs, you may need to perform manual cleanup. See “Package Control Script Hangs or Failures” in Chapter 8. See also the note about VxVM under run_script_timeout.

successor_halt_timeout

Specifies how long, in seconds, Serviceguard will wait for packages that depend on this package to halt, before halting this package. Can be 0 through 4294, or no_timeout. The default is no_timeout.

  • no_timeout means that Serviceguard will wait indefinitely for the dependent packages to halt.

  • 0 means Serviceguard will not wait for the dependent packages to halt before halting this package.

New as of A.11.18 (for both modular and legacy packages). See also “About Package Dependencies”.

script_log_file

The full pathname of the package’s log file. The default is $SGRUN/log/<package_name>.log. (See “Learning Where Serviceguard Files Are Kept” for more information about Serviceguard pathnames.) See also log_level.

operation_sequence

Defines the order in which the scripts defined by the package’s component modules will start up. See the package configuration file for details.

This parameter is not configurable; do not change the entries in the configuration file.

New for modular packages.

log_level

Determines the amount of information printed to stdout when the package is validated, and to the script_log_file when the package is started and halted. Valid values are 0 through 5:

  • 0 - informative messages

  • 1 - informative messages with slightly more detail

  • 2 - messages showing logic flow

  • 3 - messages showing detailed data structure information

  • 4 - detailed debugging information

  • 5 - function call flow

New for modular packages.

failover_policy

Specifies how Serviceguard decides where to restart the package if it fails. Can be set to configured_node or min_package_node. The default is configured_node.

  • configured_node means Serviceguard will attempt to restart the package on the next available node in the list you provide under node_name.

  • min_package_node means Serviceguard will restart a failed package on whichever node in the node_name list has the fewest packages running at the time.

This parameter can be set for failover packages only. For a package that will depend on another package or vice versa, see also “About Package Dependencies”.

failback_policy

Specifies what action the package manager should take when a failover package is not running on its primary node (the first node on its node_name list) and the primary node is once again available. Can be set to automatic or manual. The default is manual.

  • manual means the package will continue to run on the current (adoptive) node.

  • automatic means Serviceguard will move the package to the primary node as soon as that node becomes available, unless doing so would also force a package with a higher priority to move.

This parameter can be set for failover packages only. If this package will depend on another package or vice versa, see also “About Package Dependencies”.

priority

Assigns a priority to a failover package whose failover_policy is configured_node. Valid values are 1 through 3000, or no_priority. The default is no_priority. See also the dependency_ parameter descriptions, starting on dependency_name.

priority can be used to satisfy dependencies when a package starts, or needs to fail over or fail back: a package with a higher priority than the packages it depends on can drag those packages, forcing them to start or restart on the node it chooses, so that its dependencies are met.

If you assign a priority, it must be unique in this cluster. HP recommends assigning values in increments of 20 so as to leave gaps in the sequence; otherwise you may have to shuffle all the existing priorities when assigning priority to a new package.

IMPORTANT: Because priority is a matter of ranking, a lower number indicates a higher priority (20 is a higher priority than 40). A numerical priority is higher than no_priority.

New A.11.18 (for both modular and legacy packages). See “About Package Dependencies” for more information.

dependency_name

A unique identifier for a particular dependency that must be met in order for this package to run (or keep running). The length and formal restrictions for the name are the same as for package_name.

IMPORTANT: Restrictions on dependency names in previous Serviceguard releases were less stringent. Packages that specify dependency_names that do not conform to the above rules will continue to run, but if you reconfigure them, you will need to change the dependency_name; cmcheckconf and cmapplyconf will enforce the new rules.

Configure this parameter, along with dependency_condition and dependency_location, if this package depends on another package; for example, if this package depends on a package named pkg2:

dependency_name pkg2dep dependency_condition pkg2 = UP dependency_location same_node

For more information about package dependencies, see “About Package Dependencies”.

dependency_condition

The condition that must be met for this dependency to be satisfied. As of Serviceguard A.11.18, the only condition that can be set is that another package must be running.

The syntax is: <package_name> = UP, where <package_name> is the name of the package depended on. The type and characteristics of the current package (the one we are configuring) impose the following restrictions on the type of package it can depend on:

  • If the current package is a multi-node package, <package_name> must identify a multi-node or system multi-node package.

  • If the current package is a failover package and min_package_node is its failover_policy, < package_name> must identify a multi-node or system multi-node package.

  • If the current package is a failover package and configured_node is its failover_policy, <package_name> must identify a multi-node or system multi-node package, or a failover package whose failover_policy is configured_node.

See also “About Package Dependencies”.

dependency_location

Specifies where the dependency_condition must be met. The only legal value is same_node.

local_lan_failover_allowed

Specifies whether or not Serviceguard can transfer the package IP address to a standby LAN card in the event of a LAN card failure on a cluster node.

Legal values are yes and no. Default is yes.

monitored_subnet

A LAN subnet that is to be monitored for this package. Replaces legacy SUBNET which is still supported in the package configuration file for legacy packages; see “Configuring a Legacy Package”.

You can specify multiple subnets; use a separate line for each.

If you specify a subnet as a monitored_subnet the package will not run on any node not reachable via that subnet. This normally means that if the subnet is not up, the package will not run. (For cross-subnet configurations, in which a subnet may be configured on some nodes and not on others, see monitored_subnet_access below, ip_subnet_node, and “About Cross-Subnet Failover”.)

Typically you would monitor the ip_subnet, specifying it here as well as in the ip_subnet parameter (see below), but you may want to monitor other subnets as well; you can monitor any subnet that is configured into the cluster (via the STATIONARY_IP or HEARTBEAT_IP parameter in the cluster configuration file).

If any monitored_subnet fails, Serviceguard will switch the package to any other node specified by node_name which can communicate on the monitored_subnets defined for this package. See the comments in the configuration file for more information and examples.

monitored_subnet_access

In cross-subnet configurations, specifies whether each monitored_subnet is accessible on all nodes in the package’s node list (see node_name), or only some. Valid values are PARTIAL, meaning that at least one of the nodes has access to the subnet, but not all; and FULL, meaning that all nodes have access to the subnet. The default is FULL, and it is in effect if monitored_subnet_access is not specified.

See also ip_subnet_node and “About Cross-Subnet Failover”.

New for modular packages. For legacy packages, see “Configuring Cross-Subnet Failover”.

cluster_interconnect_subnet

Specifies an IPv4 address. Can be configured only for a multi-node package in a Serviceguard Extension for Real Application Cluster (SGeRAC) installation.

(See the latest version of Using Serviceguard Extension for RAC at http://www.docs.hp.com -> High Availability - > Serviceguard Extension for Real Application Cluster (ServiceGuard OPS Edition) for more information.)

New for A.11.18 (for both modular and legacy packages).

ip_subnet

Specifies an IP subnet used by the package. Replaces SUBNET, which is still supported in the package control script for legacy packages.

For each subnet used, specify the subnet address on one line and, on the following lines, the relocatable IP addresses that the package uses on that subnet. These will be configured when the package starts and unconfigured when it halts. If you want the subnet to be monitored, specify it in the monitored_subnet parameter as well.

For example, if this package uses subnet 192.10.25.0 and the relocatable IP addresses 192.10.25.12 and 192.10.25.13, enter:

ip_subnet 192.10.25.0

ip_address 192.10.25.12

ip_address 192.10.25.13

If you want the subnet to be monitored, specify it in the monitored_subnet parameter as well.

In a cross-subnet configuration, you also need to specify which nodes the subnet is configured on; see ip_subnet_node below. See also monitored_subnet_access and “About Cross-Subnet Failover”.

This parameter can be set for failover packages only.

ip_subnet_node

In a cross-subnet configuration, specifies which nodes an ip_subnet is configured on. If no nodes are listed under an ip_subnet, it is assumed to be configured on all nodes in this package’s node_name list (see node_name).

Can be added or deleted while the package is running, with these restrictions:

  • The package must not be running on the node that is being added or deleted.

  • The node must not be the first to be added to, or the last deleted from, the list of ip_subnet_nodes for this ip_subnet.

See also monitored_subnet_access and “About Cross-Subnet Failover”.

New for modular packages. For legacy packages, see “Configuring Cross-Subnet Failover”.

ip_address

A relocatable IP address on a specified ip_subnet. Replaces IP, which is still supported in the package control script for legacy packages; see “Configuring a Legacy Package”.

For more information about relocatable IP addresses, see “Stationary and Relocatable IP Addresses ”.

This parameter can be set for failover packages only.

service_name

A service is a program or function which Serviceguard monitors as long as the package is up. service_name identifies this function and is used by the cmrunserv and cmhaltserv commands. You can configure a maximum of 30 services per package and 900 services per cluster.

The length and formal restrictions for the name are the same as for package_name. service_name must be unique among all packages in the cluster.

IMPORTANT: Restrictions on service names in previous Serviceguard releases were less stringent. Packages that specify services whose names do not conform to the above rules will continue to run, but if you reconfigure them, you will need to change the name; cmcheckconf and cmapplyconf will enforce the new rules.

Each service is defined by five parameters: service_name, service_cmd, service_restart, service_fail_fast_enabled, and service_halt_timeout. See the descriptions that follow.

The following is an example of fully defined service:

service_name patricks-package4-pingservice_cmd "/usr/sbin/ping hasupt22"service_restart unlimitedservice_fail_fast_enabled no service_halt_timeout 300

See the package configuration file for more examples.

For legacy packages, this parameter is in the package control script as well as the package configuration file.

service_cmd

The command that runs the application or service for this service_name, for example,

/usr/bin/X11/xclock -display 15.244.58.208:0

An absolute pathname is required; neither the PATH variable nor any other environment variable is passed to the command. The default shell is /usr/bin/sh.

NOTE: Be careful when defining service run commands. Each run command is executed in the following way:
  • The cmrunserv command executes the run command.

  • Serviceguard monitors the process ID (PID) of the process the run command creates.

  • When the command exits, Serviceguard determines that a failure has occurred and takes appropriate action, which may include transferring the package to an adoptive node.

  • If a run command is a shell script that runs some other command and then exits, Serviceguard will consider this normal exit as a failure.

To avoid problems in the execution of service commands, ensure that each run command is the name of an actual service and that its process remains alive until the actual service stops.

This parameter is in the package control script for legacy packages.

service_restart

The number of times Serviceguard will attempt to re-run the service_cmd. Valid values are unlimited, none or any positive integer value. Default is none.

If the value is unlimited, the service will be restarted an infinite number of times. If the value is none, the service will not be restarted.

This parameter is in the package control script for legacy packages.

service_fail_fast_enabled

Specifies whether or not Serviceguard will halt the node (system reset) on which the package is running if the service identified by service_name fails. Valid values are yes and no. Default is no, meaning that failure of this service will not cause the node to halt. yes is not meaningful if service_restart is set to unlimited.

service_halt_timeout

The length of time, in seconds, Serviceguard will wait for the service to halt before forcing termination of the service’s process.

The value should be large enough to allow any cleanup required by the service to complete.

Legal values are none, unlimited, or any number greater than zero. unlimited means Serviceguard will never force the process to terminate. The default is none, meaning that Serviceguard will not wait any time before forcing the process to terminate.

resource_name

The name of a resource to be monitored.

resource_name, in conjunction with resource_polling_interval, resource_start and resource_up_value, defines an Event Monitoring Service (EMS) dependency.

In legacy packages, RESOURCE_NAME in the package configuration file requires a corresponding DEFERRED_RESOURCE_NAME in the package control script.

You can find a list of resources in Serviceguard Manager (Configuration -> Create Package -> Monitored Resources -> Available EMS resources), or in the documentation supplied with the resource monitor.

A maximum of 60 EMS resources can be defined per cluster. Note also the limit on resource_up_value (see below).

The maximum length of the resource_name string is 1024 characters.

See “Parameters for Configuring EMS Resources” for more information and example.

resource_polling_interval

How often, in seconds, the resource identified by resource_name is to be monitored. Default is 60 seconds. The minimum value is 1. (There is no practical maximum.)

resource_start

Specifies when Serviceguard will begin monitoring the resource identified by resource_name. Valid values are automatic and deferred.

automatic means Serviceguard will begin monitoring the resource as soon as the node joins the cluster. deferred means Serviceguard will begin monitoring the resource when the package starts.

resource_up_value

Defines a criterion used to determine whether the resource identified by resource_name is up.

Requires an operator and a value. Values can be string or numeric.The legal operators are =, !=, >, <, >=, or <=, depending on the type of value. If the type is string, then only = and != are valid. If the string contains white space, it must be enclosed in quotes. String values are case-sensitive.

The maximum length of the entire resource_up_value string is 1024 characters.

You can configure a total of 15 resource_up_values per package. For example, if there is only one resource (resource_name) in the package, then a maximum of 15 resource_up_values can be defined. If two resource_names are defined and one of them has 10 resource_up_values, then the other resource_name can have only 5 resource_up_values.

concurrent_vgchange_operations

Specifies the number of concurrent volume group activations or deactivations allowed during package startup or shutdown.

Legal value is any number greater than zero. The default is 1.

If a package activates a large number of volume groups, you can improve the package’s start-up and shutdown performance by carefully tuning this parameter.Tune performance by increasing the number a little at a time and monitoring the effect on performance at each step; stop increasing it, or reset it to a lower level, as soon as performance starts to level off or decline.Factors you need to take into account include the number of CPUs, the amount of available memory, the HP-UX kernel settings for nfile and nproc, and the number and characteristics of other packages that will be running on the node.

NOTE: If you set concurrent_vgchange_operations to a value greater than 1, you may see messages such as this in the package log file:

Cannot lock “/etc/lvmconf//lvm_lock” still trying...”

This is an informational message that can be safely ignored.

enable_threaded_vgchange

Indicates whether multi-threaded activation of volume groups (vgchange -T) is enabled. New for modular packages. Available on HP-UX 11i v3 only.

Legal values are zero (disabled) or 1 (enabled). The default is zero.

Set enable_threaded_vgchange to 1 to enable vgchange -T for all of a package’s volume groups. This means that when each volume group is activated, physical volumes (disks or LUNs) are attached to the volume group in parallel, and mirror copies of logical volumes are synchronized in parallel, rather than serially. That can improve a package’s startup performance if its volume groups contain a large number of physical volumes.

Note that, in the context of a Serviceguard package, this affects the way physical volumes are activated within a volume group; concurrent_vgchange_operations controls how many volume groups the package can activate simultaneously.

IMPORTANT: Make sure you read the configuration file comments for both concurrent_vgchange_operations and enable_threaded_vgchange before configuring these options, as well as the vgchange (1m) manpage.
vgchange_cmd

Specifies the method of activation for each HP-UX Logical Volume Manager (LVM) volume group identified by a vg entry (see vg). Replaces VGCHANGE which is still supported in the package control script for legacy packages; see “Configuring a Legacy Package”.

The default is vgchange -a e.

The configuration file contains several other vgchange command variants; either uncomment one of these and comment out the default, or use the default. For more information, see the explanations in the configuration file, “LVM Planning ”, and “Creating the Storage Infrastructure and Filesystems with LVM and VxVM”.

IMPORTANT: Volume groups for multi-node and system multi-node packages must be activated in shared mode: vgchange -a s, which is only available if the add-on product Serviceguard Extension for Real Application Cluster (SGeRAC) is installed. (See the latest version of Using Serviceguard Extension for RAC at http://www.docs.hp.com -> High Availability -> Serviceguard Extension for Real Application Cluster (ServiceGuard OPS Edition) for more information.) Shared LVM volume groups must not contain a file system.

(For more information about LVM, see the Logical Volume Management volume of the HP-UX System Administrator’s Guide under System Administration in the HP-UX 11i v3 Operating Environments section of docs.hp.com, or Managing Systems and Workgroups under System Administration in the HP-UX 11i v2 section, depending which version of HP-UX you are running.)

NOTE: A given package can use LVM volume groups, VxVM volume groups, CVM volume groups, or any combination.
cvm_activation_cmd

Specifies the method of activation for Veritas Cluster Volume Manager (CVM) disk groups. The default is

vxdg -g \${DiskGroup} set activation=readonly

The configuration file contains several other vxdg command variants; either uncomment one of these and comment out the default, or use the default. For more information, see the explanations in the configuration file, “CVM and VxVM Planning ”, and “Creating the Storage Infrastructure and Filesystems with Veritas Cluster Volume Manager (CVM)”.

vxvol_cmd

Specifies the method of recovery for mirrored VxVM volumes. Replaces VXVOL, which is still supported in the package control script for legacy packages; see “Configuring a Legacy Package”.

If recovery is found to be necessary during package startup, by default the script will pause until the recovery is complete. To change this behavior, comment out the line

vxvol_cmd "vxvol -g \${DiskGroup} startall"

in the configuration file, and uncomment the line

vxvol_cmd "vxvol -g \${DiskGroup} -o bg startall"

This allows package startup to continue while mirror re-synchronization is in progress.

vg

Specifies an LVM volume group (one per vg, each on a new line) on which a file system needs to be mounted. A corresponding vgchange_cmd specifies how the volume group is to be activated. The package script generates the necessary filesystem commands on the basis of the fs_ parameters (see fs_name).

cvm_dg

Specifies a CVM disk group (one per cvm_dg, each on a new line) used by this package. CVM disk groups must be specified whether file systems need to be mounted on them or not. A corresponding cvm_activation_cmd specifies how the disk group is to be activated.

Any package using a CVM disk group must declare a dependency (see the entries for dependency_name and related parameters starting on dependency_name) on the CVM system multi-node package. See “Preparing the Cluster for Use with CVM ”.

vxvm_dg

Specifies a VxVM disk group (one per vxvm_dg, each on a new line) on which a file system needs to be mounted. See the comments in the package configuration file, and “Creating the Storage Infrastructure and Filesystems with LVM and VxVM”, for more information.

deactivation_retry_count

Specifies how many times the package shutdown script will repeat an attempt to deactivate a volume group (LVM) or disk group (VxVM, CVM) before failing.

Legal value is zero or any greater number. Default is zero.

kill_processes_accessing_raw_devices

Specifies whether or not to kill processes that are using raw devices (for example, database applications) when the package shuts down. Default is no. See the comments in the package configuration file for more information.

File system parameters

A package can activate one or more storage groups on startup, and to mount logical volumes to file systems. At halt time, the package script unmounts the file systems and deactivates each storage group. All storage groups must be accessible on each target node. (CVM disk groups must be accessible on all nodes in the cluster).

For each file system you specify in the package configuration file (see fs_name), you must identify a logical volume, the mount point, the mount, umount and fsck options and type of the file system; for example:

fs_name /dev/vg01/lvol1

fs_directory /pkg01aa

fs_mount_opt "-o rw"

fs_umount_opt "-s"

fs_fsck_opt "-s"

fs_type "vxfs"

A logical volume can be created in an LVM volume group, a Veritas VxVM disk group, or a Veritas CVM disk group. Logical volumes can be entered in any order, regardless of the type of storage group.

The parameter explanations that follow provide more detail

concurrent_fsck_operations

The number of concurrent fsck operations allowed on file systems being mounted during package startup.

Legal value is any number greater than zero. The default is 1.

If the package needs to run fsck on a large number of filesystems, you can improve performance by carefully tuning this parameter during testing (increase it a little at time and monitor performance each time).

concurrent_mount_and_umount_operations

The number of concurrent mounts and umounts to allow during package startup or shutdown.

Legal value is any number greater than zero. The default is 1.

If the package needs to mount and unmount a large number of filesystems, you can improve performance by carefully tuning this parameter during testing (increase it a little at time and monitor performance each time).

fs_mount_retry_count

The number of mount retries for each file system. Legal value is zero or any greater number. The default is zero.

If the mount point is busy at package startup and fs_mount_retry_count is set to zero, package startup will fail.

If the mount point is busy and fs_mount_retry_count is greater than zero, the startup script will attempt to kill the user process responsible for the busy mount point (fuser -ku) and then try to mount the file system again. It will do this the number of times specified by fs_mount_retry_count.

If the mount still fails after the number of attempts specified by fs_mount_retry_count, package startup will fail.

This parameter is in the package control script for legacy packages. See “Configuring a Legacy Package”.

fs_umount_retry_count

The number of umount retries for each file system. Replaces FS_UMOUNT_COUNT, which is still supported in the package control script for legacy packages; see “Configuring a Legacy Package”.

Legal value is any greater number greater than zero. The default is 1. Operates in the same way as fs_mount_retry_count.

fs_name

This parameter, in conjunction with fs_directory, fs_type, fs_mount_opt, fs_umount_opt, and fs_fsck_opt, specifies a filesystem that is to be mounted by the package. Replaces LV, which is still supported in the package control script for legacy packages.

fs_name must specify the block devicefile for a logical volume.

Filesystems are mounted in the order specified in this file, and unmounted in the reverse order.

NOTE: A volume group must be defined in this file (using vg; see vg) for each logical volume specified by an fs_name entry.

See “File system parameters”, and the comments in the FILESYSTEMS section of the configuration file, for more information and examples. See also “Logical Volume and File System Planning ”, and the mount (1m) manpage.

fs_directory

The root of the file system specified by fs_name. Replaces FS, which is still supported in the package control script for legacy packages; see “Configuring a Legacy Package”. See the mount (1m) manpage for more information.

fs_type

The type of the file system specified by fs_name. This parameter is in the package control script for legacy packages.

See the mount (1m) and fstyp (1m) manpages for more information.

fs_mount_opt

The mount options for the file system specified by fs_name. This parameter is in the package control script for legacy packages.

See the mount (1m) manpage for more information.

fs_umount_opt

The umount options for the file system specified by fs_name. This parameter is in the package control script for legacy packages.

Using the -s option of umount will improve startup performance if the package uses a large number of file systems. See the mount (1m) manpage for more information.

fs_fsck_opt

The fsck options for the file system specified by fs_name. Using the -s (safe performance mode) option of fsck will improve startup performance if the package uses a large number of file systems. This parameter is in the package control script for legacy packages.

See the fsck (1m) manpage for more information.

pev_

Specifies a package environment variable that can be passed to an external_pre_script, external_script, or both, by means of the cmgetpkgenv (1m) command. New for modular packages.

The variable name must be in the form pev_<variable_name> and contain only alphanumeric characters and underscores. The letters pev (upper-case or lower-case) followed by the underscore (_) are required.

The variable name and value can each consist of a maximum of MAXPATHLEN characters (1024 on HP-UX systems).

You can define more than one variable. See “About External Scripts”, as well as the comments in the configuration file, for more information.

external_pre_script

The full pathname of an external script to be executed before volume groups and disk groups are activated during package startup, and after they have been deactivated during package shutdown (that is, effectively the first step in package startup and last step in package shutdown). New for modular packages.

If more than one external_pre_script is specified, the scripts will be executed on package startup in the order they are entered into this file, and in the reverse order during package shutdown.

See “About External Scripts”, and the comments in the configuration file, for more information and examples.

external_script

The full pathname of an external script. This script is often the means of launching and halting the application that constitutes the main function of the package. New for modular packages.

The script is executed on package startup after volume groups and file systems are activated and IP addresses are assigned, but before services are started; and during package shutdown after services are halted but before IP addresses are removed and volume groups and file systems deactivated.

If more than one external_script is specified, the scripts will be executed on package startup in the order they are entered into this file, and in the reverse order during package shutdown.

See “About External Scripts”, and the comments in the configuration file, for more information and examples.

user_name

Specifies the name of a user who has permission to administer this package. See also user_host and user_role; these three parameters together define the access-control policy for this package (see “Controlling Access to the Cluster”). These parameters must be defined in this order: user_name, user_host, user_role.

Legal values for user_name are any_user or a maximum of eight login names from /etc/passwd on user_host.

NOTE: Be careful to spell any_user exactly as given; otherwise Serviceguard will interpret it as a user name.

Note that the only user_role that can be granted in the package configuration file is package_admin for this particular package; you grant other roles in the cluster configuration file. See “Setting up Access-Control Policies” for further discussion and examples.

user_host

The system from which a user specified by user_name can execute package-administration commands.

Legal values are any_serviceguard_node, or cluster_member_node, or a specific cluster node. If you specify a specific node it must be the official hostname (the hostname portion, and only the hostname portion, of the fully qualified domain name). As with user_name, be careful to spell the keywords exactly as given.

user_role

Must be package_admin, allowing the user access to the cmrunpkg, cmhaltpkg, and cmmodpkg commands (and the equivalent functions in Serviceguard Manager) for this package, and to the Monitor role for the cluster. See “Controlling Access to the Cluster” for more information.

Additional Parameters Used Only by Legacy Packages
IMPORTANT: The following parameters are used only by legacy packages. Do not try to use them in modular packages. See “Configuring a Legacy Package” for more information.
PATH

Specifies the path to be used by the script.

SUBNET

Specifies the IP subnets that are to be monitored for the package.

STORAGE_GROUP

Specifies CVM disk groups that do not use Veritas Cluster File System (CFS).

IMPORTANT: Use the STORAGE_GROUP parameter only for CVM (not LVM or VxVM) in legacy packages, and do not use it for CVM disk groups in a cluster that uses CFS. (CFS resources are controlled by two multi-node packages, one for the disk group and one for the mount point.)

Check the Serviceguard, SGeRAC, and SMS Compatibility and Feature Matrix and the latest Release Notes for your version of Serviceguard for up-to-date information about CVM and CFS support (http://www.docs.hp.com -> High Availability -> Serviceguard).

RUN_SCRIPT and HALT_SCRIPT

Use the full pathname of each script.

These two parameters allow you to separate package run instructions and package halt instructions for legacy packages into separate scripts if you need to. In this case, make sure you include identical configuration information (such as node names, IP addresses, etc.) in both scripts.

In most cases, though, HP recommends that you use the same script for both run and halt instructions. (When the package starts, the script is passed the parameter start; when it halts, it is passed the parameter stop.)

DEFERRED_RESOURCE_NAME

Add DEFERRED_RESOURCE_NAME to a legacy package control script for any resource that has a RESOURCE_START setting of DEFERRED.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© Hewlett-Packard Development Company, L.P.