Administration Guide

Setting Up Failover Support for a Database System

To set up Sun Cluster 2.1, perform the following steps:

Ensure that your system meets the requirements detailed in Preliminary Requirements.
Ensure that Sun Cluster 2.1 is installed properly.
Create the logical hosts which that will host the database partitions.
Create the logical host filesystems, and filesystems for SMS table spaces.
Install DB2 on each machine in the cluster (you can use cconsole or ctelnet, which come with Sun Cluster 2.1).
For mutual partition failover, set up HA-NFS either locally or remotely on a separate cluster to export the highly available instance's home directory.
On one machine only, create an instance on the HA-NFS filesystem, while ensuring that the user for the instance is created with the same uid on the other machines in the cluster. Also ensure that the groups and services for the instance are also created on the other machines in the cluster.
Run the hadb2eee_addinst script as root to set up your HA instance or configure the instance manually. The hadb2eee_addinst script is provided as an example on how an instance may be set up. The hadb2eee_addinst script does the following:
- Creates the .rhost file in the specified instance owner's home directory.
- Creates the db2nodes.cfg file for the instance.
- Creates the ha-db2eee.cfg file which binds database partitions to a logical host.
- Sets up symbolic links from the default database path (which is specified by the dftdbpath configuration parameter) to the correct logical host filesystem for a database partition.
- Adds a line for the instance in the /var/db2/v5/db2tabeee file.
- Tries to run non-interactively on the other machines in the cluster.
Run hadb2start to start the high availability environment

Choosing a Failover Configuration

To choose a failover configuration, perform the following steps:

Set up the machines to use either a hot standby or mutual takeover configuration. For a hot standby configuration, use one logical host. For a mutual takeover, use two or more logical hosts.
Decide on the amount of disk space that is required for each logical host and its resources, such as raw devices or SMS table space containers. Whether you use SMS or DMS (raw devices) table spaces, any disks belonging to a logical host must be included in its disk groups.

Table space considerations
You must decide on the type of table space that you want to use. If you want to use SMS table spaces, you must set them up using disks from the disk groups that belong to a logical host. In addition, you must include the filesystem in the vfstab for the logical host. Refer to the Sun Cluster 2.1 documentation for information about how to add a file system to a logical host.
There are benefits and costs associated with using either SMS or DMS table spaces. For example, SMS table spaces reside on file systems that must be file-system checked before they are mounted. This can add a considerable amount of overhead when failover occurs, and can result in the Sun Cluster 2.1 software timing out. If you use SMS table spaces, ensure that they are journaled files systems, which require less time to check after a failover.
DMS table spaces do not have to be file-system checked during failover, which can reduce the failover time for the high availability scripts.
You should remember that, for both SMS and DMS table spaces, committed transactions that are written to the logs will be applied to the database during crash recovery after the database server fails over.

Preliminary Requirements

Any logical host that you want in a cluster must have the following directories available:

/LOGICAL_HOST: Is the name of the logical host that runs the partition
/LOGICAL_HOST/home: Is where the home directories reside
/LOGICAL_HOST/disks: Is where the SMS table spaces reside for the database partitions

For example:

   /log0
   /log0/home/db2eee
   /log0/disks/db2eee

Where log0 is the logical host and db2eee is the highly available instance.

Scripts and Programs

All of the following scripts are in the directory /opt/IBMdb2/V5.0/ha/UDB-EEE_SC2.x/bin. Included are:

hadb2eee_addinst: The sample instance setup script
hadb2eee_reg: Registers DB2 Enterprise - Extended Edition for high availability
hadb2eee_startnet: Script that starts partitions for a logical host. This script is run automatically by Sun Cluster 2.1. You should not run this script manually.
hadb2eee_stopnet: Script that stops partitions for a logical host. This script is run automatically by Sun Cluster 2.1. You should not run this script manually.
hadb2eee_unreg: Unregisters DB2 Enterprise - Extended Edition for high availability
hadb2stat: Shows the current status of DB2 Enterprise - Extended Edition
hadb2start: Starts DB2 in the highly available environment.
hadb2stop: Stops DB2 in the highly available environment.

The hadb2eee_startnet and hadb2eee_stopnet scripts are used during a failover. The hadb2eee_startnet script starts partitions on a physical machine, while hadb2eee_stopnet stops partitions on a physical machine. Both the start and stop scripts read the /var/db2/v5/db2tabeee configuration file to find out which DB2 instances are highly available. See Enabling Failover for an Instance for information about this file.

Creating a DB2 Instance

Refer to the DB2 Enterprise - Extended Edition for UNIX Quick Beginnings for information about creating an instance.

Registering the DB2 Resource with Sun Cluster 2.1

If you are using local HA-NFS for your cluster, you must register and set up HA-NFS before HA DB2 EEE. The hadb2eee_reg script may look something like this:

# Make sure you register hanfs with every logical node even though only
# one will use it. This is to fix a dependency issue with SC2.x.
#
 
TIMEOUT=600
STARTUP=1
#DEPONNFS=
DEPONNFS="-d nfs"
 
# Register HA-NFS
#
#hareg -s -r nfs
#hareg -y nfs
 
hareg -r hadb2eee -b /opt/IBMdb2/V5.0/ha/UDB-EEE_SC2.x/bin/ -m START=hadb2eee_st
art,START_NET=hadb2eee_startnet,STOP_NET=hadb2eee_stopnet,ABORT_NET=hadb2eee_abo
rtnet -t START_NET=$TIMEOUT,STOP_NET=$TIMEOUT $DEPONNFS
 
if [[ STARTUP -eq 1 ]]
then
  hareg -y hadb2eee
fi

Where:

TIMEOUT: Is the timeout for the Sun Cluster agent to start and stop DB2.
STARTUP: Specifies whether to start the high availability environment after registering HA DB2 EEE.
DEPONNFS: Set this to an empty string if you are using a remote HA-NFS server. If you are using a local HA-NFS server, ensure that this is set to -d nfs, and that the lines that register HA-NFS are uncommented.

Enabling Failover for an Instance

To enable an instance for failover, you create an entry for it in the /var/db2/v5/db2tabeee file. This file must be kept consistent across all the machines in the cluster. Entries in this file are in the form:

   TYPE INSTANCE NFS_HOST ON HA-NFS_DIR LOCAL_MOUNT_POINT

Where:

TYPE

Is the type of instance. The value can be one of the following:

DATA to indicate a database instance.
ADMIN to indicate an administration server instance.

INSTANCE

Is the user name of the instance owner.

NFS_HOST

Is the logical host which is hosting the HA-NFS filesystem.

ON/OFF

Specifies whether the instance is highly available (ON) or not (OFF).

HA-NFS_DIR

The directory on the HA-NFS host to mount.

LOCAL_MOUNT_POINT

The local mount point for the HA-NFS.

An example might be:

   DATA db2eee sphere ON /log0/home /export/ha_home

In this example, the instance owner's home directory should be placed under /export/ha_home.

Binding Database Partition Servers to a Logical Host

You use the file called $INSTHOME/sqllib/hadb2-eee.cfg to bind database partitions to a logical host. Bind, in this context, means that the file ensures that the partitions follow the logical hosts around the cluster, starting on the machine in the cluster that hosts the logical host. Entries in this file are in the form:

   NODE: log0  0
   NODE: log0 10
   NODE: log0 12
   NODE: log1 33
   NODE: log1 45
   NODE: log1 59

In this example, logical host log0 is responsible for partitions 0, 10, and 12, while logical host log1 is responsible for partitions 33, 45, and 59. These logical hosts are responsible for both starting and stopping the partitions during a failover situation.
Note: There must be a one-to-one relationship between the partitions in this file and the db2nodes.cfg file.

How Failover Processing Works

When a failover occurs, the hadb2eee_startnet and hadb2eee_stopnet programs read the /var/db2/v5/db2tabeee file to find out which DB2 instances are highly available. Then for each highly available instance, they read the configuration file $INSTHOME/sqllib/hadb2-eee.cfg, which binds partitions to logical hosts.

Information about the failover process is sent to the syslog using the facility set to LOG_USER and the priority set to LOG_ERR.

Setting Up a Hot Standby Configuration

To set up a hot standby configuration, bind all of the partitions to one logical host that is hosted by one of the servers in the cluster. When you finish, the $INSTHOME/sqllib/hadb2-eee.cfg file should resemble the following:

   NODE: log0  0
   NODE: log0 10
   NODE: log0 12
   NODE: log0 33
   NODE: log0 45
   NODE: log0 59

If the logical host log0 fails over, all the database partitions associated with it will fail over as well.

Setting Up a Mutual Takeover Configuration

To set up a mutual takeover configuration, bind the partitions to two or more logical hosts. When you finish, the $INSTHOME/sqllib/hadb2-eee.cfg file should resemble the following:

   NODE: log0  0
   NODE: log0 10
   NODE: log0 12
   NODE: log0 33
   NODE: log1 45
   NODE: log1 59

You do not need to set up a completely symmetric configuration. As the example shows, the logical host log0 supports more partitions than the logical host log1 (partitions 0, 10, 12 and 33 for logical host log0 versus partitions 45 and 59 for logical host log1). Because you do not have to implement a symmetric configuration, a mutual takeover configuration provides an amount of flexibility that will support any situation.

Starting and Stopping DB2

To start DB2 in a failover environment, use the hadb2start command. This command both enables the failover environment, and starts DB2.

If you want to stop DB2, use the hadb2stop command. This command both disables the failover environment and stops DB2.
Note: If you do not issue hadb2stop and you use db2stop, Sun Cluster 2.1 may assume that the DB2 instance needs to be failed over.

Running Scripts During a Failover

The /var/db2/v5/failover.eee script runs automatically when a failover occurs. You can use this script to send email (for example, to notify support staff) of the failover situation. You should keep the commands in this script to a minimum, because it runs before DB2 is started. Depending on whether DB2 is starting or stopping, the following scripts will also run (if they are available) for each instance.
Note: You must create the $INSTHOME/sqllib/ha directory and create these scripts to be executables. You should ensure that you have backup copies of these scripts.

$INSTHOME/sqllib/ha/pre_db2starteee
This file takes as an argument the number of logical hosts that are currently running on the failover machine. If this script exists, it runs immediately before the db2start command.
$INSTHOME/sqllib/ha/pre_db2stopeee
This file takes as an argument the number of logical hosts that are currently running on the failover machine. If this script exists, it runs immediately before the db2stop command.
Note: This script may not be run if the machine crashes.
$INSTHOME/sqllib/ha/post_failovereee
This file runs just after a failover and is used to such tasks as restart databases.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]