Oracle WebLogic Server Active GridLink for Real Application Clusters (RAC)

Oracle WebLogic Server and Oracle RAC are designed to work together to provide an environment for highly available and scalable applications. 

Oracle WebLogic Server Active GridLink for RAC provides the best available support for the Real Application Clusters (RAC) features in Oracle Database 11g, minimizing database access time while allowing transparent access to rich pooling management functions that maximizes both connection performance and availability

There are two data source implementations in Oracle WebLogic Server to support Oracle Real Application Clusters (RAC) –

1.     First, Multi data source solution which has been used successfully in customer production deployments.

2.    Second, New implementation in Oracle WebLogic 11g Release 1 (10.3.4) called Oracle WebLogic

     Active GridLink for RAC which is the market-leading mid-tier integration solution leveraging the latest and greatest Oracle RAC advances.

Note : -Database RAC ( Real Application Cluster ) is a concept just like Weblogic Clustering where multiple instance of database run in parallel for providing failover, load balancing and performance.

Multi Data Source – Capabilities and Limitations

The WebLogic Server JDBC subsystem has supported Oracle RAC since WLS version 8.1 SP5, originally developed for Oracle9i RAC.

This support is based on a particular type of data source configuration, called a multi data source.

A multi data source is a group of multiple data sources.

It serves JDBC connections from each of the member data sources according configuartions.

A RAC multi data source configuration requires that each member data source obtain connections to a particular RAC instance, as shown below for a three-node RAC cluster configuration.

Capabilities

WebLogic RAC multi data source configurations provide the following capabilities :

Load Balancing

When the Multi Data Source algorithm is set to load balancing, application connection reserve requests are served from each member data source in a round robin fashion. This allows for improved utilization of the cluster resources than the failover policy, and is supported for XA data sources as well.

Failover

The failover Multi Data Source algorithm causes connection borrow requests to be served from a single member data source until such time as the member is unavailable. Failover can optionally occur when the pool’s capacity has been exhausted. The failover policy is typically used with active-passive architectures.

XA Affinity and Failover

When accessed within a global transaction, the member data source from which the JDBC connection was obtained is pinned to the global transaction for the life of the transaction. This ensures that all database operations performed on connections obtained from the Multi Data Source, for a particular transaction, all execute on the same RAC instance.

XA affinity results in improved performance and is even a requirement for older versions of RAC, such as prior to 11g. If a pinned RAC instance suffers a failure, then a global transaction can complete utilizing a different RAC instance using a connection obtained one of the other member data sources.

Limitations

The WebLogic Multi Data Source is a pure middle tier implementation which does not leverage the Oracle RAC features such as the Oracle Notification Service (ONS).

As a result, WebLogic Multi Data Sources do not have immediate knowledge of backend events, and have related functional limitations described below.

Configuration Complexity

A WebLogic Multi Data Source requires n+1 JDBC modules (Data Sources) to be configured, where n is the number of nodes in the RAC cluster.

For RAC service configurations, a separate multi data source is required for each defined service. In addition, the configuration itself is static and requires administrative intervention to add or remove data sources when changes are made to the RAC cluster topology.

 Connection Polling

Connection polling is the mechanism used in Multi Data Source to determine the viability of individual JDBC connections and to detect changes in the RAC cluster topology. This mechanism is an alternative mechanism to use of backend notification services.

Although effective, performing SQL operations on individual connections comes at the expense of additional runtime overhead, and potentially delayed detection of RAC node failures. Also, the potential exists for false positives that could result in the unnecessary disablement of the data source pool and the termination of valid connections that may be in use by applications.

Load Balancing Algorithm

The round-robin load balancing employed by WebLogic Multi Data Source implementation distributes work evenly across all member data sources. Finer grained control is desirable for situations where RAC instances exhibit different performance/response time characteristics.

XA Affinity per MDS

XA affinity is provided by each Multi Data Source. When several Multi Data Sources are enlisted in a global transaction, it is possible that connections could be obtained from different RAC instances. This results in branches of the same global transaction being processed by separate RAC instances. Although supported in later RAC versions, it is less than optimal from a performance perspective.

Active GridLink for RAC

Oracle WebLogic Server 10.3.4 introduced a single data source implementation to support an Oracle RAC cluster.It responds to FAN events to provide Fast Connection Failover (FCF), Runtime Connection Load-Balancing (RCLB), and RAC instance graceful shutdown. XA affinity is supported at the global transaction Id level. The new feature is called WebLogic Active GridLink for RAC; which is implemented as the GridLink Data Source within WebLogic Server.

The RAC integration capabilities of Universal Connection Pool (UCP) have been utilized by the WebLogic Server GridLink Data Source implementation to provide the FCF, RCLB and Affinity features.

With the key foundation for providing deeper integration with Oracle RAC, this single data source implementation in Oracle WebLogic Server supports the full and unrestricted use of database services as the connection target for a data source.

The active management of the connections in the pool is based on static settings configured on the connection pool itself (min/max capacity, timeouts, etc.) and real time information the connection pool receives from the RAC Oracle Notification Service (ONS) subsystem that advises the “client” of any state changes within the RAC cluster

  

The Universal Connection Pool Java library has been integrated with WebLogic Server and been utilized by WebLogic GridLink data source implementation to provide the Fast Connection Failover, Runtime Connection Load Balancing and Affinity features.

Upgrades from RAC Multi Data Sources to Grid Link Data Sources are straight-forward and involve creating a single Grid Link Data Source with the same JNDI name as the Multi Data Source, which reduces the number of configuration artifacts to maintain.

Fast Connection Failover

The Fast Connection Failover (FCF) feature is a Fast Application Notification (FAN) client implemented through the Universal Connection Pool. The feature requires the use of an Oracle JDBC driver and an Oracle RAC database or use of Oracle Restart on a single instance database. WebLogic GridLink Data Source has been integrated with FCF from Universal Connection Pool implementation and uses FCF to:

• Provide rapid failure detection

• Abort and remove invalid connections from the connection pool quickly

• Perform graceful shutdown for planned and unplanned Oracle RAC node outages

• Adapt to changes in topology, such as adding or removing a node

• Distribute runtime work requests to all active Oracle RAC instances, including those rejoining a  

   Cluster

ONS is used by the Oracle RAC database to broadcast events that describe a change of state. GridLink Data Sources can register to receive notifications from ONS and therefore quickly become aware of any state changes in a RAC database. Using these state change notification events, GridLink Data Sources can intelligently adapt its connection pools so that it provides continuous, reliable and efficient access to the RAC database as changes happen.

An adaptive response to state changes in the RAC cluster allows WebLogic Server to handle outages by immediately retracting, closing and discarding connections to RAC instances that have been stopped or taken out by an unplanned outage, without needing to periodically poll the connections to ensure they are valid, or affecting uninvolved connections to surviving nodes. This eliminates the need to test connections to ensure applications are not given dead connections and quickly removes dead connections from RAC node failures, which in some failure modes, might otherwise hang for minutes.

Further, it allows WebLogic Server to proactively reapportion its set of connections to support scenarios where new RAC instances are added or are restarted after an outage. This results in WLS being able to make full use of the resources within the RAC database. Furthermore, using the database service model, this allows database administrators to make changes to the RAC service/instance allocations, which are then seamlessly applied through the affected WLS connection pools without needing to make configuration changes to the connection pool configuration. It also removes the need to create complex arrangements of multiple data sources to represent a dedicated instance of the RAC database.

The WebLogic GridLink Data Source provides Fast Connection Failover capabilities and responds to RAC database service and node events {UP, DOWN} to ensure that the reserve of physical connections in the pool are always pointing to a valid database node; and it ensures that the reserve of physical connections are well distributed across the available database nodes.

The Fast Connection Failover behavior is enabled as a configuration setting on the GridLink Data Source.

With the Fast Connection Failover capability enabled, the following scenarios are supported:

• Planned down Event - Planned outages are defined as database maintenance or other activities that are needed to perform at a known point in time. Support for these events is available where an Oracle RAC service can be gracefully shutdown. In such scenarios, any borrowed or in use connections are not interrupted and closed until work is completed and control of the connection is returned to the pool. This provides an extremely efficient way in large heterogeneous customer environments to manage planned outages.

• Unplanned down Event - Support for unplanned outages is provided by detecting and removing stale connections to an Oracle RAC cluster. Stale connections include connections that do not have a service available on any instance in an Oracle RAC cluster due to service-down and nodedown events. Borrowed connections and available connections that are stale are detected, and their network connection is severed before removing them from the pool. These removed connections are not replaced by the pool. Instead, the application must retry connections before performing any work with a connection. The primary difference between unplanned and planned shutdown scenarios is how borrowed connections are handled. Stale connections that are idle in the pool (not borrowed) are removed in the same manner as the unplanned shutdown scenario

• Up Event - Oracle RAC Instance Rejoin and New Instance Scenarios - Scenarios where an Oracle RAC cluster adds instances that provide a service of interest are supported. The instance may be new to the cluster or may have been restarted after a down event. In both cases, WebLogic Connection Pool for JDBC recognizes the new instance and creates connections to the node as required.

 Runtime Connection Load Balancing

WebLogic GridLink Data Sources and JDBC connection pools leverage the load balancing functionality provided by an Oracle RAC database to provide better throughput and more efficient use of resources.

Oracle performance analysis has revealed significant performance benefits from the use of runtime connection load balancing vs. a static round-robin algorithm. These benefits are observed even when nodes in the RAC cluster are balanced from a hardware perspective, and when the average load on the nodes on the cluster are expected to be reasonably uniform on average.

Transient differences in load characteristics are often sufficient to make runtime connection load balancing the optimal load balancing mechanism for RAC clusters. The load balancing advisory service issues FAN events that advise clients on the current state of the cluster including advice on where to direct connections to. WebLogic Server connection pool receives load balancing advisory events issued by the database, and distributes connections to the RAC nodes accordingly as shown in the diagram below.

Runtime connection load balancing provides the following benefits:

• Manages pooled connections for high performance and scalability

• Receives continuous recommendations on the percentage of work to route to database instances

• Adjusts distribution of work based on different back-end node capacities such as CPU capacity or response time

• Reacts quickly to changes in cluster reconfiguration, application workload, overworked nodes, or hangs

• Receives metrics from the Oracle RAC Load Balance Advisory. Connections to well performing instances are used most often. New and unused connections to under-performing instances will gravitate away over time. When distribution metrics are not received, connection is selected using a random choice.

 Connection Affinity

WebLogic GridLink Data Sources leverage affinity functionality provided by an Oracle RAC database. Connection affinity requires the use of an Oracle JDBC driver and an Oracle RAC database version 11.1.0.6 or higher.

Connection affinity allows a connection pool to select connections that are directed at a specific Oracle RAC instance to provide the best performance for the customer applications. The pool uses run-time connection load balancing to select an Oracle RAC instance to create the first connection and then subsequent connections are created with an affinity to the same instance. WebLogic GridLink Data Sources supports transaction-based affinity.

  Transaction-Based Affinity

Transaction-based affinity is an affinity to an Oracle RAC instance that can be released by either the client application or a failure event. Applications typically use this type of affinity when long-lived affinity to an Oracle RAC instance is desired or when the cost (in terms of performance) of being redirected to a new Oracle RAC instance is high.

WebLogic XA connections that are enlisted in a distributed transaction keep an affinity to the Oracle RAC instance for the duration of the transaction. In this case, an application would incur a significant performance cost if a connection is redirect to a different Oracle RAC instance during the distributed transaction.

The affinity will be established based on the global transaction id, instead of by individual data source, to ensure that connections obtained from different data sources that are configured for the same RAC cluster are all associated with the same RAC instance. The LLR two-phase commit optimization will be supported by the RAC data source and will also participate in XA affinity.

Regerence : http://www.oracle.com