win server故障转移群集

1、Windows Server 2008 故障转移群集文档一、 优势故障转移群集可以配置使用多种不同的配置。组成群集的服务器可以是活跃状态或不活跃状态，而不同服务器可以被配置为在活跃服务器故障后立刻接管相应的资源，从而保证业务数据的高可用性，高稳定性，高安全性。当服务器故障后，在这台服务器上配置了故障转移群集的资源组就会被其他服务器所接管。当故障服务器重新上线后，群集服务可以配置为允许让原服务器进行故障回复，或让当前服务器继续处理新的客户端请求。二、 概述故障转移集群（Failover Cluster）是实现SQL Server高可用性解决方案之一。一个集群通常由多台服务器组成，每台服务器称为一

2、个节点。通过使用冗余节点来减少宕机时间，为客户关键业务的高可用性提供了有力的保障。与以前版本相比，SQL Server 2008故障转移集群做了很大改进，不但简化了安装和维护，而且提供了新功能减少系统维护时的宕机时间，比如循环升级、循环打补丁等。本文将简述一下SQL Server 2008故障转移集群的基本结构和原理。SQL Server 2008支持本地集群，即所有节点都在同一个子网内，通常位于同一个物理地点；如果节点跨越不同区域，则必须把所有的节点都配置到同一个VLAN中，所以在上层的集群看起来还是同一个子网内。一个典型的故障转移集群的架构如图1所示。  首先要指出的是，SQL

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

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

5、L Server故障转移集群的数据不能存储在本地磁盘上，而必须存储在共享的SAN（Storage Area Network）上。实际上SAN是在Windows故障转移集群中配置，然后分配给SQL Server故障转移集群的实例使用的（在安装时指定）。通常SAN总是被当前的活动节点独占使用的，从而避免了多节点同时访问可能造成的数据损坏。故障转移有两种形式，一种是由管理员发起的，一般是在对当前活动节点进行系统维护之前先把整个集群转移到其他节点上；另一种是系统检测到故障时自动进行的故障转移。故障转移过程如图2所示。Windows故障转移集群会首先停止当前活动节点上的SQL Server实例进程，然后

6、根据该实例的故障转移策略选择一个新的节点，最后在此新节点上启动SQL Server的实例进程，同时获得对SAN的独占访问权。这个节点就成为了新的活动节点，虚拟网络名字也随之映射到此新节点上，从而保证客户应用还能正常连接数据库。由于数据都是存储在共享的SAN上的，在故障转移过程中并不需要数据复制。宕机时间只发生在故障转移时短暂的瞬间，即旧的活动节点的实例进程被停止后，到新的活动节点的实例进程正常工作之前。当然，故障转移之前的客户连接都会被中断，所有未完成的事务都会被回滚，并且故障转移完成之后，客户端需要重新连接数据库。故障的种类多种多样。如前所述，Windows故障转移集群为集群应用提供了底层服

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

8、对数据库的影响较大，尤其是系统繁忙时，所以只在每60秒钟，或者“LooksAlive”查询失败时才会去执行一次。故障发生时，默认的转移策略就已经能满足很多用户的需求了。当然，用户还可以随时根据自己的特殊需求，用Windows集群管理器（Failover Cluster Manager）对集群实例内的每个资源单独配置不同的策略。同时，同一集群实例内的资源之间会通过特定的依赖关系（如图3所示）而互相影响。如果出故障资源变成“失败”状态从而导致其上层资源的依赖关系不能成立，则该上层资源也会变成“失败”状态；如果要转移到新节点，则同实例内部的所有其他资源都会跟着转移。三、 安装及部署在此以server

9、1为例，安装方法是：打开服务器管理器图标-添加功能，从中选择“故障转移群集”。当两个节点安装完群集服务后，我们需要运行群集配置验证程序，来检查节点服务器、网络和存储设备是否符合群集要求。仅当完整配置(服务器、网络和存储)可以通过“验证配置”向导中的所有测试时，微软才支持故障转移群集解决方式，另外，解决方案中的所有硬件组件均必须标记为“certified for windows server 2008 R2”。方法是在server1或者是server2上进入故障转移群集管理器，单击“验证配置”。如下图所示：因为我们需要验证的是群集中的所有节点，所以我们需要把所有节点都添加进来，如下图所示：点击“

10、下一步”之后，我们需要“运行所有测试”，如下图所示：给出验证清单，也就是所要进行验证的项目。点击，下一步之后，开始出现下面的验证过程：经过耐心的等待后，出现下图所示：查看报告，只有一处关于网络的IP地址的警告，这应该是检测到节点间只有一块网卡相连，没有实现冗余，这不影响群集的创建。点击故障转移群集管理器中的“创建一个群集”，如下图所示：再次提示添加要加入群集的所有服务器，如下图所示：下面，我们需要输入用于管理群集的访问点，也就是群集的名称和对应的 VIP。接着，需要确认所输入的信息是否正确，如下图所示：点击，下一步，开始创建群集：最后，出现摘要信息，群集创建结束。返回到“故障转移群集管理器”，

11、查看群集的工作状态，可以看到，仲裁磁盘是我们前面所创建的quorum磁盘，如下图所示：当前的仲裁配置模式是：节点和磁盘多数，这是因为我们所创建的群集是偶数个节点。如果希望，更改群集的仲裁配置，可以点击下图所示的操作中，在此不再演示。群集网络的配置：下面需要对群集内的各个网络进行相应的配置，以确定它们的用途。针对public网络，我们需要允许客户端进行访问，所以进行下图所示的操作：注意，千万不要选错了网络，可以观察IP地址，点击属性，出现下图：Heart网络的配置： 此网络只用于节点间的通讯，所以不应该允许客户端访问，操作同上，取消客户端的访问。允许群集使用，但不允许客户端访问。针对store存

12、储网络： 则是不允许群集使用，如下图所示：群集已经搭建成功了，下面我们就来看看如何在上面安装具体的应用了，本篇先介绍一个简单的应用，实现文件服务器的故障转移群集，我们另一篇文章会详细介绍如何实现SQL Server 2008 R2的故障转移群集。防火墙准备：节点服务器上必须允许远程卷管理，不然无法在群集内创建共享文件夹。操作方法是在public网络所在网络位置上，允许远程卷管理，如下图所示：从这个图中可以看出public网络属于域网络，所以，我们只需要在域网络上允许远程卷管理即可。当然，也可以直接将防火墙禁用。注意，所有节点上都要进行此步操作。两个节点上都需要安装文件服务器角色，安装方法是服务

13、器管理-角色-添加角色。如下图所示：在如上图所示的界面中，选择文件服输，下一步后，出现下图所示，一定要选择文件服务器。节点2上进行同样的操作，安装文件服务器角色。然后，回到群集中，单击服务和应用程序，右边的配置服务或应用程序。选择配置服务或应用程序后，出现下面的界面：点中，文件服务器，此时系统会检查所有节点中是否已经安装了该服务，如果安装不正确，会报错。接下来需要输入客户端访问点的信息，如下图所示：在此界面中，需要输入客户端访问此服务或应用程序时将使用的名称。名称我们就使用clusterFs，IP地址是客户端访问时所要使用的IP地址。此名称和IP地址会被注册到DNS服务器内。选择分配给文件服务器的存储磁盘，在此，除了仲裁就是群集磁盘2了，如上图所示。出现确认信息后，开始进行配置，出现下图，表示配置结束。回到故障转移群集管理器中，可以看到目前提供此服务的是Server1。下面，我们就就来添加共享文件夹，点击下图中的添加共享文件夹按钮。下面我们准备