通过

Windows Server 2008 R2:故障转移群集的故障排除方案(zh-CN)

  • 项目

上个月，我着手了一些常见的WS2008R2群集故障，并且研究如何准确的诊断并解决这些问题。
(译自：http://technet.microsoft.com/en-us/magazine/hh289314.aspx)

注意，如果需要得到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属性编辑器是不会以十六进制格式显示的。而是以八进制格式显示。

 

http://s6.sinaimg.cn/mw690/001IPj7xty6HVdbWSJ7c5&690

 

所以默认情况下你会看到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

 

Other Languages:

 Windows Server 2008 R2: Failover Clustering Troubleshooting Scenarios