IBM Tivoli Monitoring: Implementation and Performance Optimization for Large Scale Environments

106 IBM Tivoli Monitoring: Implementation and Performance Optimization for Large Scale Environments

Figure 4-21 Sorted list of attribute groups with number of monitoring server for collection

To benefit from this feature, you have to assign the agents to different monitoring

servers when implementing your environment. This feature can also be used to

temporarily shift agents to the data collection in certain situations. If you are

planning to use different collection parameters for a given attribute group on

different monitoring servers, these configuration actions have to be done as

separate actions through the historical collection configuration user dialog (that

is, not at the same time).

4.4.2 Configure multiple Warehouse Proxy agents

Multiple Warehouse Proxy agents has been supported since IBM Tivoli

Monitoring V6.1 Fix Pack 2, but Fix Pack 5 should be installed in order to use all

the features described here.

More than one Warehouse Proxy agent could be beneficial for the following

reasons:

򐂰 Maintenance

When maintenance procedures (such as adding more memory, replacing a

disk, or defragmenting a filesystem) are applied on the machine where one

Warehouse Proxy agent is installed, other Warehouse Proxy agents can be

used to send the historical data to the Tivoli Data Warehouse database.

Note: A Technote explaining best practices for configuring multiple

Warehouse Proxy agents is available at the following site:

http://www-1.ibm.com/support/docview.wss?rs=0&q1=Configuring+Multiple+Wareho

use+Proxy+Agents&uid=swg21268675&loc=en_US&cs=utf-8&cc=us&lang=en

Chapter 4. Planning historical data collection in large scale environments 107

򐂰 Sharing the load

A large volume of simultaneous uploaded requests may negatively affect the

insertion rate if only one Warehouse Proxy agent is used. 5.5, “Tivoli Data

Warehouse performance” on page 151 advises how to set some Warehouse

Proxy tuning variables such as the number of export threads, the size of the

queue containing the historical exports, the batch option, or the database

itself when the Warehouse Proxy agent has to handle large data volumes.

Note that, if one Warehouse Proxy agent cannot handle all the historical

exports despite the tuning, the workload can be shared by installing multiple

Warehouse Proxy agents.

򐂰 Failover

Tivoli Monitoring 6.1 FP5 provides the ability to automatically send historical

uploads to a failover Warehouse Proxy agent when the communication to the

primary Warehouse Proxy agent is unavailable. However, this facility does

not provide load balancing or an automatic switch-back to the original

Warehouse Proxy agent.

Determining which Warehouse Proxy agent will act for which agent is based on:

򐂰 For an agent: which TEMS does it report to

򐂰 For a Warehouse Proxy agent: the list of TEMS it is related to for

warehousing purposes

The second relationship is set by the KHD_WAREHOUSE_TEMS_LIST

environment variable in the Warehouse Proxy agent environment file.

KHD_WAREHOUSE_TEMS_LIST is a space-separated, semi-colon-separated,

or comma-separated list of TEMS names.

The primary Warehouse Proxy agent for all agents reporting to a given TEMS is

the Warehouse Proxy agent which includes the name of this TEMS in its

KHD_WAREHOUSE_TEMS_LIST.

A Warehouse Proxy agent without any KHD_WAREHOUSE_TEMS_LIST

variable set, or with a variable containing the string '*ANY' serves automatically

all the agents that do not have a primary Warehouse Proxy agent. In this case, it

is known as the default Warehouse Proxy agent for all agents.

A default Warehouse Proxy agent should be started last of all the Warehouse

Proxy agents, so that agents use their primary Warehouse Proxy agent if it is

available.

The relationships indicating which Warehouse Proxy agent is acting for which

agent are stored in the hub monitoring server. This is why all Warehouse Proxy