在这种情况下是否应该发生 HA 故障转移?

在这种情况下是否应该发生 HA 故障转移?

我在跨两个主机(vsphereA 和 vsphereB)的 HA 群集中运行 vSphere 5。我已将 HA 群集配置为主机监控和数据存储心跳监控,并禁用了准入控制(希望我理解正确,数据存储心跳监控可防止由于管理网络隔离而导致的无意和不必要的 HA 故障转移)。每个主机都与专用 iSCSI 网络和 iSCSI 目标(无 MPIO)有单一连接。所有 VM 的所有 vmdk 都存在于 iSCSI 数据存储中。作为 HA 测试,我断开了 vsphereB 上的 iSCSI 连接,并惊讶地发现 vsphereB 上运行的 VM 继续在 vsphereB 上运行。关闭的 VM 显示为不可访问(这是我预料到的,因为它们没有运行,并且从 vsphereB 到 iSCSI 目标的连接已切断),但正在运行的 VM 继续运行并继续由 vsphereB“拥有”。我期望看到这些虚拟机发生 HA 故障转移,并期望在 HA 故障转移后看到它们由 vsphereA“拥有”(但并未发生)。我不明白为什么这些虚拟机没有发生 HA 故障转移。我是否误解了在哪些情况下应该发生 HA 故障转移?

答案1

您似乎混淆了 vMotion 和 HA,它们是执行不同操作的不同功能。

vMotion 是一种功能,允许虚拟机从一台物理主机迁移到另一台物理主机,而无需停机,服务中断时间最短(毫秒)。提前维护,并且要求 VM 以及源主机和目标主机都处于健康状态。HA 是一种重新启动发生故障的虚拟机(或配置了主机隔离时无法访问的虚拟机)的功能,并且会导致 VM 停机,因为整个虚拟机都会关闭并重新启动。

重要提示:vMotion 不是 HA 故障转移。HA 故障转移就是 HA 故障转移。

vMotion 由以下因素触发:

  1. 用户启动 vMotion
  2. DRS 启动 vMotion 以响应负载条件(由 DRS 主动性设置设定的阈值)、亲和性规则违规或通过 VUM 触发的主机更新

HA 故障转移由以下因素触发:

  1. HA 群集中的一台主机检测到群集中的另一台主机发生故障,并且未使用配置的管理网络或检测信号数据存储响应 HA 检测信号
  2. 隔离响应配置为关闭或关闭虚拟机,并且主机不再能够与大多数集群节点通信,从而触发虚拟机关闭以及随后集群剩余大多数节点的 HA 故障检测(如果有的话,这是隔离响应的危险之一)
  3. 集群/虚拟机已配置为通过 VMware Tools 进行虚拟机监控,虚拟机管理程序在特定时间内未收到心跳,并且 120 秒内未发生任何磁盘或网络活动

底线:vMotions 因性能事件而发生,而 HA 故障转移因可用性事件而发生。

您所做的就是从正在运行的虚拟机下方拉出磁盘。在这种情况下,vSphere 和大多数虚拟机管理程序的标准行为是让虚拟机独自处理磁盘问题。这样做有几个很好的理由:

  1. 如果底层磁盘停止响应,某些操作系统/发行版(例如 pfSense)仍能正常工作
  2. 同时启动几十台虚拟机往往会产生“惊群效应”问题——在本来就存在问题的存储上这样做可能并不是最好的主意
  3. 与交换一样,操作系统(和应用程序)通常比虚拟机管理程序更好地处理存储问题
  4. 有时存储会突然挂起——它是大多数虚拟化环境中最容易出现故障的组件。最好尝试检测它并发出警报,让管理员弄清楚如何处理它,然后再启动整个环境

另一方面,对于许多工作负载(比如数据库),一旦出现损坏或丢失事务的可能,最好立即关闭。不过,在最好的情况下,由于您无法在没有磁盘的情况下彻底使数据库静止,因此无论如何您最终都可能处于不一致的状态。

最终:HA 响应不可靠的存储有一些很好的用例,但它今天还没有做到这一点,而您看到的行为是完全正常的。

相关内容