menu

Some of the links are not working due to blogger upgrade, will fix it soon

Monday, November 15, 2010

Clustering Part III - Cluster Algorithms & Load Balancing


HTTP Load Balancing and Tunneling

When T3 tunneling is used with clients that connect to a WebLogic Server cluster using a WebLogic Server plug-in, the HttpClusterServlet, or a third party load balancer, the client will attempt to load balance requests within a session across other members of the cluster, and try to connect directly to other server instances in the cluster.
  • If a firewall exists, the direct connections will fail and the client will transparently failover use the connection through the firewall.
  • If there is no firewall, the client will connect directly to a server instance in the cluster.
To ensure that clients connect only through the tunneled connection, set the load balancing algorithm for the cluster to one of the server affinity algorithms, Set the load-balancing algorithm on the Cluster->Configuration->General tab in the Administration Console.

Load Balancing with a Proxy Plug-in
The WebLogic proxy plug-in maintains a list of WebLogic Server instances that host a clustered servlet or JSP, and forwards HTTP requests to those instances on a round-robin basis.
The plug-in also provides the logic necessary to locate the replica of a client's HTTP session state if a WebLogic Server instance should fail.
WebLogic Server supports the following Web servers and associated proxy plug-ins:
  • WebLogic Server with the HttpClusterServlet
  • Sun One Web Serverwith the Netscape (proxy) plug-in
  • Apache with the Apache Server (proxy) plug-in
  • Microsoft Internet Information Server with the Microsoft-IIS (proxy) plug-in

Load Balancing HTTP Sessions with an External Load Balancer


Clusters that utilize a hardware load balancing solution can use any load balancing algorithm supported by the hardware. These can include advanced load-based balancing strategies that monitor the utilization of individual machines.


Cluster Algorithms

Round Robin Load Balancing

WebLogic Server uses the round-robin algorithm as the default load balancing strategy for clustered object stubs when no algorithm is specified at the object level. This algorithm is supported for RMI objects and EJBs. It is also the method used by WebLogic proxy plug-ins.
The round-robin algorithm cycles through a list of WebLogic Server instances in order. For clustered objects, the server list consists of WebLogic Server instances that host the clustered object. For proxy plug-ins, the list consists of all WebLogic Server instances that host the clustered servlet or JSP.
The advantages of the round-robin algorithm are that it is simple, cheap and very predictable. The primary disadvantage is that there is some chance of convoying. Convoying occurs when one server is significantly slower than the others. Because replica-aware stubs or proxy plug-ins access the servers in the same order, a slow server can cause requests to "synchronize" on the server, then follow other servers in order for future requests.


Weight-Based Load Balancing
This algorithm applies only to EJB and RMI object clustering.
Weight-based load balancing improves on the round-robin algorithm by taking into account a pre-assigned weight for each server. You can use the Server -> Configuration -> Cluster tab in the Administration Console to assign each server in the cluster a numerical weight between 1 and 100, in the Cluster Weight field. This value determines what proportion of the load the server will bear relative to other servers. If all servers have the same weight, they will each bear an equal proportion of the load. If one server has weight 50 and all other servers have weight 100, the 50-weight server will bear half as much as any other server. This algorithm makes it possible to apply the advantages of the round-robin algorithm to clusters that are not homogeneous.
If you use the weight-based algorithm, carefully determine the relative weights to assign to each server instance. Factors to consider include:
  • The processing capacity of the server's hardware in relationship to other servers (for example, the number and performance of CPUs dedicated to WebLogic Server).
  • The number of non-clustered ("pinned") objects each server hosts.
If you change the specified weight of a server and reboot it, the new weighting information is propagated throughout the cluster via the replica-aware stubs. 

Random Load Balancing

The random method of load balancing applies only to EJB and RMI object clustering.
In random load balancing, requests are routed to servers at random. Random load balancing is recommended only for homogeneous cluster deployments, where each server instance runs on a similarly configured machine. A random allocation of requests does not allow for differences in processing power among the machines upon which server instances run. If a machine hosting servers in a cluster has significantly less processing power than other machines in the cluster, random load balancing will give the less powerful machine as many requests as it gives more powerful machines.
Random load balancing distributes requests evenly across server instances in the cluster, increasingly so as the cumulative number of requests increases. Over a small number of requests the load may not be balanced exactly evenly.
Disadvantages of random load balancing include the slight processing overhead incurred by generating a random number for each request, and the possibility that the load may not be evenly balanced over a small number of requests.

1 comment: