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

• Proportional Algorithm for Load Balancing

• Saturation Algorithm for Load Balancing

• Operational Affinity Algorithm for Load Balancing

• Failover Algorithm for Load Balancing

• Adaptive Failover Algorithm for Load Balancing

• Fastest Server Algorithm for Load Balancing

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.

Adaptive Failover algorithm

Requests are distributed to a set of data sources with enough added weight to provide the minimum total weight required.

Fastest Server algorithm

Requests are distributed exclusively to the attached data sources with the quickest response time for that type of operation.

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

• Add

• Bind

• Compare

• Delete

• Modify DN

• Modify

• Search

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.

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

• The data source is unavailable because an error occurred.

• All connections between the Directory Proxy Server and the data source are in use.

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:

• The type of request

• The weight of the data source as a ratio of the total weights of the other data sources in the pool

• The cumulative load since the last startup of Directory Proxy Server

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

For an example of how configure the proportional algorithm, see To Configure the Proportional Algorithm for Load Balancing in Oracle Directory Server Enterprise Edition 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

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 Oracle Directory Server Enterprise Edition 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/5_ths of the hash values to data source A, 1/5_th to data source B, and 1/5_th 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

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

• Global account lockout

• Cache optimization in Directory Server

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 Oracle Directory Server Enterprise Edition 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 Oracle Directory Server Enterprise Edition 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 Oracle Directory Server Enterprise Edition Administration Guide.

Adaptive Failover Algorithm for Load Balancing

This algorithm was created to remedy a situation that can occur when the failover algorithm is used. With the failover algorithm, data sources with identical weights represent a group. The requests are always sent to only one group, the group with the highest weight. A typical deployment uses a local group (all the data sources share the same high weight) and a remote group (all the data sources share the same low weight). The remote data sources are not contacted until every local data source is either down or unavailable. A consequence of using the failover algorithm is that in most situations, the groups are loaded at a maximum. If a data source is not available, then the whole group throughput is reduced.

The adaptive failover algorithm remedies this situation by defining a minimum required total weight. Data sources are separated in two groups. The active group is a set of data sources whose added weight reaches the desired minimum total weight. All the remaining data sources are classified into the stand-by group.

The active group is built by choosing the n data sources with the highest weight until the minimum total weight is reached (the mathematical sum of each data source weight). Each data source in the active group takes a share of the requests proportional to its weight. No request is sent to the data sources in the standby-group.

Group membership is dynamically re-evaluated when data sources go up or down, or when weights are changed.

The default minimum total weight is 100 and can be modified using with this command:

$ dpconf set-ldap-data-source-pool-prop -host host  -p port  pool-name  \
   minimum-total-weight:2

Figure 16-4 Distribution of Requests According to the Adaptive Failover Algorithm for Load Balancing

For more information, see To Configure the Adaptive Failover Algorithm for Load Balancing in Oracle Directory Server Enterprise Edition Administration Guide.

Fastest Server Algorithm for Load Balancing

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

• The type of request

• The response time for that type of request

When a server must be chosen to send a request, this algorithm will chose from its list of attached data sources the server with the lowest response time. The response time is measured separately for every data source and for every type of operation.

The server response time is actually the mean value of a fixed-size sample. The latest n response times are stored in this sample, and the mean value is re-computed each time a new measure is added, (possibly replacing the oldest measure). A sample (set of the latest n response times) is associated with each type of operation for each server. The sample-size (n) defaults to 100 but can be configured using the following command:

$ dpconf set-ldap-data-source-pool-prop -host host  -p port  pool-name  \
   sample-size:300

The lower the sample size, the more reactive the algorithm will be to changes in the data source response time. However, if the sample size is too low, it may have a negative impact. Operations from the same client can be sent to different data sources. A silent bind operation might be needed, which increases the response time as seen by the client.

The problem with this approach is that the server with the lowest mean response-time is always chosen. Other servers with higher mean response times will not be selected, and so their samples and means response times will not be updated. This can lead to a situation where a server with a high mean response time can actually provide a lower response time than the current fastest server. But because requests are not sent to the server with the high mean response time, its mean response time is not updated, and the server will never be the best choice from Directory Proxy Server point of view. Because of this, the throughput of the whole system can be lower than it could actually be.

To solve this situation, a second attribute exists. The proportion property indicates that 1 of the proportion operations must go to a randomly selected server instead of going to the fastest one. This value can be configured using the following command:

$ dpconf set-ldap-data-source-pool-prop -host host  -p port  pool-name  \
   proportion:100

The proportion default value is 100. This means that 99 operations go to the fastest server, and one operation goes to a randomly selected server. The random selection follows a uniform distribution. All the attached data sources are taken into consideration, even the one with the lowest response time. Because of this, the randomly selected server could happen to be the fastest server.

Setting the proportion to 0 means that the selection must always be based on the response time.

If for any reason it is not possible to get a connection to the chosen server, other servers will be tried randomly.

For more information, see To Configure the Fastest Server Algorithm for Load Balancing in Oracle Directory Server Enterprise Edition Administration Guide