HA配置不当可导致灾难性后果

ormosia

有一个小VI3环境, 配置也很简单:

ESX01 - (SC IP: X.X.X.90, SC GW: X.X.X.10)
ESX02 - (SC IP: X.X.X.91, SC GW: X.X.X.10)
VC01 -  (IP: X.X.X.51, GW: X.X.X.10)
GW 是一个ROUTER的口地址.

ESX01与ESX02同属于一个HA/DRS cluster. 各运行10台VM

他们计划为ESX01添加一块网卡:

1. 首先将ESX01上的10台VM VMotion到ESX02
2. 关闭ESX01, 添加网卡
3. 启动ESX01
4. 将10台VM VMotion回到ESX01上.

第一步VMotion成功, 20台VM在ESX02上正常运行.  接着他们在ESX01的service console上将ESX01 shutdown, 安装网卡的过程中, 却发现原来在ESX02上正常运行的20VM全部被关闭了. 他们判断可能是ESX02的资源分配有问题. 手动启动了一些VM, 可是过不久, 启动后的VM又被ESX02关闭. 情急之下, 他们开始向其他部门求援. 我们分析象HA出现所谓的\"脑裂\"现象, 提示他们赶紧放弃trouble shoot ESX02, 立即启动ESX01, 果然, ESX01启动之后, ESX02不再自动关闭VM. 系统逐渐恢复正常.

分析原因:

1. 从service console shutdown ESX01, ESX01并没有退出HA cluster (应该在VC上先进维护模式在shutdown)

2. 由于ESX01/ESX02同处与一个HA cluster, 他们互相检查对方的状态.

3. 当ESX01被关闭后, ESX02发现失去与ESX01的联络, 这时ESX02要判断是ESX01出了故障还是ESX02本身出故障.

4. ESX02默认的的判断方式是PING SC 的网关 (可以手动设置成其他地址), 如果回应了, 则认为是ESX01出现问题, 如果没有回应, 则认为自己被孤立了(本机出现网络故障), 如果被孤立, ESX02就会关闭所有的VM, 释放对这些VM的盘文件的锁定, 以便让ESX01接管对这些VM的控制. 碰巧他们的SC 网关又被设置成不响应ICMP. 这下, 所有能出问题的地方的都出了问题, ESX02得不到来自ESX01及SC网关的响应, 认为自己是被孤立了, 便开始关闭VM.

其实这时候个轻易避免的错误: ESX01进入维护模式; 暂停HA; 开启SC GW的ICMP响应; 指定其他的故障检测地址; 或是将\"孤立\"默认响应从\"关闭VM\"改成\"维持VM运行\". 做了其中的任何一项都能避免问题的出现.

1. 知道的, 能导致VM关机的机制好象只有HA.

2. HA主要依靠ESX之间及与\"孤立\"检测地址之间的heartbeat/ping来判断ESX彼此的运行状态. 网络故障或由于ESX SC繁忙导致的包延时或丢失. 有可能导致误判.

3. A故障, B运行的情况下, B可能一直在测试(不知道是不是一直在测)那个\"孤立\"地址.

4. 选择取消HA的时候, 在B的SC和VC上, 好象都有不少操作(修改设置), 如果这些操作导致B的SC或网络繁忙以至ICMP包不能按时传送接受, 如果此时HA服务还没完全停止, 是否会导致误判? 如果该错能重现, 对查看一下HA的LOG, 可能会有些线索
两种选择各有利弊. CLUSTER的默认设置是\"VM POWER OFF\" (不知道VI 3.5是否有改变). 如果改成\"VM POWER ON\", 则当ESX孤立的时候, VM无法HA到其他ESX上.

维持默认\"VM POWER OFF\", 最大的危险是, 如果你网络维护, 又没有冗余配置, 或FAIL-OVER时间大于10秒, 这个区域内的所有ESX通信中断, 也无法连通\"孤立\"测试地址, 他们可能会将VM POWER OFF, 因为不是正常的SHUTDOWN. 有可能导致VM OS/应用的破坏. 尤其是TRANSATION BASED的应用

在VMTN上看到过, 在交换机FIRMWARE升级时, 几百个VM突然被POWER OFF的例子.
VMWare的HA最少应该有三台服务器的，个人看法。

云杉上的蝴蝶

只少2台共享存储和3台ESX 主机才靠谱！