Chapter 17 Directory Proxy Server Distribution

Directory Proxy Server enables distribution through the definition of data
views. Data views are defined with a view base, which determines the base
DN of the entries in that data view. Based on the distribution algorithms
provided in Directory Proxy Server, you can specify how entries are divided among
the different data views.

LDAP Data View Features

A simple LDAP data view is defined primarily by the base DN of the data
view. In a simple data view all of the entries in the subtree are encompassed
by the data view. Data views can exist in hierarchy, with a superior
data view and a subordinate data view.
A subordinate data view is a data view whose base DN is inferior to the base
DN of a superior data view. The entries in a subordinate data view are excluded
from the superior data view.

For information about the features of a data view, see the following
sections.

Excluding a Subtree From a Data View

When a subordinate
data view is created, Directory Proxy Server automatically excludes the subordinate
data view from the superior data view. When a request targets the subordinate
data view, the request is sent to the subordinate data view instead of the
superior data view.

Attribute Renaming and DN Renaming

Each entry in a directory is identified by a DN and a set of attributes and their values. Often,
the DN and the attributes defined on the client side do not map to the DN
and the attributes defined on the server side.

Data views can be defined to rename DNs and attributes to values that
match the server side. When a client makes a request, the DNs and attributes
are renamed to match the server side. When the result is returned to a client,
the DN and attributes are changed back to match the client side.

Attribute Renaming

The following figure illustrates how attribute renaming is performed
by Directory Proxy Server.

Figure 17–1 Attribute Renaming

In Figure 17–1, the email
client expects the last names to be specified by the attribute surname However,
in the LDAP server, last names are specified by the attribute sn.
When attributes are renamed, only the name of the attribute is affected —
the value of the attribute is not changed. However, when attributes are renamed
all entries with that name are renamed.

Figure 17–2 DN Renaming

Attributes that contain DNs must also be renamed if those DNs are in
the portion of the DIT that is affected by the original DN renaming. In Figure 17–2, the group attribute
contains a list of the DNs of group members. When dc=example, dc=com is
renamed to dc=example, dc=org, the DNs in the group attribute
must also be renamed.

Distributing Entries In a Subtree to Different Data
Views

A distribution
algorithm distributes operations across data views that have the same base
DN. The type of distribution algorithm is defined by the distribution-algorithm parameter.

To determine how to distribute operations, the distribution algorithm
considers the value of the attribute directly below the
base DN of the data view. For example, consider a data view with a base DN
of ou=people,dc=example,dc=com. If a search operation contains
the base DN uid=23,ou=people,dc=example,dc=com, the distribution
algorithm considers uid to be the routing attribute, because uid is directly below the base DN of the data view. The algorithm
then attempts to match the value 23 to determine how to
route the operation.

However, if the search operation contains the base DN uid=23,ou=managers,ou=people,dc=example,dc=com, the distribution algorithm considers ou to
be the routing attribute, because ou is directly below
the base DN of the data view. Because ou does not match
the uid specified in the search query, the distribution
algorithm cannot distribute the search correctly. For distribution to work
in this case, the base DN of the data view should be ou=managers,ou=people,dc=example,dc=com.

You must therefore ensure that the base DN of the data view is appropriate
to the distribution algorithm.

The following distribution algorithms are provided with Directory Proxy Server:

Pattern matching

Requests are distributed to data views based on the match between the
parameters of the requests and one or more patterns. Patterns are defined
by the following parameters:

Requests are distributed to data views according to the numeric value
of the RDN in the request. The numeric value is taken from the value of the
first RDN beneath the base DN of the data view. Numeric bounds are defined
by these parameters:

numeric-attrs

numeric-default-data-view

numeric-lower-bound

numeric-upper-bound

Lexicographic

Requests are distributed to data views according to the lexicographic
value of the RDN in the request. Lexico bounds are taken from the value of
the first RDN beneath the base DN of the data view. Lexico bounds are defined
by these parameters:

lexicographic-attrs

lexicographic-lower-bound

lexicographic-upper-bound

Replication

Requests are distributed to data views according to the role
of the data view in replication. The algorithm distributes write operations
to all data sources in the data source pool and read operations to a single
data source. The replication role is defined by the replication-role parameter.
A data view can have a master role or a consumer role.

Limitations of Distribution Algorithms

The following list outlines the situations in which requests do not
respect the distribution algorithm. The examples in this list assume that
the routing attribute is uid and the view base of the data
view is dc=example,dc=com.

When the search base ends with the view base and the scope
is base, requests are always distributed to the first data
view. For example:

$ ldapsearch -b "ou=people,dc=example,dc=com" -s base "uid=116352"

When the search base ends with the view base and the scope
is one level or subtree, requests are always distributed to the first data
view. For example:

$ ldapsearch -b "ou=people,dc=example,dc=com" -s sub "uid=116352"

When the search base ends with the view base and starts with
the routing attribute, but the search filter does not contain the routing
attribute, requests are distributed to all data views. For example:

Data Views to Route All Requests, Irrespective of
the Target DN of the Request

This section describes a data view that routes all requests to a data
source pool, irrespective of the target DN of the request. This data view
is called the root data view. The root data view is
created by default when an instance of Directory Proxy Server is created.

The example in this section has multiple data sources that contain the
same set of subtrees. The data sources are data-equivalent and pooled into
one data source pool for load balancing. A data view is configured with a
base DN at the rootDSE, represented as “ ”. Figure 17–3 shows an example deployment.

Figure 17–3 Example Deployment That Routes All Requests to a
Data Source Pool, Irrespective of the Target DN

Because the base DN of the data view is the rootDSE, the data view encompasses
the base DN of all possible requests. All requests are
forwarded to the data source pool, irrespective of the target DN or whether
the data source contains an entry for the request.

If Directory Proxy Server receives a request with a target DN that does
not exist in the data source, the request is forwarded to the data source
pool. The data source that responds to the request returns an error.

Data Views to Route Requests When a List of Subtrees
Are Stored on Multiple, Data-Equivalent Data Sources

This section describes data views that route requests targeted at a
list of subtrees to a set of data-equivalent data sources.

The example in this section has multiple data sources that each contain
the same set of subtrees. The data sources are data-equivalent and pooled
into one data source pool for load balancing. A data view is configured for
each subtree to expose that subtree to client requests. Figure 17–3 shows the example deployment.

Figure 17–4 Example Deployment That Routes Requests When a List
of Subtrees Is Stored on Multiple, Data-Equivalent Data Sources

A request is exposed to a data view only if the target DN is subordinate
to the base DN of the data view. When a request is exposed to a data view,
the request is forwarded to the data source pool specified by the data view.

If the target DN of a request is not subordinate to the base DN of any
data view, Directory Proxy Server returns an error.

In Figure 17–4, requests
that target dc=example1,dc=com or dc=example2,dc=com are
forwarded to the data source pool. Directory Proxy Server returns an error for
requests that target neither dc=example1,dc=com nor dc=example2,dc=com.

Data Views to Provide a Single Point of Access When
Different Subtrees Are Stored on Different Data Sources

This section describes how Directory Proxy Server provides a single point
of access to different subtrees of data on multiple data sources. The example
in this section contains a data view is for each subtree, to expose that subtree
to client requests. A data source pool is configured for each set of data-equivalent
data sources. Figure 17–5 shows
the example deployment.

Figure 17–5 Example Deployment That Provides a Single Point
of Access When Different Subtrees Are Stored on Different Data Sources

The Directory Proxy Server exposes a request to a data view if the DN targeted
by the request is subordinate to the base DN of the data view. When a request
is exposed to a data view, the request is forwarded to the data source pool
specified by the data view.

If a request has a target DN that is not subordinate to the base DN
of a data view, Directory Proxy Server returns an error.

In Figure 17–5, client requests
that target dc=example1,dc=com are forwarded to the data
source pool 1 and are treated by data source 1 or data source 1'. Client requests
that target dc=example2,dc=com are forwarded to the data
source pool 2 and are treated by data source 2 or data source 2'. The Directory Proxy Server returns
an error for client requests that target neither dc=example1,dc=com nor dc=example2,dc=com.

Data Views to Route Requests When Different Parts
of a Subtree Are Stored in Different Data Sources

This section describes how Directory Proxy Server provides a single point
of access to different parts of a subtree stored in multiple data sources.
To route requests for different parts of a subtree, Directory Proxy Server uses
a distribution algorithm. In the example in this section, Directory Proxy Server uses
the numeric distribution algorithm. For more information about distribution
algorithms, see Distributing Entries In a Subtree to Different Data Views.

The example in this section contains two data views with the same base
DN. A numeric distribution algorithm is used to separate entries into different
data views. A data source pool is configured for each set of data-equivalent
data sources. Figure 17–6 shows
the example deployment.

Figure 17–6 Example Deployment That Routes Requests When Different
Parts of a Subtree Are Stored in Different Data Sources

Directory Proxy Server exposes a request to the data view which satisfies
the following conditions:

The DN targeted by the request is subordinate to the base
DN of the data view

The parameters of the requests match the pattern specified
by the distribution algorithm in the data view

When a request is exposed to a data view, the request is forwarded to
the data source pool specified by the data view.

If a request that does not match the conditions of any data view, Directory Proxy Server returns
an error.

The example in Figure 17–7 contains
three data views. The base DN of dataview–1 is superior
to the base DNs of dataview-2 and dataview-3.

The excluded-subtrees property on dataview-1 excludes dataview-2 and dataview-3 from dataview-1.
The alternate-search-base-dn properties on dataview-2 and dataview-3 include dataview-2 and dataview-3 in search operations targeted at dataview-1. Figure 17–7 shows the example deployment.

Figure 17–7 Example Deployment to Route Requests When Superior
and Subordinate Subtrees Are Stored in Different Data Sources

Directory Proxy Server exposes a request to the data view which satisfies
the following conditions:

The DN targeted by the request is subordinate to the base
DN of the data view

The DN targeted by the request is not excluded from the data
view by the excluded-subtrees parameter

When a request is exposed to a data view, the request is forwarded to
the data source pool specified by the data view.

If a request does not match the conditions of any data view, the request
cannot be exposed to a data view and Directory Proxy Server returns an error.

In Figure 17–7, client requests
that target dc=example,dc=com but do not target ou=computer,
dc=example, dc=com or ou=people, dc=example, dc=com are
forwarded to the data source pool 1. Such requests are treated by data source
1 or data source 1'. Client requests that target ou=computer, dc=example,
dc=com or ou=people, dc=example, dc=com are forwarded
to data source pool 2 and data source 3, respectively. Directory Proxy Server returns
an error for client requests that do not target dc=example,dc=com.

All three data views are candidates for search operations that are targeted
at dc=example,dc=com.

Data Views With Hierarchy and a Distribution Algorithm

Different data views can be used in the same topology to expose or hide
parts of a subtree. Figure 17–8 shows
are an example with data views that combine the hierarchy shown in Figure 17–7 with the distribution algorithms
shown in Figure 17–6.

The example in Figure 17–8 contains
four data views. The base DN of data view 1 is superior to the base DNs of
the other data views. Data view 3 and data view 4 have the same base DN, but
a numeric distribution algorithm separates entries into the different data
views. Figure 17–8 shows the example
deployment.

Figure 17–8 Data View With Hierarchy and a Distribution Algorithm

The excluded-subtrees property on dataview-1 excludes
the other data views from dataview-1. The alternate-search-base-dn property on dataview-2, dataview-3,
and dataview-4 includes these data views in search operations
targeted at dataview-1.

Directory Proxy Server exposes a request to the data view which satisfies
the following conditions:

The DN targeted by the request is subordinate to the base
DN of the data view

The DN targeted by the request is not excluded from the data
view by the excluded-subtrees parameter

The parameters of the requests match the pattern specified
by the distribution algorithm

When a request is exposed to a data view, the request is forwarded to
the data source pool specified by the data view.

If a request does not match the conditions of any data view, Directory Proxy Server returns
an error.