« UKOUG TEBS 2010... | Main | Commercial-grade... »

GridLink Data Source in WebLogic Server 11gR1 PS3

23 Jan 2011 by Simon Haslam (in HA)

Ever since Oracle acquired BEA Systems at the start of 2008 one of the most eagerly awaited features, for me at least, has been improved integration between WebLogic Server and the Oracle database (RAC in particular). This has now been addressed in WLS 10.3.4, also known as 11gR1 Patchset 3 (PS3).

As well as fixes, the WebLogic 11gR1 PS3 release contains a host of new features - for more information see What's New in WebLogic Server 10.3.4. The feature I'd like to introduce here is Active GridLink for RAC, and in particular, the GridLink data source. If you run a busy website with maybe hundreds, or thousands, of database sessions across a RAC database, then you should definitely be considering this new feature.

Spoiler alert: unless you have bought an Oracle Exalogic, or the Exalogic Elastic Cloud Software, you are not licensed to use this feature! See later in this post. Superceded 27/7/11 - see later blog post

Oracle seems to have hit the nail on the head functionality-wise: this release has everything I'd hoped for in this area (ONS integration, FAN/FCF, RCLB), and more besides (SCAN addresses, dynamic ONS). GridLink also includes other features such as session affinity and advanced Infiniband support to maximise performance between Exalogic and Exadata installations, but I won't discuss these further here.

The blog post outlines the functionality, shows how to configure a new GridLink data source, describes the licensing situation and gives my first impressions.

Functional Overview

Oracle Notification Service (ONS) consists of daemons, typically on the database servers that, talking a propriety protocol, notify clients (or other ONS daemons) of database status events such as an instance shut down. ONS is the enabling mechanism for what Oracle calls Fast Application Notification (FAN) which in turn is used to implement Fast Connection Failover (FCF), for instance, in a pool of JDBC connections. This communication between client (WLS) and database servers gives a number of benefits including no sudden loss of sessions during a controlled instance shutdown, directing connections to the least loaded database server (runtime connection load balancing - RCLB) and re-balancing of connections across a cluster following the addition of a new server.

For some diagrams as to how client failover works please see the various presentations I have given on FCF and the Universal Connection Pool (UCP) on my download page.

Configuring the GridLink Data Source

The simplest way to create a GridLink data source connection pool is using the WebLogic administration console. The steps are very similar to creating a single instance data source, except that there are a few additional questions, especially pertaining to ONS.

Firstly go to create a JDBC data source and choose the GridLink option:

Now, like a regular data source, you are asked for details about its JNDI name and transaction support:

Usually you will use the wizard to set up the JDBC URL for you:

Now enter details about the RAC database, service and user. Note my example here uses VIP names (which you should always use for 10.2 and above RAC databases), though you should be able to use a SCAN instead if you are using an 11.2 database.

Next you are presented a deep screen with all the database access details, including the innocuous looking test table, and a convenient button to test the database connection to all listeners in the cluster. Note you still don't have the option on this screen to change the pool size which puzzles me - in any non-trivial environment that is something you always want to do and yet you have to go back into the configuration afterwards to amend it.

Now this is where things get interesting! You'll see the "FAN enabled" tick-box and a place to enter the ONS details typically, though not necessarily, on the database servers. This is ticked by default and the UI makes sure you enter at least one ONS server (of course, as FAN is not going to work otherwise).

You'll also notice the wallet parameters which allow the ONS messages to be sent over SSL - usually a good practice in production.

The next page allows you to test connectivity with the ONS servers. This is handy as in production you will probably have requested firewall ports to be opened between the application server DMZ and the database zone and this allows you easily verify such a change is working.

Finally, as for other types of data source, you choose which (usually) managed servers to assign it to, and then you're done.

Note I have had a warning message at this point but the data source was still activated - I'm not sure why. In this case it was happy though:

This is how my configuration looks in the JDBC file referenced from the domain's config.xml:

<?xml version='1.0' encoding='UTF-8'?>
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source" xmlns:sec="http://xmlns.oracle.com/weblogic/security" xmlns:wls="http://xmlns.oracle.com/weblogic/security/wls" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/jdbc-data-source http://xmlns.oracle.com/weblogic/jdbc-data-source/1.0/jdbc-data-source.xsd">
<name>racb-ds</name>
<jdbc-driver-params>
    <url>jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=westfield03)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=westfield04)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=appa)))</url>
    <driver-name>oracle.jdbc.OracleDriver</driver-name>
    <properties>
      <property>
        <name>user</name>
        <value>hr</value>
      </property>
    </properties>
    <password-encrypted>{AES}...</password-encrypted>
</jdbc-driver-params>
<jdbc-connection-pool-params>
    <initial-capacity>5</initial-capacity>
    <max-capacity>15</max-capacity>
    <capacity-increment>1</capacity-increment>
    <test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
    <statement-cache-size>10</statement-cache-size>
    <statement-cache-type>LRU</statement-cache-type>
</jdbc-connection-pool-params>
<jdbc-data-source-params>
    <jndi-name>jdbc/racb-ds</jndi-name>
    <global-transactions-protocol>OnePhaseCommit</global-transactions-protocol>
</jdbc-data-source-params>
<jdbc-oracle-params>
    <fan-enabled>true</fan-enabled>
    <ons-node-list>westfield03:6200,westfield04:6200</ons-node-list>
    <ons-wallet-file></ons-wallet-file>
</jdbc-oracle-params>
</jdbc-data-source>

What is interesting to me about this is that it is almost identical to a regular/'generic' Oracle JDBC data source - the only difference (for the same transaction regime) is the additional properties (shown above in bold).

Monitoring

You can monitor a GridLink data source through the WebLogic administration console in the same way as multi data sources, e.g. numbers of connections to each RAC instance. There are new tabs for ONS though which allow you to check connectivity once the data source is running:

You can also view the data source status, like any other, on the Monitoring Dashboard:

Licensing

This section is no longer relevant - see later blog post 27/7/11

As I mentioned earlier, at the time of writing, the functionality described above is not included in any of the WebLogic Server licences (Basic, Standard, Enterprise or Suite). You are only allowed to use this feature in test and production environments if you have one of:

an Exalogic Server: starting at $475,000 for a quarter rack (8 computer nodes) hardware, plus WebLogic licences etc, or,
the Exalogic Elastic Cloud software: this costs an additional $20,000 per Oracle Processor on top of WebLogic Suite.

Note even if you have an Exadata you are still not allowed to use GridLink data sources from a non-Exalogic WebLogic installation unless you have bought the Exalogic Elastic Cloud software.

As most people know, the Oracle licensing police don't take prisoners so if you're not on Exalogic and haven't paid for the extra Elastic Cloud licences you need to make sure your WebLogic administrators are fully aware that they mustn't use GridLink Data Sources. Note: I haven't seen of a way to switch off their availability in the console. Also, as you can see from the earlier configuration snippet, it is easy for Oracle to tell if you are using a GridLink data source, and I am sure their use will be included in auditing scripts.

If you think this licensing approach is unfair given that some of the GridLink functionality was available in OAS 10gR3 and that you have already bought both WebLogic, Oracle's premium application server, and RAC, Oracle's premium database server, then I suggest you write to Mike.Lehmann@oracle.com.

Summary

GridLink Data Sources are what Oracle application server administrators with busy, highly available web applications have been waiting for in WebLogic for some time.

I will reserve judgment on the implementation until I have a customer running it in production - early indications are promising, but those who have heard me speak about using the Implicit Connection Cache in Oracle Application Server 10g R3, and more recently Oracle's Universal Connection Pool (on top of which the new functionality runs), will know that getting this technology to work properly relies on meticulous attention to detail during configuration, along with plenty of diagnostics and testing.

GridLink Data Sources offer core features that used to be provided in Oracle Application Server 10gR3 (like FCF) but then go much further (RCLB, SCAN listeners, etc). If this all works in practice they could become the standard way for configuring WebLogic Servers with RAC databases, providing the current licensing situation is resolved.