![SQL 群集或 Hyper V 群集](https://linux22.com/image/628136/SQL%20%E7%BE%A4%E9%9B%86%E6%88%96%20Hyper%20V%20%E7%BE%A4%E9%9B%86.png)
我们很快将实施 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 中的高可用性组服务。