我们目前有一个带有两个节点的故障转移 sql 集群。对于我们确定对业务至关重要的新大型项目，我们的开发团队正在请求一个新的 2 节点故障转移 sql 集群。
我们的服务器部门回应说他们不想为我们实施集群，而是雇用多个虚拟机，每个虚拟机都安装了 SQL 服务器，指向同一个磁盘，所以如果一个失败，他们要么将其移动到新主机，或者将另一个图像打开，因为它指向同一个磁盘，所以数据将保持不变。
我不是 sql server 专家，只了解基本级别的集群，但有些事情告诉我，他们提出的这个虚拟机“想法”并不完全是企业解决方案。对我来说，这听起来很像米奇老鼠。我要出去吃午饭吗？我可以用什么样的论据来支持我的观点？
为了确定是采用虚拟解决方案还是集群解决方案，需要详细说明容错要求。解决方案是否需要适应硬件故障、存储故障或实例故障？如果服务器出现故障，恢复过程应该有多简单/复杂？计划的硬件资源利用率是多少？
虚拟和集群解决方案都将提供硬件故障容错。SAN 存储可能会覆盖存储容差。
应用程序是否需要在失败后立即启动？如果它在半夜失败，需要什么级别的交互来恢复应用程序。它应该是自动的还是手动的？如果它需要自动化，是否应该将其内置到技术中或周围编码的东西？
根据上述问题的答案，虚拟或集群解决方案可能满足高可用性的需求。我建议列出要求，并且通常会指出适合的解决方案。
抱歉，答案主要是问题，但他们会为您指出适当的解决方案。
我同意你的看法 - 如果它们指向同一个磁盘，如果（何时）该磁盘发生故障会发生什么？
如果他们谈论的是 SAN 而不是实际的磁盘，那么如果您假设 SAN 具有适当的容错能力，那么这可能是一个不错的解决方案。
一切都是为了钱！虚拟机通常也位于具有多个群集节点的 SAN 上，例如，如果您有一台带有大量虚拟机的 ESX 服务器。因此，如果您有一个带有 SAN 后端的 4 节点虚拟机集群，您可能可以在其中安装 40 个虚拟机。你仍然是容错的，等等。
但是，经过 SQL Server 的虚拟化，它是缓慢的、纯粹的和简单的。我们没有获得 IOPS 或足够的内存和 CPU。如果您需要良好的性能，例如进行大容量压力测试，请选择集群。请记住，您需要 2 台服务器、SAN 存储以及 SQL/Windows 许可，因此您需要进行一场艰苦的战斗。:-(
我想我在这个问题上被撕裂了。作为一名 DBA，我喜欢我的服务器执行。我们的测试服务器仍然需要这个，但我们的开发服务器通常不会太忙。你需要表演吗？（当然，谁会说不）
其实这是很普遍和可行的。虚拟机上的集群解决方案部署起来很便宜。更重要的是，SQL Server 实际上在 Hyper-V 上得到官方支持：
在 Windows Server 2008 R2 和 Windows Server 2008 Standard、Enterprise 和 Datacenter 版本中以 Hyper-V 角色运行的虚拟机环境中支持 SQL Server 2008。
唯一的问题是性能。显然，基于 Hyper-V 的部署比在裸机上的部署要慢，但我已经看到许多站点在 VM 上运行良好。