这是我刚才问的一个问题的重新散列 – 在一个顾问向部门的其他团队发出想法之后，整个问题又被提了出来，因此我正在寻找更详细的答案。
我们打算在多个物理刀片上设置一个多实例SQL集群，这些物理刀片将在每个SQL实例上运行各种不同的系统。 一般情况下，每个VM主机上将运行一个虚拟SQL实例。 再一次，在一般操作中，每个VM主机将运行在专用的底层刀片上。 安装应该给我们很大的灵活性来维护任何单独的虚拟机或底层刀片，所有的SQL实例都可以根据需要进行故障切换。
我原来的计划是要做到以下几点：
顾问build议我们改为：
最大的不同之处在于增加了第4步，即我们也将所有访客虚拟机集群在一起。 由于我们在SQL集群和物理硬件之间根本没有任何联系，所以它进一步改进了维护。 我们理论上可以在客户机周围实时迁移客户虚拟机，而不会影响SQL集群，所以我们需要日常维护物理刀片来移动SQL集群而不会中断，也不需要进行故障切换。
这听起来像个不错的主意，但是我还没有在互联网上遇到任何人说他们已经这样做，而且工作正常。 我可以实际进行客户端的实时迁移吗？
有没有人有这种设置的经验，好或坏？ 有没有我没有考虑的利弊？
我很欣赏镜像也是一个值得考虑的select – 在这种情况下，我们倾向于使用集群，因为它将完成每个实例的全部操作，并且我们拥有大量的数据库。 有些数据库是为了减轻第三方系统的负担，而这些系统甚至可能不适合与镜像工作（我对群集的理解是，失败对客户端来说是完全透明的）。
谢谢。
如果这些刀片式服务器将全部专门用于运行SQL Server，那么为什么还要虚拟化呢？
为什么不简单地在每台服务器上安装Windows Server和SQL Server，并相应地设置你的集群，而不会增加额外的虚拟化开销？
听起来很复杂。
我将不得不考虑您的解决scheme的“复杂性”，以及bog标准物理集群SQL服务器实现的可靠性和相对简单性。
所有的数据库任务关键？ 根据我的经验，通常不是，所以我倾向于将最重要的数据库托pipe在具有完整弹性的服务器上，其余的（通常是很大比例的）在简单的SQL服务器上。
这使您可以专注于保持最重要的系统运行，而不是试图保持“所有的球同时在空中”。
所有服务器都需要定期维护。 考虑到安全补丁的规则性，严重性和重要性，我们已经摆脱了试图保持一个理论上的正确时间（用户喜欢，但并不真正需要）到一个更现实的“我们将保持服务器的安全并且安全 – 但是会有很短的MANDATORY维护窗口，以便我们能够正确地修补服务器。“
在列出的选项中，我select了＃2，但是我不会对SQL进行集群（步骤5），因为它增加了一层您从中获益不多的复杂性。 Hyper-V集群已经允许您在任一主机上运行该虚拟机，这样就可以解决硬件故障。
我假设你打算使用固定大小的VHD作为SQL日志和数据库卷。
我完全理解了其他人关于跳过Hyper-V的意见，只是将2个刀片作为一个普通的SQL集群使用 – 这当然是传统的方法。 但是，虚拟化工作负载的灵活性优势对维护，升级和硬件故障来说是巨大的。 虚拟机的可移植性非常吸引人。
请注意，这个解决scheme的价值也取决于你的环境。 如果您没有其他的Hyper-V服务器，并且您的员工对Hyper-V不熟悉，那么虚拟化您最关键的工作负载可能不是一个好主意。 但是，如果您像许多IT部门一样开始虚拟化不重要的服务器，则已经构build了几台主机，并具有可靠运行Hyper-V的技能和过程，将重点扩展到更关键的工作负载是完全合理的。 就我个人而言，我宁愿在主机级别与SQL级别上进行集群pipe理，我想我们会发现这种做法越来越多，尽pipe它还不常见。
最后，关于在Hyper-V上运行SQL的问题：是的，实时迁移对于SQL来说可以正常工作，并且不会注意到 – AND – SQL数据库镜像非常好，但是没有普遍支持，所以不适合每个情况。
你顾问的设置的好处是，如果你只是硬件故障转移，它不会保护你免受错误的服务或不。 在硬件和软件上都有冗余是很好的，所以如果你问我，我会select2（当然，考虑到你有预算和知识）
我认为你的顾问是对的。 我有他的确切想法，我希望在当前的环境中实施。 2个物理硬件，每个硬件运行2个W2k8安装的Hyper-V。
这将在SQL环境中为您提供完整的failiver集群级别和完整的H / A级别。
或者，也许我的想法是愚蠢的？
对于nic问题，你应该能够解决这个问题，我不知道你的硬件是什么，但是有很多这样的问题，比如戴尔的Power Edge，1950年代，2950年代，R710等等。只有nic，并且在HyperV时不能正确地发送stream量。 最新的驱动器和正确的组合configuration不仅会提供额外的冗余，还会提高性能。
真的选项1和选项2是非常接近相同的事情。 最大的问题是你想如何访问你的数据，你的SAN是为什么devise的。 SQL 2008在跨群集共享卷的虚拟化中运行时性能实际上有所提高，并且再次对SQL进行群集，原因是SQL足够聪明，可以将其进程卸载到多个SQL节点。 这不仅可以大大提高性能（想象一下，当intel首次推出真正的超线程技术时），还可以通过分离stream量并使用数据包redirect来提高高开销networking的基础架构性能。