eDirectory Tree Design

A key purpose of implementing a network directory is to make the operation of the network more efficient and easy to use. Unfortunately, this means that the directory cannot be rolled out without any consideration for the environment into which it is being installed. There are a few basic rules that should be followed when designing an eDirectory tree:

• The top of the tree reflects the physical layout.

• The bottom of the tree reflects the organizational structure.

• Organize objects to facilitate access and administration.

• Partition and replicate for scalability and fault tolerance.

Each of these issues is addressed in the sections that follow.

Top of the Tree Reflects Physical Layout

The top one or two levels of an eDirectory tree form the foundation for everything that comes later. If these levels are not configured properly, the whole tree suffers. Similar to the construction of a house, the eDirectory tree foundation needs to be stable and not prone to changes in structure.

The stable part of an organization tends to be its capital assets (buildings and equipment). Organizational structure might change and merge, but it still generally uses the same physical facilities. Make use of this stability by designing the foundation of the eDirectory tree around physical locations.

There are four main points to address when designing the top levels of the eDirectory tree:

• Name the tree [Root].

• Determine use of Country and Locality objects.

• Define the Organization object.

• Define location-based Organizational Unit objects.

When you name your eDirectory tree, you are naming the [Root] object. Make the name descriptive and unique. It should also be different from other Container objects. Many use the following tree name convention: Organization Name_TREE.

Next you have to decide how to create the first level in your eDirectory tree. This involves determining whether you are going to incorporate the use of a Country \ or a Locality (L) object into your eDirectory tree design, as shown in Figure 7.4.

Figure 7.4. eDirectory Country and Locality objects.

Country and Locality object use is optional and may not make sense depending on your directory structure. However, if it is important to comply with X.500 naming syntax in order to interact with external X.500 directories, these objects can be used. Other than that, it is probably easier to start with the Organization (O) object and define geographical regions under the organization as Organizational Unit (OU) objects, as shown in Figure 7.5.

Figure 7.5. Sample eDirectory tree.

Next you must determine the name of your Organization object. Every eDirectory tree must have at least one Organization container. Normally, this is the first level of the tree, so using the organization name is a good way to go.

Finally, define subsequent levels of the tree around the physical network infrastructure currently employed (or planned) by the organization. Regional sites are usually defined as level 2 organizational units. A third level may also be appropriate for larger organizations to designate branch offices. Usually, three levels dedicated to the geographical structure of the organization will accommodate even the largest organizations.

The opposite is true for smaller companies. In some cases where the company is located at a single site, the physical levels can be eliminated altogether, if desired. However, this strategy is not recommended if there is any chance the company will grow into multiple sites in the future because the lack of containers based on physical sites will make it more difficult to expand the eDirectory structure as the organization grows.

Bottom of the Tree Reflects Organizational Structure

The bottom portion of the tree is where all the action is. Unlike the top of the tree, we fully expect adaptation and evolution to occur over time at the lower levels of the tree. This means we need to design flexibility into the system.

For this reason, the lower levels of the eDirectory tree will grow based not on physical locations, but on organizational structure, as shown in Figure 7.6. The best way to visualize the eDirectory tree at this point is to look at a current copy of your company's organizational chart. You will need to understand the divisions and/or departments that operate at each physical site in order to create the lower levels of the eDirectory tree.

Figure 7.6. The lower levels of an eDirectory tree mirror the organizational structure.

The reason that Organizational Unit containers are so useful at this level is that they allow you to group resources together. You can put the users in the Marketing department together with their printers, servers, and applications. Then those users and resources can be managed together. As you will see in the next section, this grouping also allows you to minimize the overhead associated with maintaining replica integrity and currency.

Organize Objects to Facilitate Access and Administration

Now that you have the general tree design and containers created, the next point to consider becomes how to organize the Leaf objects that will populate the eDirectory tree. The two primary considerations for this are

• Make it as easy as possible for users to access the resources they need.

• Make it as easy as possible to centrally control and administer network resources.

In most cases, you will be able to place resources such as servers, printers, and departmental applications in the same container with the users who will need access to those resources. However, if users in multiple containers will share resources, place those resources one level above the user containers. This makes the resource much easier to locate.

Furthermore, if you group users based on common needs, you can manage things like access controls, login scripts, and policies from the container level, rather than managing each user individually. Only the exceptions to the general container rules need to be specifically managed. Management by exception is tremendously powerful as a tool for reducing complexity and increasing efficiency.

Partition and Replicate for Scalability and Fault Tolerance

As a distributed database, eDirectory requires a mechanism for dividing the entire database into discrete chunks that can be installed on different servers across the organization. This is done through a process of partitioning and replicating the database.

PARTITIONS

eDirectory allows the creation of partitions in order to distribute the directory database across the network. A copy of a given eDirectory partition is known as a replica. By creating multiple replicas of a given partition, you build fault tolerance into the directory architecture. If a server holding a partition replica fails, the partition is still available from other replica servers.

Locating those portions of the eDirectory database close to those users who make use of them dramatically increases eDirectory performance. It also greatly reduces network traffic associated with directory queries. This is particularly important when multiple sites are connected by costly WAN links. The last thing you want to do is use a WAN link bandwidth for background operations like searching for a server or printer.

When the first eDirectory server is installed, a [Root] partition is automatically created and a replica of that partition is stored on the eDirectory server. When [Root] exists, the rest of the directory can be built by adding the necessary Container and Leaf objects.

As other eDirectory servers are installed, replicas of [Root] should be created to provide fault tolerance. If you maintain a small network at a single site, the [Root] partition might be all you need. Replicate it to two or three servers for fault tolerance and you are done. However, if your network environment is more complex, more work should be done to create an efficient eDirectory environment.

Planning your eDirectory partition strategy is similar to planning the top levels of the eDirectory tree. Partition creation should follow the physical network infrastructure. WAN links should always be considered boundaries between partitions. This eliminates the need for eDirectory to pass background traffic across these links. Refer to Figure 7.3 for a view of partitioning along geographical lines.

Each child partition should then be replicated to multiple servers at the site that partition is serving. When partitions have been created based on the physical boundaries, it is not usually necessary to partition the bottom layers of a tree. However, there are two possible exceptions to this:

• A child partition might also be further partitioned in order to limit the number of partition replicas that exist across the network. A large number of replicas for any given partition will increase the background traffic required for synchronization. It also complicates partition repair operations that may be necessary. A good rule of thumb is to try to limit the total number of replicas of a given partition to 10 or fewer.

• If you are using Filtered replicas to create specific views of eDirectory information, it is entirely acceptable to further divide a child partition.

The goal of your partitioning strategy should be a small [Root] partition and a child partition for every physical site in the network. The [Root] partition should end up containing only [Root] and the Organization object. The reason for this is explained in the next section.

REPLICAS

A replica is a physical copy of an eDirectory partition. By default, the first replica created is designated as the Master replica. Each partition will have one, and only one, Master replica. Other replicas will be designated as Read/Write, Read-Only, and Subordinate references. There are five types of eDirectory replicas:

• Master replica The Master replica contains all object information for the partition. Objects and attributes maintained in the partition can be modified from the Master replica. These changes are then propagated to other servers holding replicas of this partition. Furthermore, all changes to the partition itself, such as creating other replicas or creating a child partition, must be performed from the perspective of the server that holds the Master replica.

• Read/Write replica A Read/Write replica contains the same information as the Master replica. Objects and attributes maintained in the partition can be modified from the Read/Write replica. These changes are then propagated to other servers holding replicas of this partition. Any number of Read/Write replicas can be created. However, for the sake of overall directory performance, it is recommended that the total number of partition replicas not exceed 10. This type of replica cannot initiate partition operations.

• Read-Only replica A Read-Only replica contains all the same information as the Master and Read/Write replicas. Users can read, but not modify, the information contained in these replicas. The replica is updated with changes made to the Master and Read/Write replicas. In practice, Read-Only replicas are seldom used because they are unable to support login operations. The login process requires updating some directory information. Because a Read-Only replica does not support directory updates, it cannot provide login services. One potential use is maintaining a backup copy of a partition. The Read-Only replica will receive all partition updates but will not participate in the update process in any way.

• Filtered replica A Filtered replica can be either a Read-Only or a Read/Write replica. They are designed to provide specific services or applications, including other directories, with only the eDirectory information they need. Creating replicas that contain only certain types of objects and/or specific subsets of object attributes accomplishes this goal. For example, a Filtered replica might hold only User objects with their associated names, phone numbers, and email addresses for a corporate directory application.

  NOTE

  These replica types exist primarily to eliminate the single point of failure in an eDirectory environment. A recommended design goal is three replicas one Master and a combination of Read/Write and/or Read-Only replicas. As stated previously, the Read-Only replica is seldom used, so most eDirectory implementations will focus on Master and Read/Write replicas in their production environments.

  
  

• Subordinate references Subordinate references are special replica types that provide connectivity between the various partitions that exist in an eDirectory environment. Subordinate references are internal replicas and are not visible to users or configurable by administrators. A Subordinate reference contains a list of all servers that hold replicas of a child partition. eDirectory uses this list to locate the nearest replica of a child partition so that it can walk down the tree when searching for an object. Figure 7.7 shows how Subordinate references are distributed across servers.

  Figure 7.7. eDirectory Subordinate references.

  

  
  

  A partition's Subordinate reference is stored on all servers that hold a replica of that partition's parent. Subordinate references effectively point to child partition(s) that are not stored on that particular server. The distributed nature of eDirectory allows servers to hold replicas of the parent partition but not all of the corresponding child partitions.

The eDirectory replication strategy is a balancing act between the need to provide consistency across the directory and the limitations of network hardware and bandwidth. You should follow three rules when creating your replication strategy:

• Don't replicate across WAN links. WAN links represent one of the most costly network resources. To clutter up these links with unnecessary eDirectory traffic would be a terrible mistake. To avoid this, all copies of a given partition should be maintained locally. The one situation where this rule might not apply (there's always at least one exception, isn't there?) is the case of a small satellite office with only one server. In that case, it is more important to protect the eDirectory database by placing a replica across a WAN link than it is to preserve the WAN link bandwidth itself. Fortunately, a partition that contains only one server will not usually generate a lot of eDirectory traffic.

• Replicate to limit subordinate references. Even though Subordinate references don't participate in the normal eDirectory replica update process, it's still a good idea to limit the number of Subordinate references to reduce complexity. There are two ways to do this:

  • Limit the number of child partitions that are created. This is only partially controllable because you always want to define WAN links as partition boundaries. However, this does argue for limiting the number of additional partitions that are created within a single site.

  • Store both parent and child partition replicas on the same server wherever possible. If multiple partitions are going to exist at a single site, try to distribute replicas such that parent and child partition replicas are stored together.

• Replicate to improve eDirectory performance. The final reason to replicate is to provide the best possible performance for network users. If the partition and replication guidelines in this chapter are followed, a user will find most of his or her resources within the local partition. Occasionally it may be necessary to access a resource on the other side of the world. These situations require eDirectory to traverse, or walk, the tree to locate the requested resource. As previously noted, these searches start at [Root] and proceed down the tree until the requested object is located. Placing replicas of [Root] at strategic locations, such as communications hubs, can facilitate these searches. In order to do this without significantly increasing the overall replication burden, the [Root] partition must be small (only the [Root] object and the Organization object) and the number of [Root] replicas should not exceed three or four.

TIP

Novell now offers some advanced services that are helping to redefine directory design and usage in today's modern networks. For example, Nterprise Branch Office helps greatly reduce the cost and complexity of eDirectory replication at satellite offices. Identity Manager is redefining eDirectory as a world-leading meta-directory that allows data to be transparently synchronized across many potential repositories. More information on Identity Manager is available in Chapter 10, "Identity Manager Bundle Edition." For information regarding a Linux-based Nterprise Branch office, watch Novell's website!