SQL中国研发中心 : HADR

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

sqlcrdft — Mon, 29 Jun 2009 15:51:00 GMT

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的文档：http://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中也能很好的满足。

总结

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

方式	需要几台物理机？	宿主机之间做群集？	虚拟机之间做群集？	是否支持 Live migration?	虚拟硬盘文件放在共享盘上？
A	2台	否	是，SQL Server群集	否	否
B	1台	否	是，SQL Server群集	否	否
C	2台	否	宿主机和虚拟机之间的SQL Server群集	否	否
D	2台	是，Hyper-V群集	是，SQL Server群集	是	是，2个虚拟机硬盘放在2个不同的共享盘上
E	2台	是Hyper-V群集	是，SQL Server群集	是，只有1台虚拟机支持	是，只有1个虚拟机硬盘放在共享盘上
F	3台	是Hyper-V群集	宿主机和虚拟机之间的SQL Server群集	是，只有1台虚拟机支持	是，只有1个虚拟机硬盘文件放在共享盘上

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

软件测试工程师
赵振宇

SQL Server 2008故障转移集群概述

sqlcrdft — Mon, 22 Jun 2009 14:54:00 GMT

故障转移集群（Failover Cluster）是实现SQL Server高可用性解决方案之一。一个集群通常由多台服务器组成，每台服务器称为一个节点。通过使用冗余节点来减少宕机时间，为客户关键业务的高可用性提供了有力的保障。与以前版本相比，SQL Server 2008故障转移集群做了很大改进，不但简化了安装和维护，而且提供了新功能减少系统维护时的宕机时间，比如循环升级、循环打补丁等。本文将简述一下SQL Server 2008故障转移集群的基本结构和原理。

SQL Server 2008支持本地集群，即所有节点都在同一个子网内，通常位于同一个物理地点；如果节点跨越不同区域，则必须把所有的节点都配置到同一个VLAN中，所以在上层的集群看起来还是同一个子网内。一个典型的故障转移集群的架构如图1所示。

首先要指出的是，SQL Server故障转移集群有两个核心层次，一个是Windows层，一个是SQL Server层。Windows故障转移集群是一个平台，提供了与应用无关的故障转移的基本功能，比如节点之间心跳检测、故障转移策略管理等。在其上可以构建很多故障转移集群的具体应用，而SQL Server故障转移集群正是其中之一（其他故障转移集群的应用还有很多，比如邮件服务器、文件服务器、打印服务器等）。因此，安装SQL Server故障转移集群前，必须要先把所用的节点加入到同一个Windows故障转移集群中。向现有的集群中增加新节点也是如此。SQL Server 2008故障转移集群推荐安装在Windows Server 2008上，因为该版操作系统大大简化了Windows故障转移集群的管理维护。

和独立的SQL Server一样，SQL Server的故障转移集群也支持多实例。每一个SQL Server故障转移集群的实例都有一个虚拟的网络名字，客户通过该名字访问集群数据库就和访问一台物理的数据库服务器一样。所以虽然集群内部有很多节点，但客户是感觉不到的。正常运行时，只有一个节点上的SQL Server实例进程在运行，此节点称为活动节点（Active Node），而所有其他节点则称为被动节点（Passive Node）。集群的虚拟网络名字总是映射到当前活动节点的IP上。

和独立的SQL Server不同的是，SQL Server故障转移集群的数据不能存储在本地磁盘上，而必须存储在共享的SAN（Storage Area Network）上。实际上SAN是在Windows故障转移集群中配置，然后分配给SQL Server故障转移集群的实例使用的（在安装时指定）。通常SAN总是被当前的活动节点独占使用的，从而避免了多节点同时访问可能造成的数据损坏。

故障转移有两种形式，一种是由管理员发起的，一般是在对当前活动节点进行系统维护之前先把整个集群转移到其他节点上；另一种是系统检测到故障时自动进行的故障转移。故障转移过程如图2所示。Windows故障转移集群会首先停止当前活动节点上的SQL Server实例进程，然后根据该实例的故障转移策略选择一个新的节点，最后在此新节点上启动SQL Server的实例进程，同时获得对SAN的独占访问权。这个节点就成为了新的活动节点，虚拟网络名字也随之映射到此新节点上，从而保证客户应用还能正常连接数据库。由于数据都是存储在共享的SAN上的，在故障转移过程中并不需要数据复制。宕机时间只发生在故障转移时短暂的瞬间，即旧的活动节点的实例进程被停止后，到新的活动节点的实例进程正常工作之前。当然，故障转移之前的客户连接都会被中断，所有未完成的事务都会被回滚，并且故障转移完成之后，客户端需要重新连接数据库。

那么在系统自动触发的故障转移中，系统是如何检测故障及采取措施呢？这就需要探讨一下故障的检测和转移策略。

故障的种类多种多样。如前所述，Windows故障转移集群为集群应用提供了底层服务，与之对应，一些底层的故障，比如网络故障、磁盘故障等，也是由它来检测的。而每个SQL Server集群实例自身的故障（比如拒绝客户端连接、无响应等）则是由一个为SQL Server定制的集群资源来检测的，称为“SQL Server资源”，其任务就是定期去查询数据库的状态。具体来说有两种查询：一个是“LooksAlive”，另一个是“IsAlive”。前者是一个轻量查询，缺省配置下每5秒钟检查一下SQL Server服务的状态，并不去连接数据库，所以对数据库的影响很小，查询次数也比较多；而后者是要连接到数据库中去执行一下SQL语句“SELECT @@SERVERNAME”判断是否能返回正确的结果，对数据库的影响较大，尤其是系统繁忙时，所以只在每60秒钟，或者“LooksAlive”查询失败时才会去执行一次。

故障发生时，默认的转移策略就已经能满足很多用户的需求了。当然，用户还可以随时根据自己的特殊需求，用Windows集群管理器（Failover Cluster Manager）对集群实例内的每个资源单独配置不同的策略。同时，同一集群实例内的资源之间会通过特定的依赖关系（如图3所示）而互相影响。如果出故障资源变成“失败”状态从而导致其上层资源的依赖关系不能成立，则该上层资源也会变成“失败”状态；如果要转移到新节点，则同实例内部的所有其他资源都会跟着转移。

集群内部的状态信息都会同时记载到集群日志和Windows事件浏览器中，所以一旦集群发生了异常，总可以通过研究这些信息了解系统状态变化的全过程。

您可以参考以下链接获得Windows和SQL Server故障转移集群更详细的信息：

Windows Server 2008 Failover Clustering
http://www.microsoft.com/Windowsserver2008/en/us/failover-clustering-main.aspx
SQL Server 2008 Failover Clustering
http://msdn.microsoft.com/en-us/library/ms189134.aspx

李凌伟
SQL Server引擎测试工程师

SQL HADR多个技术概览和比较

sqlcrdft — Tue, 09 Jun 2009 09:22:00 GMT

对于企业级用户和关键系统来说，最重要的要求之一就是系统的高度可用性和数据的安全性（High Availability and Disaster Recovery，HADR）。我们先来了解一下HADR的问题空间。HADR有两个目标和衡量方式：

保证系统可用
目标恢复时间（Recovery Time Objective，RTO）：出了故障后把系统恢复正常工作状态所需要的时间。
保证数据安全
目标恢复点（Recovery Point Objective，RPO）：系统数据能恢复到故障前的哪个时间点。换而言之，故障后你能容忍多少数据损失。

故障又主要有两大类别：

计划宕机时间

硬件升级
软件补丁（操作系统，应用程序），应用程序升级
维护操作

意外宕机时间

无法预料的故障

硬件故障，软件故障，电力中断，数据损坏
站点故障：火灾，地震，洪水

用户或应用程序错误

意外更改，不正确的数据操作

针对不同的可用性要求和故障类别，SQL Server提供多样的HADR技术来满足用户的需要。但怎样从中选择最合适的技术？下面是对SQL可用性技术和功能的一个概览：

意外宕机时间

SAN/RAID
备份和恢复（Back Up and Restore）
日志传送（Log Shipping）
数据库镜像（Database Mirroring）
故障转移群集（Clustering）复制（Replication）

计划宕机时间

轮流升级和打补丁（Upgrade and Patching）
在线操作（Online Operations）
资源管理器（Resource Governor）
数据库快照（Database Snapshot）

SQL Server HADR 技术比较

这些技术都有自己的特点和要求，用户可根据自已需求，配置，和预算来选择，以满足HADR在目标恢复时间（RTO）和目标恢复点（RPO）的要求。

希望您能通过本文对SQL HADR技术有个大致了解，以后我们会再详细介绍其中的一些技术，谢谢。

SQL Engine部门经理
吴家震