IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Installation Guides > Installation Guide > Pre-deployment phase

IBM Tivoli Monitoring, Version 6.3 Fix Pack 2


Multi-hub environments

Large users who go beyond the limits of a single hub monitoring server environment must consider additional factors. Tivoli Monitoring V6.3 has been tested with environments of up to 20000 agents. Some users need multiple hub monitoring servers to handle the tens of thousands of agents in their environment.

Following are some considerations to take into account when deploying multiple hub monitoring servers.


Sharing a warehouse database

You can share a single warehouse database with multiple hub monitoring servers, but there are additional considerations when choosing this deployment option. First, you must take into account scalability of the Warehouse Proxy and Summarization and Pruning Agents. Use the Warehouse load projection spreadsheet, which can be found in the IBM Integrated Service Management Library by searching for "warehouse load projections" or the navigation code "1TW10TM1Y".

With multiple hubs and up to 20000 agents, you increase the likelihood of exceeding the capacity of the Warehouse. Be aware of how much data you are collecting to ensure that you do not exceed the capacity of the warehouse database. To get an idea of the capacity of the Summarization Pruning agent with your warehouse database, consider using the measurement approach.

In addition to scalability, there are specific deployment requirements when a warehouse database is shared between hub monitoring servers. First, you can run only one Summarization and Pruning Agent in only one of the two monitoring server environments. The single Summarization and Pruning Agent is responsible for summarizing and pruning the data for all of the data in the Warehouse. The summarization and pruning configuration settings are maintained by the portal server specified in the Summarization and Pruning Agent configuration dialog.

Due to the complexity and potential scalability issues of sharing a warehouse database across multiple hub monitoring servers, you might want to maintain multiple warehouse databases. To build reports across the databases, use Federation capabilities or create a data mart that merges that content from multiple warehouse databases.

You cannot set up different summarization and pruning schedules for each of the hub monitoring server environments. In addition, you must also ensure that the hub with the Summarization and Pruning Agent is patched and maintained so that it is a superset of the two monitoring servers. If you install the database agents in one hub, then install the application support for the database agents on the hub monitoring server and portal server in the hub environment with the Summarization and Pruning Agent. If you install a fix pack on one hub, then you must ensure that it is also installed on the hub with the Summarization and Pruning Agent, which ensures that the Summarization and Pruning Agent is aware of all attribute groups and attributes that can be collected.


Sharing customization

When using multiple hubs, most customization can be shared between the two hub environments. Customization includes situations, workflow policies, workspaces, and managed systems lists. There are tacmd CLIs commands that can be used to perform bulk imports and exports of situations, workflow policies, and workspaces. For details on the tacmd CLIs, see the Command Reference. Most of the customization can be cleanly exported from one monitoring server environment to another monitoring server environment using tools that are identified in Maintaining an efficient monitoring environment.


Dashboard environments and Authorization Policy Server

In the V6.3 release of IBM Tivoli Monitoring, set up a separate dashboard environment for each Hub monitoring server (unless it is a standby Hub for the Hot Standby feature). A dashboard environment consists of the Dashboard Application Services Hub and monitoring applications such as...

A dashboard environment can also include the Authorization Policy Server and the tivcmd CLI. If all of your authorization policies are going to be different for each dashboard environment, or each environment is going to have a different set of policy administrators: you should install the Authorization Policy Server with the Dashboard Application Services Hub in each of your dashboard environments. However, if some of your authorization policies are common across monitoring domains, you can use a single Authorization Policy Server instance to manage the policies for multiple domains. (A domain consists of the Hub monitoring server, its standby Hub monitoring server, remote monitoring servers, the portal server, a Dashboard Application Services Hub, and monitoring agents.) For this scenario, install the Authorization Policy Server on the Dashboard Application Services Hub for one of your domains and use the tivcmd CLI to create authorization policies for all of your domains using this single instance of the policy server. (As an alternative, you can install the Authorization Policy Server with a Dashboard Application Services Hub that is used solely for the purpose of creating authorization policies.) Configure the portal servers for all of your domains to retrieve authorization policies from the single instance of the Authorization Policy Server when you enable authorization policies. All of your Dashboard Application Services Hubs and portal servers must be configured to use the same LDAP user repository so that the Authorization Policy Server can validate that roles are being assigned to users and user groups in this common repository.

If you have some authorization policies that should be domain specific, you can specify the domain name when using the tivcmd CLI to create a permission. By default, the provider ID of the dashboard data provider is used as the domain name and its format is...

You can customize a domain override value when you configure the portal server. If you do not specify a domain name when you create a permission then the permission applies to all domains that the authorization policies are distributed to.

See the IBM Tivoli Monitoring Administrator's Guide chapter for authorization policies and the Command Reference for more information on creating domain specific authorization policies.


Parent topic:

Pre-deployment phase

+

Search Tips   |   Advanced Search