Db2

 View Only

DB2 pureScale enablement: Workload balancing, automatic client reroute, and client affinities

By Arun Ramachandran posted Sun December 11, 2022 10:13 AM

  

Executive summary

In today’s highly competitive marketplace, it is important to deploy a data processing architecture that not only meets your immediate tactical needs but can also grow and change to adapt to your future strategic requirements. In December 2009, IBM introduced the DB2 pureScale Feature for Enterprise Server Edition software (DB2 pureScale Feature). The DB2 pureScale Feature builds on familiar and proven design features from the IBM DB2 for z/OS database software (DB2 for z/OS), bringing the industry-leading technology and reliability of DB2 for z/OS to open systems.

The DB2 pureScale Feature provides the following advantages:
  • Practically unlimited capacity: The DB2 pureScale Feature provides practically unlimited capacity by allowing for the addition and removal of members on demand. The DB2 pureScale Feature can scale to 128 members by using a highly efficient centralized management facility. The DB2 pureScale Feature also uses a technology called Remote Direct Memory Access (RDMA). RDMA provides a highly efficient internode communication mechanism that also facilitates the scaling capabilities of the DB2 pureScale Feature.
  • 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 or have to be concerned about partitioning data. The DB2 client that is supported by the DB2 pureScale Feature automatically routes application requests to the most appropriate members. The DB2 pureScale Feature also provides native support for a great deal of syntax that is used by database vendors other than IBM. Therefore, applications from those vendors can run in a DB2 pureScale environment with minimal or no changes. In many cases, you can take advantage of the benefits of the DB2 pureScale Feature without having to modify your applications.
  • Continuous availability: The DB2 pureScale Feature provides a fully active-active configuration such that if one member goes down, processing can continue on the remaining active members. During a failure, only data that is being modified on the failing member is unavailable, and only until database recovery is completed for that set of data, which is very quick.
  • Reduced TCO: The DB2 pureScale Feature can help reduce total cost of ownership through its integrated and simplified deployment and maintenance capabilities. The DB2 pureScale Feature provides tools and utilities to handle the deployment and maintenance of components that are integrated within the DB2 pureScale Feature. These tools and utilities help reduce the steep learning curves that are typically associated with deploying such technologies.

Workload balancing (WLB) and client affinities are the critical DB2 client features in delivering the value propositions of the DB2 pureScale Feature. This paper describes the concept of DB2 workload balancing (WLB) and client affinities. This paper provides detailed examples to illustrate how to enable and use these features to access DB2 pureScale cluster from WebSphere Application Server and various stand-alone DB2 clients. This paper also demonstrates how automatic client reroute (ACR) routes application requests among pureScale members when an outage occurs. In addition, this paper provides tips on how to recover from a non-responsive TCP/IP layer along with how to provide alternate servers for the first connection to ensure successful access to the DB2 pureScale database.

Introduction 

Workload balancing overview

Database applications running in a DB2 pureScale environment can use the DB2 transaction-level or connection-level workload balancing (WLB) functionality. WLB balances application requests among all members of the DB2 pureScale cluster. When WLB is enabled the DB2 clients distribute workload or application request based on the capacity (that is, the priority or weight) values in a server list that the DB2 pureScale server returns. These capacity values indicate the current load on a DB2 pureScale member. A member with a capacity value below that of the other members in the server list is busier than other members.

To avoid overloading particular members, when client processing begins, the client automatically and transparently sends the transaction to a member that has a higher capacity value. The following diagrams illustrate scenarios where the workload is not evenly balanced across the DB2 pureScale members and the workload is then balanced across the DB2 pureScale members by using the WLB feature.


For Java clients, WLB uses transaction-level balancing only. In this paper, WLB means transaction-level balancing unless explicitly indicated otherwise.

Client affinities overview

The client affinities feature is another DB2 client technology that you can use to explicitly control how database applications use your DB2 pureScale members. The client affinities feature provides a highly customizable way for you to use your DB2 pureScale members based on your specific business requirements.

The client affinities feature allows you to define an ordered list of DB2 pureScale members to which a DB2 client can connect; different clients can implement a different ordered list. In certain situations, you might want to direct application requests from a DB2 client to a particular DB2 pureScale member on the list. If that DB2 pureScale member goes down because of a planned or unplanned outage, the DB2 client can direct the client application requests to another DB2 pureScale member on the list. If that member is unavailable, the DB2 client can work through the list of all DB2 pureScale members to find an available member. This feature is typically used in an environment where the applications and data are inherently segregated and particular servers are targeted to service requests of particular applications.

With client affinities, you can also control whether application requests fail back to the failure primary server after it comes back online. The primary server is the DB2 pureScale member that the application originally connected to. If you set up the client in this manner, you can choose how often the DB2 client should check whether the primary server is back online.

The following diagram illustrates four application servers that are initially directed toward a specific DB2 pureScale member. If the DB2 pureScale member to which the application servers in Group C are connected fails, those applications are automatically routed to another DB2 pureScale member based on the specified ordered list.

Important: The client affinities feature is mutually exclusive with the WLB feature because the intended behavior of the application with these two methods is different.

Automatic client reroute with WLB and client affinities

DB2 automatic client reroute (ACR) complements a continuously available DB2 pureScale cluster that offers 24/7 availability for clients connecting to mission-critical production systems. ACR is a feature in DB2 clients that takes application requests that are directed toward an offline DB2 pureScale member and reroutes them to active DB2 pureScale members. ACR is automatically enabled with WLB or client affinities so no additional steps are required to specify which member the application should connect to upon encountering an outage.

In some cases, after an outage, clients are seamlessly routed to another DB2 pureScale member, and no error messages are returned to the application because the failure is transparent to the application. For more details on when failures are seamless, see the DB2 Information Center information about seamless client reroute. However, in some situations, the DB2 client cannot replay the statement execution environment on the new connection after automatic client reroute occurs. In such a situation, the transaction is rolled back, and SQLCODE -30108 (or SQLCODE - 4498 for Java applications) is returned to the application after the connection is rerouted from the failing member to a surviving member. If this occurs, applications must replay the statement execution environment and redo the statements, but applications do not have to explicitly reconnect to the database because ACR automatically reconnects the applications.

Download the full report for more on DB2 pureScale enablement.
Download the report to get started!


#Db2
0 comments
9 views

Permalink