What Is Clustering?

Clustering in the Web Tier

All Web-enabled enterprise applications use some type of Web server to serve HTML pages back to the end user. A third-party vendor normally will provide the Web server, but some are actually built into or packaged with the application server. Either way, the end user makes a request for an HTML page that must be serviced by a Web server. If you are using a single Web server to handle the requests , the Web server is a single point of failure for your application. If the Web server were to have a serious failure and stop servicing requests, users would not be able to use the site.

Therefore, for any serious Web-enabled application that must have a high availability, it's very important to support some type of load balancing or clustering in this tier. There are several ways to structure the support for clustering in the Web tier. One simple way is to have several Web servers that each can handle the requests independently of each other. You then can use the Domain Name Service (DNS) to shuffle the requests around between the Web servers each time a request is made. This provides a simple form of load balancing and failover mechanism because a client request normally will go to the first IP in the list provided by the DNS. If this IP doesn't respond after a certain timeout period, it could request servicing from another one in the list. This technique is commonly referred to as DNS round- robin . Figure 22.1 shows an example of how DNS round-robin works.

Figure 22.1. Use DNS round-robin for basic Web server load balancing and failover.

If you need more of a heavyweight load balancing solution in your Web tier, you could use one of the several IP load-balancing products on the market, or it's possible that your application server vendor supports this feature in its product. IP load balancing uses more advanced techniques to determine which Web server should get the next request based on a combination of dynamic loads on each server, latency, which server got the last request, and other factors.

A couple of products that provide more advanced features are Central Dispatch from Resonate. You can find information at its Web site:

http://www.resonate.com/products/central_dispatch

and also Cisco's Local Directory, on which you can find more information at

http://www.cisco.com/univercd/cc/td/doc/pcat/ld.htm

There are several other products available for load balancing in the Web tier. These two links should get you started in the right direction.

Managing Session State

One very important aspect that must be figured out and dealt with on the Web tier is how to maintain the session state for a user when a failure occurs. To do this, you need some way of persisting the session state either each time there is a modification to it or at least periodically. As you can imagine, there can be significant overhead in keeping every user's session persistent or maintaining a redundant copy of the session on another machine.

A less expensive solution is to update or persist the session information only when significant operations occur. The application could have certain checkpoints that when the user reaches one, their session state gets persisted by the system so that if a system failure does occur, you could at least go back to that last checkpoint. This is sometimes a good tradeoff for the users. The difficult part is trying to figure out where those checkpoints are.

Up to this point, we have been assuming that session load balancing occurred only at session initiation time and not for every Web hit. You might have constraints or nonfunctional requirements that force your architecture to load balance every Web hit and to have each sequential request be potentially handled by a different Web server or servlet instance.

If this is the case, some servlet engines provide a servlet session state manager, which helps maintain the state while at the same time helping to direct the requests to a different servlet instance in a different servlet engine for each hit. However, this is a pretty heavyweight solution. Be sure you really understand the nonfunctional requirements before implementing such a complex solution on your Web tier.

Some application servers can be configured to have the servlet engine and Web server located within the EJB container. This could be done within a single Java Virtual Machine (JVM) or in separate ones, depending on the vendor and configuration. This can improve performance of caching session state because it allows the state to move closer to a possible persistence store. At the same time, the calls between the Web tier and application tier don't have to travel over the network. Not all your customers will allow this solution, however, because usually there is a required separation between the Web server and resources that the Web server wants to access. This is done for security reasons and usually enforced with one or more hardware firewalls. The areas where the Web servers are located are commonly referred to as Demilitarized Zones (DMZs). Be sure you understand the target environment for your application before making significant architectural decisions.