If you are using MSCS clusters, your DB2 instance requires additional planning with regards to daily operation, database deployment, and database configuration. For DB2 to execute transparently on any MSCS node, additional administrative tasks must be performed. All DB2 dependent operating system resources must be available on all MSCS nodes. Some of these operating system resources fall outside the scope of MSCS. That is, they cannot be defined as an MSCS resource. You must ensure that each system is configured such that the same operating system resources are available on all MSCS nodes. The sections that follow describe the additional work that must be done.
You must start and stop DB2 resources from the Cluster Administrator tool. Several mechanisms are available to start a DB2 instance, such as the db2start command, and the Services option from the Control Panel. However, if DB2 is not started from the Cluster Administrator, the MSCS software will not be aware of the state of the DB2 instance. If a DB2 instance is started using the Cluster Administrator, and stopped using the db2stop command, the MSCS software will interpret the db2stop command as a software failure, and attempt to restart DB2. (The current MSCS interfaces do not support notification of a resource state.)
Similarly, if you use db2start to start a DB2 instance, MSCS cannot detect that the resource is online; if a database server fails, MSCS will not bring the DB2 resource online on the failover machine in the cluster.
Three operations can be applied to a DB2 instance:
You can run scripts both before and after a DB2 resource is brought online. These scripts must reside in the instance profile directory that is specified for the DB2INSTPROF environment variable. This directory is the directory path that is specified by the "-p" parameter of the db2icrt command. You can obtain this value by issuing the following command:
db2set -i:instance_name DB2INSTPROF
This file path must be on a clustered disk, so that the instance directory is available on all cluster nodes.
These script files are not required, and are only run if they are found in the instance directory. They are launched by the MSCS Cluster Service in the background. The script files must redirect standard output to capture any information returned from commands within the script files. The output is not displayed to the screen.
In a partitioned database environment, by default, the same script will be used by every database partition server in the instance. If you need to distinguish among the different database partition servers in the instance, use different assignments of the DB2NODE environment variable to target specific node numbers (for example, use the IF statement in the db2cpre.bat and db2cpost.bat files).
If you want to run a script before you bring a DB2 resource online, the script must be named db2cpre.bat. DB2 calls functions that will launch this batch file from the Windows NT command line processor (CLP) and wait for the CLP to complete execution before the DB2 resource is brought online. You can use this batch file for tasks such as modifying the DB2 database manager configuration. You may want to change some database manager parameter values if the failover system is constrained, and you must reduce the system resources consumed by DB2.
The commands placed in the db2cpre.bat script should execute synchronously. Otherwise, the DB2 resource may be brought online before all tasks in the script are completed, which may result in unexpected behavior. Specifically, db2cmd should not be invoked in the db2cpre.bat script, because it, in turn, launches another command processor, which will run DB2 commands asynchronously to the db2cmd program.
If you want to use DB2 CLP commands in the db2cpre.bat script, the commands should be placed in a file and run as a CLP batch file from within a program that initializes the DB2 environment for the DB2 command line processor, and then waits for the completion of the DB2 command line processor. For example:
#include <windows.h>
int WINAPI DB2SetCLPEnv_api(DWORD pid);
void main ( int argc, char *argv [ ] )
{
STARTUPINFO startInfo = {0};
PROCESS_INFORMATION pidInfo = {0};
char title [32] = "Run Synchronously";
char runCmd [64] =
"DB2 -z c:\\run.out -tvf c:\\run.clp";
/* Invoke API to set up a CLP Environment */
if ( DB2SetCLPEnv_api (GetCurrentProcessId ()) == 0 ) (1)
{
startInfo.cb = sizeof(STARTUPINFO);
startInfo.lpReserved = NULL;
startInfo.lpTitle = title;
startInfo.lpDesktop = NULL;
startInfo.dwX = 0;
startInfo.dwY = 0;
startInfo.dwXSize = 0;
startInfo.dwYSize = 0;
startInfo.dwFlags = 0L;
startInfo.wShowWindow = SW_HIDE;
startInfo.lpReserved2 = NULL;
startInfo.cbReserved2 = 0;
if ( CreateProcessA( NULL,
runCmd, (2)
NULL,
NULL,
FALSE,
NORMAL_PRIORITY_CLASS CREATE_NEW_CONSOLE,
NULL,
NULL,
&startInfo,
&pidInfo ) )
{
WaitForSingleObject (pidInfo.hProcess, INFINITE);
CloseHandle (pidInfo.hProcess);
CloseHandle (pidInfo.hThread);
}
}
return;
}
A sample program called db2clpex.exe can be found in the MISC subdirectory of the DB2 install path. This executable is similar to the example provided, but accepts the DB2 CLP command as a command line argument. If you want to use this sample program, copy it to the BIN subdirectory. You can use this executable in the db2cpre.bat script as follows (INSTHOME is the instance directory):
db2clpex "DB2 -Z INSTHOME\pre.log -tvf INSTHOME\pre.clp"
All DB2 ATTACH commands or CONNECT statements should explicitly specify a user; otherwise, they will be executed under the user account associated with the cluster service. CLP scripts should also complete with the TERMINATE command to end the CLP background process.
Following is an example of a db2cpre.bat file:
db2cpre.bat : (1) ------------------------ db2clpex "db2 -z INSTHOME\pre-%DB2NODE%.log -tvf INSTHOME\pre.clp" (2) - (5) ------------------------ PRE.CLP (6) ------------------------ update dbm cfg using MAXAGENTS 200; get dbm cfg; terminate; ------------------------
If you want to run a script after you bring a DB2 resource online, it must be named db2cpost.bat. The script will be run asynchronously from MSCS after the DB2 resource has been successfully brought online. The db2cmd command can be used in this script to execute DB2 CLP script files. Use the "-c" parameter of the db2cmd command to specify that the utility should close all windows on completion of the task. For example:
db2cmd -c db2 -tvf mycmds.clp
The "-c" parameter must be the first argument to the db2cmd command, because it prevents orphaned command processors in the background.
The db2cpost.bat script is useful if you want to perform database activities immediately after the DB2 resource fails over and becomes active. For example, you can restart or activate databases in the instance so that they are primed for user access.
Following is an example of a db2cpost.bat script:
db2cpost.bat (1) ------------------------ db2cmd -c db2 -z INSTHOME\post-%DB2NODE%.log -tvf INSTHOME\post.clp (2) - (4) ------------------------ POST.CLP (5) ------------------------ restart database SAMPLE; connect reset; activate database SAMPLE; terminate; ------------------------
When you create a database, ensure that the database path refers to a share disk. This allows the database to be seen on all MSCS nodes. All logs and other database files must also refer to clustered disks for DB2 to failover successfully. If you do not perform these steps, a DB2 system failure will occur, because it will seem to DB2 that files have been deleted or are unavailable.
Ensure also that the database manager and database configuration parameters are set so that the amount of system resources consumed by DB2 is supported on either MSCS node. The autorestart database configuration parameter should be set to ON, so that the first database connection on failover will bring the database to a consistent state. (The default setting for autorestart is ON.) The database can also be brought to a ready state by using the db2cpost.bat script to restart and activate the database. This method is preferred, because there will be no dependency on autorestart, and the database is brought to a ready state independent of a user connection request.
DB2 relies on Windows NT for user authentication and group support. For a DB2 instance to fail over from one MSCS node to another in a seamless fashion, each MSCS node must have access to the same Windows NT security databases. You can achieve this by using Windows NT Domain Security.
Define all DB2 users and groups in a Domain Security database. The MSCS nodes must be members of this Domain, or the Domain must be a Trusted Domain. DB2 will then use the Domain Security database for authentication and group support, independent of the MSCS node on which DB2 is running.
If you are using local accounts, the accounts must be replicated on each MSCS node. This approach is not recommended, because it is error prone and requires dual maintenance.
DCE Security is also a supported authentication mode, if all MSCS nodes are clients in the same DCE cell.
You should associate the MSCS service with a user account that follows DB2 naming conventions. This allows the MSCS service to perform actions against DB2 that may be required in the db2cpre.bat and db2cpost.bat scripts.
For more information about Windows NT user and group support, see User Authentication with DB2 for Windows NT .
DB2 supports two LAN protocols in an MSCS Environment:
TCP/IP is supported because it is a supported cluster resource type. To enable DB2 to use TCP/IP as a communications protocol for a partitioned database system, create an IP Address resource and place it in the same group as the DB2 resource that represents the database partition server that you want to use as a coordinator node for remote applications. Then create a dependency, using the Cluster Administrator tool, to ensure that the IP resource is online before the DB2 resource is started. DB2 clients can then catalog TCP/IP node directory entries to use this TCP/IP address.
The TCP/IP port associated with the svcename database manager configuration parameter must be reserved for use by the DB2 instance on all machines that participate in the instance. The service name associated with the port number must also be the same in the services file on all machines.
Although NetBIOS is not a supported cluster resource, you can use NetBIOS as a LAN protocol, because the protocol ensures that NetBIOS names are unique on the LAN. When DB2 registers a NetBIOS name, NetBIOS ensures that the name is not in use on the LAN. In a failover scenario, when DB2 is moved from one system to another, the nname used by DB2 will be deregistered from one partner machine in the MSCS cluster and registered on the other machine.
DB2 NetBIOS support uses NetBIOS Frames (NBF). This protocol stack can be associated with different logical adapter numbers (LANA). To ensure consistent NetBIOS access to the server, the LANA associated with the NBF protocol stack should be the same on all clustered nodes. You can configure this by using the Networks option from the Control Panel. You should associate NBF with LANA 0, because this is the default setting expected by DB2.
DB2 uses the system time to time stamp certain operations. All MSCS nodes that participate in DB2 failover must have the system time zone and system time synchronized to ensure that DB2 behaves consistently on all machines.
Set the system time zone using the Date/Time option from the Control Panel dialog. MSCS has a time service that synchronizes the date and time when the MSCS nodes join to form a cluster. The time service, however, only synchronizes the time every 12 hours, which may result in problems if the time is changed on one system, and DB2 fails over before the time is synchronized.
If the time is changed on one of the MSCS cluster nodes, it should be manually synchronized on the other cluster nodes using the command:
net time /set /y \\remote_node
Where remote_node is the machine name of the cluster node.
The DB2 Administration Server is (optionally) created during the installation of DB2 Universal Database. It is not a partitioned database system. The Control Center uses the services provided by the Administration Server to administer DB2 instances and databases.
In a partitioned database system, a DB2 instance can reside on multiple MSCS nodes. This implies that a DB2 instance must be cataloged on multiple systems under the Control Center so that the instance remains accessible, regardless of the MSCS node on which the DB2 instance is active.
The Administration Server instance directory is not shared. You must mirror all user-defined files in the Administration Server directory to all MSCS nodes to provide the same level of administration to all MSCS nodes. Specifically, you must make user scripts and scheduled executables available on all nodes. You must also ensure that scheduled activities are scheduled on all machines in an MSCS cluster.
Alternatively, instead of duplicating the Administration Server on all machines, you may want to have the Administration Server fail over. For the purposes of the following example, assume that you have two MSCS nodes in the cluster, and that they are called MACH0 and MACH1. MACH0 has access to a cluster disk that will be used by the Administration Server. Assume also that both MACH0 and MACH1 have an Administration Server. You would perform the following steps to make the Administration Server highly available:
# # db2mscs.admin for Administration Server # run db2mscs -f:db2mscs.admin # DB2_INSTANCE=DB2DAS00 CLUSTER_NAME=CLUSTERA DB2_LOGON_USERNAME=db2admin DB2_LOGON_PASSWORD=db2admin # put Administration server in the same group as DB2 Node 0 GROUP_NAME=DB2NODE0 (1) DISK_NAME=DISK E: INSTPROF_DISK=DISK E: IP_NAME= IP Address for Administration Server IP_ADDRESS=9.9.9.8 IP_SUBNET=255.255.255.0 IP_NETWORK=Ethernet
db2set -g db2adminserver=DB2DAS00
When the Administration Server is enabled for failover, all remote access should use an MSCS IP resource for communicating with the Administration Server. The Administration Server will now have the following properties:
When you run DB2 in an MSCS environment: