SQL Server的“高可用性”与“灾难恢复” 之二 故障转移群集

SQL Server使用最广的高可用性技术叫做故障转移群集（SQLServer Failover Cluster）。这是一项基于Windows故障转移群集的一种技术。SQLServer故障转移群集技术集成了微软技术一贯简单易用的特点，在部署和管理上都非常容易，同时又能提供非常良好高可用性，因此目前得到了非常广泛的使用。可以说，它是SQL2012之前的各个版本，实现高可用性的必选技术。

故障转移群集

要了解SQL Server故障转移群集，首先要对Windows故障转移群集有一个基本的了解。下面介绍的内容不求面面俱到地都覆盖Windows群集的知识，但对于一个数据库系统管理员，理解这些概念是非常有用的。

1.  Windows故障转移群集的基本组成要素

Windows故障转移群集是由多个服务器组成的。每个服务器也被称为“节点”(Node)，每个节点上都运行着Microsoft 群集服务 （MSCS）。这些节点有相同的软硬件配置，并且具有共享的磁盘（Shared Array）。所有需要在几个节点之间共享的东西，例如SQLServer的数据库文件、错误日志等，都会被安放在共享磁盘上。不需要共享的内容则被安放在每个节点的本地磁盘上。

除了共享磁盘之外，组成群集的多个节点之间通过“私有网络”（privatenetwork）和“公共网络”（public network）连接起来。每个节点上有一块私有网卡，这些网卡通过网络互相连接组成了私有网络。节点之间通过私有网络互相发送信号来感知彼此是否已经工作正常，这类信号被称为“心跳线”。一旦某服务器因为某种异常而无法回应信号，这就好像一个人的心跳停止了一样。此时剩余的节点就认为这个节点已经“死了”，于是就把这个节点排除出当前群集。

公用网络，顾名思义是用来被群集外部的资源所使用的一个网络。每个节点上有一块公共网卡，外部资源通过公用网卡来访问这个节点。要注意的是，私有网卡和公共网卡在物理上可以是一块网卡，这种时候群集就通过一个网络来完成私有网络和公共网络的职责，这个网络被称其为混合网络（mixednetwork）。

一个群集内的所有节点共同组成一个“虚拟”的服务器(VirtualServer)。也就是说，从这个群集的外部来看，只能看到一个服务器，而不是它背后的一堆节点服务器。虚拟服务器具有自己的机器名和IP地址，而这个名称和IP与群集内的任何节点都不同。由于服务器是虚拟的，因此人们称呼它的IP是“虚拟IP”，而它的机器名是“虚拟网络名”（virtualnetwork name）。但事实上“虚拟IP”和“虚拟网络名”都是在DNS服务器上登记在册的，它们本身和一台真实的物理机器的IP和机器名没有任何区别，只是它们对应的服务器是一个虚拟的机器。虚拟IP一定要和公共网络配置在同一个网段里，因为这个IP需要在网络上可以被其他机器访问到。

在Windows群集中，虚拟IP，虚拟网络名，共享磁盘，SQL Server等等，被统称为“资源”。在任意时刻，只有群集中的一个节点能提供用户所需的服务和资源，而其他节点都处于空闲状态。所以，Windows群集无法提供负载均衡的能力。这个技术和NLB是有本质区别的。

那么当用户使用虚拟IP或者虚拟网络名来访问虚拟服务器的时候，到底是哪个节点来为用户提供服务呢？答案是，由“活跃节点”来提供服务。所谓的活跃节点，就是当前拥有该群集资源的节点。

举个例子，假设当前有两个节点，分别是NodeA和NodeB；它们组成的群集的虚拟网络名是Vserevr。在某个时刻，NodeA拥有了虚拟网络名和虚拟IP这两个资源，而服务器B拥有了一个共享磁盘资源DiskX。这种情况下，对虚拟网络名和IP而言，NodeA就是活跃节点，而对于共享磁盘DiskX而言，NodeB才是活跃节点。如果你使用远程桌面工具去连接虚拟网络名Vserver，你实际上是登录到了NodeA上，你可以的本地磁盘上的文件其实是NodeA磁盘中的文件，你运行的程序都是NodeA上安装的程序。虚拟网络名好像一个中转站一样，所有该虚拟服务器的请求都被转向到了NodeA上。但是NodeA上看不到共享磁盘。因为共享磁盘资源当前被NodeB所拥有。您只有直接登录到NodeB上才能看到那个共享磁盘。

谁是“活跃节点”是Windows群集服务决定的，对用户完全透明。用户不需要关心当前哪个节点正在运行。客户端的连接指令始终都是一样的：指向虚拟IP，或者虚拟网络名。例如用户要通过UNC方式访问共享磁盘上的某个文件，他所发出的指令会是\\Vsever\DiskX\FolderY\。

 

2.  故障转移

接下来再来谈谈群集的“故障转移”（Failover，也称为“切换”）。也就是说，当“活跃节点”服务器出问题的时候，群集服务是怎么实现其“高可用性”的。

还是前面的这个例子，假设此时NodeA拥有DiskX，虚拟网络名和虚拟IP地址三个资源。如果NodeA突然间由于硬件故障蓝屏了，那么Windows群集会立刻探知到这个问题，然后自动发起一个故障转移。转移完成后，这三个资源全部在NodeB上线，也就是被NodeB所拥有。如果之前有一个用户通过\\Vsever\DiskX\FolderY\这样的UNC方式来访问共享磁盘上的某个文件，NodeA的蓝屏对该用户不会造成任何的影响。用户甚至可能没感觉到虚拟服务器内部的故障转移。对他而言通过Vserver里的那个文件一直都是可以访问，而这就是高可用性的目的。

除了由于系统故障所造成的Windows群集的自动切换，系统管理员也可以通过工具或者命令行手动发起切换。

 

故障转移群集

所谓的SQL Server故障转移群集，就是将SQLServer部署在Windows群集中的多个节点上，然后组成一个虚拟的SQLServer实例。这样SQL Server 实例依旧像运行在单台计算机一样显示在网络中。不过它具有一种功能，即在当前运行SQLServer实例的节点不可用时，可以在节点之间进行故障转移，把SQL Server切换到工作正常的节点上去继续为应用程序提供服务。

实现这个功能，需要将SQL Server安装成群集模式，而不是单机模式。安装的具体步骤，请参见本书的第一章。安装成功以后，您就可以看到本节所提到的各个管理界面了。

打开Windows的故障转移群集管理器（FailoverCluster Manager），然后使用Windows群集的虚拟网络名来连接群集。左侧的面板中的“Servicesand application”节点，下面会列出该Windows群集的所有“资源组”。“资源组”顾名思义就是由一个或者多个资源组成的组。所有的故障转移都是以资源组为单位发生的，在任何时候，每个资源组都仅属于群集中的一个节点，这个节点就是该资源组的“活跃节点”。由于资源组里的资源是一起切换的，所以这些资源应该是彼此关联，并且协同工作来提供某项服务。用户应当尽量避免把无关的资源加入到同一个资源组里。可以简单地把资源组想象成在虚拟服务器上运行的一个个独立的应用程序或者服务，而群集技术为这些应用程序或者服务提供了高可用的特性。SQLServer资源组就是一个很好的例子。

SQL Server群集资源组的结构

 

1.  SQLServer网络名和SQL Server IP地址：

SQL Server群集并不使用Windows群集的虚拟网络名和虚拟IP地址来作为应用程序访问它的接口。在SQLServer的资源组里有该SQL Server实例自己专用的虚拟网络名和IP地址这两个资源，它们提供了应用程序访问SQL Server时使用的机器名或者IP地址。事实上，无论是Windows群集还是SQL Server群集的虚拟机器名/IP，它们的资源类型都是相同的，只是它们一个服务于Windows虚拟服务器；一个服务于SQL Server群集实例。

 

2.  SQL Server和SQLServer Agent

这两个资源是SQL Server故障转移群集的关键资源。它们分别代表了SQL Server服务和SQLServer Agent服务。事实上，SQL Server 2005群集还包含有第三种资源：SQL Server Fulltext Search。但是这个资源在SQL Server 2008以后被并入了SQL Server资源里，因此就只剩下现在这2个资源了。

对于一个SQL Server群集，群集中的所有节点上都会有安装有SQL Server和SQLServer Agent服务以及与服务所对应的二进制文件、注册表键值等。Node1是SQL Server的“活跃节点”。如果你到群集中的每个节点上的SQLServer Configuration Manager里查看的话，会发现只有Node1上的SQL Server实例对应的服务是处于启动状态，其余所有节点上服务都是处于停止状态的。

如果SQL Server是默认实例的话，那么SQL Server资源的名字就是“SQLServer”。如果SQL Server是命名实例的话，SQLServer资源名就是“SQL Server (实例名)”。客户端应用程序就是通过“虚拟网络名\实例名”的形式找到它所想要访问的SQLServer实例。

 

3.  共享磁盘

共享磁盘资源可以是一块逻辑磁盘，也可以是一块磁盘上的一个mountpoint。

对于一个SQL Server群集实例，数据库的所有数据文件和事务日志文件（MDF，NDF和LDF），SQL Server和SQLServer Agent的日志文件（ERRORLOG），以及一些其他的文件和目录，都是保存在共享磁盘上的。必须设置共享磁盘和SQLServer资源在一个资源组里，这样就保证了运行SQL Server服务的节点一定能访问到共享磁盘里的数据。

事实上SQL Server资源和共享磁盘资源是具有“依赖”关系的。也就是说在磁盘资源无法在某节点正常运行的时候，SQL Server资源在该节点也无法上线运行。

需要注意的是，一个共享磁盘资源只能属于一个SQLServer实例（事实上，在安装SQL Server群集实例时是不允许把SQLServer安装在一个已经被其他SQL Server群集实例使用的共享磁盘上的）。但是一个SQLServer群集实例可以使用多个共享磁盘。

 

4.  其他

除了上述列出的资源之外，SQLServer资源组里还可能包含

(1)  FileShare：如果 SQL Server要使用FileStream，就需要这样一个资源

(2)  AnalysisServices：这个资源和SQL Server/SQL Server Agent资源不同，是属于Generic Service资源。

 

一般而言，每个资源可能处于的状态有：

上线（online）：该资源在某个节点上正常工作中。

离线（offline）：该资源在某个节点上处于停止工作状态，无法提供相应的服务。

失败（failed）：该资源在某节点尝试上线，但是由于某些异常无法上线成功。

上线挂起（onlinepending）：资源尝试进入上线状态，但是还没完全成功上线。

离线挂起（offlinepending）：资源尝试进入离线状态，但是还没完全成功离线。

以上五个状态中，上线/离线/失败是会长时间保持的状态；除非有人为的操作或者系统异常发生，否则他们会保持这个状态。而两个“挂起”的状态不会长时间保持。经过一段时间之后，它们要么成功“上线”，要么由于某种错误或者由于超时最后进入了“失败”状态。

2. 集群资源的配置

在任意一个资源上点右键，选择“属性”，在弹出窗口上能看到一系列选项卡，这里包含了群集资源的重要设置选项。

这里以SQL Server资源为例。首先来看“Dependencies”选项卡。

SQL Server资源的Dependencies属性页

这里显示了SQL Server依赖了哪些资源。SQLServer要依赖的资源包括：

·        虚拟网络名资源

·        共享磁盘资源

这两个资源之前的关系是“and”，就是说只有两个资源都online之后，SQL Server资源才可以online。这也符合SQL Server成功启动的要求：（1）能绑定IP地址，（2）能找到系统数据库和错误日志。

如果去看虚拟网络名的依赖“选项”卡，你会发觉它其实是依赖于虚拟IP资源。这样就组成了一个完整的依赖“链条”。SQL Server资源组里各个资源的依赖关系如下：

SQL Server资源组中属性的依赖关系

一个资源所依赖的其他资源必须要和这个资源处于同一个资源组里，跨资源组的依赖关系是不存在的。如果用户需要SQLServer群集实例同时可以访问多个共享磁盘资源，必须在SQL Server资源组里添加，然后让SQLServer资源去依赖于它们。没有这样的依赖关系࿰