我读了很多关于高可用性虚拟化的文章，无论是通过 Hyper-V 还是 VMWare。在这种情况下，高可用性本质上意味着虚拟机由一组物理服务器（节点）托管，因此如果其中一个物理服务器发生故障，虚拟机仍可由其他物理服务器提供服务。到目前为止一切顺利，物理集群和虚拟机本身都是高可用性的。
但是，如果所提供的服务（比如 SQL Server、MSDTC 或任何其他服务）实际上是由 VM 映像和虚拟化操作系统提供的。因此，我认为虚拟层仍存在未考虑的故障点。虚拟机本身可能会发生物理群集无法解决的某些问题，对吗？在这种情况下，物理故障转移群集 (Hyper-V) 或 VMWare 主机无法进行故障转移，因为问题不在于物理群集中的某个服务器 - 对物理节点进行故障转移不会带来任何好处。
这是否需要在物理故障转移群集上构建虚拟故障转移群集，还是没有必要？
或者，我想您可以跳过物理集群，而只在虚拟层（基于子级的故障转移集群）进行集群，因为它仍然可以承受物理故障。
参见下图，其中显示了基于父母（左）、基于子女（右）和组合（中）。基于父母是否已经足够，还是基于子女更合适？
答案1
答案是视情况而定。
集群解决方案通常比应用层做得更多。传统上，集群依赖关系图将包括以下内容：
- 网络/IP 可用性检查
- 存储/共享卷可用性。
在虚拟机内部运行这些检查中的一些非常困难。例如，在 Windows 2003 群集中，它需要一个使用 SCSI 锁的仲裁驱动器，以确保它是资源的所有者。发生故障时，它还会发送“毒药包”以获取该锁。如果没有 RDM 到 LUN，所有这些功能几乎都无法实现。
所有这些“硬件检测”组件在 VM 中都会产生很大的开销。（VM 性能对于用户应用程序来说总是很棒的，但任何内核基础都会产生不同程度的开销）。
因此，在 Microsoft Windows 2003 集群的情况下（我必须进行虚拟化，我会使用您的“子”方法）。
最理想的奋斗目标就是，
- VMware HA 用于硬件故障检测。
- vSphere 应用程序监控
其次是，
- VMware 高可用性
- 一个应用程序仅有的监视器（无硬件依赖）
- 确保配对的虚拟机启用了反亲和性，这样 DRS、HA 就永远不会在同一主机上重新启动节点！
最后
- 儿童聚类
答案2
物理集群使虚拟硬件具有高可用性，即物理服务器的故障不会影响任何给定的虚拟机。但是，虚拟机本身仍然可能会发生故障（例如操作系统崩溃、有人关闭虚拟服务器等），因此在虚拟机上运行的服务在某些时候仍可能会发生故障（尽管这种可能性比在独立物理硬件上运行的相同服务要小）。为了降低这种风险，您可以创建集群服务，这样即使虚拟服务器发生故障，服务也不会受到影响。当然，如果您直接在物理服务器上构建集群服务，您可以获得大致相同的结果。
您是否在物理服务器上或集群虚拟化平台上运行集群服务取决于您的需求。如果您不需要虚拟化平台来做其他事情，或者集群服务需要大量系统资源，那么我建议在物理硬件上构建集群。但如果您的物理硬件有多余的资源，或者您已经有一个虚拟化集群，我会在虚拟机上运行集群服务，因为这样可以更轻松地管理（虚拟）硬件。
答案3
不过，别忘了在这一过程中接受现实。
您需要了解应用程序所需的正常运行时间，更重要的是，了解应用程序发生故障时最长时间的不可用时间。而且确实会这样。
第二点至关重要；我曾见过一家大型系统集成商管理的“五个九”应用程序，由于用于保持其高可用性的技术过于复杂，该应用程序离线了近一天。对于日常运营可用性，该技术满足要求，但当配置出现问题时，上述公司的人员就陷入了困境。
请不要误会我的意思，集群、SAN 快照、VM 快照、异地复制、HA 锁步虚拟化等都有其用途，但请确保您选择所需的，而不是看起来漂亮和闪亮的。
我现在要从我的肥皂盒里走下来了；-)
答案4
您首先必须构建一个高可用性系统（用于 SQL、用于操作系统等）。这意味着您必须拥有多台物理或虚拟计算机，并且必须使用能够支持高可用性的软件。
完成此操作后，您可以使用高可用性虚拟化系统，它“仅”保护您免受硬件故障的影响。
第二级高可用性需要 2 台物理计算机（或更多）。
因此，假设您的第一级高可用性由 2 台计算机完成：您现在无需担心第二级，因为它不会给您带来任何更好的效果。