LDAP Specific Routing
ChallengeIn a large enterprise environment, whether purposefully (for performance and cost reasons) or not, it is not unfeasible that identity data becomes scattered or fragmented across a variety of backend LDAP systems. As a result, routing requests to the appropriate server for processing can quickly raise a number of challenges.
Consider the problem of BIND requests. Your users may be distributed across different servers and depending on the DN that they BIND with, you may want to route the request to a particular server. Alternatively, for Active Directory administrators, there is the possibility that BIND requests belonging to different domains should be routed to different Active Directory instances for authentication.
For any request to a particular suffix or branch within your directory, you may wish to route the request to an alternate server dedicated to hosting the entries for that suffix. This would allow you to fragment a very large directory and store data on a variety of cheaper servers that can be dedicated to handling particular queries.
Consider an environment where separate servers are dedicated to write operations and read operations. It is fairly common in enterprise environments to make use of a set of 'master' servers to deal with data modifications (write operations), while using a set of 'replica' servers to handle search, bind and compare requests (read operations). This approach helps to distribute operational load and improves the efficiency with which particular operations can be handled. The main problem with this sort of configuration is that many applications are simply unable to work with more than one backend at a time, and even if an application is capable of this, it is even more rare for an application to be able to distinguish which server should be used for which operation. A traditional approach to handling this problem has been to make use of referrals. However, it is inefficient to use referrals for every possible operation and it also requires that your client application understands how to deal with referral responses.
Solution
For each of these scenarios, and a few more, Symlabs has provided a variety of LDAP routing plugins that can be used within LDAP Proxy and Virtual Directory Server to control how traffic is routed depending on various LDAP specific information within the request sent by a client application.
The Route on Bind plugin allows you to route LDAP Bind Requests to different Server Groups depending on the source IP of the client application performing the operation, the suffix of the user DN or the Active Directory Domain Name.
The Route on Suffix plugin can be used to route requests that belong to a particular DN, or suffix, to a specified ServerGroup. much of this functionality can be found using more complex plugins such as the Attach Tree plugin, or the Virtual Tree functionality, this plugin provides a quick and simple solution to a common problem.
The Route On Operation plugin offers an automatic way of routing the requests based on operation type to different servergroups. With this plugin, all replica servers can be added to a common 'read-only' servergroup, while all master servers can be added to a second 'write-only' servergroup, allowing you to build a more responsive environment using a master-replica architecture.
The Route On Operation plugin also includes a configuration parameter that controls rerouting of operations after a write operation. This means
that if a client performs a write operation, it will not be rerouted to the 'read-only' servergroup for a period after the
write operation has taken place. This ensures that if the client needs to check that a write request was successful, it will
not be immediately routed to a replica server which may still be waiting to be synchronized. This facility can be applied
per-session or globally, so that you can either ensure that all clients are recieving the most up-to-date information, or
you can ensure that load is reduced to only the clients that are performing write operations.
The Route on Filter plugin allows you to route LDAP Search
Requests to different Server Groups depending on the attributes of the
search request filter. This is convenient when a large set of data entries is distributed
across several directory instances which have different attributes
indexed. With this functionality it is possible to route search requests
to the appropriate directory instance by taking into account the
attributes that are indexed in each directory instance. Alternatively,
if the same data is being stored across multiple servers, with different
indexes, a request can be routed to the server that has an index for
the filter that is used in the search request.