When you partition eDirectory, you allow parts of the database to exist on several servers. With this capability, you can optimize network use by distributing the eDirectory data processing and storage load over multiple servers on the network. By default, a single partition is created. For more information on partitions, refer to Partitions. For information on creating partitions, refer to Section 6.0, Managing Partitions and Replicas.
The following are guidelines for most networks. However, depending on the specific configuration, hardware, and traffic throughput of the network, you might need to adjust some guidelines to fit your needs.
Just as you design your tree with a pyramid design, you will also partition with a pyramid design. Your partition structure will have few partitions at the top of the tree and more partitions as you move toward the bottom. Such a design creates fewer subordinate references than an eDirectory tree structure that has more partitions at the top than at the bottom.
This pyramid design can be achieved if you always create the partitions relatively close to the leaf objects, particularly the users.
NOTE:An exception is the partition created at the root of the tree during installation.
When designing the partitions for the upper layers, keep the following in mind:
Partition the top of the tree based on the WAN infrastructure. Place fewer partitions at the top of the tree with more at the bottom.
You can create containers for each site separated by WAN links (placing each Server object in its local container), then create a partition for each site.
In a network with WAN links, partitions should not span multiple locations.
This design ensures that replication traffic between different sites is not unnecessarily consuming WAN bandwidth.
Partition locally around the servers. Keep physically distant servers in separate partitions.
For more information on managing your WAN traffic, see Section 14.0, WAN Traffic Manager.
When designing the partitions for the lower layers of the eDirectory tree, keep the following in mind:
Define lower-layer partitions by organizational divisions, departments, and workgroups, and their associated resources.
Partition so that all objects in each partition are at a single location. This ensures that updates to eDirectory can occur on a local server.
With eDirectory, we recommend the following design limits for partition sizes:
|
Element |
Limit |
|---|---|
|
Partition Size |
Unlimited Objects Replica Directory Information Base (DIB) limited to ITB |
|
Total number of partitions in tree |
Unlimited |
|
Number of child partitions per parent |
150 |
|
Number of replicas per partition |
50 Limited by replica DIB |
|
Number of replicas per replica server |
250 |
This change in design guidelines from NDS® 6 and 7 is due to architectural changes in NDS 8. These recommendations apply to distributed environments such as corporate enterprises. These recommendations might not subsequently apply to e-business or applications.
Although typical e-business users require that all the data be stored on a single server, eDirectory provides filtered replicas that can contain a subset of objects and attributes from different areas of the tree. This allows for the same e-business needs without storing all the data on the server. For more information, see Filtered Replicas.
Consider the following network variables and their limitations when planning your partitions:
The number and speed of servers
The speed of network infrastructure (such as network adapters, hubs, and routers)
The amount of network traffic