首页 > 代码库 > Windows活动目录系列---ADDS复制的概述(1)

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就会重新调整站点的复制拓扑来适应当前的环境。



本文出自 “乾涸的海綿” 博客,转载请与作者联系!

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