eDirectory Design Notes
For networks with fewer than 2000 objects consider the basic tree structure – in this environments you may not need to use advanced features like partitioning; eDirectory will be able to take care of itself with its default settings.
Some legitimate service orientated tree designs, which are now becoming common, include:
- eCommerce/LDAP (typically very flat)
- Workforce tree
- Multiple tree
Partitioning & Replication
Partition design guidelines changes with eDirectory 8.7
- trees can store an unlimited number of objects
- partitions can contain an unlimited number of objects
- the number of child partitions, including subordinate references, is unlimited
- you can have an unlimited number of replicas (always have 2 or 3)
- a non-dedicated replica server can hold 50 replicas
- a dedicated replica server can hold 150-200 replicas
- All partition begin with a single container object that is the highest point in the partition’s hierarchical tree, which is a subtree of eDirectory.
- All partitions must contain a connected subtree.
- All non-container objects must exist in the same partition as their parent object.
- All container objects not designated as partitions must exist in the same partition as their parent object.
- A partition cannot overlap another partition.
- The name of a partition is the fully qualified, distinguished name of the partition root object.
Replica Filters are managed through the server object. Each server can have only one filter which applies to all the replicas it holds. NDS eDirectory 8.5 (build version 85.xx) was the first eDirectory version to implement Filtered Replicas.
- refer to objects not physically located on the local server (called external objects).
- provide the server with an ID for the operating system.
- provide tree connectivity.
- Allow attributes of external objects to be cached to improve performance
External references only hold a few of the attributes of the real objects and external references now receive replica pointers to improve tree walking efficiency.
Providing Tree connectivity - external references also effectively provide the missing links between replicas on the server and the [Root]. Allowing names to be resolved fully.
The following operations create external references:
When a user authenticates to a server which doesn’t have an entry in a partition on that server.
When a browsing user requests an entry not stored locally.
A user authenticating who has a security equivalence to an entry not stored locally.
Attributes of Local Entries
Some attributes, such as Member, take a list of entries and can have entries for objects that are not stored locally.
The file system uses entry IDs to maintain a list of owners and trustees of files and directories. Trustees or owners that are not local require external references.
By default eDirectory builds a list of unused external references, ready to be deleted, every 8 days and 30 minutes (but this can be altered).
The real object relating to each and every external reference has a back link attribute which points to the external reference, maintaining a link between the two to allow eDirectory to update external references when the real object is renamed or deleted.
The back link process runs 2 hours after the eDirectory database has open and every 780 minutes thereafter (but this can be altered). This process:
- verifies all external references and removed any expired or unnecessary external references
- verifies all backlink attributes, creating any back links eDirectory could not create when it created the external reference.
If a server receives a request it cannot satisfy it initiates a search for a server that can fulfill it. Until a relevant partition is found, the search proceeds toward the eDirectory [Root], since any request can be pursued successfully by beginning at the [Root]. If it can find no other information, it can at least provide the name server that has a partition with information about objects that are closer to the [Root] than itself. During the tree-walking process, when the server discovers information about how to get closer to the desired partition and server, this information is sent back to the server that sent the request – this progress report is called a referral. The referral provides the requesting server with a new list of name servers to try if the name server cannot satisfy a request. Referals contain:
- Server List – a list of name servers.
- Class Definition Cache – holds the expanded class definition of each eDirectory class
This tree walking process relies upon subordinate references to connect the tree. The subordinate reference is an entry in a superior.
Design Project Roles
Helps move the team through the process by maintaining the project’s focus and schedule, and by maintaining contact with others in the organization.
- Makes final decisions
- Acquires resources and funding
- Manages costs and time estimates
- Oversees the design and implementation phases of the project
- Identifies training needs in order to maintain standards in the new eDirectory tree
- Educates the organization on the changes and effects of the new design
Designs the logical structure of the tree. Has worked extensively with eDirectory or has completed specialised training relative to Netware and eDirectory. This role can be filled by an outside consultant.
- Acts as team leader
- Creates the tree design
- Maintains eDirectory design standards
- Designs eDirectory security
- Formulates a strategy for partitioning and replication
- Maintains a list of applications, resources, printers, etc.
- Communicates with management and departments to determine needs
- Documents the tree design and standards
Works daily with server administration and designs the physical network structure.
- Maintains network performance levels
- Ensures implementation of a logical time synchronization strategy
- Determines hardware requirements
- Plans server placement in the tree
- Determines how to remove and add servers
- Determines backward compatibility
- Combines tree design with the organization’s disaster recovery strategy
Works with he physical network, managing the internetwork backbone, telecommunications, WAN design, and router placement.
- Makes decisions regarding the use of single or multiple protocols on the network
- Makes sure Internet, directories, and disparate operating systems are interoperable
- Makes sure the network design delivers optimal internetwork traffic throughout
- Advises the planning team about routing, protocols, and WAN structure
- Assists overall eDirectory design in regards to WAN traffic
- Determines the effect of routing, protocols, telecommunications, or WAN structure on the eDirectory tree design
- Polling users and network personnel affected by the design
- Gathering business information related to network design
- Determining the scope of the design process
- Creating a preliminary schedule
- Gathering information about the applications you are using
- Designing the eDirectory Tree Structure
- Planning the User Environment
- Determining a Partition and Replica Strategy
- Planning a Time Synchronization Strategy
- Implementing an eDirectory Design
- Analysis of Current eDirectory Design
Before an eDirectory design can be begun information must be gathered about the company. A company profile is needed, including information about the nature of the company, its organizational and physical structure and the networks structure (with particular attention to any WAN links). The information will include data on the users and the resources they access. Key source documents might include a network diagram, organization diagram and company profile, the physical structure of the company (offices, locations of servers, users and resources). An indication of predicted future development.
Design Tree Structure
Identify Fundamental Directory Design Factors
- Network Layout
- Organizational Structure
- Speed and Efficiency
- Fault Tolerance
- Scalability and Operability
- Ongoing eDirectory Design
Naming Standards Documents
Object Naming Standards
- List each type of object used in the eDirectory tree
- Specify the standard you will use for each object type
- Provide a brief example for each object type used
- Specify the rationale for each object type selected
Object Attribute Standards
- Required attributes
- Optional attributes you want network administrators to define when creating an object
- Attributes that are populated automatically via a template object in eDirectory