| Windows Server Troubleshooting - Replication |
|
|
|
|
|
NT Domain AD Multimaster Replication To provide better fault tolerance, the Active Directory supports multimaster replication. With multimaster replication, any domain controller can accept updates. All updates must then be replicated to all other domain controllers to try to achieve a consistent database. When network links and servers go down, the consistency between the distributed database cannot be guaranteed at any point in time. Because of this situation, the Active Directory is said to be loosely consistent. The Active Directory is designed to cope with loose consistency by continuously trying to get the databases to converge. Eventually updates will replicate to all Domain Controllers and then the Active Directory has convergence. If every server had to replicate changes to every other server, there would be an excessive number of server connections. To simplify the replication topology and to reduce the network traffic, the Active Directory uses a store-and-forward replication model as shown in the following diagram.
The store-and-forward model has a reduced number of replication partners with whom domain controllers exchange information. Each domain controller stores three NC naming contexts, schema, configuration, and domain, each of which is replicated separately.
A service called the KCC Knowledge Consistency Checker determines which servers are replication partners. It starts by forming a replication ring and then adds connections that divide the ring until there is no more that 3 hops between servers. In the following diagram, 3 connections must be added to divide the 10-server ring to ensure no more than 3 hops.
Update Sequence Numbers Any change to any object attribute in the Active Directory must be replicated to all other domain controllers. To keep track of changes, every attribute update is assigned a 64-bit sequence number called the USN update sequence number. The following diagram is a simplified view of his this works and shows how each attribute update is assigned a simple update sequence number.
In the following example, if Server2 is a new domain controller then all attributes from Server1 are replicated to Server2. Server2 maintains its own independent USN update sequence numbers. Server2 must record the highest USN from Server1. This highest USN is know as the high-watermark vector. The next time replication occurs, only attributes with a higher USN need be copied
Domain Controllers must also record for every attribute update,
To understand how the USN is used to notify domain controller replication partners, consider the following example. The diagram shows the state of the attribute updates before and after a replication cycle. The italics text represents the new information after the replication cycle. Initially, Server1 is updated to USN 1241. Its replication partners Server2 and Server3 have a high-watermark for Server1 of 1238 and 1240 respectively, set from the previous replication cycle. Only attribute updates with a USN higher than the high-watermark need to be replicated and are represented by the text in italics with the gray background. After the replication cycle, both servers will update their high-watermark to Server1's USN of 1241. When attribute changes occur, domain controllers delay the notification of replication partners for 5 minutes in an attempt to accumulate multiple changes. Sending multiple changes together will result in less network traffic than sending each update separately.
If a domain controller is offline for an extended period of time, its high-watermark vectors will not be updated. When it does come back online, it will then receive all updates without any loss of information. Up-to-dateness Vector Although we see that changes get replicated even when servers fail, we do not yet have the complete story of how replication works. Based on what has been described above, there is a problem if Server2 and Server3 replicate to each other. Because their USNs have now increased, they would replicated these changes to each other. But Server2 and Server3 already got these changes from Server1. They would also try to replicate these changes back to Server1. Server1's USN would increase again and it would replicate these same changes back to Server2 and Server3, thus creating a vicious replication loop. To prevent this, the domain controllers need to have another mechanism to represent how up-to-date they are with the source of the attribute updates. The Active Directory has an up-to-dateness vector to record the highest USN for updates that originate from each domain controller and have been received. The following table provides a summary.
The up-to-dateness vector prevents changes from replicating when they have already been received from a different source. The up-to-dateness vector ensures that a domain controller knows how up to date it is with changes that originated on a particular domain controller.
Resolving Conflicts What happens if the same attribute is changed independently on two different domain controllers? The conflict needs to be resolved as the change replicates between the domain controllers. In the end the attribute change must converge to a consistent value. For each attribute, the Active Directory stores its value, but also
Conflicts are resolved by examining this additional information in the following sequence. Normally the last value that is written is used.
There is a problem to resolve in the case of an object being added or moved to a container on one domain controller and that same container is deleted on another domain controller. In such cases, the objects are placed in the LostAndFound container.
Another problem occurs if objects are added to two different domain controllers with the same object name. In this case, the first added object keeps its name, but the second object gets a name in the format RDN*CNF:<GUID> where <GUID> is the globally unique identifying number for the object which is guaranteed to be unique. RDN stands for Relative Distinguished Name, CNF stand for Conflict, and * is a reserved character.
REPADMIN /SHOWMETA To see the USNs, originating time, and version numbers for each attribute, use the REPADMIN command as shown below. C:\>repadmin /showmeta cn=administrator,cn=users,dc=newdomain,dc=com | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
ï
è
Add
user to container
Delete container
