活动目录的复制之细节

转载自：http://teamapproach.ca/trouble/Replication.htmWindows Server Troubleshooting - Replication

Replicating directory information in Windows NT servers is simple because only the PDC Primary Domain Controller can accept updates and these updates are sent directly from the primary to the BDC Backup Domain Controllers. The problem with this simple scheme is that no updates can be accepted if the Primary Domain Controller fails.

NT Domain                                           AD Multimaster Replication
ïð                    óó
BDC            PDC          BCD                     DC              DC             DC
Only PDC accept updates                         Any DC can accept updates

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.

ó     ô õö ô         ÷ø ó Excessive connections

ÄÊ ÇÃ Store-and-Forward Replication

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.

 

	ó Domain1 NC		óó Domain2 NC	Domain3 NC
	All servers replicate the configuration and schema NCs

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.  

	óóó
ô    ô	ó	ô    ô
	óóó
	Replication Ring

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.

USN	Attribute
1238	AttributeQ
1237	AttributeX
1236	AttributeB
1234	AttributeZ
1234	AttributeN
...	...

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

Existing directory on Server1			New directory on Server2
USN	Attribute		USN	Attribute
1238	AttributeQ	Replicatedè	325	AttributeQ
1237	AttributeX		324	AttributeX
1236	AttributeB		323	AttributeB
1234	AttributeZ		322	AttributeZ
1234	AttributeN		321	AttributeN
...	...		...	...
			High-watermark for Server1 = 1238

Domain Controllers must also record for every attribute update,

• Is this an originating update that was made on this server? or
• Is this a replicated update and on which server did it originate?

USN	Attribute	Originated where?
9880	AttributeY	Replicated from Server2
9879	AttributeC	Replicated from Server3
9878	AttributeF	Originated here
9877	AttributeW	Replicated from Server2
9876	AttributeP	Originated here
...	...	...

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. 

 

Existing directory on Server1			Directory on Server2
USN	Attribute		USN	Attribute
1241	AttributeM	Replicatedè	325	AttributeM
1240	AttributeG		324	AttributeG
1239	AttributeV		323	AttributeV
1238	AttributeQ		325	AttributeQ
1237	AttributeX		324	AttributeX
...	...		...	...
		Replicated	High-watermark for Server1 = 1238
		î	High-watermark for Server1 = 1241

			Directory on Server3
			USN	Attribute
			9881	AttributeM
			9880	AttributeY
			9879	AttributeC
			9878	AttributeF
			9877	AttributeW
			...	...
			High-watermark for Server1 = 1240
			High-watermark for Server1 = 1241

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.

Vector	Description	For which DCs
High-watermark	Highest USN received from	Replication Partners
Up-to-dateness	Highest USN originating from	All DCs with same name context

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.

	Server1		Server2		My information with respect to Server1 is up-to-date to USN 1240 so only send me changes that originate at Server1 with a USN greater than 1240.
USN	Attribute		î
1241	AttributeM			Server4
1240	AttributeG	ì		__
1239	AttributeV	î	ì
1238	AttributeQ				Up-to-dateness of Server1 = 1240
1237	AttributeX
...	...		Server3

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

• an incrementing version number
• the time that the change was originated
• the server where the change originated

Attribute	Value	Version	Originating time	Originating server
	incremented

Conflicts are resolved by examining this additional information in the following sequence. Normally the last value that is written is used.

• the highest version number is used
• the latest originating time is used
• the originating server is identified by a GUID number, if the version and time are the same then the value of the GUID is arbitrarily used to break the tie.

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.

Server1	Server2
èAdd user to container	Delete container
To resolve the conflict AD stores the user 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.

	I want to be called Bob Added 09:30		I want to be called Bob Added 09:31
	The 1st object will be named Bob		The 2nd object will be named RDN*CNF:1234567890

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

33 entries.
Loc.USN Originating DC              Org.USN Org.Time/Date     Ver Attribute
======= ===============           ========= =============     === =========
 8194 Default-First-Site-Name\WIN2003  8194 2003-02-11 11:31:37 1 objectClass
 8194 Default-First-Site-Name\WIN2003  8194 2003-02-11 11:31:37 1 cn
16429 Default-First-Site-Name\WIN2003 16429 2003-04-23 19:45:04 3 description
16427 Default-First-Site-Name\WIN2003 16427 2003-04-23 19:44:14 1 physicalDeliveryOfficeName
 8194 Default-First-Site-Name\WIN2003  8194 2003-02-11 11:31:37 1 instanceType
 8194 Default-First-Site-Name\WIN2003  8194 2003-02-11 11:31:37 1 whenCreated
16432 Default-First-Site-Name\WIN2003 16432 2003-04-23 19:45:53 4 displayName
13893 Default-First-Site-Name\WIN2003 13893 2003-02-11 12:00:00 2 nTSecurityDescriptor