JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Fusion Middleware Deployment Planning Guide for Oracle Unified Directory 11g Release 1 (11.1.1)
search filter icon
search icon

Document Information

Preface

1.  Overview of Oracle Unified Directory

2.  Overview of the Directory Server

3.  Overview of the Proxy Server

4.  Overview of the Replication Gateway

5.  Building Blocks of the Proxy Server

Load Balancing Using the Proxy

Failover Load Balancing

Optimal Load Balancing

Proportional Load Balancing

Saturation Load Balancing

Search Filter Load Balancing

Data Distribution Using the Proxy

Numeric Distribution

Lexico Distribution

Capacity Distribution

DN Pattern Distribution

Global Index Catalog

DN Renaming Using the Proxy

How the DN Renaming Workflow Element Works

6.  Example Deployments Using the Directory Server

7.  Example Deployments Using the Proxy Server

8.  Simple Proxy Deployments Using the Command Line Interface

9.  Deploying Advanced Proxy Architectures

Load Balancing Using the Proxy

You can use the Oracle Unified Directory proxy to route requests across multiple data sources or LDAP servers. These LDAP servers must be replicated in order to contain identical data.

When using the Oracle Unified Directory proxy, the client requests are routed to one of the data sources based on the load balancing algorithm set.

You can choose one of the following load balancing algorithms:

Failover Load Balancing

In load balancing with failover algorithm, the Oracle Unified Directory proxy routes requests to the remote LDAP server or data center with the highest priority for a given operation type, for example for Add operations. The Oracle Unified Directory proxy continues to send requests to the priority route until the remote LDAP server goes down. This may be caused by a network cut, a hardware failure, a software failure or some other problem. At failover, the Oracle Unified Directory proxy routes incoming requests to the server with the second highest priority for that specific operation type.

Figure 5-1 illustrates a failover load balancing configuration. In this example, there are three routes, each with a unique priority per operation type. All Add operations are treated by Server 1, since it has the highest priority, that is priority=1, while Bind operations are handled by Server 2. If Server 1 goes down, the Add requests are sent to the server with the second highest priority, that is, Server 2.

Figure 5-1 Failover Load Balancing Example

Example of failover, where Server 1 is the priority server.

By default, the Oracle Unified Directory proxy does not immediately reroute requests to a server that has gone down, once it is running again. For example, if Server 1 goes down, the Add requests are sent to Server 2. Even when Server 1 is up again, Server 2 continues to handle incoming Add requests. However, if Server 2 goes down, and Server 1 is up again, Server 1 will now receive incoming requests. This default behavior can be changed with the switch-back flag. For information about configuring the switch-back flag, see Setting the switch-back Flag in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.

For failover to work effectively, the monitoring check interval must be set to be low enough so that the failover happens inside a time interval that suits your business needs. For details about setting the monitoring check interval, see Chapter 13, Monitoring Oracle Unified Directory, in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.

Optimal Load Balancing

With the optimal load balancing algorithm, the Oracle Unified Directory proxy sends requests to the route with the lowest saturation level. The Oracle Unified Directory proxy continues to send requests to this route until the saturation level of the remote LDAP server on that route passes the saturation level of the other remote LDAP servers in the deployment. The saturation level is represented as a percentage.

When the saturation level of a route changes, the load balancing algorithm re-evaluates the best route and if required, selects another route as the active one. The route with the lowest saturation level is always chosen as the optimal route. In the configuration illustrated by Figure Figure 5-5, Server 1 has the lowest saturation level and will handle all the requests until its saturation level rises above the saturation level of the other servers. If one of the servers goes down, its saturation level is considered as 100%.

Figure 5-2 Optimal Load Balancing Example

Optimal Load balancing

You can configure the saturation precision, to set the difference of saturation between two servers before the route changes to the server with the lowest saturation level. By default, the saturation precision is set to 5. However, if you find that the algorithm is switching between servers too often, you can set the saturation precision to 10, for example. The saturation precision is set in the LDAP server extension, see Setting the Saturation Precision for the Optimal or Saturation Algorithm in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.

Proportional Load Balancing

With the proportional load balancing algorithm, the Oracle Unified Directory proxy forwards requests across multiple routes to remote LDAP servers or data sources, based on the proportions set. The proportion of requests handled by a route is identified by the weight that you set for each route in your configuration. The weight is represented as an integer value.

When you define your load balancing configuration in the Oracle Unified Directory proxy, you must indicate the proportion of requests handled by each LDAP server. In the example in Figure 5-3, Server 1 handles twice as many connections as Server 2, since the weight is set with a proportion of 2:1. Server 2 and Server 3 handle the same amount of requests (1:1).

Figure 5-3 Proportional Load Balancing Example

Proportional load balancing onto three remote LDAP servers.

With the Oracle Unified Directory proxy, you can configure a specific weight for each type of client operation, as illustrated in Figure 5-4. For example, in you want Server 1 to handle all the Bind operations, this is possible. To do so, set the weight of bind to 1 (or higher) for Server 1, and to 0 for Server 2 and Server 3.

In the example illustrated in Figure 5-4, Server 1 will handle three times as many Add requests as Server 2 and Server 3. However, Server 1 will handle only one half the Search requests handled by Server 2, and Server 3. Server 2 and Server 3 will handle the same amount of Add and Search requests, but will not handle Bind requests.

Figure 5-4 Proportional Load Balancing with Request Specific Management

Proportional load balancing onto three remote LDAP servers, where one server manages all the Bind requests.

If you do not modify the weights of operations other than Bind, Add, and Search, as illustrated in Figure 5-4, the servers will share the same load for all other operations (for example for Delete operations).

For more information on configuring the load balancing weights of routes when using proportional load balancing, see Modifying Load Balancing Properties in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.

Saturation Load Balancing

With the saturation load balancing algorithm, the Oracle Unified Directory proxy sends requests to a chosen priority route. The Oracle Unified Directory proxy continues to send requests to the priority route until the remote LDAP server on that route passes the saturation threshold set. The saturation threshold is represented as a percentage.

For example, if you want a remote LDAP server to manage all incoming requests, set it as priority 1. If you want that same remote LDAP server to stop handling requests when its saturation index reaches 70%, set the saturation threshold to 70%, as illustrated in Figure 5-5. In this way, the server handles all incoming requests until it becomes 70% saturated. The Oracle Unified Directory proxy then sends all new requests to the remote LDAP server to Server 2, since it has the next highest priority. Server 2 will continue to handle requests until it reaches its own saturation threshold, or until Server 1 is no longer saturated.

In other words, if Server 1 reaches 70% saturation, Oracle Unified Directory proxy directs the requests to Server 2. If Server 1 is still at 70%, and Server 2 reaches 60%, then Oracle Unified Directory proxy directs the new requests to Server 3.

However, if while Server 2 is handling requests, the saturation level of Server 1 drops to 55%, thenOracle Unified Directory proxy will direct all new requests to Server 1, even if Server 2 has not reached its saturation threshold.

Figure 5-5 Saturation Load Balancing Example

Saturation load balancing example over three remote LDAP servers, with different saturation limits.

If all routes have reached their saturation threshold, the Oracle Unified Directory proxy chooses the route with the lowest saturation.

With the Oracle Unified Directory proxy, you can set a saturation threshold alert. For example, if you set a saturation threshold alert to 60%, you will get a notification when the server reaches this limit, and thus, you can act before the server becomes too degraded.

Search Filter Load Balancing

With the search filter load balancing algorithm, the Oracle Unified Directory proxy routes search requests to LDAP servers based on the presence of certain attributes defined in the request search filter.

The topology consists of several LDAP servers, which are accessible through the Oracle Unified Directory proxy. All the LDAP servers contain similar data, but each server is optimized based on attributes defined in the search filter to provide better performance. You can configure each route with a list of allowed attributes and a list of prohibited attributes. A search request matches a route when the request search filter contains at least one allowed attribute, and none of the prohibited attributes.

The Figure 5-6 illustrates a search filter load balancing algorithm. In this example, there are three LDAP servers and therefore three distinct routes. LDAP server 1 indexes the uid attribute, LDAP server 2 indexes the cn attribute, and the third LDAP server is a pass-through route.

Figure 5-6 Search Filter Load Balancing

Search Filter Load Balancing

So, when the Oracle Unified Directory proxy receives a search request that contains the uid attribute in its search filter, the search request is routed to LDAP server 1 for better performance. Similarly, if the search filter contains a cn attribute, then the search request is routed to LDAP server 2. All other search requests are routed to the pass-through LDAP server 3.

All other requests, such as ADD, DELETE, MODIFY, and so on can be routed to any LDAP server based on the highest priority. Each search filter route is given a priority. This priority determines the order in which the route are evaluated. The highest priority route filter that matches the search filter is selected to process the request. If all the search filter routes have the same priority, then any route can process the request.