Introduction

A challenging scenario is where a DB2 instance and the Systems Director server both reside on the same system that has caused confusion based on feedback from customers and field engineers. This article provides a clear and consistent direction for both scenarios where the DB2 database is local or remote to the Systems Director server. Following the guideline of this article enables you to safely upgrade the DB2 server, or easily migrate your database to another system, if the need arises, without reconfiguring the Systems Director server.

Though the instructions provided in this article are applicable to all supported platforms, we use AIX as an example for all the discussions and illustrations. This article represents the view and recommendation of the authors, not IBM.

Back to top

Transition process from Derby to DB2

There is more than one way to switch the database of Systems Director server from the embedded Derby engine to DB2, but the most straight forward way could be summarized as follow:

1. Install IBM Systems Director server with default options.
2. Start the Systems Director server to confirm that it is working normally.
3. Stop the Systems Director server.
4. Create the DB2 database on the DB2 server.
5. Install DB2 client and create a DB2 client instance.
6. Setup root's user environment to point to the DB2 client instance.
7. Customize Systems Director's database configuration response file.
8. Run the Systems Director's script to create the remote database and tables.
9. Start the Systems Director server.
10. Verify and finish.

These steps should be easily understood and followed.

The challenge arises when the DB2 server resides on the same system as the Systems Director server. The product documentation has a different set of instructions when the DB2 database is remote versus local. It is better to treat the local database just as a remote to decouple the client instance from the server instance for easier maintenance and increased flexibility.

So, let's see how we do it if the DB2 server is on the same system as the Systems Director server:

1. Install Systems Director server with default options.
2. Start the Systems Director server to confirm that it is working normally.
3. Stop the Systems Director server.
4. Install DB2 server, create a DB2 server instance and a database.
5. Install DB2 client, create a DB2 client instance.
6. Setup root's user environment to point to the DB2 client instance.
7. Customize the Systems Director's database configuration response file.
8. Run the Systems Director script to configure and populate the database.
9. Start the Systems Director server.
10. Verify and finish.

Not much of a difference is there? Step 4 is the only difference, the rest remains exactly the same.

So, let's dive into the details and see how this is actually going to work out.

Back to top

Test environment description

To illustrate the actual setup process, we used a single AIX partition to install the Systems Director server and DB2 server. Figure 1 below shows the component relationship and the respective user ID of each component. It shows an AIX partition that hosts 2 subsystems within it. The first subsystem includes Director server and its associated DB2 client instance. The Director server process runs as root account, it makes SQL query using dirusr1 account. The DB2 client instance is owned by db2admc1 account. The second subsystem includes a DB2 server instance and its database. The DB2 server instance is owned by db2inst1 account, and the database DIRDB01 table schema is dirusr1.

For this experiment, we used a small partition on an IBM POWER7 server with 0.5 processor entitlement, 4 GB of memory and 20 GB of storage. In a production environment, you want to have more resources than this if you're running the Systems Director server and DB2 server together. Please consult the Systems Director InfoCenter hardware requirement for the latest recommendation (see Resources).

The following software was used:

• IBM AIX 6.1 TL04
• IBM Systems Director 6.2
• IBM DB2 Data Server Enterprise Edition 9.5 fixpack 5
• IBM Data Server Client 9.5 fixpack 5

Back to top

Installing Systems Director server with default options

Let us begin by installing Systems Director server and confirming that it is working normally with the embedded Derby database. A very brief instruction is provided here. Please refer to the InfoCenter for detailed installation instruction (see Resources).

1. Login to the AIX system as root.
2. Ensure that you have sufficient free space on the following filesystems:
   • / 0.5 GB
   • /usr 0.5 GB
   • /var 0.5 GB
   • /tmp 1 GB
   • /opt 4 GB
3. If you're downloading the Systems Director server from the web (the package is approximately 1.5GB), then make sure there is enough disk space. Also, ensure the ulimit file size is set to greater than the default value or run the command ulimit -f unlimited before downloading the large file.
4. Ensure that you have a healthy TCP/IP configuration, including routing, /etc/hosts, DNS entry and reverse DNS lookup of the server host name.
5. Run dirinstall.server to begin the installation.
6. After accepting the license agreement, the installation runs for about 30 minutes. At the completion, you'll see something similar to the following in installp format showing the result of Director Server installation.

   Finished processing all filesets. (Total time: 26 mins 28 secs) Finished processing all filesets. (Total time: 26 mins 38 secs) +---------------------------------------------------------------------+ Summaries: +---------------------------------------------------------------------+ Installation Summary -------------------- Name Level Part Event Result ----------------------------------------------------------------------- DirectorServer 6.2.0.0 USR APPLY SUCCESS DirectorServer 6.2.0.0 ROOT APPLY SUCCESS This installation log file can be found in /var/log/dirinst.log. Installation of IBM Systems Director Server completed successfully.

   
   
7. Configure the local Agent Manager by running /opt/ibm/director/bin/configAgtMgr.sh. The results of running the Agent Manager configuration script are shown below:

   Configuring Resource Manager and Common Agent. Starting Agent Manager... OK Retrieving Agent Manager Instance ID... OK Registering Agent Manager toolkit... OK Removing Agent Manager user manager... OK Adding Agent Manager user root... OK Configuring Common Agent... OK Waiting for Common Agent certificates... OK Waiting for Common Agent SLP advertisement... OK Waiting for Common Agent status report... OK Stopping Agent Manager... OK Agent Manager configuration completed successfully.

   
   
8. Now, you can run the command /opt/ibm/director/bin/smstart to start the Systems Director server.
9. It should take about 5 minutes for the first start-up to complete. Run the command /opt/ibm/director/bin/smtatus -r to check for the status of Systems Director server recursively; it should show something like this over time:

   Inactive Starting Active

   
   

From a remote browser (Firefox or Internet Explorer), login to the Systems Director server with the following URL:

https://hostname:8422/ibm/console

The browser shows a warning that the security certificate was not certified by a trusted authority and not matching the actual website. Accept the exception and move forward. Then you should see the Systems Director login page. Login as root and the Systems Director welcome page, as shown in Figure 2, displays.

Figure 2 shows a screen shot of the Welcome page after login from the web console of Systems Director. It has a left navigation bar with a list of functions available to the current user, such as Automation, Availability, Inventory, Release Management, Security, System Configuration, System status and health, Task management and Settings. The right panel shows 3 tabs, Start, Manage and Learn. The Start tab has a button to Discover, and a pie chart showing one operating system, zero systems with no agent, zero systems with Platform agent, and two systems with Common agent.

Go to Navigate Resources, choose the default group All Systems, verify that there are two endpoints for the Systems Director server, as shown in Figure 3. One operating system type and one virtual server type (or server type if you're not running on LPAR), the status should be OK.

Figure 3 shows a screen shot of the Navigate Resources panel. The table list all the systems in the static group All Systems, starting with a virtual server endpoint named IBM 8233E8B and an operating system endpoint named prve32.cite.cn.ibm.com. Both endpoints have the access status of OK and problem status of OK.

If your Systems Director server is good up to now, you can stop it with the /opt/ibm/director/bin/smstop command.

Back to top

DB2 installation planning

If you are going to leverage an existing remote DB2 server for Systems Director database, then the choice is straightforward, you just need to install IBM Data Server Client.

If you are going to install DB2 server on the same system as Systems Director server, then there are two valid choices:

1. You can install one copy of DB2 server then create a client instance and a server instance from it. This option is easy to maintain since there's only one copy of DB2 to update or patch, but it is less flexible if, in the future, you want to move the database to a separate system or want to consolidate the database on another DB2 server. You would want to uninstall DB2 server to reclaim the license but that would break the DB2 client instance. Therefore, you end up having to maintain the server copy for the client instance.
2. You can install one copy of DB2 client for the client instance and one copy of DB2 server for the server instance. There is twice as much maintenance when it comes to update or patch, but you have the flexibility to move the database away when needed, uninstall or stop maintaining the server copy, without any impact to the DB2 client instance. This is the recommendation for an enterprise environment where you want to leave as much room as possible for future growth and potential consolidation.

So, the remainder of this article will use the second option which is slightly more work to setup, but the extra effort is well worth the agility that it provides.

Back to top

DB2 server installation

Installing DB2 server for Systems Director use is no different on a local or remote system. The instructions below assume that you have a GUI environment on AIX, which could be satisfied with VNC or a remote X server display.

To install a new DB2 server, do the following:

1. Ensure that you have 1GB of free space at the /home filesystem to hold the DB2 instance.
2. Create a new JFS2 file system (and logical volume) for the instance's database storage, for example at /db2inst1, 10 GB of size.

   You could skip this step and leave the database storage in the instance home directory. However, there's a risk that any other user who fills up the /home filesystem will cause the database to fail due to lack of free space, so it's safer for the database to be stored in its own filesystem.

3. Install DB2 server using the DB2 Installation Setup Wizard (db2setup) and create a server instance db2inst1 at the same time.

   Figure 4 shows a screen shot of the DB2 server instance setup wizard. It shows step 12 which is the summary of the wizard, with all default values, and the default button is the Finish button for running the actual task.

   
   
   Figure 4: DB2 Server Installation Wizard summary page
   
   
   

Note that on our POWER7 partition, we ran into Java core dump while starting the DB2 installation launchpad and the instance setup wizard, running "export JAVA_COMPILER=NONE" before the launchpad avoided the issue.

Once the installation is completed, you should have a DB2 instance created. Login as the instance owner with su - db2inst1.

1. Verify that the right DB2 level was installed at the right location:

   db2level

   
   
2. Update the default database path to /db2inst1 (instead of /home/db2inst1):

   db2 update dbm cfg using DFTDBPATH /db2inst1

   
   
3. Ensure that the following DB2 instance variables are set, if not add it using db2set command:

   DB2_WORKLOAD=TPM DB2COMM=tcpip DB2AUTOSTART=YES

   
   
4. Restart the database instance to pick up the change:
   db2stop
db2start
5. Create the database for Systems Director usage:

   db2 'create db DIRDB01 using codeset UTF-8 territory US pagesize 8192 with "Director database"'

   
   

   Actually the Systems Director database setup script can create the database, too. But, most database administrators would rather create the database themselves to assure that it's properly created at the right location. This does not harm the Systems Director script.

6. Try connecting to the database and list the tables:

   db2 connect to DIRDB01 db2 list tables for all

   
   
7. Verify that the database is indeed created in the preferred database path by looking if the directory /db2inst1/db2inst1/NODE0000/DIRDB01 exists and contain subdirectories.

Notice that in this example, I use the DB2 Server Fix Pack 5 so it is up to DB2 V9.5 FP5 after installation. If you would rather use the GA installation package, then you need to update it to fixpack 5 manually using DB2 Universal Fix Pack instead.

If you are using the downloaded DB2 Server Fix Pack, remember to extract the license file from the purchased installation media and apply it, otherwise the DB2 copy will expire after the 30 days trial period.

The previous instructions are not meant to be exhaustive, please consult the DB2 InfoCenter for detailed installation and configuration instruction if you're unfamiliar with DB2.

Now you need to create an account on AIX for the Systems Director database access and schema. Using the instance owner id "db2inst1" for database access is not recommended due to security reason. So we're going to create a regular user named "dirusr1", from root.

useradd -c 'Director db access & schema' -d /home/dirusr1 -g staff -m dirusr1

Assign a password to it, and clear the password expiration flag.

pwdadm dirusr1
pwdadm -c dirusr1

Back to top

DB2 client installation

Installing DB2 client is straightforward if you use the DB2 Installation Setup Wizard (db2setup) that allows you to install and create a client instance at the same time. The wizard will automatically propose to install DB2 client at an alternate directory name if the default location is already used by the DB2 server copy earlier.

In my case, the DB2 client copy is installed at /opt/IBM/db2/V9.5_02, and the instance db2admc1 is to be created after the installation. Figure 5 shows a screen shot of the DB2 client instance setup wizard. It shows step 8 which is the summary of the wizard, with all default values, and the default button is the Finish button for running the actual task.

After the installation and instance creation is completed, you can now catalog and connect to the database to validate this client instance.

su - db2admc1
db2 'catalog tcpip node LOCAL remote 127.0.0.1 server 50000 with "Local DB2 instance"'
db2 'catalog db DIRDB01 as LOCALDB at node LOCAL with "Local Director database"'
db2 connect to LOCALDB user dirusr1
db2 list tables

You should be able to connect to the database; there are no tables created yet. Now the DB2 client setup is completed.

Back to top

Preparing system environment

Before we can actually configure Systems Director to use DB2, there are some environment variables to set on the system.

Add the following lines into root's .profile so that it points to the DB2 client instance db2admc1 when running DB2 command:

# The following three lines are added for DB2 instance utilities.
if [ -f /home/db2admc1/sqllib/db2profile ]; then
    . /home/db2admc1/sqllib/db2profile
fi

export DB2_HOME=/home/db2admc1/sqllib/

This will make the DB2 command available to root after login. The variable DB2_HOME is specifically for Systems Director database setup command, it's not used by the DB2 command.

You can logoff and login to make the change effective, or sourcing the profile with this command

. ~/.profile

To verify that you have the proper environment variable setup, you can try to connect to the database DIRDB01 as shown earlier; it should work from root context now.

Back to top

Configure the database for Systems Director

Now we need to customize a configuration file to tell Director about the DB2 settings. Figure 6 shows the response file cfgdbcmd.rsp and a set of parameters pertaining to DB2, and its relationship with the two subsystems described in Figure 1. The parameter DbmsDatabaseName maps to the database name DIRDB01 in the DB2 server subsystem. The parameter DbmsUserId maps to the account dirusr1 used by Systems Director server subsystem for SQL query. The parameter DbmsDatabaseAppHome maps to the DB2 client instance directory, /home/db2admc1/sqllib, of the Systems Director server subsystem. The DbmsPassword could be left as is because it will be substituted by the encrypted value when you run the command configDB.sh later on.

Make a backup copy of the /opt/ibm/director/proddata/cfgdbcmd.rsp file first, then use your favorite text editor to open it. Put all the sections in remark (with ";") except the DB2 section, like this:

;===============================================================================
; DB2
;===============================================================================
DbmsApplication = DB2
DbmsTcpIpListenerPort = 50000
DbmsServerName = 127.0.0.1
DbmsDatabaseName = DIRDB01
DbmsUserId = dirusr1
DbmsPassword = xxxxx
DbmsDatabaseAppHome = /home/db2admc1/sqllib

The DbmsPassword value can remain as a dummy string because we use another utility to inject the encoded password into the file, with "/opt/ibm/director/bin/configDB.sh". The following listing shows the results of running configDB.sh to encrypt the database administrator password in the response file.

bash—3.2# /opt/ibm/director/bin/configDB.sh 
Enter the user name to use for connecting to the database: 
dirusr1 
Enter the password for the database user name: 

Verify the password for the database user name: 

Reading response file 
Encrypting password... 
Response file successfully encoded 
    

You should see a long encoded string in the DbmsPassword value in cfgdbcmd.rsp.

Now run the following command to configure the database for Systems Director:

/opt/ibm/director/bin/cfgdbcmd.sh -dbAdmin db2inst1 -dbLocal false

It first prompts for the password of db2inst1, then attach to the DB2 server instance to run a series of DB2 commands to configure the database. A successful run would yield the following final line:

return code from cfgdbcmd is 0

Note that cfgdbcmd.sh reports an error if the keyword in cfgdbcmd.rsp has any typo, to make sure all the required keywords are correct.

Now we must create the table structure in the database, which also wipes out the existing tables and data (if there's any) and start from scratch. Be careful before you run this command if you have important data in the current Systems Director repository.

/opt/ibm/director/bin/smreset

The following shows the results of a successful run of smreset.

CREATE INDEX I_WKF_FLW_DTYPE ON WKF_WORKFLOW (DTYPE) 
DB20000I The SQL command completed successfully. 

CREATE INDEX I_WKF_FLW_TCDRIVER ON WKF_WORKFLOW (TCDRIVER_ID) 

[ 7/6/10 1:07 AM ] DB20000I  The SQL command completed successfully. 

DB200001 The TERMINATE command completed successfully. 

[ 7/8/10 1:07 AM ] Database initialization completed successfully. 
[ 7/8/10 1:07 AM ] cfgdbcmd completed successfully. 
return code from cfgdbcmd is 0 
    
    

You can also validate the result by listing the tables under the schema dirusr1. There should be more than 300 tables in the list.

db2 connect to DIRDB01 user dirusr1
db2 list tables

Back to top

Try it out

Here is the moment of truth, start the Systems Director server, it should take a few minutes to start the first time.

/opt/ibm/director/bin/smstart

Then monitor for its readiness:

/opt/ibm/director/bin/smstatus -r
Inactive
Starting
Active

If it turns active, then you may login to the Systems Director console once again.

https://hostname:8422/ibm/console

To confirm that Systems Director server is using DB2, you can su to db2inst1, then run this command:

bash-3.2$ db2 list applications

Auth Id  Application    Appl.      Application Id                        DB       # of
         Name           Handle                                           Name    Agents
-------- -------------- ---------- ------------------------------------ -------- -----
DIRUSR1  java           1072       127.0.0.1.34651.100707172416          DIRDB01  1
DIRUSR1  java           1065       127.0.0.1.34619.100707172208          DIRDB01  1
DIRUSR1  java           1071       127.0.0.1.34650.100707172415          DIRDB01  1
DIRUSR1  java           1064       127.0.0.1.34617.100707172153          DIRDB01  1
DIRUSR1  java           1070       127.0.0.1.34628.100707172405          DIRDB01  1
DIRUSR1  java           1063       127.0.0.1.34616.100707172152          DIRDB01  1
DIRUSR1  java           1062       127.0.0.1.34612.100707172055          DIRDB01  1
DIRUSR1  java           1061       127.0.0.1.34610.100707172049          DIRDB01  1
DIRUSR1  java           1074       127.0.0.1.34788.100707172754          DIRDB01  1
DIRUSR1  java           1060       127.0.0.1.34609.100707172044          DIRDB01  1
DIRUSR1  java           1073       127.0.0.1.34652.100707172417          DIRDB01  1

At this point, it would be good to stop Systems Director server and take a backup of the clean database.

db2 backup db DIRDB01 to <any_backup_directory>

Back to top

Other considerations

One of the difficulty of having the DB2 instance and Systems Director server together is when we want to have both services start automatically at system startup.

On one hand, we need to set the DB2 instance to automatically starts, using this command:

/opt/IBM/db2/V9.5/instance/db2iauto -on db2inst1

On the other hand, we need to ensure that the LIBPATH variable is present when Systems Director server automatically starts, because at boot time the root profile is not run. There are two ways to do this:

• Define LIBPATH in /etc/environment, such as:

  LIBPATH=/usr/lib:/lib:/home/db2admc1/sqllib/lib64

  
  Since this is applicable to the entire system, it might cause conflict with other services on the system that relies on other DB2 instance.
• Define LIBPATH in the Systems Director startup script /etc/rc.d/init.d/smserver, like this:

  # For Systems Director server during system startup LIBPATH=/home/db2admc1/sqllib/lib64:$LIBPATH export LIBPATH

  
  

  This is safer for the system, but if you apply a Systems Director update in the future that replaces this script (unlikely for 6.2.x), then you'll have to modify it again. This is my recommended approach considering the cost and benefit.

We also notice that it takes quite some time for the DB2 Fault Monitor to start the DB2 instance, so most likely the Systems Director server startup script kicks in first before the database is ready. The Systems Director server is able to throttle for a few minutes while waiting for the database to come up, but you will see SQL errors in the Director server logs during that time, just don't panic yet.

Bottom line is, unless you absolutely want to have Director server starts up automatically, you could probably save yourself some hassle doing it manually.

Back to top

Conclusion

In this article, we have shown an end-to-end path to setup Systems Director server to use DB2 database, on a remote and local system. We explained the various options and our recommendation for achieving a robust, maintainable and flexible setup. We used AIX as illustration but it should be easily convertible to other UNIX® or Linux® platforms.

In future articles, we will show you how to update the DB2 copies (e.g. V9.5 FP6), upgrade to new release (e.g. V9.7), and move the database to a remote system with minimal downtime and no impact to other subsystems. But if you're an experienced DB2 administrator, you might have already figured it out while reading this article.

Resources

Learn

• IBM Systems Director 6.2 InfoCenter
  
  
• IBM DB2 V9.5 InfoCenter
  
  

Discuss

• Follow developerWorks on Twitter.
  
  
• Get involved in the My developerWorks community.
  
  
• Participate in the AIX and UNIX® forums:
  • AIX Forum
  • AIX Forum for developers
  • Cluster Systems Management
  • Performance Tools Forum
  • Virtualization Forum
  • More AIX and UNIX Forums
  
  

About the authors

CheKim Chhuor currently works at IBM China Systems and Technology Lab, at Shanghai, in the IBM Systems Director testing team. He has previously worked at IBM Poughkeepsie on various system management products. He also worked at IBM Montreal as a consultant. He has many years of web infrastructure consulting experience, and holds many IBM certifications on WebSphere, DB2, and On Demand Business. His current focus is on platform management technologies and systems architecture. You can reach him at chhuor@cn.ibm.com.

Xiao Zhi Yan currently works at IBM China Systems and Technology Lab, at Shanghai, in the IBM Systems Director testing team. He has worked for IBM Systems Director testing for two years. His current focus is on platform management technologies and systems oriented technologies. You can reach him at xzhiyan@cn.ibm.com.

Peng Peng Wang currently works at IBM China Systems and Technology Lab, at Shanghai, in the IBM Systems Director testing team. He has previously worked at IBM GBS as an IT Specialist. His current focus is on platform management technologies and systems oriented technologies. You can reach him at wppeng@cn.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Transition process from Derby to DB2
• Test environment description
• Installing Systems Director server with default options
• DB2 installation planning
• DB2 server installation
• DB2 client installation
• Preparing system environment
• Configure the database for Systems Director
• Try it out
• Other considerations
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: DB2 Enterprise
• Demo: Create an electronic form solution with DB2 pureXML and Lotus Forms
• Community: DB2
• Buy: DB2 Enterprise

Dig deeper into AIX and UNIX on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers