J2EE Clustering Part 1
The cluster is critical to good website design; do you understand the basics of Clustering?
By Abraham Kang
Translation Tianyu 2002-12-13
Http://www.javaworld.com/javaworld/jw-02-2001/jw-0223-extremescale_p.html
Summary
If you plan to build a scalable, available website, then you need to understand the cluster. In this article, Abraham Kang introduced the J2EE cluster, explains how to implement the cluster, investigated Bluestone Total-E-Server, Sybase Enterprise Application Server, Silverstream Application Server, and WebLogic Application Server how different methods are different. Master the cluster knowledge, you will be able to design and achieve effective J2EE applications.
Enterprises on the Web are selecting Java 2, Enterprise Edition (J2EE) to generate applications for their critical tasks. In the J2EE framework, the cluster provides a key task service that guarantees minimal download time and maximum scalability. Cluster is in a set of applications The server explicitly runs your J2EE app, just like an entity, for telescopic, you will introduce additional machines in the cluster later. Determine that each component of the cluster is redundant, to ensure the least download time.
In this article, we will have a basic understanding of clusters, clustering methods, and important cluster services. Due to the clustering mode, we will investigate the benefits and disadvantages of each way. In addition, we It will also look for important related features in the application server and discuss it.
In order to apply our new cluster knowledge to the real world, we will learn how HP Blure Total-E-Server 3.6, Silverstream Application Server 3.7 and BEA WebLogic Server 6.0 each is how to implement clusters .
In the subsequent second part, including the programming and failover strategy of the cluster. It also tested four application server products to understand how they telescopically and failed.
Cluster definition
J2EE Application Server Provider is defined by a cluster. A cluster is a robot that works together, explicitly providing corporate services (support JNDI, EJB, JSP, HTTPSession and component failover, etc. They are deliberately given Ambingly defined definition because each provider achieves a difference in cluster. Some providers put a distributor in front of a set of independent machines, and they don't know each other between these machines in the cluster. In this program The distributor receives an initial request from the user, and then the specific member server in the cluster is reached to the client through HTTP. Other providers realize a close, complete machine alliance, each machine As those objects on the machine know other machines around it.
In addition to the machine, the cluster can include redundant and failover capabilities.
· Load Balancers:
Enter the unique entry point of the cluster and pass indicator to a single web or application server
Web Servers
· Gateway router (Gateway Routers) exports outside the network.
· Multilaxyer Switches)
Packages and frame filtering ensures only information about the related machines in each machine in the cluster.
· Firewalls
Cluster protector to prevent Hackers from accessing clusters and intranets via port filtering
· Storage area network switch (SAN --- storage area networking switches)
Connect application servers, web servers, and databases to a back-end storage;
Manage write data to physical hard drives; there is a failover.
· Databases
Regardless of how they are implemented, all clusters provide two benefits: scarability and high availability (high availability --- ha). (HIGH AVAILITY --- HA)
Scarability
Scalability supports users growth to ensure the ability to apply service quality. Cluster allows you to rely on additional servers to provide additional capacity, thereby ensuring scalability.
High availability (High Availability --- HA) HA can be summarized by a word: redundancy. Clusters use many machine handling services. Therefore, if any machine in the cluster fails, another machine will take over.
The cluster only provides HA only on the application server layer. For a web system to show true HA, there must be two kinds of web servers, gateway routers, exchange infrastructure, and so on. (About HA More Content, see this ha checklist.)
Cluster type
J2EE clusters are usually popular: non-shared and shared disks. In a non-shared cluster, each application server has its own file system, and the application running in this cluster is consistent. Application update And add to update each node in the cluster. When the code is added and updated, the big cluster has a nightmare.
Instead, disk sharing clusters use a storage device that all application servers to get applications running in the cluster. Updates and add all machines in a file system, and all machines in the cluster can access these changes. Until recently Single point failure is the unfavorable aspect of this method. However, SAN gives a separate logical interface, which can enter a redundant storage intermediary providing failed transfer, feedback, and scalability. (About SAN More content, watch storage infrastructure)
Important considerations when comparing the cluster implementation of the J2EE application server:
· Cluster implementation
· Cluster and component failover service
· Httpsession failed
· Universal failure in the cluster topology
· Flexible topology planning
·maintain
In the future, we will see how four popular application servers are compared in different fields, but first let us check every item to consider more detailed.
Cluster implementation
J2EE Application Server implements a cluster around their JNDI (Java Name and Directory Interface). Although JNDI is a core service dependent on J2EE app, it is difficult to implement in the cluster because it cannot bind multiple objects in a single On the name. About the JNDI implementation of each application server has three universal cluster methods.
·independent
· Central central
· Global sharing
Independent JNDI tree
HP Bluestone Total-E-Server and Silverstream Application Server uses a separate JNDI tree that is suitable for each application server. The member server in a separate JNDI tree is not known or does not care about the existence of other services in the cluster. Therefore, no Support failover or support for media services requested by redirect HTTP or EJB. Configuration Media Services makes them know that each component is residing in the cluster and how unable to get an alternative component.
A cluster of independent JNDI trees Its advantage: shorter cluster convergence time and flexible stretching. Cluster convergence measures the time of the cluster fully knows all machines and related objects in the cluster. However, converge in a set group of a separate JNDI tree (Convert) is not a question to be concerned, because the cluster completes the convergence (Convergence). Other advantages of a separate JNDI tree: scaling only needs to increase additional servers.
However, there are also several weaknesses. First, failover is usually the agent's responsibility. That is, because the JNDI tree of each application server is independent, the remote agent re-found through JNDI is fixed to the appearance. Lookup server. In this case, if one method of calling EJB fails, the developer must write additional code to connect to the distributor to obtain another active server, do another JNDI lookup, once again call has failed Method. Bluestone implements a more complex independent JNDI tree, which is that each request has passed the EJB proxy service or a proxy LBB (Load Balance Broker). EJB proxy service guarantees that each EJB request enters an activity UBS instance. This solution adds additional reaction time to each request, but allows automatic failover between method calls.
Central central JNDI tree
The Sybase Enterprise Application Server implements a centralized JNDI tree cluster. According to this setting, the central central JNDI tree uses CORBA's cosnaming service. Name Server takes a cluster's central concentrated JDNI tree, which is clear which server is going. Just A startup, each server in the cluster is bound to its object to its JNDI tree and all naming servers.
In the cluster of a central centralized JNDI tree, you need two steps. First, the client looks up a Home object from the naming server, returns an interoperable object reference (IOR). A IOR pointing to the cluster Active HOME A few machines of the object. Second, the client picks up the first server located in IOR, get home and transote. If there is a failure between the EJB method call, CORBA Stub implements a re-acquire another home or remove. Logic. This HOME or Remote comes from an alternate server listed from the naming server. The name server itself confirms a weak point of the central concentration JNDI tree cluster. If you have a specific 50 machine cluster, there is 5 is a naming server. If the 5 naming server is down, then this cluster has not been used. Of course, another 45 machines can run, but when named server Download, this cluster will not be an EJB customer Did service.
If the cluster's original name server has failed, another problem will appear online online. If this is done, a new central centralized naming server needs to bind its objects in the cluster. To the JNDI tree of the new naming server. Although it is possible when the binding process occurs, it is not recommended because the binding process extends the recovery time of the cluster. In addition, JNDi from an Application or Applet LOOKUP, in fact, two network calls. The first call re-acquired an object from the naming server, the second call from the other, the server you specify, the client wants the object you want.
Finally, when the number of clusters of the cluster increases the increase time of the Central Convergence, the increase time of Convergence. That is to say, when you retract your cluster, you must add more named servers. Tight to name the name server. Machines and all cluster machines typically recognize the ratio of 1:10, two named servers are minimal. So, if you have a 10 machine cluster and two named servers, binding between servers and naming servers Total number can reach 20. In a 40 machine cluster and four named servers, there will be 160 binding relationships. Each binding represents one of the member servers binds all objects to a naming server JNDI tree. Process. Remember, the cluster of the central centralized JDNI tree has a worse convergence time between all JNDI cluster implementations.
Global sharing JNDI tree
Finally, Bea WebLogic implements a global shared JNDI tree. In this way, when a server in the cluster is started, the existence is announced through IP broadcast and notifies the JNDI tree to other servers in the cluster. A machine is bound to its object to globally shared JNDI tree, and bind it to its own local JNDI tree.
There is a global and local JNDI tree in each member server, allowing the generated HOME and Remote Stubs fail to transfer, and provides JNDI Lookups in a fast process. Global shared JNDI tree between all machines in the cluster They are all shared, allowing any member machine to know the exact location of all objects in the cluster. If the objects on multiple machines in the cluster are available, a special Home object is bound to the global sharing jndi tree. This special home I know all EJB objects and the location of the object associated with it, also generates a Remote object that knows all EJB objects and locations with the location associated with it.
The main disadvantages of the global sharing method: When the server starts, the excess convergence time of the cluster generated during the start of the server. On the contrary, in the cluster of a separate JNDI tree, since there is no JNDI sharing information, convergence It is not to be seen is a problem. However, all machines in the cluster, a global sharing or central concentration cluster, establish a global sharing or central concentration JNDI tree needs time. In fact, because the global sharing cluster uses broadcast transmission JNDI information, the time required to establish a global shared JNDI tree is linearly related to the number of servers in the future.
The global sharing is concentrated in free telescopic and high availability compared to the central centralized JNDI tree. Use global sharing, you don't have to mess with CPU and RAM on a special named server, do not have to adjust the number of named servers in the cluster Of course, in order to expand the application, only more machines can only be added. In addition, if some of the machine Down in the cluster fall, the cluster will continue to work. Finally, and in the cluster of the central central JNDI tree, each Remote You need two network calls that require only a single network call than that of each Remote Lookup. All of this should be a discount. Because JSPS, servlets, EJBS, and JavaBeans running on the application server. Can be shared in the EJB server. They always use JNDI Lookup in a process. Tight, if you only run the server-side app, then in standalone, centralized, or global shared cluster implementation almost There is no difference. In fact, each HTTP request will end on the application server, because the application server will use the JNDI Lookup in the process to return some objects used in your Server-Side server.
Below, we turn our attention to things that need to be considered in the J2EE application server: clusters and failover services.
Cluster and failover services.
Providing J2EE services on a machine is slightly negligible compared to the same services as the cluster. It is not high. Due to the complexity of the cluster, each application server implements cluster components in a unified approach. You should understand how the provider Communication and failover of Entity Beans, Stateless Session Beans, Stateful Session Beans, and JMS. Many providers claim to support cluster components, but what they do will usually mean components involving running in the cluster. For example, Bea WebLogic Server 5.1 Support Cluster Stateful Session Beans But if the server where the Bean instance fails, the bean's state will be lost. The client will then be recreated and resident, it is useless in the cluster. Until BEA Weblogic 6.0, Stateful Session Beans uses memory replication to handle failover and clusters.
All application servers support EJB clusters, but there is a very big difference in configurable automatic failover. In fact, some application servers rely on some of the EJB clients, do not support automatic failover. For example, Sybase Enterprise Application Server supports the Stateful Session Bean failover through the status of the BEAN from the database or serialization. As mentioned above, the BEA WebLogic 6.0 supports the failure transfer of Stateful Session Bean through the memory replication of the stateful session bean. Most applications The server can run JMS in the cluster, but do not have individual named topics (Queues) load balancing or failover, remember, you may need to purchase a jms to be clustered implementation. For example, get Topics by purchasing SonicMQ And Queues's load balance.
Now, we go to another important thing: httpsession failed.
HttpSession failed
When a session created on the original server fails, the HttpSession failed to allow the client to seamlessly get session information from other servers in the cluster. Bea WebLogic Server implements memory replication of session information, and HP Bluestone Total- E-Server has a backup made for HA, using a central centralized session server. Silverstream Application Server and Sybase Enterprise Application Server uses a central centralized database or file system to read and write.
The main disadvantage of the database / file system session persistence is focused on the restricted scalability when storing large or numerous HttpSession objects. A user adds an object to httpsession each time, all objects in the session are all written A database or shared file system. Most of the application servers that use the database session persistence advocate minimal use httpsession storage objects, but this limits the architecture and design of your web application, especially if you are using HttpSession to store cache users. Data. Memory-based session persistence stores session information in memory to backup servers. This method has two changes. The first method writes the httpsession information to a central centralized status server. All machines in the cluster put them The HttpSession object writes to this server. In the second method, each cluster node selects an arbitrary backup node to store session information in the memory. Users add an object to httpsession each time, the object is alone, then from Add to a backup server in memory.
In these methods, if the number of servers in the cluster is low, this dedicated status server proves that it is better than the memory to an arbitrary backup server because it is generated for transaction and dynamic pages, which releases the CPU cycle.
On the other hand, when the number of machines in the cluster becomes large, this dedicated state server will become a bottleneck. When you add more servers, the memory copies to an arbitrary backup server (relative to a special status server. ) Stretching linear. In addition, when you add more machines in the cluster, you also need to add more RAM and CPUS to continuously adjust this status server. For memory to a arbitrary backup server, you Simply add more machines, Sessions can be uniformly distribute themselves on all machines in the cluster.
Memory-based persistence provides flexible web application design, scalability, and high availability.
We have solved the failover of httpsession, now we will study single point failure (SINGLE POINTS OF FAILURE)
Single point failure
Cluster services without backed up are famous for unlike a single point. They will cause the entire cluster or your part of your application failed. For example, WebLogic JMS can have only one run on a single machine in the cluster. Your application relies on JMS Topics, if that The machine has a crash, your cluster falls down until another WebLogic instance starts with the JMS Topics. (Note: When starting a new instance, only persistent information will be sent.)
Ask your cluster if you have a single point failure, if any, you need to estimate whether you can endure them based on your application.
Here, the flexible telescopic topology begins.
