Sun Java System Directory Server Enterprise Edition 6.1 Reference

Load Balancing

When more than one data source is attached to a pool, load balancing determines which data source in the pool responds to the request.

For information about load balancing, see the following sections:

Introduction to Load Balancing

Directory Proxy Server distributes requests according to a load balancing algorithm. The following load balancing algorithms can be configured:

Proportional algorithm

Requests are distributed according to the weight of the data source and the cumulative load of the data source since the last startup of Directory Proxy Server.

Saturation algorithm

Requests are distributed according to the weight of the data source and the number of available connections on the data source.

Operational affinity algorithm

Requests are distributed according to the hash value. The number of hash values that are allocated to an attached data source is proportional to the weight of that data source.

Failover algorithm

Requests are distributed exclusively to the attached data source with the highest weight for that operation.

In all load balancing algorithms, each attached data source can be configured with an independent weight for each of the following types of operation:

If multiple attached data sources are configured with the same weight for a given type of operation, Directory Proxy Server distributes the requests evenly between the data sources. If a data source has a weight of disabled for a particular type of operation, Directory Proxy Server never distributes requests of that type to the data source. If a data source has a weight of 0 (zero) no requests are distributed to that data source unless all other data sources are unavailable. Therefore, data sources configured with a weight of 0 are used only when all other data sources are down.

An attached data source cannot be selected by the load balancing algorithm in the following circumstances:

If a data source is configured as read-only, the data source cannot receive add, delete, or modify requests. The data source can receive search requests.

The load balancing algorithm works on a best-effort basis. If there are not sufficient resources for the load balancing algorithm to distribute requests by respecting weights, the weights are overruled. For example, if the number of simultaneous requests to a data source exceeds the maximum number of connections to that data source, requests are distributed to other data sources.

When the client affinity feature is active, Directory Proxy Server distributes requests by using the client affinity feature instead of using the load balancing algorithm. For information about client affinity, see Client Affinity.

Proportional Algorithm for Load Balancing

In the proportional algorithm, requests are distributed to attached data sources according to the following criteria:

After startup, the first request of a given type is distributed to the data source with the highest weight for that type of request. Directory Proxy Server continues to distribute the requests in proportion to the weight of each data source for that type of request.

If a data source becomes unavailable, Directory Proxy Server distributes the requests to remaining data sources in proportion to their weight.

The following figure illustrates how Directory Proxy Server distributes the first eight search requests to a pool of data sources with different weights. The data source with a weight of 2 processes twice as many requests as the data sources with a weight of 1.

Figure 16–1 Distribution of Requests According to the Proportional Algorithm for Load Balancing

Figure shows how requests are distributed to a group
of data sources by using the proportional algorithm for load balancing.

For an example of how configure the proportional algorithm, see To Configure the Proportional Algorithm for Load Balancing in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

Saturation Algorithm for Load Balancing

In the saturation algorithm, requests are distributed to data sources according to a combination of the weight of the data source and the number of available connections.

All requests of a certain type are distributed to the data source with the highest weight, until its saturation level is reached. Once this level is reached, requests are distributed between this data source and the data source with the next highest weight. The saturation level is obtained by multiplying the weight of the data source by the total number of connections.

The following figure illustrates how Directory Proxy Server distributes requests to a pool of data sources with 10 connections and different weights. The number of available connections multiplied by the weight is shown in brackets.

Figure 16–2 Distribution of Requests According to the Saturation Algorithm for Load Balancing

Figure shows how requests are distributed to a group
of data sources by using the saturation algorithm for load balancing.

If your deployment includes data sources with greatly different capacity, you can use the saturation algorithm to distribute requests according to the capacity of the data source.

For an example of how configure the saturation algorithm, see To Configure the Saturation Algorithm for Load Balancing in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

Operational Affinity Algorithm for Load Balancing

In the operational affinity algorithm for load balancing, all requests are allocated a hash value according to the request type and request properties. Each hash value is allocated to an attached data source. The number of hash values that are allocated to a data source is proportional to the weight of the data source.

When a request is received, Directory Proxy Server examines the hash table to determine whether a request with that hash value has already been distributed. If the hash value already exists in the hash table, Directory Proxy Server sends the request to the data source with that hash value. If the hash value does not exist in the hash table, the request is distributed by using the proportional algorithm for load balancing.

Figure 16–3 shows an example with three attached data sources. Data source A has a weight of 3 for search operations, the other data sources have a weight of 1 for search operations. The hash table allocates 3/5ths of the hash values to data source A, 1/5th to data source B, and 1/5th to data source C.

If requests have a normal range of diversity, data source A would receive three times more requests than data source B or data source C. If there is a disproportionate number of requests with identical properties, the ratio of requests between the three data sources is disturbed. For example, if a client make repeated BIND requests on the same DN, the BIND must always be serviced by the same data source.

Figure 16–3 Distribution of Requests According to the Operational Affinity Algorithm for Load Balancing

Figure shows how requests are distributed by the operational
affinity algorithm for load balancing.

The use of the operational affinity algorithm for load balancing is beneficial for the following features:

Disadvantage of Using the Operational Affinity Algorithm for Load Balancing

The operational affinity algorithm for load balancing does not ensure an evenly distributed work load across data sources.

A hash value is allocated to a request according to the type of request and the properties of the request. A range of hash values represents an arbitrary group of unrelated requests. It is possible for one range of hash values to represent many more operations than another range of hash values. A given range of hash values might represent requests that are made frequently, another range of hash values might represents requests that are almost never made.

Operational Affinity Algorithm for Global Account Lockout

By using the operational affinity algorithm for load balancing, you can ensure that the same data source always responds to bind requests from a given client. In this way, you can ensure that a client is locked out after the maximum number of failed bind attempts. If the same data source does not respond to bind requests from a given client, the client can exceed the maximum number of failed bind attempts.

When a client binds, a hash value for the request is allocated according to the bind credentials. Directory Proxy Server consults the hash table and distributes the request to the data source for that hash value. No matter how many times the client binds, the hash value is always the same. The request is always distributed to the same data source.

If a client requests a bind without the appropriate credentials, the data source rejects the bind request. If the client makes a second or third bind request, the same data source rejects the bind request. When the client exceeds the maximum number of allowed bind attempts, Directory Server locks the client out.

For an example of how configure the operational affinity algorithm for global account lockout, see To Configure the Operational Affinity Algorithm for Global Account Lockout in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

Operational Affinity Algorithm for Cache Optimization

By using the operational affinity algorithm for load balancing, searches from the same client to the same entry can always be distributed to the same data source. When a data source responds to a request, the targeted entry is stored in the cache. If the same data source responds repeatedly to the same request, the data source can benefit from using the cached data.

For an example of how configure the operational affinity algorithm for cache optimization, see To Configure Operational Affinity Algorithm for Cache Optimization in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

Failover Algorithm for Load Balancing

In the failover algorithm, requests of a given type are distributed exclusively to the attached data source with the highest weight for that operation. If that attached data source fails, requests are distributed exclusively to the attached data source with the next highest weight for that operation. If the data source with the highest weight comes back on line, requests are distributed to that data source.

For an example of how configure the failover algorithm, see To Configure the Failover Algorithm for Load Balancing in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.