Deploy and explore the DB2 10 pureScale Feature on WebSphere Application Server V8

The IBM® DB2® pureScale® Feature is designed for continuous availability and tolerance of both planned maintenance and unplanned accidental component failure. DB2 pureScale is a separately priced feature for both IBM DB2 Enterprise Server Edition and DB2 Advanced Enterprise Server Edition. This article describes how to deploy the DB2 10.1 pureScale Feature with IBM WebSphere® Application Server (WAS) V8.0.0.1, and also explores the client reroute and workload balancing (WLB) capabilities by using a WAS application. We also examine how a DB2 pureScale cluster recovers from a failure and the impacts on WAS applications. You can apply the information from this article to WAS V8.5.

Share:

Yiying Zhang (yiyingz@ca.ibm.com), DB2 Quality Assurance, IBM

Photo of Yiying ZhangYiying Zhang is an IBM certified Advanced Database Administrator. She has been working with IBM for 8 years on the DB2 database, focusing on system verification testing. She has over 10 years of experience in integrating DB2 with various WebSphere products.



Aslam Nomani (aslam@ca.ibm.com), STSM, DB2 Quality Assurance, IBM

Aslam NomaniAslam Nomani has been with IBM for 14 years, with most of that time spent with the Quality Assurance team. His main area of focus has been on high availability and disaster-recovery solutions. Over the past several years, Aslam has been the Quality Assurance Architect for the DB2 pureScale Feature.



Mei-hsiang Chang (meichang@us.ibm.com), WebSphere System Verification Test, IBM

Photo of Mei-hsiang ChangMei-hsiang Chang has been working at IBM for 14 years with WebSphere Application Server System Verification Test. She has been involved with WAS releases since Component Broker, 4.0 up to now 8.5 with Liberty. She has a wide range of testing skills, including long run stress and JVM memory analysis. She is currently leading the Datasek Trust Company (DAT) persona to highlight the focus testing (security, high transaction) on the related customer model.



Fran Beaulne (fbeaulne@ca.ibm.com), DB2 Quality Assurance, IBM

Photo of Fran BeaulneFran Beaulne has been with IBM for 12 years. She was a release manager for several of the early years, and she also serves as QA manager with a focus on the DB2 pureScale feature.



25 July 2013

Also available in Chinese

Introduction to the DB2 pureScale Feature

Based on the familiar and proven design features from DB2 for z/OS® database software, IBM introduced the DB2 pureScale Feature in December 2009 to provide the current highly competitive and demanding marketplace with the following key benefits: extreme capacity, application transparency, continuous availability, and reduced total cost of ownership.

Extreme capacity

The DB2 pureScale Feature provides extreme capacity by enabling the addition and removal of members on demand. The DB2 pureScale Feature can scale up to 128 members. It has a highly efficient, centralized management facility that allows for very efficient scale-out capabilities. The DB2 pureScale Feature also leverages a technology called Remote Direct Memory Access (RDMA) that provides a highly efficient internode communication mechanism to augment its scaling capabilities.

Application transparency

An application that runs in a DB2 pureScale environment does not need to have any knowledge of the different members in the cluster. The DB2 pureScale Feature automatically routes applications to the members deemed most appropriate. The DB2 pureScale Feature also provides native support for syntax that other database vendors use, which enables those applications to run in a DB2 pureScale environment with minimal or no changes.

Continuous availability

The DB2 pureScale Feature provides a fully active-active configuration such that if one member goes down, processing continues at the remaining active members. During a failure, only data being modified on the failing member is temporarily unavailable until database recovery completes for that set of data, which is very quick. This is an advantage over some competing solutions in which an entire system freeze occurs as part of the database recovery process.

Reduced total cost of ownership

The DB2 pureScale interfaces easily handle the deployment and maintenance of components integrated within the DB2 pureScale Feature. This helps reduce what might amount to steep learning curves associated with deploying and maintaining with some competing technologies.

Figure 1. DB2 pureScale Feature topology overview
DB2 pureScale Feature topology overview

Integrated system

DB2 pureScale does not just provide technical advantages; the integration with other IBM-leading technologies also gives customers more value. Integrated systems means lower initial purchase costs, easier deployment, single-number support, and optimized performance.

The integration of WebSphere Application Server and DB2 has been a solution for enterprise applications for many years. The tight integration promotes IBM leadership on providing an end-to-end application and resource management system. With the DB2 pureScale capabilities of continuous availability, you can implement the enterprise systems with virtually no downtime. The integration makes both the database and the application ready. With the integration, a client loads data onto DB2 pureScale and gets that database ready for applications; at same time, the application is loaded on WebSphere and running with the database on the same environment. This reduces cost, complexity, and time to give client extra value.

Figure 2 is an integrated WAS and DB2 pureScale system. There are multiple members in the DB2 pureScale system, but there is still a single database view. WebSphere applications can connect to any member of the pureScale system the same way they connect to a DB2 Enterprise Server Edition (ESE) system.

This article introduces the deployment, workload balancing, and failure recovery in an integrated environment of DB2 10 pureScale Feature and WebSphere Application Server V8.

Figure 2. Integrated WAS and DB2 pureScale system
Integrated WAS and DB2 pureScale system

Deploying the DB2 10 pureScale Feature to WAS V8

This section shows how to deploy the DB2 pureScale Feature with a stand-alone WAS instance by configuring a data source with custom properties to enable the automatic client reroute and workload balancing features. The example used in this article is based on the following setup:

  • IBM WebSphere Application Server V8.0.0.1
  • DB2 v10.1.0.2
  • The DB2 pureScale cluster has two members and two pureScale servers

This article does not explain the installation of DB2 pureScale Feature and WAS. For that information, refer to the Resources section.

Data source configuration in WAS admin console

The data source configuration against DB2 pureScale server is the same as that against a DB2 ESE server. To configure the data source, access the WAS administration console and click Resources > JDBC.

Note the following :

  • Only DB2 Universal JDBC Driver (JCC driver) type 4 is supported.
  • The recommended JCC driver version is V97 FP3 or above.

Use the following steps to create a brand new data source to connect to the database server in a DB2 pureScale environment. You can also modify the current existing data sources accordingly.

Step 1. Create the JDBC driver

  1. Click Resources > JDBC > JDBC Providers from the left panel of the WAS admin console.
  2. Choose the following options (shown in Figure 3):
    • Database type: DB2
    • Provider type: DB2 Universal JDBC Driver Type
    • Implementation type: XA data source (if two-phase commit is required) or Connection pool data source
  3. Specify the CLASSPATH of the DB2 Universal JDBC Driver, as shown in Figure 4. The CLASSPATH is where the DB2 Universal JDBC Driver is installed.
  4. Click Finish on the summary page, and save the changes.
Figure 3. Create a new JDBC Provide by choosing DB2 Universal JDBC Driver Provider
Create a new JDBC Provide by choosing DB2 Universal JDBC Driver Provider
Figure 4. Specify the CLASSPATH for the JDBC driver
Specify the CLASSPATH for the JDBC driver

Step 2. Create a new data source

  1. Click Resources > JDBC providers > Data sources on the left panel of the WAS Admin Console.
  2. Click DB2 Universal JDBC Driver Provider (XA) (we just created) on the right panel of the WAS Admin Console shown as Figure 5.
  3. Click Data sources under Additional Properties on the right panel of the WAS Admin Console.
  4. Click New… to create a new data source.
  5. Enter DB2 Universal JDBC Driver XA DataSource as the data source name and jdbc/Test as the JNDI name. Figure 6 shows the first page for creating a new data source.
  6. Enter the database specific information for the data source, as the example shown in Figure 7.
    • Driver type: 4 (it must be 4)
    • Database name: TEST
    • Server name: coralpib87.torolab.ibm.com (in this example)

      Note: The server name can be any member node in the pureScale cluster.

    • Port number: 38610 (in this example)
  7. Set up the security aliases as needed.
  8. Click Finish on the summary page, and save the changes.
Figure 5. Choose by which JDBC driver the Data source will be created
Choose by which JDBC driver the Data source will be created
Figure 6. Specify the basic information for the data source
Specify the basic information for the data source
Figure 7. Enter the database specific properties for the data source
Enter the database specific properties for the data source

Step 3. Modify the data source connection pool property to enable WAS to support seamless ACR

  1. Click Resources > JDBC > JDBC providers from the left panel of WAS Admin Console.
  2. Click DB2 Universal JDBC Driver Provider (XA) (we just created) under JDBC providers from the right panel of WAS Admin Console.
  3. Click Data sources under Additional Properties from the right panel of WAS Admin Console.
  4. Click DB2 Universal JDBC Driver XA DataSource (we just created) from the right panel of WAS Admin Console.
  5. Click Connection pool properties under Additional Properties from the right panel WAS Admin Console.
  6. Select FailingConnectionOnly from the drop-down list of Purge policy, as shown in Figure 8.
  7. Click Apply, and save the changes.
Figure 8. Modify the property of Purge policy to enable WAS for seamless ACR
Modify the property of Purge policy to enable WAS for seamless ACR

For Java client applications, failover for automatic client reroute can be seamless or non-seamless. With non-seamless failover, when the client application reconnects to another server, an error is always returned to the application, to indicate that failover (connection to the alternate server) occurred. With seamless failover, the driver does not return an error if a connection failure and successful reconnection to an alternate server occur during execution of the first SQL statement in a transaction.

The property of Purge Policy specifies how to purge connections when a stale connection or fatal error is detected. The default is EntirePool, which means all connections in the pool are marked stale. FailingConnectionOnly means only the connection that caused the StaleConnectionException is closed. To enable WAS to support the seamless automatic client reroute, the Purge Policy with FailingConnectionOnly should be set.

Step 4. Add the custom property for the data source to enable Workload Balancing

DB2 pureScale environment provides the applications with transaction-level or connection-level workload balancing functionality. When the first connection is made to the pureScale server, a list of all members along with their capacity (priority or weight) will be passed back to the client in a server list. These capacity values indicate the current load on a DB2 pureScale member. Workload balancing relies on the server list to distribute application requests among the available DB2 pureScale members. To avoid overloading particular members, when the client processing begins, the client automatically and transparently sends the transaction to a member that has a higher capacity value, which means a lower workload on it.

The configuration of enableSysplexWLB=true is mandatory to enable WAS applications to take advantage of the transaction level workload balancing, so the requests can be distributed among the members according to the capacity of each member.

Follow these steps to add the customer property to enable workload balancing:

  1. Click Resources > JDBC > JDBC providers from the left panel of WAS Admin Console.
  2. Click DB2 Universal JDBC Driver Provider (XA) (we just created) under JDBC providers from the right panel of WAS Admin Console.
  3. Click Data sources under Additional Properties from the right panel of WAS Admin Console.
  4. Click DB2 Universal JDBC Driver XA DataSource (we just created) from the right panel of WAS Admin Console.
  5. Click Custom properties under Additional Properties from the right panel of WAS Admin Console.
  6. Click New… to add a new property enableSysplexWLB, as shown in Figure 9. Enter enableSysplexWLB and true as the Value.
  7. Click Apply, and save the changes.
Figure 9. Add a new custom property for the data source to enable WLB
Add a new custom property for the data source to enable WLB

Step 5. Enable the enableAlternateServerListFirstConnect feature

When a data source is created, the server name can be any member node in the pureScale cluster. When the first connection is made, a server list is returned from the pureScale server to the client to indicate the workload balancing will happen for the node(s) contained in the returned server list and the node(s) will be used for client reroute in case automatic client reroute happens. However, it is possible that the member is not up yet when the first connection is made, for example, there is a hardware failure on the member node, to which the data source is configured to connect to. In this case, the client cannot make the first connection to retrieve the server list from the server.

To resolve this issue, DB2 introduced the enableAlternateServerListFirstConnect feature since version V97 FP1. Together with the clientRerouteAlternateServerName and clientRerouteAlternatePortNumber properties, it enables the capability of loading the preconfigured alternate server list into memory when the application tries to open the first connection, and it tries to connect to a different member in the pureScale cluster (specified in the list of clientRerouteAlternateServerName) on the first connection failure.

The preconfigured alternate server list is used only when the client fails to make the first connection to the member that the data source is configured to connect to. The alternate server list needs manual maintenance to ensure that all the current members of the pureScale cluster are listed in case that new members are added into the cluster or some members are removed from the cluster.

To enable the enableAlternateServerListFirstConnect feature, configure the following:

  • Add enableAlternateServerListFirstConnect custom property to the data source; the steps are similar to those in Step 4:
    • Name: enableAlternateServerListFirstConnect
    • Value: true
  • Specify the values for the clientRerouteAlternateServerName and clientRerouteAlternatePortNumber custom properties of the data source. You can find these properties in the Customer properties of the data source as shown in Figure 10 and Figure 11:
Figure 10. Specify the clientRerouteAlternateServerName custom property
Specify the clientRerouteAlternateServerName custom property
Figure 11. Specify the clientRerouteAlternatePortNumber custom property
Specify clientRerouteAlternatePortNumber custom property

Conclusion

In this article, we described how to enable WAS with the DB2 pureScale Feature and how it automatically distributes the workload across all DB2 members in the cluster without any changes at the application side. The enablement is as simple as add/modify a few custom properties of the WAS data sources from the admin console. From the WAS application perspective, there is only one single database view provided by the DB2 pureScale server. WAS with DB2 pureScale provides an easy-to-deploy solution that also demonstrates industry-leading scalability and availability.


Appendix A: Example of Failure recovery in DB2 pureScale cluster with WAS Applications

This section shows how a DB2 pureScale cluster is recovered from a hard failure (reboot) scenario and its impact on the WAS applications. We show how the client applications are rerouted to the surviving member and how the applications are driven to the member again when the failed member is restarted on its home host.

The initial state of the pureScale cluster is shown in Figure 12. There are two members in the cluster, member 0 (on coralpib87) and member 1 (on coralpib88), and two pureScale PowerHA servers, the primary CF (CF 128) on coralpib89 and the secondary CF (CF 129) on coralpib90. The secondary CF is in PEER state.

Figure 12. Initial state of the pureScale cluster
Initial state of the pureScale cluster

Figure 13 shows the list of the applications connecting to the DB2 pureScale server. The command list applications global show detail can show the member node that each of the applications is connecting to (see the bold 7th column of the output). In the output of Figure 13, we only display the WAS related applications ("grep db2jcc"), and we can see that the connections are distributed between the two members. "0" means member 0 which is currently active coralpib87, and "1" means member 1, which is currently active on coralpib88.

Figure 13. list applications global show detail command
list applications global show detail command

Reboot node coralpib88, which currently hosts member, is shown in Figure 14:

Figure 14. Rebooting coralpib88 node
Rebooting coralpib88 node

As member 1 is not available, all the client applications are connecting to the surviving member 0 now. Note the seventh column (bold) in the displayed results, shown in Figure 15:

Figure 15. Client applications connecting to the surviving member 0
Client applications connecting to the surviving member 0

In the WAS system log, shown in Figure 16, there are some ClientRerouteException(s) to indicate the connections to the original member 1 on node coralpib88 failed, and the connections are rerouted to member 0 on node coralpib87.

Figure 16. WAS system log
WAS system log

Same as client reroute happens in a High Availability Disaster Recovery (HADR) environment, it is the application's responsibility to handle the ClientRerouteException and resubmit the failed transaction, but the application does not have to explicitly reconnect to the database.

Member 1 is restarted light on the guest host coralpib87, and the databases are recovered. In the output of "db2instance –list" in Figure 17, member 1 is in WAITING_FOR_FAILBACK state and its current host is coralpib87. Member 1 will not accept requests in this state, and the main purpose of restart light is to ensure the database consistency. Right now, node coralpib88 is inactive, and an alert is set for this host.

Figure 17. db2instance –list output
db2instance –list output

When cluster service detects that coralpib88 is active again, it tries to bring up member 1. At this point, member 1 is in "RESTARTING" state, shown in Figure 18. Note the alert that was set for coralpib88 has been automatically cleared when the cluster service detects that coralpib88 is available.

Figure 18. member 1 is in RESTARTING state
member 1 is in RESTARTING state

Member 1 is restarted successfully on its home host coralpib88 and the databases are recovered too. Now, member 1 is in a STARTED state again and ready to accept application requests, shown in Figure 19:

Figure 19. member 1 is in STARTED state
member 1 is in STARTED state

Figure 20 shows that the applications requests are balanced on both members again:

Figure 20. Balanced application requests
Balanced application requests

Appendix B: Planning for multiple databases

The database creation in a DB2 pureScale environment is not significantly different from DB2 ESE environment. For multiple databases, you may need to adjust the following configurations:

  • Database manager configuration parameter NUMDB needs to be adjusted according to the number of the databases that can be concurrently active in the instance.
  • DB2 registry DB2_DATABASE_CF_MEMORY needs to be set properly to support multiple active databases. This parameter is used, in conjunction with other CF configuration parameters, to indicate the percentage of total CF memory that will be allocated to each active database.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=938037
ArticleTitle=Deploy and explore the DB2 10 pureScale Feature on WebSphere Application Server V8
publish-date=07252013