我一直在阅读有关在 Hyper V 环境中运行 SQL 群集的信息，似乎有几个选项：
在 2 台虚拟机上安装来宾群集，这两台虚拟机本身是故障转移群集的一部分。
在 2 台虚拟机上安装 SQL 集群，但虚拟机本身不是底层集群的一部分。
对于选项 1，情况会稍微复杂一些，因为实际上有两个集群在运行，但这增加了一些灵活性，因为我可以自由地在集群之间的虚拟机和物理刀片之间迁移以进行物理维护，而不会影响在其中运行的 SQL 客户集群的状态。
对于选项 2，设置会更简单一些，因为混合中只有 1 个集群，但我的虚拟机固定在它们设置的物理刀片上（为了回答这个问题，我将忽略我可以手动移动 VHD 的事实）。
在决定选择哪个选项时，我还应该考虑其他因素吗？
我可以自由地测试这两种选择，而且可能都会这样做，但如果有人有这些设置的工作经验并能提供一些意见，那就太好了。
编辑：
关于添加镜像以添加数据库的第二个副本，提出了很好的观点。我正在考虑是否只使用 2 个 SQL 实例并单独使用镜像，因为这个后端将用于单个应用程序，因为对于用户等来说它将是一个相当稳定的设置。
不过，这个问题的重点具体与集群设置有关。也就是说，
a) 在 Hyper V 主机上，构建虚拟机的故障转移群集，然后在虚拟机内部设置第二个群集，并在主机群集之上安装 SQL 群集 - 客户群集
或者
b) 只需在虚拟机内设置 SQL 集群，而无需在主机 Hyper V 机器上设置底层故障转移集群。
我见过支持这两种选择的人，但我真的不明白每种方法的优缺点。
答案1
使用 2，然后使用 MIRRORING 实现高可用性。这为您提供的不仅仅是一个 SQL 集群，因为它为您提供了两个数据副本。
这是 SQL 群集的一个弱点 - 如果数据库因某种原因损坏数据库文件而死机（这种情况确实会发生 - 虽然并不常见，但如果您追求高可用性，您就不会想要这种情况），那么群集就会发生故障转移，新启动的 SQL 进程....将不会加载数据库或崩溃。
通过镜像，第二台服务器可以选择它自己的数据副本。
建议使用第三个（小型）SQL 服务器作为“见证”（这样就有 3 个实例，使故障转移更加稳定）。
就我个人而言，我认为（在微软的 MS SQL Server 支持部门工作了几个月后）在第一道防线中使用 SQL 群集来实现高可用性几乎是严重疏忽。在 3 个月内，我几乎每个月都会遇到一次故障转移因各种原因而失败的情况（其中一个原因包括 SAN 系统崩溃时保存数据）。这确实让您感激镜像实例的双重生命数据副本。
答案2
假设您正在运行 Windows 2008 R2 和 SQL 2008，那么：
设置起来并不难，一旦你的存储和主机集群完成，只需几分钟就可以配置 sql 集群。
实时迁移也不是一个坏的解决方案，这样你就不会被固定在集群内的刀片上。