Managing HP Serviceguard A.11.20.20 for Linux, May 2013

6.1.4.21 weight_name, weight_value
These parameters specify a weight for a package; this weight is compared to a node's available
capacity (defined by the CAPACITY_NAME and CAPACITY_VALUE parameters in the cluster
configuration file) to determine whether the package can run there.
Both parameters are optional, but if weight_value is specified, weight_name must also be
specified, and must come first. You can define up to four weights, corresponding to four different
capacities, per cluster. To specify more than one weight for this package, repeat weight_name
and weight_value.
NOTE: But if weight_name is package_limit, you can use only that one weight and capacity
throughout the cluster. package_limit is a reserved value, which, if used, must be entered
exactly in that form. It provides the simplest way of managing weights and capacities; see “Simple
Method” (page 121) for more information.
The rules for forming weight_name are the same as those for forming package_name (page 175).
weight_name must exactly match the corresponding CAPACITY_NAME.
weight_value is an unsigned floating-point value between 0 and 1000000 with at most three
digits after the decimal point.
You can use these parameters to override the cluster-wide default package weight that corresponds
to a given node capacity. You can define that cluster-wide default package weight by means of
the WEIGHT_NAME and WEIGHT_DEFAULT parameters in the cluster configuration file (explicit
default). If you do not define an explicit default (that is, if you define a CAPACITY_NAME in the
cluster configuration file with no corresponding WEIGHT_NAME and WEIGHT_DEFAULT), the
default weight is assumed to be zero (implicit default). Configuring weight_name and
weight_value here in the package configuration file overrides the cluster-wide default (implicit
or explicit), and assigns a particular weight to this package.
For more information, see “About Package Weights” (page 120). See also the discussion of the
relevant parameters under “Cluster Configuration Parameters ” (page 91), in the cmmakepkg
(1m) and cmquerycl (1m) manpages, and in the cluster configuration and package
configuration template files.
6.1.4.22 monitored_subnet
The 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” (page 233).
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 (page 183), and
“About Cross-Subnet Failover” (page 130).)
Typically you would monitor the ip_subnet, specifying it here as well as in the ip_subnet
parameter (page 182), but you may want to monitor other subnets as well; you can specify any
subnet that is configured into the cluster (via the STATIONARY_IP parameter in the cluster
configuration file). See “Stationary and Relocatable IP Addresses and Monitored Subnets” (page 62)
for more information.
If any monitored_subnet fails, Serviceguard will switch the package to any other node specified
by node_name (page 176) which can communicate on all the monitored_subnets defined for
this package. See the comments in the configuration file for more information and examples.
6.1 Choosing Package Modules 181