Overview of Workload Manager Architecture

Workload Manager provides an intelligent policy engine that monitors workloads running in a Virtual Server Environment and dynamically adjusts resource allocation to ensure that workloads are meeting their service-level objectives. The architecture of WLM relies on several building blocks that are used according to the technologies that have been chosen to manage resources. The Workload Manager product was originally designed to reallocate resources between Secure Resource Partitions using Process Resource Manager (PRM). As a result, the most critical component of WLM is the wlmd daemon. This daemon is responsible for collecting data for workloads running on the system, determining the level of resources required to meet the SLOs for each workload, and then reconfiguring the Secure Resource Partitions to better meet all of the SLOs in the environment. The internal architecture of wlmd is shown in Figure 15-1. The major internal components of wlmd include:

Controllers: WLM initializes a workload controller for every SLO. The controllers are responsible for taking in whatever data is being used to drive resource entitlements based on the defined goal for the SLO, determining how well the workload is currently satisfying its goal, and then deciding whether a resource adjustment is required to help the workload better meet the goal. The controller then passes the new entitlement request to the arbiter.

The Arbiter: The resource arbiter is responsible for taking in all the resource requests from all of the controllers and deciding which requests will be granted. If there are sufficient resources to satisfy all requests, each workload gets the requested resources. If there is not enough to go around, the arbiter uses the priorities on the SLOs to determine the entitlements. The highest-priority SLOs will get their requests filled before lower-priority SLOs.

Figure 15-1. Internal Architecture of the wlmd Daemon

Figure 15-1 also shows that there are different types of controllers depending on the type of goal defined for the workload. WLM supports the following types of controllers.

Metric Data Collector is used when a specific goal has been defined, such as "response time must stay below five seconds." In this case, an external process or script must provide the response-time metric to the controller. The controller will base its entitlement request on how well the actual response time compares to the goal.

Usage Data Collector is a simple CPU utilization goal. In this case there is no need for a data collector because WLM collects the data itself. The controller will request more CPU resources if the utilization in the partition is high (greater than 75% by default). If the utilization is low (below 50% by default) then the controller will give back some of the resources and allow another workload to use them.

Fixed Allocation also requires no external data sources. In this case, the controller will always request the same resource entitlement. The arbiter will satisfy the request as long as there is enough left over after satisfying higher-priority SLOs.

Shares-per-metric sets the requests and entitlements based on the value of an external metric. The shares-per-metric controller could be used with a metric such as "the number of users" or possibly "the number of processes" if the workload is batch oriented. With this controller, the entitlement request could be some number of shares for each process or user. This allows the entitlement to increase when a workload gets busy, but it is not necessarily a direct measurement of the actual performance of the workload.

Finally, Figure 15-1 shows the linkage between the WLM arbiter to the PRM infrastructure. This linkage is used to reconfigure Secure Resource Partitions after the WLM arbiter has determined new entitlements. This information is also passed to the global arbiter in a multipartition configuration, which is discussed next.

Architecture of Workload Manager's Multipartition Mode

WLM also supports a multipartition mode. In this mode multiple nPartitions or virtual partitions can share resources with WLM acting as the arbiter between multiple partitions. When WLM is running in the multipartition mode, two additional daemons, wlmpard and wlmparc, arbitrate across the partitions. Figure 15-2 shows how these additional daemons are used.

Figure 15-2. Architecture of WLM when Managing Resources across Multiple Operating Systems

The wlmpard daemon is the global arbiter. This daemon accepts the entitlement requests from the wlmd daemons in each of the partitions and determines if there is any need to reallocate CPU resources between the partitions. When it sees the need to reallocate resources, it sends requests to the wlmparc daemons running in each partition to either deallocate or allocate resources.

Remote User Interface Architecture

The previous architectural discussions have focused on the WLM collectors and daemons. The last architectural feature of interest is WLM's remote GUI. The architecture of the remote user interface is shown in Figure 15-3.

Figure 15-3. Architecture of the WLM Remote Graphical User Interface

The WLM GUI is a Java application that can run on the managed system or on any Windows, HP-UX, or Linux system that has the Java Runtime Environment version 1.4.2 or higher. On the managed nodes, an additional communications daemon, wlmcomd, is required. The GUI connects to the remote wlmcomd daemons via secure sockets layer (SSL); and once it establishes the connection, the data that is passed between the GUI and the partition is encoded in XML. This lightweight communication protocol makes it possible to run the GUI on a desktop connected to the systems via a low-speed connection with very little performance degradation.

The WLM GUI also allows users to create a partition set, which consists of an arbitrary group of partitions that are running wlmcomd. After the partition set has been defined, WLM's monitoring and management functions are greatly enhanced. Since the partitions need not reside within the same system, the partitions that host a multi-tier application, for example, can be defined in a partition set. WLM creates a single graph that monitors the resource utilization of all the instances in the application.

Workload Manager Configuration Options

WLM can be configured through a graphical user interface or by directly editing the configuration files. There are two configuration options when using the GUI. The first option is the WLM wizard, wlmcw. The WLM wizard continues to evolve and starting in version 3.0 it supports template-based configurations. The templates provide a step-by-step configuration of the most common configuration choices. The following templates are supported in the WLM wizard in version 3.0:

Utility Pricing PPU: provides configuration assistance for a single nPar wlmd and wlmpard configuration that minimizes the Pay per use cost of a system by ensuring that CPUs are turned off when they are idle.

Secure Resource Partitions: provides configuration assistance for multiple workloads running in a single OS image. It enables configuration of SLOs for each workload and allows the configuration of each workload to be isolated in a security compartment.

Multipartitions: provide configuration assistance for either CPUs between nPartitions using Instant Capacity or reallocation of CPUs between vPars. In these configurations, there is a single workload in each OS image and CPU utilization will be used to determine when more CPU resources are needed.

The second configuration option is a form-based configuration editor GUI, wlmgui. The WLM GUI allows users to load and edit an existing configuration or create a new configuration. HP highly recommends that users start with a simple configuration until they become comfortable with how WLM allocates resources. At that point, the users can use the WLM GUI to tweak individual configuration parameters to tune the configuration.