Windows Server 2003 和 SQL SERVER 2008 群集配置指南.doc

SQL Server 2008 群集配置指南(Windows 2003) 文档目的 本文档将介绍SQL Server 2008在windows2003上群集配置方法及注意事项。 概述 Microsoft SQL Server 2005 中的故障转移群集为整个 SQL Server 实例提供高可用性支持。例如，您可以将故障转移群集的一个节点上的 SQL Server 实例配置为在发生硬件错误、操作系统错误或计划升级时故障转移到此群集中的任何其他节点。 故障转移群集是一个或多个节点（服务器）与两个或多个共享磁盘的组合，即资源组。一个资源组及其网络名称、构成群集应用程序或服务器的 Internet 协议 (IP) 地址的组合称为“虚拟服务器”。SQL Server 虚拟服务器在网络中就像单个计算机一样，不过，它还具有一种功能，在当前节点不可用时，可以在节点之间进行故障转移。故障转移群集显示为常规应用程序或服务器，但它具有提高可用性的附加功能。服务器群集本身和群集服务器上安装的 SQL Server 实例都可以视为虚拟服务器。 注意：SQL Server 2005（包括2008）只支持故障转移群集，并不支持类似Oracle RAC的网格计算群集。 工作原理 Windows操作系统和SQL Server的各个节点是通过心跳（heartbeat）信号检查各个节点是否可用的。在操作系统级别上，群集各节点通过持续不断的通讯，检查所有节点的可用情况。当安装完SQL Server容灾群集后，SQL Server虚拟主机通过Service Control Manager每隔5秒检查SQL Server服务是否正在运行，这种检查行为我们称之为LooksAlive，它几乎不影响操作系统的性能，但是这也是一种不彻底的检查。LooksAlive认为只要SQL Server服务状态为可运行时，检查结果即为成功，即使SQL Server服务可能根本无法响应请求。 由于LooksAlive无法彻底检查SQL Server服务的工作状态，每隔60秒还会进行一次IsAlive检查。IsAlive检查机制是通过在SQL Server实例上运行SELECT @@SERVERNAME （T-SQL语句），根据SQL查询返回的结果来决定SQL Server服务是否能够响应请求。尽管IsAlive发出的查询请求可能已经被SQL Server服务正常响应了，但是这并不能判断所有的用户数据库是否都是可用的，其性能是否满足要求。如果IsAlive发出的查询无法成功，它会重试5次，然后尝试重新连接SQL Server实例。如果5次重试全部失败，将认为SQL Server服务失败了。根据SQL Server容灾群集中SQL Server的资源设置，群集将尝试重启服务或在其它节点启动SQL Server服务。IsAlive检查可以容忍查询返回错误的结果，但是如果返回错误结果次数超过设定的阀值，最终还会认为数据库服务已经无法工作了。 当SQL Server实例发生节点转移时，SQL Server的资源将在新的节点上启动。Windows群集在新的节点上启动SQL Server服务，SQL Server服务通过内部恢复进程启动数据库。当SQL Server服务启动，并且master已经联机，SQL Server资源将被认定已经启动。接下来用户数据库将被恢复。那些在事务日志中已经完成的事务将被重用（redo阶段），没有完成的事务将被会退（undo阶段）。SQL Server 2005 Enterprise版本的用户数据库，一旦恢复了已提交事务（redo阶段），数据库就可以使用了。对于SQL Server 2005其它版本和早期版本只有当所有未提交事务全部被会退（undo阶段），用户数据库才能使用，这些版本的数据库恢复时间决定于有多少需要回退的未提交事务。 系统参数recovery interval可以设定redo恢复的最小时间，通过对其设置可以避免长时间的redo操作进而加速恢复过程。如果想减少undo的恢复时间，需要避免使用长事务。 拓扑图 下面为两节点群集拓扑图： 群集节点规格 SQL Server 2005 Standard Edition SQL Server 2005 Enterprise Edition Windows Server 2003 Enterprise Edition 2* 8 Windows Server 2003 Datacenter Edition 2* 8 *说明：虽然Windows Server 2003 Enterprise 和Windows Server 2003 Datacenter最多支持八个节点，但是SQL Server 2005 Stand