SQL 集群或 VM 映像
我们目前有一个具有两个节点的故障转移 SQL 集群。对于我们确定对业务至关重要的新大型项目，我们的开发团队正在请求一个新的 2 节点故障转移 SQL 集群。
我们的服务器部门回应说他们不想为我们实现集群，而是雇用多个虚拟机，每个虚拟机都安装了SQL Server，指向同一个磁盘，所以如果一个失败，他们要么将其移动到新主机，或者调出另一个映像，因为它指向同一个磁盘，所以数据将保持不变。
我不是 sql server 专家，只了解基本水平的集群，但有些事情告诉我，他们提出的这个虚拟机“想法”并不完全是一个企业解决方案。对我来说，这听起来很漂亮米奇老鼠。我出去吃午饭吗？我可以用什么样的论据来支持我的观点？
We currently have a failover sql cluster with two nodes. For a new large project which we have determined to be business critical, our development team is requesting a new 2 node failover sql cluster.
Our server department has responded saying that they do not want to implement a cluster for us, and instead employee multiple virtual machines, each with SQL server installed, pointing to the same disk, so if one fails, they either move it to a new host, or the bring the other image up instead, and because it's pointing to the same disk the data will remain intact.
I'm no sql server expert, and only understand clustering on a basic level, but something tells me that this VM 'idea' they came up with is not exactly an enterprise solution. It sounds pretty Micky Mouse to me. Am I out to lunch here? What kind of arguments can I use to support my view?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
为了确定是采用虚拟解决方案还是集群解决方案，需要详细说明容错要求。该解决方案是否需要适应硬件故障、存储故障或实例故障？如果服务器宕机，恢复过程应该有多简单/复杂？计划的硬件资源利用率是多少？
虚拟和集群解决方案都将提供硬件容错能力。 SAN 存储可能会涵盖存储容差。
应用程序是否需要在失败后立即启动？如果它在半夜失败，需要什么级别的交互才能使应用程序恢复。应该自动还是手动？如果需要自动化，是否应该将其内置到技术中或进行编码？
根据上述问题的答案，虚拟或集群解决方案可能满足高可用性的需求。我建议列出要求，并且通常会指出适合的解决方案。
抱歉，答案主要是问题，但它们会为您指出适当的解决方案。
In order to determine whether to go with a virtual or clustered solution the requirements for fault tolerance need to be detailed. Does the solution need to accommodate for hardware failure, storage failure, or instance failure? If the server goes down how simple/complex should the recovery process be? What is the planned hardware resource utilization?
Both virtual and clustered solutions will offer hardware failure tolerance. SAN storage will likely cover the storage tolerance.
Does the application need to come up immediately after a failure? If it fails in the middle of the night what level of interaction is needed to bring the application back up. Should it be automatic or manual? If it needs to be automatic, should this be built into the technology or something that gets coded around?
Depending on the answers to the questions above either the virtual or clustered solution may fit the needs for high availability. I'd recommend laying out the requirements and often that will point to the solution that fits.
Sorry the answer is mostly questions but they'll point you to the appropriate solution.
我同意你的观点 - 如果它们指向同一个磁盘，如果该磁盘发生故障会发生什么？
如果他们谈论的是 SAN，而不是实际的磁盘，那么如果您假设 SAN 具有适当的容错能力，那么这可能是一个不错的解决方案。
I would agree with you - if they point to the same disk, what happens if (when) that disk fails?
If they are talking about a SAN though rather than an actual disk, then it might be an OK solution if you assume that the SAN is properly fault-tolerant.
都是钱的事！虚拟机通常也位于具有多个集群节点的 SAN 上，例如，如果您有一台包含大量虚拟机的 ESX 服务器。因此，如果您有一个带有 SAN 后端的 4 节点虚拟机集群，您可能可以在其中容纳 40 个虚拟机。你仍然具有容错能力，等等。
但是，在经历了 SQL Server 虚拟化之后，它变得缓慢、纯粹且简单。我们没有获得 IOPS 或足够的内存和 CPU。如果您需要良好的性能，例如进行大量压力测试，请选择集群。请记住，您需要 2 台服务器、SAN 存储以及 SQL/Windows 许可，因此您将面临一场艰苦的战斗。 :-(
我想我在这个问题上很困惑。作为一名 DBA，我喜欢我的服务器的性能。我们的测试服务器仍然需要这个，但我们的开发服务器通常不会太忙。您需要性能吗？（当然，谁会说不）
It's all about money! VM's are usually also on a SAN with several cluster nodes as well, if you have, say, an ESX server with a lot of VMs. So, if you have a 4 node VM cluster with a SAN backend, you might be able to fit 40 VMs on there. You're still fault tolerant, etc.
BUT, having gone through virtualization of SQL Server, it was slow, pure and simple. We weren't getting the IOPS or enough memory and CPU. If you need decent performance, say, for high volume stress testing, go for the cluster. Keep in mind that you need 2 servers, SAN storage plus SQL/Windows licensing, so you have an uphill battle. :-(
I guess I'm torn on the subject. As a DBA, I like my servers to perform. Our test servers still need this, but our dev servers aren't usually too busy. Do you need the performance? (Granted, who would say no)
其实这种做法很普遍，也很可行。虚拟机上的集群解决方案部署成本低廉。更重要的是，SQL Server 实际上Hyper-V 已正式受支持：
唯一的问题是性能。显然，基于 Hyper-V 的部署会比裸机上的部署慢，但我发现许多站点在虚拟机上运行得很好。
Actually this is quite common and feasible. Cluster solutions on virtual machines are cheap to deploy. Even more, SQL Server is actually officially supported on Hyper-V:
The only question is performance. Obviously a Hyper-V based deployment will be slower than one on bare metal, but I've seen many sites running just fine on VMs.