遇到此问题时,必须终止虚拟机才能恢复数据存储。HA(如果已启用)应在其他主机上恢复这些虚拟机。如果必须重新启动管理代理,则暂时将无法通过 vCenter Server 管理主机。
计划内 PDL 与计划外 PDL 解析:
当试图移除向 ESXi 主机提供的设备时,将发生计划内 PDL。 必须首先卸载数据存储,然后分离设备,这样才能在存储阵列上取消提供该存储设备。 有关如何在 ESXi 5.x 中正确取消提供 LUN 的详细信息,请参见 如何从ESXi 主机卸载 LUN 或分离数据存储设备 (2072353) 。
如果意外从存储阵列取消提供存储设备,而未在 ESXi 主机上执行卸载和分离,则将发生计划外 PDL。
在 ESXi 5.5 中,VMware 提供了一种名为“自动移除”的功能,以便在计划外 PDL 期间自动移除设备。 有关详细信息,请参见 PDL AutoRemove feature in vSphere 5.5 (2059622)。
要清除计划外 PDL,请执行以下操作:
数据存储中所有运行的虚拟机必须关闭电源并从 vCenter Server 中取消注册。
从 vSphere Client 中,转到 ESXi 主机的配置选项卡,然后单击存储。
右键单击要移除的数据存储,然后单击卸载。
此时将显示确认卸载数据存储窗口。 如果符合必备条件,则会显示确定按钮。
如果您在卸载 LUN 时看到以下错误:
在 vCenter Server <name_of_vCenter> 上为对象 <name_of_LUN> 调用数据存储刷新失败
(Call datastore refresh for object <name_of_LUN> on vCenter server <name_of_vCenter> failed)
您可能提供了快照 LUN。 要解决此问题,请在阵列端移除该快照 LUN。
4. 在该 LUN 对其可见的所有 ESXi 主机上执行重新扫描。
注意: 如果存在对该设备或挂起 I/O 的活动引用,ESXi 主机在重新扫描后仍会列出该设备。 检查可能仍具有对该设备或数据存储的活动引用的虚拟机、模板、ISO 映像、软盘映像和裸设备映射。
5. 如果该 LUN 仍在使用中且再次可用,请转到每个主机,右键单击该 LUN,然后单击挂载。
注意: 计划外 PDL 的一个可能原因是 LUN 的空间不足,从而导致其变得无法访问。
Vc 6.0解决方案:
如果启用虚拟机组件保护 (VMCP),vSphere HA 可以检测到数据存储可访问性故障,并为受影响的虚拟机提供自动恢复。
VMCP 可防止发生数据存储可访问性故障,这些故障可能会影响 vSphere HA 群集中主机上正在运行的虚拟机。当发生数据存储可访问性故障时,受影响的主机无法再访问特定数据存储的存储路径。您可以确定 vSphere HA 将对此类故障作出的响应,从创建事件警报到虚拟机在其他主机上重新启动。
使用虚拟机组件保护功能时,ESXi 主机的版本必须为 6.0 或更高版本。
存在两种类型的数据存储可访问性故障:
PDL(永久设备丢失)是在存储设备报告主机无法再访问数据存储时发生的不可恢复的可访问性丢失。如果不关闭虚拟机的电源,此状况将无法恢复。
APD(全部路径异常)表示暂时性或未知的可访问性丢失,或 I/O 处理中的任何其他未识别的延迟。此类型的可访问性问题是可恢复的。
配置 VMCP
在 vSphere Web Client 中配置虚拟机组件保护。转到配置选项卡并单击 vSphere 可用性和编辑。在故障和响应下,可以选择处于 PDL 状态的数据存储或处于 APD 状态的数据存储。您可选择的存储保护级别以及可用的虚拟机修复操作根据数据库可访问性故障的类型而异。
PDL 故障
在处于 PDL 状态的数据存储下,可以选择发布事件或关闭虚拟机电源再重新启动虚拟机。
APD 故障
响应 APD 事件是更加复杂的,相应地配置是更加精细的。可以选择发布事件、关闭虚拟机电源再重新启动虚拟机 - 保守的重新启动策略或关闭虚拟机电源再重新启动虚拟机 - 激进的重新启动策略
针对APD和PDL的时间调度有几个周期,分别是:
APD说明:
0s - 此时APD会激活时间计数器;
140s APD - ESXi主机会生命APDTimeout然后会针对故障设备执行NON VM I/O激活Fast Fail动作。这个Timeout的周期可以被修改;
140-320s APD - APD Timeout的时间到达之后,这之前VMCP的Timeout已经到达。如果故障存储设备在这之前恢复正常,则可以通过对Response for APD recovery after APD timeout配置选项的配置来确保VM不会被强行重置;
320s APD - VMCP Timeout,同时激活Response for Datastore with All Paths Down(APD);
PDL说明:
0s PDL - VMs会立刻在正常ESXi主机上重新启动;
VMCP的Timeout时间会是320秒,里面包含了APD的默认140秒。VMCP组件的配置可以通过勾选vSphereHA设定选项中Protect against Storage Connectivity Loss选项来激活;
针对VMCP的配置选项如下:
VM restartpriority - VM重启优先级设定;
Response for Host Isolation - 主机被隔离时的响应方式;
Response for Datastore with Permanent Device Losss(PDL) - 三个配置选项,分别是Disabled、Issue events(不激活处理动作,只发通知讯息)、Power off and restart VMs(针对故障Vms尝试做重启动作);
Response for Datastore with All Path Down(APD) - 四个配置选项,分别是Disabled、Issue events(不激活处理动作,只发通知讯息)、Power off and restart(conservative)(受影响的Vms会被Kill掉,然后在连接正常的ESXi主机上重启。如果故障主机无法与Master主机通讯则将无法激活)、Power off and restart VMs(aggressive)(受影响的Vms会被Kill掉,无论是否有主机可以通过重启承载这些Vms。不论Master主机是否存在,是否能和其它主机通讯以及是否有足够的资源);
Response for APD recovery after APD timeout - 这个选项表示在APDTimeout(140s)之后VMCP Timeout之前(320s)存储设备恢复正常时的处理方式。它有2个可用配置选项,分别是:Disabled、Reset VMs(Vms会被强行于APD发生前所在主机重置);
如果禁用“主机监控”或“虚拟机重新启动优先级”设置,VMCP 将无法执行虚拟机重新启动。但是,仍可监控存储运行状况,且可发布事件。
APD的解决方案补充:
此问题已在 ESXi 6.0 Update 1(可从 VMware Downloads 获得)中得到解决。 有关详细信息,请参见 VMware ESXi 6.0 Update 1 Release Notes。
如果无法升级,没有其他措施可以保证在 APD 事件期间不会遇到此问题。 但是,出现此问题时有两种权宜措施可以恢复生产。
要临时解决此问题,请使用以下选项之一:
1、执行终止 LUN 的所有未完成 I/O 的过程。 有关非计划 PDL 的信息,请参见 Cannot remount a datastore after an unplanned permanent device loss (PDL) (2014155)。
2、 注意: 可能还需要重新启动 ESXi 管理代理。 有关详细信息,请参见 Restarting the Management agents on an ESXi or ESX host (1003490)。
3、重新引导卷处于“APD 超时”状态的所有主机。
其他补充:
当群集发生裂脑的状况时候,因为无法进行任何沟通而误会对方无法运作,所以主与备份服务器都会启动浮动IP和相关服务,此时若两部服务器对外连线亦未短线,那么势必导致有些使用者存取的是主要服务器,另外一些则存取备份服务器的情形。此外,如果两部服务器共享一个存储装置,发生裂脑时两部服务器会同时挂载该存储装置,亦同时存取相同的档案,因此若共享存储装备缺乏良好的锁定机制,更可能使得存储装置上的档案因同时读写而损坏。更有可能导致硬盘中写入不一致的信息,导致后期数据错误,甚至整个数据库损坏,后果不堪设想。
对付HA系统“裂脑”的对策,目前我所了解的大概有以下几条:
1)添加冗余的心跳线,例如双线条线。尽量减少“裂脑”发生机会。
2)启用磁盘锁。正在服务一方锁住共享磁盘,“裂脑”发生时,让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题,如果占用共享盘的一方不主动“解锁”,另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃,就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即,正在服务的一方只在发现心跳线全部断开(察觉不到对端)时才启用磁盘锁。平时就不上锁了。
3)设置仲裁机制。例如设置参考IP(如网关IP),当心跳线完全断开时,2个节点都各自ping一下参考IP,不通则表明断点就出在本端,不仅“心跳”、还兼对外“服务”的本端网络链路断了,即使启动(或继续)应用服务也没有用了,那就主动放弃竞争,让能够ping通参考IP的一端去起服务。更保险一些,ping不通参考IP的一方干脆就自我重启,以彻底释放有可能还占用着的那些共享资源。