Clusters and workload management


 

+

Search Tips   |   Advanced Search

 

Clusters are sets of servers that are managed together and participate in workload management. Clusters enable enterprise apps to scale beyond the amount of throughput capable of being achieved with a single appserver. Clusters also enable enterprise apps to be highly available because requests are automatically routed to the running servers in the event of a failure.

The servers that are members of a cluster can be on different host machines. In contrast, servers that are part of the same node must be located on the same host machine. A cell can include no clusters, one cluster, or multiple clusters.

Servers that belong to a cluster are members of that cluster set and must all have identical application components deployed on them. Other than the applications configured to run on them, cluster members do not have to share any other configuration data. One cluster member might be running on a huge multi-processor enterprise server system, while another member of that same cluster might be running on a smaller system. The server configuration settings for each of these two cluster members are very different, except in the area of application components assigned to them. In that area of configuration, they are identical. This allows client work to be distributed across all the members of a cluster instead of all workload being handled by a single appserver.

By creating a cluster, you make copies of an existing appserver template. The template is most likely an appserver that we have previously configured. we are offered the option of making that server a member of the cluster. However, IBM recommends that you keep the server available only as a template, because the only way to remove a cluster member is to delete the appserver. When you delete a cluster, you also delete any appservers that were members of that cluster. There is no way to preserve any member of a cluster. Keeping the original template intact allows you to reuse the template to rebuild the configuration.

A vertical cluster has cluster members on the same node, or physical machine. A horizontal cluster has cluster members on multiple nodes across many machines in a cell. Configure either type of cluster, or have a combination of vertical and horizontal clusters.

Clustering appservers that host Web containers automatically enables plug-in workload management for the appservers and the servlets they host. The routing of servlet requests occurs between the Web server plug-in and clustered appservers using HTTP transports, or HTTP transport channels.

This routing is based on weights associated with the cluster members. If all cluster members have identical weights, the plug-in sends equal requests to all members of the cluster, assuming there are no strong affinity configurations. If the weights are scaled in the range from zero to twenty, the plug-in usually routes requests to those cluster members with the higher weight values.

Use the admin console to specify a weight for a cluster member. The weight you assign to a cluster member should be based on its approximate, proportional ability to do work. The weight value specified for a specific member is only meaningful in the context of the weights you specify for the other members within a cluster. The weight values do not indicate absolute capability. If a cluster member is unavailable, the Web server plug-in temporarily routes requests around that cluster member.

For example, if we have a cluster that consists of two members, assigning weights of 1 and 2 causes the first member to get approximately 1/3 of the workload and the second member to get approximately 2/3 of the workload. However, if we add a third member to the cluster, and assign the new member a weight of 1, approximately 1/4 of the workload now goes to the first member, approximately 1/2 of the workload goes to the second member, and approximately 1/4 of the workload goes to the third member. If the first cluster member becomes unavailable, the second member gets approximately 2/3 of the workload and third member gets approximately 1/3 of the workload.

The weight values only approximate the load balance objectives. There are other application dependencies, such as thread concurrency, local setting preferences, affinity, and resource availability that are also factors in determining where a specific request is sent. Therefore, do not use the exact pattern of requests to determine the weight assignment for specific cluster members.

Workload management for EJB containers can be performed by configuring the Web container and EJB containers on separate appservers. Multiple appservers can be clustered with the EJB containers, enabling the distribution of enterprise bean requests between EJB containers on different appservers.

In this configuration, EJB client requests are routed to available EJB containers in a round robin fashion based on assigned server weights. The EJB clients can be servlets operating within a Web container, stand-alone Java programs using RMI/IIOP, or other EJBs.

The server weighted round robin routing policy ensures a balanced routing distribution based on the set of server weights that have been assigned to the members of a cluster. For example, if all servers in the cluster have the same weight, the expected distribution for the cluster is that all servers receive the same number of requests. If the weights for the servers are not equal, the distribution mechanism sends more requests to the higher weight value servers than the lower weight value servers. The policy ensures the desired distribution, based on the weights assigned to the cluster members.

We can choose to have requests sent to the node on which the client resides as the preferred routing. In this case, only cluster members on that node are chosen (using the round robin weight method). Cluster members on remote nodes are chosen only if a local server is not available.

Multiple servers that can service the same client request form the basis for failover support. If a server fails while processing a client request, the failed request can be rerouted to any of the remaining cluster members. Even if several servers fail, as long as at least one cluster member is running, client requests continue to be serviced.

The backup cluster still functions even if all of the members of the primary cluster are not available.



 

Related concepts


Introduction: Clusters
Backup clusters

 

Related tasks


Create clusters
Replicating data across appservers in a cluster
Balancing workloads

 

Related


Cluster member settings