Installation Guide

IBM DB2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms

Target Audience ■ Technology Consultants ■ System Administrators

Document Version 1.00 - August 11, 2006

SAP AG Neurottstraße 16 69190 Walldorf Germany T +49/18 05/34 34 24 F +49/18 05/34 34 20 www.sap.com

© Copyright 2004 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their

respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP Library document classification: PUBLIC Disclaimer Some components of this product are based on Java™. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java™ Source Code delivered with this product is only to be used by SAP’s Support Services and may not be modified or altered in any way. Documentation in the SAP Service Marketplace You can find this documentation at the following Internet address: service.sap.com/instguides

Typographic Conventions Type Style Description

Example Text Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options.

Cross-references to other documentation

Example text Emphasized words or phrases in body text, graphic titles, and table titles

EXAMPLE TEXT Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE.

Example text Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools.

Example text Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.

<Example text> Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system.

EXAMPLE TEXT Keys on the keyboard, for example, F2 or ENTER.

Icons

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Additional icons are used in SAP Library documentation to help you identify different types of information at a glance. For more information, see Help on Help → General Information Classes and Information Classes for Business Information Warehouse on the first page of any version of SAP Library.

4 August 2006

Contents

1 Introduction .........................................................................................6 1.1 Reference Documentation..................................................................... 7 1.2 Naming Conventions ............................................................................. 9

2 Planning .............................................................................................10 2.1 Hardware Requirements ...................................................................... 10 2.2 Software Requirements ....................................................................... 11 2.3 Virtual Host Name and Virtual IP Address ......................................... 12

2.3.1 Reusing the Host Name and IP Address of a Single Database Server......................12 2.3.2 Setting Up a New Virtual Host Name and IP Address................................................14

3 Preparation ........................................................................................15 3.1 Setting Up File Systems ...................................................................... 15 3.2 Setting Up the ssh/rsh Connection..................................................... 16 3.3 Changing the Password of the SAP Connect User ........................... 18

4 Installation .........................................................................................19 4.1 Downloading the Latest DB2 9 Software and SA MP License.......... 19 4.2 Installing the Database Server ............................................................ 19 4.3 Setting Up the High Availability Cluster............................................. 20

4.3.1 Installing the SA MP Software ....................................................................................21 4.3.2 Installing the SA MP License ......................................................................................22 4.3.3 Setting Up the Cluster.................................................................................................22 4.3.4 Changing References to the Virtual Host Name or IP Address..................................25

5 Post-Installation Steps .....................................................................28 5.1 Checking the Cluster Setup ................................................................ 28 5.2 Checking the Cluster Failover............................................................. 30 5.3 Performing a Backup of the SA MP Core Policy................................ 31

6 Updating the Software ......................................................................32 6.1 Updating the Database Fix Paks......................................................... 32 6.2 Updating SA MP FixPaks..................................................................... 34

7 Uninstall .............................................................................................35 7.1 Uninstalling Cluster ............................................................................. 35 7.2 Uninstalling SA MP .............................................................................. 36 7.3 Deleting the Database Software.......................................................... 36

Appendix A - SA MP Policy for DB2...................................................37 A.1 Script sapdb2gen.sh ........................................................................... 37 A.2 File sapdb2policy.conf ........................................................................ 38 A.3 Script sapdb2policy.sh ....................................................................... 42

Appendix B - Syntax of SA MP Setup Scripts ..................................44 B.1 Script prereqSAM ................................................................................ 44

Migration to Version 7 of the IBM DB2 Universal Database for

August 2006 5

B.2 Script installSAM ................................................................................. 45 B.3 Script uninstallSAM............................................................................. 46

Appendix C - Diagnosis/Troubleshooting .........................................47 C.1 Troubleshooting Reference Documentation ..................................... 47 C.2 Requesting SAP Support .................................................................... 47 C.3 Symbol Resolution Failed for db2start on AIX.................................. 47 C.4 DB2 Immediately Stops After the db2start/startdb/startj2eedb Command.................................................................................................... 48 C.5 DB2 Immediately Starts After the db2stop/stopdb/stopj2eedb Command.................................................................................................... 49

6 August 2006

1 Introduction Purpose This document describes how to set up a high-availability (HA) solution for IBM DB2 for Linux, UNIX and Windows (version 8 and 9) using IBM Tivoli System Automation for Multiplatforms (SA MP) when your operating system is AIX or Linux.

SA MP is a high-availability cluster solution which provides several monitoring mechanisms to detect system failures and a set of rules to initiate the correct action without any user intervention. The set of rules is called a policy, which describes the relationships between applications or resources. This provides SA MP with extensive up-to-date information about the system landscape so that it can restart the resource on the current node or move the whole application to another cluster node.

IBM provides a free two-node license of SA MP for the IBM DB2 database server only. Additional licenses are required to set up the SAP central instance for HA.

Due to the database reconnect feature of SAP NetWeaver, a database server failure and a subsequent failover controlled by SA MP within the database cluster to another node is almost transparent to the clients. The running transactions of the work processes are terminated. The end users of transactions within the affected dialog processes get a message. SAP NetWeaver reconnects to the database server as soon as it is available again.

Example of Setup

DB instance: DB2 cluster using SA MP

Node 1 Host name: db2_sa_mp_1 IP: 17.2.10.1 OS: AIX 5.3 Network: en0

Node 2 Host name: db2_sa_mp_2 IP: 17.2.10.2 OS: AIX 5.3 Network: en0

Shared Disk (Storage Subsystem)

DB2 9 (software + database)

SAP NetWeaver

SAP GUI

Virtual host name: db2_sa_mp_cl Virtual-IP: 17.2.10.3

Central instance Dialog instance(s)

August 2006 7

The above figure shows a setup of two database servers that share the database software and the database itself on a shared disk. Both database servers have access to the shared disk but only one of them is running at any one time and is connected to the shared disk. The SAP NetWeaver instances are running on different machines. SAP NetWeaver only knows about the virtual host name or the virtual IP address of the database cluster. SA MP assigns the virtual IP address to the node where the DB2 software is currently running.

1.1 Reference Documentation The following section provides information about additional documentation that might be useful:

• SAP documentation

• SA MP documentation

• Reliable Scalable Cluster Technology (RSCT) documentation

Since SA MP is based on RSCT, make sure that you also refer to this documentation.

• Important SAP Notes

Before you start the installation, make sure that you read the latest version of SAP Note 960843. It contains the most recent information about the installation of SA MP, as well as corrections to this document.

SAP Documentation

Document URL

Installation Guide – SAP NetWeaver 2004s SR1 <ABAP; ABAP+Java; Java> on <OS>: IBM DB2 Universal Database for UNIX and Windows

service.sap.com/instguidesnw2004s Installation

Database Upgrade Guide – Migration to Version 9 of IBM DB2 for Linux, UNIX, and Windows

service.sap.com/instguides Other Documentation Database Upgrade DB2 UDB

8 August 2006

SA MP Documentation

Document URL

IBM Tivoli System Automation for Multiplatforms - home page

www.ibm.com/software/tivoli/products/sys-auto-linux/

IBM Tivoli System Automation for Multiplatforms – product manuals

publib.boulder.ibm.com/tividd/td/IBMTivoliSystemAutomationforMultiplatforms2.1.html

IBM Tivoli System Automation for Multiplatforms - Base Component User’s Guide

publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8210-06/en_US/PDF/HALGRE22.pdf

IBM Tivoli System Automation for Multiplatforms - Base Component Reference

publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8212-02/en_US/PDF/HALBCR02.pdf

IBM Tivoli System Automation for Multiplatforms - End-to-End Automation Management User’s Guide and Reference

publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8211-02/en_US/PDF/HALE2E02.pdf

RSCT Documentation

Document URL

IBM Reliable Scalable Cluster Technology (RSCT) - Diagnosis Guide

publib.boulder.ibm.com/epubs/pdf/bl5dia03.pdf

IBM Reliable Scalable Cluster Technology (RSCT) - Library

publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=/com.ibm.cluster.rsct.doc/rsctbooks.html

The following SAP Notes are referenced within this document. Make sure that you always have the most recent version of each SAP Note. You can find the SAP Notes in the SAP Service Marketplace at service.sap.com/notes.

SAP Notes

SAP Note Number Title

70856 DB2 specific actions when renaming DB host

816773 DB6: Installing an SAP OEM license

960843 DB6: Installation of System Automation for Multiplatforms

August 2006 9

1.2 Naming Conventions In this document, the following naming conventions apply:

Terminology

• IBM DB2 for Linux, UNIX, and Windows is referred to as DB2 9.

• IBM DB2 UDB for UNIX and Windows Version 8 is referred to as DB2 Version 8.

• IBM Tivoli System Automation for Multiplatforms is referred to as SA MP.

• IBM Reliable Scalable Cluster Technology is referred to as RSCT.

Variables

Variable Description

<DBSID> Name of the database in upper case

<dbsid> Name of the database in lower case

<SAPSID> System ID of the SAP system in upper case

<sapsid> System ID of the SAP system in lower case

<SID> If SAPSID and DBSID are the same this means SAPSID. In an MCOD (Multiple Components on One Database) environment the SAPSID and DBSID are most probably not equal. So SID refers to both of them in upper case.

<sid> If SAPSID and DBSID are the same, this means SAPSID. In an MCOD environment the SAPSID and DBSID are most probably not equal. So SID refers to both of them in lower case.

10 August 2006

2 Planning Make sure that you read the following sections:

• Hardware Requirements [page 10]

• Software Requirements [page 11]

• Virtual Hostname and Virtual IP Address [page 12]

2.1 Hardware Requirements To set up the DB2 server in an HA environment using the free two-node license of SA MP, the following hardware requirements must be met:

Requirement Type Requirement

Server hardware Two separate servers for the database.

Both servers must meet the DB2 requirements as described in the IBM documentation DB2 Installation Prerequisites for <OS>, which you can find at: www.ibm.com/software/data/db2/udb/sysreqs.html

Physical disks One shared disk, which you can mount from both database servers. No synchronization is required since the disk is mounted by only one server at a time. NFS is not supported.

We recommend that you use SAN (Storage Area Network).

Disk space 300 MB additional free disk space on each node within the HA cluster for the SA MP Software

Make sure that the directories /usr/sbin, /opt and /var have at least 100 MB of free disk space available.

We recommend that you use two identical machines for the cluster setup. Since the database manager configuration and the database registry are transferred during movement of DB2 from one node to the other, the configuration must suit both of them.

August 2006 11

2.2 Software Requirements The following software requirements must be met for the use of SA MP:

• Supported Operating Systems

IA3232-bit X86_64 64-bit

Power 64-bit

AIX 5.2 64 bit X

Requires C++ Runtime Library for AIX 8.0.0.4

Requires RSCT 2.3.9.1 Fix Pak IY83473

AIX 5.3 64 bit X

Requires C++ Runtime Library for AIX 8.0.0.4

Requires RSCT 2.4.5.1 Fix Pak IY83474

Red Hat Enterprise Linux 3.0 X X

Requires RHEL 3.0 Update 2.

X

Red Hat Enterprise Linux 4.0 X

Requires compat-libstdc++-33-3.2.3 and xorg-x11-deprecated-libs-6.8.1

X

Requires compat-libstdc++-33-3.2.3 and xorg-x11-deprecated-libs-6.8.1

X

Requires compat-libstdc++-33-3.2.3 and xorg-x11-deprecated-libs-6.8.1

SuSE Linux Enterprise Server 8 X

Requires SLES 8 SP3

X

Requires SLES 8 SP4

SuSE Linux Enterprise Server 9 X X X

• Supported DB2 Fix Pack levels:

For DB2 Version 8, at least Fix Pak 13 is required.

For DB2 9, no additional Fix Paks are required.

• Perl must be installed on the database servers. On Linux, Public Domain Korn Shell (pdksh) must also be installed. For more information, see the document IBM Tivoli System Automation for Multiplatforms - Base Component User’s Guide, which you can find at: publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8210-04/en_US/PDF/halgre20.pdf

12 August 2006

• Both nodes must run on the same operating system.

• Both host machines must have the same operating system patch level.

• See also the latest SA MP release notes at: publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8214-05/en_US/PDF/HALRL205.pdf

2.3 Virtual Host Name and Virtual IP Address The virtual host name and the virtual IP address are used to access the cluster. The virtual host name is a reference on the DNS server or to the virtual IP address in the /etc/hosts files. The cluster binds the virtual IP address to the active cluster node. All clients have to refer either to the virtual host name or directly to the virtual IP address. Therefore, the clients always connect to the node of the cluster where DB2 is currently running.

To set up such an environment, you can choose between the following options:

• Reuse the host name and IP address of a single database server as virtual host name and IP address [page 12]

• Set up new virtual host name and IP address [page 14]

2.3.1 Reusing the Host Name and IP Address of a Single Database Server To reuse the host name and the IP address of the single database server as virtual host name and virtual IP address, you have to replace the host name and the IP address of the single database server with a new host name and a new IP address. You specify the old host name and the old IP address of the database server as the new virtual host name and virtual IP address in the cluster setup configuration file sapdb2policy.conf.

The advantage of this approach is that you do not have to change the references to the database host of your SAP system landscape and of additional monitoring tools. However, additional services that are installed on the database server are not available anymore on the specified host name or IP address.

August 2006 13

The following figure provides an example of such a reuse before and after the cluster has been set up:

The host name db2_sa_mp_1 of the single database server is reused as virtual host name; the IP address 17.2.10.1 is reused as virtual IP address. To avoid naming conflicts, the database server needs a new network identity. Therefore, the database host name is changed to db2_sa_mp_3 and the IP address to 17.2.10.3.

The host name and IP address of the second database server (Node 2) remain the same and both database servers are now addressed with the new virtual address and IP address.

2. after:

1. before:

DB2 Failover Cluster

Node 1 (Database server) Host name: db2_sa_mp_3 IP: 17.2.10.3

Node 2 Host name: db2_sa_mp_2 IP: 17.2.10.2

SAP NetWeaver

Virtual host name: db2_sa_mp_1 Virtual IP: 17.2.10.1

Central instance Dialog instance(s)

Database server (Node1) Host name: db2_sa_mp_1 IP: 17.2.10.1

Node 2 Host name: db2_sa_mp_2 IP: 17.2.10.2

SAP NetWeaver

Central instance Dialog instance(s)

14 August 2006

2.3.2 Setting Up a New Virtual Host Name and IP Address To set up a new virtual host name and a new virtual IP address, you specify the new host name and the new IP address in the cluster setup configuration file (sapdb2policy.conf).

The following figure shows an example of how you set up a new virtual host name or IP address before and after the cluster has been set up:

The database server keeps its host name db2_sa_mp_1 and its IP address 17.2.10.1. A new virtual host name db2_sa_mp_cl and a new virtual IP address 17.2.10.3 are chosen for the failover cluster.

If you already have a SAP NetWeaver system running on this database server (Node 1), you have to change all references to the database host in the SAP system landscape and in the monitoring tools. Although the sapdb2post.sh script automatically replaces some of the references in your SAP system landscape, you have to make some of the changes manually. For more information, see Changing the References to the Virtual Host Name or IP Address [page 25].

2. after:

1. before:

DB2 Failover Cluster

Node 1 (Database server) Host name: db2_sa_mp_1 IP: 17.2.10.1

Node 2 Host name: db2_sa_mp_2 IP: 17.2.10.2

SAP NetWeaver

Virtual host name: db2_sa_mp_cl Virtual IP: 17.2.10.3

Central instance Dialog instance(s)

Database server (Node1) Host name: db2_sa_mp_1 IP: 17.2.10.1

Node 2 Host name: db2_sa_mp_2 IP: 17.2.10.2

SAP NetWeaver

Central instance Dialog instance(s)

August 2006 15

3 Preparation Make sure that you perform the following steps before you start the installation: ...

1. Set up file systems [page 15].

2. Set up the ssh/rsh connection [page 16].

3. Change the password of the SAP connect user [page 18].

3.1 Setting Up File Systems Before you install SA MP, you have to ensure the required file systems are set up as follows:

• All directories under /db2 must be located on the shared disk but not on NFS shares.

For example, the following file systems are required for a standard SAP system with a database that uses DB2’s automatic storage management:

File System Description

/db2/db2<dbsid> Contains the home directory of db2<sapsid>.

/db2/<DBSID>/log_dir Contains at least the online database log files.

/db2/<DBSID>/db2dump Contains DB2 diagnostic log files, DB2 dump files, and further service engineer information.

/db2/<DBSID>/db2<dbsid> Contains the local database directory.

/db2/<DBSID>/saptemp1 Contains the temporary tablespace(s).

/db2/<DBSID>/sapdata1 SAP data for container type database managed space (DMS) FILE or for use of DB2's automatic storage management.

To make sure that either of the mentioned file systems is stored on the shared disk, choose one of the following options (where <dir> can be replaced by any of the directories mentioned here):

Mount the shared disk on /db2 and create an appropriate directory, for example, /<dir>.

Create a partition on the shared disk and mount the partition on /db2/<dir>. For more information about the recommended file system sizes, see the installation guide and the database migration guide [page 7].

Mount the shared disk, for example, under /shr and create a link from /db2/<dir> to an appropriate directory under /shr.

16 August 2006

• Make sure that all required mount points to the shared disk are not mounted at system boot time and that the file systems check at boot time is disabled.

On Linux, you have to set the noauto option and set the sixth column fs_passno to 0 in file /etc/fstab as follows:

/dev/sdc1 /db2 reiserfs noauto,acl,user_xattr 0 0

On AIX, you have to set the options check and mount to false.

/db2: dev = /dev/fslv01 vfs = jfs2 log = /dev/loglv00 mount = false check = false options = rw account = false

You must make sure that none of the file systems are mounted automatically during system reboot. SA MP is the only authority allowed to mount the file systems.

• If you have to mount the file systems listed above manually, you must disable SA MP first, that is, set it to manual mode. Otherwise, SA MP unmounts the file systems immediately.

To set SA MP to manual mode or automation mode, use the following commands as user root, db2<dbsid> or <sapsid>adm:

Manual Mode (disabled): samctrl –MT

Automation Mode (enabled): samctrl -MF

• All types of local file systems are supported by SA MP, for example, reiserfs, jfs2, etc.

3.2 Setting Up the ssh/rsh Connection For the installation of SA MP, you have to enable ssh or rsh login for user root without password authentication. This enables user root to connect to all nodes of the cluster including itself on any node of the cluster. To configure the nodes of the cluster, the SA MP cluster setup script uses ssh or rsh.

By default, the setup script uses ssh on Linux and rsh on AIX.

August 2006 17

Setting Up the Connection Using ssh For example, to use RSA authentication instead of password authentication for ssh, proceed as follows:

1. Log on to the first node of the cluster as user root.

2. Generate an RSA key for user root by entering the following command:

ssh-keygen –t dsa

You are now asked to specify the file name for the key and a passphrase:

Enter the default file name for the key: ~/.ssh/id_dsa

Do not specify any passphrase.

3. To enable key authentication for ssh on the same node, enter the following command: cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

4. To transfer the public key to the second node, enter the following command: scp ~/.ssh/id_dsa.pub root@<hostname>:~/id_dsa.pub

5. Log on to the second node of the cluster as user root.

6. To enable key authentication for ssh on the second node, enter the following command: cat ~/id_dsa.pub >> ~/.ssh/authorized_keys

7. To remove the public key file from the home (directory?) of user root on the second node, enter the following command: rm ~/id_dsa.pub

8. To add both cluster nodes to the list of known hosts, enter the following command: ssh-keyscan –t dsa <host1_short_name>,<host1_full_name>, <host1_ip> >> ~/.ssh/known_hosts

ssh-keyscan –t dsa <host2_short_name>,<host2_full_name>, <host2_ip> >> ~/.ssh/known_hosts

9. Follow the same procedure in the opposite way on the second node.

Setting Up the Connection Using rsh If you want to use rsh and to avoid password authentication, you add the two nodes to the .rhosts file in the home directory of the user root.

1. Log on to first node of the cluster as user root.

2. Add the two nodes to the file .rhosts and the user root separated by a space.

18 August 2006

Using the example setup shown in the Introduction [page 6] the content of .rhosts should look like the following:

db2_sa_mp_1.company.net root db2_sa_mp_1 root 17.2.10.1 root db2_sa_mp_2.company.net root db2_sa_mp_2 root 17.2.10.2 root

3.3 Changing the Password of the SAP Connect User If you change the password of the database connect user with the dscdb6up tool, the password in the dscdb6.conf file and the operating system password of the connect user on the database host are changed. On the standby database server the password is not changed. As a result, the SAP systems cannot connect to the standby database server if DB2 is started on this node.

If you use Network Information Service (NIS) for central user management, the password is not changed in the NIS directory.

So if you change the password of connect user sap<sapsid> or <sapsid>adm you have to manually change the operating system password on the standby database server in the failover cluster or in the NIS directory.

August 2006 19

4 Installation The following sections describe how to install and set up the database failover cluster.

To set up SA MP in a distributed SAP NetWeaver system, do the following:

1. You set up the central services instance or prepare the global host, which is not described in this document.

2. You install the database instance as follows:

a. Download the latest DB2 9 software and SA MP license [page 19].

b. Install the database server [page 19].

c. Set up the high availability cluster [page 20].

d. Perform post-Installation steps [page 28].

3. You install the central instance, which is not described in this document.

You can also install SA MP after you have completed a distributed SAP NetWeaver installation. In this case, you only need to install the second database server as described in Installing the Database Server [page 19] and continue to set up the high availability cluster as described in Setting Up the High Availability Cluster [page 20].

If your database server is not addressed using a virtual host name, you have to change all references to it as described in Changing References to the Virtual Host Name or IP Address [page 25].

4.1 Downloading the Latest DB2 9 Software and SA MP License To be able to install the latest version of DB2 9 and SA MP, download the required software from SAP Service Marketplace at:

service.sap.com/swdc → Download → Database Patches (from other vendors) → DB2 for UNIX and Windows → DB2 9 software download

The SA MP software and setup scripts are bundled with the latest DB2 9 installation image. Also, the license file for SA MP is packed together with DB2 9 licenses.

4.2 Installing the Database Server You install the database server as described in the following documentation:

• For DB2 Version 8, see:

SAP NetWeaver 2004s SR1 <ABAP/ABAP+Java/Java> on <OS>: IBM DB2 Universal Database for UNIX and Windows

You can find this on SAP Service Marketplace at:

service.sap.com/instguidesnw2004s → Installation

20 August 2006

• For DB2 9, see:

Migration to Version 9 of IBM DB2 for Linux, UNIX, and Windows

You can find this on SAP Service Marketplace at:

service.sap.com/instguides → Other Documentation → Database Upgrade → DB2 UDB

For the installation of the database server, you must consider the following:

• If you are using DB2 version 8, you must install the DB2 software on both hosts of the cluster. Do not mount the software directory itself on the shared disk. Even if there are two separate database manager configurations and registries – after you have set up the cluster – only one is valid and is always transferred to the current node. You have to install the OEM license on each node separately.

• If you are using DB2 9, you can also install the database software once on the shared disk. We recommend that you install DB2 9 on the shared disk in the home directory of user db2<dbsid>: /db2/db2<dbsid>/db2_v9. This is the default for SAP NetWeaver future releases. You have to install the OEM license once on one of the nodes.

4.3 Setting Up the High Availability Cluster To set up the cluster, you have to perform the following steps:

1. Install the SA MP software on both nodes [page 21].

2. Install the SA MP license [page 22].

3. Set up the cluster [page 22].

4. Change the references to the virtual host name or IP address [page 25]

In future releases of SAP NetWeaver, SAPinst automatically performs most of the steps shown above.

August 2006 21

4.3.1 Installing the SA MP Software The SA MP software is bundled with DB2 9 DVD images and it is located in the following directory on the DVD:

/<platform>/SA_MP/software/.

Procedure

1. Log on to the first node as user root.

2. Insert and mount the database software DVD to <dvd_mount>.

3. To change to the mount directory, enter the following command: cd <dvd_mount>/<platform>/SA_MP

4. To check that the prerequisites are met, enter the following command : ./prereqSAM

5. To start the installation, enter the following command: ./installSAM –-noliccheck

You can ignore the warning CT_MANAGEMENT_SCOPE not set. It will be set automatically during cluster setup.

6. Install the SA MP software on the second node.

See also For detailed information about the syntax and additional parameters of the scripts prereqSAM and installSAM, see Appendix B – Syntax of SA MP Setup Scripts [page 44].

22 August 2006

4.3.2 Installing the SA MP License You use the following procedure to install the free two-node license of SA MP.

Prerequisites • You have downloaded the license file sam21.lic from SAP Service Marketplace as

described in Downloading the Latest DB2 9 Software and SA MP License [page 19].

• Check if you have installed the DB2 license. If not already done, install it as described in SAP Note 816773.

Procedure 1. Log on to the first node as user root.

2. Move the license file to the home directory of user root:

For Linux: /root

For AIX: /home/root

The cluster setup script transfers the license to the second node and installs it on both nodes.

4.3.3 Setting Up the Cluster Use You set up the high-availability cluster using the cluster setup configuration file and the setup scripts, which are explained in the following tables:

File or Script Name Description

File sapdb2policy.skel Used as a template by script sapdb2gen.sh. File sapdb2policy.skel contains a basic structure and template configuration data that is used for the generation of file sapdb2policy.conf

Script sapdb2gen.sh Generates file sapdb2policy.conf.

File sapdb2policy.conf Contains all data that is required for the setup and maintenance of the cluster.

It is created by script sapdb2gen.sh. During the creation process, sapdb2gen.sh asks for all information required for your cluster setup and finally generates sapdb2policy.conf.

August 2006 23

Script sapdb2policy.sh Sets up the cluster using the data contained in file sapdb2policy.conf.

During the setup process, script sapdb2policy.sh stops the database server, consecutively starts and stops both nodes and finally activates the database on the original node.

It is also used to reset or delete the cluster configuration.

Script sapdb2post.sh Executes post installation steps and is invoked by sapdb2policy.sh.

The script sapdb2post.sh is invoked by the sapdb2policy.sh and cannot be executed separately.

It is also used to reset or delete the cluster configuration.

The following files are replaced during the setup process and are required later.

File Name Description

• startdb

• startj2eedb

• stopdb

• stopj2eedb

• sampdbcmd

Replace the former SAP scripts startdb and stopdb because you have to start and stop the database using the SA MP scripts listed here.

Since SA MP monitors DB2, you cannot start and stop DB2 using the DB2 commands db2start or db2stop. For example, if DB2 is started using db2start, SA MP immediately initiates a db2stop afterwards. For more information on how to manually start and stop DB2, see Checking the Cluster Setup [page 28].

Prerequisites If you have chosen to reuse the host name and IP address of a single database server [page 12], you have to change the host name and the IP address of the database server now.

24 August 2006

Procedure

Copying the Setup Files and Scripts to a Local Directory

The SA MP software is bundled with DB2 9 DVD images and you can find the SA MP software in the following directory on the DVD:

/<platform>/SA_MP/scripts/

Before you set up the cluster, you have to copy all files located in this directory to a local directory, for example, /samp_setup, as follows:

1. Log on to the first node as user root.

2. Create a directory for the scripts using the following command: mkdir ~/samp_setup

3. Insert and mount the database software DVD to <dvd_mount>.

4. Copy the setup files using the following command: cp <dvd_mount>/<platform>/SA_MP/scripts/* ~/samp_setup/.

Creating File sapdb2policy.conf

File sapdb2policy.conf contains all parameters that are required to set up and maintain the DB2 cluster properly. It is created by script sapdb2gen.sh. For more information about the syntax of script sapdb2gen.sh, see A1. Script sapdb2gen.sh [page 37].

1. Log on to the first node as user root.

2. Mount the shared disk.

3. Change to the directory to which you copied the scripts: cd ~/samp_setup

4. Execute the generator script sapdb2gen.sh using the following command:

./sapdb2gen.sh

5. Provide all required parameters.

Some parameters are fixed, some are initial values that you can change and for some parameters you must enter a value. To accept the default or initial values, choose Enter.

Make sure that you keep the sapdb2policy.conf because it is required to reset or uninstall the cluster.

For more information about the parameters that you can check in this configuration file, see A.2 File sapdb2policy.conf [page 38].

August 2006 25

Setting Up the Cluster Using sapdb2policy.sh

The final setup is performed by the scripts sapdb2policy.sh and sapdb2post.sh based on the information contained in file sapdb2policy.conf as follows:

1. Log on to the first node as user root.

2. Mount the shared disk.

3. Change to the directory to which you copied the scripts using the following command: cd ~/samp_setup

4. Set up the cluster – assuming that you have created the cluster setup configuration file in ~/samp_setup – using the following command:

./sapdb2policy.sh –f ~/samp_setup/sapdb2policy.conf -create

The script sapdb2post.sh is invoked by the sapdb2policy.sh and cannot be executed separately.

5. For local users, such as, db2<dbsid>, <sapsid>adm, sap<sapsid> or sap<sapsid>db, you have to set the passwords of these users on the second node using the passwd command.

The passwords must be the same as on the first node.

For more information on script sapdb2policy.sh, see A.3 Script sapdb2policy.sh [page 42].

4.3.4 Changing References to the Virtual Host Name or IP Address

You can omit this procedure if one of the following applies:

• You are reusing the old host name as the virtual host name.

• You have a new installation, that is, you directly set up the failover cluster after the installation of the database instance before installing the application servers.

If you have chosen to set up a new virtual host name and a new virtual IP address [page 14], you must perform the following steps. Although the script sapdb2post.sh performs some of the steps, you have to perform other steps manually:

26 August 2006

Process Flow

1. sapdb2post.sh changes the default profile:

In the default profile /sapmnt/<SAPSID>/profile/DEFAULT.PFL, the database host name has to be replaced for SAPDBHOST and j2ee/dbhost.

2. If the DB2 CLI driver is used, sapdb2post.sh changes the DB2 CLI driver settings in file db2cli.ini, that is, the database host name is replaced.

3. sapdb2post.sh changes the environment of users <sapsid>adm and sap<sapsid>:

The environment of the users <sapsid>adm and sap<sapsid> has to be adapted because most of the environment source files contain the host name as part of their file name. For all other nodes of the cluster, sapdb2post.sh creates the appropriate links as shown in the following example.

.dbenv_db2_sa_mp_2.sh -> .dbenv_db2_sa_mp_1.sh

4. You change the catalog entries on all SAP NetWeaver instances:

a. Log on to the host of an SAP NetWeaver instance as user db2<dbsid>.

b. Get a list of all catalog entries and look for an entry NODE<SAPSID> by entering the following command: db2 “list node directory”

c. Uncatalog the reference to the old host name using the following command: db2 “uncatalog node NODE<SAPSID>”

d. Catalog the reference to the new virtual host name using the following command: db2 “catalog tcpip node NODE<SAPSID>

remote <virtual_hostname> server <service_name>”

where <servicename> stands for sapdb2<SAPSID>.

e. Repeat this procedure for all SAP NetWeaver instances.

5. You change the JDBC URL:

The following steps only apply for ABAP+Java and Java systems only.

a. Log on to the host of an SAP NetWeaver instance as user root.

b. Change to the directory of the configuration tool using the following command: cd /usr/sap/<SAPSID>/<Instance>/j2ee/configtool

c. Run the configuration tool using the following command: ./configtool.sh

d. In the left frame, choose security store.

e. In the right frame, choose the key jdbc/pool/<SAPSID>/url.

f. Change the host name in the JDBC URL to the virtual host name.

August 2006 27

• URL with the old host name: jdbc:db2://db2_sa_mp_1:5912/TSP:deferPrepares=0

• URL with the new virtual host name: jdbc:db2://db2_sa_mp_cl:5912/TSP:deferPrepares=0

g. Choose Add.

h. To save your changes, click on the disk icon in the upper left corner.

i. Close the configuration tool.

j. Restart Java instance ...

6. Change the references in remotely monitored systems.

Make sure that you also change the references in your monitoring tools to the new virtual host name.

28 August 2006

5 Post-Installation Steps After you have successfully completed the installation, you have to perform the following post-installation steps:

1. Check the cluster setup [page 28].

2. Check the cluster fail over [page 30].

3. Back up the SA MP core policy [page 31].

5.1 Checking the Cluster Setup Use After the installation, check that the failover cluster is working properly.

Procedure 1. Log on to one of the cluster nodes as user root, <sapsid>adm, or db2<dbsid>.

2. To check if both nodes are online, enter the following command: lsrpnode

The output looks as follows (RSCT versions can differ): Name OpState RSCTVersion db2_sa_mp_1 Online 2.4.5.2 db2_sa_mp_2 Online 2.4.5.2

3. To check if the domain is online, enter the following command: lsrpdomain

The output looks as follows (RSCT versions can differ): Name OpState RSCTActiveVersion MixedVersions TSPort GSPort sap_tsmdb2 Online 2.4.5.2 No 12347 12348

4. To check the resource groups, enter the following command: lsrg

The output looks as follows: Resource Group names: db2_db2tsm_0-rg

The naming convention for the resource group name is: db2_db2<dbsid>_0-rg.

5. To check the status of the resource group, enter the following command: lsrg –g db2_db2<dbsid>_0-rg

August 2006 29

The output looks as follows:

Displaying Resource Group information: For Resource Group "db2_db2tsm_0-rg". Resource Group 1: Name = db2_db2tsm_0-rg MemberLocation = Collocated Priority = 0 AllowedNode = ALL NominalState = Online ExcludedList = {} Subscription = {} Owner = Description = InfoLink = ActivePeerDomain = sap_tsmdb2 OpState = Online TopGroup = db2_db2tsm_0-rg ConfigValidity = TopGroupNominalState = Online

Most of the commands of SA MP are asynchronous. Therefore, there are two states for the resource group:

NominalState

Indicates the status that the resource group is supposed to have.

OpState

Shows the current status of the resource group.

If you just started the resource group, the NominalState is Online but the OpState is Offline or Pending Online. If the resource group is online, OpState turns into Online as well. Shutting down the resource group causes the same effect but vice versa.

If the resource group is not yet online, start it using the following command: chrg –o online db2_db2<dbsid>_0-rg

To stop the DB2 resource group, set the NominalState to offline using the following command: chrg –o offline db2_db2<dbsid>_0-rg

To receive more information about resource members of the cluster, use the following SA MP command: lsrg –Ab –m –V –g db2_db2<dbsid>_0-rg

30 August 2006

In addition, you can use a special script of the DB2 HA precanned policy to display all registered resources and the status on the node where the script is issued using the following command: /usr/sbin/rsct/sapolicies/db2/getstatus

The output looks as follows:

-- Resource Groups and Resources -- Group Name Resources ---------- --------- db2_db2tsm_0-rg db2_db2tsm_0-rs_ip db2_db2tsm_0-rg db2_db2tsm_0-rs_db2_disk db2_db2tsm_0-rg db2_db2tsm_0-rs

-- Resources -- Resource Name Node Name State

------------- --------- ----- db2_db2tsm_0-rs_ip db2_sa_mp_1 Online db2_db2tsm_0-rs_ip db2_sa_mp_2 Offline

db2_db2tsm_0-rs_db2_disk db2_sa_mp_1 Online db2_db2tsm_0-rs_db2_disk db2_sa_mp_2 Offline

db2_db2tsm_0-rs db2_sa_mp_1 Online db2_db2tsm_0-rs db2_sa_mp_2 Offline

6. Check that you can start and stop DB2 in the cluster.

To start and stop the members of the resource group – taking the relationship between them into consideration – use the following command: rgmbrreq -o [start|stop|cancel] <resource_class>:<rgmbr>

To explicitly start and stop the DB2 instance, only use the following command: rgmbrreq -o [start|stop|cancel] IBM.Application:db2_db2<dbsid>_0-rs

Since SA MP monitors DB2 you cannot start and stop DB2 using the DB2 commands db2start or db2stop. For example, if DB2 is started using db2start, SA MP immediately initiates a db2stop afterwards.

5.2 Checking the Cluster Failover Use You use the following procedure to check the failover of the cluster by moving the DB2 instance from one node to the other.

Procedure 1. Log on to one cluster node as user root, <dbsid>adm or db2<dbsid>.

2. To move DB2 to another node, enter the following command:

rgreq -o Move -n <hostname> db2_db2<dbsid>_0-rg

August 2006 31

Since you specify the node to move from, you have to enter the <hostname> where the DB2 instance is currently running.

As result, SA MP shuts down DB2 on the specified node, unmounts the shared disk, removes the virtual IP address from the network adapter of this node, and sets up everything on the other node in the cluster. You can monitor the process using the getstatus.

Alternatively, since this method does not check the monitoring and failure-detection features of SA MP, you can use the following method to check the failover behavior:

You can shut down the operating system on the node where the DB2 instance is currently running. SA MP detects that the resources of the resource group are not online anymore and starts all required resources on the other node.

5.3 Performing a Backup of the SA MP Core Policy SA MP stores all its knowledge about the cluster in a policy that contains all definitions of resources, resource groups, and their relationships. Therefore, this policy contains the core configuration of the SA MP cluster. After cluster setup, we recommend that you back up the SA MP core policy. This lets you easily restore the initial cluster setup if you accidentally change the SA MP core policy.

Performing a Backup The following command creates a backup of the SA MP core policy and writes it to the bkpPolicy.xml XML file:

1. Log on to a cluster node as user root.

2. To back up the core policy, enter the following command: sampolicy –s /bkp/samp/bkpPolicy.xml

Restore To restore an SA MP core policy, proceed as follows:

1. Log on to a cluster node as user root.

2. To restore the core policy, enter the following command: sampolicy –a /bkp/samp/bkpPolicy.xml

The restore process replaces the current policy by the one specified and finally activates this policy.

32 August 2006

6 Updating the Software

6.1 Updating the Database Fix Paks Use You use the following procedure to update the database Fix Paks in an SA MP environment.

After a DB2 migration or a Fix Pak update, you have to update the DB2 HA precanned policy files in SA MP that are stored in the subdirectory of the DB2 software directory ha/tsa . These policy files are required by SA MP for monitoring, starting, stopping the database server, and transferring the registry.

Restrictions In general, you can also apply Fix Paks by performing a rolling update, that is, you update the standby server first, then fail over to the already updated standby database server, and finally update the other database server. This causes only several seconds downtime for the failover of the database to the second node.

However, in an SA MP environment, you must not perform a rolling update for the following reasons:

• For DB2 Version 8, you must not run the application servers and the database server at different Fix Pak levels. Therefore, you have to shut down the complete SAP system and update all database servers and the DB2 clients on the application servers.

A rolling update only updates the database server and not the DB2 clients on the application servers. The result is that the database server has a higher Fix Pak level than the application servers.

• For DB2 9, you can run the database server at a higher Fix Pak level than the application servers. You can install the Fix Pak besides your current DB2 software, stop the database server, update the database instance within seconds and finally restart the database server. In addition, you do not have to restart the application servers because they will immediately reconnect to the database server. Using this feature of DB2 to just update the DB2 instance, which means simply recreating the links in the instance directory, causes only a few seconds downtime for the database server.

The failover in the rolling update scenario is no faster. Therefore, there is no advantage in performing a rolling update with DB2 9.

Procedure 1. Log on to the first node as user root.

2. To shut down the DB2 instance, enter the following command: chrg –o offline db2_db2<dbsid>_0-rg

3. To check, if DB2 is stopped, enter the following command: lsrg –g db2_db2<dbsid>_0-rg

In the output, check if the OpState is Offline.

August 2006 33

4. To disable SA MP, enter the following command: samctrl –MT

5. If the DB2 software is located on the shared disk, mount it.

6. Apply the DB2 Fix Pak to the first node as described in SAP Note 603972.

7. To remove the old HA policy, enter the following command: rm /usr/sbin/rsct/sapolicies/db2/*

8. To update to the new HA policy, enter the following command: cp <DB2_software_dir>/ha/tsa/* /usr/sbin/rsct/sapolicies/db2/.

9. If the DB2 software is located on the shared disk, unmount it.

10. Log on to the second node as user root.

11. If the DB2 software is located on the shared disk, mount it.

12. If the DB2 software is not located on the shared disk, you must apply the DB2 Fix Pak to this node as described in SAP Note 603972.

You must not update the DB2 instance (db2iupdt) again because it was already updated in step 6.

13. To remove the old HA policy, enter the following command: rm /usr/sbin/rsct/sapolicies/db2/*

14. To update to the new HA policy, enter the following command: cp <DB2_software_dir>/ha/tsa/* /usr/sbin/rsct/sapolicies/db2/.

15. If the DB2 software is located on the shared disk, unmount it.

16. To enable SA MP, enter the following command: samctrl –MF

17. To start the DB2 instance, enter the following command: chrg –o online db2_db2<dbsid>_0-rg

18. To check if DB2 is running again, enter the following command: lsrg –g db2_db2<sapsid>_0-rg

The OpState and Nominal State of the resource group come online in a short time.

If you share the DB2 software, you have to install the Fix Pak once only, but you must replace the DB2 HA precanned policy on both nodes.

34 August 2006

6.2 Updating SA MP FixPaks For information about how to upgrade an SA MP installation to the latest Fix Pak, see section Migrating the Product in the document IBM Tivoli System Automation for Multiplatforms - Base Component User’s Guide that is available at: publib.boulder.ibm.com/tividd/td/IBMTivoliSystemAutomationforMultiplatforms2.1.html.

August 2006 35

7 Uninstall

To uninstall the cluster and the software from the two database hosts, you have to perform the following steps:

1. You uninstall the cluster [page 35].

2. You uninstalling the SA MP software [page 36].

3. You delete the DB2 software [page 36].

7.1 Uninstalling Cluster To uninstall the cluster and to separate the two nodes, use the sapdb2policy.sh script as follows:

1. Log on to the first node where you initially transferred the SA MP scripts (for more information, see Setting Up the Cluster [page ]) to as user root.

2. If the second node becomes the server where the database is running (that is, the single database server), move directory ~/samp_setup to the other node and log on to the other node as user root.

3. Change to the directory using the following command: cd ~/samp_setup

4. Delete the DB2 resource groups using the following command: ./sapdb2policy.sh –f ~/samp_setup/sapdb2policy.conf -deleteDB2

5. Delete the cluster using the following command: ./sapdb2policy.sh –f <sapinst_instdir>/sapdb2policy.conf -deleteCluster

6. Change to the home directory using the following command: cd ~

7. Delete the setup scripts using the following command: rm –R ~/samp_setup

Result The cluster has been uninstalled and the node where you performed the steps mentioned here is able to run DB2.

Since the virtual host name and virtual IP address are no longer valid, you have to replace all references to it with the host name or IP address of the single database server. The sapdb2policy.sh script already updated the references in the SAP profile, the db2cli.ini file, and sapdb2policy.sh restores the SAP startdb/stopdb scripts when you deleted the DB2 resource group.

36 August 2006

In addition, you have to replace all references listed for manual actions as described in Changing the References to Virtual Host Name or IP Address [page 18].

You can also remove the users db2<dbsid>, sap<sid> and <sid>adm from the host where the database instance is no longer running.

7.2 Uninstalling SA MP Use You uninstall the SA MP software using the uninstallSAM script from the SA MP software directory on the DVD.

Procedure 1. Log on to the first node as user root.

2. Insert and mount the database software DVD to <dvd_mount>.

3. Change to the directory where the SA MP software is located using the following command: cd <dvd_mount>/<platform>/SA_MP/software

4. To uninstall the SA MP software, enter the following command: ./uninstallSAM

7.3 Deleting the Database Software For information about how to delete the DB2 software, see the installation guide SAP NetWeaver 2004s SR1<ABAP/ABAP+Java/Java> on <Platform>: IBM DB2 Universal Database for UNIX and Windows.

You can find this at: service.sap.com/instguides2004s → Installation

August 2006 37

Appendix A - SA MP Policy for DB2 The following sections provide detailed information about:

• Script sapdb2gen.sh [page 37]

• File sapdb2policy.conf [page 38]

• Script sapdb2policy.sh [page 42]

A.1 Script sapdb2gen.sh The generator script sapdb2gen.sh generates the cluster setup configuration file that is required by the sapdb2policy.sh and sapdb2post.sh scripts.

sapdb2gen.sh requires ssh or rsh connection to the cluster nodes as described in Setting Up the ssh/rsh Connection [page 16] to detect most of the required cluster settings.

Syntax sapdb2gen.sh [-h] [-s <skeletonfile>] [-f <configfile>] ...

Options Parameter Description

-h Prints the usage syntax.

-l <skeletonfile> Specifies the skeleton file name. Otherwise, the default is: sapdb2policy.skel

-f <configfile> Specifies the configuration file name. By default, sapdb2gen.sh the sapdb2policy.conf file in the current directory.

See also For a detailed description of all the required configuration information, see section A.2 File sapdb2policy.conf below.

38 August 2006

A.2 File sapdb2policy.conf The sapdb2policy.conf policy file contains all parameters that are required to set up the DB2 cluster properly.

The following is an example of the policy file containing all relevant information based on the setup example shown in the Introduction [page 6] (where TSM stands for the <SAPSID>, and no NFS for home directories of local users).

Example # IBM_PROLOG_BEGIN_TAG # This is an automatically generated prolog. # # Licensed Materials - Property of IBM # # (C) COPYRIGHT International Business Machines Corp. 2003,2005 # All Rights Reserved # # US Government Users Restricted Rights - Use, duplication or # disclosure restricted by GSA ADP Schedule Contract with IBM Corp. # # IBM_PROLOG_END_TAG #.-----------------------------------------------------------------. #| | #| IBM Tivoli System Automation for Multiplatforms | #| Policy for DB2 | #| Policy version: 1.0 | #| | #| Configuration Information | #| ========================= | #| | #| This script is used by other scripts to obtain | #| configuration information. | #| You must adapt the indicated lines to your environment. | #| | #'-----------------------------------------------------------------' ###### START OF CUSTOMIZABLE AREA ################################### # domain name

TSA_DOMAIN_NAME=sap_tsmdb2

# comma-separated list of the hostnames

TSA_HOSTNAME_LIST=db2_sa_mp_1, db2_sa_mp_2

# TSA License File

TSA_LICENSE_FILE=/home/root/sam21.lic

# IP address of the network tie breaker

TSA_TIEBREAKER_IP_ADDRESS=17.2.10.0

# remote shell (ssh or rsh)

TSA_REMOTE_CMD=rsh

# comma-separated list of users of the TSA operators

TSA_USER_LIST=db2tsm, tsmadm

# installation directory for DB2

August 2006 39

DB2_INST_DIR=/db2/db2tsm/db2_v9

# comma-separated list of DB2 communication ports, # each port in syntax <name>:<port_num>[,<name>:<port_num>]

DB2_COMM_PORTS=sapdb2TSM:5912/tcp,DB2_db2tsm:5914/tcp, DB2_db2tsm_1:5915/tcp,DB2_db2tsm_2:5916/tcp, DB2_db2tsm_END:5917/tcp

# Virtual hostname of the cluster

DB2_HA_HOSTNAME=db2_sa_mp_cl

# Virtual IP address of the cluster

DB2_HA_IP_ADDRESS=17.2.10.3

# Network Mask for the virtual IP address

DB2_HA_IP_MASK=255.255.255.0

# DB2 instance owner

DB2_DB2INSTANCE=db2tsm

# comma-separated list of DB2 directories on shared disks

DB2_DIR_LIST=/db2/db2tsm,/db2/TSM/db2dump,/db2/TSM/db2tsm, /db2/TSM/log_dir,/db2/TSM/sapdata1,/db2/TSM/saptemp1

# comma-separated list of public HA network interfaces for DB2, # at least one per node DB2_NETWORK_INTERFACE_LIST=en0:db2_sa_mp_1,en0:db2_sa_mp_2

# comma-separated list of user groups, each group in syntax # <group>:<num>:<local_group> DB2_GROUP_LIST=dbtsmadm:1001:true,dbtsmctl:1002:true, dbtsmmnt:1003:true

# comma-separated list of users, each user in syntax # <user>:<num>:<home_dir>:<local_home_dir>:<shell>:<local_user> # <prim_group>[:<sec_group>]

DB2_USER_LIST=db2tsm:1010:/db2/db2tsm:false:/bin/csh:true:dbtsmadm, saptsm:1011:/home/saptsm:true:/bin/csh:true:dbtsmmnt, tsmadm:1009:/home/tsmadm:true:/bin/csh:true:dbtsmmnt

# the SAP System ID (SAPSID)

SAP_SID=TSM

###### END OF CUSTOMIZABLE AREA #####################################

Options Parameter Description Default Value

TSA_DOMAIN_NAME Domain name of the cluster sap_<dbsid>db2

TSA_HOSTNAME_LIST Comma-separated list of host names.

-

TSA_LICENSE_FILE Location of downloaded SA MP license file

• Linux: /root/sam21.lic

• AIX: /home/root/sam21.lic

40 August 2006

TSA_TIEBREAKER_ IP_ADDRESS

IP address of the network tie breaker, described in detail below

-

TSA_REMOTE_CMD Remote shell to use for the setup

• Linux: ssh

• AIX: rsh

TSA_USER_LIST Comma-separated list of users with the authority to start or stop the cluster and single resources in the cluster

db2<dbsid>, <sapsid>adm

DB2_INST_DIR Installation directory of the DB2 software

• DB2 9: /db2/db2<dbsid>/db2_v9

• DB2 Version 8:

Linux: /opt/IBM/db2/V8.1

AIX: /usr/opt/IBM/db2/V8.1

DB2_COMM_PORTS Comma-separated list of DB2 communication ports with the following syntax: <name>:<port>, …

For example:

sapdb2TSM:5912/tcp, DB2_db2tsm:5914/tcp, DB2_db2tsm_1:5915/tcp, DB2_db2tsm_2:5916/tcp, DB2_db2tsm_END:5917/tcp

sapdb2<DBSID>:5912/tcp, DB2_db2<dbsid>:5914/tcp, DB2_db2<dbsid>_1:5915/tcp, DB2_db2<dbsid>_2:5916/tcp, DB2_db2<dbsid>_END:5917/tcp

DB2_HA_HOSTNAME Virtual host name of the cluster -

DB2_HA_IP_ADDRESS Virtual IP address of the DB2 database cluster server

-

DB2_HA_IP_MASK Virtual network mask of the DB2 database cluster server

-

DB2_DB2INSTANCE DB2 instance owner db2<dbsid>

DB2_DIR_LIST Comma-separated list of DB2 mount point directories on the shared disk

/db2/db2<dbsid>, /db2/<DBSID>/log_dir, /db2/<DBSID>/db2dump, /db2/<DBSID>/db2<dbsid>, /db2/<DBSID>/saptemp1, /db2/<DBSID>/sapdata1

DB2_LV_LIST AIX logical volume list for usage of raw devices.

AIX only: /dev/lv01…

August 2006 41

DB2_NETWORK_ INTERFACE_LIST

Comma-separated list of network interfaces for the IP address equivalency

The list must correspond to the order in the host name list, one per host is mandatory.

• Linux: eth0:<host1>, eth0:<host2>, …

• AIX: en1:<host1>, en1:<host2>, ...

DB2_GROUP_LIST Comma-separated list of groups with the following syntax:

<group>:<num> :<local_group>, …

For example: dbtsmadm:1015:true

If you use NIS for central user management, <local_group> has to be false for all groups.

db<sapsid>adm:<num>:<localgrp>,db<sapsid>ctl:<num>:<localgrp>,db<sapsid>mnt:<num>:<localgrp>

DB2_USER_LIST Comma-separated list of users

The syntax is as follows: <user>:<num>:<home_dir>:<local_home_dir> :<shell>:<local_user> :<prim_group> [:<sec_group>], …

For example: db2tsm:1010:/db2/db2tsm:false:/bin/csh:true :dbtsmadm

If you use NFS shares for your home directories, the parameter <local_home_dir> has to be false for all users.

If you use NIS for central user management, <local_user> has to be false for all users.

db2<sapsid>:<num>: /db2/db2<sapsid>:false: /bin/csh:true:db<sapsid>adm,

<sapsid>adm:<num>: /home/<sapsid>adm:true: /bin/csh:true:db<sapsid>mnt

ABAP: sap<sapsid>:<num>: /home/sap<sapsid>:true: /bin/csh:true:db<sapsid>mnt,

Java: sap<sapsid>db:<num>: /home/sap<sapsid>db:true: /bin/sh:db<sapsid>mnt

SAP_SID SAP system ID. <SAPSID>

42 August 2006

Network TieBreaker If the cluster is split into two or more subclusters (for example, because of network problems), only one subcluster must have the authority to manage the resources of the cluster. Otherwise, data might be corrupted when it is accessed by several nodes at the same time and the read/write operations are not synchronized in any way. To ensure correct behavior in the event of a cluster split, you need a tie breaker. Using the tie breaker technology, only one subcluster gets the quorum to manage the resources.

The network tie breaker uses the following rule:

The subcluster that can be accessed from outside of the cluster should get the quorum. The network tie breaker uses an external IP address to resolve a tie. It uses ICMP echo requests (ping) to check the network connectivity to an IP address that is outside of the cluster.

If the network tie breaker is able to ping the IP address, this part of the cluster gets the quorum and manages the resources. We recommend that you use the IP address of the gateway for the network tie breaker. By choosing the gateway as the tie breaker, you ensure all nodes that can ping the tie breaker can communicate with each other via the gateway. These nodes should be in the same subcluster after a cluster split.

Make sure that the ICMP echo request and ICMP echo reply messages are not rejected by any firewall settings for the tie breaker and the cluster nodes.

A.3 Script sapdb2policy.sh The script sapdb2policy.sh sets up the cluster according to the cluster setup configuration file. Basically it configures SA MP according to the data contained in the sapdb2policy.conf file and creates all required resources, resource groups, relationships between the resources and installs the DB2 HA policy files on the cluster nodes.

Syntax sapdb2policy.sh [-h] [-v] [-silent] [-l <logfile>]

[-f <configfile>]

–create[Cluster|DB2]

-resetCluster

-delete[Cluster|DB2]

August 2006 43

Options Parameter Description

-h Prints the usage syntax

-v Runs the script in verbose mode

-silent Writes no messages to stdout

-l <logfile> Specifies the log file name. Otherwise, the default log name is sapdb2policy.log.

-f <configfile> Specifies the configuration file name. By default, the script looks for sapdb2policy.conf in the current directory.

-create Creates the SA MP domain and DB2 resources

-createCluster Creates the SA MP domain

-createDB2 Creates the DB2 resources

-resetCluster Resets an invalid SA MP domain

-deleteCluster Deletes the SA MP domain

-deleteDB2 Deletes the DB2 resources

Return Codes Return Code Meaning

0 The cluster and all it’s resources are created successfully

1 Error occurred, see log file for details

2 Syntax error in the configuration file

3 Error creating or deleting the cluster

4 Error creating or deleting the DB2 policy resources

5 Error activating the SA MP license file

6 Error defining local users or local groups

44 August 2006

Appendix B - Syntax of SA MP Setup Scripts The following sections provide detailed information about:

• Script prerequSAM [page 44]

• Script installSAM [page 45]

• Script uninstallSAM [page 46]

B.1 Script prereqSAM The script prereqSAM determines the prerequisites of SA MP on this node. It checks the level of the operating system, architecture and distribution and the presence of required software packages.

Syntax prereqSAM [--nodeleteinstlog] [--silent]

[-d <inst-pkg-dir>] [-l <log-file>] ...

Options Parameter Description

--nodeleteinstlog Prevents removal of old logs. Since logs carry a Process ID (PID) in their name it is not likely that old logs are overwritten.

--silent Suppresses output to the command line

-d <inst-pgk-dir> Allows prerequisite checking based on NLS files in <inst-pkg-dir> although prereqSAM is not in the package directory. prereqSAM is not dependent on the packages to be installed, but needs the directory for its message files.

-l <logfile> Logs to file <log-file> instead of /tmp/prereqSAM.<pid>.log

Return Codes Return Code Meaning

0 The version of the operating system is supported and all prerequisite packages were found installed at the correct version. The log file contains names and versions of the installed packages.

20 An installed package does not have the correct version. The log file contains the names and versions of the missing packages.

21 Package has not been found installed

22 Operating system version is not supported

23 Unable to conduct prerequisite checking due to a reason described in more detail in the log. Reason might be that a file is missing.

August 2006 45

B.2 Script installSAM The installSAM script checks the prerequisites once again and finally installs the SA MP software on this machine.

Syntax installSAM [--force] [--noliccheck]

[--nodeleteinstlog] [--silent] [--upgrade]

[-d <inst-pkg-dir>] [-l <logfile>] ...

Options Parameter Description

--force Allows downgrading package sam if the installed version is higher than the version of the supplied package

--noliccheck Allows first time installation even if no license file is supplied, or allows upgrade if no installed license is found. The fact is recorded in the log.

--nodeleteinstlog Prevents removal of old logs. Since logs contain a PID in their name, it is unlikely that old logs are overwritten.

--silent Suppresses output to the command line

--upgrade Allows to upgrade SA MP if –-silent is specified

-d <inst-pgk-dir> Allows installing packages from directory <inst-pkg-dir> although installSAM is not in the package directory

-l <logfile> Logs to file <logfile> instead of /tmp/installSAM.<pid>.log

Return Codes Return Code Description

0 installSAM including prerequisite checking and installation completed successfully.

1 Package installer returned with return code not 0, return code and message can be found in the log. ‘Package installer’ is: installp for AIX, rpm for Linux.

2 Package sam is already installed at the same version. If --force is specified, the installation overwrites the same version. A warning is logged and the installation status is returned.

3 Package sam is already installed at a higher version. If – -force is specified, the installation overwrites the higher version. A warning is logged and the installation status is returned.

46 August 2006

4 Package sam is already installed at a lower version than package version and option –-silent is specified. If –-upgrade is specified, upgrade from a lower version is performed and upgrade status is returned.

5 The node on which the installation task is required is online. The task is not performed.

6 SA MP base license file is not found or no installed license is detected.

7 installSAM was unable to continue because directories or files could not be detected or other conditions make it fail.

2x Prerequisite checking conducted by prereqSAM failed (see above).

B.3 Script uninstallSAM The uninstallSAM script removes SA MP software.

Syntax uninstallSAM [--nodeleteinstlog] [--silent]

[-d <inst-pkg-dir>] [-l <log-file>]

Options Parameter Description

--nodeleteinstlog Prevents removal of old logs. Since logs carry a PID in their name it is not likely that old logs are overwritten.

--silent Suppresses output to the command line

-d <inst-pgk-dir> Allows uninstall from directory <inst-pkg-dir> although uninstallSAM is not in the package directory

-l <logfile> Logs to file <log-file> instead of /tmp/prereqSAM.<pid>.log

Return Codes Return Code Description

0 uninstallSAM completed successfully.

1 Error occurred during uninstall.

2 The domain is still online. Uninstall stopped.

3 Uninstall is not possible.

August 2006 47

Appendix C - Diagnosis/Troubleshooting

C.1 Troubleshooting Reference Documentation For troubleshooting and diagnosis information, see the following documentation:

• IBM Tivoli System Automation for Multiplatforms – Base Component User’s Guide, section Appendix – Troubleshooting, available at:

publib.boulder.ibm.com/tividd/td/ITSAFL/SC33-8210-04/en_US/PDF/halgre20.pdf

• IBM Reliable Scalable Cluster Technology (RSCT) – Diagnosis Guide, available at:

publib.boulder.ibm.com/epubs/pdf/bl5dia03.pdf

This guide provides information that helps you to inspect the RSCT subsystems. In addition, this guide covers a detailed description list of messages of the subsystems.

C.2 Requesting SAP Support To request SAP support, open a message on SAP Service Marketplace using component BC-DB-DB6.

C.3 Symbol Resolution Failed for db2start on AIX Problem If you have DB2 installed on the shared disk on AIX, the following error can occur when you want to start DB2: > db2start Could not load program db2start: Symbol resolution failed for /usr/lib/threads/libc.a[aio_64.o] because: Symbol kaio_rdwr64 (number 0) is not exported from dependent module /unix. Symbol listio64 (number 1) is not exported from dependent module /unix. Symbol acancel64 (number 2) is not exported from dependent module /unix. Symbol iosuspend64 (number 3) is not exported from dependent module /unix. Symbol aio_nwait (number 4) is not exported from dependent module /unix. Symbol aio_nwait64 (number 5) is not exported from dependent module /unix. Symbol aio_nwait_timeout (number 6) is not exported from dependent module /unix. Symbol aio_nwait_timeout64 (number 7) is not exported from dependent

48 August 2006

module /unix. System error: Error 0 Examine .loader section symbols with the 'dump -Tv' command. The error occurs if you do not install DB2 on the node where you did not use db2setup and you do not have asynchronous I/O (AIO) enabled. Normally, db2setup enables it for you during setup.

Solution 1. Check if AIO is enabled by the following command:

lsdev –Cc aio

If AIO is enabled, the output is as follows:

aio0 Available Asynchronous I/O (Legacy)

Otherwise, it is like the following:

aio0 Defined Asynchronous I/O (Legacy)

4. Enable AIO as follows:

a. Log on to the node as user root.

b. Open AIO configuration in smitty using the following command: smitty aio

c. Enable AIO by the topic "Configure defined aio".

C.4 DB2 Immediately Stops After the db2start/startdb/startj2eedb Command Problem After you have installed SA MP and configured SA MP to manage DB2, the native DB2 db2start command is obsolete. If you use db2start to start a DB2 instance, SA MP does not know that you want to start DB2 on this node. Once SA MP monitors that DB2 is started on this node, it immediately stops DB2 according to the rule “this resource is supposed to be offline”. On Linux and AIX (if syslogd is configured), you see an entry in the system log that db2_stop.ksh is invoked to bring DB2 down.

During the setup of the cluster the SAP scripts startdb and startj2eedb are replaced by the script sapdb2post.sh. The new scripts use SA MP commands to start DB2 via SA MP commands.

Solution Make sure that the scripts you use to start DB2 are the same as on the SA MP setup images.

August 2006 49

C.5 DB2 Immediately Starts After the db2stop/stopdb/stopj2eedb Command Problem When you have installed SA MP and configured SA MP to manage DB2 the native db2stop command becomes obsolete. If you use db2stop to stop a DB2 instance, SA MP does not know that you want to stop DB2 on this node. Once SA MP monitors that DB2 is stopped on this node, it immediately starts DB2 according to the rule “this resource is supposed to be online”. On Linux and AIX (if syslogd is configured), you see an entry in the system log that db2_start.ksh is invoked to start DB2.

During the setup of the cluster the SAP scripts stopdb and stopj2eedb are replaced by the script sapdb2post.sh. The new scripts use SA MP commands to stop DB2 using SA MP commands.

Solution Make sure that the scripts you use to stop DB2 are the same as on the SA MP setup images.