我们很快将实施 Dynamics AX 安装。我们的目标是实现高可用性，并且我们正在与实施者密切合作。
我们向他们提出了有关 SQL 和 Hyper-V 群集的问题。他们建议，在完全虚拟化的平台上运行时，没有必要在应用程序层 (SQL) 进行虚拟化，只需在 Windows Server 中设置 Hyper V 群集并在后端存储的 LUN 上创建 SQL 和所有其他相关应用程序 VM（在我们的例子中是 HP P2000），然后使用 CSV 在高可用性模式下运行 VHD 文件即可。
这是真的吗？还是我们应该在 VHD 级别单独对 SQL 进行集群？
非常感谢！
答案1
他们建议，在完全虚拟化的平台上运行时，没有必要在应用程序层进行虚拟化
这是潜在的危险建议。Hyper-V 集群可在发生硬件故障时实现高可用性 - 仅此而已。
在发生 BSOD、Windows 更新失败、应用程序故障或任何其他与硬件无关的故障模式时，来宾内群集可实现操作系统级高可用性。它还允许您修补这些系统和应用程序，而不会导致应用程序停机，这对于 Dynamics 安装之类的操作可能很重要。
在许多配置中，使用虚拟机管理程序级集群时，添加客户机集群是没有意义的，因为在发生操作系统故障时，你可以从备份中恢复，但要说这是绝不因为集群是在虚拟机管理程序上完成的，所以需要使用它们，这充其量只是粗略的建议。它们在串联使用时最有效。
答案2
他们建议，在完全虚拟化的平台上运行时，没有必要在应用程序层进行虚拟化
无能。就这么简单。
这完全取决于您的要求。以及您如何实现。
SQL Server 级别标准集群是主动/被动的，当另一个实例出现故障时，它将重新启动 SQL Server 实例，但这仍然比重新启动 VM 更快。
SQL Server 替代方案是高可用性组，它具有 2 个存储的好处，因此如果一台服务器发生故障导致数据库文件崩溃，那么另一台机器可以接管。无需共享存储。
这确实取决于你需要什么。
这需要也取决于修补；）当您修补包含 SQL Server 的 VM 时 - 这可能是停机时间。您可以这样做吗？（计划停机时间、维护窗口）。
通常，“没有真正的原因”就像你说的，要么是能力不足，要么是沟通不畅——原因有很多。问题是它们是否与你有关。我们无法决定。但有充分的理由不使用 CSV 并使用复制的本地存储来为 SQL Server 中的高可用性组服务。