Advice for Going Production

Understanding and Deploying LDAP Directory Services > 9. Topology Design > Designing Your Directory Server Topology

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053054012006221255145095152090110

Designing Your Directory Server Topology

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

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

  • Your directory server software and its capabilities

  • Your physical network topology

  • Your directory namespace

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 naming context. This means that you may create a partition only at a branching point in your directory. Also, if you've decided on a completely flat namespace design, but you later decide that you need to partition your directory, you'll need to go back and think about your namespace again.

Also, don't worry too much about getting every last detail exactly correct. Requirements will change. New directory-enabled applications will be developed. Your company will reorganize. Upgraded server software will become available. Your company will reorganize again. Change is a fact of life. Directory services are flexible, and you can tweak your solution as your needs evolve .

With those things in mind, here are the four steps toward designing your topology.

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, you should 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 5, "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 thescope 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 only within a particular organizational unit? Or, does it need to search the entire directory?

Knowing something about the scope of requests an application makes allows you to decide if that application can tolerate the overhead associated with a partitioned directory. If an application needs to consistently search across the entire namespace, it may be detrimental to performance if a large number of servers must be contacted. In this case, the application will perform better if it needs to contact only a single server.

Additionally, you should know the performance requirements of the application. For some applications, performance requirements are stringent enough that you need to configure your directory so that only one server needs to 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 whatever manner you feel comfortable with. We have provided a form in Table 9.1 as a starting point; feel free to modify it as you see fit.

Table  9.1. Taking inventory of your applications
Application Scope Performance Requirements
Mail transfer agent: Netscape Messaging Server Entire Directory Intermittent delays 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 (for example, Novell Netware login program) User 's org unit Delay of a few seconds acceptable.

If you're just in the planning stage, you may not be able to produce such an inventory because you don't have any 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:

  • 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 some resource. For example, a Netscape Enterprise Server can be configured to use an LDAP-based directory server for access control. The access control information for a particular Web page or set of Web pages is stored in the directory so that it can be shared by a number of servers. 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 access control information can reduce the load on the directory server, these types of applications generally place a heavy load on the directory server, and users of these applications expect high performance. A response time of less than one second is necessary, and faster response is desirable.

    The scope of these operations, however, is also quite important, and it is quite dependent on the way the application is configured. NDS, 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 quite 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, such as the student population described in Chapter 24, "Case Study: A Large University," little benefit is gained from a highly partitioned directory.

  • Address book applications.   These applications, typically embedded inside electronic mail applications such as Netscape Communicator, are usually used by people to look up information about other 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 Netscape Communicator address book and Qualcomm's Eudora 4.0 address book are both examples of this type of application.

  • Messaging applications.   These applications use the directory to route electronic mail messages to their destinations. They can generate a heavy load on a directory server, especially when delivering mail to groups of users. The searches generated usually 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 Netscape's Messaging Server and most other LDAP-aware electronic mail servers.

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

Tip

It is our experience that directories increasingly are becoming the nerve center of IT organizations. In the past, it was possible to lay out your 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 becoming available. These applications leverage the enterprisewide knowledge contained in your directory and tend to search across your entire organizational directory space.

For example, an electronic 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 email 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 at all possible.



Step 2: Understand Your Directory Server Software and Its Capabilities

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

  • Number of entries that can reasonably be stored in a partition

  • Number of partitions that can be held on a server

  • Number of entries that can be held on a server

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

  • Number of replicas of a partition that can be maintained

  • Number of indexed searches that can be serviced per second

  • 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 100,000-entry directory but need to implement it with server software that has a practical limitation of 5,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 12, "Choosing 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 5, "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 FTP, which transfers data in bulk.

If you know that the connection is not 100% 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 9.12. 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 quite reliable but exhibits a relatively high latency of 200 milliseconds (1/5 of a second).

Figure 9.12 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 electronic 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 9.13 that there are two types of directory-enabled applications on the Engineering LAN segment: NDS login clients and Netscape Communicator clients.

Figure 9.13 An expanded network map showing locations of directory-enabled applications.

You should also, if possible, include server-based directory-enabled applications such as electronic 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 a large number of updates. You may need to enlist the help of other system and network administrators to accomplish this task.

After you have 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 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 network layout.

Directory Partition Design Examples

This section describes two examples of directory partition design: a single- partition example and a multiple-partition example. 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:   Airius 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:   Airius is deploying its directory to initially support two major applications. 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. Additionally, each user's workstation will run an address book application used to address and digitally sign internal electronic mail. The inventory of planned directory-enabled applications is shown in Table 9.2.

Table  9.2. An application performance requirements table
Application Scope Performance Requirements
Messaging server Entire directory Intermittent delays 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 Webserver Entire directory Approximately 100authenticated page-views per second. 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 3 seconds for indexed attributes.

Capabilities of directory software:   Airius 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.

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 9.14). 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 electronic mail. Additionally, a number of 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 remote office.

Figure 9.14 A network topology map showing the location of Airius's directory-enabled applications.

Namespace design:   Airius is organized by projects, and individual employees move among projects fairly frequently. For this reason, Airius has decided on a flat namespace (see Figure 9.15) with all employee directory entries contained directly below ou=People, dc=airius, 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 9.15 Airius's namespace design.

Conclusions:   After reviewing all this information, Airius's information systems organization has decided to retain the flat namespace and put all directory entries within 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 of the European offices, and clients at 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. A diagram of the final design is shown in Figure 9.16.

Figure 9.16 Airius's final topology design.
A Multiple-Partition Directory Design Example

Background:   Our hypothetical company in this example, Airius 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. The company organizational chart is shown in Table 9.3.

Table  9.3. Organizational chart of Airius Software
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   U.S. Sales

The company has chosen to deploy NDS as it upgrades its existing NetWare 3 network to Novell IntranetWare. It also plans to deploy a third-party email hub that leverages information stored in NDS to route inbound Internet mail to internal destinations, including a number of shared mailboxes used by the support staff to handle support requests that come via email.

Inventory of directory-enabled applications:   As previously mentioned, Airius is planning to deploy two applications that use the NDS directory: NetWare login and electronic mail delivery. The scope of the NetWare login application is generally limited to the local workgroup, whereas the mail hub software needs to search across the entire organizational namespace and has a high throughput requirement (see Table 9.4).

Table  9.4. An application performance requirements table
Application Scope Performance Requirements
Netware Login Local to workgroup Retrieval time of a few seconds for user login scripts acceptable
Electronicmail hub Entire directory Must sustain throughputof 10 messages per second

Capabilities of directory software:   In general, NDS guidelines recommend limiting the number of directory entries within a single partition to a few thousand, so it is probably not prudent to place all 10,000 entries within a single partition.

Physical Network Topology:   The three offices are connected via a frame relay network. This is very reliable, but the speed (1.544Mbps peak) is modest compared to the intracampus backbone networks. Furthermore, the intercampus links have only a 64Kbps committed information rate, which means that the actual throughput is often much less than the peak. For this reason, it is a good idea to limit traffic across the WAN links to the greatest extent possible. These intercampus links are shown in Figure 9.17.

Figure 9.17 Airius Software's network map.

Traffic across the WAN links can be limited by placing the data needed by clients at each campus on an on-campus server.

Namespace design:   Airius originally decided on a namespace that reflected its organizational structure. This initial namespace layout is shown in Figure 9.18.

Figure 9.18 Airius 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. This means that the partitioning choices are as follows :

  • A single partition rooted at dc=airius, dc=com . This is a poor choice because it would exceed the practical limits for the number of entries in a single partition.

  • Three partitions, rooted at ou=Administration, dc=airius, dc=com ; ou=Sales, dc=airius, dc=com ; and ou=Product Development, dc=airius, dc=com . This arrangement probably allows for adequate distribution of entries among three partitions, assuming that roughly an equal number of people work in each division. However, such an arrangement makes it difficult to avoid sending directory traffic across WAN links. Note in Table 9.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 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 re-examine 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 9.19 shows a revised namespace design.

Figure 9.19 Airius Software's revised namespace design.

Notice how 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 campus, 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 9.19. There must be a partition rooted at dc=airius, 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 NDS replication.

One problem remains, however. The mail hub application needs to search across the entire organizational namespace frequently ”perhaps several times per second. Without taking some special action, the mail hub's directory traffic would span two of the WAN links.

We can solve this problem by creating a dedicated server that holds replicas of all the partitions (replication will be covered in more detail in the next chapter). 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. If that approach still does not provide adequate performance, another alternative would be to make a copy of the NDS data in a single Netscape Directory 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 NDS, which is designed primarily to support Netware.

Conclusions:   The final allocation of partitions to servers is shown in Figure 9.20. The three campus directory servers each hold a copy of the top-level partition, rooted at dc=airius, dc=com , and each campus directory server holds a partition comprising the data local clients need. Additionally, 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 9.20 Allocation of partitions to servers at Airius Software.

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



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing

<  BACK CONTINUE  >

Index terms contained in this section

address books
applications
          address books
          authentication
          authrorization 2nd 3rd
         inventories
                    topology design 2nd 3rd 4th 5th 6th 7th 8th 9th
          login
          messaging
authentication
          applications
authorization
          applications 2nd 3rd
design
          topologies 2nd
                    application inventories 2nd 3rd 4th 5th 6th 7th 8th 9th
                    directory server software 2nd
                    partition examples 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
                    physical network mapping 2nd 3rd 4th
                    reviewing namespace design
directories
          topologies 2nd
                    application inventories 2nd 3rd 4th 5th 6th 7th 8th 9th
                    directory server software 2nd
                    partition examples 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
                    physical network mapping 2nd 3rd 4th
                    reviewing namespace design
distributed directories
          topologies 2nd
                    application inventories 2nd 3rd 4th 5th 6th 7th 8th 9th
                    directory server software 2nd
                    partition examples 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
                    physical network mapping 2nd 3rd 4th
                    reviewing namespace design
examples
         partition
                    topology design 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
inventories
         application
                    topology design 2nd 3rd 4th 5th 6th 7th 8th 9th
login applications
mapping
         networks
                    topology design 2nd 3rd 4th
messaging applications
multiple-partition directory designs 2nd 3rd 4th 5th 6th 7th 8th
namespaces
         reviewing designs
                    topology design
networks
         mapping
                    topology design 2nd 3rd 4th
partitioning
         examples
                    topology design 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
physical networks
         mapping
                    topology design 2nd 3rd 4th
servers
         directory software
                    topology design 2nd
single-partition directory designs 2nd 3rd 4th 5th 6th
software
         directory servers
                    topology design 2nd
topologies
          designing 2nd
                    application inventories 2nd 3rd 4th 5th 6th 7th 8th 9th
                    directory server software 2nd
                    partition examples 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
                    physical network mapping 2nd 3rd 4th
                    reviewing namespace design

2002, O'Reilly & Associates, Inc.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net