Basic clustering with Weblogic 12c and Apache Web Server

The aim of this post is to demonstrate Weblogic’s clustering capabilities and to use the Weblogic Apache plugin to use the Apache Web Server as a proxy to forward requests to the cluster.

Objectives

• Install Weblogic 12c on a virtual machine
• Configure two clustered servers
• Set up Apache on a separate virtual machine
• Configure Apache to forward requests to the new cluster
• Test the cluster’s failover
• Investigate Apache configuration options

This diagram shows the finished scenario. The Weblogic cluster will be hosted on a Red Hat virtual machine, the Apache web server on a separate virtual machine, and the client will be anyone who connects to Apache, in my case, my host Windows 7 machine.

This is a little convoluted for a proof-of-concept, but separating the Apache proxy into a separate machine will help with understanding how communication happens between the servers.

Install Weblogic

Weblogic can be installed graphically, via the command line or silently. Since this blog is a tech demo, I’ll be doing things graphically. For more information on silent installation, see the documentation.

Since I installed Weblogic 12c on a shiny new VM image, I didn’t have any JVM installed. I took the opportunity to use jRockit because of the extra tools that come with it. The good news is that jRockit is free, but the bad news is that some of my favourite tools (Mission Control, for example) aren’t!

After running the graphical installer, I ran the Quickstart configuration wizard to create a domain. My policy is always “why make things needlessly difficult”, but for those of you that like to do things with just a keyboard and green screen, domain creation can be done as follows:

cd <install_dir>/Oracle/Middleware/wlserver_10.3/common/bin

./config.sh –mode=console

This should give a command line alternative showing all of the same options as in the graphical installer.

Above, you can see the name and location for my new domain (I accepted the default settings) and the JRockit JDK I installed earlier. Note that I am creating the domain in “Development Mode” and the security risk that comes with it! My VM is a single-user system, so I don’t need to worry about access control.

Creating the Clustered Servers

The high-level steps in creating a new two-server cluster are as follows:

     1. Create servers

     2. Create cluster

     3. Create machine

     4. Add servers to cluster and machine.

The first three steps are not inter-dependent and, using the console, the lines between tasks get blurred. The actual steps I performed to achieve the set-up were as follows:

     1. Create “Server1”

          a. During creation, specify the server should be added to a newly defined cluster

                 i. Create new cluster wlCluster1

     2. Create “Server2”

          a. During creation, add server to existing cluster wlCluster1

     3. Create new machine “RedHatVM”

     4. Click each server in turn and add to RedHatVM

These are the screens you will see when following the steps above with the Admin Console

When all steps are completed, you should see your servers in a similar state:

Once your servers are set up, they’ll need starting! To do this, you first need to start a Node Manager to do the actual starting.

cd <install_dir>/Oracle/Middleware/wlserver_10.3/server/bin

./startNodeManager.sh

The response should look something like this:

Once the Node Manager is available, you can start your servers either through the Admin Console or through the command line.

cd /home/mike/Oracle/Middleware/user_projects/domains/base_domain/bin

./startManagedServer.sh <server_name>

Set up Apache on a Separate VM

Apache’s web server is so popular and ubiquitous that I am going to assume you have either already installed it, or can manage it without yet another guide! Anyone who has spent much time working with Apache will be no stranger to configuration but, for the sake of those new to the web server, you’re about to get very familiar with a certain configuration file:

<Apache_install_dir>/conf/httpd.conf

Opening the configuration, there will be a long list of modules to be loaded. You can tell this because each line begins with “LoadModule…” To the end of this, you’ll need to add the following:

LoadModule weblogic_module modules/mod_wl.so

Those eagle-eyed amongst you will have here noticed that we’ve just added a reference to a file that doesn’t exist yet! “mod_wl.so” is the Weblogic plugin for Apache, so now is probably the right time to find it and put it in the <apache_install_dir>/modules folder. There is a different module for each platform and all can be downloaded directly from Oracle. Downloading is not a necessary step, however, there are modules included in your Weblogic install at the following location:

<Weblogic_install_dir>/Oracle/Middleware/wlserver_10.3/server/plugin/<os>/<os_version>

You may find the modules are named slightly differently (e.g. mod_wl_22.so) but in this case, the numbers just refer to the version of Apache you are using.

Back to our favourite configuration file, httpd.conf, we now need to add instructions for Apache to forward requests to Weblogic. To make sure this is all working properly, the easiest “check” is to forward requests for the admin console. Underneath the “LoadModule” block, enter the following:

<Location /console >

  SetHandler weblogic-handler

  WebLogicHost <ip_address_or_domain_name>

  WebLogicPort 7001

</Location>

After saving the configuration, it will need to be verified to make sure no spelling errors have crept in! On Unix-based systems, this is done as follows:

/usr/sbin/apachectl –t

And on Windows:

<apache_home>\bin\httpd -t

Start or restart the server to enact the changes and test the configuration by first going to http://localhost to check Apache is running and then to http://localhost/console which should show the admin console from Weblogic on your other machine!

Testing the cluster

To properly test the cluster, we first need to deploy an application: the sample .war file “ClusterTest.war”. Once this has been deployed, we will then use it to demonstrate a graceful failover in the middle of a session.

Deploying an application

Deploy ClusterTest through the admin console by going to “Deployments” and clicking “Install”. Follow the steps and make sure to target it at the cluster “wlCluster1” we created earlier. To immediately test that it has deployed properly, we should be able to see it by going to any member of the cluster:

http://localhost:8001/ClusterTest/Session.jsp

http://localhost:8002/ClusterTest/Session.jsp

Note that the page has a line to tell you which server is currently hosting your session – this will be important when testing failover!

Finally, we need to configure Apache to forward all *.jsp requests on to Weblogic. Going back to the configuration file, underneath the <Location> block enter the following, remembering to enter the IP address or host name of your Weblogic server:

<IfModule mod_weblogic.c> 

      WebLogicCluster <weblogic>:8001, <weblogic>:8002 

      MatchExpression *.jsp 

</IfModule>

Now, if we visit http://<apache_server>/ClusterTest/Session.jsp we should be served with the same page as earlier! Make a note of which server is hosting the session, because now it’s time to test!

Testing failover

To the right is a screenshot of some random data I entered to the page. In my case, I was connected to Server2. Once some data is held in the session, it’s time to force a failover! Simply go to whichever server is currently hosting the session in the admin console and select “force shutdown”. Once the shutdown has completed, return to your session and add more new data. If everything has worked, you should see a similar result to mine, where the new data is simply added to the old and you will see the hosting server has switched back to Server1! 

Further Apache Configuration

If you have followed what I’ve done exactly and used the same ClusterTest sample WAR, you will probably have noticed that your Session.jsp page looks a little different when viewed through the Apache proxy than it does when viewed by connecting directly to a cluster member. This is because we are only forwarding *.jsp requests, not *.css requests; Apache is looking for the CSS file locally because we haven’t told it to look on Weblogic. Adding that line to the configuration is trivial, so I’m going to leave it as an exercise to the reader! Meanwhile, I’ll take this opportunity to outline a few of the extra useful parameters provided by the Weblogic module in Apache:

Debug

When set to “ON”, this logs to wlproxy.log in a temp directory. The directory and filename can be set to something different using the WLLogFile option. There are several other options to turn on debugging which relate to various logging levels, but the default is usually a good starting point if you are unsure what you’re looking for. You can always increase the logging later if needed.

Idempotent

This should only be used with applications which can transparently failover without any adverse effect to the transaction. Read transactions are usually OK for this, but thought should be given to what’s happening behind the scenes – if your app sends a request to Server1, which times out, then resends the request to Server2, what would happen if the request was executed twice…once on both servers? If your answer to that question is “doom”, then it’s probably a good idea to leave this off.

WLIOTimeoutSecs 

This timeout applies to the Idempotent option above. It’s always a good idea to make sure the timeout is relatively high, by default, so you don’t find that your app is constantly failing over because of a spike in demand.

WlForwardPath

Remember the <Location /console> tag? This works in a similar way. Whatever argument you give to the parameter, it will parse the request URL to see if it begins with your argument (for example, /webapps) so any request to your webserver to /webapps/someApp will be forwarded to your Weblogic app server. If you were to just use “/” then all requests would be forwarded. This parameter gets really useful when used in conjunction with PathTrim…

PathTrim

If you want to forward all requests to /webapps, as above, but have things configured very differently in your Weblogic cluster, you’ll be relieved to know that you don’t have to alter the context root of every app to include the new prefix! PathTrim will chop the front off so the request goes straight to the correct app without changing a thing on the Weblogic instance.

Mike Croft