Microsoft SQL Server 2008故障转移群集在Hyper-V虚拟机上的多种组建方式

Hyper-V虚拟机给我们带来了诸多便利，比如应用程序整合、节能、节约成本、提高资源利用率等等。随着Hyper-V虚拟机的推广，用户的使用越来越普及。很多用户在Hyper-V虚拟机中用到了MS SQL Server。但是单独（standalone）的SQL Server 不能提供高可用性和灾难恢复的功能。在对可用性有较高要求的Hyper-V用户面前，故障转移群集（Failover cluster）是必然用到的功能。当虚拟的生产服务器宕机时，热备份中的虚拟的服务器可以很快投入工作中。 然而在虚拟机上搭建故障转移群集比在物理机上搭会有更多种组合。

本文中介绍各种搭建方式的优点和缺点。您可以在虚拟机上搭建SQL Server 故障转移群集以供学习与自娱。需要提醒的是，搭建需要满足如下前提条件：

Hyper-V要求的宿主机（host machine）必须是Windows 2008 x64 或 Windows2008 第二版 x64（差点忘了，用免费的securable软件可以检查你的宿主机CPU是否支持硬件虚拟化，2009年买的新机通常都是支持的）。虚拟机的操作系统可以是Windows 2003、Windows 2008、Windows 2008第二版（x64或x86）等不限。

熟悉Windows Cluster service的兄弟们都知道要搭建Cluster的机器必须拥有共享硬盘。Hyper-V还有个更严厉的要求：两个虚拟机搭cluster需要的共享硬盘必须是支持iSCSI的共享硬盘才行。可以是支持iSCSI的SAN或iSCSI的仿真软件（iSCSI Target和iSCSI Initiator）。 真实生产环境中的当然得买老贵的iSCSI SAN了。如果只是搭一个供自己欣赏或者搞个开发、测试环境的话当然是用仿真软件来仿真出几个共享硬盘省钱了，仿真软件可在网上搜索下载。有了仿真软件普通台式机就可以搭建，SCSI的物理设备可以统统不用。幸福吧？做过Cluster的老人们都还记得在Hyper-V出现之前，搭个故障转移群集有多麻烦，软件硬件都有特殊要求啊。

2节点的SQL Server故障转移群集是最常见的，更多节点的故障转移群集（最多16个）的搭建方式和2节点故障转移群集的搭建方式类似，所以在本博文中不讨论。

在Hyper-V虚拟环境中有很多种搭建故障转移群集的方式足有5、6种之多。哪种方式比较实用用户往往无所事从。本文中我们将分析虚拟环境中有很多种搭建故障转移群集的方式及其利弊，供各位IT兄弟们参考。为了描述清楚，各种搭建方式用A、B、C、D、E和F来编号。

方式A如下图

 
方式A 需要2台宿主机，两台宿主机的本地硬盘（例如E:）上各放着一个虚拟机的虚拟硬盘文件（.vhd），映射为虚拟机的操作系统C:。2个虚拟机在每个宿主机上分别启动，共同组建成一个SQL Server故障转移群集。可以看到2个虚拟机要用到iSCSI SAN了吧？ 那个就是共享盘。SQL Server跑在虚拟机Child1中，当Child1宕机的时候就会发生failover，共享盘Q:, R:就自动被第二台虚拟机Child2上的SQL Server抢到，第二台虚拟机上的SQL Server就开始工作了，如下图所示：

 
方式A是最容易想到的一种搭建方式。而且提供了高可用性的支持。如果有带冗余的网络和SAN, 可以用在生产环境中。（我可没说iSCSI仿真软件可以用在生产环境中啊，仿真软件感觉有点慢，而且没有冗余）

方式B如下图

 
方式A看起来有点费钱了，要2台物理机，想省物理机吗？那么试试方式B，您只要1台够了。既然每台宿主机可以同时跑多台虚拟机，我把2台组建SQL Server cluster的虚拟机跑在同一台宿主机上不就可以了? 如上图所示。如果你青睐iSCSI仿真软件，iSCSI SAN的钱也可以省掉，彻底的虚拟化了。你可以在唯一的宿主机上跑2个虚拟机的同时，宿主机还装了iSCSI Target可以模拟虚拟机所需要的共享盘。爽！

方式B的好处是，你可以把SQL Server cluster整个放到自己的笔记本中去。要演示SQL Server cluster怎么工作只要带着1个笔记本就够了（俺的笔记本是支持Hyper-V的 J，检查一下你自己的）。Cluster的2个节点及共享硬盘都是虚拟的。但是注意：这种方式省了不少钱也省了不少性能，而且不提供高可用性的支持，如果笔记本完了，覆巢之下焉有完卵， 你的SQL Server应用也无法健壮的挺起腰板啊。当然如果一个虚拟机去了，还是可以故障转移到另一个虚拟机的, 看下图。但如果宿主机坏掉会造成单点失败（Single point of failure）。小心啊！

方式C 如下图

方式C是一种奇特的设计，宿主机和虚拟机之间搭SQL Server cluster。当然这需要两台宿主机。

这种虚拟机和物理机之间的cluster有什么用？据我看起来可以作为一种临时的解决方案。例如某客户要把当前的2台物理机搭建的cluster改为2台虚拟机搭建的cluster，为了不打断正运行在物理机上的SQL Server生产环境（Active node）， 他可以先改造完Passive node再说。先把这台待命的物理机（Passive node）改造成虚拟机，然后做个failover, 让改造完的虚拟机（这时候变成了Active node）继续干活，再把另一台物理机（现在是Passive node）改造成虚拟机。这样在业务不中断的情况下完成了从物理机cluster到虚拟机cluster的升级。这样看来方式C也不失为一种升级时临时用用的方案了。升级到虚拟机时要用到SQL Server 2008中往cluster中添加以及删除节点的功能。 方式C也提供了高可用性的支持，如果2个机器中的一个宕机，不管是物理机还是虚拟机，故障转移的功能还仍旧能起作用，看下图：

方式D如下图

Windows 2008第二版的快要推出了，很多用户都迫不及待想用用其中的新版Hyper-V提供的一个很酷的功能——live migration。利用这一功能，用户可以在几秒钟之内很容易地把虚拟机从一台物理机挪到另外一台物理机上，而且虚拟机上运行的程序不中断。如果把live migration和failover cluster结合起来，就组成了方式D中更加健壮的cluster搭建方式。

方式D需要在2台物理机上建2台虚拟机。注意这种方式需要宿主机和虚拟机2个不同层次上搭建cluster。首先在2台物理机之间搭建Hyper-V 的cluster来支持live migration。虚拟机的虚拟硬盘文件（.vhd）放在物理机cluster的共享盘上（虚拟机的OS放在上面)， 这样在做live migration的时候才可以把虚拟机在两台物理机之间变魔术似得搬来挪去。

然后在2个虚拟机之间搭建SQL Server failover cluster，但为了清楚起见，在虚拟机层次上所需要的共享硬盘在上图中没有画出来。这里有一篇手把手的搭建live migration的文档：https://technet.microsoft.com/en-us/library/dd446679(WS.10).aspx, 但其中不涉及怎样搭建SQL Server cluster。

这种搭建无疑是最复杂的。但方式D提供了两种情况下的热备用：不可预料的宕机（Unplanned down time），例如硬件故障，以及可预料的宕机（Planned down-time），例如Windows打补丁。例如物理机2需要打Windows补丁，如果物理机2上的虚拟机是正运行着SQL Server的活动节点（Active node）， 你可以做live migration把这个虚拟机弄到物理机1上， 如下图所示。等物理机2打完补丁再同样挪回来。这样保证了你的SQL Server应用系统的高可用性。如果任何一个物理机或虚拟机宕机了（Unplanned down time，谁也无法预料什么时候发生），还可以依靠SQL Server failover cluster来保证你的SQL Server应用系统的可用性。好处多多啊。

方式E如下图

方式E需要2台物理机。其中1个虚拟机可以做live migration，另外一个虚拟机不做live migration。能做live migration的机器当然要放在物理机上事先建好的cluster中的共享盘上，就是和方式D中同样的做法。不做live migration的虚拟机放在物理机的本地硬盘上（D:\N1.VHD）。

这种配置没有太大的意义，实际上是方式A和方式D的混合。其中的一个虚拟机采用了方式A中的配置，另一个虚拟机采用了方式D中的配置。

方式E能提供高可用性。 如果物理机1需要打Windows补丁，可以把上面正在运行SQL Server应用的虚拟机（Active node）live migrate到物理机2上，如下图所示。打完Windows补丁再同样地挪回去。

如果物理机2需要打Windows补丁，而且上面的虚拟机中SQL Server是活动（Active node）的。因为它不支持live migration，那只能将SQL Server 转移到物理机1上的虚拟机VM2上去继续干活。当然Failover的过程比live migration的过程要慢。

方式F如下图

 
方式F是一种更怪异的搭建方式，需要3台物理机。只不过这种方式比较浪费硬件，从软件角度来说和方式C是类似的，是一种虚拟机和物理机混合构建的SQL Server cluster，只不过这里的虚拟机可以做live migration。虚拟机VM1和物理机3之间构建了SQL Server cluster。虚拟机VM1位于物理机1和物理机2之间构建的Hyper-V cluster中，所以可以在2个物理机1和2之间做live migration。Live migration的一个好处是负载均衡。在物理机1上面可能有别的应用突然占用了90%的CPU，这样运行着SQL Server 应用的VM1可以在不停机的情况下挪到CPU不忙的物理机2上继续运行。同样道理，如果物理机1需要安装Windows补丁，也可以利用live migration把所有的虚拟机负荷搬到物理机2上去而不影响SQL Server故障转移群集，如下图所示。这种要求在方式D中也能很好的满足。

总结

下面的表格中把几种组建方式做个对比，可以看的更清楚一些：

这几种方案中最有使用价值的是方式A和方式D。A是生产环境中最常用的配置。如果需要live migration的功能则可选用D。其次是B和C。方式B主要用于测试、开发以及演示的环境。但它没有高可用性，也就失去了应用到生产环境中的意义。C可作为从物理机的群集到虚拟机的群集临时的升级方案。

软件测试工程师
赵振宇