VMware vSphere 5.1 群集深入解析（二十九）-故障排错

如果一台主机发生故障，群集的HA主节点检测到故障，从此该主机不再收到网络心跳。在主节点检测到网络心跳丢失，它将开始监控数据存储的心跳，自从主机完全发生故障，它不能产生数据存储心跳，这些通过HA 主节点检测。在这段时间，ping故障主机的管理地址，再一次检测完成。如果所有的检测返回都是不成功的，主节点将申明丢失的主机死亡，再主节点与主机失去联系之前，将尝试重新启动故障主机上所有受保护的虚拟机。

vSphere DRS VM-Host管理规则定义群集级别时“shoud rules”（的成员虚拟机应在组），意味着虚拟机可能在其它数据中心的主机上重启。在我们的测试中，我们见证这一行为多次，虚拟机在Bluefin数据中心群集中任一可用的主机上启动。vSphere DRS在首次调用时将尝试调整任何冲突的关联规则，同时按照他们的关联规则排队自动迁移置入虚拟机。我们建议手工调用vSphere DRS来确保所有的虚拟机在正确的主机上，尽可能避免性能降低和减少可用性以及可能的二次故障。在我们的场景中，虚拟机置入位置丢失将导致增加延迟，虚拟机将访问其它地方的存储。下面的截图描述了怎样在vCenter群集对象的DRS项中手工运行DRS。

图170：手工触发DRS

Frimley 数据中心主机隔离故障

在这个场景中，我们通过断开单个主机的所有的网络连接将其从Frimley数据中心隔离，存储网络不受影响。

图171：单个主机隔离

结果

虚拟机保持运行，隔离响应设置的是“保持电源开启”

解释

当主机被隔离，通过HA 主节点隔离被检测到，同时该主机不再接受网络心跳。当主节点检测到网络心跳丢失，它将开始监控数据存储心跳，自此主机被隔离，它将在第二次HA检测机制时产生数据存储心跳，检测到有效的主机心跳将允许HA主节点来决定主机在运行中但网络隔离。依靠隔离响应配置，受影响的主机可能选择断电或者关闭虚拟机，或者依次让虚拟机通电。主机被隔离后30秒触发隔离响应。

我们建议调整隔离来响应商业需求和物理约束。从最佳实践观点来说，“保持电源开启”是主流环境的推荐隔离响应。在合理的架构环境中隔离主机是非常罕见的事件，冗余是非常主流的设计，在使用基于网络存储协议的环境中，例如iSCSI和NFS，建议隔离响应是“关闭电源”，在这些环境中，它更可能是网络中断引起的主机隔离还将影响主机与数据存储的通信。

如果隔离响应推荐选择“保持开启电源“，当隔离响应被触发，将通过群集上的HA节点重新启动虚拟机。vSphere DRS VM-host管理规则定义了群集级别时“should rules”，意味着虚拟机可能在其它的数据中心的主机上重启，在我们的测试中，我们见证过这一行为多次，接下来的主机隔离和群集响应关联，我们建议手工调用vSphere DRS确保所有的虚拟机在合适的主机上，尽可能避免性能降低和无法置入虚拟机。在我们的场景中，无法置入虚拟机将导致增加延迟，同时虚拟机将访问其它地方的存储。

存储分割

在这个场景中，模拟数据中心之间的存储网络发生故障，描述如下图。

图172：存储分割

结果

虚拟机没有受到影响继续运行

解释

每个LUN有定义关联存储站点，vSphere DRS规则与这些关联一致。由于这些配置，没有虚拟机受到影响，同时它们的站点运行的存储保持可用。

如果任何原因虚拟机的关联规则发生冲突，Frimley数据中心内主机上运行的虚拟机，它们的磁盘属于Bluefin数据中心的数据存储，在站点间的存储分割，数据存储在所有路径断开（APC）的条件下，它不能成功的产生I/O。当HA主仍收到来自于群集其它主机的心跳，它将不会有任何行动：它们站点有冲突的任何虚拟机将不同通过HA重新启动，除非手动关闭虚拟机。

我们建议监控vSphere DRS规则的兼容性来避免APD场景中不必要的停机时间，尽管vSphere DRS每分钟调用一次，它不会保证每次调用期间所有的冲突都被解决。因此，建议严格的监控来允许快速识别异常同时阻止不必要的当机时间。

数据中心分割

在这个场景中，我们完全将Frimley数据中心和Bluefin数据中心隔离，描述如下图。

图173：数据中心分割

结果

虚拟机保持运行无影响

解释

在这个场景中，两个数据中心彼此完全隔离，这个场景类似于存储部分和主机部分隔离。发生这样的故障虚拟机不受影响。当vSphere DRS规则正确的执行，没有规则冲突。在群集分割期间HA按照逻辑的过程来决定哪些虚拟机需要重新启动：Frimley数据中心上运行的HA主节点检测到Bluefin数据中心的全部主机不可达，HA主节点首先检测没有接受到网络心跳。在此之后，它将证实是否有任何存储心跳生成；这个检查将检测存储心跳，同时站点之间存储连接发生故障，每个站点的数据存储心跳只更新本地的。虚拟机将关联剩下的正在运行的主机。接下来，HA将证实是否接受重启，因为数据存储的读写版本处于Bluefin无法访问Frimley的主机，所以不要尝试开启其它站点丢失的虚拟机。

同样的，Bluefin 数据中心的ESXi主机将检测有没有主节点可用，并初始化选举主节点的过程，在新的主节点选出后，它将试图发现发生故障之前运行着的虚拟机，尝试重新启动它们。当所有关联到Bluefin的虚拟机仍运行在Bluefine数据中心，就不需要重启。只有关联到Frimley的虚拟机不可用，vSphere HA不会重启这些虚拟机，因为虚拟机所在的数据存储关联到Frimley，而在Bluefin数据中心不可用。

如果主机关联规则冲突，例如，默认，行为发生改变，虚拟机运行的存储没有定义的读写。我们故意配置冲突关联规则来记录这个行为：我们手工从Frimley迁移虚拟机到Bluefin，这样做之后，我们创建了一个情况，虚拟机运行在Bluefin的主机上运行，但是可以访问Frimley 数据中心的数据存储，当数据中心被隔离，接下来的顺序是我们见证的：

1. 虚拟机关联到Frimley但在Bluefin上不能到达数据存储。这导致了虚拟机不能磁盘读写

2. 在Frimley数据中心，虚拟机通过vSphere HA重新启动，同时Frimley数据中心的主节点不知道Bluefin数据中心运行的实例

3. 由于数据存储只有Frimley数据中心的主机能使用，Frimley数据中心的主机能获取锁定的虚拟机文件，并能够开启虚拟机

4. 创建的这个场景，同一个虚拟机在两个数据中心上运行。

图174：上电顺序

这是为什么？

运行的虚拟机主机网络心跳丢失，因为两个站点之间没有管理网络连接
数据存储心跳丢失，因为两个站点之间没有存储网络连接
ping运行了虚拟机的主机的管理地址失败，因为两个站点之间没有管理网络连接
Frimley数据中心本地的主节点知道发生故障之前虚拟机已经开启，因为它不能再发生故障之后同Bluefin数据中心内的主机上的虚拟机通信
通过Bluefin数据中心的主机判断数据存储全部路径断开，同样的，没有采取任何行动。正如之前解释的，只有PDL条件下虚拟机被自动杀掉。

当两个站点之间的连接被修复，经典的“脑裂”场景就存在了，在短时间内，两个同样MAC地址的虚拟机副本在网络上被激活。但是，它将访问虚拟机文件，HA也认识到这一点，只要被检测到，所有属于虚拟机的副本不会访问被杀掉的虚拟机，如下图所示。

图175：锁定文件日志信息

在这个例子中，如果站点关联规则维护得比较合理，不必要的停机时间应该等于虚拟机的重启时间，而这个例子不是。所以我们建议更进一步监控vSphere DRS规则与数据存储站点的关联来阻止不必要的停机时间。

Frimley数据中心磁盘柜故障

在这个场景中，Frimley数据中心的一个磁盘柜发生故障。在存储A 上的Frimley01和Frimley02受到影响。

图176：磁盘柜故障

结果

虚拟机保持运行但可能增加了存储延迟

解释

在这个场景中，只有Frimley数据中心的磁盘柜发生故障，存储处理器认识到故障，并立即交换Frimley的主磁盘柜到Bluefin数据中心的镜像副本上，在我们测试期间，没有发现任何对虚拟机的影响除了I/O响应时间，这将导致Frimley和Bluefin之间较低延迟的连接。这个场景通过扩展群集解决方案可以全面的认识和把握。不需要重新扫描数据存储或者HBA卡，而且无缝切换，从ESXi的角度来看，LUN是相同的。

Frimley 数据中心全存储发生故障

在这个场景中，我们在Frimley数据中心中测试了全存储系统发生故障，如下图所示：

图177：全存储发生故障

结果

虚拟机保持运行无影响

解释

当Feimley数据中心的全存储系统发生故障，一个“接管”命令手工初始化。描述如下，我们使用NetApp Metrocluster配置。“接管”是特指NetApp环境中的命令，但相似的命令和进程在其它厂商的扩展群集解决方案中也存在。在命令初始化后，镜像，每个故障数据存储只读副本被提升为读写，并立即访问，请注意，我们在一个非常高的级别来描述这个过程。更多详细的信息请查看存储厂商的文档。

从虚拟机的角度来说，故障切换时无缝的，意味着存储控制者将进行处理，vSphere或者存储管理员不会接收到请求。（注意当存储管理员初始化take over命令这些是无缝的），应该注意所有的I/O通过内部连接到其它数据中心，虚拟机保持运行在Frimley数据中心，同时访问在Bluefin数据中心其它的数据存储。

vSphere HA不知道发生故障的类型，尽管数据存储心跳可能短暂丢失，HA不会采取行动，当网络心跳有3秒没有收到，HA主代理只检查数据存储心跳。存储发生故障网络心跳保持可用，HA不会接收到初始化任何重启。

永久设备丢失

在这个场景中，我们测试一个永久设备丢失的条件。这个场景在同一配置时比较少见，我们强制设置一个LUN为“离线”状态，永久设备丢失条件在不统一的vMSC配置中很常见。

图178：永久设备丢失

结果

虚拟机通过ESXi被杀掉，并通过HA重启

解释

当模拟了永久设备丢失条件，属于该数据存储的虚拟机被立即杀掉，虚拟机被杀掉之后，虚拟机通过vSphere HA重新启动，永久设备丢失和通过ESXi主机目录/var/log下的vmkernel.log可以查看到虚拟机杀掉的过程。接下来是PDL认识到的vmkernel日志文件，并采取了相应的行动。

2012-03-14T13:39:25.085Z cpu7:4499)WARNING: VSCSI: 4055: handle 8198(vscsi4:0):opened by wid 4499 (vmm0:fri-iscsi-02) has Permanent Device Loss. Killing world group leader 4491

我们建议在高级选项disk.terminateVMOnPDL Default和das.maskCleanShutdown Enabled设置为“True”，如果这些没有配置（通过默认das.maskCleanShutdown Enabled设置为“False”）此时vSphere HA将不采取行动，PDL对虚拟机的影响可能不会重新启动。

Frimley数据中心全计算能力发生故障

在这个场景中，我们在Frimley数据中心通过模拟移除站点内所有主机的电源来测试全计算能力发生故障。

图179：全计算能力发生故障

结果

所有的虚拟机在Bluefin数据中心的主机上重新启动，注意使用的是Frimley的存储。

解释

Frimley数据中心全计算能力发生故障，vSphere HA主节点位于Frimley，一旦Bluefin数据中心检测到主机没有接收到网络心跳，马上开始选举过程，20秒内，一个新的vSphere HA主节点被从剩下的主机中选出，同时新的主节点决定哪些主机发生故障，哪些虚拟机受到故障的影响。当其它站点的所有主机发生故障，所有虚拟机受到影响，vSphere HA初始化重启所有的机器，vSphere HA能在一个主机上同时初始化32个虚拟机，为大多数的环境提供一个较低的重启延迟。启动的顺序来自于HA的高，中和低级别，规则必须给予每虚拟机，这些规则被坚持，高优先级虚拟机首次启动，其次是中，低优先级的虚拟机。

作为测试的一部分，我们再次开启Frimley数据中心的主机，vSphere DRS马上检测到这些主机再次可用，一个vSphere DRS被调用运行。执行初始化DRS只解决了vSphere DRS关联规则的冲突，导致资源不平衡并没有纠正，知道下一次调用vSphere DRS。DS默认每5分钟调用一次，或者当虚拟机通过vCenter客户端关闭/开启电源。

Frimley 数据中心丢失

在这个场景中，模拟了Frimley数据中心完全故障

图180：数据中心丢失

结果

所有Frimley数据中心的虚拟机成功在Bluefin数据中心重启

解释

在这个场景中，Bluefin数据中心的主机同vSphere HA主节点丢失了联系，于是选举出新的vSphere HA主节点。当存储系统发生故障，再次由于NetApp特别的过程，“take over”命令必须在存在的站点初始化。“take over”命令初始化以后，新的vSphere HA主节点访问每个HA用来记录保护的虚拟机的数据存储文件，vSphere HA主节点此时尝试重新启动这些没有在Bluefin数据中心存在的主机的虚拟机。在我们的场景中，所有的虚拟机在发生故障的两分钟之内重新启动，有完全访问和功能。注意：默认vSphere HA在30分钟后可能停止尝试启动虚拟机。如果存储组没有发生问题时间任务中的“take over”命令，一旦存储可用vSphere管理员将需要手工开启虚拟机。

如果新选择的master仍然连接着vCenter，就有一个轻微的差距，尽管在大多数环境中不可能发生，如果发生vCenter将告诉新的主节点发生故障，虚拟机不能与已存在的数据中心的主机兼容，这样就不能初始化虚拟机，当他们再次兼容时再告诉主节点。如果主节点知道虚拟机不兼容，它将不尝试重启它们。主节点不会初始化重启但将等待主机变得兼容，然后尝试重新启动。