Directory Distribution and Routing
This section includes the following topics:
This section includes the following topics:
In a distributed directory, the DSAs use the X.500 Directory Systems Protocol (DSP) to cooperate to resolve queries on any area of the namespace.
CA Directory fully supports the X.500 directory systems protocol, including the following distribution features:
- Routing or ChainingRequests sent to a DSA are performed by another DSA. The routing decision is based on the base DN of the request and the prefixes of DSAs in the backbone. A routed request is handled by a single DSA, if the target DSA cannot be contacted then the request is refused with a referral error.
- Multi-Chaining SearchA search that involves an entire subtree may be spread across multiple DSAs. If multi-chaining is enabled, a multi-chained search follows a process across an entire subtree.
- Continuation Reference or ReferralsIf one or more DSAs in the backbone servicing a distributed request cannot be contacted, then a referral or continuation reference is returned to the client, indicating the unexplored area od the search.
How Distribution Works
distributeddirectory, many DSAs cooperate to form a single namespace. Parts of the namespace are served by different DSAs. An application connected to any DSA can search the entire namespace.
From the client's point of view, the directory backbone is a single entity, because every request is routed to the appropriate DSAs within the namespace.
The DSAs may be all on the same computer, or they may be on different computers.
A distributed directory is useful to organizations with offices in several locations, because each office can maintain its own directory, and yet to a client it appears as just one directory. It is also useful for large directories because you improve scalability and performance when you share the data across different servers.
A distributed directory can incorporate LDAP servers. CA Directory fully complies with the LDAP standards, which means that it can be used as a backbone, to unify directories that support LDAP.
Example A Distributed Directory
The following diagram shows a single namespace that is served by five DSAs. The CA Directory DSAs communicate with each other using DSP, and they communicate with LDAP-only directory servers using LDAP.
When the client sends a query to the directory, the query is routed to the DSA that serves the relevant part of the namespace. The client does not need to know that the directory is distributed.
How Multi-Chaining Searches Work
The multi-chained search functions in the following way:
- DSA receives search request and searches itself
- The search is then multi-cast to immediate subordinate DSAs if any exist
- The subordinate DSAs then continue processing at 1
- When all the searches are complete, the results are collated and returned to the client
If any DSAs in the scope of the search cannot be contacted, a partial outcome is included with the search result indicating the unexplored area of the directory information tree.
Referring to multi-chaining as multi-casting is not appropriate. Multi-casting is a component that contains many multi-chained searches.
How Routing or Chaining Works
When a DSA in a backbone receives a request, it may need to forward (or
chain) the request to another DSA to deal with the request.
A DSA receiving a request is able to forward that request directly to any other DSA within the domain using the shortest path routing, as the entire directory backbone shares the same configuration knowledge.
Example Routing an Update Request
The following diagram shows five DSAs that control a single namespace. Each DSA controls a portion of the namespace, represented by its prefix, and a relationship with the other DSAs in the domain.
In the following diagram, DSA 1 is the superior of DSA 2 and DSA 3. DSA 4 and DSA 5 are subordinates of DSA 3:
- A client sends a request to DSA 2, to modify the phone number of the entry cn=Milio GILMORE,ou=Legal,ou=Corporate,o=DEMOCORP,c=AU.
- When DSA 2 cannot handle the request, it routes (forwards) the request to DSA 5 using the shortest path routing.
- DSA 5 modifies the phone number, and sends a confirmation response back to DSA 2.
- DSA 2 sends the response to the client.
Impact of Operational Limits on Distribution
There are two operational limits that can be imposed while a DSA is servicing a distributed request, either the time limit or the size limit.
- Time LimitWhen a request is received by a local DSA, a time limit can be applied (for example, max-op-time, or service time limit). If the request is either chained or multi-chained to a remote DSA, the local DSA still retains a reference to the request. This reference is impacted by the time limit even though the request is now being serviced by one or more remote DSAs.Example:If max-op-time is set to 30 seconds and Democorp: <c AU><o Democorp> receives a request in the scope of UNSPSC: <c AU><o UNSPSC> the request is chained. If Democorp does not receive a response from UNSPSC for 30 seconds, a request refusal (adminLimitExceeded) is sent to the client. Democorp also sends an abandon request to UNSPSC in an attempt to stop the request from continuing.
- Size LimitWhen a search request is received by a local DSA, a size limit is imposed on the result (for example, max-op-size, or service size limit). If the request is chained or multi-chained to another DSA then the local DSA limit is not enforced. The size limit is only enforced by the data DSA performing the search locally.Example:If max-op-size is set to 100 for all DSAs and Router: <c AU> receives a whole subtree search with scope <c AU>, the search is multi-chained to both Democorp: <c AU><o Democorp> and UNSPSC: <c AU><o UNSPSC>. Democorp and UNSPSCS both have the size limit applied and return 100 entries each with a partial outcome (adminLimitExceeded). The router collates the results (200 entries) and sends the result (including partial outcome) to the client. The router does not trim the result set, as the size limit is unenforced by the router, but the DSA handles the chained request.
Each DSA has a context prefix that defines the base of the DIT controlled by that DSA.
When the DSA receives an incoming operation, it services the request locally when the request occurs in its own section of the namespace. When the operation is not local, it chains the operation to a remote DSA except in the following circumstances:
- One (user) service control (eitherchainingProhibitedorlocalScope) is set.
- The remote DSA is unavailable.
- A link of the appropriate authentication level to the remote DSA cannot be established.
- There is no DSA knowledge for the area of the operation.
Depending on the circumstance, the remote operation returns one of the following options:
- Service error
- Security error
See the X.500 standards for a complete specification of how distributed DSAs cooperate to resolve a query.
Caching Entries from Subordinate DSAs
Unlike DAP, LDAP does not have a LIST operation. So, when LDAP clients want to browse a directory, they invoke one-level searches that return object class only.
These one-level searches become a problem when there are many subordinate DSAs because a one-level search must be broadcast to each of the DSAs (whereas a LIST returns the names of the DSAs).
To stop the flooding effect that this creates, especially at first-level DSAs, the DSA caches the replies to one-level-search queries and makes them available to subsequent similar requests.
Only one-level searches returning object class are cached. These are the searches commonly used to browse the directory.
Transparent routingallows a router DSA to process LDAP requests and responses without requiring the controlling schema. This is useful if the router DSA is being used to link LDAP clients to an LDAP server, or the clients and server have schema that are not known by the router DSA. Transparent routing works with LDAP clients only.
By default, transparent routing is set to
false. Transparent routing can be set on a router, as shown in the following diagram