Designing Your Directory Server Topology

The optimal directory server topology for your organization depends on these five factors:

1. The directory-enabled applications you use or plan to use, and the expectations of the users of those applications

2. Your directory server software and its capabilities

3. Your physical network topology

4. Your directory namespace

5. Political considerations in your organization

As you begin work on your directory topology, you may find that you want to revisit your namespace design. Recall that each partition needs a partition root, which is the DN of the entry at the top of the directory partition. This means that you may create a partition only at a branching point in your directory. In addition, if you've decided on a completely flat namespace design, but later you decide that you need to partition your directory, you'll need to go back and think about your namespace again.

If you are designing an Active Directory system, Microsoft provides many tools and guides that are helpful in leading you to an optimal design. These guides take into account the preceding factors, as well many factors specific to Active Directory, and help you determine the appropriate number of domains and the trust relationships that should exist between them. The sections that follow outline the steps in designing a directory server topology. For more information, see the Further Reading section at the end of this chapter.

Step 1: Inventory Your Directory-Enabled Applications

To decide how your directory should be partitioned, you need to understand where the directory network traffic will be coming from. To get this information, start by taking an inventory of your directory-enabled applications. You probably already have such an inventory if you followed the steps outlined in Chapter 6, Defining Your Directory Needs. We'll augment that inventory somewhat, focusing on the specific aspects of the applications that will affect your partitioning design.

While you're taking this inventory of your directory-enabled applications, you need to understand the demands those applications make on the directory. For each application, you should be interested in understanding the scope of directory operations performed by that application. In other words, what part of your organization's DIT does the application need to work with? Does it need to manipulate only a particular entry? Does it need to work within only a particular organizational unit? Or does it need to search the entire directory?

Knowing something about the performance requirements and the scope of requests an application makes allows you to decide whether that application can tolerate the overhead associated with a partitioned directory. If an application needs to search consistently across the entire namespace, having to contact many servers may be detrimental to performance. In this case the application will perform better if it needs to contact only a single server. For some applications, performance requirements are stringent enough that you need to configure your directory so that only one server must be contacted to meet that application's needs. On the other hand, for applications with relaxed performance requirements, it may be perfectly acceptable for the client application to experience delays introduced by a highly partitioned directory.

You can inventory your applications in any manner that makes you feel comfortable. Table 10.1 provides a form as a starting point; feel free to modify it as you see fit.

If you're just in the planning stage, you may not be able to produce such a detailed inventory because you have not identified all your directory-enabled applications. Use the following list as a starting point to think about the types of applications you might obtain and install. Although this list is not exhaustive, it does describe some of the more common types of directory-enabled applications:

Table 10.1. Taking Inventory of Your Applications

Application	Scope	Performance Requirements
Mail transfer agent: Sun ONE Messaging Server	Entire directory	Intermittent delays are acceptable; however, overall throughput must be at least 10 messages per second.
Netscape Communicator address book	Entire directory	Searches based on cn or uid should require no more than one second.
Network login (e.g., Active Directory login)	User 's organizational unit	Delay of a few seconds is acceptable.

• Interactive authentication and login applications . These types of applications typically verify the user's login ID and password via a two-step process. First the directory is searched to find the entry that corresponds to the login ID presented by the user. Then the application attempts to bind to the directory using the entry's DN and the password supplied by the user. If the bind operation succeeds, the user is granted access to the application. Such applications typically make light use of the directory, and a response time of a second or so is acceptable.

• Authorization applications . These applications perform some sort of authorization check for the purpose of granting or denying access to a particular resource. For example, the Netegrity SiteMinder access control and authentication system can use an LDAP directory as its store of user information when making access control decisions for a complex Web site. This type of application makes heavy use of the directory because a directory lookup may be required for each HTTP request made to the Web server. Although caching of the resulting user and group information can reduce the load on the directory server, these types of applications generally place a heavy load on the server, and users of these applications expect high performance. A response time significantly faster than one second is required.

  Also important, however, is the scope of these operations, which depends on the way the application is configured. Novell eDirectory, for example, requires that the user or administrator configure a default context, which specifies the subtree under which searches are performed and therefore limits the scope of the search operation that maps the user login ID to a directory entry. If users log in primarily from a single physical location, this works well because the server that can provide the requested information can be located on the same network as the client. On the other hand, if you have a large population of "nomadic" users, little benefit is gained from a highly partitioned directory.

• Address book applications . These applications, typically embedded inside e-mail applications, are usually used for looking up information about specific people or groups. The searches generated by these applications usually span the organization's entire namespace. Response times of a second or two are usually tolerable. The address books in Netscape Communicator, Microsoft Outlook, and QUALCOMM Eudora are all examples of this type of application.

• Messaging applications . These applications use the directory to route e-mail messages to their destinations. They can generate a heavy load on a directory server, especially when they're delivering mail to groups of users. The searches generated often span the entire organizational directory namespace. The performance of an individual search request is generally not important, but the overall throughput of the directory can be a limiting factor in the number of messages delivered. Examples of this type of application include Sun ONE Messaging Server and most other LDAP-aware e-mail servers.

After you inventory the directory applications that will use the directory and you understand their scope and the expected response times, you can begin to understand the performance implications of a highly partitioned directory versus an unpartitioned directory.

Tip

In our experience, directories increasingly are becoming the nerve center of IT organizations. In the past it was possible to lay out a directory in such a way that clients could get almost all the information they needed from a local server, which held information only about the local workgroup. But now that LDAP has provided a standard way for client applications to retrieve directory information, a much richer, more functional set of directory-enabled software is available. These applications leverage the enterprisewide knowledge contained in your directory and tend to search across your entire organizational directory space.

For example, an e-mail client might support sending signed, encrypted mail by using the directory to look up the public keys of mail recipients. This type of application has a wide scope; it typically needs to look up an e-mail address in your directory and retrieve the public key associated with the entry. You should not be surprised to learn that a majority of your directory-enabled applications require fast access to your entire directory tree. If you are in this situation, a highly partitioned directory will perform poorly. You should strive to reduce the number of partitions if possible.

Step 2: Understand Your Directory Server Software and Its Capabilities

Your directory server will no doubt have some practical limitations on the following:

• The number of entries that can be stored in a partition

• The number of partitions that can be held on a server

• The number of entries that can be held on a server

• The number of subordinate references that can be maintained at a given level of the DIT

• The number of replicas of a partition that can be maintained

• The number of indexed searches that can be serviced per second

• The number of concurrent client connections that can be supported

As you design your topology, you may find that some previous decisions you made are at odds with the limitations of your directory server software. For example, if you've decided on a flat namespace design for your 500,000-entry directory but need to implement it with server software that has a practical limitation of 100,000 entries per server, you need to revisit your namespace design to accommodate the server software.

If you have not yet decided on a particular vendor's directory server software, you can use the preceding list as a checklist as you go through the decision-making process described in Chapter 13, Evaluating Directory Products.

Step 3: Create a Map of Your Physical Network

Start with the map of your organization's physical network that we discussed in Chapter 6, Defining Your Directory Needs. The components you should now focus on are your LANs and the connections between them. Label each LAN segment with its physical location, and then label the connections between LANs with the bandwidth, latency, and reliability of the connection. The bandwidth of a network connection is the maximum speed at which data can be transferred, and the latency of a connection is the time it takes for data to travel across the connection. A low-latency connection is ideal for LDAP traffic. High-latency links such as satellite links result in slow round-trip times for interactive traffic such as LDAP authentication, which can result in poor performance for applications. Such links, however, are often adequate for protocols such as File Transfer Protocol (FTP), which transfers data in bulk.

If you know that the connection is not 100 percent reliable or is active only during certain times of the day, note that on the map as well. Consider the hypothetical organization shown in Figure 10.11. The main office, located in Boulder, Colorado, consists of several Ethernet segments connected via a high-speed backbone network. A branch office in London is connected via a 56Kbps leased line that is reliable but exhibits a relatively high latency of 200 milliseconds (one-fifth of a second).

Figure 10.11. A Basic Network Map

Next label on your map the locations of any directory-enabled applications you currently have. For example, if you have deployed (or plan to deploy) LDAP-enabled e-mail client software to users on each LAN, note this on your map. If you know the scope and performance requirements of the directory operations these clients execute, note those as well. As an example, note in Figure 10.12 that there are two types of directory-enabled applications: Novell login clients and Netscape Communicator clients.

Figure 10.12. An Expanded Network Map Showing Locations of Directory-Enabled Applications

If possible, you should also include server-based directory-enabled applications such as e-mail servers, LDAP-enabled Web applications servers, and so on. You may not have installed these servers yet; that's fine, because you can experiment with their placement to optimize availability. Note on the map any other details, such as applications that perform many updates. You may need to enlist the help of other system and network administrators to accomplish this task.

After you put your directory clients and servers on your map, you can start to see traffic patterns emerge. Look for the locations of your high-volume directory clients, especially mail and authorization servers. Strive to limit traffic across slower WAN links; make sure that clients on remote networks have the information they need on the local LAN so that client requests need not traverse the WAN links.

Step 4: Review Your Directory Namespace Design

Now that you have a good idea of how your client and server applications are laid out, you can revisit your namespace design. Does it fit well with your WAN infrastructure and partition design? A properly designed namespace allows you to place partitions close to the users and applications that use the data they contain. If you find that your namespace makes this difficult, try other ways of arranging the namespace.

For example, if you are designing a directory for a multinational company and you've chosen a namespace that reflects the company's organizational structure, you may have problems defining partitions that minimize traffic across WAN links. In this case, consider an alternative namespace design. Rather than having the top-level branch points correspond to organizational structure, try making them correspond to geographical regions .

Step 5: Consider Political Constraints

Almost all organizations have one or two departments that operate autonomously from the main company. These departments have their own servers and their own IT staff, and they administer their own user population. Try to design your topology in such a way that allows these groups to operate autonomously while still participating in your directory system. For example, giving each of these departments its own directory partition and the ability to administer it is one approach that balances participation in the directory topology with the department's need to be autonomous.

Directory Partition Design Examples

This section describes two examples of directory partition design: one with a single partition, the other with multiple partitions. Your directory partition design will almost certainly not be exactly like one of the two scenarios described here. However, you may find some elements in common between your situation and these examples, and we hope you can draw useful conclusions from those common themes. You should also become familiar with the case studies in Part VI of this book. The case studies represent real-world directory deployments and do even more to illustrate the issues you will face as you set out to design the best directory topology for your environment.

A Single-Partition Directory Design Example

Background

Example Electronics is a small manufacturer of electronics modules for the airline industry. It employs 1,000 people, most of them at its large Boulder, Colorado, office. It has two branch offices: one in London and one in Paris. The branch offices are connected to the main campus by 56Kbps leased lines. The Boulder campus consists of 30 Ethernet segments connected via a 100Mbps backbone network.

Inventory of Directory-Enabled Applications

Example Electronics is deploying its directory to support two major applications initially. The first is a directory-enabled messaging application; the second is an intranet Web application in which the directory will be used to store access control information. In addition, each user's workstation will run an address book application that addresses and digitally signs internal e-mail. Table 10.2 shows the inventory of planned directory-enabled applications.

Capabilities of Directory Software

Example Electronics has not yet chosen a particular directory server package. Part of the planning phase of the directory deployment will be the development of a set of requirements for the directory server.

Table 10.2. Performance Requirements of Example Electronics' Planned Applications

Application	Scope	Performance Requirements
Messaging server	Entire directory	Intermittent delays are acceptable. However, overall throughput must be at least 10 messages per second. Each message delivery requires one search per recipient. Estimated peak directory load is 50 searches per second.
Intranet Web server	Entire directory	Approximately 100 authenticated page views per second are expected. Assuming that each page contains four inline images, this corresponds to approximately 500 hits per second. Web server caching of ACL information will reduce the load on the directory server to about 10 directory searches per second. Maximum acceptable delay time to send the entire Web page is one second.
Address book application	Entire directory	Total directory load will be approximately 5 searches per second. Searches should require no more than three seconds for indexed attributes.

Physical Network Topology

Whereas all users on the Boulder campus enjoy high-speed connectivity to other hosts on the Boulder campus, the two European offices are connected via slower leased lines (see Figure 10.13). Frequently these connections see heavy use from other applications. Actual throughput on the leased lines is likely much less than 56Kbps. Directory clients are present on each Ethernet segment and at both remote office locations. These remote clients require access to the entire directory tree to address and sign e-mail. In addition, multiple local intranet Web servers are planned so that each department or remote sales office can publish information to the intranet with access control. To guarantee fast response at the remote offices, it was decided that a replica of the entire directory needs to be available at each one.

Figure 10.13. A Network Topology Map Showing the Location of Example Electronics' Directory-Enabled Applications

Namespace Design

Example Electronics is organized by projects, and individual employees move among projects fairly frequently. For this reason, the company has decided on a flat namespace (see Figure 10.14) with all employee directory entries contained directly below ou=People,dc=example,dc=com . Individual attributes within a person's entry denote the projects the person is working on, so it is not necessary to rename an entry if the employee changes projects.

Figure 10.14. Example Electronics' Namespace Design

Conclusions

After reviewing all this information, Example's information systems organization has decided to retain the flat namespace and put all directory entries in a single partition. Two additional replicas of the directory will be placed at the main office for load balancing and fault tolerance. Replicated directory servers will be placed at both European offices, and clients at each of those offices will be configured to use the local replica, falling back on using the server at the Boulder campus only if the local server fails. Figure 10.15 shows a diagram of the final design.

Figure 10.15. Example Electronics' Final Topology Design

A Multiple-Partition Directory Design Example

Background

Our hypothetical company in this example, Example Software, is a company with about 10,000 employees in three separate offices: New York, the corporate headquarters; San Francisco, which houses the software developers and support staff; and a London office, which houses European sales and support staff. Table 10.3 shows the company's organizational chart.

The company has chosen to deploy Novell eDirectory. It also plans to deploy a third-party e-mail hub that leverages information stored in the Novell directory to route inbound Internet mail to internal destinations, including several shared mailboxes used by the support staff to handle support requests that come via e-mail.

Table 10.3. Example Software's Organizational Chart

New York Office	London Office	San Francisco Office
Finance department	European Sales	Software Development
Legal department	European Support	Western Region Support
Eastern Region Support	Human Resources	Human Resources
Human Resources		US Sales

Inventory of Directory-Enabled Applications

As previously mentioned, Example Software is planning to deploy two applications that use Novell eDirectory: NetWare login and e-mail delivery. Whereas the scope of the NetWare login application is generally limited to the local workgroup, the mail hub software needs to search across the entire organizational namespace and has a high throughput requirement (see Table 10.4).

Capabilities of Directory Software

Novell's eDirectory is capable of handling all 10,000 entries in a single partition. In this case the capabilities of the directory software do not constrain our decision-making process.

Physical Network Topology

The three offices of Example Software are connected via a frame relay network. The network is reliable, but the speed (1.544Mbps at peak) is modest compared to the intracampus backbone networks. Furthermore, the intercampus links have only a 64Kbps committed information rate, which means that the measured throughput is often much less than the theoretical maximum. For this reason, it is a good idea to limit traffic across the WAN links as much as possible. Figure 10.16 shows the intercampus links.

Figure 10.16. Example Software's Network Map

We can limit the traffic across the WAN links by placing the data needed by clients at each campus on an on-campus server.

Table 10.4. Performance Requirements of Example Software's Planned Applications

Application	Scope	Performance Requirements
NetWare login	Local to workgroup	Retrieval time of a few seconds for user login scripts is acceptable.
E-mail hub	Entire directory	Must sustain throughput of 10 messages per second.

Namespace Design

Example Software originally decided on a namespace that reflected its organizational structure. Figure 10.17 shows this initial namespace layout.

Figure 10.17. Example Software's Original Namespace Design

Recall that directory partitions can be defined only at branch points in the directory. This means that any possible partition must have a partition root corresponding to one of the organizational units in the design. Thus the partitioning choices are as follows :

• A single partition rooted at dc=example,dc=com . This is a reasonable choice, except it will require all directory traffic to cross the relatively low-speed WAN links.

• Three partitions, rooted at ou=Administration,dc=example,dc=com ; ou=Sales,dc=example,dc=com ; and ou=Product Development,dc=example, dc=com . Again, this arrangement makes it difficult to avoid sending directory traffic across WAN links. Note in Table 10.3 that the Human Resources staff is divided among the three campuses. No matter where the ou=Administration partition is located, Human Resources staffs at the other two locations would need to traverse WAN links to retrieve their directory data.

• Eleven partitions, corresponding to each of the individual workgroups. Although this arrangement would allow partitions to be placed locally to each workgroup, management of all these partitions would be more time-consuming , especially if replication were used to provide additional copies of the partitions.

When you find yourself facing this kind of dilemma, it's often beneficial to step back and reexamine your choice of namespace layout. In this case, doing away with the existing namespace based on organizational structure and replacing it with one based on geographical layout makes the topology fit much better with the WAN infrastructure. Figure 10.18 shows a revised namespace design.

Figure 10.18. Example Software's Revised Namespace Design

Notice that the three organizational units based on geography fit well with the WAN infrastructure. If we make these organizational units the roots of three partitions and locate those partitions at their respective campuses, we succeed in localizing user traffic to the individual campuses. Note that there are actually four partitions, as denoted by the dashed lines in Figure 10.18. There must be a partition rooted at dc=example,dc=com to tie the three subordinate partitions together and allow name resolution. This partition, which is very small, can be replicated to each of the three locations via Novell replication.

One problem remains, however. The mail hub application needs to search across the entire organizational namespace frequently ”perhaps several times per second. If we don't take special action, the mail hub will need to contact all of the directory servers, resulting in a great deal of traffic on the WAN links.

We can solve this problem by creating a dedicated server to hold replicas of all the partitions (replication will be covered in more detail in Chapter 11, Replication Design). Because the mail hub has high-performance requirements, it's probably a good idea to provide it a dedicated server anyway. We call this an aggregating server because it aggregates the directory data into a central location for the mail hub's use. The one drawback to using an aggregating server is that placing all the entries on a single host may tax the system hosting the aggregating server.

Another more expensive but higher-performance alternative would be to place each replica on a separate server and locate all the replicas on the same network as the mail hub application. Performance would improve because each mail hub would have a dedicated directory server. If that approach still did not provide adequate performance, another alternative would be to make a copy of the directory data in a single Netscape Directory Server 6 server that would service the mail hub. The Netscape server, designed specifically with search performance in mind, is a better choice for this particular application than Novell eDirectory, which is designed primarily to support a highly distributed NOS environment.

Conclusions

Figure 10.19 shows the final allocation of partitions to servers. The three campus directory servers each hold a copy of the top-level partition, rooted at dc=example, dc=com , and each campus directory server holds a partition comprising the data that local clients need. In addition, the aggregating server, which resides on the same network segment as the mail hub, holds read-only copies of all directory partitions and receives replication updates from the read/write partitions located at each campus site.

Figure 10.19. Allocation of Partitions to Servers at Example Software

This example shows that it's beneficial to spend some time thinking about namespace design and topology as a unit.