- The Motivations for Clustered Infrastructure Solutions: Scalability and High Availability
- Understanding WebLogic Clusters
- Understanding How WebLogic Servers Communicate within a Cluster
- Designing the Architecture of a WebLogic Cluster
- Creating and Configuring a WebLogic Cluster
- Implementing a Load-Balancing Mechanism for Your Clustered Servlets and JSPs
- Implementing a Failover Mechanism for Your Clustered Servlets and JSPs
- Clustering Enterprise JavaBeans
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Implementing a Load-Balancing Mechanism for Your Clustered Servlets and JSPs
As stated earlier in this chapter, you have two options for implementing a load-balancing mechanism for your Presentation tier:
Use a WebLogic proxy plug-in.
Use a separate load-balancing hardware appliance.
Both options are discussed in detail in the following sections.
Using a WebLogic Proxy Plug-in Load-Balancing Solution
The WebLogic proxy plug-in is an ideal solution if you want to leverage an existing Web tier composed of Netscape, Microsoft, or Apache Web servers to proxy (forward) connection requests to the WebLogic cluster. Alternatively, you can also use WebLogic Server with the HttpClusterServlet as a proxy server.
In a proxy server load-balancing scenario, when an HTTP client requests a servlet or JSP, the proxy plug-in or HttpClusterServlet proxies the request to a managed server in the WebLogic Server cluster. The accessed servlet or JSP maintains data on behalf of a connecting client by using a dedicated HttpSession object, which is created on a per-session basis. When the HTTP response is sent back to a client via the proxy server, the client's browser is instructed to write a cookie that lists the primary and secondary locations of the session's HttpSession object.
TIP
If the client's browser does not support cookies, the managed server can use URL rewriting instead to embed the primary and secondary locations of the HttpSession object into the URLs passed between the client and proxy servers.
The primary location is the address of the managed server that received and processed the initial HTTP connection request. For subsequent HTTP requests, the proxy plug-in or HttpClusterServlet automatically maintains a "sticky" connection between the client and its primary HttpSession object location. The secondary location is the address of a managed server that maintains a replica of the HttpSession object that is used for in-memory session state failover purposes only; this object is discussed later in this chapter.
TIP
The HttpClusterServlet automatically maintains a list of managed servers in a WebLogic cluster, but you will have to configure this information manually and identically for each third-party Web server using the WebLogic proxy plug-in.
The limitation for using a proxy server load-balancing solution is that you are currently constrained to using a round-robin strategy for distributing client requests to the managed servers in a WebLogic cluster.
To showcase the load-balancing capabilities of the WebLogic proxy plug-in, as well as set up a WebLogic environment for subsequent examples in this chapter, the following section discusses how you can easily configure an HttpClusterServlet load-balancing solution.
Configuring the HttpClusterServlet As a Load-Balancing Solution
By default, the HttpClusterServlet is included with every WebLogic Server installation. However, for it to be able to function, the servlet must be deployed as the default application to WebLogic Server that will serve as the proxy server for a domain. Previously in this chapter, you configured the mycluster WebLogic cluster in your WebLogic domain. To demonstrate the load-balancing capabilities of the WebLogic proxy plug-in, you can deploy the HttpClusterServlet as the proxyApp default Web application on the administration server (AdminServer) of your WebLogic domain, which will serve as the proxy server, as illustrated in Figure 25.16.
CAUTION
This configuration is used for demonstration purposes only. In a production environment, you should use a dedicated managed server as a proxy server and ensure the administration server is used only for administration tasks.
)
Figure
25.16 Load balancing the mycluster WebLogic cluster using the HttpClusterServlet.
Follow these steps to create and deploy the proxyApp Web application to the administration server of your WebLogic domain:
NOTE
If you use different names for your domain, administration server, and WebLogic cluster, substitute those names where appropriate.
-
Create a directory named proxyApp in the root of your %BEA_Home%\ objectmind\user_projects directory. Within this directory, create another directory called WEB-INF.
-
Create a file called web.xml in the WEB-INF directory and open it with any text editor.
-
Enter the text shown in Listing 25.2, ensuring you modify the names and port numbers of the managed servers you specified when you created your WebLogic cluster.
-
Save the file.
-
Create the proxyApp Web application (WAR file) by executing the following command from within the root of the proxyApp directory:
-
From the left pane of the Administration Console, select Web Applications under the Deployments node and click the Configure a New Web Application link.
-
At the bottom of the screen, navigate until you find the proxyApp directory you created earlier. Click the proxyApp link and then click the Select link next to proxyApp.war, as shown in Figure 25.17.
-
On the Configure Application or Component screen, select your target proxy server (AdminServer) and click Configure and Deploy.
Listing 25.2 The web.xml File for the proxyApp Application
<web-app>
<servlet>
<servlet-name>HttpClusterServlet</servlet-name>
<servlet-class>weblogic.servlet.proxy.HttpClusterServlet</servlet-class>
<init-param>
<param-name>WebLogicCluster</param-name>
<param-value>EINSTEIN:7003|EINSTEINt:7005</param-value>
</init-param>
<init-param>
<param-name>DebugConfigInfo</param-name>
<param-value>ON</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
</web-app>
You can also include the following useful parameter, which creates a proxy log file under the default temp directory:
<init-param> <param-name>Debug</param-name> <param-value>ALL</param-value> </init-param>
jar cfv proxyApp.war *.*
CAUTION
Ensure that only the WEB-INF directory and web.xml file exist in this directory before you create the proxyApp Web application.
)
Figure
25.17 Selecting the proxyApp Web application for deployment.
After you deploy the proxyApp Web application, the next task is to specify that it is the default Web application on your proxy server. To do this, follow these steps:
In the left pane of the Administration Console, open the Servers directory and select your proxy server's (AdminServer) node.
Select the Connections, HTTP tab.
Select proxyApp as the Default Web Application and click Apply.
As you can see in Figure 25.18, you can test the HttpClusterServlet by using the following URL in a Web browser, substituting the correct IP address or DNS name and port for your proxy server:
http://EINSTEIN:7001/foo.jsp?__WebLogicBridgeConfig
)
Figure
25.18 Testing the functionality of the HttpClusterServlet.
From this point onward, you can access applications deployed on your WebLogic cluster via a single entry point, your proxy server, using the following URL:
http://ip_address_of_proxy_server:port_of_proxy_server/<Application>
Using a Hardware Appliance Load-Balancing Solution
If you require a more sophisticated HTTP connection distribution strategy than just purely a round-robin approach, you should opt to use a hardware load-balancing appliance solution.
In a load-balancing appliance scenario, when a client requests a servlet or JSP directly using an IP address, the load balancer routes the client's connection request to any available managed server in the WebLogic cluster in accordance with a selected load-balancing algorithm supported by the appliance. The managed server that receives the client request serves as the primary location of the client's HttpSession object. The secondary or replica HttpSession object is immediately created on another managed server. As a client initiates subsequent HTTP requests to the WebLogic cluster, the load-balancing appliance uses an identifier in the client-side cookie to ensure these requests are directed to the primary location of the client's HttpSession object.
In its default configuration, WebLogic Server uses client-side cookies to keep track of the primary and secondary locations of the HttpSession object. Hence, to ensure a "sticky" connection between the client and its primary HttpSession object location using cookies, the load-balancing appliance must support a passive or active cookie persistence mechanism, as well as SSL persistence. If cookies are not supported by the client, as in the case of WAP-enabled devices, you must do the following:
Enable the managed server's URL rewriting capabilities by setting the URLRewritingEnabled attribute in the weblogic.xml file, under the <session-descriptor> element. The default value for this attribute is true.
Configure the load-balancing appliance to extract the location of the primary HttpSession object from inbound URLs.
NOTE
If you decide to use URL rewriting, review BEA's e-docs for coding guidelines on how to programmatically handle URLs in your servlets and JSPs.