Splitting data within a subtree

You can split data within a subtree that is based on a hash of the RDN® by using a proxy server.

In this setup, three servers have their data that is split within a "container" (under some entry in the directory tree). Because the proxy server handles the routing of requests to the appropriate servers, no referrals are used. Client applications need to be aware of proxy server only. The client applications never must authenticate with servers A, B, or C.

The illustration shows a single proxy server that is distributing the data for the subtree o=sample across three servers. ServerA has a partition value or hash value of 1, ServerB has a hash value of 2 and ServerC has a hash value of 3.

Data is split evenly across the directories by hashing on the RDN just below the base of the split. In this example, the data within the subtree is split based on the hash value of the RDN. Hashing is only supported on the RDN at one level in the tree under a container. Nested partitions are allowed. For a compound RDN, the entire normalized compound RDN is hashed. The hash algorithm assigns an index value to the DN of each entry. This value is then used to distribute the entries across the available servers evenly.

Note:

The parent entries across multiple servers must remain synchronized. It is the administrator's responsibility to maintain the parent entries.
ACLs must be defined at the partition base level on each server.

Note: The number of partitions and the partition level are determined when the proxy server is configured, and when the data is split. There is no way to expand or reduce the topology without repartitioning.

The hash value enables the proxy server to locate and retrieve entries

For example: Data under o=sample is split across three servers. This means that the proxy server is configured to hash RDN values immediately after o=sample among three servers, or "buckets". This also means that RDN values more than 1 away from o=sample will map to the same server as values immediately after o=sample. For example, cn=test,o=sample and cn=user1,cn=test,o=sample will always map to the same server. ServerA holds all the entries with a hash value of 1, server B holds all the entries with a hash value of 2, and ServerC holds all the entries with a hash value of three. The proxy server receives an add request for an entry with DN cn=Test,o=sample. The proxy server then uses the configuration information (specifically that there are three partitions with a base at o=sample) and the cn=Test RDN as inputs to the internal hashing function. If the function returns 1, the entry resides on ServerA and the add request is forwarded there.

Entry hashing is based on the RDN of the entry. Only the portion of the DN immediately to the left of the split point is used by the hash algorithm. Also, the whole normalized string is used for the hash, not just the value. For example, if our split point is o=sample and this is split into three partitions, then the following results occur:

cn=example,o=sample hashes to a single server, for example ServerA. This is determined by hashing cn=example into one of three partitions.
dc=example, o=sample hashes to a different server, for example ServerB. This is determined by hashing dc=example.
cn=foo,cn=example,o=sample hashes to ServerA. This is because only cn=example is used for the hash algorithm. All entries beneath cn=example,o=sample resolve to the same server as cn=example,o=sample.

Note: When you use 6.1 or above version of the proxy server with 6.0 backend servers, the cn=pwdpolicy subtree must be configured as a split point. However, a 6.1 and above version of proxy server using 6.1 and above backend servers should not have the cn=pwdpolicy subtree.