sg_pkg_active(1M)sg_pkg_active(1M)NAMEsg_pkg_active - check the status of a Serviceguard package
SYNOPSIS
interval] [package_name]
DESCRIPTION
The command, when used with WLM's data collector (see wlmrcvdc(1M) ),
allows you to check the status of a Serviceguard package. If the pack‐
age is active on the local host machine, is printed to stdout; other‐
wise, is printed.
Use to maintain a single WLM configuration across a Serviceguard clus‐
ter. With you can activate and deactivate a Serviceguard package's SLOs
along with the package.
must run as root.
OPTIONS
Checks the status of the package once and exits. Without
checks the package status repeatedly, with the frequency deter‐
mined by
Sets the sleep time between checks to
interval seconds. When omitted, interval is set to the value of
which is set in the WLM configuration file. If is not set, inter‐
val is set to the default (60 seconds).
package_name
Instructs to check on the status of the Serviceguard package named
package_name. By default, checks on the Serviceguard package
whose name is derived from the environment variable, which must
have the format package_name_active. When is invoked by WLM, is
automatically constructed for each metric.
HOW TO USE sg_pkg_active
Use to integrate WLM with Serviceguard, as explained below.
Step 1
Install WLM on each node in your Serviceguard cluster.
Step 2
Edit a single WLM configuration file to handle all the Serviceguard
packages in the cluster. The example below assumes there are two pack‐
ages: pkgA and pkgB.
A. Place all the packages' applications in workload groups
in the structure:
prm {
...
groups = pkgA:2, pkgB:3;
apps = pkgA:/opt/dbase/bin/sales_dbase,
pkgB:/opt/dbase/bin/finance_dbase;
...
}
B. Use to set up structures to report a
status metric for each package:
tune pkgA_active {
coll_argv = wlmrcvdc sg_pkg_active;
}
tune pkgB_active {
coll_argv = wlmrcvdc sg_pkg_active;
}
These structures set the metric values pkgA_active and pkgB_active
to 1 if their packages are indeed active on the current node.
Rather than creating structures for each package, you can set up a
global structure that takes in package status data from any running
tune {
coll_argv = wlmrcvdc sg_pkg_active;
}
C. Set up structures for each status metric, with the SLO
being active when the package is active:
slo pkgA_slo {
...
condition = metric pkgA_active;
...
}
slo pkgB_slo {
...
condition = metric pkgB_active;
...
}
Recall that the statement governs when an SLO is active: If an SLO's
condition expression is true, the SLO is active. In these cases, the
expressions "metric pkgA_active" and "metric pkgB_active" are true
when the pkgA_active and pkgB_active metrics are 1.
Workload groups that have only inactive SLOs continue to consume
system resources. To prevent this needless consumption, use the tun‐
able, which is described in the next substep. This tunable causes
groups with inactive SLOs to be temporarily removed. If you do not
want inactive workload groups to be removed, you can minimize
resource allocation to inactive groups by using the tunable, as
described in wlmconf(4).
D. (Optional) Use in a global structure to
temporarily remove workload groups with no active SLOs
By default, if a package's workload group has no active SLOs, WLM
reduces its resource shares. Such a workload group receives 1% of
the total CPU resources (for FSS groups) or one core (for PSET-based
groups), unless it has a value requesting more. (A core is the
actual data-processing engine within a processor, where a processor
might have multiple cores.) Similarly, if you are using WLM's memory
management, the workload group with no active SLOs receives 1% of
the memory, unless the group has a value requesting more.
If the tunable is enabled (extended_shares = 1), a group with no
active SLOs requires 0.2% of the total CPU resources for FSS groups,
unless it has a value requesting more. If you are using WLM's memory
management, the workload with no active SLOs receives 0.2% of the
memory, unless the workload has a value requesting more.
If you would prefer these groups to go away temporarily (as long as
they have no active SLOs) and consume no CPU or memory resources,
set the tunable to 1 in a global structure:
tune {
transient_groups = 1;
}
With the keyword set to 1: FSS groups with no active SLOs are
deleted and therefore use no resources; the minimum CPU allocation
for PSET groups becomes 0.
If an FSS workload group has been temporarily removed, its and val‐
ues (if any) are ignored.
The group is never removed, regardless of the group's number of
active SLOs. Likewise, any group associated with a process map is
never removed.
Step 3
Validate the syntax of the configuration file:
# /opt/wlm/bin/wlmd -c configfile
Correct any errors found in the syntax check.
Step 4
Distribute the WLM configuration file to all the nodes in the cluster.
Step 5
Activate WLM with your configuration file on all the nodes:
# /opt/wlm/bin/wlmd -a configfile
If you are using WLM's secure communications, be sure to distribute the
security certificates as explained in the section HOW TO SECURE COMMU‐
NICATIONS in wlmcert(1M) .
RETURN VALUE
returns exit status if no errors occur, or if there are errors.
EXAMPLE
The partial example WLM configuration file below assumes a Serviceguard
package called app1.
slo app1 {
pri = 1;
mincpu = 10;
maxcpu = 80;
entity = PRM group app1_group;
goal = usage _CPU;
condition = metric app1_active;
}
tune {
wlm_interval = 10;
transient_groups = 1;
}
tune app1_active {
coll_argv = wlmrcvdc sg_pkg_active-i 30;
}
checks the value of the environment variable, which WLM automatically
sets to app1_active in this case. For nonzero values of the metric, the
package app1 is considered active, and the expression in the structure
is true. Consequently, the SLO is active.
runs in multiple-sample mode (the default), checking the status of
package app1 every 30 seconds. Had the option not been specified in the
second structure, would check every 10 seconds because of being set in
the global structure. With the tunable set, whenever the app1 SLO is
not active, the associated workload group is temporarily removed unless
the group is associated with a process map. Groups associated with a
process map always remain active.
AUTHOR
was developed by HP.
FEEDBACK
If you would like to comment on the current HP-UX WLM functionality or
make suggestions for future releases, please send email to:
wlmfeedback@rsn.hp.com
SEE ALSOwlmrcvdc(1M), wlmsend(1M), wlmconf(4), wlm(5), glance_app(1M),
glance_gbl(1M), glance_prm(1M), glance_prm_byvg(1M), glance_tt(1M)
HP-UX Workload Manager User's Guide (/opt/wlm/share/doc/WLMug.pdf)
"Writing a Better WLM Data Collector" white paper
(/opt/wlm/share/doc/howto/perfmon.html)
HP-UX Workload Manager homepage (http://www.hp.com/go/wlm)
Serviceguard documentation (available at http://docs.hp.com)
sg_pkg_active(1M)
