原文：http://technet.microsoft.com/en-us/magazine/hh289314.aspx

Translated:2014/4/7 by Soda (转载请注明出处)


上个月，我着手了一些常见的 WS2008R2 群集故障，并且研究如何准确的诊断并解决这些问题。

注意，如果需要得到 WS2008 或者 WS2008R2 故障转移群集的官方支持解决方案（Microsoft Customer Support Services 微软客户支持服务），必须符合以下条件：

  • 所有的所有的硬件和软件部件必须满足获得“Certified For Windows Server 2008 R2”徽标的资格

  • 完整的配置解决方案必须通过故障转移群集管理器的验证测试

以下是几个常见场景，可能会帮助你加快诊断或是预知你的下一次故障排除工作。

提出一类在维护 WS2008R2 故障转移群集过程中比较常见的问题，以及你解决它们需要遵循的步骤。


场景一：我们正在进行 AD 对象月度清理，不经意间删除了「群集名称」这个对象，我们尝试建立一个新项，但是群集无法上线了。

The Cluster Name Object（CNO 群集名称对象）是非常重要的，因为它是群集的通用身份 ID。

CNO 会被群集创建向导自动创建，使用群集的名字命名。当在群集上创建新的服务或是应用时便通过此账户来创建其他的群集虚拟计算机对象（Cluster Virtual Computer Objects 即 VCOs）。如果你删除了该对象，或是修改了它的权限，它将无法创建其他的群集所需对象直到被恢复或被分配了正确的权限。

所有在 AD 里的对象，都会被分配一个 objectGUID。故障转移群集藉由此来判断你处理的是正确的对象。如果你简单的新建了一个对象，一个新的 objectGUID 也会被创建。我们需要做的是恢复正确的对象，这样故障转移群集可以继续其正常运转。

当排除此类故障时，我们需要从群集资源里找到两样参数，在 powershell 里运行命令

Get-ClusterResource "Cluster Name" | Get-ClusterParameter CreatingDC,objectGUID

将会获得所需要的值，第一个我们需要的参数是 Creating DC，当故障转移群集创建 CNO，我们记录下是哪台 DC 创建的。对于任何基于群集进行的操作（创建 VCOS，使名字上线等），我们就知道是在此台 DC 上获得的对象与权限，如果在 DC 上没有找到或者 DC 失效了，将会在其他的可响应 DC 上搜索，但是至少知道首先去的地方。

第二个需要的参数是 objectGUID，确保我们正在操作正确的对象。在我们当前的例子里，群集名称是CLUSTER1，CreatingDC 是 DC1，objectGUID 是 1a3cf049cf79614ebd94670560da6f04

Object  Name  Value

------  ----  -----

Cluster Name  CreatingDC  \\DC1.domain.com

Cluster Name  ObjectGUID  1a3cf049cf79614ebd94670560da6f04

我们需要登录到 DC1 上，并且运行 ADUC。如果存在当前的 CLUSTER1 对象，我们可以检查一下它是否有适当的属性。注意在对象属性里的显示方式，AD 属性编辑器是不会以十六进制格式显示的。而是以八进制格式显示。

Windows <wbr>Server <wbr>2008 <wbr>R2:<wbr>Failover <wbr>Clustering <wbr>Troubleshooting <wbr>场景

所以默认情况下你会看到 49f03c1a-79cf-4e61-bd94-670560da6f04 这样一串数字，十六进制格式会进行相邻两位的交换动作，可能稍微有点难懂。如果你取第一个八位数字并且进行交换，49f03c1a 变成了 1a3cf049。交换接下来的两对互相交换，79cf 变成了 cf79，然后 4e61 变成了 614e。再剩下来保持不动。

你必须使属性编辑器里看到的 objectGUID 以十六进制格式与故障转移群集里显示的一样。如果不是正确的对象（即两个 GUID 不一致），则我们首先需要删除这个不正确的对象，空出位置以便恢复正确的那个。

有几种方法来恢复对象，我们可以使用活动目录的一些实用恢复程序，例如 ADRESTORE 或者新的 AD 回收站（如果使用的是 WS2008R2 DC 和已经升级过的林构架）。使用新的 AD 回收站功能会使事情边的简单许多，也是最无缝的恢复 AD 对象的手段。

使用 AD 回收站，我们可以使用以下 powershell 命令来搜索需要恢复的对象：

Get-ADObject –filter 'isdeleted –eq $true –and samAccountName –eq "CLUSTER1$"' –includeDelectedObjects –property * | FormatListsamAccountName,objectGUID

这个命令会去 AD 回收站里搜索所有以 CLUSTER1 命名的被删除对象，此命令会返回对象的名称和objectGUID，如果存在多个对象，则会全部显示出来。当找到我们需要的，会以如下形式显示：

samAccountName : CLUSTER1$  
objectGUID:49f03c1a-79cf-4e61-bd94-670560da6f04

现在我们需要恢复它，当我们删除了不正确的一项，恢复它的命令是：

Restore-ADObject –identity 49f03c1a-79cf-4e61-bd94-670560da6f04

这将恢复被删除的对象至对象的原有位置（组织单元之类的），并且恢复对象原有的权限和计算机账户密码。

这是 AD 回收站相比其他的一些实用程序例如 ADRESTORE 非常有优势的地方，使用 ADRESTORE，你必须重置密码，将他移动至适当的 OU，然后修复故障转移群集里的对象等等。

使用 AD 回收站，我们可以简单的将群集名称资源恢复。这也是执行 AD 恢复的最佳选项。


场景 2：我的群集共享卷在故障转移群集管理器里显示“重定向访问”，我改如何修正这个。

首先让我们快速回顾一下关于群集共享卷（CSV）的定义。CSVs 简化了 HyperV 虚拟机在故障转移群集里的配置与管理。使用 CSV 的 HyperV 群集可以使多个 VM 连接同一个 LUN（磁盘），仍然可以彼此对立的进行故障转移（从一个节点移动到另一个节点）。CSV 提供群集存储里卷的扩容弹性。例如，你可以将系统文件与数据区分开来优化磁盘性能，即使系统文件和数据都是用 VHD 文件保存的。

在所有的承载群集通信额网络适配器属性里，确保“Microsoft Networks 客户端”和“Microsoft Networks 文件与打印机共享”两个选项是勾上的，这样才能完全的支持 SMB 共享协议（服务器消息块 ServerMessageBlock)。这也是 CSV 所需要的。运行 WS2008 R2 的服务器会自动提供 CSV 所需要的 SMB 版本，即 SMB2。虽然只有一个首选的 CSV 通信网络，但是在多个网络上开启这些选项，有助于增加群集的故障响应弹性。

“重定向访问”意味着所有得的 I/O 操作都会通过网络 “重定向” 到另一个可以访问到磁盘（CSV）的节点。有以下三个基本原因来解释为何磁盘会开启重定向模式：

1、手动的将其置为重定向模式。

2、后台有备份的操作正在进行

3、硬件问题，当前的节点无法直接访问到磁盘（csv）

在我们的场景里，我们将排除选项 1 和选项 2。剩下选项三，如果我们去查看一下系统日志（System Event Log），我们会发现来自故障转移群集的，事件 ID 为 5121 的事件日志：

以下是该日志条目的定义：群集共享卷 CSV ‘ Cluster Disk X’ 不能再被当前节点直接访问。 I/O 访问请求会被重定向到网络上另一个拥有该卷的访问节点。这可能导致性能的降低。如果针对该卷的重定向访问被打开，请关闭掉。如果已经关闭了，请诊断该节点到存储设备的连通性，一旦连通性恢复，I/O 访问将恢复到健康的状态。

站在这个理论上，我们得先找找在此事件之前的硬件相关事件，所以应该去查看一下 ID 号为 9、11 或者 15的关于硬件或是连通问题的事件。还应该去看看磁盘管理界面里是否存在该 CSV 卷。在大多数情况下，还会看到其他的一些错误，当我们在后端存储解决了该问题后，我们就能将磁盘转回正确的模式了。

请注意，CSV 最少只需要一个能访问到存储（SAN）的节点就能保持运行。这就是为什么叫”重定向模式“。所有针对该 CSV 卷的 I/O 将会发送到这个可以访问存储的节点，Hyper-V 的 VM 们也能继续运行。当然这可能会对 VM 的性能造成一定影响，但他们仍在运行。生产环境得以保持，这真是个好事。


场景 3：我刚刚为了高可用 VM 而创建了一个 WS 2008 R2 故障转移群集。同时设置了一些磁盘作为 CSV，但是当我尝试访问磁盘时，Explorer（资源管理器）和磁盘管理界面都挂了。我不能把以前的 VHD 文件拷贝到驱动器里来继续了。

群集里只有一个”真的“驱动器拥有者，被称为”协调器节点“。任何形式的针对该驱动器的原始数据写入都只能通过该节点完成。

当你打开 Explorer 资源管理器或是磁盘管理器时候，就是在试图打开驱动器并进行元数据写入。鉴于此，针对此服务器未拥有的驱动器的访问都会通过网络被重定向到协调器节点。这与驱动器的”重定向访问“模式是不一样的。

诊断这种情况时，故障转移群集管理器会显示该驱动器处于连接状态，所以首先去检查日志里记录的事件。你会看到以下一些来自故障转移群集的事件：

事件 ID： 5142：

群集共享卷’ Cluster Disk X‘ 在此节点上无法访问，因为出现了错误‘ERROR_TIMEOUT(1460).' 请诊断节点与存储之间的连通性与网络连通性。

事件 ID：5120

群集共享卷’cluster disk X‘在此节点上无法访问，因为 'STATUS_BAD_NETWORK_PATH(c00000be).' 所有的I/O 将临时被队列直到存储连接恢复正常。

这些事件日志都是在连接到协调性节点时超时，所以接下来你可以看看系统事件日志里是否有关于节点间网络连接的条目。如果有，那么你需要解决他们。网卡故障或被禁用都可能导致这些问题。

下一步，就得去检查下节点间的基础网络连接。首先要检查 CSV 所在的网络通信是否顺畅，故障转移群集选择网络的方法是选择最高 Metric 值的链路，这与 windows 的识别网络方式是不同的。

故障转移群集网络容错适配器 (NETFT，Network Fault Tolerance adapter) 有自己的一套 Metric（度量值）系统。所有有默认网关的网络将被分配 Metric 由 10000,10100,10200 并顺序增长。所有没有默认网关的网络将被分配从 1000 开始,1100,1200 顺序增长。

使用 Powershell，可以输入 

Get-ClusterNetwork | FT Name,Metric,Role

来查看 NETFT 适配器如何定义它们，你可以看到类似如下结果：

Name  Metric

-------------------

Management  10100

CSV Traffic  1000

LAN-WAN  10000

Private  1100


在以上四种网络中，我定义为 CSV 使用的网络名为“csv traffic“，我设置 Node1 的 ip 地址是 1.1.1.1，node2的地址是 1.1.1.2，接下来我会通过 ping 两个 IP 地址来进行基础网络链路检查。

下一步就是尝试使用 ip 地址来进行 SMB 连接，这也是故障转移群集会做的，

一条简单的 NET VIEW \\1.1.1.1 命令就能观察出 1.1.1.1 的 SMB 服务是否有响应. 你会得到一个共享的列表,或者一条信息:" 列表中未发现任何条目”。

这表明你可以向共享建立连接。但是如果你得到一个报错“系统错误 53 发生，网络路径未找到”，这表明和TCP/IP 配置有关，得检查下网卡的配置了。

CSV 要求在网卡配置里开启“Microsoft Networks 客户端”和“Microsoft Networks 文件与打印共享”两个选项。如果没有被开启，你就会碰到 Explorer 挂了的问题。开启选项就好了。

在 WS 2003 群集或者更低的版本，不勾选这些选项是推荐的做法，你需要注意这一点。

其他因素：

有一些其他的因素你也需要考虑，如果你的群集节点正处于资源主机子节点（RHS Resource Host Subsystem）失败的状态，你首先要考虑到 RHS 的本质以及它是干什么的。RHS 是故障转移群集用来做资源健康检查的组件，对于 IP 地址，它确保 IP 处于正确的网络并且是响应的；对于磁盘，他会尝试去连接驱动器，并且执行一下 DIR 命令。

如果正处于 RHS 崩溃状态，可以去找系统事件日志里事件 ID 为 1230 和 1146 的日志，在 1230 里，会明确指出资源和资源使用的 DLL 文件。如果它崩溃了，就意味着该资源无法正确响应或是假死状态。如果是磁盘资源崩溃，你就必须去查找与磁盘相关的错误，或是磁盘延迟问题。跑一下性能监视器是个好的开头，更新一下阵列卡的驱动或是后端存储的 firmware 都是可以考虑执行的操作。

你也可以进行一些用户模式检测，故障转移群会进行从内核模式到用户模式全过程的监测以便得知何时用户模式无响应或挂起。从这种情况中恢复，群集会开始进行错误检查，你会收到一个 Stop 错误检测错误代码 0x9E，诊断此错误需要内存转储文件。（参考 SeeAlso 第一条）

你也可以使用性能监视器来检查挂起、内存泄露等现象。

故障转移群集是基于 Windows Management Instrumentation（WMI）的，如果服务器上的 WMI 有问题，那么故障转移群集里也会出现问题（创建或添加节点，迁移等）。针对 WMI 进行检查，使用 WBEMTEST.EXE，或是一些远程 WMI 脚本。

可以尝试使用下列 Powershell 脚本：（node1 是当前的节点名）

Get-WMIObject mscluster_resourcegroup -computer NODE1 -namespace "ROOT\MSCluster"

这将对群集建立 WMI 连接，并且返回你相关的 WMI 资源信息。

如果这条命令运行失败，那么服务器可能存在 WMI 的问题：WMI 服务可能被停止，你需要重启它；WMI数据库损坏，使用 powershell 命令 winmgmt /salvagerepository 来执行一致性检查， 等等。（参考 SeeAlso 第二条）

记住以下一些诊断要点：

  • Validate, validate, validate. Use Cluster Validation for troubleshooting. Use it for best practices. Use it when changes are made to your system.

  • 验证、验证、验证。使用群集验证向导来诊断、使用它来进行最佳实践、使用它来进行群集更改。

  • Everything is headed toward Windows PowerShell. If you don’t know it yet, start playing around with it.

  • 任何操作都会转化为 Powershell，如果你还不知道这玩意儿，马上开始学习并玩儿起来吧！

  • Because we’re reliant on Active Directory objects, protect yourself. Enable the Active Directory Recycle Bin and protect objects from accidental deletion.

  • 因为我们始终依靠着 AD 对象，为了保护自己，打开 AD 回收站来防止对象被意外删除。

  • When troubleshooting CSVs, don’t always assume it’s a hardware problem.

  • 当诊断 CSV 时，不要老是考虑硬件问题

  • When troubleshooting, take a step back and look at everything that can be affected. Then start narrowing your focus.

  • 诊断时候，后退一步注意一下全局都可能影响的情况，再开始缩小焦点。

  • 故障转移群集是被设计用来检测问题、从故障里恢复的。群集会告诉你哪里有、或者已经发生了问题，而非群集引起了问题。就像某些人说的：两国交战，不斩来使。


See also:

1、如何在服务器群集中启用用户模式挂起检测 http://support.microsoft.com/kb/815267/zh-cn

2、winmgmt http://msdn.microsoft.com/en-us/library/aa394525(v=vs.85).aspx