|
| Sun ONE Directory Server 5.2 Deployment Guide |
Chapter 5 Designing the Directory Topology
In Chapter 4 "Designing the Directory Tree," you designed how your directory stores entries. Because Directory Server can store a large quantity of entries, you may need to distribute your entries across more than one server. Your directory's topology describes how you divide your directory tree among multiple physical Directory Servers and how these servers link with one another.
This chapter describes planning the topology of your directory. It contains the following sections:
Topology Overview
You can design your deployment of Sun ONE Directory Server to support a distributed directory where the directory tree you designed in Chapter 4 "Designing the Directory Tree," is spread across multiple physical Directory Servers. The way you choose to divide your directory across servers helps you accomplish the following:
- Achieve the best possible performance for your directory-enabled applications
- Increase the availability of your directory
- Improve the management of your directory
The database is the basic unit you use for jobs such as replication, performing backups, and restoring data.
When you divide your directory among several servers, each server is responsible for only a part of the directory tree. The distributed directory works similarly to the Domain Name Service (DNS), which assigns each portion of the DNS namespace to a particular DNS server. Likewise, you can distribute your directory namespace across servers while maintaining a directory that, from a client's point of view, appears to be a single directory tree.
Sun ONE Directory Server also provides the referral and chaining mechanisms for linking directory data stored in different databases.
The remainder of this chapter describes databases, referrals, and chaining, and describes how you can design indexes to improve the performance of your databases.
Distributing Your Data
Distributing your data allows you to scale your directory across multiple server instances which, may or may not, depending on your performance requirements, be stored on several machines, without physically containing those directory entries on each server in your enterprise. A distributed directory can thus hold a much larger number of entries than would be possible with a single server.
In addition, you can configure your directory to hide the distributing details from the user. As far as users and applications are concerned, there is simply a single directory that answers their directory queries.
The following sections describe the mechanics of data distribution in more detail:
Using Multiple Databases
Sun ONE Directory Server stores data in LDBM databases. he LDBM database is a high-performance disk-based database. Each database consists of a set of large files that contains all of the data assigned to it.
You can store different portions of your directory tree in different databases. For example, your directory tree appears as shown in Figure 5-1:
Figure 5-1 Directory Tree With Three Subsuffixes
You can store the data of the three subsuffixes in three separate databases as shown in Figure 5-2:
Figure 5-2 Three subsuffixes Stored in Three Separate Databases
When you divide your directory tree among a number of databases, these databases can then be distributed across multiple servers, which generally equates to several physical machines to improve performance. For example, the three databases you created to contain the three subsuffixes of your directory tree can be stored on two servers as shown in Figure 5-1:
Figure 5-3 Example.com's Three Databases Stored on Two Servers A and B
Server A contains databases DB1 and DB2 and server B contains database DB3. Distributing databases across multiple servers reduces the amount of work each server needs to do. Thus, the directory can be made to scale to a much larger number of entries than would be possible with a single server.
In addition, Sun ONE Directory Server supports adding databases dynamically, meaning you can add new databases when your directory needs them without taking your entire directory off-line.
About Suffixes
Each database contains the data within a suffix of your directory server. You can create both suffixes and subsuffixes to organize the contents of your directory tree. A suffix is the entry at the root of a tree. It can be the root of your directory tree or part of a larger tree you have designed for your directory server.
A sub suffix is a branch underneath a suffix. The data for suffixes and subsuffixes are contained by databases.
For example, you want to create subsuffixes to represent the distribution of your directory data. The directory tree for Example.com Corporation appears as shown in Figure 5-4:
Figure 5-4 Example.com Corporation's Directory Tree
Example.com Corporation decides to split their directory tree across five different databases as illustrated in Figure 5-5:
Figure 5-5 Example.com Corporation's Directory Tree Split Across Five Databases
o=NetscapeRoot and dc=Example,dc=com are both suffixes. The other ou=testing,dc=Example,dc=com, ou=development,dc=Example,dc=com, and ou=partners,ou=development,dc=Example,dc=com suffixes are all subsuffixes of the dc=Example,dc=com suffix. The suffix dc=Example,dc=com contains the data in the ou=marketing, branch of the original directory tree.
The suffixes and subsuffixes that result from this division contain entries as shown in Figure 5-6:
Figure 5-6 Example.com Corporation Suffixes and Associated Entries
Your directory might contain more than one suffix. For example, an ISP called Example.com might host several websites, one for its own website Example.com and one for another website called HostedExample2.com. The ISP can choose between creating one suffix, which houses everything, or two suffixes to separate the hosted ISP part of the organization from internal Example.com data.
The first solution with just one suffix for all data, would have the directory information tree as shown in Figure 5-7:
Figure 5-7 ISP Example.com Directory Tree with One Suffix
Whereas the second solution where the ISP creates two suffixes, one corresponding to the dc=Example,dc=com naming context and one corresponding to the o=ISP part of the organization would have the directory information tree as shown in Figure 5-8:
Figure 5-8 ISP Example.com's Directory Tree
The dc=Example,dc=com entry represents a suffix as does the o=ISP entry. The entries for each hosted ISP, that is, o=Example and o=HostedExample, are subsuffixes of the o=ISP suffix, with the ou=people and the ou=groups branches as subsuffixes of each hosted ISP.
About Referrals and Chaining
Once your data is distributed over several databases, you need to define the relationships between the distributed data. You do this using pointers to directory information held in different databases. The Sun ONE Directory Server provides the referral and chaining mechansims to help you link your distributed data into a single directory tree.
- Referrals
The server returns a piece of information to the client application indicating that the client application needs to contact another server to fulfill the request.
- Chaining
The server contacts other servers on behalf of the client application and returns the combined results to the client application after finishing the operation.
The following sections describe and compare these two mechanisms in more detail.
Using Referrals
A referral is a piece of information returned by a server that tells a client application the server to contact to proceed with an operation request. Directory Server supports three types of referrals:
- Default referral
The directory returns a default referral when a client application presents a DN for which the server does not have a matching suffix. Default referrals are configured at server level using the nsslapd-referral attribute.
- Suffix Referrals
A suffix referral, as opposed to a default referral, is a referral stored at database level. Suffix referrals are configured in the suffix configuration information. You can set a suffix referral for each suffix, which, generally speaking, means setting a suffix per database.
- Smart referrals
Smart referrals are stored on entries within the directory itself. Smart referrals point to Directory Servers that have knowledge of the subtree whose DN matches the DN of the entry containing the smart referral.
All referrals are returned in the format of an LDAP uniform resource locator (URL). The following sections describe the structure of an LDAP referral, and then describe the three referral types supported by Directory Server.
The Structure of an LDAP Referral
An LDAP referral contains information in the format of an LDAP URL. An LDAP URL contains the following information:
- The host name of the server to contact.
- The port number of the server.
- The base DN (for search operations) or target DN (for add, delete, and modify operations).
For example, a client application searches dc=Example,dc=com for entries with a surname Jensen. A referral returns the following LDAP URL to the client application:
ldap://europe.Example.com:389/ou=people,l=europe,dc=Example,dc=com
The referral tells the client application to contact the host europe.Example.com on LDAP port 389 and submit a search rooted at ou=people,l=europe,dc=Example,dc=com.
The LDAP client application you use determines how a referral is handled. Some client applications automatically retry the operation on the server to which they have been referred. Other client applications simply return the referral information to the user. Most LDAP client applications provided by Sun ONE Directory Server (such as the command-line utilities) automatically follow the referral. The same bind credentials you supply on the initial server request are used to access the referred server.
Most client applications follow a limited number of referrals, or hops. The limit on the number of referrals followed reduces the time a client application spends trying to complete a directory lookup request and helps eliminate hung processes caused by circular referral patterns.
Default Referrals
The directory server determines whether a default referral should be returned by comparing the DN of the requested directory object against the directory suffixes supported by the local server. If the DN does not match the supported suffixes, the directory server returns a default referral.
For example, a directory client requests the following directory entry:
uid=bjensen,ou=people,dc=Example,dc=com
However, the server manages only entries stored under the dc=europe,dc=Example,dc=com suffix. The directory returns a referral to the client that indicates which server to contact for entries stored in the dc=Example,dc=com suffix. The client then contacts the appropriate server and resubmits the original request.
You configure the default referral to point to a Directory Server that has more knowledge about the distribution of your directory. Default referrals for the server are set by the nsslapd-referral attribute, stored in the dse.ldif configuration file.
For information on configuring default referrals, see the Setting Default Referrals section in the Sun ONE Directory Server Administration Guide.
Suffix Referrals
Suffix referrals allow you to configure referrals at the suffix level. This functionality offers a more detailed level of referral and, with one of the configuration attributes, allows you to control where updates are actually made. Default referrals for each database in your directory installation are also set by the nsslapd-referral attribute in the mapping tree entry of the dse.ldif configuration file.
Imagine you have two major sites in the US, one based in New York and the other in Los Angeles. A client application sends which concerns the New York site as follows:
uid=bjensen,ou=people,dc=US,dc=Example,dc=com
You can configure a suffix referral to dc=NewYork,dc=US,dc=Example,dc=com so that the request can be processed by the suffix which contains the dc=NewYork subtree.
Suffixes can be configured to operate in four different states, two of which concern suffix referrals. If you do not require suffix referrals you can choose between the
nsslapd-referral: backend state, where the backend (database) processes all operations, and the nsslapd-referral: disabled state, where the database is not available for processing and an error is returned in response to requests made by the client applications.However, if you want to configure suffix referrals, then you can choose to configure two different states. The nsslapd-referral: referral state causes a referral to be returned for all requests made to this suffix, and the nsslapd-referral: referral on update state causes the database to be used for all operations except update requests which will receive a referral. The second referral on update state is used internally by the server when replication is configured to prevent consumers from processing update requests. However, should you need to restrict access to read operations on certain databases for load balancing or performance reasons, this suffix referral configuration possibility would be your solution.
For information on configuring suffix referrals, see the Creating Suffix Referrals section in the Sun ONE Directory Server Administration Guide. For more information concerning the configuration attributes
Smart Referrals
Directory Server also allows you to configure your directory to use smart referrals. Smart referrals allow you to associate a directory entry or directory tree to a specific LDAP URL. Associating directory entries to specific LDAP URLs allows you to refer requests to any of the following:
- Same namespace contained on a different server
- Different namespaces on a local server
- Different namespaces on the same server
Unlike default referrals, the smart referrals are stored within the directory itself. For information on configuring and managing smart referrals, refer to the Creating Smart Referrals section in the Sun ONE Directory Server Administration Guide.
For example, the directory for the American office of Example.com Corporation contains the following directory branch point: ou=people,dc=Example,dc=com.
You redirect all requests on this branch to the ou=people branch of the European office of Example.com Corporation by specifying a smart referral on the ou=people entry itself. This smart referral appears as follows :
ldap://europe.Example.com:389/ou=people,dc=Example,dc=com
Any requests made to the people branch of the American directory are redirected to the European directory. An illustration of this smart referral where requests made to the American directory are redirected to the European directory is shown in Figure 5-9:
Figure 5-9 Smart Referral From American Directory to European Directory
You can use the same mechanism to redirect queries to a different server that uses a different namespace. For example, an employee working in the Italian office of Example.com Corporation makes a request to the European directory for the phone number of a Example.com employee in America. The referral returned by the directory follows:
ldap://europe.Example.com:389/ou=US employees,dc=Example,dc=com
Figure 5-10 illustrates the smart referral for an Italian employee in the European office requesting the phone number of an American employee in the American office.
Figure 5-10 Smart Referral for Phone Number Request
Finally, if you serve multiple suffixes on the same server, you can redirect queries from one namespace to another namespace served on the same machine. If you want to redirect all queries on the local machine for o=Example,c=us to dc=Example,dc=com, then you would put the following smart referral on the o=Example,c=us entry:
ldap:///dc=Example,dc=com
as illustrated in Figure 5-11:
Figure 5-11 Smart Referral Traffic
Since you are redirecting queries from one namespace to another on the same machine, there is no need to provide the host:port information pair which usually appears in the URL after the second slash. As a result, because this pair is empty in the URL, the URL pointing to the same Directory Server contains three slashes.
Note To make best use of referrals, do not make the base of your search below where the referral is configured.
For more information on LDAP URLs see the LDAP URLs appendix in the Sun ONE Directory Server Reference Manual. For more information on how to include smart URLs on Sun ONE Directory Server entries, see the Setting Referrals section in the Sun ONE Directory Server Administration Guide.
Tips for Designing Smart Referrals
Consider the following points before using smart referrals:
- Keep the design simple.
Deploying your directory using a complex web of referrals makes administration difficult. Also, overusing smart referrals can lead to circular referral patterns. For example, a referral points to an LDAP URL, this LDAP URL in turn points to another LDAP URL, and so on until a referral somewhere in the chain points back to the original server. A circular referral pattern is depicted in Figure 5-12:
Figure 5-12 Incorrect Circular Referral Pattern Caused by the Overuse of Smart Referrals
- Redirect at major branch points.
Limit your referral usage to handle redirection at the suffix level of your directory tree. Smart referrals allow you to redirect lookup requests for leaf (non-branch) entries to different servers and DNs. As a result, you may be tempted to use smart referrals as an aliasing mechanism, leading to a complex and difficult to secure directory structure. By limiting referrals to the suffix or major branch points of your directory tree, you can limit the number of referrals that you have to manage, subsequently reducing your directory's administrative overhead.
- Consider the security implications.
Access control does not cross referral boundaries. Even if the server where the request originated allows access to an entry, when a smart referral sends a client request to another server, the client application may not be allowed access.
Also, the client credentials need to be available on the server to which the client is referred for client authentication to take place.
Using Chaining
Chaining is a method for relaying requests to another server. This method is implemented through chained suffixes. A chained suffix, as described in the section titled "Distributing Your Data", contains no data. Instead, it redirects client application requests to remote servers that contain the data.
During chaining, a server receives a request from a client application for data it does not contain. Using the chained suffix, the server then contacts other servers on behalf of the client application and returns the results to the client application. This operation is illustrated in Figure 5-13.
Figure 5-13 Chaining Operation
Each chained suffix is associated to a remote server holding data. You can also configure alternate remote servers containing replicas of the data for the chained suffix to use when there is a failure. For more information on configuring chained suffixes, refer to the Creating Chained Suffixes section in the Sun ONE Directory Server Administration Guide.
Chained suffixes provide the following features:
- Invisible access to remote data.
Because the chained suffix takes care of client requests, data distribution is completely hidden from the client.
- Dynamic management.
You can add or remove a part of the directory from the system while the entire system remains available to client applications. The chained suffix can temporarily return referrals to the application until entries have been redistributed across the directory. You can also implement this functionality through the suffix itself, which can return a referral rather than forwarding a client application on to the database.
- Access control.
The chained suffix impersonates the client application, providing the appropriate authorization identity to the remote server. You can disable user impersonation on the remote servers when access control evaluation is not required. For more information regarding access control and chained suffixes see the Access Control Through Chained Suffixes section in the Sun ONE Directory Server Administration Guide.
Deciding Between Referrals and Chaining
Both methods of linking your directory partitions have advantages and disadvantages. The method, or combination of methods, you choose depends upon the specific needs of your directory.
The main difference between using referrals and using chaining is the location of the intelligence that knows how to locate the distributed information. In a chained system, the intelligence is implemented in the servers. In a system that uses referrals, the intelligence is implemented in the client application.
While chaining reduces client complexity, it does so at the cost of increased server complexity. Chained servers must work with remote servers and send the results to directory clients.
With referrals, the client must handle locating the referral and collating search results. However, referrals offer more flexibility for the writers of client applications and allow developers to provide better feedback to users about the progress of a distributed directory operation.
The following sections describe some of the more specific differences between referrals and chaining in greater detail.
Usage Differences
Some client applications do not support referrals. Chaining allows client applications to communicate with a single server and still access the data stored on many servers. Sometimes referrals do not work when a company's network uses proxies. For example, a client application has permissions to speak to only one server inside a firewall. If they are referred to a different server, they will not be able to contact it successfully.
Also, with referrals a client must authenticate, meaning that the servers to which clients are being referred need to contain the client credentials. With chaining, client authentication takes place only once. Clients do not need to authenticate again on the servers to which their requests are chained.
Evaluating Access Controls
Chaining evaluates access controls differently from referrals. With referrals, a bind DN entry must exist on all of the target servers. With chaining, the client entry does not need to be on all of the target servers.
For example, a client sends a search request to server A. Figure 5-14 shows how the operation would work using referrals:
Figure 5-14 Client Application Search Request to Server A Being Redirected to Server B Through a Referral
In the illustration above, the client application performs the following steps:
- The client application first binds with Server A.
- Server A contains an entry for the client that provides a user name and password, so returns a bind acceptance message. In order for the referral to work, the client entry must be present on Server A.
- The client application sends the operation request to Server A.
- However, Server A does not contain the information requested. Instead, Server A returns a referral to the client application telling them to contact Server B.
- The client application then sends a bind request to Server B. To bind successfully, Server B must also contain an entry for the client application.
- The bind is successful, and the client application can now resubmit its search operation to Server B.
This approach requires Server B to have a replicated copy of the client's entry from Server A.
Chaining solves this problem. A search request using chaining would work as shown in Figure 5-15:
Figure 5-15 Search Request using Chaining
In the illustration above, the following steps are performed:
- The client application binds with Server A and Server A tries to confirm that the user name and password are correct.
- Server A does not contain an entry corresponding to the client application. Instead, it contains a chained suffix to Server B, which contains the actual entry of the client. Server A sends a bind request to Server B.
- Server B sends an acceptance response to Server A.
- Server A then processes the client application's request using the chained suffix. The chained suffix contacts a remote data store located on Server B to process the search operation.
In a chained system, the entry corresponding to the client application does not need to be located on the same server as the data the client requests. Figure 5-16 illustrates how two chained suffixes can be used to satisfy a client's search request:
Figure 5-16 Chaining Using Two Chained Suffixes to Process a Client's Search Request
In this illustration, the following steps are performed:
- The client application binds with Server A and Server A tries to confirm that the user name and password are correct.
- Server A does not contain an entry corresponding to the client application. Instead, it contains a chained suffix to Server B, which contains the actual entry of the client. Server A sends a bind request to Server B.
- Server B sends an acceptance response to Server A.
- Server A then processes the client application's request using another chained suffix. The chained suffix contacts a remote data store located on Server C to process the search operation.
However, chained suffixes do not support the following access controls:
- Controls that must access the content of the user entry are not supported when the user entry is located on a different server. This includes access controls based on groups, filters, and roles.
- Controls based on client IP addresses or DNS domains may be denied. This is because the chained suffix impersonates the client when it contacts remote servers. If the remote database contains IP-based access controls, it will evaluate them using the chained suffix's domain rather than the original client domain.