Print-friendly Version

Deploying IBM DB2 UDB V8.2.x in Containers in the Solaris 10 OS

Cherry Shu, October 2006

Abstract: This article provides guidelines for running IBM DB2 UDB v8.2.x in non-global zones under the Solaris 10 OS using Solaris Containers technology.

Contents:

• Solaris Containers
• Installing DB2 UDB in Solaris Containers
• Deciding on a Zone Configuration for DB2 UDB
• Installing the Zone
• Booting the Zone
• Installing DB2
• Setting IPS Facilities for DB2 Through Resource Controls
• Special Considerations
• File Systems
• Raw Devices
• Volume Management
• Resource Pools
• DB2 Deployment Scenarios
• Summary
• Additional Resources

DB2 UDB and DB2 Connect v8.2.2 and later products have been certified to run in a global zone using Containers technology in the Solaris 10 OS. This document concentrates on running DB2 UDB and DB2 Connect products in a non-global zone using Solaris Containers and explains in detail the process of creating a non-global instance of Solaris Containers appropriate for deploying a DB2 database. As a supplement to existing product documentation for DB2 planning, installation. and deployment from IBM, only the important step-by-step guidelines for the Solaris 10 OS will be summarized here. Additionally, this article captures special considerations for running DB2 UDB in a non-global zone using Solaris Containers.

Solaris Containers

Containers in the Solaris 10 OS provide a virtualized runtime environment, within which one or more applications can run without affecting or interacting with the rest of the system. Solaris Containers include two important technologies: Solaris Zones partitioning technology and Resource Management tools. Solaris Zones provide the application environment boundaries for Solaris Containers, while the resource management framework creates resource boundaries for each application. These resource boundaries can limit CPU or memory consumption, network bandwidth, or even be a processor set.

Solaris Zones provide virtual mappings from software services to platform resources, and allow applications to be isolated from each other even though they share a singe Solaris OS instance. The two types of zones are global and non-global.

The global zone encompasses the entire system. The administrator of the global zone can control the system as a whole. The global zone always exists. Inside the global zone are non-global zones. These zones are isolated from the physical hardware of the machine by the virtual platform layer. Certain constraints are applied to the non-global zone processes to achieve container isolation.

Because Solaris Containers include Zones technology, this paper will use "Containers" as the name for the complete virtualized environment and "Zones" only when needed for clarity.

Communications between containers use the same standard interfaces, such as the network stack and shared file systems, that are used in communications between separate systems. Should an error occur in a container, it is designed as a blast shield that isolates and localizes the effects to just the services running in that container and not in any other part of the system. In the unlikely event that an error is so severe that it would normally cause a server to reboot, the error would instead affect only the container in which it occurred. The affected container can restart, automatically or manually, without affecting any other containers or services in the system and without the inconvenience and downtime normally associated with a full system restart.

Because Zones provide a complete virtual OS, Solaris Containers will appear to be completely separate systems from a user's perspective. In order for a user to access a container, the user must have a valid user ID and use it to log in to the container in the same way as with any separate system. Any administrative users must also have privileged access to their containers, and the privileged access is limited to the container which it is provided for. Thus, workloads in a container will be protected from common manual errors, such as unintentionally shutting down all databases instead of only a specific database instance. This separation also applies to common operating system tools. When used in a container, tools such as ps, which normally lists all processes running on a system, will list only processes running in the container, assuring the same level of security that would be expected between systems.

Major Benefits of Solaris Containers

Reduced management costs: Applications can be more safely consolidated onto fewer servers, resulting in reduced management complexity and costs through reductions in OS instances and associated software licensing fees.

Increased resource utilization for lower cost of operations: Dynamic resource reallocation improves resource utilization by allowing unused resources to be shifted to other Containers as needed. In addition, with fault and security isolation provided by Solaris Containers, applications with unpredictable workloads no longer require a dedicated and underutilized system, but may now be safely consolidated with other applications.

Improved service availability: Fault isolation and security isolation protect applications from error propagation as well as intentional or unintentional intrusions that can affect performance or availability. The greater consistency and simplicity of this environment also reduces the chance of human errors that might impact availability.

Increased flexibility: Solaris Containers can make it safer for businesses to implement server consolidation with less worry about applications being affected by resource constraints, faults, or security issues. Also, Solaris Containers are easy to reconfigure and can greatly simplify the task of migrating applications from one set of hardware to another.

Installing DB2 UDB in Solaris Containers

With Zones technology, multiple zones can be created on a single system and each zone can be configured to execute a separate instance of DB2 UDB. Each zone is a virtualized OS environment with its own private name spaces that can be managed independently. For an instance, the db2inst1 user in one zone is a completely different user from the db2inst1 user in another zone. Each can have different UIDs, passwords, home directories, and so on. By running each DB2 instance in its own zone, the instances can be completely isolated from each other. From the point of view of a DB2 instance, it still runs on a dedicated system.

This section provides instructions for creating Solaris Containers appropriate for installing and running DB2 UDB.

1. Deciding on a Zone Configuration for DB2 UDB

Solaris Zones require approximately 100 Mbytes of disk space, and the DB2 UDB v8.2.x ESE software and a DB2 instance each require about 1 Gbyte of disk space.

The following resource types can be configured for a non-global zone:

• inherit-pkg-dir: System directories loop-back mounted to the zone
• fs: File systems to be mounted in the non-global zone
• net: Network interface to be plumbed to the zone
• device: Devices to be exposed to the zone
• rctl: The resource controls to be enabled
• pool: The name of the resource pool to which the zone is bound

Here is a sample zone configuration where the zone name is db2-zone1. A virtual network interface with IP address 199.0.1.12 is set on the hme0 interface of the global zone.

global # zonecfg -z db2-zone1
db2-zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:db2-zone1> create
zonecfg:db2-zone1> set zonepath=/export/zones/db2-zone1
zonecfg:db2-zone1> set autoboot=true
zonecfg:db2-zone1> add net
zonecfg:db2-zone1:net> set address=199.0.1.12/24
zonecfg:db2-zone1:net> set physical=hme0
zonecfg:db2-zone1:net> end
zonecfg:db2-zone1>verify
zonecfg:db2-zone1>commit
zonecfg:db2-zone1>exit

The zone configuration is now complete. An XML file, /etc/zones/db2-zone1.xml, has been created to store the zone configuration data.

Besides using zonecfg(1M) in interactive mode to set the configurations using subcommands, zonecfg also provides a command-file mode that takes input configuration data from a script file specified by the -f option.

Create a script to configure the zone named db2-zone1.

global # vi /export/zones/zone1.cfg

#script to create zone to run DB2
create
set zonepath=/export/zones/db2-zone1
set autoboot=true
add net
set address=199.0.1.12/24
set physical=hme0
end 
verify
commit
#end of script

Create a zone with zonecfg from the script file that contains the zone configuration data.

global # zonecfg -z db2-zone1 -f /export/zones/zone1.cfg

2. Installing the Zone

Here is how to install the zone:

# zoneadm -z db2-zone1 install

Preparing to install zone <db2-zone1>.

Creating list of files to copy from the global zone.

Copying <12704> files to the zone.

Initializing zone product registry.

Determining zone package initialization order.

Preparing to initialize <785> packages on the zone.

Initialized <785> packages on zone.

Zone <db2-zone1> is initialized.

The file </export/zones/db2-zone1/root/var/sadm/system/logs/install_log>
contains a log of the zone installation.

3. Booting the Zone

global# zoneadm -z db2-zone1 boot

For first boot of a zone after installation, the standard system identification questions such as the naming schemes, locale or time zone, or root password, must be answered by accessing the zone's console. This should be done using the zlogin(1M) command.

global# zlogin -C db2-zone1

It is possible to skip the system identification questions during the first boot of the zone by creating a sysidcfg file in the zone prior to the first boot. The location of the sysidcfg file from the global zone is /export/zones/db2-zone1/root/etc/sysidcfg. A sample sysidcfg file for db2-zone1 is as follows:

global # cat /export/zone/db2-zone1/root/etc/sysidcfg
system_locale=C
timezone=US/East
network_interface=primary {
hostname=db2zone2
terminal=xterm
security_policy=NONE
name_service=NIS {
domain_name=east.sun.com
}
root_password=sS3G0h84sqwJA

After setting the system identification and root password, the zone is ready for use. The zone now can be accessed over the network using the telnet(1), rlogin(1), or ssh(1) commands, just like a standard Solaris OS system. Or you can use zlogin(1M) from the global zone to log into the non-global zone.

global# zlogin -l root db2-zone1

4. Installing DB2

The next step is to install DB2 UDB in db2-zone1.

db2-zone1# cd ${DB2_DIST}
 
db2-zone1# ./db2setup

Follow the DB2 installation wizard to install DB2 and create a DB2 instance named db2inst1.

5. Setting IPS Facilities for DB2 Through Resource Controls

In previous Solaris releases, IPC facilities were controlled by kernel parameters. You had to modify the /etc/system file and reboot the system to reflect the changes. The /etc/system file is deprecated in the Solaris 10 OS and it is only kept for backward compatibility. There is no /etc/system file in non-global zones.

In the Solaris 10 release, many kernel tunable parameters including System V IPC settings are either automatically configured or can be controlled by resource controls. IPC facilities such as shared memory, message queues, and semaphores can be set on a per-project or per-user basis in the global zone and non-global zones. Their configurations can be modified using the prctl(1M) command while the system is running.

The DB2 instance db2inst1 is created after the installation of db2setup. To set the resource controls for db2inst1, you need to create a custom project for user db2inst1.

db2-zone1# projadd -c "DB2 instance 1" user.db2inst1 

A project named user.db2inst1 is created to serve as the default project for the user db2inst1. A new project entry is added to the local project database stored at /etc/project. The id(1M) command can be used to verify the default project for the db2inst1 user.

db2-zone1# su - db2inst1

$ id -p

uid=7001(db2inst1) gid=707(db2iadm1) projid=4567(user.db2inst1) 

$ exit

DB2 provides a utility called db2osconf to generate the recommended values for IPC tunables on the Solaris platform. db2osconf can only be run from the global zone.

global# cd /export/zones/db2-zone1/root/opt/IBM/db2/V8.1/bin 
global# ./db2osconf 

set msgsys:msginfo_msgmni = 6144 
set semsys:seminfo_semmni = 7168 
set shmsys:shminfo_shmmax = 9578697523 
set shmsys:shminfo_shmmni = 7168 

Total kernel space for IPC: 
0.98MB (shm) + 1.71MB (sem) + 2.08MB (msg) == 4.77MB (total) 

Log in to db2-zone1 and set resource controls according to the value generated by db2osconf.

db2-zone1# projmod -s -K "project.max-shm-
memory=(privileged,9578697523,deny)" user.db2inst1 
db2-zone1# projmod -s -K "project.max-shm-ids=(privileged,7168,deny)" 
user.db2inst1
db2-zone1# projmod -s -K "project.max-msg-ids=(privileged,6144,deny)" 
user.db2inst1 
db2-zone1# projmod -s -K "project.max-sem-ids=(privileged,7168,deny)" 
user.db2inst1 

The new tunable settings are added to the project database for project user.db2inst1.

db2-zone1#cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
user.db2inst1:4567::::project.max-
shm-memory=(privileged,9578697523,deny);project.max-shm-
ids=(privileged,7168,deny);project.max-msg-
ids=(privileged,6144,deny);project.max-sem-
ids=(privileged,7168,deny);

You can also make these changes using the prctl command, but the settings will not persist.

db2-zone1# prctl -n project.max-shm-memory -v 9578697523 -r -i project 
user.db2inst1 
db2-zone1# prctl -n project.max-shm-ids -v 7168 -r -i project user.db2inst1
db2-zone1# prctl -n project.max-msg-ids -v 6144 -r -i project user.db2inst1 
db2-zone1# prctl -n project.max-sem-ids -v 7168 -r -i project user.db2inst1 

To verify the resource control, the id and prctl commands can be used to examine the new settings.

db2-zone1# su - db2inst1 
$ prctl -i project user.db2inst1 

Special Considerations

Here are some special considerations when running DB2 UDB using Solaris Containers technology.

File Systems

Each zone has its own file system hierarchy rooted at zone root. Processes in the zones can access only files in the part of the hierarchy that is located under the zone root. Only the global zone administrator has the privilege to create new devices, and then export devices to the local zones. The zone administrator can create new file systems on the devices that exported from the global zone and mount them from the local zone.

The following presents four different ways of mounting a file system from the global zone to a local zone:

1. Create a file system in the global zone and mount it in the local zone as a loopback file system (lofs).

a. Create a file system and mount the file system in the global zone.

global# newfs /dev/rdsk/c1t4d0s0
global# mount /dev/dsk/c1t4d0s0 /myfs

b. Modify the zone configuration to export the file system to the local zone.

global# zonecfg -z db2-zone1

zonecfg:db2-zone1>add fs
zonecfg:db2-zone1:fs>set dir=/usr/myfs
zonecfg:db2-zone1:fs>set special=/myfs
zonecfg:db2-zone1:fs>set type=lofs
zonecfg:db2-zone1:fs>end

2. Create a file system in the global zone and mount it to the local zone as UFS.

a. Create a file system in the global zone.

global# newfs /dev/rdsk/c1t4d0s0

b. Add the file system of type UFS to the local zone.

global# zonecfg -z db2-zone1

zonecfg:db2-zone1>add fs
zonecfg:db2-zone1:fs>set dir=/usr/myfs
zonecfg:db2-zone1:fs>set special=/dev/dsk/c1t4d0s0
zonecfg:db2-zone1:fs>set raw=/dev/rdsk/c1t4d0s0
zonecfg:db2-zone1:fs>set type=ufs
zonecfg:db2-zone1>end 

3. Export a device from the global zone to a local zone and mount it.

global# zonecfg -z db2-zone1

zonecfg:db2-zone1>add device
zonecfg:db2-zone1:device>set match=/dev/rdsk/c1t4d0s0
zonecfg:db2-zone1:device>end 
zonecfg:db2-zone1>set match=/dev/rdsk/c1t4d0s0
zonecfg:db2-zone1>end 

Repeat the add subcommand to add multiple devices.

Log in as local zone administrator, create a file system in the local zone, and mount it.

db2-zone1# newfs /dev/rdsk/c1t4d0s0
db2-zone1# mount /dev/dsk/c1t4d0s0 /usr/myfs

4. The device is already made available to the local zone. Mount a UFS file directly into the local zone's directory structure.

db2-zone1# mount /dev/dsk/c1t4d0s0 /usr/myfs

Raw Devices

To guarantee that the security and isolation are not compromised, certain restrictions regarding devices are placed in Solaris Containers. Devices that expose system data such as dtrace, kmem, and ksysm are not available in Solaris Containers. By default, physical devices are also not accessible by Solaris Containers.

The system administrator can make physical devices available to local zones. It is the system administrator's responsibility to ensure that system security is not compromised by doing so, mainly for the following reasons:

• Placing a physical device in more than one zone can create a covert channel between zones and hence breaks the zone isolation.
• Global zone applications that use such a device risk the possibility of compromised data or data corruption by a local zone.

The system administrator can use the add device subcommand of zonecfg to export devices in a local zone.

global# zonecfg -z db2-zone1

zonecfg:db2-zone1>add device
zonecfg:db2-zone1:device>set match=/dev/rdsk/c1t4d0*
zonecfg:db2-zone1:device>end 
zonecfg:db2-zone1>set match=/dev/rdsk/c1t4d0*
zonecfg:db2-zone1>end 

All the slices of /dev/dsk/c1t40d0 are added to the local zone.

Volume Management

Volume managers cannot be installed or managed from Solaris Containers. Currently, the recommended approach is to install and manage volume manager products from the global zone. The system administrator is responsible for creating the devices, file systems, and volumes. Once these are created in the global zone, they can be made available to the Solaris Containers by using zonecfg subcommands.

In the case of VERITAS, VERITAS Volume Manager does not support local zones. In local zones, a VERITAS file system (VxFS) is supported and is mounted as a loopback file system.

Solaris Volume Manager should also be installed and managed from the global zone. Once the storage has been configured in the desired way from the global zone, the meta devices can be made available to the local zones.

Resource Pools

It may be desirable to establish the appropriate CPU resource boundaries to partition the resources. The Solaris 10 OS adds the capability to dynamically adjust the resource allocations in response to application load changes in order to meet system performance goals set by administrators.

The guarantee for minimum and maximum CPU capability can be ensured by using Dynamic Resource Pools and the Fair Share Scheduler. Resource Pools provide hard upper and lower bounds at the granularity of a CPU. They can be bound to Solaris Containers. Fair Share Scheduler can be further used inside the container to distribute CPU resources according to the shares.

On April 26, 2006, IBM announced the subcapacity licensing for DB2 and other IBM software products on x86 servers. Solaris 10 Container is eligible as a licensable entity, which means DB2 customers running DB2 in a Solaris 10 OS environment can license only the CPUs or cores that are assigned in a Solaris Container.

DB2 Deployment Scenarios

DB2 UDB v8.2.x can be installed on a Solaris 10 system following either of these approaches:

• Install DB2 UDB v8.2.x in the global zone; no local zones will be created later on the system.
• Create local zones and install DB2 UDB v8.2.x directly in the local zones.

Suppose a Solaris 10 system has DB2 UDB v8.2.x installed in the global zone: If a new local zone is subsequently created on the system, as part of the zone installation, a DB2 UDB pre-installation script will try to remove the /opt/IBM/db2/V8.1 directory in the global zone, which makes DB2 UDB v8.2.x unavailable in the global zone.

On a Solaris 10 system that has local zones deployed, if an attempt is made to install DB2 UDB v8.2.x in the global zone, the installation will fail with the following error message:

"pkgadd: ERROR: unable to get inherited directories: zonecfg_setipdent: Bad handle"

The recommended approach is to install DB2 UDB in the local zones directly. The only DB2 utility that does not work properly in Solaris Containers is the db2osconf utility, which is used to generated tunable kernel parameters optimal for DB2. Because db2osconf requires access to /dev/kmem, which is not available from Solaris Containers, the workaround is to run db2osconf in the global zone and set the tunable kernel parameters through resource controls in the container.

Summary

Solaris Containers technology provides facilities to improve application-level service management by partitioning a single system into several independent execution environments. Solaris Containers are secure, flexible, lightweight, and easy to implement, and they can provide optimized environments to consolidate DB2 UDB and other web-facing applications.

Additional Resources

Sun Manuals

System Administration Guide: Solaris Containers-Resource Management and Solaris Zones

Solaris Tunable Parameters Reference Manual

Sun BluePrints Articles

Solaris Containers -- What They Are and How to Use Them (pdf)

Slicing and Dicing Servers: A Guide to Virtualization and Containment Technologies (pdf)

Restricting Service Administration in the Solaris 10 Operating System (pdf)

Sun White Papers

Solaris Containers: Server Virtualization and Manageability (pdf)

IBM Documents

Considerations for Installing DB2 UDB Version 8 Products on Solaris Operating Environment 10 Systems

Common Criteria Certification: Installing DB2 Universal Database Enterprise Server Edition and DB2 Universal Database Workgroup Server Edition (pdf - 312 pages)

IBM DB2 Universal Database: Installation and Configuration Supplement (pdf)

Sub-capacity Licensing for Select IBM Passport Advantage Eligible Programs Running on x86 Servers Helps Improve Flexibility and Price/Performance (pdf)

About the Author

Cherry Shu, a member of technical staff at Marketing Development Engineering at Sun Microsystems, assists independent software vendors with technology adoption, porting, and performance-tuning projects on Solaris platform.

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.