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