我们即将实施我们的Dynamics AX安装。 我们的目标是提供高可用性，并与我们的实施者密切合作。
我们向他们提出了关于SQL和Hyper-V集群的问题。 他们build议，在完整的虚拟化平台上运行时，没有必要在应用程序层（SQL）虚拟化，只需在Windows Server中设置Hyper V群集，然后在LUN上创buildSQL和所有其他相关应用程序虚拟机，以便后端存储（在我们的情况下，HP P2000），并使用CSV以高可用性模式运行VHD文件。
这是真的？ 还是应该在VHD级别分别对SQL进行聚类？
非常感谢！
他们build议，在完整的虚拟化平台上运行时，没有真正的理由在应用层进行虚拟化
这是潜在的危险build议。 Hyper-V集群可以在发生硬件故障时实现高可用性，就是这一切。
客户机内集群允许在发生BSOD，Windows更新失败，应用程序故障或任何其他与硬件无关的故障模式的情况下实现操作系统级高可用性。 它还允许您修补这些系统和应用程序，而不会导致应用程序停机，这对于像Dynamics安装那样可能很重要。
在使用虚拟机pipe理程序级集群时，有很多configuration在添加客户机内部集群时没有意义，因为您可以在发生操作系统故障时从备份中恢复，但是由于这种configuration从不需要，因为虚拟机pipe理程序的集群完成是粗略的build议。 串联使用时效果最好。
他们build议，当在完整的虚拟化平台上运行时，没有真正的理由在应用层进行虚拟化
无能。 像这样
这完全取决于你的要求。 而你如何做到这一点。
SQL Server级别的标准集群是主动/被动的，当另一个失败的时候会重新启动sql server实例，但是这应该比重启虚拟机要快。
SQL Server替代scheme是高可用性组，并且具有2个索引的好处，所以如果服务器取下数据库文件，则另一台计算机可以接pipe。 不需要共享存储。
这真的取决于你需要什么。
这也需要修补;）当你修补包含SQL Server的虚拟机时 – 可能是停机。 你能做到吗？ （计划停机时间，维护时间）。
一般来说，你所说的“没有真正的原因”是无能或者不好的沟通 – 有很多原因。 问题是他们是否与你有关。 我们不能决定。 但有一个很好的理由不使用CSV，并在SQL Server中为高可用性组使用复制的本地存储。