4.6 Synchronization

Synchronization is the process of ensuring that all changes to a particular partition are made to every replica of that partition. The X.500 standard defines two synchronization mechanisms:

The master-to-slave mechanism requires that all changes be made on the master replica. That replica is then responsible to update all the other replicas (slave replicas).

In a peer-to-peer synchronization system, updates can be made to any read-write or master replica. At a predetermined interval, all servers holding copies of the same partition communicate with each other to determine who holds the latest information for each object. The servers update their replicas with the latest information for each replica.

eDirectory uses both the master-to-slave and peer-to-peer synchronization processes, depending upon the type of change being made. Most operations use peer-to-peer synchronization. The biggest exceptions are the partition operations which require a single point of control. In NetWare 4.x, the server with the master partition communicates with all other servers in the replica ring and controls the updates for partition operations. In NetWare 5.x, the master-to-slave mechanism has been slightly modified for partition operations. The server with the master replicas isn't responsible for updating all replicas. This server is responsible for updating its own replica and one other replica. The other replicas in the ring are updated peer-to-peer.

In eDirectory, the synchronization time interval ranges from between 10 seconds to 25 hours depending upon the type of information updated.

To understand the eDirectory synchronization processes, you should be familiar with the following eDirectory features:

eDirectory has a number of synchronization processes. From a user's view point, the most important one is Replica Synchronization which keeps the object information synchronized across all replicas. The others are Background Processes that update eDirectory information that is mostly hidden from the user but required to ensure the efficient distribution and replication of eDirectory.

4.6.1 Loose Consistency

Because the eDirectory database must synchronize replicas, not all replicas hold the latest changes at any given time. This concept is referred to as loose consistency (called transient consistency in the X.500 standard), which simply means that the partition replicas are not instantaneously updated. In other words, as long as the database is being updated, the eDirectory database is not guaranteed to be completely synchronized at any instance in time. However, during periods in which the database is not updated, it will completely synchronize.

Loose consistency has the advantage of allowing eDirectory servers to be connected to the network with different types of media. For example, you could connect one portion of your company's network to another by using a satellite link. Data traveling over a satellite link experiences transmission delays, so any update to the database on one side of the satellite link is delayed in reaching the database on the other side of the satellite link. However, because the database is loosely consistent, these transmission delays do not interfere with the normal operation of the network. The new information arrives over the satellite link and is propagated through the network at the next synchronization interval.

Another advantage to loose consistency is that if part of the network is down, the changes will synchronize to available servers. When the problem is resolved, the replicas on the affected servers will receive updates.

eDirectory is a loosely synchronized database. Because of the time required to synchronize different servers, eDirectory does not guarantee that a particular piece of information on a particular replica has the most current value. If a client agent were to request the same information from two replicas, there is a chance that the results may differ. This happens when an update is made in one replica and the client agent reads from another replica before the update is synchronized.

Loose synchronization allows eDirectory to reduce the overhead required to maintain a partition. eDirectory is designed to support frequent reads and infrequent writes. In light of this, clients are discouraged from storing values in eDirectory that change frequently.

4.6.2 Time Stamps

One critical component in synchronization is the time stamp, which records information about when and where a given value in a given attribute was modified. When eDirectory updates a replica, it sends a modification time stamp with the data to be updated. The replica compares time stamps and replaces the old information with the new.

4.6.3 Partition Information

For normal operations, including synchronization, to be successful, the partition root object on each server must store several important attributes and their values:

  • Replica Pointers. The local server stores a pointer to the remote servers that contain a replica of this partition. This pointer structure contains, among other things, the server's ID, address, and the type of replica stored on the server.

  • Partition Control Attribute. The local server uses this attribute to track the progress of operations such as splitting and joining partitions and repairing time stamps.

  • Partition Status Attribute. The local server uses this attribute to store information about the success of the last synchronization cycle.

  • Synchronized Up To Attribute. NetWare 4.x servers use this attribute to store a time stamp that indicates the last update the local replica received from each remote replica.

  • Transitive Vector Attribute. NetWare 5.x servers use this attribute to store information about each replica in the ring, and the attribute includes a modification time stamp.

4.6.4 Replica Synchronization

Replica synchronization refers to the process of copying data among the replicas of a partition. A partition is synchronized if all of its replicas contain the same information. If one replica has a more current version of a piece of data than the other replicas, it propagates this data to the other replicas. The act of performing synchronization of the replicas of a partition is called the convergence of the replicas. The time between scheduled synchronization is called the synchronization interval.

All replicas belonging to a given partition set must be synchronized to include all updates generated to writable copies of the partition set (master and secondaries). This task is the responsibility of the replica synchronization process.

When a name server receives an update, it schedules the replica synchronization process to begin in 10 seconds. If the synchronization fails, then the replica synchronization process reschedules the event.

The replica synchronization process is responsible for the following maintenance operations:

  • Accepting updates from other replica synchronization processes and applying them to the relevant local replicas.
  • Maintaining consistency of the eDirectory tree by performing periodic checks on the links in the tree.
  • Maintaining the validity of external references found on the local server.
  • Summarizing access control information for each local partition.

The consistency or convergence of the eDirectory replicas is directly related to the frequency with which the replica synchronization processes operate. Administrators can control the frequency of the replica synchronization according to the needs of their system by adjusting the synchronization interval.

Because an eDirectory partition can be replicated and distributed across a network, any changes made to one replica must be sent to, or synchronized with, the other replicas.

eDirectory uses two timers to synchronize changes to replicas:

  • Convergence attribute-some changes, such as a change in a user's password or access rights, need to be sent immediately to another replica. When these high convergence attributes are modified, the replica synchronization process is scheduled with the fast synchronization interval of 10 seconds.
  • Heartbeat-less critical changes, such as a user's last login time, can be collected locally for a short period of time before being sent to other replicas. The heartbeat triggers a scheduled synchronization at least every thirty minutes. The network administrator can adjust the trigger's time interval with the use of the DSTrace console SET command. eDirectory adjusts the time if it must respond to expiring time outs.

eDirectory uses both a send and receive sync process:

  • In bound sync process—receives updates from other replicas. DSTrace commands can turn this process off for a specified interval.
  • Out bound sync process—discovers which replicas need updates and then sends the updates.DSTrace commands can turn this process off for a specified interval.

The out bound synchronization process checks the synchronization status of every server that has a replica of a given partition. Factors that determine whether synchronization is necessary include the replica's convergence attribute, its replica type, and the time that has elapsed since the replica was last synchronized or updated. The synchronization process in NetWare 4.x is slightly different than the transitive synchronization process used in NetWare 5.x.

4.6.5 NetWare 4.x Synchronization Process

In NetWare 4.x, the replica synchronization contacts each of the replicas of the partition one by one. After the processing for a replica has been completed, or if it fails, the replica synchronization process tries to process the next replica in the replica list until attempts to update all replicas have been made. It is frequently possible that the replica synchronization process may not be able to update all the replicas in one attempt. If the server holding a replica is currently unavailable, an attempt to update this replica fails. The replica synchronization process, however, proceeds with attempts to update other replicas in the replica list. The replicas that are not updated in this replica synchronization process are attempted again.

When the replica synchronization process begins, it builds a list of replicas for the partition it is attempting to synchronize. The replica synchronization process then sends a StartUpdateReplica message to the server holding the replica that needs to be synchronized.

The receiving server responds with a vector of time stamps that indicate how current the replica is in relation to this partition. The replica synchronization process compares the local Received Up To attribute with the time stamp vector received. If the local Received Up To is more current than the received time stamp vector, the replica synchronization process sends the relevant changes to the receiver. The changes are sent in an UpdateReplica message.

After all the updates have been sent, the replica synchronization process sends an EndUpdateReplica message to the receiver, indicating that all the changes have been sent. If no changes need to be sent (which would be the case if the receiver is as current or more current than the local partition), the replica synchronization process sends an EndUpdateReplica indicating that no changes need to be sent. If the receiver fails to apply the changes, the synchronization is aborted for this replica. The replica synchronization process attempts to synchronize this replica at the next scheduled synchronization.

Once the processing of this replica has been completed, or it has failed, the replica synchronization process begins processing the next replica in the replica list. This procedure is repeated until all the replicas of the partition have been processed.

In NetWare 5.x, NDS uses transitive synchronization instead of replica synchronization if all the replicas in the replica list are stored on NetWare 5.x servers. If the replica list contains a mix of NetWare 4.x and NetWare 5.x servers, the replicas stored on NetWare 4.x servers are synchronized with the replica synchronization process.

4.6.6 Transitive Synchronization

In NetWare 4.x, the replica synchronization process requires that all servers in a replica list be able to communicate and synchronize with each server in the replica list. Each server must be able to query all the servers in the replica list, obtain their synchronization status, and send updates if the server is not synchronized. Transitive synchronization changes this procedure.

Transitive Vector Attribute. Transitive synchronization depends on the Transitive Vector attribute, which is stored as an attribute of the partition root object. The Transitive Vector is a multivalued attribute that stores the following information for each server in the replica ring:

  • The server’s Distinguished Name (or Entry ID on the local server)
  • A count of the replicas in the replica ring
  • The last modification time stamp received for each replica in the replica ring
  • A replica number for each replica in the replica ring

If the server stores two replicas (C and D) and Replica C has three servers in its replica ring and Replica D has two servers in its replica ring, the server will contain five Transitive Vector attributes, one for each replica. Each attribute will contain a value for each server in the ring; thus the attribute for Replica C has three values and the attribute for Replica D has two values.

Starting the Process. When a partition replica is modified on a given server, that server updates the modification time stamp for that replica in its local transitive vector. Then, the server checks its local Transitive Vector for each server in the replica ring. If any server in the Transitive Vector holds a time stamp older than the local time stamp, the local server initiates the synchronization process. Synchronization occurs only between servers that can communicate with each other.

For example, in the figure below, server S1’s copy of Replica #1 is modified and given a modification time stamp of 100. Server S1 then checks the local Transitive Vector for servers S2 and S3. Both of these hold time stamps of 12 for Replica #1, indicating that they must be synchronized. Assuming that server S1 can communicate with servers S2 and S3, server S1 initiates the synchronization process. If, however, server S1 is an IPX-only server and S3 is an IP-only server, server S1 would not initiate replica synchronization with server S3. Rather, server S3 would have to be synchronized with a server capable of using the IP protocol.

Figure 4-15 Modification Time Stamps

This procedure reduces synchronization traffic because a server does not have to query each server in the replica ring before synchronizing but checks the local Transitive Vector.

In addition, the procedure allows changes made on one replica to be synchronized to other replicas through intermediaries. This is a requirement with the introduction of IP support. For example, a server that supports only IP cannot communicate directly with a server that supports only IPX. The only requirement in a mixed IP and IPX replica list is that one server in the replica list must support both IP and IPX.