Steps for using WLM

Identify the workloads to run on a given system.

Each workload can consist of one or more applications and multiple users.

Separate the workloads into three types:

For information on the types of workloads and their associated SLOs, see “Shares-based SLOs vs goal-based SLOs”.

Start a WLM configuration file using a text editor. Define your workloads.

For workloads without goals, add shares-based SLOs to your configuration.

Determine the amount of CPU resources each workload requires so that you can set appropriate CPU shares requests. One method for determining CPU needs is illustrated in the example configuration file “manual_entitlement.wlm”.

For information on the types of SLOs, see “Shares-based SLOs vs goal-based SLOs”.

For workloads with CPU usage goals, add goal-based SLOs to your configuration. For information on usage goals, see “Specifying a goal (optional)”.

For workloads with performance goals, add goal-based SLOs to your configuration, as explained in “Configuring WLM for metric-based SLOs”.

(Optional) Tune the controllers’ behavior.

Consider tuning controllers if your workload performance is not responding to load changes quickly enough or if workload performance is erratic.

(Optional) For notification of SLO status changes, monitor the WLM EMS resources.

For information on EMS, see Chapter 10 “Monitoring SLO compliance and WLM”.

(Optional) Activate the 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.

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

Activate the WLM file configfile in passive mode as follows:

# wlmd -p -a configfile

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

For wlmd syntax information, see Appendix A “WLM command reference”.

Activate the configuration.

	NOTE: When you start WLM by using the /sbin/init.d/wlm script, WLM runs in secure mode by default. However, if you are upgrading WLM and the /etc/rc.config.d/wlm script had been modified prior to the upgrade, ensure that the secure mode variables discussed in “Securing WLM communications” are enabled. You also must have set up security certificates and distributed them to all systems or partitions being managed by the same WLM global arbiter (wlmpard). HP recommends using secure mode. If you choose not to use secure mode, use global arbitration only on trusted local area networks. For information on securing communications, see the section HOW TO SECURE COMMUNICATIONS in wlmcert(1M).

Activate your configuration—putting WLM in control of your system’s resources—as follows:

# wlmd -a -s configfile

To generate audit data (-t) and log statistics (-l all), use the following command:

# wlmd -t -a -s configfile -l all

Monitor SLO compliance.

Using wlmgui or wlminfo with its slo command allows you to monitor your SLOs.

Also, the WLM EMS monitor makes various status data available to EMS clients. Check this data to verify SLO compliance.

For more information on this topic, see Chapter 10 “Monitoring SLO compliance and WLM”.

Monitor data collectors.

Data collection is a critical link in the effective maintenance of your configured service-level objectives. When a data collector dies, each SLO that uses the data from the dead collector is affected. Consequently, monitor your data collectors so you can be aware when one dies.

When using wlminfo slo, there are two columns that can indicate the death of a data collector process: State and Concern. For more information on these columns, see wlminfo(1M).

Alternatively, configure EMS monitoring requests that notify you on the death of a data collector.

The SLO’s EMS resource:

/applications/wlm/slo_status/SLONAME

changes to:

WLM_SLO_COLLECTOR_DIED (5)

Use the EMS configuration interface (available in the SAM or SMH “Resource Management” application group) to set up monitoring requests to watch for this situation. For information about using SMH, see “Configuring EMS notification”.

(Optional) Configure global arbitration across partitions.

You can set up WLM to automatically move cores between virtual partitions or nPartitions in response to the service-level objectives of the workloads in the partitions. The workloads would be specified workloads inside the partitions or the partitions themselves if you did not define workloads in the partitions.

	NOTE: By default, WLM global arbitration runs in secure mode when you use the /sbin/init.d/wlm script to start WLM. However, if you are upgrading WLM and the /etc/rc.config.d/wlm script had been modified prior to the upgrade, ensure that the secure mode variables discussed in “Securing WLM communications” are enabled. You also must have performed the required steps to set up security certificates and distribute them. HP recommends using secure mode. If you choose not to use secure mode, use global arbitration only on trusted local area networks.

For more information on the global arbiter, including its passive mode, see the chapter Chapter 7 “Managing SLOs across partitions”.

(Optional) Set up WLM to automatically start its wlmd and wlmpard daemons at reboot.

Edit the /etc/rc.config.d/wlm file as explained in the sections “Setting WLM to start automatically at reboot” and “Setting WLM global arbitration to start automatically at reboot”. You can also set variables in /etc/rc.config.d/wlm to start logging statistics and generating audit data automatically at reboot.