IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Installation Guides > High Availability Guide for Distributed Systems
IBM Tivoli Monitoring, Version 6.3 Fix Pack 2
Monitor functions and architecture
There are two primary technological approaches to configuring resiliency (also known as high availability) for the Tivoli monitoring platform components. One approach exploits common, commercially available, high-availability cluster manager software. Examples include:
- High-Availability Cluster Multiprocessing for pSeries on AIX systems (HACMP™)
- IBM Tivoli System Automation for Multiplatforms (SA-MP)
- Microsoft Cluster Server, from Microsoft (MSCS)
In the second approach, the hub Tivoli Enterprise Monitoring Server is resilient to specific failure scenarios. This alternative approach is also referred to as hot standby in Tivoli publications. These two approaches provide different resiliency and failover characteristics. Failover is the process of taking resource groups offline on one node and bringing them back on another node; the resource dependencies are respected.
The first approach requires the use of a high-availability cluster manager such as HACMP, IBM's SA-MP, or Microsoft's MSCS. Using this approach, you can configure all of the components of the monitoring platform for resiliency in the case of component failure. See the following chapters for a detailed description of how to create clusters with the Tivoli Monitoring components by using each of the cluster managers:
- Create clusters with Tivoli Monitoring components in an HACMP environment
- Create clusters with monitoring components in a System Automation for Multiplatforms environment
- Create clusters with Tivoli Monitoring components in a Microsoft Cluster Server environment
If you are primarily concerned with the availability of the hub Tivoli Enterprise Monitoring Server, the IBM Tivoli Monitoring platform provides the hot standby option. The hot standby option replicates selected state information between the hub monitoring server and a secondary hub monitoring server running in a listening standby mode; the secondary hub monitoring server monitors the active hub's heartbeat so that it can remain up-to-date with the hub’s environment information. In an appropriately configured environment, the secondary (that is, the backup) hub monitoring server takes over as the active hub monitoring server whenever the primary hub monitoring server fails. Hot standby operates without shared or replicated persistent storage between the two monitoring servers and does not require cluster manager software. However, hot standby addresses only the hub monitoring server component of the monitoring platform, and is therefore suited to users without stringent resiliency requirements on the other components of the monitoring platform. High availability and disaster recovery configuration are also possible when using hot standby. Additional strategies must be used to ensure high availability for other IBM Tivoli Monitoring components, including the Tivoli Enterprise Portal Server, the Warehouse Proxy Agent, and the Summarization and Pruning Agent.
The following three features are requirements for implementing high availability on z/OS systems:
- Sysplex environment
- Shared DASD
- Dynamic Virtual IP Address (DVIPA)
For more information about implementing high availability on z/OS systems, see Configure the Tivoli Enterprise Monitoring Server on z/OS.
- Monitor functions
- Monitor architecture
- High Availability considerations for the Tivoli Enterprise Monitoring Server
- IBM Tivoli Monitoring portal navigation