| Oracle® Fusion Middleware Reference for Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7.0) Part Number E28969-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Reference for Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7.0) Part Number E28969-01 |
|
|
PDF · Mobi · ePub |
Deployments that use more than one data source to respond to client requests use load balancing to distribute work load. Client affinity can be used to reduce the risk of propagation delay in load balanced deployments.
For information about how to configure load balancing and client affinity, see Chapter 20, Directory Proxy Server Load Balancing and Client Affinity, in Administrator's Guide for Oracle Directory Server Enterprise Edition.
For information about how the Directory Proxy Server performs load balancing and client affinity, see the following sections:
Requests from clients are distributed to an LDAP data source pool. One or more data sources are attached to the data source pool. The properties of a data source pool determine how client requests are routed to the different LDAP data sources that are attached to the pool. The following properties can be configured for an LDAP data source pool:
client-affinity-policyThe algorithm used to determine when client requests should exhibit affinity to a single LDAP data source
client-affinity-timeoutThe client affinity time-out duration
descriptionA description of the LDAP data source pool
enable-client-affinityA flag indicating whether or not consecutive requests from the same client should be directed to the same LDAP data source
load-balancing-algorithmThe algorithm used to distribute operations over load-balanced LDAP data sources
For information about how to create and configure an LDAP data source pool, see Creating and Configuring LDAP Data Source Pools in Administrator's Guide for Oracle Directory Server Enterprise Edition.
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:
Directory Proxy Server distributes requests according to a load balancing algorithm. The following load balancing algorithms can be configured:
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.
Requests are distributed according to the weight of the data source and the number of available connections on the data source.
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.
Requests are distributed exclusively to the attached data source with the highest weight for that operation.
Requests are distributed to a set of data sources with enough added weight to provide the minimum total weight required.
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.
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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/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
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.
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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 Administrator's Guide for Oracle Directory Server Enterprise Edition.
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 Administrator's Guide for Oracle Directory Server Enterprise Edition
Client affinity is defined between a client connection and a data source. When client affinity is defined, requests from a specified client connection are distributed to a specified data source in a data source pool.
The client affinity feature reduces the risk of propagation delay in deployments that use load balancing. Propagation delays can occur when a client makes consecutive requests that target the same entry if those requests are not treated by the same data source. For example, a client might make one request to change an entry and a second request to use the changed entry. If the second request is treated by a data source that has not been updated by the first request, an error occurs.
Client affinity can be configured in the following ways:
Enabled or disabled
Configured for all write requests after the first write request
Configured for all requests after the first write request
Configured for all requests after the first read request or write request
Configured for first read request after a write request
Configured to expire after a specified time
Client affinity takes precedence over the load balancing algorithm. Directory Proxy Server distributes a request from the specified connection to the specified data source, irrespective of the load balancing algorithm.
If client affinity is defined and enabled, the load balancing algorithm takes precedence in the following circumstances:
The request that starts client affinity has not occurred
The request that ends client affinity has occurred
The client affinity time-out has expired
The specified data source cannot be used for a request, or an error has occurred on the specified data source
A data source cannot be used for a request in the following circumstances:
It is offline.
It is not configured to perform the operation being requested. For example, a data source that is configured for read requests cannot respond to write requests.
For information about how to configure client affinity, see Configuring Client Affinity in Administrator's Guide for Oracle Directory Server Enterprise Edition.
The client affinity feature must be used to configure Directory Proxy Server as a simple, connection based router. For information, see Configuring Directory Proxy Server as a Connection Based Router in Administrator's Guide for Oracle Directory Server Enterprise Edition.
|
 Copyright © 2001, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|