J2EE Clustering 1 --- Some old

J2EE Application Server supplier defines the cluster as a set of computers, providing transparent enterprise-level services (support JNDI, EJB, JSP, HttpSession, component error recovery, etc.). They deliberately defined very vague because they The implementation of it is different. Some developers placed a Dispatcher, Dispatcher accepted a user's request in a set of inter-independent machine front, then use HTTP Redirect Header to request a specific server in a cluster. Another part development The business has achieved a combination of a closely set together, each machine can completely perceive the existence of other machines around it, along with the objects that are constrained above.

In addition to machine integration, clusters also contain redundant and error recovery:

Load balancer: Enter a single entry point, site, or traffic indicator of the site, or Application Server

Gateway router: export point of internal network

Multi-layer exchanger: package filter or frame filter, make sure that each machine receives only information related to yourself

Firewall: Port Level Filtration to prevent Hacker from entering cluster or internal network

SAN (Storage Area Networking) Controller: Connect Application Servers, Web Servers, and Databases to the back-end storage medium, which hard disk is managed; and the error backup

database

No matter how it is achieved, the cluster provides two major functions: scalability and high reliability (HA).

Scalability

Scalability refers to an application that supports the capacity of growing users. Clusters provide additional work capabilities by adding Server to ensure scalability.

High reliability

HA can be summarized by a word: Redundance. A cluster is requested with a lot of machine service, so even a machine crashes, other machines can also be transparently accessed.

The cluster only provides high reliability only on the Application Server layer. For a network system, it is necessary to express truly HA, which must provide two pieces as Noah's Ark, including Web Servers, gateway routers, swap structures. Wait.

Cluster type

J2EE cluster usually takes two ways: Shared-Nothing Cluster, and Shared Storage Clusters. In the Uncharacted Cluster, each Application Server has its own file system and the application of the application running in the cluster. Application The upgrade needs to update each node in the cluster. This setting is like a big cluster, and it is like a nightmare, especially when the code needs to be updated. Instead, share storage clusters publicly a storage device, each Application Servers So there is a running application. Update is only in a file system, and all machines can access these changes. Now, single-point failure is still its weakness. However, SAN provides a redundant The remaining logical interfaces of the media remain in order to make error recovery, error fallback and scalable. (For more information, see Storage Infrastructure.)

Comparing J2EE Application Server's cluster technology implementation, most important is to consider factors:

Cluster implementation

Error recovery of clusters and components

Error recovery of httpsession

Single point failed in the cluster topology

Variable topology

maintain

In the future, we will compare four popular Application Server cluster technology in different aspects, but first, let's take a closer look at each element.

Cluster implementation

J2EE Application Server implements clusters on the basis of JAVA Naming and Directory Interface. Although JNDI is the core of J2EE application dependencies, it is difficult to implement in the cluster, because you cannot put multiple objects bind to a JNDI name. There are three clusters of clusters based on different Application Server JNDIs.

Independent

Centralized

Global Sharing (Shared Global)

Independent JNDI TREE

HP Bluestone Total-E-Server and Silverstream Application Server uses separate JNDI Tree.jndi Tree's Server members in each Application Server does not know and care about the existence of other Server in the cluster. So error recovery is either not supported, or pass An intermediate service support for redirection HTTP or EJB Request. These intermediate services can be found in the location of each component in the cluster, and know where there is an error where there is an alternative.

One advantage of the stand-alone JNDI Tree cluster is that the cluster concentration is shorter, and the cluster concentration is measured. The cluster is completely perceived with the time indicator of all members and the objects. However, the concentration is in the independent JNDI TREE cluster It is not a problem. Once the two machines are started, the cluster can know the concentration. Another advantage is that scalability is as long as the additional machine is involved.

However, there is also a disadvantage. First, error recovery is usually the developer's responsibility. Therefore, because each Application Server JNDI Tree is independent, Remote Proxy, which is obtained through JNDI queries, is bound to the query time server. In this way, if the EJB of this call fails, the developer needs to write additional code to connect Dispatcher, get another effective server address, and then perform a JNDI query, re-call the method of just failing. Bluestone implemented one More complex forms, each request is served through an EJB Proxy service, called the Proxy LBB (Load Balance Broker). EJB Proxy Service guarantees the UBS instance of each request. This introduces additional delays, but Automatically perform error recovery.

Centralized JNDI TREE

Sybase Enterprise Application Server is a centralized JNDI Tree cluster. Concentrated JNDI Tree cluster uses CoSnaming services using CORBA in JNDI .Name Server resides in centralized JNDI Tree, which Server is started. Each server is started, Object Bind is in your JNDI Tree, and it is also bind to all the JNDI Tree in Name Server.

In this mode, you get the reference to the EJB reference. First, the user queries home object from the Name Server, the former returns an interactive object reference (IOR). IOR points to several events containing the Home object. Server. Then, the user gets Home and Remote with the first Server. If an error occurs in the EJB method call, CORBA Stub is responsible for achieving logic on another machine (listed in IOR) .Name Server itself is in this way A weakness. For example, there are 50 machines in a cluster, 5 of which are Name Server. If each Name Server is unworthy, the cluster is useless. In fact, another 45 machines are good , But the entire cluster will not process any EJB request.

When all the Name Server in the cluster crashed, another machine immediately plays the role of Name Server, resulting in another problem. In this case, the new Name Server requires all the machines in the cluster to put themselves Object BIND to JNDI Tree. Although accept requests are not tasted during bind, it is recommended not to do this. Binding process extends the recovery time of the cluster. Moreover, each JNDI query actually represents two network calls, one from Name Server Gets IOR, while the second NORT is Object from the server.

Finally, when the centralized JNDI Tree cluster expands, its concentration time is growing and longer. When expanding the scale, more and more Name Server must be added. Remember the general acceptance ratio of Name Server and the entire cluster machine. It is 1:10, and there are at least two Name Server. Therefore, if your cluster has 10 machines, two are Name Server, there are 20 bind. 40 machine clusters, 4 Name Server, There are 160 bind. Each bind represents a process on which all objects BIND to Name Server is backed above. This is the worst of centralized JNDI Tree clusters.

Global Sharing JNDI Tree

Finally, BEA WebLogic is implemented in this way, when a machine in the cluster is started, it announces its presence and its JNDI Tree. Each Server is bind. At the same time, it is also bind to a shared global JNDI Tree.

Divide JNDI TREE into globally and locally, generated Home and Remote Stub, you can recover, and provide a fast process (in-process) JNDI query. Global JNDI Tree is shared in each member, each member It can know the exact address of each object in the cluster. If Which object is on two or more machines, a special home object is bind to the global jndi tree. This home knows all EJB Object of EJB Object, generated Remote Object also knows all positions.

The main defects in global sharing are: Network traffic is very large when Server starts, and the cluster concentration is also very. Instead, this is not a problem in a separate JNDI Tree cluster, because there is no JNDI information sharing. And global sharing or The centralized cluster takes time when resume sharing or centralized JNDI Tree. In fact, since the global shared cluster uses multicast transmission JNDI information, the time to establish global JNDI TREE is ranging from Server.

The global sharing of more concentrated JNDI TREE is that the main advantage is that cluster implementation is mainly dedicated to scaling and achieving the easiness and higher reliability. By global sharing, you don't have to change Name Server's CPU and RAM, or adjust the cluster The number of Name Server. Want to expand the application size, increase the server. Moreover, if it crashes, the cluster can still work well. Finally, each remote query is completed as a network call, compared to centralized In two, there is more.

Because JSP, Servlet, EJB and JavaBean are best involved on an Application Server, they always use JNDI queries in the process. Remember if you only run the server-side application, there is no difference in the three ways. In fact, each HTTP requests in the process server JNDI query, returns the object called in the application. Next, we will focus on the second major consideration of J2EE Application Server: Cluster and Error Recovery Services.