J2EE clustering,
Part 1 - JavaWorld February 2001
Tutorial Details:
J2EE clustering, Part 1
J2EE clustering, Part 1
By: By Abraham Kang
Clustering technology is crucial to good Website design; do you know the basics?
nterprises are choosing Java 2, Enterprise Edition (J2EE) to deliver their mission-critical applications over the Web. Within the J2EE framework, clusters provide mission-critical services to ensure minimal downtime and maximum scalability. A cluster is a group of application servers that transparently run your J2EE application as if it were a single entity. To scale, you should include additional machines within the cluster. To minimize downtime, make sure every component of the cluster is redundant.
In this article we will gain a foundational understanding of clustering, clustering methods, and important cluster services. Because clustering approaches vary across the industry, we will examine the benefits and drawbacks of each approach. Further, we will discuss the important cluster-related features to look for in an application server.
To apply our newly acquired clustering knowledge to the real world, we will see how HP Bluestone Total-e-Server 7.2.1, Sybase Enterprise Application Server 3.6, SilverStream Application Server 3.7, and BEA WebLogic Server 6.0 each implement clusters.
In Part 2 of this series, we will cover programming and failover strategies for clusters, as well as test our four application server products to see how they scale and failover.
Clusters defined
J2EE application server vendors define a cluster as a group of machines working together to transparently provide enterprise services (support for JNDI, EJB, JSP, HttpSession and component failover, and so on). They leave the definition purposely vague because each vendor implements clustering differently. At one end of the spectrum rest vendors who put a dispatcher in front of a group of independent machines, none of which has knowledge of the other machines in the cluster. In this scheme, the dispatcher receives an initial request from a user and replies with an HTTP redirect header to pin the client to a particular member server of the cluster. At the other end of the spectrum reside vendors who implement a federation of tightly integrated machines, with each machine totally aware of the other machines around it along with the objects on those machines.
In addition to machines, clusters can comprise redundant and failover-capable:
Load balancers: Single points of entry into the cluster and traffic directors to individual Web or application servers
Web servers
Gateway routers: Exit points out of an internal network
Multilayer switches: Packet and frame filters to ensure that each machine in the cluster receives only information pertinent to that machine
Firewalls: Cluster protectors from hackers by filtering port-level access to the cluster and internal network
SAN (Storage Area Networking) switches: Connect the application servers, Web servers, and databases to a backend storage medium; manage which physical disk to write data to; and failover
Databases
Regardless of how they are implemented, all clusters provide two main benefits: scalability and high availability (HA).
Scalability
Scalability refers to an application's ability to support increasing numbers of users. Clusters allow you to provide extra capacity by adding extra servers, thus ensuring scalability.
High availability
HA can be summed up in one word: redundancy. A cluster uses many machines to service requests. Therefore, if any machine in a cluster fails, another machine can transparently take over.
A cluster only provides HA at the application server tier. For a Web system to exhibit true HA, it must be like Noah's ark in containing at least two of everything, including Web servers, gateway routers, switching infrastructures, and so on. (For more on HA, see the HA Checklist .)
Cluster types
J2EE clusters usually come in two flavors: shared nothing and shared disk. In a shared-nothing cluster, each application server has its own filesystems with its own copy of applications running in the cluster. Application updates and enhancements require updates in every node in the cluster. With this setup, large clusters become maintenance nightmares when code pushes and updates are released.
In contrast, a shared-disk cluster employs a single storage device that all application servers use to obtain the applications running in the cluster. Updates and enhancements occur in a single filesystem and all machines in the cluster can access the changes. Until recently, a downside to this approach was its single point of failure. However, SAN gives a single logical interface into a redundant storage medium to provide failover, failback, and scalability. (For more on SAN, see the Storage Infrastructure sidebar.)
When comparing J2EE application servers' cluster implementations, it's important to consider:
Cluster implementation
Cluster and component failover services
HttpSession failover
Single points of failure in a cluster topology
Flexible topology layout
Maintenance
Later on we'll look at how four popular application servers compare in various areas. But first, let's examine each item in more detail.
Cluster implementation
J2EE application servers implement clustering around their implementation of JNDI (Java Naming and Directory Interface). Although JNDI is the core service J2EE applications rely on, it is difficult to implement in a cluster because it cannot bind multiple objects to a single name. Three general clustering methods exist in relation to each application server's JNDI implementation:
Independent
Centralized
Shared global
Independent JNDI tree
HP Bluestone Total-e-Server and SilverStream Application Server utilize an independent JNDI tree for each application server. Member servers in an independent JNDI tree cluster do not know or care about the existence of other servers in the cluster. Therefore, failover is either not supported or provided through intermediary services that redirect HTTP or EJB requests. These intermediary services are configured to know where each component in the cluster resides and how to get to an alternate component in case of failure.
One advantage of the independent JNDI tree cluster: shorter cluster convergence and ease of scaling. Cluster convergence measures the time it takes for the cluster to become fully aware of all the machines in the cluster and their associated objects. However, convergence is not an issue in an independent JNDI tree cluster because the cluster achieves convergence as soon as two machines start up. Another advantage of the independent JNDI tree cluster: scaling requires only the addition of extra servers.
However, several weaknesses exist. First, failover is usually the developer's responsibility. That is, because each application server's JNDI tree is independent, the remote proxies retrieved through JNDI are pinned to the server on which the lookup occurred. Under this scenario, if a method call to an EJB fails, the developer has to write extra code to connect to a dispatcher, obtain the address of another active server, do another JNDI lookup, and call the failed method again. Bluestone implements a more complicated form of the independent JNDI tree by making every request go through an EJB proxy service or Proxy LBB (Load Balance Broker). The EJB proxy service ensures that each EJB request goes to an active UBS instance. This scheme adds extra latency to each request but allows automatic failover in between method calls.
Centralized JNDI tree
Sybase Enterprise Application Server implements a centralized JNDI tree cluster. Under this setup, centralized JNDI tree clusters utilize CORBA's CosNaming service for JNDI. Name servers house the centralized JNDI tree for the cluster and keep track of which servers are up. Upon startup, every server in the cluster binds its objects into its JNDI tree as well as all of the name servers.
Getting a reference to an EJB in a centralized JNDI tree cluster is a two-step process. First, the client looks up a home object from a name server, which returns an interoperable object reference (IOR). An IOR points to several active machines in the cluster that have the home object. Second, the client picks the first server location in the IOR and obtains the home and remote. If there is a failure in between EJB method invocation, the CORBA stub implements logic to retrieve another home or remote from an alternate server listed in the IOR returned from the name server.
The name servers themselves demonstrate a weakness of the centralized JNDI tree cluster. Specifically, if you have a cluster of 50 machines, of which five are name servers, the cluster becomes useless if all five name servers go down. Indeed, the other 45 machines could be up and running but the cluster will not serve a single EJB client while the naming servers are down.
Another problem arises from bringing an additional name server online in the event of a total failure of the cluster's original name servers. In this case, a new centralized name server requires every active machine in the cluster to bind its objects into the new name server's JNDI tree. Although it is possible to start receiving requests while the binding process takes place, this is not recommended, as the binding process prolongs the cluster's recovery time. Furthermore, every JNDI lookup from an application or applet really represents two network calls. The first call retrieves the IOR for an object from the name server, while the second retrieves the object the client wants from a server specified in the IOR.
Finally, centralized JNDI tree clusters suffer from an increased time to convergence as the cluster grows in size. That is, as you scale your cluster, you must add more name servers. Keep in mind that the generally accepted ratio of name server machines to total cluster machines is 1:10, with a minimum number of two name servers. Therefore, if you have
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: J2EE clustering,
Part 1 - JavaWorld February 2001
View Tutorial: J2EE clustering,
Part 1 - JavaWorld February 2001
Related
Tutorials:
 XML messaging, Part
3
XML messaging, Part
3
|
Web services hits
the Java scene,
Part 1
Web services hits
the Java scene,
Part 1
|
Connect the
enterprise with the JCA, Part 1
Connect the
enterprise with the JCA, Part 1
|
Connect the
enterprise with the JCA, Part 2
Connect the
enterprise with the JCA, Part 2
|
Step into
the J2EE architecture and process
Step into
the J2EE architecture and process
|
Master J2ME for live data
delivery
Master J2ME for live data
delivery
|
Score big with
JSR 77, the J2EE Management Specification
Score big with
JSR 77, the J2EE Management Specification
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Business process
automation
made easy with
Java, Part 1
Business process
automation
made easy with
Java, Part 1
|
Sun boosts
Sun boosts enterprise Java
|
Get the inside
track on J2EE architect certification
Get the inside
track on J2EE architect certification
|
The J2EE 1.4 Tutorial
The J2EE 1.4 Tutorial is a guide to developing enterprise applications for the Java 2 Platform, Enterprise Edition (J2EE) version 1.4. Here we cover all the things you need to know to make the best use of this tutorial.
|
Clustering and Load Balancing in Tomcat 5, Part 1
The latest version of the Tomcat servlet container provides clustering and load balancing capabilities that are essential for deploying scalable and robust web applications.
|
Clustering and Load Balancing in Tomcat 5, Part 2
Clustering and Load Balancing in Tomcat 5, Part 2
|
Monitoring Session Replication in J2EE Clusters
Clustering has become one of the most common and most emphasized features of J2EE application servers, because, along with load balancing, it is the fundamental element on which the scalability and reliability of an application server rely.
|
Session Replication in Tomcat 5 Clusters, Part 1
The Tomcat 5 server provides built-in support for clustering and session replication. This first article in this series will provide an overview of session persistence and the inner works of session replication in Tomcat clusters.
|
Interoperability with Patterns and Strategies for Document-Based Web Services
In Part 2 of this article, we demonstrate interoperability for document-driven web services with Microsoft .NET (C#) using strategies discussed in Part 1.
|
Definition of Bioinformatics
Definition of Bioinformatics
Definition of Bioinformatics
About Bioinformatics
In February 2001, the human genome was finally deciphered! In other words, scientists have succeeded in reading the chain of more than 3 billion base pairs that
|
We are providing Downloadable Version of Dyne:bolic 1.3 Linux
We are providing Downloadable Version of Dyne:bolic 1.3 Linux
Dyne:bolic 1.3 Linux
Now Available Dyne:bolic 1.3 CD
We are providing the free downloadable version of Dyne:bolic, which is distributed under GNU public license. You have to pay only
|
Solaris 10 OS Certification Beta Exams
If you are an expert in system and network administration, you can get involved in the creation of three new Solaris 10 certification exams. These Beta exams count toward official Solaris Certification and allow you to provide comments and technical feedb
|
|
|
|
