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.
- 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.
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 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
- 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
|Service Name||Port Number||Protocols|
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.