IBM Tivoli System Automation for Multiplatforms (Linux and AIX)

IBM® Tivoli® System Automation for Multiplatforms (SA MP) is cluster managing software that facilitates automatic switching of users, applications, and data from one database system to another in a cluster. Tivoli SA MP automates control of IT resources such as processes, file systems, and IP addresses.

Tivoli SA MP provides a framework to automatically manage the availability of what are known as resources. Here are some examples of resources:
  • Any piece of software for which start, monitor, and stop scripts can be written to control
  • Any network interface card (NIC) to which Tivoli SA MP was granted access. That is, Tivoli SA MP manages the availability of any IP address that a user wants to use by floating that IP address among NICs that it has access to. This is known as a floating or virtual IP address.

Db2 resources

In a single-partition Db2® environment, a single Db2 instance is running on a server. This Db2 instance has local access to data (its own executable image as well as databases owned by the instance). If this Db2 instance is made accessible to remote clients, an unused IP address may be assigned as a floating IP used to connect to the Db2 instance database(s).

The Db2 instance, the local data, and the IP address are all considered resources, which must be automated by Tivoli SA MP. Since these resources are closely related (for example, they collectively run on the same node at the same time), they are defined under a single resource group.

The entire resource group is collocated on one node in the cluster. In the case of a failover, the entire resource group is started on another node.

The following dependencies exist between the resources in the resource group:
  • The Db2 instance must be started after the local disk
  • The Db2 instance must be stopped before the local disk
  • The virtual IP address must be collocated with the Db2 instance

Disk storage

The Db2 database can use these resources for local data storage:
  • Raw disk (for example, /dev/sda1)
  • Logical volume that is managed by Logical Volume Manager (LVM)
  • File system (for example, ext3, jfs)

Db2 data can be stored either entirely on one or more raw disks, entirely on logical volumes, entirely on file systems, or on a mixture of all three. Any executables need to be on a file system of some sort.

Db2 database requirements for the virtual IP address

The Db2 database has no special requirements for the virtual IP address. It is not necessary to define a virtual IP address in order for the instance to be considered highly available. However, it is important to remember that the virtual IP address is the client's access point to the data, and as such, this address must be known by all database clients. In practice, it is recommended that this IP address be the one that is used by the clients in their CATALOG TCPIP NODE commands.

Setting up Tivoli SA MP with your Db2 environment

For detailed configuration information to help you set up SA MP to work with your Db2 environment, refer to Configuring a clustered environment using Db2 High Availability Instance Configuration Utility (db2haicu).

Tivoli SA MP Port usage information

Table 1. If firewall is set up on each host or in the network, following ports should be opened:
Service Name Port Number Protocols
cthats 12347 UDP
cthags 12348 UDP
rmc 657 UDP
rmc 657 TCP


The communication must be allowed for all communication groups. The RSCT lscomg command displays the CommunicationGroups (CG) formed by RSCT. These CGs are used for heartbeating to see if peer node is alive. If a communication ring fails then it is checked with other CGs if peer node is reachable.

You can see the member interfaces of a CG with

lscomg -i <CG1>

where <CG1> is the name of the communication group.