Chapter 7: Load Balancing, Failover, and Component Availability  Understanding high availability

Chapter 7: Load Balancing, Failover, and Component Availability

Understanding load balancing

Load balancing in an EAServer cluster is determined by three factors, each of which is discussed in detail in this section:

Load metrics

Load metrics is a collection of system statistics that define a load on a server. Each server in a cluster is assigned a value, or normalized load, based on the load metrics.

Many factors affect overall system performance and throughput of a server. The load metrics that EAServer uses to determine the normalized load are:

When overall cluster load is light, incoming requests are evenly distributed to all member servers; that is, all member servers have some load. When the cluster becomes more loaded, the load is distributed according to a server’s current load.

How load metrics work

Various system load metrics are collected at each sampling interval by the load collector in each server. At each broadcasting interval, the load collector broadcasts its load metrics to all member servers. At each calculating interval the load collectors in the name servers calculate and generate a normalized load list (NLL) of all member servers sorted according to their load metrics. The NLL consists of two elements: the server name and normalized load number. For example, a three-server cluster may have an NLL of:

(Jaguar_server_A, 5), (Jaguar_server_B, 3), (Jaguar_server_C, 1)

Which indicates that the load of Jaguar_server_A is five times greater than the least-loaded server, Jaguar_server_C.A normalized load number ranges from 1 to 5 and is generated by combining all weighted load metrics. A value of 5 indicates a heavily loaded server, while a 1 indicates a lightly loaded server.

All name servers have their own copies of the NLL, which reflects the Naming Service’s view of system-wide load distribution that remains static for an entire refresh interval.

The NLL is referenced to balance the load of a cluster if an adaptive load distribution policy is used. See “Load distribution policies” for information about the various distribution policies.

Load distribution policies

There are four load distribution policies:

The first three policies do not rely on load metrics, so there is no need to obtain an NLL.

The naming service applies the selected load distribution policy and generates an IOR with multiple profiles. See “Interoperable object references” for more information.

Random and round-robin policies

Both random and round-robin policies attempt to evenly distribute incoming client requests to all participating servers. These distribution policies are ideal for a cluster with comparable physical nodes that have similar performance characteristics.

Weighted policy

The weighted policy allows you to specify the processing load to each server. This policy is designed for physical nodes with a wide range of performance variations. You can specify any weight between 1and 5 for each server. A larger number indicates that the server can handle a larger load.

Adaptive policy

The adaptive policy is similar to the weighted policy but adapts for runtime load variation. It examines the NLL for current load metrics, and compensates for uneven loads by distributing proportionately more client requests to lightly loaded servers. There is more overhead with the adaptive policy than the other policies.

Load collectors reside in each server, and the failure of any load collector has no global effect. If a broadcast of load metrics from a particular load collector has not been received for a predefined period of time, the corresponding server is dropped from the NLL.The load distribution is fully synchronized and is linked to the name servers as part of the naming services. The high availability protection for naming services also applies to dynamic load balancing. See “Understanding high availability” for more information.

Interoperable object references

Load balancing uses EAServer’s naming service to distribute incoming IIOP requests across the servers within an EAServer cluster:

  1. The client obtains a factory IOR from the name server when it performs a lookup operation on a component. This factory IOR contains a profile (a server::port combination) that identifies the servers from which the component is available. There is a profile for each server, or if a single server has multiple IIOP ports, a profile for each port.

    The name server uses the selected load distribution policy and generates an IOR with multiple profiles to balance the requests between available servers and ports. If a dynamic load policy is selected, the NLL is used to determine and balance the load of the individual servers.

  2. Using the factory IOR, the client contacts a server using one of the profiles to obtain the IOR for the component. The IOR for the component has only one profile within it.

  3. The client sends the IIOP request to the profile specified by the IOR of the component.

    See the EAServer Programmer’s Guide for detailed information.

Copyright © 2005. Sybase Inc. All rights reserved. Understanding high availability