Understanding and Deploying LDAP Directory Services > 9. Topology Design > Designing Your Directory Server Topology |
Designing Your Directory Server TopologyThe optimal directory server topology for your organization depends on these four factors:
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 ApplicationsTo 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
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:
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 CapabilitiesYour directory server will no doubt have some practical limitations on the following:
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 NetworkStart 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 DesignNow 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 ExamplesThis 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 ExampleBackground: 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
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 ExampleBackground: 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
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
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 :
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.
|
Index terms contained in this sectionaddress booksapplications 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. |