Windows活动目录系列---ADDS复制的概述(1)

AD DS分区介绍：

活动目录数据存储中所包含的信息会被ADDS发布到林中的所有DC上。数据存储中包含的大部分信息会在单域中发布，但是还有部分相关信息会不受域的复制边界限制，将信息发布到整个林中。

为了提升DC之间的复制效率和扩展性，活动目录的数据被逻辑的划分成几个分区，每个分区作为一个复制单元，并且每个分区都有自身的复制拓扑，ADDS有以下默认的分区：

1. 配置分区。配置分区是在林中第一台DC被创建的时候自动生成的，配置分区中包含了林范围的ADDS结构信息，包括林中有哪些域或站点，每个域中有哪些DC。配置分区还保存了林范围的服务信息，比如DHCP授权和证书模板。此分区会在林中的所有DC之间复制，它比其他分区都要小，它保存的对象变更频率也不高，所以它的复制频率也不会很频繁。

2. 架构分区。架构分区保存了你在数据存储中创建的所有对象和属性的定义，以及创建对象和属性时所使用的规则和操作。架构分区同样在整个林中的DC之间复制，因此所有的对象都必须符合架构对象和属性的定义规则。ADDS默认有一组不能被修改的类和属性，但是如果你是Schema Admins的成员，你可以通过添加新的属性和类来扩展架构，扩展架构中的类将会用于那些特定应用程序。微软的Exchange和SCCM2012都需要扩展架构来提供某些应用上的增强功能。这些变更只会在林中的架构主机角色所在的DC上生效，因为只有架构主机才能新增类和属性，和配置分区一样，架构分区也是一个较小的分区，并且它只会在数据存储发生更改的时候才需要复制，所以它的复制频率也不会很频繁，一般都是在扩展架构之后才会进行复制操作。

3. 域分区。当你创建了一个新的域，ADDS会自动的创建一个域分区的实例，并将它复制到域中的所有DC，域分区中包含了所有特定域对象的信息，比如用户，群组，计算机，OU，以及域相关的系统设定。域分区一般是ADDS最大的分区，它保存了域中所有的对象，而且它的变更十分频繁，因为每次创建，删除一个对象，或者修改对象的属性值，它都必须将这些变更复制到域中其他的DC上。林中每个域分区中的对象都会保存在GC(全局目录)上，但是全局目录保存的只是对象的部分属性值。

4. 应用程序分区。应用程序分区存储了非域的，与应用程序相关的信息，这些信息可能会有一个规律的更新频率或者特定的生命周期，比如启用了DNS和AD集成功能后，DNS分区就会保存在应用程序分区中。应用程序一般会根据编程语言去决定如何保存，分类和使用这些特定的应用程序信息。为了防止应用程序分区中产生不必要的复制操作，你可以指定林中的某台DC保存特定应用程序的分区。与域分区不同的是，应用程序分区不会保存安全性主体对象，比如用户账号。此外GC中也不会保存应用程序分区中的数据，应用程序分区的大小和复制频率的变动幅度比较大，因为这些都与应用程序的使用有关。使用AD集成的DNS会让你在多台DC上拥有一个大而稳固的DNS区域，但是服务器和客户端计算机会导致分区的频繁复制。

AD DS复制的特征：

设计一个高效的AD DS复制能够保障DC上每个分区中的数据与其他DC上的副本一致。通常情况下，不是所有的DC在任意的一个时刻都会有完全相同的信息，因为变更数据的来源时常会不一样，不过AD复制功能会将分区中所有变更的信息传递到其他所有的分区副本中。AD复制能够准确的去平衡，集成，或者聚合服务器性能，从而使得复制流量保持在一个合理的级别。

AD复制的关键特征：

1. 多主机复制。除了RODC以外的DC都可以向AD DS发起和提交一个变更动作，这个机制使得ADDS具有容错功能，并且使目录存储的维护不再仅依赖单独的一台DC。

2. 拉取式复制。一台DC对其他DC发出请求或者拉取那些变更的数据，举个例子，A和B都是同一域的DC，B在目录中变更了某些数据，但是B并没有通知A数据发生了变更，但是A会轮询它的复制伙伴去检查是否目录数据有发生变更，当A轮询到B的时候发现目录数据发生了变更，那么A就会自己发出请求并拉取这些变更。

3. 存储转发复制。DC可以从它的复制伙伴拉取变更数据，然后将这些变更数据发送给其他的复制伙伴。举个例子，A,B,C都是同一个域的DC，B首先发生了数据变更，然后A从B上拉取了变更数据，接着C又从A上面拉取变更的数据，这样能够在拥有多台DC的环境中均衡DC复制的负载。

4. 数据存储分割。域中的DC会承载这个域的域命名上下文，域命名上下文能够最小化复制，特别是在一个多域环境中。DC同时也会承载架构和配置分区的副本，这两个分区是在林范围复制的，但是这两个分区数据变更的频率比域分区要低很多，所以默认情况下其他的数据是不会复制到林中的每台DC上的，包括应用程序目录分区和GC上的对象属性。不过你可以将林中的所有DC都配置成GC使所有的复制都一样。

5. 自动生成一个有效稳定的复制拓扑。默认情况下，AD DS会有一个有效的多向复制拓扑，以便当一台DC出现故障后不会对复制造成影响，当有新的DC被添加，删除，移动到其他站点的时候，AD DS会自动的去更新这个复制拓扑。

6. 属性级复制。当一个对象的属性变更了，AD DS只会复制这个属性和该属性最小的元数据描述。它不会把整个对象都进行复制，除非这个对象是第一次创建，对于一个多值的属性，比如群组中包含的成员账号名，它也只会复制实际变更的成员，而不会把整个列表中的成员都复制过去。

7. 直观的控制站点之间复制。可以通过AD站点和服务控制台去控制站点之间的复制。

8. 冲突检测和管理。可能有某些比较少见的情况，比如在某次复制发生期间有一个属性在不同的DC上被修改了，如果出现了这种情况，你就必须协调好这两个修改的属性，否则就会产生冲突，AD DS中对几乎所有的场景都有相应的解决算法，包括上述所列举的情况。

AD DS站点内复制的过程

在单独的站点中，AD DS会自动执行复制行为，这种复制被称为站内复制。但是你也可以根据需要去手动配置站内复制，下面有四个与站内复制相关的概念：

1. 连接对象

2. 知识一致性检查器(KCC)

3. 通知

4. 轮询

接下来，描述一下四个概念与站内复制如何进行相关

连接对象：

DC1从另一台DC2中复制变更的数据，那么DC1与DC2被称为复制伙伴。复制伙伴之间是通过连接对象进行连接的，一个连接对象代表了一台DC到另一台DC之间的复制路径，连接对象是单向的，它仅代表传入的拉取复制。

我们可以通过AD站点和服务控制台查看和配置连接对象，打开控制台中DC服务器内的NTDS Setting容器，右键选中右侧的连接对象，在弹出的菜单中选择"立即复制"，需要注意的是这个复制仅仅是传入的复制，如果你想将变更的数据复制到双方DC上，你需要到每个站点的连接对象上手动执行一次复制动作。

知识一致性检查器(KCC)：

DC之间的连接对象所构成的复制路径，这些复制路径建立了林的复制拓扑，所以你不需要手动去创建复制拓扑。ADDS会默认创建一个拓扑来保证有效的复制，这个拓扑是双向的，即使有一台DC出错了复制也不会被中断，并且这个拓扑还保证了任意两台DC之间不会超过三个跃点。

每台DC中的KCC组件帮助站点内的DC自动生成并优化复制。KCC会评估站点内的DC，然后创建连接对象去构成双向三跃点的复制拓扑，如果你添加或者删除一台DC，或者有一台DC故障了无法响应，KCC会动态的去重新调整复制拓扑，通过添加或者删除连接对象来重建一个有效的复制拓扑。KCC有一个固定的运行时间间隔(默认15分钟一次)，并且运行时会指定DC之间最优的复制路由。

你可以手动的创建连接对象来满足一些特定的复制要求，但是一般不推荐你手动创建连接对象，因为KCC不会去验证手动创建的连接对象，也不会将手动创建的连接对象作为故障转移的路径，KCC也不会删除手动创建的连接对象，所以当你不需要使用那些手动创建的连接对象时，你必须手动去删除它们。

通知：

当DC上的活动目录分区发生变更后，DC会将这些变更放入复制队列发送给它的复制伙伴，源DC会默认15s向它的第一复制伙伴发送数据变更的通知。通知就是上游的伙伴向下游的伙伴发送已有数据变更的信息的过程，在通知到达其他伙伴期间，源DC会默认等待3s，这两种延时被称为"初始通知延时"和"后续通知延时"，这种设计是为了错开站内复制所产生的网络流量。比如DC1的复制伙伴为DC2和DC3，DC2是DC1的第一复制伙伴，DC1变更数据后15s通知DC2，通知DC2之后再等3s才会将通知发送给DC3。

根据接收到的通知，下游的伙伴会向源DC请求变更的数据，同时目录复制代理从源DC拉取变更的数据。例如，假设DC1发起了一个ADDS的数据变更，当DC2接收到了DC1的变更数据，DC2会将变更数据更新到它的目录中，然后DC2将变更数据加入复制队列，传递给它的下游复制伙伴。接下来，假设DC3是DC2的下游复制伙伴，15s之后DC2会向DC3发送一个通知，告诉DC3我的数据已经变更了，DC3将DC2变更的数据更新到自己的目录中，然后再通知它的下游复制伙伴。变更数据经过了两个跃点，从DC1到DC2，然后从DC2到DC3，复制拓扑不会让数据复制时超过三个跃点，每个跃点大概15s，变更数据会在1分钟之内复制到站内所有DC。因为复制拓扑不会让数据复制时超过三个跃点，参照上面的例子，DC1到DC2，DC2到DC3，DC3到DC4，但是DC4就不会到DC5了，因为DC4到DC5就是第四个跃点。

轮询：

有时候DC较长时间不会发生数据变更，特别是在节假日之类的非工作时间。现在我们假设DC1很长时间没有数据变更，那么它的下游复制伙伴DC2就不会收到DC1的变更通知，当然如果DC1处于故障或者离线状态，它也不会发送变更通知给DC2。那么DC2如何得知它的上游复制伙伴是处于没有数据更新还是已经故障了呢？轮询就是为了解决这个问题而设计的，在轮询的过程中下游复制伙伴会向上游的复制伙伴发送一个查询，这个查询会去检查上游复制伙伴是否有变更数据在复制队列中。站内复制的查询时间间隔默认为每小时1次，你可以在连接对象的属性中通过修改计划来更改这个时间间隔，但是不推荐你去修改。

如果上游的复制伙伴无法响应这个查询，下游复制伙伴会发起KCC去检查复制拓扑，如果上游复制伙伴确实故障了，KCC就会重新调整站点的复制拓扑来适应当前的环境。