我已经通过 Hyper-V 或 VMWare 阅读了很多有关高可用性虚拟化的文章。在这种情况下，本质上高可用性意味着 VM 由物理服务器（节点）集群托管，因此如果其中一台物理服务器出现故障，该 VM 仍可由其他物理服务器提供服务。到目前为止一切顺利，物理集群和 VM 本身都具有高可用性。
但是，如果所提供的服务，比方说 SQL 服务器、MSDTC 或任何其他服务，实际上是由 VM 映像和虚拟化操作系统提供的。所以我想虚拟层仍然存在未考虑的故障点。虚拟机本身可能会发生物理集群无法解释的事情，对吗？在那种情况下，物理故障转移集群 (Hyper-V) 或 VMWare 主机无法进行故障转移，因为问题不在于物理集群中的其中一台服务器 - 故障转移物理节点不会有任何好处。
这是否需要在物理故障转移集群之上构建虚拟故障转移集群，还是没有必要？
或者，我想你可以跳过物理集群，只在虚拟层集群（基于子故障转移集群），因为它仍然应该在物理故障中幸存下来。
请参见下图，其中显示了基于父项（左）、基于子项（右）和组合（中）。是根据您的需要以父母为基础，还是以孩子为基础更合适？
物理集群使您的虚拟硬件高度可用，即物理服务器的故障不会影响任何给定的虚拟机。但是，虚拟机本身仍然可能会失败（例如操作系统崩溃、有人关闭虚拟服务器等），因此在虚拟机之上运行的服务可能仍会在某个时候失败（尽管这种可能性比实际情况要小）用于在独立物理硬件上运行的相同服务）。为了减轻这种风险，您创建了集群服务，这样即使虚拟服务器发生故障，该服务也不会受到影响。当然，如果您直接在物理服务器上构建集群服务，您或多或少可以获得相同的结果。
您是在物理服务器上还是在集群虚拟化平台上运行集群服务取决于您的要求。如果您不需要任何其他虚拟化平台或集群服务需要大量系统资源，那么我建议在物理硬件上构建集群。但是如果你的物理硬件有空闲资源或者你已经有一个虚拟化集群，我会在虚拟机上运行集群服务，因为这使得管理（虚拟）硬件变得容易得多。
不过，别忘了沿途服用现实药丸。
您需要了解您的应用程序所需的正常运行时间，更重要的是，您的应用程序在出现故障时可以不可用的最长时间。它会的。
第二点很关键；我见过一个由大型系统集成商管理的“五个九”应用程序，该应用程序离线了将近一天，因为用于保持其高可用性的技术非常复杂。对于日常操作可用性，该技术符合要求，但当配置出现问题时，上述公司的人员就陷入了困境。
不要误会我的意思，集群、SAN 快照、VM 快照、异地复制、HA 锁步虚拟化等都有它们的用武之地，但只需确保您选择所需的，而不是看起来漂亮闪亮的。
我现在要离开我的肥皂盒了 ;-)
是的。
您首先必须构建一个高可用性系统（用于 SQL、操作系统等）。这意味着您必须拥有不止一台物理或虚拟计算机，并且您必须使用能够支持高可用性的软件。
完成此操作后，您可以使用高可用性虚拟化系统，它“仅”保护您免受硬件故障的影响。
第二级高可用性需要 2 台物理计算机（或更多）。
所以假设你的第一级高可用性是用两台计算机完成的：你现在不需要为第二级操心，因为它不会给你更好的东西。
我认为您已经掌握了可用性概念的本质。Hyper-v 和 VMware HA 功能均不向来宾提供 HA，仅提供虚拟化服务的 HA。根据来宾服务的可用性要求，您还需要来宾级别的 HA（并且取决于所涉及的技术可能意味着集群）。您需要评估每项服务，了解如何提供所需的正常运行时间的细节。例如，SQL 服务器可以使用事务镜像或服务器集群。很多时候，在虚拟服务上集群的额外开销和挑战超过了所提供的好处，这可能意味着服务最终将在专用硬件上提供。
答案是视情况而定。
集群解决方案通常比应用层做的更多。传统上，集群依赖图将包括以下内容，
在 VM 中运行其中一些检查非常困难。例如，在 Windows 2003 集群中，它需要一个使用 SCSI 锁的 Quorum 驱动器，以确保它是资源的所有者。如果失败，它还会发出“毒包”来获取该锁。如果没有对 LUN 的 RDM，所有这些功能几乎不可能实现。
所有这些“硬件检测”组件都会在 VM 中产生很大的开销。（VM 性能对于用户应用程序来说总是很好，但是任何基于内核的东西总是会产生不同程度的开销）。
所以在 Microsoft Windows 2003 集群的情况下（我不得不虚拟化我会使用你的“孩子”方法）。
理想的奋斗之地是，
其次是，
最后
如果你真的想要高可用性，你也需要集群你的高可用性虚拟机，是的。
如果您想避免每一个 SPOF，您将很难过。
我曾经参加过一个关于 NAS 系统的课程，他们告诉我们 NASA 就是这样做的——每件作品都存在三种不同的风格。只有其中至少两个结果相同，结果才可以。除此之外，一切都必须是多余的（在三个部分中的每一个）。
当然，在飞行前，所有三个都必须提供相同的结果。