Setting up IBM DB2 database for IBM Systems Director 6.2

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

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 commandulimit -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.

   • • • • 1. Finished processing all filesets. (Total time: 26 mins 28 secs)

           2. Finished processing all filesets. (Total time: 26 mins 38 secs)

           3. +---------------------------------------------------------------------+

           4. Summaries:

           5. +---------------------------------------------------------------------+

           6. Installation Summary

           7. --------------------

           8. Name Level Part Event Result

           9. -----------------------------------------------------------------------

           10. DirectorServer 6.2.0.0 USR APPLY SUCCESS

           11. DirectorServer 6.2.0.0 ROOT APPLY SUCCESS

           12. This installation log file can be found in /var/log/dirinst.log.

           13. 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:

   • • • • 1. Configuring Resource Manager and Common Agent.

           2. Starting Agent Manager... OK

           3. Retrieving Agent Manager Instance ID... OK

           4. Registering Agent Manager toolkit... OK

           5. Removing Agent Manager user manager... OK

           6. Adding Agent Manager user root... OK

           7. Configuring Common Agent... OK

           8. Waiting for Common Agent certificates... OK

           9. Waiting for Common Agent SLP advertisement... OK

           10. Waiting for Common Agent status report... OK

           11. Stopping Agent Manager... OK

           12. 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:

   • • • • 1. Inactive

           2. Starting

           3. Active

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

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.

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.

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.

   1. 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.

   1. 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.

   2. 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:

   1. 1. 1. 1. 1. db2level

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

   1. 1. 1. 1. 1. db2 update dbm cfg using DFTDBPATH /db2inst1

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

   1. 1. 1. 1. 1. DB2_WORKLOAD=TPM

               2. DB2COMM=tcpip

               3. DB2AUTOSTART=YES

4. Restart the database instance to pick up the change:

• 1. db2stop

  2. db2start

5. Create the database for Systems Director usage:

   1. 1. 1. 1. 1. db2 'create db DIRDB01 using codeset UTF-8 territory US pagesize 8192

               2. with "Director database"'

• • 1. 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:

   1. 1. 1. 1. 1. db2 connect to DIRDB01

               2. 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.

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

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

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

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:

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

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:

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.

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:

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:

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.

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

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

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.

Then monitor for its readiness:

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

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

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

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:

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.

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.