An SAP J2EE Engine 6.20 cluster is a group of independent nodes managed as a single system for higher availability and reliability, easier manageability and greater scalability. Clustering minimizes response time to client requests and provides scalability by adding more nodes to an existing system, thereby minimizing the risk of system disruption. Clustering results in improved manageability because the system administrator can manage the cluster remotely from a central location. The cluster appears to him or her as containing no nodes, but as a single system.
SAP J2EE Engine 6.20 cluster solution includes dynamic cluster load balancing, fail-over recovery, component clustering, and data replication.
SAP J2EE Engine 6.20 Load Balancing distributes client requests proportionally to the servers in the cluster, so the full capacity of each server can be reached. Data is registered about the load factor of each server. The system locates the least-busy server on which the specific service is running, and reroutes the request to that server node for further processing.
Note: For more information on how to use the SAP J2EE Engine 6.20 Load Balancing System, refer to the Managing the Load Balancing System section in the Configuration Tasks chapter.
An important feature of an SAP J2EE Engine 6.20 cluster is the quick fail-over recovery. Besides the simple type of fail-over recovery in which the dispatcher reroutes the request of the client to another server in case of a failure, SAP J2EE Engine 6.20 persistent engine (DBMS Service) provides replication of data, to achieve improved and faster fail-over recovery and optimal cluster performance.
The data replication mechanism supported by SAP J2EE Engine 6.20 Database Management System Service is synchronous replication. Data is replicated on all specified server nodes in the cluster simultaneously. Core services that store data in SAP J2EE Engine 6.20 persistent storage are “Naming Service” and “Security Service.” Their session-level data (or only parts of it), as specified by the system administrator or the service, can be replicated on other server nodes in the cluster to achieve session-level fail-over recovery, greater availability, and optimal performance of the SAP J2EE Engine 6.20 cluster. When a service whose data is replicated fails, DBMS selects one of the running servers where this data exists and reroutes the particular request. In this way, fail-over recovery is achieved and a single server node overloading is prevented.
Clients get access to SAP J2EE Engine 6.20 services using a Java Naming and Directory Interface (JNDI) compliant naming service. SAP J2EE Engine 6.20 Naming Service is a distributed, scalable and reliable system that appears as a single unit to the client. The client request can be processed by any of the SAP J2EE Engine 6.20 server nodes, but from the client’s perspective it has connected to the cluster.
Session EJBs in SAP J2EE Engine 6.20 work locally and independently of each other. They are not clustered and do not communicate with other Session EJBs on other server nodes in the cluster.
Entity EJBs, as opposed to Session EJBs, are clustered. Because all entity EJBs are deployed on all server nodes in the cluster, each of these nodes contains instances of this bean. An SAP J2EE Engine 6.20 entity bean container conditionally divides container-managed entity beans into two types: cached and not cached. Each server node in the cluster is responsible for the primary keys of a given number of cached container-managed entity beans and performs database operations for these beans. With the presence of server nodes responsible for the primary keys of a given number of beans, faster access to data is achieved, because the server node updates the bean data on the other server nodes at their request.
In EJB1.1 Service for cached container-managed entity beans, there is a mapping between each primary key and the ID of the server responsible for the given key. In this way, each server node in the cluster can obtain information about the server that is responsible for each primary key. The server node responsible for the particular primary key synchronizes the calls to the bean, thereby preventing dirty writing. The mapping is changed each time a new server node is added to the cluster. When a server node is removed from the cluster, only the mapping of those primary keys that were mapped to the removed server node is changed.
Servlets and Java Server Pages can also be clustered. Typically, this is achieved through deployment on multiple servers. When the servlet or JSP is deployed on a server node, the Servlets_jsp Service also deploys it on the other server nodes in the cluster. This achieves faster request processing and greater scalability.