SQL群集安装在Hyper V选项上

我一直在阅读在Hyper V环境中运行SQL集群,似乎有几个选项:

  1. 在2个虚拟机上安装guest虚拟机群集,这些虚拟机本身是故障转移群集的一部分

  2. 在2个虚拟机上安装SQL集群,但虚拟机本身不是基础集群的一部分。

使用选项1,它稍微复杂一些,因为有效地使用了两个群集,但是这增加了一些灵活性,因为我可以自由地迁移群集中的VM和物理刀片以进行物理维护,而不会影响SQL guest的状态在其中运行的群集。

使用选项2,设置更简单一些,因为混合中只有一个簇,但是我的虚拟机是锚定在他们设置的物理刀片上的(我会忽略我可以手动移动VHD为了这个问题的目的)。

在决定select哪个选项时,我应该考虑其他因素吗?

我可以自由地testing这两个选项,可能会做,但如果任何人有这些设置的工作经验,并可以提供一些将是伟大的投入。

编辑:

提出了关于添加镜像到混合添加数据库的第二个副本好点。 我正在考虑是否只使用2个SQL实例并单独使用镜像,因为这个后端将用于单个应用程序,因为它将相对于用户而言是一个相当稳定的设置。

这个问题的主要观点虽然是专门针对集群设置的。 即更好

a)在Hyper V主机上,构buildVM的故障转移群集,然后在VM内自行设置第二个群集,并在主机群集的顶部安装SQL群集 – 来宾群集

要么

b)只需在虚拟机中设置SQL群集,并且在主机Hyper V机器本身上没有基础的故障转移群集设置。

我见过这两种select的提倡者,但我并不真正了解每种方法的优缺点。

使用2,然后使用MIRRORING来实现高可用性。 这不仅仅是一个SQL集群,因为它提供了两个数据副本。

这是SQL Cluster的一个弱点 – 如果数据库以损坏数据库文件的方式死亡(并且发生了 – 不是经常发生,但是如果您为了高可用性而不想这么做),那么群集故障转移和新的启动SQL进程….将不会加载数据库或将崩溃。

使用镜像时,第二台服务器会自行select数据副本。

第三个(小)SQL服务器作为“见证”(这样有3个实例,使故障转移更稳定)被build议。

就个人而言,我认为(在微软的MS SQL Server支持上花费了几个月的时间),在第一道防线上使用SQL集群来实现高可用性是非常严重的问题。 在3个月内,我每个月都有一个案例因为各种原因(其中一个包括SAN系统数据在崩溃的时候)而失败。 这真的让你欣赏镜像实例的双重生活数据副本。

假设你正在运行Windows 2008 R2和SQL 2008,那么:

  1. 一旦你的存储和主机集群完成了它仅仅几分钟的时间来configurationsql集群,那么设置起来并不是很难。

  2. 实时迁移也不是一个不好的解决scheme,这种方式不会固定在集群内的刀片上。