高可用性虚拟机

Question

我通过 Hyper-V 或 VMWare 阅读了很多关于高可用性虚拟化的文章。在这种情况下，本质上的高可用性意味着 VM 由一组物理服务器（节点）托管，因此如果其中一个物理服务器出现故障，该 VM 仍然可以由其他物理服务器提供服务。到目前为止一切顺利，物理集群和 VM 本身是高度可用的。

但是，如果提供的服务，比如说 SQL 服务器、MSDTC 或任何其他服务，实际上是由 VM 映像和虚拟化操作系统提供的。所以我想虚拟层仍然存在未考虑的故障点。虚拟机本身可能会发生物理集群无法解释的事情，对吗？在这种情况下，物理故障转移群集 (Hyper-V) 或 VMWare 主机无法进行故障转移，因为问题不在于物理群集中的一台服务器 - 故障转移物理节点不会有任何好处。

这是否需要在物理集群之上构建一个虚拟故障转移集群，或者这不是必要的？

或者，我想您可以跳过物理集群，而只在虚拟层进行集群（基于子故障转移集群），因为它应该仍然可以在物理故障中幸免于难。

请参阅下图，显示基于父项（左）、基于子项（右）和组合（中心）。是根据您的需要以父母为基础，还是以孩子为基础更合适？

Answer 1

物理集群使您的虚拟硬件高度可用，即物理服务器的故障不会影响任何给定的虚拟机。但是，虚拟机本身仍然可能会失败（例如操作系统崩溃、有人关闭虚拟服务器等），因此在虚拟机上运行的服务在某些时候仍然可能会失败（尽管它不太可能发生）用于在独立物理硬件上运行的相同服务）。为了降低这种风险，您创建了集群服务，这样即使虚拟服务器出现故障，该服务也不会受到影响。当然，如果您直接在物理服务器上构建集群服务，您可以获得或多或少相同的结果。

您是在物理服务器上还是在集群虚拟化平台之上运行集群服务取决于您的要求。如果您不需要其他任何虚拟化平台，或者集群服务需要大量系统资源，那么我建议在物理硬件上构建集群。但是，如果您的物理硬件有空闲资源，或者您已经有一个虚拟化集群，我会在虚拟机上运行集群服务，因为这样可以更轻松地管理（虚拟）硬件。

Answer 2

不过，在此过程中不要忘记服用现实药丸。

您需要了解您的应用程序所需的正常运行时间，更重要的是，您的应用程序在发生故障时可能不可用的最长时间。它会的。

第二点很关键；我见过一个“五个九”的应用程序由一家大型系统集成商管理，该应用程序离线将近一天，因为用于保持其高度可用的技术的复杂性。对于日常操作可用性，该技术符合要求，但是当配置出现问题时，上述公司的人员就被卡住了。

不要误会我的意思，集群、SAN 快照、VM 快照、异地复制、HA 锁步虚拟化等都有其一席之地，但只要确保您选择所需的东西，而不是看起来漂亮和闪亮的东西。

我现在要离开我的肥皂盒了 ;-)

Answer 3

这是否需要在物理集群之上构建一个虚拟故障转移集群，或者这不是必要的？

确实如此。

Answer 4

答案是视情况而定。

集群解决方案通常不只限于应用程序层。传统上，集群依赖图将包括以下内容：

1. 网络/IP 可用性检查
2. 存储/共享卷可用性。

在虚拟机内运行其中一些检查非常困难。例如，在 Windows 2003 群集中，它需要使用 SCSI 锁定的仲裁驱动器来确保它是资源的所有者。发生故障时，它还会发出“毒数据包”来获取该锁。如果没有 LUN 的 RDM，所有这些功能几乎不可能实现。

所有这些“硬件检测”组件都会在虚拟机内产生大量开销。（虚拟机性能对于用户应用程序来说总是很棒，但任何内核基础总是会产生不同程度的开销）。

因此，对于 Microsoft Windows 2003 集群（我必须进行虚拟化，我会使用您的“子”方法）。

奋斗的理想之地是，

• 用于硬件故障检测的 VMware HA。
• vSphere 应用程序监控

其次是，

• 虚拟机高可用性
• 仅应用程序监视器（不依赖硬件）
• 确保配对虚拟机的反关联性处于启用状态，以便 DRS、HA 永远不会重新启动同一主机上的节点！

最后

• 子聚类