|< Day Day Up >|| |
The previous section explained how to put the entries together to build the directory tree. In the planning phase, you may only have a rough idea of how many of these entries your directory is going to hold, and this number can be considerable. If it is too high, performance will suffer. The remedy is to distribute the data on more than one directory server, and that is what this section is about.
As mentioned previously, the partitioning design is closely related to replication design. Furthermore, both partitioning and replication can modify the decisions you made in designing the directory tree. Arguments that let you decide to partition or replicate the directory are nearly the same. Another point that is related to partitioning and replication is physical design, but this is beyond the scope of this chapter.
As we have seen in Chapter 5, partitioning is the division of your directory into more parts, while replication copies a part or all of the directory onto one or more other servers. These parts can be on the same machine or on different computers on your network. Partitioning of the directory has several goals:
Scalability: Directories can contain a few thousand entries or several million. The ability to distribute the entries over several servers provides a greater degree of scalability.
Load balancing: Distributing the entries over several servers prevents overloads on the server as well as the network.
Local management: Moving the entries to the local networks where the entries are maintained reduces network traffic and enhances performance of the local directory.
Partitioning of the directory is called for when:
Number of entries is too high
Network traffic to the directory is too high
Not all of the data is equally used
Some line segments become overloaded
If the database gets too big to be held within a single partition, you should divide it. You may wonder, "What is 'too big'?" First you have the computer, where the disk space is one limiting factor. Another limiting factor is the directory server. See the documentation delivered with your software about the upper limit of entries your server can hold. Another limitation is backup time. When it takes ten hours to back up your system and only 1 kB of data has changed, it may be worthwhile to consider partitioning the database.
Even if both the hardware and the server can handle the amount of data, the traffic caused by the directory can penalize the part of the network where your directory server is installed. Depending on the access frequency of the individual parts, dividing the data over two subnetworks could help to increase network performance.
Your directory may contain data that is used frequently by one application and infrequently by another. Partitioning of the directory may enable you to put the frequently used data on a directory server that is closer to the application that uses the data. Backup time is another consideration. Separating static data from data that is updated frequently could save you backup time, because you will reduce the frequency of backups for the nearly static data.
If your company has a high-speed network distributed throughout the enterprise, overloaded line segments will not be an issue for you. However, not everyone is so lucky. Consider the case of an international enterprise having offices in the United States, the United Kingdom, and Germany, with each office maintaining its personnel records in a central directory. Assume that the connection between two of these nodes is not a high-speed connection or, even worse, is a dial-up connection available only a few hours a day. In such cases, it may convenient to partition the directory and create a separate directory for each office.
As mentioned earlier, partitioning design and tree design are not independent design phases. You can partition the directory only at branch points, which means that you can only move entire subtrees to new partitions from the main directory. See Exhibit 6 for an example of valid partitions. The accounting subtree and the human resources subtree are split up from the original partition, and two new partitions are created. Exhibit 7 instead is an example of invalid partitioning. You cannot put the accounting branch point in a separate partition because "accounting" no longer contains the subtree people and, therefore, there is a hole between people and ldap_abc.
Exhibit 6: Organization of ldap_abc with Two Partitions, One for Human Resources and One for Accounting
Exhibit 7: Example of an Invalid Partition
|< Day Day Up >|| |