Class definitions, class attributes, the shares and limits, and the automatic class assignment rules, can be entered using Web-based System Manager, SMIT, or the WLM command-line interface. These definitions and rules are kept in plain text files, that can also be created or modified using a text editor.
These files (called WLM property files) are kept in the subdirectories of /etc/wlm. A set of files describing superclasses and their associated subclasses define a WLM configuration. The files for the WLM Config configuration are in /etc/wlm/Config. This directory contains the definitions of the WLM parameters for the superclasses. The files are named description, classes, shares, limits, and rules. This directory might also contain subdirectories with the name of the superclasses where the subclass definitions are kept. For example, for the superclass Super of the WLM configuration Config, the directory /etc/wlm/Config/Super contains the property files for the subclasses of the superclass Super. The files are named description, classes, shares, limits, and rules.
After a WLM configuration has been defined by the system administrator, it can be made the active configuration using Web-based System Manager, the smit wlmmanage fast path, or the wlmcntrl command.
You can define multiple sets of property files, defining different configurations of workload management. These configurations are usually located in subdirectories of /etc/wlm. A symbolic link /etc/wlm/current points to the directory containing the current configuration files. This link is updated by the wlmcntrl command when WLM starts with a specified set of configuration files.
Instructions for creating a WLM configuration are described in in the AIX 5L Version 5.2 System Management Guide: Operating System and Devices. This section describes the concepts and requirements of each phase of the procedure.
The first phase of defining a configuration requires an understanding of your users and their computing needs, as well as the applications on your system, their resource needs and the requirements of your business (for example, which tasks are critical and which can be given a lower priority). Based on this understanding, you define your superclasses and then your subclasses.
Setting priorities is dependent on what function WLM serves in your organization. In the case of server consolidation, you might already know the applications, the users and their resource requirements, and you might be able to skip or shorten some of the steps.
WLM allows you to classify processes by user or group, application, type, tag, or a combination of these attributes. Because WLM regulates the resource utilization among classes, system administrators should group applications and users with the same resource utilization patterns into the same classes. For instance, you might want to separate the interactive jobs that typically consume very little CPU time but require quick response time from batch-type jobs that typically are very CPU- and memory-intensive. This is the same in a database environment in which you need to separate the OLTP-type traffic from the heavy-duty queries of data mining.
This step is done using Web-based System Manager, SMIT, or command-line interface. For the first few times, it is probably a good idea to use Web-based System Manager or SMIT to take you through the steps of creating your first WLM configuration, including defining the superclasses and setting their attributes. For the first pass, you can set up some of the attributes and leave the others at their default value. This is the same for the resource shares and limits. All these class characteristics can be dynamically modified at a later time.
You can then start WLM in passive mode, check your classification, and start reviewing the resource utilization patterns of your applications.
Verify your configuration, using the wlmcheck command or the corresponding SMIT or Web-based System Manager menus. Then start WLM in passive mode on the newly defined configuration. WLM will classify all the existing processes (and all processes created from that point on) and start compiling statistics on the CPU, memory, and disk I/O utilization of the various classes. WLM will not try to regulate this resource usage.
Verify that the various processes are classified in the appropriate class as expected by the system administrator (using the -o flag of the ps command). If some of the processes are not classified as you expect, you can modify your assignment rules or set the inheritance bit for some of the classes (if you want the new processes to remain in the same class as their parent) and update WLM. You can repeat the process until you are satisfied with this first level of classification (superclasses).
Running WLM in passive mode and refreshing WLM (always in passive mode) involves low risk, has low overhead operation, and can be done safely on a production system without disturbing normal system operation. To activate and refresh WLM, use the wlmcntrl command, invoked either from the command line or from SMIT or Web-based System Manager.
Run WLM in passive mode to gather statistics by using the wlmstat command. The wlmstat command can be used at regular time intervals to display the per-class resource utilization as a percentage of the total resource available, for superclasses). This allows you to monitor your system for extended periods of time to review the resource utilization of your main applications.
Using the data gathered from running WLM in passive mode and your business goals, decide which tier number will be given to every superclass and what share of each resource should be given to the various classes. For some classes, you might want to define minimum or maximum limits. Adjust the shares and tier numbers to reach your resource-allocation goals. Reserve limits for cases that cannot be solved only with shares. Also, you might decide you need to add subclasses.
When creating and adjusting the parameters of subclasses, you can refresh WLM only for the subclasses of a given superclass that do not affect users and applications in the other superclasses, until you are satisfied with the system behavior.
You can also define other configurations with different parameters, according to the needs of the business. When doing so, you can save time by copying and modifying existing configurations.
You are now ready to start WLM in active mode. Monitor the system using the wlmstat command and verify that the regulation done by WLM aligns with your goals and does not unduly deprive some applications of resources while others get more than they should. If this is the case, adjust the shares and refresh WLM.
As you monitor and adjust the shares, limits, and tier numbers, decide whether you want to delegate the administration for the subclasses for some or all of the superclasses. The administrator can then monitor and set up the subclass shares, limits, and tier number.
The administrator of each superclass can repeat this process for the subclasses of each superclass. The only difference is that WLM cannot run in passive mode at the subclass level only. The subclass configuration and tuning has to be done with WLM in active mode. One way not to impact users and applications in the superclass is to start the tier number, and the shares and limits for the subclasses at their default value ('-' (hyphen) for shares, 0% for minimum, and 100% for soft and hard maximum). With these settings, WLM will not regulate the resource allocation between the subclasses.