Configuring a Simple Web Cluster

Whenever you deploy a web application to a WebLogic cluster, you need something sitting before the cluster (i.e., between the client and the cluster) that can direct incoming requests to the appropriate server that hosts the primary session state. There are many ways in which you can accomplish this:

Hardware load balancer

A hardware load balancer can be placed in front of the cluster. In this case, all client requests to the cluster must pass through the load balancer. The load balancer can distribute requests across the available members of the cluster, and direct requests involved in a session to the appropriate server holding the primary state.

Web server with proxy plug-in

A web server can be augmented with a proxy plug-in, a piece of software supplied with WebLogic that will redirect certain requests (for example, those to servlets and JSPs) through to the cluster. Clients accessing the web server then can be served up static content by the web server directly and transparently proxied through to the cluster behind the web server for the dynamic content.

WebLogic with the HttpClusterServlet

The HttpClusterServlet is an alternative to a proxy plug-in. A WebLogic instance can be configured to host the servlet, which can forward requests across to the cluster in the same way as the proxy plug-in.

The main ways in which you can architect your cluster and web tiers are discussed in much more detail in Chapter 14. Here we will give a brief introduction to setting up the HttpClusterServlet, leaving the configuration of the proxy plug-ins, an almost identical task, to Chapter 3.

2.8.1 Configuring HttpClusterServlet

As its name suggests, the HttpClusterServlet is a servlet. It is supplied with WebLogic. To put the servlet into action, create a simple web application with the servlet configured as part of the web application. You need to then deploy the web application to the machine that is going to serve as the main gateway to your cluster, as suggested by Figure 2-2.

Figure 2-2. Example clustering setup

As detailed in Figure 2-2, the idea is that requests that go to the server instance called Front Server are to be redirected to one of the servers in the cluster. If Server A and Server B form a cluster, then the HttpClusterServlet will load-balance new requests between the servers, and session replication and failover will occur as detailed in the previous section. The cluster servlet maintains a list of all the servers participating in the cluster and avoids redirecting to failed servers. The client has direct access to the Front Server only, and remains unaware of the actual cluster member that eventually processes its requests.

The configuration entails several tasks, and we will use the architecture in Figure 2-2 in our configuration details.

• The HttpClusterServlet servlet has to be registered in the web application, and the web application must be deployed on Front Server. You typically would make the web application the default web application.
• You have to configure the servlet engine to send certain URL patterns through to the HttpClusterServlet servlet. The servlet will then pass these on to the cluster and return the results.
• You have to configure the HttpClusterServlet so that it knows the addresses of the servers participating in the cluster.
• You must deploy your web application to the cluster. Make sure the web application has its PersistentStoreType attribute set to replicated.

Registering the servlet is like registering any other servlet. The class name for the servlet is weblogic.servlet.proxy.HttpClusterServlet, and it is included within WebLogic's runtime libraries. The following snippet from the web.xml descriptor file does the job:

 HttpClusterServlet 
 
 weblogic.servlet.proxy.HttpClusterServlet
  
 

As shown earlier in this chapter, you can create a servlet mapping to determine the set of URLs to pass to the servlet. For instance, we would like a request such as http://10.0.10.10/index.jsp to result in the cluster servlet being invoked, which will in turn proxy through to the appropriate server in the cluster. The easiest way to establish a mapping for all files is to use the special shortcut URL pattern, /, together with explicit mappings for HTML and JSP files:

 HttpClusterServlet 
 / 



 HttpClusterServlet 
 *.jsp 



 HttpClusterServlet 
 *.html 

The servlet also has to be configured with the addresses of the servers in the cluster and other information. This must be done with the servlet initialization parameters. The most important parameter, WebLogicCluster, configures the addresses and ports of the members of the cluster. For the preceding example, you need the following:

 WebLogicCluster
 
 10.0.10.12:7001:7002|10.0.10.14:7001:7002
  

The servlet can take a whole host of additional parameters, all of which are detailed in the proxy plug-in documentation in Chapter 3.

Once the cluster servlet has been configured and deployed, requests to the server Front Server will be mapped to the appropriate server in the cluster. So, assuming we have a web application deployed to the cluster, accessing http://10.0.10.10/index.jsp will result in the following activity:

1. WebLogic's servlet engine on Front Server will find a matching URL pattern and will send the request to the cluster servlet.
2. The cluster servlet will consult its internal list of available cluster members and forward the request to either Server A or Server B. In fact, it also will check to see if the request is associated with a user in a session, in which case it will try and forward to the server hosting the primary session state.
3. The server in the cluster tier will execute the request, feeding the result back to the cluster servlet, which will in turn feed the result back to the user.

2.8.2 Debugging the Configuration

The HttpClusterServlet supports the DebugConfigInfo initialization parameter, which is useful for debugging the servlet's configuration. If you've specified this initialization parameter for the HTTPClusterServlet, the servlet returns the details of its configuration whenever you invoke a servlet along with the query parameter _ _WebLogicBridgeConfig, instead of passing the request through to the cluster. In order to debug the servlet's configuration, you need to use the web.xml descriptor file to specify the initialization parameter for the HttpClusterServlet:

 DebugConfigInfo
 ON

Now you can view the configuration of the HttpClusterServlet by navigating to a URL similar to http://10.0.10.10/index.jsp?__WebLogicBridgeConfig. In the case of our example cluster setup, we obtain the following details on the servlet's configuration:

Query String: _ _WebLogicBridgeConfig

Primary Server: 10.0.10.12:7001:7002

General Server List: 
10.0.10.12:7001:7002 
10.0.10.14:7001:7002

ConnectRetrySecs: 2
ConnectTimeoutSecs: 10
CookieName: JSESSIONID
Debug: false
DebugConfigInfo: true
DefaultFileName: null
DisableCookie2Server: false
DynamicServerList: true
FileCaching: true
HungServerRecoverSecs: 300
Idempotent: true
KeepAliveEnabled: true
KeepAliveSecs: 30
MaxPostSize: -1
MaxSkipTime: 10
PathPrepend: null
PathTrim: null
TrimExt: null
SecureProxy: false
WLLogFile: c:/temp/wlproxy.log
WLProxySSL: false

Note how the output lists the servers participating in the cluster, and also indicates the primary server to which the request has been bound (if any).