Using WebSphere Dynamic Process Edition with DB2 High Availability and Disaster Recovery (DB2 HADR) A Step-by-Step Guide

Size: px

Start display at page:

Download "Using WebSphere Dynamic Process Edition with DB2 High Availability and Disaster Recovery (DB2 HADR) A Step-by-Step Guide"

Linette Lewis
6 years ago
Views:

Using WebSphere Dynamic Process Edition 7.

1 Using WebSphere Dynamic Process Edition with DB2 High Availability and Disaster Recovery (DB2 HADR) A Step-by-Step Guide September 2010 IBM Corporation,

2 Disclaimer This document is subject to change without notification and will not comprehensively cover the issues encountered in all customer situations. The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. For updates or newer releases please refer to the IBM Support page at The Author This document was written by the WebSphere Business Process Management (BPM) test team in Böblingen. Torsten Wilms Accredited IT Specialist IBM Software Group, Application and Integration Middleware Software WebSphere BPM Test I would like to thank the WebSphere Business Process Management test team for their contributions to this document. 2

3 Table of Contents Chapter 1 Introduction... 4 Chapter 2 WebSphere Business Process Management V7 Production Environment... 5 Chapter 3 DB2 HADR... 7 DB2 HADR replication modes... 7 DB2 HADR failover... 7 Chapter 4 Configuration of BPM for DB2 HADR... 9 Datasources for BPEDB, WPRCSDB, EVENTDB, BSPACE and MONITORDB... 9 Datasource for MEDB Summary Appendix: Setup of DB2 HADR Prerequisites Configuration Steps

4 Chapter 1 Introduction This document describes how to set up a WebSphere Dynamic Process Edition (WDPE) environment with database failover and disaster recovery. There are several ways to achieve DB2 high availability. In general, high availability is achieved by making systems redundant. The more system redundancy, the higher the level of availability that can be achieved. One option is to use external clustering software like IBM Power HA (also referred to as IBM HACMP). Another option is to use DB2 High Availability and Disaster Recovery (HADR). This document describes how to implement failover and disaster recovery for the WebSphere Dynamic Process Edition databases using DB2 HADR. To make a decision on which option to use, you have to gather information most importantly the non-functional requirements. Depending on these requirements your system architecture, or operational model, should be designed. Usually this is a high-level design. The following Redbook will help you to choose the option best suited for your requirements. High Availability and Disaster Recovery Options for DB2 on Linux, UNIX, and Windows DB2 HADR is a feature in DB2 Enterprise Server allowing replication of a database to a local or remote location. All the data replication work is done inside DB2 at the software level. A DB2 HADR primary database uses internal processes to replicate the data to a DB2 HADR standby database. The standby database can be converted to the primary database and accessed by applications and users in the event of a disaster, or if the primary server fails. This document gives an architectural overview of WebSphere Dynamic Process Edition with DB2 HADR and describes configuration details and the behavior of WebSphere Process Server and WebSphere Business Monitor in the case where the databases are temporarily unavailable during the database takeover phase. This document does not focus on the transactional behavior details of WebSphere and its databases in a failover case. Find more information about this topic here: Failover Scenarios in a Highly Available WebSphere Business Process Management V7 Production Environment 4

Chapter 2 WebSphere Business Process Management V7 Production Environment The WebSphere Business Process Management (BPM) V7 production environment described in this paper consists of a WDPE Remote

5 Chapter 2 WebSphere Business Process Management V7 Production Environment The WebSphere Business Process Management (BPM) V7 production environment described in this paper consists of a WDPE Remote Messaging and Remote Support setup and a DB2 HADR setup. For more details on how to setup such a topology refer to the following Redbook: WebSphere Business Process Management V7 Production Topologies The figure below shows a schematic overview of this environment and its databases. The figure does not show the hardware boxes for the WebSphere clusters, because for the DB2 HADR-focussed scenario this is not relevant. DB Host 1 Hosts the primary DB2 database instance for WDPE databases: BPEDB Used for the Business Flow Manager and Human Task Manager 5

6 WPRCSDB Used as a repository for various components in WebSphere Process Server EVENTDB Used for the Common Event Infrastructure MEDB Used to host tables for messaging engines BSPACEDB Used by the Business Space applications to store configuration data for the various user profiles, space definitions, and page definitions MONITORDB Used by WebSphere Business Monitor to store metadata and configuration information, AlphaBlox data, and schemas for each deployed monitor model DB2 Host 2 Hosts the standby DB2 database instance for WDPE databases. WPS (WebSphere Process Server) Cluster Hosts the Business Process Choreographer (BPC) components, that is the Business Flow Manager (BFM), the Human Task Manager (HTM) and business process execution language (BPEL) applications. Support Cluster Hosts the Common Event Infrastructure (CEI) and the Business Process Choreographer Explorer (BPC Explorer). Messaging Cluster Hosts the Messaging Engines (BPC, CEI, SCA.SYS, SCA.APP, Monitor). The Messaging Engines (hereafter called MEs) are operated in a 1-of-N policy, this means that a component s Messaging Engine is active on one cluster member only. Monitor Cluster Hosts the monitor model application. Web Cluster Hosts the Business Monitor REST services, the Business Space and IBM DB2 Alphablox. 6

7 Chapter 3 DB2 HADR DB2 high availability and disaster recovery (DB2 HADR) is a data replication feature in DB2 Enterprise Server that provides a high availability solution. HADR protects against data loss by replicating data changes from a source database, called the primary database, to a target database, called the standby database. Detailed information about DB2 HADR can be found in the DB2 Information Center: DB2 HADR replication modes DB2 HADR provides three replication modes: Synchronous Near-synchronous Asynchronous In our case we set the DB2 HADR database replication mode to synchronous. A synchronous replication mode ensures transactional safety in case of a failover of databases. From a WebSphere point of view this means that there will be no inconsistencies between WebSphere transactions and database transactions in a failover case. Depending on your recovery strategy it might be also valid to use the asynchronous or near-synchronous replication mode: - The near-synchronous replication mode has a shorter transaction response time than the synchronous mode, but it also provides slightly less protection against transaction loss. - The asynchronous replication mode has the shortest transaction response time among the three modes, but has the highest chance of transaction loss if the primary system fails. DB2 HADR failover When a failure occurs on the primary database, you can initiate a takeover operation on the standby database which then becomes the new primary. Since the standby database is already online, failover can be accomplished very quickly resulting in minimal down time. The takeover operation can be initiated manually by using the DB2 takeover command or it can be automated. However, for an automated failover external products should be in place, such as Tivoli System Automation. Refer to the developerworks document referenced below on how to automate the failover using Tivoli System Automation. Implement DB2 high availability disaster recovery in a Tivoli System Automation cluster domain sundaram/index.html 7

8 Once the failed old primary is repaired, it can rejoin the DB2 HADR pair as a standby database if the two copies of the database can be made consistent. After the original primary database is reintegrated into the DB2 HADR pair as the standby database, a failback operation can be performed so that the original primary database is once again the primary database. 8

9 Chapter 4 Configuration of BPM for DB2 HADR This chapter describes how WebSphere works with DB2 HADR and how the WebSphere JDBC datasources are configured for DB2 HADR. Datasources for BPEDB, WPRCSDB, EVENTDB, BSPACE and MONITORDB This section describes the setup for all datasources except the datasource for the MEDB, which will be described separately. The datasources for BPEDB, WPRCSDB, EVENTDB, BSPACE and MONITORDB will use the Automatic Client Reroute feature of DB2 HADR. During the first connect from the datasource to the database, the datasource receives information on how to connect to the standby database in case of a DB2 HADR takeover. In this case, no additional mandatory configuration steps on the datasources are required. Hence, you will define your DB2 datasource in the same manner as if you were not using HADR. However, it is recommended to adjust the Retry interval for client reroute and Maximum retries for client reroute parameters, which is described in the next section. The figure below shows the failover behavior in case the DB2 Host 1 is not available. 1)The datasource will receive a connection not available error and tries to connect to the DB Host 2. However, the connection is not established yet, because the DB2 Host 2 is in standby mode. 2)A DB2 HADR takeover command must be issued on the standby host (in this case DB Host 2). The standby database will then switch into the active mode. During the 9

phase in between Db Host 1-failure and takeover the database is temporarily unavailable for the datasource. Transaction rollbacks can occur. 3)The datasource will now reroute requests to DB Host 2.

10 phase in between Db Host 1-failure and takeover the database is temporarily unavailable for the datasource. Transaction rollbacks can occur. 3)The datasource will now reroute requests to DB Host 2. The Business Process Container component (as well as the Monitor-, Business Space-, CEI components) has a built-in retry mechanism which will frequently retry to connect to the database. All requests will now be served by DB2 Host 2. 10

Retry interval and maximum retries for client reroute By default, the Automatic Client Reroute feature retries to establish a connection to the database repeatedly for up to 10 minutes.

11 Retry interval and maximum retries for client reroute By default, the Automatic Client Reroute feature retries to establish a connection to the database repeatedly for up to 10 minutes. It is, however, possible to configure the exact retry behavior. Follow the steps below to do this configuration. In the Admin Console, select the datasource. Click on WebSphere Application Server data source properties Set the following properties: Retry interval for client reroute: Use this property to specify the amount of time (in seconds) to sleep before retrying again. This property is only used if the maxretriesforclientreroute property is also set. Maximum retries for client reroute: Use this property to limit the number of retries if the primary connection to the server fails. This property is only used if the Retry interval for client reroute property is also set. These properties can have an effect of better turnaround time by limiting the duration in which an automatic reroute is attempted and returning an error faster to the application if a reroute is not possible. In the screenshot below we set the value for Retry interval for client reroute to 15 seconds and the value for Maximum retries for client reroute to 2 retries. These are only sample values. You have to choose values that match your environment and requirements. 11

12 The Alternate server names, Alternate port numbers and Client reroute server list JNDI name fields are left blank. They are not required for the Automatic Client Reroute feature of DB2 HADR. In the next section datasource for MEDB they are described in detail. Click OK and save. 12

Datasource for MEDB This section describes why the datasource for MEDB can not use the Automatic Client Reroute feature of DB2 HADR and how to configure the

1) The datasource will receive a connection not available error.

13 Datasource for MEDB This section describes why the datasource for MEDB can not use the Automatic Client Reroute feature of DB2 HADR and how to configure the datasource for DB2 HADR. The figures below show the default failover behavior in case the DB2 Host 1 is not available. 1) The datasource will receive a connection not available error. The messaging engine on server 1 lost its connection to the database on DB Host 1 and its JVM will immediately shut down to avoid unpredictable messaging behaviours. 2)A DB2 HADR takeover command must be issued on the standby host, in this case DB Host 2. The standby database will switch into the active mode. 13

not available in the JVM of server 2 at this point in time.

14 3) Meanwhile, the messaging engine starts on server 2 (because server 1 shut down) and tries to connect during the start to DB Host 1 because the Automatic Client Reroute information is not available in the JVM of server 2 at this point in time. It is not available, because server 2 never connected to DB Host 1 before (ME on server 2 was until now never in active mode). 14

properties in the data source properties: Data sources > <your>me data source > WebSphere Application Server data

15 Therefore, the messaging engine on server 2 must be forced to connect to the secondary DB2 instance: 4)To force the ME to connect to the secondary DB2 instance, set the Alternate server name and Alternate port number properties in the data source properties: Data sources > <your>me data source > WebSphere Application Server data source properties The ME on server 2 is now able to connect to the DB2 instance on DB Host 2 when DB Host 1 is not available. 15

16 Summary To setup a DB2 HADR environment for WDPE, two main steps have to be performed by the database and WebSphere administrator: 1. During configuration/install time: Configure DB2 HADR Configure JDBC datasources to use either the Automatic Client Reroute feature or the Alternate server name (MEDB datasource) property. 2. During runtime/failover time: Manual failover: Use the DB2 takeover command to activate the standby database Automated failover: Use an external automation provider like Tivoli System automation to activate the standby database. 16

Appendix: Setup of DB2 HADR Prerequisites The configuration steps below describe how to enable DB2 HADR for the WDPE databases. The configuration steps require following prerequisites: 1.

17 Appendix: Setup of DB2 HADR Prerequisites The configuration steps below describe how to enable DB2 HADR for the WDPE databases. The configuration steps require following prerequisites: 1. Install a primary DB2 instance on the primary database host 2. Install a second DB2 instance on the standby database host In our setup, we use the DB2 Control Center to enable DB2 HADR. Therefore, catalog both DB2 instances on a DB2 Control Center. Configuration Steps This section describes the configuration steps required to setup DB2 HADR for the database BPEDB. Repeat the configuration steps below also for these databases: MEDB WPRCSDB EVENTDB BSPACEDB MONITORDB Open the DB2 Control Center Right click on the BPEDB select High Availability and Disaster Recovery > Set up 17

18 Click Next DB2 HADR requires archiving logging type for the DB2 logs. By default it is set to Circular. To change the logging type to Archive click Configure. 18

19 Select Archive Logging and click Next. 19

20 20

21 Select a location for the log files and click Next. Select the Number of log files and click Next. A database backup is required when you change the log type. Specify a backup location. After the backup you will continue with the HADR wizard. 21

22 Specify the buffer settings and click Next. Review the actions and click Finish to back up the database. After the backup continue with the HADR wizard and click Next. 22

Identify the standby database instance on the remote host that will contain the standby database. The standby database itself will be created in the next steps.

23 Identify the standby database instance on the remote host that will contain the standby database. The standby database itself will be created in the next steps. Select the System Name and the Instance Name of the remote standby DB2 host. Select the option Use a backup image of the existing primary database to initialize a standby database. Click Next. 23

24 Select Back up the primary database and click Back Up... 24

25 Select a backup directory. Select Full Backup. Select Online. After the backup, continue with the HADR wizard to create the standby database from the backup you have created. Select the backup image and click Next. 25

26 Click Add Database. Enter an Alias and click OK. 26

27 Copy the backup image to a directory on the standby system. Click Next. On the Copy objects to the standby system step click Next. 27

28 Specify TCPIP parameters for the HADR service. The wizards suggests free ports as HADR port numbers. However, you can ensure that the ports are free by reviewing the ports in /etc/services. Click Next. 28

29 Configure the database for automatic client reroute. The wizard automatically takes the DB2 instance port values of the primary and standby database instances. 29

30 Select Synchronous as synchronization mode. DB2 HADR provides three replication modes: Synchronous Near-synchronous Asynchronous In our case we set the DB2 HADR database replication mode to synchronous. A synchronous replication mode ensures transactional safety in case of a failover of databases. From a WebSphere point of view this means that there will be no inconsistencies between WebSphere transactions and database transactions in a failover case. Depending on your recovery strategy, it might be also valid to use the asynchronous or near-synchronous replication mode: The near-synchronous replication mode has a shorter transaction response time than the synchronous mode, but it also provides slightly less protection against transaction loss. The asynchronous replication mode has the shortest transaction response time among the three modes, but has the highest chance of transaction loss if the primary system fails. 30

31 Select Start HADR on the databases to start the HADR service. Click Finish. After finishing the wizard, you will see the HADR standby database on the remote system. 31

32 To verify that HADR is running, right-click on BPEDB and select High Availability Disaster Recovery > Manage. You will see the status information of the HADR peer. 32

33 *** End of Document *** 33

WebSphere Process Server Change The User Registry From Standalone LDAP To Virtual Member Manager. A step by step guide

WebSphere Process Server Change The User Registry From Standalone LDAP To Virtual Member Manager. A step by step guide WebSphere Process Server 6.1.2 Change The User Registry From Standalone LDAP To Virtual Member Manager A step by step guide May 2009 IBM Corporation, 2009 1 Disclaimer This document is subject to change