Instructions on how to configure a WebLogic Cluster and use it with Oracle Http Server

Posted by Laurent Goldsztejn on Oracle Blogs See other posts from Oracle Blogs or by Laurent Goldsztejn
Published on Mon, 22 Oct 2012 16:33:05 +0000 Indexed on 2012/10/22 23:10 UTC
Read the original article Hit count: 373

Filed under:

/Oracle/Add category

On October 17th I delivered a webcast on WebLogic Clustering that included a demo with Apache as the proxy server. I realized that many steps are needed to set up the configuration I used during the demo. The purpose of this article is to go through these steps to show how quickly and easily one can define a new cluster and then proxy requests via an Oracle Http Server (OHS).

The domain configuration wizard offers the option to create a cluster. The administration console or WLST, the Weblogic scripting tool can also be used to define a new cluster. It can be created at any time but the servers that will participate in it cannot be in a running state.

Cluster Creation using the configuration wizard

Network and architecture requirements need to be considered while choosing between unicast and multicast.

Multicast Vs. Unicast with WebLogic Clustering is of great help to make the best decision between the two messaging modes. In addition, Configure Cluster offers details on each single field displayed above.

After this initial configuration page, individual servers could be assigned to this newly created cluster although servers can be added later to the cluster. What is not recommended is for the Admin server to participate in a cluster as the main purpose of the Admin server is to perform the bulk of the processing for the domain. Servers need to stop before being assigned to a cluster. There is also no minimum number of servers that have to participate in the cluster.

At this point the configuration should be done and the cluster created successfully. This can easily be verified from the console.

Each clustered managed server can be launched to join the cluster.

At startup the following messages should be logged for each clustered managed server:

<Notice> <WeblogicServer> <BEA-000365> <Server state changed to STARTING>
<Notice> <Cluster> <BEA-000197> <Listening for announcements from cluster using 
messaging_mode cluster messaging>
<Notice> <Cluster> <BEA-000133> <Waiting to synchronize with other running members 
of cluster_name>

It's time to try sending requests to the cluster and we will do this with the help of Oracle Http Server to play the role of a proxy server to demonstrate load balancing.

Proxy Server configuration

The first step is to download Weblogic Server Web Server Plugin that will enhance the web server by handling requests aimed at being sent to the Weblogic cluster. For our test Oracle Http Server (OHS) will be used. However plug-ins are also available for Apache Http server, Microsoft Internet Information Server (IIS), Oracle iPlanet Webserver or even WebLogic Server with the HttpClusterServlet.

Once OHS is installed on the system, the configuration file, mod_wl_ohs.conf, will need to be altered to include Weblogic proxy specifics.

First of all, add the following directive to instruct Apache to load the Weblogic shared object module extracted from the plugins file just downloaded.

LoadModule weblogic_module modules/mod_wl_ohs.so

and then create an IfModule directive to encapsulate the following location block so that proxy will be enabled by path (each request including /wls will be directed directly to the WebLogic Cluster). You could also proxy requests by MIME type using MatchExpression in the Location block.

<IfModule weblogic_module>
<Location /wls>
   SetHandler       weblogic-handler
   PathTrim         /wls
   WebLogicCluster  MS1_URL:port,MS2_URL:port
   Debug 	    ON
   WLLogFile        c:/tmp/global_proxy.log 
   WLTempDir        "c:/myTemp"
   DebugConfigInfo  On
</Location>
</IfModule>

SetHandler specifies the handler for the plug-in module

PathTrim will instruct the plug-in to trim /w ls from the URL before forwarding the request to the cluster.

The list of WebLogic Servers defined in WeblogicCluster could contain a mixed set of clustered and single servers. However, the dynamic list returned for this parameter will only contain valid clustered servers and may contain more servers if not all clustered servers are listed in WeblogicCluster.

Testing proxy and load balancing

It's time to start OHS web server which should at this point be configured correctly to proxy requests to the clustered servers. By default round-robin is the load balancing strategy set by WebLogic.

Testing the load balancing can be easily done by disabling cookies on your browser given that a request containing a cookie attempts to connect to the primary server. If that attempt fails, the plug-in attempts to make a connection to the next available server in the list in a round-robin fashion. With cookies enabled, you could use two different browsers to test the load balancing with a JSP page that contains the following:

<%@ page contentType="text/html; charset=iso-8859-1" language="java"  %>

<%  
  String path = request.getContextPath();
  String getProtocol=request.getScheme();
  String getDomain=request.getServerName();
  String getPort=Integer.toString(request.getLocalPort());
  String getPath = getProtocol+"://"+getDomain+":"+getPort+path+"/";
%>
<html>
<body>
Receiving Server <%=getPath%>
</body>
</html>

Assuming that you name the JSP page Test.jsp and the webapp that contains it TestApp, your browsers should open the following URL:

http://localhost/wls/TestApp/Test.jsp

Each browser should connect to a different clustered server and this simple JSP should confirm that. The webapp that contains the JSP needs to be deployed to the cluster.

You can also verify that the load is correctly balanced by looking at the proxy log file. Each request generates a set of log entries that starts with :

timestamp ================New Request:
Each request is associated with a primary server and a secondary server if one is available.  For our test request, the following entries should appear in the log as well:
Using Uri /wls/TestApp/Test.jsp
After trimming path: '/TestApp/Test.jsp'
The final request string is '/TestApp/Test.jsp' 
If an exception occurs, it should also be logged in the proxy log file with the prefix:
timestamp *******Exception type

WeblogicBridgeConfig

DebugConfigInfo enables runtime statistics and the production of configuration information. For security purposes, this parameter should be turned off in production.

http://webserver_host:port/path/xyz.jsp?__WebLogicBridgeConfig will display a proxy bridge page detailing the plugin configuration followed by runtime statistics which could help in diagnosing issues along with the analyzing of the proxy log file. In our example the url would be:

http://localhost/wls/TestApp/Test.jsp?__WebLogicBridgeConfig

Here is how the top section of the screen can look like:

The bottom part of the page contains runtime statistics, here is a snippet of it (unrelated with the previous JSP example).

This entire plugin configuration should be very similar with other web servers, what varies is the name of the proxy server configuration file.

So, as you can see, it only takes a few minutes to configure a Weblogic cluster and get servers to join it.

Developer IT