域控制器发生故障时确保继续复制活动目录

对管理员来说，他们最重要的工作能力之一就是要能进行突发故障的恢复，无论该故障是故意的还是偶然的。活动目录（AD）灾难恢复包括确保AD恢复的许多方面。比起只是留有备份，这要复杂的多。确保你能对任何故障，无论硬件还是软件方面进行恢复的最佳方法就是要抢先防备。设法让业务停工期的时间最短，最好没有停工期。在本文中，我们将讨论关于在关键域控制器发生故障时如何确保继续复制AD方面的问题。

密码和安全发生改变，安全策略以及关键配置设置通过组策略执行，FRS复制和AD复制都能使所有域控制器具有相同的组策略。因此，有理由相信它是企业的最大兴趣点，可帮助企业确保成功进行AD复制，并保留未遭破坏的部分。对公司来说，通常会创建灾难恢复站点，在整个组织“轴心”站点出现故障时，该站点可用于支持基础结构，关键应用程序以及数据。许多组织网络以重复轴心及轮辐网络方式进行配置，如图一所示。注意在某些配置中，多种轴心形成AD恢复的核心。多种核心轴心站点包含固有的灾难恢复配置。也就是说，如果一个核心站点出现故障，还有其他站点分担载荷。

560)this.style.width=560; onmousewheel = javascript:return big(this) style="WIDTH: 477px; HEIGHT: 316px" height=305 onerror="this.src=/files/uploadimg/20051215/1711210.gif;" hspace=3 src="/files/uploadimg/20051215/1711210.gif" width=476 align=center vspace=1 border=1>

（图1）

对单一的轴心配置来说，灾难恢复的难题在于在网络链接良好的地方创建AD站点，至少与企业中的每个森林的每个域中的一个域控制器相连接。这就得包括至少一个通用目录服务器（GC），Exchange服务器和其他依赖于用来支持用户社区的基础结构中的打印文件或应用程序服务器。

假设我们选择了这样一个站点，并具备必需的服务器基础结构，我们需确定的一件事就是在主要轴心站点不可用时AD恢复会如何。记住，你不必非要等到对该站点的恐怖袭击会使其不可用，一个简单的网络故障或电力损耗都会使其出现问题。

你需要考虑哪里的网络是简单的中心辐射型拓扑结构。如果主要轴心站点发生故障，设计良好的DR站点可以继续工作。为避免轴心站点中所有域控制器发生故障，在考虑如何准备多余AD复制时要创建与主要轴心站点及DR站点之间的站点链接，如图二所示。这里我们发现将远程站点与主要轴心站点相链接起来的站点消耗为100，而那些将远程站点与DR站点链接起来的要消耗200。表面看起来很有道理。只要主要站点中的域控制器还在运行，就不会用到多余的链接。然而，在测试主要站点域控制器实效时，我们发现KCC计算出不同的拓扑结构，而不是本来想要的结构，这样就在远程站点之间而不是直接同DR站点建立连接。它无法进行纠正。在考虑为何KCC会以这种方式进行计算时会发现，AD复制规则中显示该错误是源于设计问题。

560)this.style.width=560; onmousewheel = javascript:return big(this) onerror="this.src=/files/uploadimg/20051215/1711212.gif;" hspace=3 src="/files/uploadimg/20051215/1711212.gif" align=center vspace=1 border=1>

（图2）

活动目录复制有一个内置的冗余特性，被称为站点链接桥（SLB）。如在任何给定站点中，域控制器出现故障，SLB允许KCC建立可传递链接，在不需人力操作的情况下，允许复制对出现故障的域控制器进行调整。当出现故障的域控制器是站点中唯一的域控制器（或者，如站点中所有域控制出现问题时），SLB就尤为重要了。看看图示三中的情况。有三个站点，ATL，CHI，以及NYC。假设物理网络将所有三个站点联结起来，一个站点链接联结ATL和CHI，一个站点链接联结CHI和NYC。ATL与NYC之间没有站点链接联结。只要CHI中的域控制器可用，复制就没有问题。但如果CHI域控制器发生故障怎么办？似乎ATL同NYC之间的复制也会无法进行，在没有SLB的情况下更会出现这种问题。如果SLB可用，KCC就要有所决定，因为ATL能复制到CHI，CHI复制到NYC，然后ATL又能复制到NYC。从ATL到NYC之间又会创建链接，消耗与CHI-NYC，ATL-CHI链接的联合消耗相等。（如图四所示）

560)this.style.width=560; onmousewheel = javascript:return big(this) onerror="this.src=/files/uploadimg/20051215/1711214.gif;" hspace=3 src="/files/uploadimg/20051215/1711214.gif" align=center vspace=1 border=1>

（图3）

560)this.style.width=560; onmousewheel = javascript:return big(this) onerror="this.src=/files/uploadimg/20051215/1711216.gif;" hspace=3 src="/files/uploadimg/20051215/1711216.gif" align=center vspace=1 border=1>

（图4）

需要记住的是，KCC不能看到物理网络，要依靠管理员配置物理网络中联结域控制器的站点链接。当CHI站点出现问题，KCC就会察觉到。因为CHI-NYC域ATL-CHI间存在联结性，物理网络联结了ATL与NYC，但是管理员不能从ATL-NYC中创建明确的站点链接。KCC负责这种勘漏和ATL、NYC之间的复制，直到CHI恢复工作，在这种情况下，KCC将拆除ATL-NYC联结，并通过CHI建立初始联结。我们可以决定使SLB实效（默认情况下它是可用的）并简单地创建ATL-NYC链接，但是在较大环境里，管理起来比较困难。

在我们所讨论的问题中，比较重要的一点是Windows 2000本身存在一些限制，基于这种原因微软建议在企业中的域控制器站点最多不能超过200个，对单一轴心站点的复制不能多于120个，因为除了KCC限制外，硬件配置也是很重要的一方面。我们现在无法对该主题展开来说，但是在推出的KB文章里有很好的说明，如KB244368以及Branch Office部署指南。通常的解决方法是使SLB失效，减少KCC中的载荷，并切实消除多数情况中的问题。Windows 2003使用完全不同的支持生成树算法，可允许KCC消除那些限制，让我们重新使用SLB。

因此，在消除DR站点到远程站点中所创建的复制链接时SLB起到什么作用呢？如果我们利用原来在ATL，NYC及CHI站点中用到的例子，就能发现它是如何工作的。在那些例子里，CHI是轴心站点，ATL是DR站点。但是除了NYC，我们还有很多其他的远程站点，当然SLB也被激活。在例子中我们看到，在CHI站点中的域控制不可用时，远程站点NYC是如何被复制到ATL的。这种情况也适用所有其他的远程站点。因此，如果CHI的域控制器不可用，KCC将最终确定CHI没有可复制的域控制器，它将创建链接到ATL，允许在远程站点与ATL之间建立联结对象，完成网络容错备援设置。

需要指出几个重要问题：

• 在主要轴心站点与DR站点间建立低成本的站点链接，确保两者间的频繁复制，从而保障DR站点同主要站点一起随时得到更新。这也意味着物理网络在那两者间应该有一个可靠，高速的链接。
• 不要在DR站点与远程站点间创建站点链接。
• 不要手动创建联结对象到DR站点中。
• 当出现故障的站点得到恢复后，Windows 2000在清除旧的联结对象时并不出色，这就需要管理员手动清除旧联结对象到DR站点上。Windows 2003的清除工作确非常出色（这也是选用Windows 2003的另一个原因）。
• 当然，这些都取决于DR站点与远程站点间的物理网络联结性如何。
• 通常，在投入生产前都要在实验室里进行测试。总会有些情况你没有首先想到，因此不要总是等到灾难性问题出现时再去解决。
• 在多种核心轴心站点里，当一个出现问题，（SLB可用），KCC将调整其他节点中的联结情况。它们都会互相成为对方的内置DR站点。
• 控制KCC行为的最好方法时给它设定足够的参数，这样它就不会走入歧途。如果给予过多自由，KCC通常不能按你预期的那样进行复制。允许SLB传递性既可。

总的来说就是以尽可能简单的模式设计复制的拓扑结构（中心辐射结构提供到达远程站点的单一路径），允许SLB在主要轴心站点发生故障时提供冗余配置。