eDirectory Synchronization and Background Processes
Articles and Tips: article
Senior Research Engineer
Novell AppNotes
kburnett@novell.com
01 Nov 2002
This month I want to switch gears from covering a focused directory subject and look at eDirectory from a much more broad view, even a [Root] view, if you will excuse the pun. There are several things that make eDirectory 8.x the premier directory service. Of course, components like Partitioning, Replication, Synchronization, an extensible Schema and Background Processes that you typically don't have to worry about are only scratching the surface.
Object Synchronization
Novell's eDirectory has a very slick and efficient synchronization engine that takes care of the following features:
Convergence, which is the act of making an object consistent among all instances of that object.
Hierarchy, which is a graded series of objects in which each element may contain other objects.
Replication Styles, offered are Single Instance, Master-Slave, Multi-Master, and Hybrids.
Replication Methods, None, Copy and Replace, Change Log, State Based and Hybrids.
Note: Of the above features, eDirectory uses Multi-Master/Slave Hybrid and State-Based the most.
In addition, eDirectory utilizes the following features in the synchronization process:
Replica Types: Master, Read/Write, Read Only and Filtered.
Replica Ring: The set of eDirectory agents that hold a replica of a given partition and, therefore, participate in the synchronization of objects contained with that partition.
Deltas: The time differences between copies of a given object.
Change Cache: The collection of objects with deltas for a given replica.
Transitive Synchronization: A method for providing convergence of data without requiring an eDirectory agent with changes (i.e. state based deltas) to directly contact and synchronize those changes with every other agent in the replica ring.
eDirectory includes the following Partition Root Object Attributes:
Replica--A synchronizing multi-value attribute, where each attribute value represents an eDirectory agent that is participating in replication of this partition and how it can be contacted.
Transitive Vector--A synchronizing multi-valued attribute, where each attribute value represents the state in time that the specified eDirectory agent has received changes up to.
Local Received Up To--A non-synchronizing single-valued attribute whose value represents the current state in time that the local eDirecotry agent has received changes up to.
Purge Vector--A non-synchronizing single-valued attribute whose value represents the oldest state in time that has been seen by each eDirectory agent in the replica ring. Users the Transitive Vector to find out the oldest state that is seen by all the agents in the ring for each replica in the ring.
Local Received Up To (LRUT)
eDirectory uses LRUTs to keep track of what changes have been received from other replicas in the network. LRUTs are also used to inform inbounding replicas of t the current synchronization state and to advertise the local state when the agent is ready to do an outbound synchronization.
Once the changes are ready for outbound synchronization, the following occurs:
Read the last TimeStamp issued on the local replica from the partition record
Update the row in the Local Received Up To corresponding to the local replica number
Update the Transitive Vector value corresponding to the local agent ("server")
The updated data is then sent out to all of the other servers.
Synchronization Improvements
eDirectory 8.6 and greater includes improvements to the synchronizing process.
Incremental Replication Changed--All changes for the entire state difference between replicas of a given partition are still required, but a progress marker (which is a synchronization point) is kept so that work is not lost and redone in the event of an error (usually in communication) during a synchronization cycle.
Multi-Threaded Outbound--The outbounding eDirectory agent can update more than one agent for more than one partition at a time.
Reduced Chattiness--Communication of the Transitive Vector between replicas is no longer delayed until each replica's outbound synchronization cycle. The destination replica's Transitive Vectors are exchanged with the source replica at the end of a replication cycle.
More Effective Object Analysis--Improved handling of large multi-valued attributes for both inbound and outbound.
External Reference Synchronization
An External Reference is a name that needs to be tracked by the local Directory Information Base (DIB). It may contain a partial cache of attributes from the real object and/or results of local operations. External references are typically created when one of the following occurs:
Authentication
It is referenced by another eDirectory object
File rights or another Operating System (OS) dependency
eDirectory itself has a dependency
Normally External References are maintained by a Reference Check Process, such as the Backlinker or DRL processor. On real replicas, this process maintains User, Used By, and Back Link attributes.
So what is actually maintained? That depends on the object and the version of eDirectory. The base class, name, and certain attributes are all maintained. Some examples of maintained attributes include Public Key and GUID for User objects, Replica for Partition Root objects, and Status and NDS Version for NCP objects.
So Why Should I Care About External References?
Here are a few reasons you might want to care about External References:
If you have a lot of external references from one partition, you may want to consider placing a replica of that partition on another server.
They must be maintained properly for those subsystems that are dependant on them.
They effect the amount and types of communication that is required between eDirectory agents.
Referential Integrity.
You can usually tell if there is a problem with External References by using NDS iMonitor and looking at the Agent Process Status.
Obituary Synchronization
In eDirectory, an Obituary is used to ensure referential integrity during operations, such as delete, move, rename, and the like. The most common types of Obituaries are two fold:
Primary, which can be Dead, Restored, Moved, Inhibit Move or New Relative Distinguished Name (RDN)
Secondary, which can be Back Link or Used By
So, how are Obituaries processed by eDirectory? The Obituary process is one of the eDirectory processes that uses the Purge Vector. It is not manually schedule-able; it is automatically scheduled at the end of an inbound synchronization cycle for the just synchronized partition.
Obituaries are moved through a series of states (i.e. Notified, OK to Purge, Purgable, etc.) before they are purged from the system. This is done to ensure that all interested parties are notified and can make the proper adjustments and modifications. For backlink obituaries, the Master replica is responsible for moving the obituary through the state transitions; for used obituaries, it is the replica which created it. If that replica no longer exists, then the Master Replica will take ownership.
Obituaries are synchronized as they move through their various states. Using the Obituary Index, those changes are synchronized to agents holding a replica of the effected objects. You are able to tell if you have obituary problems on your network by using NDS iMonitor, Agent Process Status and Obituary Report options.
Schema Synchronization
The eDirectory schema resides on all agents (servers) in the network. Each agent has a copy that will be a cached copy and it is not modifiable unless the agent also holds a writeable copy of the tree root partition.
The schema propagates through the schema synchronization process, sideways and down, never upwards on the directory tree. This is based on replica depth. Replica depth is the replica with the fewest number of containers held by a given agent.NDS iMonitor, Server Information Report option, shows replica depth for all agents.
So what happens to the schema when the first replica is added to an agent? The agent resets the schema and adds itself to a poll list in order to receive a new copy of the schema. This operation must complete before the replica can proceed with synchronization. If there are problems present on the network, you will be able to tell by using NDS iMonitor, Agent Process Status option along with the Schema Browse and Schema Root Browse options.
Agent Configuration Synchronization
Not every agent in an eDirectory environment will hold a copy of its own NetWare Core Protocol (NCP) server object. This object contains information that is needed to control the agent's behavior. In order to have this information available and to reduce network bandwidth, a local partial cache of the NCP Server object is maintained. Also, the Agent Configuration Synchronization process updates the NCP Server object with changes that occur on the local agent (i.e. Network Address, NCP Sever Name, etc.).
The Agent Configuration is stored on the Pseudo Server, which is maintained by eDirectory. Every agent has its own copy of this object in which to store its own agent configuration, regardless of whether or not it holds any replicas.
Limber Process
Limber is the process that performs Agent Configuration Synchronization. Limber (also referred to as Connectivity Check) may trigger other processes to refresh their configuration (i.e. LDAP, etc.) Limber is scheduled to run every 4 hours by default, which is configurable in NDS iMonitor. It will also run when requested or when a change is noticed that needs to be synchronized.
This process maintains data such as the Network Address, Index Definitions, the NCP Server's RDN and location in the tree, the Tree Name, and Permanent Configuration Parameters. You can tell if you are having this type of problem in your network by using NDS iMonitor, the Agent Process Status and Pseudo Server Browse functionality (eDirectory 8.6 or greater).
Additional Background Processes
The following explains a few of the background processes that eDirectory relies on to run quickly and efficiently:
Janitor: The janitor process checks for synthetic time, updates inherited ACL's, updates known NCP server status and version, purges unneeded bindery entries, purges expired temporary agent configuration parameters.
Purger: Using the Change Cache together with the Purge Vector for each replica held, the Purger process removes values and entries that are no longer needed in the system because their removal has been seen by all replicas.
eDirectory Background Processes can be monitored in NDS iMonitor using the Background Process Schedule option.
Conclusion
This month we have looked at how some of the deeper eDirectory synchronizing and background processes work and what they are. Next month we'll begin a discussion of NDS iMonitor.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.