Some common WLM tasks

(Optional) Set up secure WLM communications.

Follow the procedure HOW TO SECURE COMMUNICATIONS in wlmcert(1M)—skipping the step about starting/restarting the WLM daemons. You will do that later in this procedure.

Create a WLM configuration file for each partition.

Each partition on the system must have the WLM daemon wlmd running. Create a WLM configuration file for each partition, ensuring each configuration uses the primary_host keyword to reference the partition where the global arbiter is running. For information on the primary_host syntax, see “Setting up your WLM configuration file”.

(Optional) Activate each partition’s WLM configuration in passive mode.

WLM operates in “passive mode” when you include the -p option in your command to activate a configuration. With passive mode, you can see approximately how a particular configuration is going to affect your system—without the configuration actually taking control of your system.Activate each partition’s WLM configuration file configfile in passive mode as follows:

# wlmd -p -a configfile

For information on passive mode, including its limitations, see “Passive mode versus actual WLM management”.

Activate each partition’s WLM configuration.

After verifying and fine-tuning each partition’s WLM configuration file configfile, activate it as follows:

# wlmd -a configfile

To use secure communications, activate the file using the -s option:

# wlmd -s -a configfile

The wlmd daemon runs in secure mode by default when you use the /sbin/init.d/wlm script to start WLM. (If you upgraded WLM, secure mode might not be the default. Ensure that the appropriate secure mode variables in /etc/rc.config.d/wlm are set correctly. For more information on these variables, see “Securing WLM communications”.)

Create a configuration file for the global arbiter.

On the system running the global arbiter, create a configuration file for the global arbiter. (If this system is being managed by WLM, it will have both a WLM configuration file and a WLM global arbiter configuration file. You can set up and run the global arbiter configuration on a system that is not managed by WLM if needed for the creation of fault-tolerant environments or Serviceguard environments.)

This global arbiter configuration file is required. In the file specify the:

For information on the syntax of this file, see the section “Setting up your WLM global arbiter configuration file” or see wlmparconf(4).

(Optional) Activate the global arbiter configuration file in passive mode.

Similar to the WLM passive mode, the WLM global arbiter has a passive mode (also enabled with the -p option) that allows you to verify wlmpard settings before letting it control your system.

Activate the global arbiter configuration file configfile in passive mode as follows:

# wlmpard -p -a configfile

Again, to see approximately how the configuration would affect your system, use the WLM utility wlminfo.

Activate the global arbiter.

Activate the global arbiter configuration file as follows:

# wlmpard -a configfile

To use secure communications, activate the file using the -s option:

# wlmpard -s -a configfile

The global arbiter runs in secure mode by default when you use the /sbin/init.d/wlm script to start WLM. (If you upgraded WLM, secure mode might not be the default. Ensure that the appropriate secure mode variables in /etc/rc.config.d/wlm are set correctly. For more information on these variables, see “Securing WLM communications”.)

Define the workload group and assign a workload to it.

In your WLM configuration file, define your workload group in a prm structure using the groups keyword. Assign a workload to the group using the apps keyword.

In this example, the sales group is the group of interest again.

prm {
    groups = sales : 2;
 
    apps = sales : /opt/sales/bin/sales_monitor;
}

Define the SLO.

The SLO in your WLM configuration file must specify:

The condition keyword determines when the SLO is enabled or disabled.

The following slo structure shows a fixed-allocation SLO for the sales group. When enabled, this SLO requests 25 CPU shares for the sales group. Based on the condition statement, the SLO is enabled between 8pm and 11pm every day.

slo condition_example {
    pri = 1;
    entity = PRM group sales;
    cpushares = 25 total;
    condition = 20:00 - 22:59;
}

Whenever the condition statement is false, the SLO is disabled and does not make any CPU resource requests for the sales group. When a group has no enabled SLOs, it gets its gmincpu value (if set); if this value is not set, a group gets the minimum allocation possible. For FSS groups, this is 1% of the CPU resources of the default PSET (the default PSET—also referred to as PSET 0—is discussed in “The default PSET (PSET 0) and FSS groups”). If the extended_shares tunable is set to 1 and absolute CPU units are being used, this minimum is 0.2% (with incremental allocations of 0.1%). For more information on the extended_share tunable, see “Refining granularity of CPU (and memory) allocation by increasing shares per core (optional) ”.

You can use times, dates, or metrics to enable or disable an SLO.

For information on the syntax for the condition keyword, see wlmconf(4).

Activate the configuration as in the following example, substituting your configuration file’s name for config.wlm:

# /opt/wlm/bin/wlmd -a config.wlm

Define the workload group and assign a workload to it.

In your WLM configuration file, define your workload group in a prm structure using the groups keyword. Assign a workload to the group using the apps keyword.

The following example shows the prm structure for the sales group.

prm {
    groups = sales : 2;
 
    apps = sales : /opt/sales/bin/sales_monitor;
}

Define the SLO.

The SLO in our WLM configuration must specify:

The following slo structure for the sales group shows a usage goal statement:

slo usage_example {
    pri = 1;
    mincpu = 20;
    maxcpu = 60;
    entity = PRM group sales;
    goal = usage _CPU 80 90;
}

With usage goals, WLM adjusts the amount of CPU resources it grants a workload group so that the group uses between 50% and 75% of its allocated CPU resources by default. In the previous example though, with the values of 80 and 90 in the goal statement, WLM would try to increase or decrease the CPU allocation for the workload group until the group is using between 80% and 90% of the allocated share of CPU resources. However, in attempting to meet the usage goal, the new CPU allocations to the workload group will typically be within the mincpu/maxcpu range.

Set your interval to 5.

With a usage goal, you should typically set wlm_interval to 5.

tune {
    wlm_interval = 5;
}

Activate the configuration as in the following example, substituting your configuration file’s name for config.wlm:

# /opt/wlm/bin/wlmd -a config.wlm