Advantages and Disadvantages of Partitioning

For many smaller directory deployments, it is perfectly reasonable to keep all your directory data in one partition. This arrangement generally results in better search performance because a single server can provide the data requested by the client without requiring that other servers be contacted.

If you have only a few thousand entries in your directory, there is probably no benefit to partitioning, regardless of the type of server software you're using. Even larger partitions (sometimes as big as millions of entries) are supported by certain server software. Consult your server documentation to determine the largest number of entries that is reasonable to place in a single partition. If the number of entries stored in your directory significantly exceeds the number that can be practically stored in a single partition, split your directory into multiple partitions. Otherwise, try to limit your directory to one or just a few partitions.

Another reason to maintain a single large partition has to do with the types of directory-enabled applications you're using. Some applications tend to search the entire directory namespace repeatedly; these types of applications perform best if they have to search only one server to obtain the data they need.

For example, Sun ONE Messaging Server, when delivering e-mail, must look up the recipient's e-mail address in the directory to determine routing information. If you provide a centralized e-mail forwarding service that routes mail addressed to employee@domain to the correct server, it's likely that the entire directory namespace of your enterprise will have to be searched to perform this function. If your directory is split into many partitions, the overhead of searching each of them can have a significant negative impact on the performance of such a directory-enabled application. If your directory must support these types of applications, try to limit the number of directory partitions or point these applications to a server that aggregates all the partitions into a single location. We describe this configuration in more detail in the design example later in this chapter.

Microsoft Active Directory takes a different approach to solving the problem of searching across the entire organizational namespace. A special type of replica called the global catalog ( GC ) contains partial copies of frequently searched attributes from all directory entries in all domains. When an application such as Microsoft Exchange needs to search across the entire organizational namespace, it searches the GC rather than all the individual domains.

Another factor to consider is the amount of update traffic that your servers must handle. If your directory is contained in a single partition, that partition must handle all of the update traffic. Depending on your software, this requirement may cause performance to degrade unacceptably. By partitioning your directory, you reduce the number of entries contained within each directory partition and therefore reduce the amount of update traffic that any given server must handle.

You may also want to partition your directory if your physical network topology includes many slower WAN links, and partitioning the directory enables you to place a partition close to the applications and users that use the data in that partition. For example, if you're using a network operating system (NOS) directory like Active Directory or Novell's eDirectory, it often makes sense to construct a namespace that reflects the physical WAN structure of the company and assign partitions to servers in each location. When users log in to the NOS, their credentials are checked against the directory, and login preferences and scripts are retrieved. If the directory partition holding a user 's entry is assigned to a server located close by, traffic does not need to span a WAN link, and therefore performance improves .

On the other hand, if your organization's network is well connected ”perhaps if all links are T1 or faster ”there isn't much to be gained from this type of approach. These are only general guidelines; examine your network layout and application needs carefully to choose the design that will work best for you. Your directory server software probably comes with a planning and deployment guide that will give you specific advice.

Finally, if you know that your directory will expand significantly in the future and exceed one of the limitations, it may be best to partition the directory sufficiently to accommodate the growth without having to redesign your partitioning scheme. Although it is certainly possible to split and combine partitions, this is generally a time-consuming task. Avoid it if you can.

Following is a summary of the factors to consider when you're deciding whether to partition your directory:

Factors favoring a directory with a larger number of partitions:

- The number of entries is too great for a single partition or server.

- Your directory-enabled applications tend to read and modify entries from only the local workgroup.

- The amount of update traffic to a single partition is too large.

- Partitioning allows data and update traffic to remain local and avoid spanning WAN links.

- Directory use will expand significantly in the future, beyond the point where a single partition is feasible .

Factors favoring a directory with a smaller number of partitions:

- All the directory entries fit easily within a single partition and server.

- Your directory-enabled applications tend to read and modify entries across the whole enterprise.

- Few updates are generated by clients .

- The entire organization is centrally located on a single high-speed network.

- Directory size will remain fairly static, or you know that it will not exceed the capabilities of your software.

We will discuss these partitioning issues in more detail when we look at a sample design later in this chapter.