IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Installation Guides > High Availability Guide for Distributed Systems > Configure for high availability and disaster recovery
IBM Tivoli Monitoring, Version 6.3 Fix Pack 2
Configure for portal server high availability and disaster recovery
It is important to have multiple portal servers available in case of a hardware failure. While the hub monitoring server tracks the state of the Tivoli Monitoring environment it is not as critical to ensure that data is synchronized in real-time between multiple portal servers. The primary data that you want to protect is the customization that is stored in the portal server database, such as user-defined workspaces. Because this data does not change frequently, a good backup and restore strategy ensures a highly available environment.
You can employ a variety of configurations to achieve both high availability and disaster recovery with the portal server, depending on the amount of hardware you are willing to dedicate to your solution:
OS Cluster
Many users set up an OS Cluster for their portal server. Depending on the clustering software used, the cluster can be set up across a WAN to achieve disaster recovery. For detailed information on setting up the monitoring server and portal server in an OS Cluster, see the sections that follow.
Cold backup
Some smaller users do not want to dedicate CPU cycles and memory to a live backup portal server. If that is the case in your environment, install a second portal server on another computer that serves as a production server. The backup portal server is typically shut down so that it does not use any CPU or memory. If the primary portal server goes down, the cold backup can be brought online. The key for a cold backup portal server is to periodically export the portal server database content and import it into the cold backup. In addition, ensure that the cold backup portal server is patched with the same software levels as the primary portal server and the same application support.
Select one of several methods for exporting and importing the portal server database:
- Use RDBMS backup utilities such as DB2’s db2 backup and db2 restore commands
- Use the migrate-export and migrate-import command provided by the Tivoli Monitoring product
- Use a tool like the Tivoli System Automation for Multiplatforms to automate the process of backing up the resources.
If the various portal server databases are not running on the same OS version, then the RDBMS backup and restore utilities will probably not work. In those cases, use the Tivoli Monitoring migrate-export and migrate-import commands as described in the "Replicating the Tivoli Enterprise Portal Server database" chapter of the IBM Tivoli Monitoring Administrator's Guide.
Multiple active portal servers
As discussed previously, some users choose to implement a master read-write portal server and one or more read-only portal servers. The strategy for backup and restore is to have one master Tivoli Enterprise Portal Server database where all customization is done. Then, periodically export the content from the "master" portal server and import the content into any other portal server. The import replaces the Tivoli Monitoring content in the portal server database, so be aware that any customization made in the secondary portal server environments will be overwritten during the import.
The export and import of the portal server database can be done in two ways:
- Use RDBMS backup utilities such as DB2’s db2 backup and db2 restore commands
- Use the migrate-export and migrate-import command provided by the Tivoli Monitoring product
If the various portal server databases are not running on the same OS version, then the RDBMS backup and restore utilities will probably not work. In those cases, use the Tivoli Monitoring migrate-export and migrate-import commands as described in the "Replicating the Tivoli Enterprise Portal Server database" chapter of the IBM Tivoli Monitoring Administrator's Guide. Any Tivoli Enterprise Portal client users and tacmd CLI users that perform customizations must connect to the "master" portal server. All other portal client users can connect to any of the other portal servers.
You can use a HTTP load balancing server between IBM Dashboard Application Services Hub and multiple active portal servers for a high availability dashboard environment. See "Configuring load balancing for a high availability dashboard environment" in the IBM Tivoli Monitoring Administrator's Guide.
Parent topic:
Configure for high availability and disaster recovery