Setup and configuration
The configuration process is similar to that described in the previous sections in this chapter for clustering hardware, networks, and software. We highlight the differences here.
WebSphere uses two databases: the persistent sessions database for HTTP sessions, and the application database for Entity EJBs and others.
The HTTP persistent sessions database usually does not contain enough data to benefit from database partitions. The small overhead of coordinating partitions in a DB2 UDB EEE instance may incur a minor performance penalty. However, the application database may be big enough for many customers to benefit from database partitions across several nodes in a cluster.
Since the WebSphere application database is a multiple-partition database and physically resides on multiple nodes, the steps for defining the corresponding data source are different. The custom properties are needed to define the coordinator node (cnode). This is a DB2-specific connection attribute for DB2 UDB EEE. We chose the first node as a coordinator node (cnode=0) to catalog. You can choose any node as a coordinator node, for example cnode=0, cnode=1 or cnode=2.
You must modify the generated DDL file for container-managed persistence (CMP) EJBs developed using the "top-down" approach, because the generated DDL does not define the partition key required for DB2 UDB EEE.
You need to modify the WebSphere application deployment generated table DDL to include the partitioning key. The modified sample DDL file is shown in Example 12-11.
Example 12-11 Sample DDL file modified for DB2 UDB EEE partitioning
CREATE TABLE MyCMPBean (
group INTEGER,
country VARCHAR(3) NOT NULL,
name VARCHAR(20) NOT NULL,
phone VARCHAR(12) NOT NULL,
age INTEGER,
city VARCHAR(15))
partitioning key (country) IN TABLESPACE ptb);
ALTER TABLE MyCMPBean ADD Constraint MyCMPBeanPK PRIMARY KEY (country, name, phone);
Now we have defined the partitioning key as country, a part of the primary key. Remember that the partitioning key must be a subset of the primary key or you will get an error. It is very important to choose the partitioning key, since it can impact performance. Partitioning the database by country, incidentally, is a common practice.
As listed in Table 12-2, each partition runs in its first preference host if there are no failures, and the configuration file looks like this:
0 host1 host1 0 10.1.1.11
1 host2 host2 0 10.1.1.12
2 host3 host3 0 10.1.1.13
Table 12-2
| DB2 Partition | First Preference | Second Preference |
|---|---|---|
| DB2 Partition 1 | Host1 | Host4 |
| DB2 Partition 2 | Host2 | Host4 |
| DB2 Partition 3 | Host3 | Host4 |
Failover preference of DB2 partitions
When host2 fails, the partition 2 is moved to host4 with the same IP address and the same disks as:
0 host1 host1 0 10.1.1.11
1 host4 host4 0 10.1.1.12
2 host3 host3 0 10.1.1.13
Similarly, we can configure multiple partitions in a host, and mutual takeover. If more than one partition uses a host, then different ports are used to avoid any conflicts. The simplest configuration is to configure two or more partitions in a two-node system with mutual failover.
Please note that the failover discussed here for DB2 UDB EEE is an IP-based failover that takes over the resource group and IP address. DB2 UDB EEE itself doesn't provide HA for data access since the share-nothing architecture is used. With the assistance of such clustering software as HACMP, ServiceGuard, VERITAS Cluster, or Microsoft Cluster, DB2 UDB EEE can provide both scalability and high availability.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.