A Primer on J2EE Clusters for Webhosting - Cluster Architecture and Communication In a Cluster
(Page 3 of 4 )
Determining the cluster architecture is the first step in configuring the cluster. Since there are many diverse deployment scenarios, it is logical that the possible configurations are also diverse. Although there is no universally recommended cluster architecture, there are some universally valid rules to keep in mind when configuring the cluster.
First, you need to consider what kind of applications will be deployed. Then, taking into account the available hardware resources, consider how you will implement load balancing and fail over. It is also very important to think in advance about which objects will be clustered and how exactly you plan to do it. As you have already guessed, there are so many possible cluster architectures that there is hardly one that fits all cases. The next three diagrams present three very basic architectures.
A Combined Tier Cluster Without a Dispatcher
The next diagram presents a basic confuguration for a cluster solution without a dispatcher. This is a combined tier architecture and each server runs the same objects (HTTP pages, servlets, EJBs, etc.) as the other servers in the cluster. No server instance communicates directly with clients, but all servers can communicate directly with each other and with the backend (the database) when needed to service a client's request.
Figure 1 – A Combined Tier Cluster Without a Dispatcher
The advantages of a combined tier without a dispatcher configuration are its simplicity and robustness, and this is absolutely enough in many situations, although it does not fully utilize the load balancing and fail over capabilities of clusters. In some cases you will choose hardware load balancing, which needs additional configuration for faultless communication with the cluster.
Combined Tier Cluster With a Dispatcher
The combined cluster tier with a dispatcher is basically the same as the one without a dispatecher in regard to the way objects (HTTP pages, EJBs, JSPs, etc.) are deployed. In this case, the dispatcher is part of the cluster itself, and no external hardware or software is necessary to ensure load balancing and fail over. Again, simplicity and ease of administration are among its major advantages, but the dispatcher itself could turn into a bottleneck and a single point of failure.
Of course, it is not mandatory to have only one dispatcher. If the load is heavy, you could easily set up two or more dispatchers, and it is possible for each of them to communicate with all the servers in the cluster. It is true that several dispatchers in a cluster are like several managers of a team; it takes more communication and synchronization efforts to avoid each dispatcher giving contradicting requests to the the servers, but for servicing millions or billions of clients' requests, this is the escape from the single point of failure trap.
Figure 2 - A Combined Tier Cluster With a Dispatcher
Next: Multi-Tier Architecture With a Dispatcher >>
More Web Hosting How-Tos Articles
More By Blue Moon
