Helper scripts for HA

TSLM provides helper scripts that you can use for a TSLM High Availability environment configured with IBM® PowerHA® and DB2® High Availability Disaster Recovery (HADR). These helper scripts for HA are included on the distribution DVD in the /tslm/scripts/ha directory.

Overview of an example configuration for a TSLM High Availability environment

Before you can use the helper scripts for HA that come with TSLM, you must modify them for your particular HA environment. An example configuration that can use these scripts is shown in Figure 1; the example configuration is for a mutual-takeover, dual-node implementation.

A sample High Availability configuration with PowerHA and HADR — Figure 1. Example of a High Availability configuration with PowerHA and HADR

Note: You must configure each control path (that is, each device file `/dev/smcX`) to be assigned to the identical library on both nodes. In the example configuration, the PowerHA cluster service must be manually started on both nodes, and must be started on the node that has the HADR Primary role first.

The example cluster shown in Figure 1 is configured with the non-concurrent resource group tslm_rg and the concurrent resource group db2_rg (a non-concurrent resource group is also known as a rotating resource group).

The non-concurrent resource group tslm_rg starts only on the primary node (that is, on the node where the cluster service is started first). The control of this resource group moves onto the standby node when a takeover event occurs (for example, when the primary node is down or when the cluster service stops with takeover on the primary node). Therefore, this resource group contains application controllers that handle takeover for database and application services.

Example configuration for the TSLM resource group tslm_rg and the TSLM and HADR application controllers tslm_controller and hadr_controller

In the example configuration, the following application controllers run the helper scripts:

tslm_controller - an application controller for TSLM control.
hadr_controller - an application controller for HADR control.

Note: You must associate the service addresses with the non-concurrent resource group.

Table 1, Table 2, and Table 3 show example configurations for the resource group tslm_rg and the application controllers tslm_controller and hadr_controller .

Table 1. Example configuration for resource group "tslm_rg"
Configuration field	Value
Resource Group Name	tslm_rg
Startup Policy	Online Using Distribution Policy
Fallover Policy	Fallover To Next Priority Node In The List
Fallback Policy	Never Fallback
Application Controllers	tslm_controller hadr_controller

Table 2. Example configuration for application controller "tslm_controller"
Configuration field	Value
Application Controller Name	tslm_controller
Start Script	/opt/IBM/ermm/ha/ha_tslm_start.ksh
Stop Script	/opt/IBM/ermm/ha/ha_tslm_stop.ksh
Application startup mode	background

Table 3. Example configuration for application controller "hadr_controller"
Configuration field	Value
Application Controller Name	hadr_controller
Start Script	/opt/IBM/ermm/ha/ha_hadr_start.ksh
Stop Script	/opt/IBM/ermm/ha/ha_hadr_stop.ksh
Application startup mode	background

Example configuration for the DB2 resource group db2_rg and the DB2 application controller db2_controller

The concurrent resource group db2_rg starts on both nodes at the cluster service startup. This resource group takes care of controlling DB2 services, and contains an application controller which starts and stops DB2 appropriately according to its HADR role and status. In this example, the following application controller that runs the helper script:

db2_controller - an application controller for DB2 control.

Table 4 and Table 5 show example configurations for the resource group db2_rg and the application controller db2_controller.

Table 4. Example configuration for resource group "db2_rg"
Configuration field	Value
Resource Group Name	db2_rg
Startup Policy	Online On All Available Nodes
Fallover Policy	Bring Offline (On Error Node Only)
Fallback Policy	Never Fallback
Application Controllers	db2_controller

Table 5. Example configuration for application controller "db2_controller"
Configuration field	Value
Application Controller Name	db2_controller
Start Script	/opt/IBM/ermm/ha/ha_db2_start.ksh
Stop Script	/opt/IBM/ermm/ha/ha_db2_stop.ksh
Application startup mode	background

Example configuration for the custom application monitor tslm_monitor

The example cluster shown in Figure 1 is also configured with a custom application monitor tslm_monitor, which periodically checks whether TSLM is running. This application monitor is associated with the application controller tslm_controller, which is shown in the example configuration for tslm_monitor in Table 6.

Table 6. Example configuration for custom application monitor "tslm_monitor"
Configuration field	Value
Monitor Name	tslm_monitor
Application Controller(s) to Monitor	tslm_controller
Monitor Mode	Long-running monitoring
Monitor Method	/opt/IBM/ermm/ha/tslm_monitor.ksh
Monitor Interval	60
Stabilization Interval	300¹
Action on Application Failure	fallover
Table notes: 1 - In this example, TSLM instances (Media Manager and Library Manager) are started on the primary node only when the HADR role on the primary node becomes “Primary”. The HADR role and status will not be determined unless the cluster services start up on both nodes. Therefore, you must configure the Stabilization Interval configuration setting to have a value that gives sufficient time to start up the cluster services on both nodes. Otherwise, this application monitor will start before TSLM service startup and might result in triggering a takeover.

Description of helper scripts for HA

Table 7 describes the helper scripts for HA that come with TSLM.

Table 7. Helper scripts for High Availability configuration with PowerHA and HADR
Script name	Description
`env`	Sets common settings such as environment variables. This script is called from other scripts.
`ha_db2_start.ksh`	Starts the DB2 service with the appropriate HADR role. This script is called from the application controller db2_controller.
`ha_db2_stop.ksh`	Stops the DB2 service and leaves the HADR role unchanged. This script is called from the application controller db2_controller.
`ha_hadr_start.ksh`	Triggers an HADR takeover when a takeover event occurs (for example, when the primary node is down or when TSLM on the primary node is down). This script is called from the application controller hadr_controller.
`ha_hadr_stop.ksh`	Triggers an HADR takeover when the cluster service stops with takeover option on the primary node. This script is called from the application controller hadr_controller.
`ha_tslm_start.ksh`	Starts the TSLM Media Manager and Library Manager instances by starting the script tslm_start.ksh in background mode. This script is called from the application controller tslm_controller.
`ha_tslm_stop.ksh`	Stops the TSLM Media Manager and Library Manager instances. This script is called from the application controller tslm_controller.
`hadr_monitor.ksh`	Returns the current HADR configuration role, HADR role, and HADR status for the node from which the script is run. This script is called from other scripts as a tool.
`tslm_monitor.ksh`	Monitors whether TSLM is working by checking the output of ”ermmtool lssys –s \| head -2”. If the check fails three times in a row, the script returns a "TSLM is not working" status. This script is called from custom application monitor tslm_monitor.
`tslm_start.ksh`	Starts the TSLM Media Manager and Library Manager instances when the current HADR role on the node becomes “Primary". This script is started in background mode from the script ha_tslm_start.ksh.

These scripts are designed to be installed in one directory that is set to /opt/IBM/ermm/ha by default. If you choose to change the directory, before you run any scripts you must modify the following line in all the scripts:

SCRIPT_DIR="/opt/IBM/ermm/ha"

The log files for these scripts are created as "

/opt/IBM/ermm/ha/log/<script
file name>.log

". If you change the SCRIPT_DIR setting, the log path will change accordingly.