You are likely to use both Capacity Advisor and Serviceguard together
in your data center.
Serviceguard organizes
systems or nodes into clusters. In a Serviceguard environment, applications,
services, and other entities are organized as packages that can move from
one cluster node to another.
VSE management software organizes applications into workloads. Capacity
Advisor collects utilization data for both systems and workloads. As a package
fails over from one system to another, one of the workloads that Capacity
Advisor is tracking might also move from one system to another. Capacity Advisor
continues to monitor the workload on the old system until the workload is
updated or edited to change the host
name to that of the new host. Serviceguard packages and Capacity Advisor workloads
are defined independently but can overlap.
In setting up your Capacity Advisor to monitor workloads that run on
a Serviceguard cluster, you have several options:
Define a workload only for the system where the package
usually runs.
Define a workload for every possible package/node pair.
Create one workload per package but manually move the workload
after a failover.
Defining a Workload for Where the Package Usually Runs |
 |
This is the easiest way to set up Capacity Advisor. It is simple to
implement and is how you would do things if Serviceguard were not present.
The drawback is that when a Serviceguard failover happens, Capacity Advisor
records all utilization numbers as zero; there are no utilization numbers
for when the workload was running on another system. After the package moves
back to its usual system, you must use the Capacity Advisor Profile Editor
to mark any zero-utilization
entries as invalid data. This ensures that the zeros are not used for computing average
utilization and other metrics. Use this solution to minimize the time that
packages run on systems other than their usual systems.
If the package is configured using the MIN_PACKAGE_NODE failover policy,
determining what is the “usual system” might not be obvious because
the package is started where there are the fewest number of packages. If
the other packages are set up with the CONFIGURED_NODE policy, an administrator
might be able to decide which is the usual system. For packages that use the
CONFIGURED_NODE policy, the “usual system” is the first system
in the node list.
The relationship between workloads and packages is not 1:1 but rather n:1.
Defining a Workload for Every Package/node Pair |
|
When setting up VSE management software, you can define a workload for
each Serviceguard package on every node of the cluster where that package
might run. (This applies only to packages that consist of one or more processes.)
Packages that correspond to a part of a process, a file, or an IP address
cannot correspond to a VSE workload because a VSE workload is a collection
of processes. By defining a separate VSE workload for each node in the cluster, Capacity Advisor can collect utilization
data no matter where the workload is running. Capacity Advisor records nonzero
readings for the system where the workload is actually running, and records
readings of zero for workloads defined on the systems where the package is
not running.
When using Capacity Advisor to simulate moving a workload to a new
system, move all the workloads that represent the same package. The zero
entries sum with the nonzero entries to represent the workload as an unbroken
trace. This is a more complete solution than defining a workload for where
a package usually runs, if a package does not have a cluster node on which
it usually runs. It is also a more complete solution because you continue
to collect data if a workload is moved because of a package failover.
You should use Capacity Advisor’s Profile Editor to mark readings
as invalid near the time when the workload was in transition from one system
to another. During this period, many factors affect utilization readings,
such as the system getting into an error state, the extra load of the application
being restarted, and the extra demands of clearing the backlog of requests
that arrived while the failure was being detected and the package restarted.
These spikes in utilization are not predictable and are generally not taken
into account when doing capacity planning. Since many Serviceguard clusters
have only two nodes, this can double the number of workloads defined, and
defining workloads for every package/node pair may not be a practical solution
on clusters with many nodes.
Defining a Workload per Package and Manually Moving Workloads |
|
This option is set up in the same way as the first, defining a workload
for where a package usually runs. In this option, a single VSE workload is
defined for each application running on the Serviceguard cluster. Each workload
is defined with the host where the application is initially running, the application's
primary node. The difference is that when a package fails over, someone manually
runs VSE Manager and edits the workload to indicate that it is now running
on a different system. This involves running cmviewcl to
find out where the package that corresponds to the workload is currently running.
You then enter this information into the Virtualization Manager page for
editing workloads. Capacity Advisor collects data later that night, finds
data for the workload on more than one system, and merges the data together
into a single trace.
As with the second option, defining a workload for every package/node
pair, the utilization data collected near the time of the failover should
be marked as invalid. This includes the time just before the failover through to the time when the workload
was edited to reflect the system where it is currently running. This option
might be best for installations where clusters have several nodes, or where
packages are not migrated back to the original node of the cluster as soon
as possible. In either case, someone must monitor Serviceguard failover events
and update the workload definition to reflect the new host.
Printable version
