Oracle Fusion Middleware Deployment Planning Guide for Oracle Directory Server Enterprise Edition

Using Load Balancing for Read Scalability

Load balancing increases performance by spreading the read load across multiple servers. Load balancing can be achieved using replication, Directory Proxy Server, or a combination of the two.

Using Replication for Load Balancing

Replication is the mechanism that automatically copies directory data and changes from one directory server to another directory server. With replication, you can copy a directory tree or subtree that is stored in its own suffix between servers.

Note –

You cannot copy the configuration or monitoring information subtrees.

By replicating directory data across servers, you can reduce the access load on a single machine, improving server response time and providing read scalability. Replicating directory entries to a location close to your users also improves directory response time. Replication is generally not a solution for write scalability.

Basic Replication Concepts

The replication mechanism is described in detail in Chapter 7, Directory Server Replication, in Oracle Fusion Middleware Reference for Oracle Directory Server Enterprise Edition. The following section provides basic information that you need to understand before reviewing the sample topologies described later in this chapter.

Master, Consumer, and Hub Replicas

A database that participates in replication is defined as a replica.

Directory Server distinguishes between three kinds of replicas:

The following figure illustrates the role of each of these replicas in a replication topology.

Figure 10–1 Role of Replicas in a Replication Topology

Figure shows the flow of replication traffic and LDAP

Note –

The previous figure is for illustration purposes only and is not necessarily a recommended topology. Directory Server supports an unlimited number of masters in a multi-master topology. A master-only topology is recommended in most cases.

Assessing Initial Replication Requirements

A successful replicated directory service requires comprehensive testing and analysis in a production environment. However, the following basic calculation enables you to start designing a replicated topology. The sections that follow use the result of this calculation as the basis of the replicated topology design.

ProcedureTo Determine Initial Replication Requirements

  1. Estimate the maximum number of searches per second that are required at peak usage time.

    This estimate can be called Total searches.

  2. Test the number of searches per second that a single host can achieve.

    This estimate can be called Searches per host. Note that this should be evaluated with replication enabled.

    The number of searches that a host can achieve is affected by several variables. Among these are the size of the entries, the capacity of the host, and the speed of the network. A number of third party performance testing tools are available to assist you in conducting these tests. The SLAMD Distributed Load Generation Engine (SLAMD) is an open source Java application designed for stress testing and performance analysis of network-based applications. SLAMD can be used effectively to perform this part of the replication assessment. For information about SLAMD, and to download the SLAMD software, see

  3. Calculate the number of hosts that are required.

    Number of hosts = Total searches / Searches per host

Load Balancing With Multi-Master Replication in a Single Data Center

Replication can balance the load on Directory Server in the following ways:

Generally, if the Number of hosts calculated in Assessing Initial Replication Requirements is about 16, or not significantly larger, your topology should include only master servers in a fully connected topology. Fully connected means that every master replicates to every other master in the topology.

Note –

The Number of hosts is approximate and depends on the hardware and other details of the deployment.

The following figure assumes that the Number of hosts is two. LDAP operations are divided between two master servers, based on the type of client application. This strategy reduces the load that is placed on each server and increases the total number of operations that can be served by the deployment.

Figure 10–2 Using Multi-Master Replication for Load Balancing

Figure shows two different kinds of client applications,
whose requests are sent to two separate masters.

For a similar scenario in a global deployment, see Multi-Master Replication Over WAN.

Load Balancing With Replication in Large Deployments

If your deployment requires a Number of hosts significantly larger than 16, you might need to add dedicated consumers to the topology.

The following figure assumes that the Number of hosts is 24 and, for simplicity, shows only a portion of the topology. (The remaining 10 servers would have an identical configuration, with a total of 8 masters and 16 consumers.

Figure 10–3 Using Multi-Master Replication for Load Balancing in a Large Deployment

Figure shows multi-master replication with four masters
and eight consumers.

A change log can be enabled on any of these consumers if you need to do the following:

If the Number of hosts is several hundred, you might want to add hubs to the topology. In such a case, there should be more hubs than masters, with up to 10 hubs for each master. Each hub should handle replication to only 20 consumers at most.

No topology should have the same number of hubs as masters, or the same number of hubs as consumers.

Note –

Configuring a “one-way” master (a master that receives replication changes but does not send them) in a multi-master topology is not recommended and can break replication to that master.

Using Server Groups to Simplify Multi-Master Topologies

When the Number of hosts is large, the use of server groups can simplify the topology and improve resource usage. In a topology with 16 masters, the use of four server groups, each containing four masters, is easier to manage than 16 fully meshed masters.

Setting up a such a topology involves the following steps:

The following figure shows the resulting topology.

Figure 10–4 Server Groups in Multi-Master Topologies

Figure shows four server groups, each containing four

Using Directory Proxy Server for Load Balancing

Directory Proxy Server can use multiple servers to distribute the load of a single source of data. Directory Proxy Server can also ensure that if one of the servers is unavailable, the data remains available. Apart from distributing data, Directory Proxy Server provides operation-based load balancing. That is, the server is able to route client operations to a specific Directory Server, based on the type of operation.

Directory Proxy Server supports operation-based load balancing, and a variety of load balancing algorithms that determine how the workload is shared between Directory Servers. For a detailed description of each of these algorithms, see Chapter 16, Directory Proxy Server Load Balancing and Client Affinity, in Oracle Fusion Middleware Reference for Oracle Directory Server Enterprise Edition.

The following figure illustrates how the proportional algorithm is used to balance read load across two servers. Operation-based load balancing routes all writes to Master 1, unless that server fails. On failure all reads and writes are routed to Master 2.

Figure 10–5 Using Proportional and Operation-Based Load Balancing in a Scaled Deployment

Figure shows proportional and operation-based load balancing
with Directory Proxy Server.

Note that the configuration for load balancing is not recalculated when one server instance fails. You cannot use proportional load balancing to create a “hot standby” server by setting a server's load balancing weight to 0.

Imagine, for example, you have three servers A, B, and C. Proportional load balancing has been configured such that servers A and B each receive 50% of the load. Server C is configured to have 0% of the load as it is designed to be a standby server only. If server A fails, 100% of the load will go to server B automatically. Only if server B also fails, will the load be distributed to server C. So, either the instance participates in load balancing all the time, always ready to take part of the load, or all primary instances have to fail before that server will take any load.

You can achieve something like a hot standby by using the saturation load balancing algorithm and applying a low weight to the standby server. Although the server is not a true standby server, you can configure the algorithm such that requests are distributed to this server only if the primary servers are under heavy load. Effectively if one primary server is disabled, the load on the other primary servers increases to the extent that requests must be distributed to the standby server.