Novell Home

Tree Architecture Design

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 12 Oct 2005
 

Note: This summary article is adapted from BrainShare presentation DL 155.

Overview

eDirectory performance is largely dependent on the Tree design. The important consideration is to balance eDirectory manageability with eDirectory performance. The number of objects per partition directly impacts repair and recovery times. Also, LDAP operations are adversely impacted by the depth and scope of the Tree.

You will need to customize the database schema for your specific needs. Be careful with the use of passwords - for example, encrypted passwords are more expensive than simple passwords in the NDS Login Properties Class.

Traditional Trees

A traditional tree design is shown below.

Figure 1 - Traditional tree design

The tree is primarily an organization of your physical network resources. Here are some guidelines to keep in mind as you design your tree:

  • Design the top of the tree to mirror your WAN infrastructure.
  • Design the bottom of the tree to mirror sites, divisions, departments, and workgroups.
  • Place your network's physical resources close to the users who need them.
  • Partition top of the tree based on the WAN infrastructure.
  • Do NOT create a partition that spans the WAN (split across a WAN link).

  • Partition around the local servers in each geographic area.
  • Partition the top of the tree based on its size (1000 - 100,000's of users).
  • Keep the Tree as flat as possible.
  • When dealing with millions of users, do not try to excessively organize.
  • Use O and OU objects as access containers for both security and ease of middleware design.
  • Be frugal with the use of ACLs and more reliant on the use of attributes.
  • Partition Organizational Units (OU) into 2 Million objects or fewer.
  • Use partitions more for manageability instead of geographic locations of replicas (although geographic locations may still be relevant). This can shorten DSRepair times.

Below is a sample Identity Management tree with 50 managed partitions and up to 10 million users:

Figure 2 - Sample Identity Management tree

LDAP Search Scopes

There are three LDAP search scopes:

  • Base (the fastest)
  • One-Level
  • Sub-Tree

Figure 3 - Types of LDAP search scopes

Most One-Level and Sub-Tree searches are performed for disambiguation purposes. If disambiguation can take place before the LDAP search, then a Base search is all that is needed. Note: Base searches are ideal for speed.

Disambiguation

There are several methods of disambiguation:

  • One-Level or Sub-Tree Searches - on a Full Tree or a Filtered Replica
  • Functional Containment - on Customers, Devices, Profiles, Services, etc.
  • Object ID Hashing - Hash the Object ID to determine where the Object is placed in the Tree

Below is an example of Filtered Replica Searching.

Figure 4 - Filtered replica searching

Here is an example of what a Functional Containment Tree would look like:

Figure 5 - Functional containment tree

eDirectory Object Hashing

Another way to disambiguate for Base LDAP searches is to hash the object to calculate the fully qualified DN. For example, take the Modulus of the UserID using a binary number (ie 2, 4, 8, 16, 32, ...). Then, the {ObjectID #} % {# of containers} = container number where the user will be placed.

Figure 6 - Calculating fully qualified DN's from hashing method

Here is an example of what a Hashed Tree would look like:

Figure 7 - Hashed tree example

Horizontal Scaling

Horizontal scalability is a differentiating strength of eDirectory. With horizontal scaling you can run many Read/Write Replicas. Horizontally scaling an eDirectory LDAP Tree is advised in environments where load and throughput is more important than transaction response time. Customer Portals and LDAP enabled applications are likely candidates for multi-server horizontal scaling.

Due to the increased replication traffic, there are diminishing returns in performance scaling as more Read/Write Replicas are added to a Replica Ring.

Below is an example of horizontal scaling.

Figure 8 - Horizontal scaling

Replica Domains

To achieve near-linear horizontal scaling, use Replica Domains. Replica Domains are advised when low latency is required in conjunction with large load and search scopes. Time-critical systems, such as those found with Telecoms, are strongly encouraged to use Replica Domains.

Replica Domains increase the hardware requirements of an eDirectory LDAP environment. Using Replica Domains requires disambiguating the objectID before an LDAP operation is made.

Here is a Replica Domains scaling example.

Figure 9 - Replica domains scaling

Below is an illustration of how Replica Domains function with a sample tree.

Figure 10 - Replica Domains Illustration

Other Considerations

Here are some additional things to consider as you design your tree:

  • Myth - Keep the first 8 characters of the ObjectID unique for Indexing purposes. Fact - Index creation algorithms use the first 128 bytes of text and the first 24 bytes of binary for index creation.
  • Be careful with the use of References. eDirectory's inherent Referential Integrity capabilities can become troublesome in large tree designs if not carefully designed. If Referential Integrity must be used, use few-to-few versus many-to-few or many-to-many (ie group memberships).
  • Remember to customize the Schema to fit your needs.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell