SQL Server 2000 故障转移群集

简介

对于一个产品环境，无论是数据库驱动的关键任务客户端/服务器应用程序，还是电子商务Web站点，环境中持续的正常运行时间日益成为一个基本的商业要求。在本白皮书中将介绍一种实现高可用性的方法——Microsoft® SQL Server™ 2000故障转移群集。这种故障转移群集仅适用于SQL Server 2000 Enterprise Edition。

故障转移群集是这样一种流程：在应用程序出错、硬件故障或操作系统出错时，操作系统和SQL Server 2000通过共同协作提供可用性。故障转移群集通过特殊的配置提供硬件冗余。在这种配置下，关键任务的资源将自动从发生故障的机器转移到同等配置的服务器上。同时，故障转移群集也允许在其它节点保持运行的情况下对计算机进行系统维护。这也能将由于正常维护而导致的系统停机时间保持在一个最低的水平上。有关优化数据库的更多信息以及如何避免可能导致系统不可用的性能问题的技巧，请参考Microsoft SQL Server 2000 Resource Kit（资源工具包）的第33章“数据层：数据库优化方法”。

故障转移群集旨在为全面的可伸缩性解决方案提供高可用性，这类解决方案能够提供备份、冗余和性能。如果软件和/或硬件出现了故障，故障转移群集以及其他高可用性方法（例如：SQL Server 2000日志递送）能够在很短的时间内设置完成一个产品环境并使其投入运行。

但是，故障转移群集并不是一种负载平衡解决方案，无法保护您的系统免受外部攻击，也无法避免所有群集节点遭遇灾难性软件故障、单点故障（例如：无冗余硬件）或者自然灾害。有关SQL Server 2000高可用性的更多信息，请参考Microsoft SQL Server 2000 Resource Kit的第16章“99.999%：高可用性的终极目标”。

故障转移群集的改进

Microsoft SQL Server 2000 Enterprise Edition故障转移群集提供了超越SQL Server version 7.0 Enterprise Edition所提供群集功能的多种改进。在SQL Server 2000中群集功能的部分改进包括：

·         现在，SQL Server 2000故障转移群集的安装和卸载都是通过SQL Server 2000安装程序来完成的，而不是通过设置数据库服务器以及随后的向导程序来实现。安装和群集同时在一个过程中完成。SQL Server 2000故障群集是一个永久性选项，将其删除的唯一方法就是卸载SQL Server的群集实例。

·         SQL Server 2000支持多个实例，允许同步支持最多16个SQL Server 实例。

·         SQL Server 2000扩展了对于从群集的服务器节点执行故障恢复的支持，包括单节点群集。如果一个节点发生了故障，可以将其删除并进行重新安装，然后重新加入到群集中，同时保持所有其他节点继续正常工作。将新的服务器添加回虚拟服务器定义中对于SQL Server 2000安装程序来说是一个很简单的操作。

·         运行于Microsoft Windows® 2000 Datacenter Server的SQL Server 2000在一个群集中可支持多达4个服务器节点。

·         现在，所有节点都拥有SQL Server工具（包括性能计数器）以及在发生故障时可能派上用场的可执行程序的本地副本；您可以从远程系统或群集节点本身对服务器进行管理。

·         SQL Server 2000故障转移群集支持Microsoft Search Services。

·         SQL Server 2000故障转移群集的配置可以通过重新运行安装程序进行更新。

·         SQL Server 2000 支持多个网络地址。这使得SQL Server 2000能够侦听不同子网中的多个IP地址。

·         现在，数据库管理员可以使用SQL Server Service Manager或者SQL Server Enterprise Manager启动和停止SQL Server，而不需要使用群集管理器（Cluster Administrator）启动和停止SQL Server服务。

·         服务程序包可直接应用于SQL Server 2000虚拟服务器。在使用SQL Server 7.0时，您在应用服务程序包之前必须将服务器从群集中释放出来。

·         现在，SQL Server 2000是一个完全支持群集的应用程序，允许SQL Server 2000与群集服务进行交互，另外还提供了其它更多的优点，例如：避免在无效逻辑驱动器上创建数据库。

什么是Windows群集?

Microsoft SQL Server 2000故障转移群集与Windows群集（Windows Clustering）相集成。在Windows环境中，主要有两类群集：

·         服务器群集

SQL Server 2000故障转移群集建立在Windows 2000 Advanced Server或 Datacenter Server群集的基础上。Windows 2000服务器群集将4台服务器组合在一起。当因硬件故障、自然和人为灾难、软件故障等导致计划外停机时，群集能够保持客户端对应用程序和服务器资源的访问，从而实现了资源和应用程序的高可用性、可伸缩性和可管理性。与网络负载平衡群集不同，当群集中的一台服务器、资源或支持群集的应用程序无法使用时，将被转移到另一台可用的服务器上。

·         网络负载平衡群集

网络负载平衡群集为基于TCP/IP的服务提供了高可用性和可伸缩性，包括Web服务器、FTP服务器、其他关键任务服务器以及COM+应用程序。在网络负载平衡方案中，多台服务器相互独立运行，相互之间不共享任何资源。客户端的请求被分配到各个服务器上。当其中一台服务器出现故障时，网络负载平衡群集会检测到这个问题，并将负载重新分配到其他服务器上。SQL Server 2000故障转移群集不属于这种类型，但可以是整体体系结构中的一部分。在这个体系结构中，使用网络负载平衡群集的Web农场与故障转移群集相连接。由于您将根据应用程序的需要来部署网络负载平衡群集，因此您必须在应用程序规划和配置阶段考虑网络负载平衡。

Windows群集所需的硬件

Windows群集（Microsoft Windows 2000 Advanced Server和Windows 2000 Datacenter Server的特性之一）和Microsoft群集服务（MSCS，Microsoft Windows NT® 4.0, Enterprise Edition的特性之一）使用了以下各种硬件组件：

·         群集节点

节点是群集中的一台服务器。Windows NT Server 4.0, Enterprise Edition和Windows 2000 Advanced Server都支持双节点群集，Windows 2000 Datacenter Server最多可支持4节点群集。

·         心跳（Heartbeat）

心跳是群集各节点间的一种专用网络设置，用于检查服务器是否设置完成并能正常运行。心跳通常按照一定的时间间隔运行，这种间隔被称为时间片（time slice）。如果心跳无法正常进行，就会启动故障转移，由群集中的另一个节点接管其服务。

·         外部网络

除了心跳专用网络外，至少需要再启用一个公共网络，从而使得群集具有外部连接功能。

·         共享的群集磁盘阵列

共享的群集磁盘阵列是一组群集可以访问的物理磁盘（SCSI RAID或FibreChannel）。Windows群集支持非共享磁盘阵列。非共享磁盘阵列是一种在任何给定时刻只有一个节点拥有给定资源的模式。所有其他节点在拥有资源之前都无法进行访问。这种模式能够防止在两台计算机同时具有同一个驱动器的访问权时盖写数据。

·         仲裁驱动器

仲裁驱动器是指定在Windows群集的共享磁盘阵列中的逻辑驱动器。该驱动器不断地进行更新，其中包含有关群集状态的信息。如果这个驱动器出现错误或被破坏，那么群集安装也会出现错误或被破坏。

操作系统

下面列举了一组操作系统级别的组件，也称为群集资源：

·         群集名称

这个名称指群集本身，而不是SQL Server虚拟服务器，所有的Windows NT或Windows 2000外部连接都使用该名称；不指向单个节点。

·         群集IP地址

所有外部连接都使用这个IP地址联系故障转移群集本身，而不是SQL Server虚拟服务器。

·         群集管理员帐户

这个帐户用来管理和拥有故障转移群集。群集管理员帐户必须在域级别上创建，同时必须属于群集中所有节点的管理员。

·         群集资源类型

群集资源包括各种可以在群集中配置的服务、软件或硬件，其中包括：DHCP、文件类型、通用应用程序、通用服务、Internet协议、网络名称、物理磁盘、后台打印和WINS。

·         群集组

群集组是一组根据一定逻辑组织的群集资源，可以包括支持群集的应用程序服务，例如：SQL Server 2000。从概念上说，群集组是在您硬盘上的一个文件夹，其中含有相关的信息。

虚拟服务器

理解虚拟服务器的概念是理解故障转移群集的关键。对于一个客户端或应用程序来说，虚拟服务器是用于访问的服务器名称或IP地址。建立从客户端到虚拟服务器的连接不需要知晓当前群集的哪个节点托管了虚拟服务器。群集的SQL Server被称为SQL Server虚拟服务器。

什么是SQL Server 2000故障转移群集?

SQL Server 2000构建在Windows群集或MSCS基础之上，是一种支持群集的应用程序。在图1中，SQL Server 2000的虚拟服务器位于现有的MSCS安装之上。

图1：SQL Server 2000虚拟服务器示意图。本例中包含两个服务器节点及一个SQL Server 2000虚拟服务器。

SQL Server虚拟服务器组件

实例是一种完全独立的SQL Server安装，拥有几个影响SQL Server 2000在群集环境中的运行方式的底层共享组件。SQL Server虚拟服务器是一个已群集的SQL Server 实例。每台虚拟服务器由下列资源组成：

·         SQL Server网络名称

这是用户和应用程序用来连接SQL Server的名称。

·         SQL Server IP地址

用户和应用程序将使用这个TCP/IP地址连接SQL Server。该地址与群集的IP地址不同。

·         SQL Server

用于控制该SQL Server 2000服务实例。

·         SQL Server Agent

用于控制该SQL Server Agent服务实例。

·         SQL Server 2000 全文搜索

除了SQL Server和SQL Server Agent资源之外，每个虚拟服务器还拥有一个全文资源；每个实例都指向共享的Microsoft Search服务。当出现故障时，它与其他服务的反应不一样；仅将数据文件进行故障转移，而不是服务。

·         Microsoft分布式事务协调器（MS DTC）

SQL Server的一些安装利用了MS DTC。如果您的安装出现这种情况，那么群集中的所有实例将共享这个MS DTC。

·         SQL Server虚拟服务器管理员帐户

这是SQL Server服务帐户。这个帐户可以与前面提到的群集管理员帐户雷同。如果您使用Windows NT 4.0 Enterprise Edition，这个服务帐户还必须在所有节点上都具有管理员权限；但如果使用Windows 2000则不需要。有关创建这个帐户的更多信息，请参考SQL Server 2000 Books Online（在线图书）的“设置Windows服务帐户”。

正如“故障转移群集的改进”一节中所提到的，SQL Server 2000可在每台服务器上支持多个实例——一个默认实例和最多15个指定实例，或者16个指定实例。SQL Server可以作为为默认实例或指定实例安装。SQL Server 2000虚拟服务器也可以拥有多个本地指定实例或一个SQL Server 7.0默认实例，但是在Windows群集中无法看到这些实例。其属于服务器的本地实例。

重要须知：SQL Server 2000的实例无法在SQL Server 6.5或SQL Server 7.0群集上运行。

在加入实例这个概念后，衍生出两种故障转移群集的新概念：

·         单实例群集：替代活动/被动群集。单实例群集意味着已安装了一台SQL Server 2000虚拟服务器。

·         多实例群集：替代活动/活动群集。多实例群集意味着已安装了多台SQL Server 2000虚拟服务器。由于群集的这种实施方式与SQL Server 2000并不一样，因此“活动/活动”这个术语并未真正得到体现。

单实例群集

单实例群集只拥有一个SQL Server活动实例，由一个单一服务器节点所拥有，群集的其他所有节点都处于等待状态。当活动节点出现故障或为了进行日常维护进行手动故障转移时，才启用另一个节点。

多实例群集

一个多实例群集最多拥有4个服务器节点，支持最多16个实例（1个默认和15个指定的实例，或者16个指定实例）。每台SQL Server 2000虚拟服务器都需要拥有其他实例无法使用的磁盘资源。这些磁盘资源指逻辑驱动器名称（例如，驱动器F：/），SQL Server用这种资源来存储数据和日志文件。为了设置这个逻辑驱动器，您需要多个相互独立的物理磁盘，除非您的磁盘子系统支持同一个物理磁盘上的多个逻辑驱动器。从IP端口方面考虑，群集环境中的SQL Server的行为也与单机的指定实例不同。在安装过程中，可能配置了一个动态端口，这个端口可以是除1433以外的其他端口，1433这个端口号是为该实例保留的。在故障转移群集中，多个实例可以配置为共享同一个端口，例如 1433。这是因为故障转移群集只侦听分配给SQL Server虚拟服务器的IP地址，因此实例和端口的比例并不需要1：1。但是，出于安全考虑以及可能增加的可用性，您可能需要为每个虚拟服务器指定其自己单独的端口，或者保持安装时的配置不变。

故障转移群集的运作原理

群集节点使用心跳检查每个节点是否正常运转，这种检查同时针对操作系统和SQL Server两个层面。在操作系统层面，群集中的节点争用群集的资源。主节点每3秒检查一次资源，争用节点每5秒检查一次。这个过程持续25秒钟，然后重新开始。例如，如果拥有实例的节点在19秒时由于某个问题（网络、磁盘等待）出现了故障，争用节点在20秒时侦测到这个故障，如果它确定主节点不再具有资源控制权，那么争用节点就会接管该资源。

在SQL Server层面，托管SQL Server资源的节点每5秒进行一次looks-alive（表面正常）检查。这是一种判断服务是否仍然在运行的轻量级检查，即便在SQL Server的实例停止运行时仍然顺利进行。相比较而言，IsAlive检查更为全面一些，其需要对服务器发出一个“SELECT @@SERVERNAME Transact SQL”查询，用以确定服务器本身是否能够响应请求；但仍然无法保证用户数据库正常运行。如果这个查询失败了，那么IsAlive检查会再尝试五次，然后试图重新连接到SQL Server的实例。如果五次尝试全部失败了，那就意味着SQL Server资源出现了故障。根据该SQL Server资源的故障转移阈值设置，Windows群集将试图在同一个节点上重新启动这个资源，或者转移到另一个可用的节点。这个查询能够接受少量错误，例如：许可证问题或已暂停的SQL Server实例，但是如果超过阈值将最终导致查询失败。

在从一个节点到另一个节点的故障转移过程中，Windows群集将在新的节点上为这个实例启动SQL Server服务，然后通过恢复过程启动数据库。SQL Server虚拟服务器的故障转移需要少量时间（可能是几秒钟）。在服务启动，主数据库联机后，SQL Server资源就被认为是已经启动了。接着，用户数据库将执行常规的恢复过程，这意味着所有在事务日志中已经完成的事务将前滚，而没有完成的事务将回滚。恢复过程的时间长度取决于必须进行前滚或回滚操作的活动数量。您可以将服务器的恢复间隔设置为较低的数值，这样能够避免过长的恢复时间，并能加速故障转移过程。

客户端连接和SQL Server 2000虚拟服务器

最终用户和应用程序通过SQL Server 2000虚拟服务器的SQL Server网络名称或IP地址访问SQL Server 2000虚拟服务器。无需使用群集名称、群集IP地址或单个节点的名称进行连接。从客户端或应用前景的角度来看，并不需要去考虑哪个节点拥有这些资源，连接到SQL Server 2000虚拟服务器就像一个普通的SQL Server。在故障转移过程中，所有活动的连接将被中断。对于Web浏览器用户，简单的Web页面刷新就能够创建一个新的数据库连接。而针对更传统的客户端/服务器应用程序，或特别依赖中间层的应用程序来说，应用程序的设计人员可能需要考虑检查连接是否存在。如果不存在连接，则需要重新进行连接。因此，无论在服务器出现故障时用户在处理何种类型的事务，都可能无法完成，除非在服务器出现故障前事务已经执行完毕，或者事务在应用程序内进行处理。

更多信息，请参考知识库文章“Q273673 – 虚拟服务器客户端连接必须由客户端控制”：

http：//support.microsoft.com/support/kb/articles/q273/6/73.asp

　

　

配置SQL Server 2000故障转移群集

在顺利安装SQL Server 2000故障转移群集这一问题中，最重要的莫过于确保对设计运行于故障转移群集的应用程序部署正确的硬件和软件。这些硬件应具有高性能，能够按访问SQL Server应用程序的特殊需要进行伸缩。

为故障转移群集设计您的应用程序

在开始设计硬件之前，您应该考虑可能发生于故障转移过程中的行为。在采用故障转移群集时，必须考虑一些应用程序设计时应注意的事项。

·         尽量缩小所有事务，提交合理的工作量。由于虚拟服务器要通过启动过程，其中包括通过每个数据库的事务日志，回滚或前滚事务，因此较大的事务以及较大的事务量将延长故障转移时间。

·         如果一个应用程序使用了Windows群集服务器群集API，那么将被认为其支持群集。有关Windows群集API的更多信息，请参考下方位于“MSDN开发人员中心”的链接。

http：//msdn.microsoft.com/library/default.asp?url=/library/en-us/mscs/hh/mscs/win_clus_9nfr.asp

·         在应用程序中设置超时值，正确地关闭连接或作出其它正确的响应，例如：友好信息等，从而实现良好的用户体验。最终用户不必担心数据库问题。

·         与前一点相关联的是，如果连接被中断了，用户可重试逻辑，重新连接数据库。有些应用程序的编程模型中包括了重试逻辑，例如：Microsoft BizTalk Server。但如果不存在这样的产品，那么可能需要设计一个定制的解决方案，例如：使用某类中间件。

管理员帐户和SQL Server 2000故障转移群集

在安装服务器群集和SQL Server 2000虚拟服务器之前，需要配置几个Windows级别的帐户。

·         必须为服务器群集的管理和所有权创建一个帐户。其必须是一个有效的域管理员帐户。同时，在安装SQL Server 2000虚拟服务器过程中也要使用这个帐户。

·         至少必须创建一个帐户用以管理SQL Server和SQL Server Agent。这可以是两个不同的帐户，不一定非得是域管理员，但必须是一个有效的域帐户。如果需要，可以使用上方所列的同一个帐户，但是使用不同的帐户更好一些。

虽然在安装过程中，这个帐户会被自动赋予适当的优先级别，但如果要改变这个帐户，那么必须满足以下的条件（或者管理员组必须满足以下条件）：

·         必须是本地管理员组的成员（仅针对Windows NT 4.0, Enterprise Edition）。

·         必须被赋予“作为操作系统的一部分运行”、“作为服务登录”和“替换进程级令牌”策略。

·         群集的服务帐户必须具有登录到SQL Server的权限。如果您接受默认设置，帐户[NT Authority/System]必须具有SQL Server的登录权限，这样SQL Server资源DLL才可以向SQL Server发送IsAlive查询。

注意 请记住，任何要求更改帐户密码的企业策略（例如：必须每90天修改密码）都可能影响虚拟服务器的可用性，因为您将需要重新配置每个SQL Server 2000虚拟服务器，包括停止和重新启动以使更改生效。在规划您的环境所需要的可用性程度时需要考虑到这一点，并将之与企业的安全性进行权衡。

重要须知：如果您需要更改与SQL Server虚拟服务器（SQL Server或SQL Server Agent）相关的帐户密码，请使用SQL Server Enterprise Manager（企业管理器）。该程序可以改变所有节点上的服务密码，并赋予所选用户帐户所需的权限。如果未使用SQL Server Enterprise Manager更改密码，而使用基于Windows的服务工具修改底层服务，那么您可能无法在关机或故障转移后启动SQL Server，而像全文搜索这样的功能也可能无法正常运行。

安全性

如果您的整个解决方案中包含Kerberos、SSL或IPSEC等高级安全性，那么请在规划故障转移群集时考虑下面几个问题：

·         目前，Kerberos无法用来对群集虚拟服务器的连接进行身份验证；客户端将尝试使用NTLM身份验证。其他信息或相关内容更改，请参考知识库文章“Q235529 –Windows 2000域环境中MSCS虚拟服务器的局限性”：

http：//support.microsoft.com/support/kb/articles/q235/5/29.asp

·         在群集环境不支持IPSEC。

·         如果安装的SSL证书与您SQL Server虚拟服务器的名称相同，那么这个SQL Server 实例可能无法启动。更多信息，请参考知识库文章“Q283794 – 在群集SQL Servers中结合虚拟名称使用证书的有关问题”：

http：//support.microsoft.com/support/kb/articles/Q283/7/94.asp

软件要求

SQL Server 2000故障转移群集需要SQL Server 2000 Enterprise Edition及下列操作系统之一：

·         Microsoft Windows NT Server 4.0, Enterprise Edition（至少含Service Pack 5）

·         Microsoft Windows 2000 Advanced Server

·         Microsoft Windows 2000 Datacenter Server

硬件要求

SQL Server 2000虚拟服务器不应该仅仅是高度可用的SQL Server 实例，而且应该是具备高性能和高可伸缩性的SQL Server 实例。您可以通过两个主要因素来确定硬件需求：

·         目前应用程序或Web站点的工作负载是多少？今后6个月、一年、甚至两年的预计工作负载是多少？

这是大多数人在实施解决方案时所没有掌握的信息。掌握应用程序或Web站点运行的基准对于确定购买何种操作系统和硬件至关重要。评估一个应用程序的最佳方法就是将其置于实验室环境中。使用适当的工具可以建立性能趋势示意图，如：系统监控器（Windows NT 4.0中的性能监控器）。但缺乏基准或某种性能文档，很难确定确切的需要。另外需要注意所有影响性能的应用程序问题，无论这些问题是在当前的产品版本还是在计划的更新版本中。

·         项目的预算是多少?

虽然资金不应该是可用性的障碍，但在现实中的确需要考虑预算问题。在购买群集解决方案前，您可以根据下面几个问题来评估您的硬件需求：

·         您希望这些服务器使用多长时间？

·         您是否有足够的磁盘空间维持这一期限？

·         在这一期限内您是否有足够的内存和CPU容量？

这种规划方式可以避免在性能和容能方面硬件的成长超过预期设想。这样您将不需要经常进行升级，因此您的解决方案也将更加可用。

重要须知：对故障转移群集中所有节点进行配置，至少使其相互保持一致。但是，如果您计划配置一个节点，使其拥有较其他节点更多的虚拟服务器，那么请将该节点配置为能够处理可能托管的全部虚拟服务器容量。节点性能不足可能会影响到可用性。

对于高可用性解决方案，请考虑实施故障转移群集。但是如果您买不起Microsoft 硬件兼容性列表（HCL）中所要求的完整的群集解决方案，那么可以考虑其他的高可用性备选方案，例如：日志递送。虽然该解决方案需要HCL兼容设备，但不需要您购买一个完整的解决方案或为Windows群集购买专门的硬件。

硬件兼容性列表

在决定所有的最终硬件选择之前，请查询Microsoft硬件兼容性列表（HCL）。完整的硬件解决方案必须包括在“群集”分类的服务器配置中。购买单独的组件，即使所购买的组件列在HCL中，也无法创建一个受支持的解决方案。如果解决方案未列在HCL中，那么其群集配置将不受支持。有关受支持的群集配置的更多信息，请参考知识库文章“Q264476 –仅在HCL认证的系统中支持群集”：

http：//support.microsoft.com/support/kb/articles/Q264/4/76.asp

以及“Q224971 – Microsoft群集服务器硬件兼容性列表与测试”：

http：//support.microsoft.com/support/kb/articles/Q224/9/71.asp

　

HCL可以在http：//www.microsoft.com/hcl上找到。

 

处理器

根据您所选择的操作系统，可以使用不同数量的处理器。

操作系统

处理器数量上限

Windows NT 4.0, Enterprise Edition

8

Windows 2000 Advanced Server

8

Windows 2000 Datacenter Server

32

　

如果您在实验室或其他可控环境中对应用程序的性能进行测试，首先应该确定所需的基本处理能力。确定所需基本处理能力的一种方法就是分析您系统随时间的扩展情况，定期记录相关统计数据，然后将这些信息绘制成图表。这是非常重要的一个步骤，产品服务器的配置应该同时考虑目前的工作负载以及工作负载随时间的增长。

从操作系统角度考虑，群集需要Windows NT 4.0 Server, Enterprise Edition、Windows 2000 Advanced Server或者Windows 2000 Datacenter Server。Windows 2000 Datacenter Server能够提供最完善的解决方案；其专门针对高可用性而设计，需要一个服务层协议（Service Level Agreement）。如果操作系统没有在上表中列出，那么意味着这个操作系统无法支持4个以上的处理器。

注意   Windows 2000 Datacenter Server属于Windows数据中心计划（WDP）的一部分。 您无法通过与购买大部分Microsoft产品一样的途径获得Windows 2000 Datacenter Server，而必须作为整体解决方案的一部分从参与WDP计划的开发商处购买。更多相关信息，请联系认证开发商，或参考Windows 2000 Datacenter Server Web站点：http：//www.microsoft.com/windows2000/guide/datacenter/overview/default.asp

内存

根据所使用操作系统的不同，SQL Server 2000可利用的最大内存容量也不尽相同。在未启用地址窗口扩展（AWE）的情况下，安装SQL Server 2000 Enterprise Edition最多能够在Windows Datacenter Server上支持32GB的内存。下表列出了每个操作系统中SQL Server 2000可用的最大内存量。

操作系统

最大值

Windows NT 4.0, Enterprise Edition

3 GB

Windows 2000 Advanced Server

8 GB（启用AWE）

Windows 2000 Datacenter Server

64 GB（启用AWE)

 

地址窗口扩展和物理寻址扩展内存

通过AWE，内存密集型应用程序可以更有效地在SQL Server 2000中运行，从而提高性能。 Windows 2000 Advanced Server和Windows 2000 Datacenter Server都引入了改进后的AWE API，后者允许应用程序访问大量的物理内存。由于受到32位内存寻址的限制，未启用AWE的Windows NT 4.0和Windows 2000仅能够使用最多4 GB的物理内存。在默认情况下，其中2 GB分配给操作系统，另外2 GB分配给应用程序。如果在操作系统所用的boot.ini中加入/3GB开关，那么像SQL Server这样的应用程序则可以访问最多3 GB的内存，但操作系统所用的内存数量则降低到了1 GB。因此即使服务器配置有8 GB的内存，所有超出的4 GB内存实际上无法使用。AWE是一种内建于操作系统中的支持，使基于Win32®的应用程序能够使用扩展内存。

AWE需要应用程序（例如：SQL Server 2000）专门为AWE编写代码。SQL Server 2000中的AWE支持必须通过sp_configure中的awe enabled（启用awe）选项进行配置，并需要为每个实例进行设置。在默认情况下，awe enabled被设置为0或者关闭。启用SQL Server 2000中的AWE支持还需要一些其他的操作系统配置。更多相关信息，请参考SQL Server Books Online的“AWE内存”。

还有一种方法也可以使您能够使用更多的内存，那就是物理寻址扩展（PAE）。PAE使得32位的操作系统能够对4 GB以上的内存进行寻址。有关PAE的信息，包括具体设置，请参考知识库文章“Q268363 － Windows 2000中的Intel物理寻址扩展（PAE）”：http：//support.microsoft.com/support/kb/articles/Q268/3/63.asp

注意  如果启用了PAE，那么您可能会遇到有关Windows 2000或SQL Server 2000备份的备份和恢复错误。请参考知识库文章“Q280793 – 在PAE模式下运行时无法查看SQL Server 2000或Windows 2000备份”：http：//support.microsoft.com/support/kb/articles/Q280/7/93.asp

在为您的群集解决方案选择硬件时，如果您计划使用大内存，那么请确认配置可支持大内存的硬件。您可以在HCL所有分类中搜索关键词“海量内存”进行查找。

下表总结了您设置大量内存时所应该配置的扩展内存设置。

4 GB或以下

4 GB到16 GB

16GB以上

/3GB开关

启用/3GB

禁用/3GB

　

启用AWE

启用AWE

　

启用PAE（Boot.ini）

启用PAE（Boot.ini）

　

注意  如果您启用了AWE或PAE内存，我们强烈建议在使用服务器之前对配置进行测试。

这三种内存选项的启用采用了两种不同的机制。

/3GB

/3GB选项是一种通过boot.ini文件启用的开关。在您安装完Windows 2000 Advanced Server后，修改boot.ini文件，在ARC路径中加入/3GB参数，格式如下面例子中所列的黑体部分：

multi(0)disk(0)rdisk(0)partition(2)/WINNT="Windows 2000 Advanced Server" /3GB /basevideo /sos

　

PAE

PAE也是通过boot.ini中的一个开关予以启用的。打开boot.ini文件，在ARC路径中添加/PAE参数，格式如下面例子中所列的黑体部分：

multi(0)disk(0)rdisk(0)partition(2)/WINNT="Windows 2000 Advanced Server" /PAE /basevideo /sos

　

AWE

AWE是通过调用sp_configure在SQL Server 2000查询中启用的，方法如下：

EXEC sp_configure ‘awe enabled’, 1

RECONFIGURE

在实施AWE内存时，请您注意以下几个问题：

·         SQL Server 实例无法对所用的内存地址空间容量进行动态管理。

当在SQL Server 2000中启用AWE时，如果未设置max server memory（最大服务器内存）配置选项，那么SQL Server将会夺取全部可用的内存（除了用于允许操作系统执行基本运行的128 MB内存外），这可能会使操作系统和所有其他流程无法在同一台服务器上运行。

·         在初始化完成之后，AWE内存拥有启动时所获得的所有物理内存，直至被关闭为止。

如果启用了AWE并占用了太多的内存，则必须关闭SQL Server，对其进行重新配置，这样将导致停机时间（使得高可用性方案的可用性降低，例如：故障转移群集）。由于SQL Server 实例所使用的内存页是从不可分页的池中提取的，因此这些内存无法进行交换。这就意味着一旦物理内存被全部填满，那么SQL Server将无法使用设置在物理磁盘上的页文件使用剩余的内存。

·         如果配置了max server memory选项，那么请将工作区大小设置为0。

有关在服务器上配置AWE内存的更多信息，请参考SQL Server Books Online中的“在Windows 2000中使用AWE内存”，以及下列内容：

·         “PAE服务器设置”，其中包括一些白皮书（包含“在Windows 2000中支持PAE内存”）的链接：http：//www.microsoft.com/hwdev/PAE

·         “地址窗口扩展与Windows 2000 Datacenter Server”白皮书：http：//www.microsoft.com/hwdev/NTDRIVERS/AWE.htm

 

网络

应该将网卡的自动感应设置为符合您LAN或WAN网络的静态速度。例如，如果您的网络被配置为100兆字节全双工，那么也将所有的网卡配置为100 MB。SQL Server 2000支持多个IP地址（分别针对各个子网）和网卡。如果需要更大的带宽，SQL Server 2000能够通过Giganet或Compaq的Servernet II技术，支持更大的带宽网络。如果使用了这些技术，就能够在多台SQL Server服务器间实现更高的性能。Giganet属于内建支持，启用Servernet II的更新程序位于：http：//www.microsoft.com/sql/downloads/servrnet.asp 。

　

节点位置

由于各种限制，如：SCSI或FibreChannel所支持的距离上的物理限制，故障转移群集中各节点必须放置在比较接近的地方。但服务器群集并不关注距离，因此从理论上说这些节点可以放置在任何地方。如果要配置了一个地理位置上分散的群集，请考虑下面几点：

·         群集节点间的专用和公共网络连接必须是单独的无路由局域网（LAN），使用虚拟LAN（VLAN）等技术。在这种情况下，网络必须保证节点间连接的最大回路等待时间必须低于500毫秒。群集互连必须属于标准的局域网连接。

·         所有地理上的复制存储技术都必须保留单磁盘语义，例如：Windows群集的逻辑单位的固定仲裁。仲裁磁盘必须实时复制，在所有站点中实现同步。

配置地理位置上分散的群集很复杂，需要精心规划。在实施您的群集解决方案之前，请咨询您的硬件开发商。同样采用的硬件和软件配置必须是硬件兼容性列表所列出的，并作为一个群集解决方案进行购买，这样才能获得Microsoft的支持。您可以在HCL的“群集/地理位置”分类中找到受支持的地理分散群集。有关地理分散群集的更多信息，请参考Q280743 “Windows群集与地理分散的站点”：

http：//support.microsoft.com/support/kb/articles/Q280/7/43.asp

另一种能够实现不同地理位置间的高可用性的方法是利用日志递送，它是SQL Server 2000 Enterprise Edition的特性之一。日志递送是这样一个流程：根据所设定的时间安排，将来自一个服务器的事务日志应用到另一个服务器上。日志递送支持物理分散的位置，使得其非常适合于消除单点故障，保护由于自然灾害等事件造成的数据丢失。有关日志递送的更多信息，请参考SQL Server 2000 Books Online（在线图书）或Microsoft SQL Server 2000 Resource Kit的第13章“日志递送”。

哪种备选方案最适合您呢？即使采用了第三方解决方案，在配置日志递送以外的远程解决方案时都需要仔细地规划和调试您的网络。虽然日志递送需要各地点之间的连接性，但是不受500毫秒的时间限制；因此可以存在更长的等待时间，例如您可以实现从伦敦到旧金山的日志递送。但是这两种解决方案都需要一个在故障发生时所采用的适当计划。与群集解决方案相比，日志递送需要更多的人工干预和管理。这是因为日志递送无法自动执行角色更改，而角色更改却是实现热备用联机所必需的。

 

配置最佳实践

除了理解故障转移群集的基本原理以外，您还会发现记住下面的技巧和最佳实践对于配置您的服务器十分有用。

磁盘配置和文件放置

所有数据库系统的主要组件即存储器——其包含了应用程序所用及插入的重要数据。为了实现高可用性，SQL Server用于存储数据和日志的磁盘必须属于错误冗余外部阵列的一部分。这些磁盘必须是高速的，同时支持大量的I/O和庞大的存储空间，从而允许您的数据库能够随着时间扩展。需要记住的是，在故障转移群集中，共享的群集磁盘阵列是一个单点故障。缓解这种风险的方法之一是暗中保留备用硬盘，以备发生故障时使用。

这些磁盘可以配置为小型机算计系统接口（SCSI）或FibreChannel（光纤通道）。在实施共享磁盘阵列时，我们推荐采用FibreChannel。FibreChannel是专门为高带宽和高容量而设计的。存储区域网络（SAN）是使用FibreChannel上的网络协议执行所有I/O的磁盘阵列。如果购买的完整群集解决方案中包括一个群集/多群集设备，那么在使用故障转移群集时就可支持SAN的使用。

可以在SAN环境中使用Windows群集。HCL群集/多群集分类设备中列出了一组可使用SAN的存储设备。这些设备都受支持，并且已经通过了作为连接多个MSCS群集的SAN存储单元的测试。通过将本列表中的设备与HCL群集类中所定义的完整群集配置相匹配，您可能能够以Microsoft支持的方法在具有SAN结构的共享存储设备上部署一组Windows服务器和群集。更多有关群集的SAN支持的信息，请参考知识库文章“Q304415 – 支持连接同一个SAN设备的多个群集”：http：//support.microsoft.com/support/kb/articles/q304/4/15.asp。

注意 Windows 2000 Datacenter Server群集不支持SCSI，必须使用FibreChannel。

注意 在群集环境中不支持网络直连存储（NAS）设备。更多的相关信息，请参考知识库文章“Q304261 – 支持网络数据库文件”：http：//support.microsoft.com/support/kb/articles/q304/2/61.asp

数据和日志设备以及tempdb应该放置在不同的磁盘中，并且尽可能使用更多不同的通道。不过这样会限制能够在群集上安装的实例数量。如果您的系统非常巨大，或者具有热区，那么您可能会决定采用文件组作为划分磁盘I/O的方法。然后将文件组放置在不同的磁盘和不同的通道上，对磁盘I/O进一步划分，这样将有助于提高系统性能。在您分析高可用性设计时，注重文件放置和通道使用是相当重要的。由于瓶颈而导致的性能问题可能会被误认为是可用性问题。物理文件/磁盘布局问题可能需要停机才能解决，这将降低您系统的可用性。

数据驱动器应该使用条带镜像的RAID配置，以实现最高的可用性。这意味着首先这些驱动器被逐一映射，然后整个系统进行条带化。条带镜像有时被称为RAID 1+0。另一个对可用性有益的方法是镜像条带，其所提供的性能较条带镜像稍好一些，有时被称为RAID 0+1。镜像条带意味着一组磁盘被条带化成一个集合，然后再进行映射。与条带镜像一样，两者都无法实现容错。这几年很流行的RAID 5无法提供最高的可用性和性能。但如果无法实现条带镜像或镜像条带，那么无论从费用还是硬件限制方面考虑，RAID 5都是一个不错的选择。

日志驱动器可以使用RAID 1（普通镜像）或条带镜像/镜像条带进行配置。日志需要重点保护，因此您需要为您的高可用性计划选择合适的磁盘可用性。

注意 对于不同的开发商间，条带镜像和镜像条带（也就是0+1和1+0）的术语可能有所不同。

重点 下面是对服务器群集中磁盘使用的几点提醒：

·         Windows群集不支持动态磁盘。更多的相关信息，请参考知识库文章“Q237853 –服务器群集磁盘不可采用动态磁盘配置”，地址为 http：//support.microsoft.com/support/kb/articles/q237/8/53.asp

·         群集数据库服务器不支持文件压缩。

·         群集不支持软件RAID；必须使用硬件RAID。

　

其他信息和配置工作表，请参考附录C中的“共享群集磁盘分区配置工作表”和“SQL Server 2000故障转移群集磁盘配置工作表”。

仲裁磁盘

不要将任何数据库文件放置在仲裁磁盘中，例如：数据或日志文件。在默认情况下，SQL Server 2000 安装不采用仲裁磁盘，除非没有其他磁盘可用。从物理磁盘的角度来看，如果可能，仲裁磁盘应该放置在单独的主轴和单独的驱动器上，与SQL Server数据分开。

控制器配置

选择具有充足通道的卡来划分磁盘的逻辑组，从而降低I/O争用。但是这将限制您可以安装的虚拟服务器数量。如果FibreChannel/RAID控制器在节点内，而不在共享磁盘阵列中，那么应该禁用回写缓存。因为即使采用后备电池，一旦资源故障转移到了另一个节点，仍然可能有项目驻留在缓存中。如果服务重新转移回这个节点，则可能由于控制器试图覆盖磁盘上的内容而导致出错。如果事务在缓存中而没有被处理，那么也可能会在故障转移中发生数据丢失。

使用多个RAID控制器不仅可能提高性能并降低I/O争用（这将提高可用性），而且这样的硬件级冗余能力也可以为您在一个RAID控制器出现故障的情况下提供高可用性。

确保虚拟服务器能够看到逻辑磁盘

在故障转移群集中，如果虚拟服务器无法“看到”磁盘资源（即逻辑驱动器盘符），那么虚拟服务器将无法正常运行。发生这种情况的原因可能有两种：

·         可能没有安装正确的磁盘驱动器。

确保正确安装了磁盘驱动器。在某些情况下（例如，操作系统从Windows NT 4.0, Enterprise Edition升级到Windows 2000 Advanced Server），Windows 2000有一些专门的驱动器，但是旧的驱动器可能仍然在系统中。

·         驱动器可能不是SQL Server 2000虚拟服务器的一个从属驱动器。在虚拟服务器的安装过程中，只能选择一个数据驱动器。因此如果SQL Server 2000虚拟服务器需要多个驱动器，您需要在安装完成后添加从属驱动器。要检查驱动器是否是虚拟服务器的从属驱动器，请参考本白皮书后面的“SQL Server 2000故障转移群集组与从属”一节。

将逻辑磁盘添加到群集配置中

由于Windows群集不支持动态磁盘，因此在最初配置完成后将磁盘添加到配置中将需要一些停机时间。请参考知识库文章“Q175278 – 如何在共享SCSI总线上安装额外的驱动器”，了解有关在群集配置中添加驱动器的内容。您可以在下方地址中找到这篇文章：

http：//support.microsoft.com/support/kb/articles/Q175/2/78.asp

一旦驱动器在Windows群集层次上被识别，就将使SQL Server群集资源脱机，然后在群集管理器中将驱动器添加为从属设备。在重新恢复SQL Server资源联机后，SQL Server虚拟服务器将能够使用这个新的驱动器。

在群集配置中扩展现有的逻辑磁盘

您可以在已定义的群集磁盘中在硬件层次上对现有磁盘空间进行扩展。请参考知识库文章“Q263590 –如何通过Windows群集扩展现有共享磁盘的磁盘空间”，了解如何扩展群集配置中的驱动器。您可以在下方地址中找到这篇文章：

http：//support.microsoft.com/support/kb/articles/Q263/5/90.asp

请记住，这可能会导致一定的停机时间，而且必须首先规划，从而不至于对最终用户的可用性产生影响。

群集节点和Windows域

群集中所有节点必须是同一个域的成员，而且必须能够访问域控制器和域名系统（DNS）服务器以及WINS服务器。如果您要安装SQL Server，那么这些节点不应该配置为域控制器，不然您可能会遇到一些问题。实际上，域控制器功能（如：Active Directory）并不支持群集，因此所有的信息都是本地的。这将对一些事情产生影响，例如：由于虚拟服务器的计算机对象无法在群集中运行，因此具备目录功能的程序在虚拟服务器的计算机对象下的发布能力将会受到影响。在群集环境中，Windows 2000/SQL Server 2000仍然需要WINS服务器。更多的相关信息，请参考知识库文章“Q235529 – Windows 2000域环境中MSCS虚拟服务器的局限性”：

http：//support.microsoft.com/support/kb/articles/Q235/5/29.asp

使用多个IP地址

当对网卡进行配置以备群集使用时，您应该根据给定的网卡数量，以及必须支持的网络类型数量，考虑可用的方案。同时您需要了解，如果您分配了更多的IP地址以允许对SQL Server的连接，那么将可能影响到故障转移群集的可用性。这是因为在某些情况下，您可能无法控制路由器对网络进行重新路由。

例如，您可能试图为所有的通讯配置一个网卡，从而最大限度利用您的网卡，以便进行所有通信活动：

·         所有外部客户端连接和节点间流量。

·         内部群集（仅针对群集节点间的专用网络）。

·         仅限客户端访问（允许客户端连接的公共网络）。

即使仅需群集中的一个网卡就可以处理所有群集的网络通讯，也不要这样做，因为这将会是一个单点故障。最佳的配置是使用不同的网卡处理不同类型的连接。

理想的情况是，每个SQL Server都具有在不同子网中的三个IP地址和三个网卡：

·         心跳

这应该被配置为“仅限内部群集通讯”，允许节点进行相互间的通讯，而没有来自外部客户端的额外流量，并应位于一个相反的IP类上。更多的相关信息，请参考知识库文章“Q258750 –群集服务器上推荐的专用‘心跳’配置”，地址为http：//support.microsoft.com/support/kb/articles/Q258/7/50. asp

·         客户端连接

如果您仅拥有IP地址可以为客户端访问所用，那么请将其配置为“所有通讯”，这样就能在心跳出现故障时为内部通讯提供冗余能力。如果您拥有多个可以由客户端使用的IP地址，那么您可以将它们配置为“所有通讯”或“仅限客户端访问”。

·         不同的专用网络

这与心跳不同，应该被配置为“仅限客户端访问”。应该对其进行配置，使群集中的服务器能够访问这个特定的IP地址。这个配置将可实现文件传输，或者在最理想的情况下，能够允许对日志递送进行配置，而不影响心跳或客户端网络流量。

所有三个IP地址都不可以在同一个子网中。如果一个以上的IP地址使用同一个子网，将可能出现连接问题。即使这个IP地址没有在群集中使用，也会出问题。例如，下表列出了一些正确和错误的服务器配置。

网卡

正确配置

错误配置

1 – 配置为公共网络

172.21.10.1

172.22.10.1

2 – 配置为公共网络

172.22.10.2

172.22.10.2

3 – 配置为专用网络

172.23.7.3

172.23.7.3

4 – 配置为心跳

10.10.10.1

172.24.2.5

　

另外，有些网卡可支持多个IP地址的绑定。虽然这使得故障转移群集能够与多个网络进行通讯，但这可能是一个单点故障。在高可用性解决方案中应该避免这种情况。因此，请始终确保您为每个所需的功能至少配置一个网卡，即使这个网卡能够支持多个IP地址。

更多的相关信息，请参考知识库文章“Q175767 –同一个网络中多个适配器的预期行为”： http：//support.microsoft.com/support/kb/articles/q175/7/67.asp

内存配置

这一节介绍了在SQL Server 2000故障转移群集中有关内存使用的注意事项。

单实例故障转移群集

在单实例 SQL Server 2000故障转移群集中，故障转移的情形十分简单：如果主节点出现了故障，那么所有流程将转移到指定的已配置的第二节点上（参考本白皮书的“配置节点故障转移优先级”）。从硬件上来看，第二节点和节点A的配置应该总是完全相同的。如果两者存在差异，故障转移节点与主节点的容量不同，特别是内存上的差异（在示例二中可以看到），那么可能会出现一些问题。您需要考虑可能在服务器节点上运行的其它进程，并考虑操作系统的开销。

示例一：双节点，相同配置

您可以将群集节点比作两杯水。两个杯子各能存放4盎司水。A杯有3盎司水，而B杯没有水。如果您将水从A倒到B，不会有任何问题。在SQL Server 2000故障转移群集中，资源可以如同在主节点上一样正常运行。下图显示了这种情况。

　

示例二：双节点，不同配置

我们再次将两个群集节点比作两杯水。A杯能够容纳4盎司水，现在装了3盎司水。B杯能够容纳2盎司。如果您将水从A倒到B，水就会溢出来，因为B杯无法装下A杯中所有的水。因此，如果您的故障转移群集没有足够的物理内存可支持SQL Server 实例，而SQL Server在寻找超出可用物理内存的更多内存，此时就会分配到磁盘上。这样服务器将缺少资源，可能会导致节点无法响应。图3解释了这种情形。

　

多实例故障转移群集

在多实例 SQL Server 2000故障转移群集中，情况就变得更为复杂。在一个节点上同时可以有最多16个实例处于活动状态，此时如何才能有效地管理内存呢？首先，同时也是最重要的，您应该确保所有的服务器具有同样数量的内存，足以处理可能出现故障的实例。另一个重要的考虑事项是使用max server memory来限制SQL Server 2000 实例内存使用的上限（参考本文前面的“地址窗口扩展和物理寻址扩展内存”）。特别是启用了AWE内存的时候，必须在多实例群集中设置max server memory，避免服务器节点缺乏资源。在下面的示例二中会有所介绍。您需要考虑可能在服务器节点上运行的其它进程，并考虑操作系统的开销。

示例一：两个SQL Server 实例，内存无上限

我们再次以两杯水来说明。两个杯子的最大容量都是4盎司。A杯和B杯中都装有3盎司的水。如果您将B杯中的水倒到A杯中。只能装下1盎司，而剩下的2盎司将会溢出。和前面的例子一样，如果故障转移节点没有足够的物理内存来支持第二个SQL Server 2000 实例，而SQL Server在寻找超出可用物理内存的更多内存，此时就会分配到磁盘上。这样服务器将缺少资源，可能会导致节点无法响应。下图解释了这种情形。

 

示例二：两个SQL Server 2000 实例，内存有上限

我们继续将两个群集节点比作存水的杯子。每个杯子的最大容量都为8盎司。A杯和B杯各存放了3盎司的水。如果您将B杯中的水倒到A杯中，A杯能够存下所有的水，而不会溢出。从SQL Server角度来看，为了使这个例子正常工作，必须启用AWE内存，而且每个实例必须使用sp_configure存储程序的max server memory选项将每个实例的内存限制为3 GB。这样在故障转移时，操作系统仍有2 GB 的内存剩余，而所有其它进程仍能正常运行。下图解释了这个情形。

 

处理器容量

对于SQL Server 2000来说，对所需的处理器数量并没有特别的要求。虽然如此，但由于这取决于您的应用程序使用SQL Server的情况，因此每个群集节点都必须配置足够多的处理器，能够处理任何可能在节点上运行的实例的工作负载。除非处理器的关联被设定为虚拟服务器，否则所有的实例将共享服务器中的处理器。确定需要多大的处理能力的最佳方式是在正式运行之前对应用程序进行负载测试，并使用系统监控器进行监控。

例如，您拥有一个运用一个虚拟服务器的应用程序。这是一个始终使用服务器中所有4个处理器的OLTP应用程序，处理器占用率大约为75％。如果在故障转移群集中的第二个虚拟服务器具有相同的处理器占用率，而又被设为替代与第一个虚拟服务器一样的节点。此时，这台服务器可能会变慢，或者可能无法响应，因为其无法处理两个系统的工作负载。除了内存贵乏以外，您也将遇到CPU贵乏问题。

使用两个以上的节点

当您在SQL Server 2000故障转移群集中使用两个以上的节点时，您需要考虑以下问题：

·         每个实例需要配置多少内存？

·         哪个节点是特定实例的故障转移群集节点？首选顺序如何？

·         是否有足够的磁盘空间和内存用以支持每个配置的实例都能转移到一个特定的节点上？

·         硬件是否被配置为支持故障转移群集，而不影响其他实例？

在操作系统支持的情况下，SQL Server 2000可以使用4个节点（虚拟服务器的数量不仅受到操作系统选择和硬件容量的限制），最多16个实例。因此随着关键任务系统的日益扩大，这些考虑事项也变得越来越重要。虽然SQL Server可以支持最多16个实例，当并不建议这个数值大于4（在Windows 2000 Datacenter Server群集中，虚拟服务器和节点的比例是1：1）。另外一个考虑事项是可分配的逻辑驱动器数量——由于每个实例需要自己专用的驱动器盘符。由于英语字母表的限制，限制了可用的驱动器盘符数。如果为每个独立的实例分配了多个驱动器盘符，那么可能大大降低可以创建的实例数量。

正如前文所提到的，可能需要在安装后将一个指定的唯一端口分配给SQL Server 2000虚拟服务器。在默认情况下，SQL Server 2000将自动地在虚拟服务器安装过程中分配一个端口。要手动更改这个端口，请使用服务器网络工具。

方案一：4节点多实例 SQL Server 2000故障转移群集，三个活动节点，一个备用节点（N+1）

通过4节点支持，Windows 2000 Datacenter Server为群集配置提供更大的灵活性。在SQL Server环境中使用4节点Windows 2000 Datacenter Server群集时，我们推荐其中三个节点分别拥有一个SQL Server 2000 实例，第四个节点处于热备用状态。这不同与日志递送方案，也不同于单实例故障转移群集，在这种情况下至少有一个节点等待工作。这种情形被称为N+1。您需要将您的故障转移群集配置为允许实例在出现故障后首先转移到另一个运行SQL  Server 2000 实例的节点，除此之外，第四个节点应该配置为主故障转移。这可以减少太多实例缺乏资源所引起的问题。在这种情形下应该启用AWE内存，从而允许每个SQL Server 实例能够寻址操作1 GB的内存。这允许您的应用程序在超出SQL Server的内存分配时进行伸缩，而不是对它们进行限制。

方案二：4节点多实例 SQL Server 2000故障转移群集，所有四个节点都处于活动状态

在四个节点上运行四个SQL Server 2000 实例需要精心规划，因此在故障转移时另一个实例不会因耗尽内存和处理器而缺乏资源。内存所引起的问题不如处理器资源那么严重。例如，如果生产联机事务处理（OLTP）系统的工作负载通常占用8个处理器50％的资源，所有四个活动SQL Server 2000 实例表现出类似行为，内存只能给于处理器一定的补偿支持；必须增加更多的处理器。

其它配置问题

·         在群集中禁用或不安装防病毒软件。更多的相关信息，请参考Q250355 “群集服务中防病毒软件可能导致的问题”：

http：//support.microsoft.com/support/kb/articles/Q250/3/55.asp

·         不推荐在同一个群集中同时托管SQL Server 2000和Microsoft Exchange 2000。

·         确保所有SQL Server拥有自己唯一的网络名称和IP地址。

·         在群集服务器上配置复制时，创建一个用于复制的MSCS文件共享，并配置为在故障转移时所有的群集都能访问该复制。

·         不推荐在SQL Server运行的群集磁盘上使用任何文件共享。

·         所有虚拟资源的NetBIOS名称解析都需要WINS。

·         解决任何可能出现的应用程序问题都可能导致可用性问题，例如：锁定和阻止操作等。

其它考虑事项，请参考SQL Server 2000 Books Online。

SQL Server 2000故障转移群集配置实例

当然，根据您的系统要求和可用的硬件，有多种不同的方法来配置您的故障转移群集。当您了解有关系统的平均及峰值吞吐量的详细信息时，通常能够正确规划您的服务器容量。有关容量规划技巧的详细内容，请参考Microsoft SQL Server 2000管理员指南。

OLTP系统服务器规划

这个设计方案针对典型的OLTP应用程序。事务日志被划分到一组磁盘上，每秒能够支持大量事务。两台服务器拥有相同配置：

·         操作系统：Windows 2000 Advanced Server

·         节点数量：2

·         处理器数量（每台服务器）：8

·         内存（每台服务器）：4 GB

·         SQL Server内存配置： 上限为3 GB

·         操作系统的内置磁盘配置：2到4个内置驱动器（各有9 GB的容量），使用RAID 1。对于4个或4个以上的驱动器，则使用RAID 0+1。

共享的FibreChannel SAN配置

　

GB（总容量）

总磁盘（外置；各拥有18 GB的容量；RAID 0+1）

驱动器上的文件

Drive Q

36

4

仲裁驱动器

Drive R

54

6

事务日志

Drive S

216

24

SQL Server数据文件、tempdb

Drive T

36

4

备份/导入的数据文件（可使用较大的磁盘）

　

配备可实现日志递送的备用服务器的多实例故障转移群集

在一般的高可用性方案中，人们使用故障转移群集作为首选方法。另外也可以将事务日志发送到另一台完全不同的服务器上，以此作为另一种灾难恢复方法。这个服务器（被称为热备用服务器）应该位于另一个地理位置的数据中心内，远离故障转移群集，从而避免单点故障。但是，在这两个位置之间需要良好的网络连接。日志递送是SQL Server 2000 Enterprise Edition的特性之一。更多有关日志递送的信息，请参考Microsoft SQL Server 2000 Resource Kit的第13章“日志递送”以及SQL Server Books Online。

多实例故障转移群集

为了支持未来扩展，可选择一个8路计算机，但仅是增添4个处理器。两个实例都支持OLTP应用程序。实例 1被复制到一个报告服务器上（这里未加说明）。实例 2每周从数据仓库中提取出来，不加以复制。由于这种差异，在实例 1事务日志中添加了一个镜像组。

·         操作系统：Windows 2000 Advanced Server

·         节点数量：2

·         处理器数量（每台服务器）：4

·         SQL Server 2000 实例数量：2

·         内存（每台服务器）：4 GB，SQL Server将每个实例限制在1.5 GB

·         操作系统的内置磁盘分配：2到4个内置驱动器（每个9 GB），使用RAID 1。对于4个或4个以上的驱动器，则使用RAID 0+1。

共享的FibreChannel SAN配置

　

GB（总容量）

总磁盘（外置；各拥有18 GB的容量）

驱动器上的文件

Drive Q

36

4

仲裁驱动器

Drive R

54

6

实例 1： 事务日志

Drive S

36

4

实例 2： 事务日志

Drive T

72

8

实例 1： 数据文件

Drive U

72

8

实例 2： 数据文件

Drive V

36

4

实例 1： tempdb

Drive W

36

4

实例 2： tempdb

Drive X

54

6

备份/导入的数据文件（可使用较大的磁盘）

　

热备用服务器配置

备用服务器必须拥有充足的内存和处理能力，足以在故障转移时支持所有的数据库工作负载。

·         操作系统：Windows 2000 Advanced Server

·         处理器数量： 4

·         内存：4 GB，其中3 GB分配给 SQL Server。

磁盘配置（RAID 1）

　

GB

RAID分区

总磁盘

文件

Drive C

18

A

2（内置）

操作系统、页文件、SQL Server可执行文件以及系统数据库

Drive Z

54

C

6（内置）

备份/导入的数据文件

Drive T

36

E

4（内置）

事务日志

Drive I

180

D

12（外置）

数据文件、tempdb

　

在这种情形下，计算机可用的驱动器比较少。数据能够比较容易的转移到备用系统中，而且吞吐量要求也不会加重产品驱动器容量。但实际上，您应该对此进行测试，确保热备用系统能够处理全部的工作负载。不仅应该做好灾难恢复计划，而且应该在要求更改时对备用服务器进行更新。

多实例 Windows 2000 Datacenter 群集（N+1方案）

在该方案中，有4个具有相似内置磁盘配置的服务器，共享一个外置FibreChannel SAN。在故障转移群集中，有3个SQL Server 2000 实例处于活动状态。对CPU和RAM的要求取决于服务器在群集中所扮演的角色。3个故障转移群集节点相同，每个节点拥有一个实例。第四个节点是指定的故障转移节点，足以应付所有3个实例同时出现故障的情况。该方案采用了AWE内存。故障转移群集需要细致缜密的考虑以及通过认证的硬件解决方案。有关故障转移群集、AWE内存以及N+1配置的更多信息，请参考本文前面的“使用两个以上的节点”一节。

所有实例

·         操作系统： Windows 2000 Datacenter Server

活动实例

·         节点数量：3

·         处理器数量（每台服务器）：8

·         内存（每台服务器）：6 GB、SQL Server所用内存被限制为4 GB

·         操作系统的内置磁盘配置：2到4个内置驱动器（每个9 GB），使用RAID 1。对于4个或4个以上的驱动器，则使用RAID 0+1。

故障转移节点

这个故障转移节点必须拥有足够的内存和CPU，以便支持所有三个活动实例同时故障转移。

·         处理器数量：32

·         内存：16 GB

·         操作系统的内置磁盘配置：2到4个内置驱动器（每个9 GB），使用RAID 1。

共享的FibreChannel SAN配置

　

GB（总容量）

总磁盘（外置；各拥有18 GB的容量）

驱动器上的文件

Drive Q

36

4

仲裁驱动器

Drive T

36

4

实例 1：事务日志

Drive U

36

4

实例 2：事务日志

Drive V

36

4

实例 3：事务日志

Drive I

90

10

实例 1：数据文件
实例 1：tempdb

Drive J

108

12

实例 2：数据文件
实例 2：tempdb

Drive K

162

18

实例 3：数据文件

Drive L

72

8

实例 1：数据文件，可能包括索引

Drive M

72

8

实例 2：数据文件，可能包括索引

Drive N

72

8

实例 3：tempdb

Drive Z

36

4

备份/导入的数据文件

　

在这个例子中，实例 1和2是具有相似访问方式的OLTP应用程序。实例 3是一个决策支持系统（DSS）实例，大量使用tempdb，因此您需要将其迁移到另一个包含多个快速磁盘的驱动器上。请注意，实例 3并不需要为事务日志驱动器配置两个以上的标准磁盘。更多相关消息，请参考由Kalen Delaney撰写的SQL Server 2000内幕（Microsoft Press®出版），以及Microsoft SQL Server 2000 Resource Kit的第33章“数据层：数据库优化方法”。

由于报告系统使用的服务器资源不同于OLTP系统，因此考虑每个工作负载的特性就十分重要。在故障转移时，一个故障转移群集节点可能拥有两台SQL Server 2000虚拟服务器，而系统从内存、处理器以及磁盘I/O的角度来看能够同时支持两个虚拟服务器吗？一个节点可能在短时间内能够同时处理两台虚拟服务器。但是，一个灾难恢复方案可能需要将被故障转移的实例尽快返回其初始节点上。另一种备选方案就是为每个系统分配足够的CPU和内存资源，然后限制每个实例的资源使用情况。

实施SQL Server 2000故障转移群集

本节将介绍配置故障转移群集时的实施考虑事项。如要了解安装新的Windows 2000服务器群集的安装指南，请参考http：//www.microsoft.com/windows2000/techinfo/planning/server/clustersteps.asp

建议在安装SQL Server 2000后重新启动服务器。这样能够释放被锁定的资源，并完成所有未执行的文件重命名。

您可以使用Windows NT 4.0, Enterprise Edition或Windows 2000 Advanced Server针对开发事项设置一个单节点群集，相关信息请参考知识库文章“Q245626 – 信息：使用‘-localquorum’开关安装一个单节点MSCS群集”：

http：//support.microsoft.com/support/kb/articles/Q245/6/26.asp

　

　

前提条件

在安装SQL Server 2000之前，请确信事件查看器中不存在任何错误，错误可能会影响群集能否顺利安装。确定只有操作系统所必需的服务仍在运行。所有其他的服务都应该停止，它们可能会干扰安装过程。这些服务包括SNMP、World Wide Web Publishing服务以及开发商的特定程序。启动和停止多个服务器的最方便的方法就是创建两个批处理文件：其中一个包含多个net stop命令，另一个包含相应的net start命令。

下表列出了应该保持运行的服务。

Windows NT 4.0 Server, Enterprise Edition

·         Alerter（警报器）

·         Cluster Service（群集服务）

·         Computer Browser（计算机浏览器）

·         Event Log（事件日志）

·         License Logging Service（许可日志服务）

·         Messenger（实时通讯程序）

·         Net Logon（网络登录）

·         Windows NT LM Security Support Provider（Windows NT LM安全性支持提供商）

　

·         Plug And Play（即插即用）

·         Remote Procedure Call (RPC) Locator（远程过程调用（RPC）定位器）

·         Remote Procedure Call (RPC) Service（远程过程调用（RPC）服务）

·         Server（服务器）

·         Spooler （后台打印）

·         TCP/IP NetBIOS Helper （TCP/IP NetBIOS帮助程序）

·         Time Service（报时服务）

·         Workstation（工作站）

　

Windows 2000 Advanced Server和Windows 2000 Datacenter Server

·         Alerter（警报器）

·         Cluster Service（群集服务）

·         Computer Browser（计算机浏览器）

·         Distributed File System（分布式文件系统）

·         Distributed Link Tracking Client（分布式链接跟踪客户端）

·         Distributed Link Tracking Server（分布式链接跟踪服务器）

·         DNS Client（DNS客户端）

·         Event Log（事件日志）

·         License Logging Service（许可日志服务）

·         Logical Disk Manager（逻辑磁盘管理器）

·         Messenger（实时通讯程序）

·         Net Logon（网络登录）

·         Windows NT LM Security Support Provider（Windows NT LM安全性支持提供器）

·         Network Connectors（网络连接器）

·         Plug and Play（即插即用）

·         Process Control（进程控制）

·         Remote Procedure Call (RPC) Locator（远程过程调用（RPC）定位器）

·         Remote Procedure Call (RPC) Service（远程过程调用（RPC）服务）

·         Remote Registry Service（远程注册表服务）

·         Removable Storage（移动存储）

·         Security Accounts Manager（安全性帐户管理器）

·         Server（服务器）

·         Spooler （后台打印）

·         TCP/IP NetBIOS Helper（TCP/IP NetBIOS帮助程序）

·         Windows Management Instrumentation （Windows管理规范）

·         Driver Extensions（驱动器扩展）

·         Windows Time Service（Windows报时服务）

·         Workstation（工作站）

　

安装顺序

这一节将介绍指定操作系统和SQL Server 2000的安装顺序。

Windows NT 4.0 Server, Enterprise Edition

·         安装Windows NT 4.0 Server, Enterprise Edition（不要安装Microsoft Internet Information Server）。

·         创建域用户。

·         安装Windows NT 4.0 Service Pack 3。

·         安装Microsoft Internet Explorer 5。

·         在内部专用网络中禁用NetBIOS。

·         在两个节点上都安装MSCS。

·         手动创建MS DTC群集资源，参考本文稍后的“创建MS DTC资源（仅适用于Windows NT 4.0, Enterprise Edition）”。

·         如果需要可安装Windows NT 4.0 Option Pack，当不要安装MSMQ。

·         安装Windows NT Service Pack 5或更新的版本。

·         暂停所有不需要的服务。

·         安装SQL Server 2000 （参考“附录B” － “安装新的虚拟服务器的循序渐进指南”）。

Windows 2000 Advanced Server和Windows 2000 Datacenter Server

·         安装Windows 2000 Advanced Server（如果您选择Windows 2000 Datacenter Server，那么该操作系统由开发商进行安装）。

·         安装Microsoft Internet Explorer 5 Update（如果需要）。

·         创建域用户。

·         在内部专用网络中禁用NetBIOS。

·         在一个节点上安装Windows群集。

·         将其它节点加入到这个群集中。

·         在所有节点上运行comclust.exe，创建群集MS DTC资源。（更多的相关信息，请参考SQL Server 2000 Books Online的“故障转移群集从属”）。

·         暂停所有不需要的服务。

·         安装SQL Server 2000 （参考附录B － “安装新的虚拟服务器的循序渐进指南”）。

创建MS DTC资源（仅适用于Windows NT 4.0, Enterprise Edition）

本节将说明如何为运行Windows NT 4.0, Enterprise Edition 的服务器配置MS DTC资源，其安装过程比Windows 2000 Advanced Server或Windows 2000 Datacenter Server更为复杂。

配置MS DTC IP地址

1.      在群集管理器中，选择包含仲裁磁盘资源的磁盘组。右击这个磁盘组，然后对其进行重命名。

2.      选择您需要的磁盘组。在“文件”菜单中，单击“新建”，然后单击“资源”。在“新建资源”对话框的“名称”方框中，输入“MDSTC IP地址”；在“资源类型”方框中，选择“IP地址”；在“组”方框中，选择您所要的组。单击 “下一步”。

3.      群集的两个节点都应该是可能的所有者。如果不是，则需添加节点，然后单击“下一步”。

4.      在“从属”对话框中，从“可用资源”方框中选择您选定组中的磁盘资源，然后单击“添加”。此时，磁盘资源将出现在“资源从属”方框中。单击“下一步”。

5.      在“TCP/IP地址参数”对话框中，输入TCP/IP信息。在“地址”方框中，输入静态IP地址（例如：10.1.14.131）；在“子网掩码”方框中，输入IP子网地址（例如：255.255.255.0）；在“所用网络”方框中，选择您所需的群集网络。单击“完成”。

6.      此时将出现一条消息，确认IP地址已经配置成功。

7.      在“群集管理器”窗口中，这个新建的资源将出现在右侧窗格中。要启动这个资源（现在处于脱机状态），右击这个资源，然后单击“联机”。

配置MS DTC网络名称

1.      在群集管理器的“文件”菜单中，指向“新建”，然后单击“资源”。

2.      在“新建资源”对话框的“名称”方框中，输入“MSDTC网络名称”；在“资源类型”方框中，选择“网络名称”；在“组”方框中，选择您所需的组；单击“下一步”。

3.      在“可能的所有者”对话框中，群集的两个节点都应该显示为可能的拥有者。如果不是，则需添加节点，然后单击“下一步”。

4.      在“从属”对话框中，您前面配置的MS DTC IP地址资源应该显示在“可用资源”方框中。选定这个资源，然后单击“添加”。这个资源将在“资源从属”方框中显示。单击“下一步”。

5.      在“网络名称参数”对话框中，输入“MSDTC”，然后单击“完成”。

6.      此时将出现一条消息，确认IP地址已经配置成功。

7.      在“群集管理器”窗口中，这个新建的资源将出现在右侧窗格中。要启动这个资源（现在是脱机的），右击这个资源，然后单击“联机”。

 实施最佳实践

这一节将介绍一些有关实施SQL Server 2000故障转移群集的最佳实践。

配置节点故障转移优先级

当您在故障转移群集中使用两个以上的节点时，需要考虑在故障转移时，哪个节点应该拥有SQL Server进程？这一点十分重要。由于最多能够使用4个节点，因此需要为产品环境设计一个逻辑顺序。这种故障转移群集优先级应该针对包含所有SQL Server 实例资源的组来设置（而不仅仅是虚拟服务器），从而确保所有资源都能够正确的转移到同一个节点。例如，在N+1配置中，每个组在首选所有者列表中都应该有一个闲置节点。这意味着无论哪个节点出现了故障，在这个节点上的资源都能够迁移到闲置节点上。

重要须知：不要使用“群集管理器”将节点从资源定义中删除掉，应该使用“SQL Server设置”实现该功能。有关说明请参考本文后面的“从虚拟服务器定义中添加或删除群集节点”。

为节点配置首选的故障转移顺序

1.      启动“群集管理器”。在包含SQL Server 2000虚拟服务器的组上单击右键，然后单击“属性”。

2.      在“常规”选项卡中，“首选所有者”列表框列出了在这个组中所有可能拥有这些进程的群集节点，以及故障转移的当前顺序。要更改这个顺序，请单击“修改”。

3.      在“修改首选所有者”对话框中，对首选故障转移顺序做任意修改。所有被配置为可能的拥有者的节点都显示在右侧窗格中，并安装故障转移顺序排列。例如，在一个群集中有4个节点：DENNIS、TOMMY、JAMES和CHUCK。所有这四个群集的节点都可以是可能的所有者，其顺序为：如果DENNIS出现故障，则转移到JAMES，然后是TOMMY，最后如果JAMES或TOMMY都不可用则选择CHUCK。

故障转移/故障恢复策略

推荐建立一个整体的群集故障转移/故障恢复策略。故障转移可以通过一个阈值来控制，也就是说未超过这个值时资源将不会执行故障转移。现在有两种级别的阈值：资源和群集。根据资源的配置方式，该策略可以对转移到另一个节点的组产生影响。

在故障转移时，包含SQL Server资源的群集组可以被配置为：如果该节点重新可用，则将资源恢复到主节点上。在默认情况下，这个选项是关闭的。这是因为继续在第二个节点上运行通常不会有任何问题。这个设置提供了一个分析和修复故障节点存在的问题的机会。

为群集组配置自动故障恢复

1.      启动“群集管理器”。在包含SQL Server 2000虚拟服务器的组上单击右键，然后单击“属性”。

2.      在“属性”对话框中，单击“故障恢复”选项卡。

3.      如要阻止自动故障恢复，请选择“阻止执行故障恢复”。要允许自动故障恢复，选择“允许执行故障恢复”，然后选择下列选项之一：

·       立即恢复

这意味着当第二个Windows群集节点侦测到首选群集节点处于联机状态时，马上恢复所有资源。这样做并不十分合理，因为可能干扰客户端和应用程序，特别是在工作日的高峰期。

·       在某个时间段执行故障恢复

这个选项允许将故障恢复到首选节点（如果其处于联机状态）控制在一个特定的时间段内。这里的时间可以是0到23的所有整数。

为资源配置阈值

1.      启动“群集管理器”。选择包含SQL Server 2000虚拟服务器的正确的组，然后右击该资源，并单击“属性”。

2.      在“属性”对话框中，单击“高级”选项卡。

3.      如果群集服务将不尝试重新启动或允许资源处于故障状态，则选择“不重新启动”。默认选定“重新启动”选项。

4.      如果选择了“重新启动”，请配置重启策略：

·         影响组

为了避免在超过指定的重试次数（阈值）之后所选定的资源出现故障而影响到SQL Server组的故障转移，请不要选定“影响组”复选框。

·         阈值是群集服务尝试重新启动资源的次数，周期是两次重试之间的时间长度（单位：秒）。根据您对可用性的要求，设置这两个数值。

例如，如果阈值被设定为0，并选中“影响组”，那么在侦测到故障时，整个组及资源都将故障转移到另一个节点上。

5.      不要修改“Looks Alive（表面正常）”和“Is Alive（正常）”设置。

6.      除非必要，否则不要修改“悬挂超时”。这个值以秒为单位，是处于脱机悬挂（Offline Pending）或联机悬挂（Online Pending）状态的资源确定自身状态所用的时间，然后群集服务将其设置为脱机或失效状态。

7.      单击“应用”，然后单击“确定”。

　

为组配置故障转移阈值

1.      启动“群集管理器”。在包含SQL Server 2000虚拟服务器的组上单击右键，然后单击“属性”。

2.      在“属性”对话框中，单击“故障转移”选项卡。

3.      如要配置故障转移策略，请在阈值方框中输入在设置的时间段内允许组进行故障转移的次数。在“周期”方框中，输入所设置的时间段。

例如，如果“阈值”被设置为10，而“周期”设为6。那么群集服务最多能够在6个小时内将这个组进行10次故障转移。当在这6小时内发生第11次故障转移时，Windows群集将把这个组设置为脱机。这仅对被故障转移的资源起作用；因此如果SQL Server群集出现了11次故障，它将被设置为脱机，而IP仍然保持联机。

SQL Server 2000故障转移群集和MS DTC

在设计采用MS DTC的服务器群集时，有两种不同的方法：

·         使用默认配置。在这种情况下将MS DTC配置为使用仲裁驱动器。这是最流行且最常用的解决方案，我们推荐您采用此方案。

·         预先规划，创建一个独立的群集驱动器供MS DTC使用。虽然如果在群集中使用MS DTC可能降低仲裁驱动器的争用，但是也会导致没有足够多的驱动器提供给SQL Server 实例。同时，也会导致配置群集的步骤变得更多。例如，群集的BizTalk Server配置要求MS DTC被放置在单独的群集组中。更多有关BizTalk Server群集考虑事项的信息，请参考“附录A”所提供的有关BizTalk Server群集白皮书的链接。

无论哪种方法，都需要确保分配给MS DTC的驱动器大约为500MB。这个驱动器不需要几GB的空间。如果MS DTC被放置在仲裁服务器上，请确保仍有足够的空间提供给群集文件。即使目前还不会使用MS DTC，在最初的安装过程中进行配置会更简单一些，而且随时可能用到它。

如果由于某种原因，服务器的群集设计需要为MS DTC设置另一个群集磁盘，请参考知识库文章“Q294209 – INF：重新构建和移动故障转移群集SQL Server所用的MSDTC”：

http：//support.microsoft.com/support/kb/articles/Q294/2/09.asp

其它有关MS DTC和Windows群集的信息可以参考知识库文章“Windows 2000群集服务器的Microsoft分布式事务协调器恢复技术”：

http：//support.microsoft.com/support/kb/articles/Q243/2/04.asp

　

SQL Server 2000的群集组配置

当使用群集管理器设置组时，没有任何最大值和最小值的要求。从概念上来说，将相类似的条目放置在一个组中会很有效，例如：

·         将群集IP地址、群集名称和仲裁磁盘放置在一个组中。

·         在默认情况下，除非需要移动，否则MS DTC应该保持在其默认位置上。

·         将特定实例的SQL Server IP地址、SQL Server网络名称、SQL Server、SQL Server Agent以及SQL Server全文资源放置在各自实例的组中。

MS DTC可以放置在一个具有主群集IP、仲裁磁盘的组中，也可以放置在具有MS DTC配置使用的磁盘的组中。MS DTC是一种共享资源，依赖于其所配置使用的磁盘。但是，我们建议不要将SQL Server或其它任何群集应用程序与仲裁磁盘放置在同一个组中。MS DTC会是一个例外，因为操作系统默认将其放置在这个组中。

SQL Server 2000故障转移群集从属

群集资源可以在实现联机之前，依赖于其它资源进行启动。默认安装具有下列从属（下表并不代表一个组；仅列出了每个资源的默认从属）。

资源

从属

群集IP地址

无

群集名称

群集IP地址

仲裁

无

MS DTC

群集名称、磁盘资源（仲裁磁盘是默认配置）

SQL Server IP地址

无

SQL Server 网络名称

SQL Server IP地址

SQL Server（虚拟服务器本身）

SQL Server 网络名称，与该实例相关联的磁盘资源

SQL Server 代理

SQL Server

SQL Server 全文索引

SQL Server

　

您可以将其他从属添加到这些资源中，但是为了使SQL Server 2000故障转移群集能够正常运行，有一个不能更改的基本配置。请记住，如果没有正确的配置群集从属，任何超出这个基本设置的定制都可能导致计划外的故障转移。

检查资源的从属

1.      启动“群集管理器”，右击资源，然后单击“属性”。

2.      在“属性”对话框中，单击“从属”选项卡，然后单击“修改”。

3.      在“修改从属”对话框中，群集中的可用资源将显示在“可用资源”列表中。选择所要添加的驱动器，单击箭头将资源移动到“从属”列表中，然后单击“确定”。

4.      要检验这个资源现在已经是一个从属对象，请在“属性”对话框中，单击“从属”选项卡。

SQL Server 2000分析服务和故障转移群集

故障转移群集不支持SQL Server 2000分析服务（OLAP和数据挖掘）组件。更多相关信息，请参考知识库文章“Q254321 – 有关群集SQL Server 的警告事项”：

http：//support.microsoft.com/support/kb/articles/q254/3/21.asp

有关如何实现SQL Server 2000分析服务高度可用的信息，请参考白皮书“创建大规模高度可用的OLAP站点”：http：//www.microsoft.com/sql/techinfo/BI/CreatingOLAPsites.asp。

　

SQLMail和故障转移群集

SQL Server 2000虚拟服务器并不完全支持SQL Mail（SQL邮件），因为所采用的基本MAPI协议并不支持群集。更多相关信息，请参考知识库文章“Q263556 – 如何配置SQL Mail”：

http：//support.microsoft.com/support/kb/articles/q263/5/56.asp

从SQL Server群集的早期版本升级到SQL Server 2000故障转移群集

在高度可用的环境中，升级您现有的生产SQL Server可能会影响到可用性。设计一个导致最少停机时间的计划是一项关键任务。虽然在升级过程中保证100％的正常运行时间是不可能的，但是有一些方法可以为您提供更多的正常运行时间。首先，考虑下列这些问题：

·         Windows 2000：您所选择的解决方案是否仍然列在HCL中？如果您不仅限于考虑SQL Server升级，而且考虑操作系统升级，那么这个解决方案可能已经针对Windows NT 4.0进行过测试并获得认证，但可能没有针对Windows 2000进行过测试。

·         如果您使用复制，那么将需要在升级进行前将该功能禁用/解除配置。您需要将复制的配置存档，以及编写成脚本，这样就能够在升级完成后重新进行设置。更多有关复制的升级信息，请参考SQL Server 2000 Books Online中的“备份和恢复复制数据库”、“针对复制编写脚本”和“复制与升级”。

同时，您是否也要升级参与复制的所有服务器呢？虽然这并不是必需的，将所有的工作一起完成总能够更好的最大化您的工作，并将停机时间降到最低。

·         您的意外情况计划是什么？拥有操作系统和SQL Server数据库的可靠备份十分重要。最好购买新硬件并进行全新的配置，这样能够使生产环境的风险和停机时间降到最低。在这种情况下，硬件需要进行配置，应用程序或Web站点仅在升级数据库的时候才会导致停机时间。甚至您可以消除停机时间。例如，使用前一晚的备份，然后将数据的变更应用到服务器上（如果可能的话）。最后一点，您的升级策略必须考虑应用程序的可用性以及与系统用户所达成的正常运行时间协议。

升级操作系统

Windows 2000 Advanced Server和Windows 2000 Datacenter Server提供了一些新增特性用以增强SQL Server 2000，如：AWE内存和更好的可伸缩性（例如，更多的处理器及更多的基本内存）。如果从Windows NT 4.0, Enterprise Edition进行升级，那么您就可以直接升级到Windows 2000 Advanced Server，但是不能直接升级到Windows 2000 Datacenter Server。 请参考“硬件兼容性列表”，检查您当前的群集解决方案和组件是否经过认证适合Windows群集的使用。

从Windows NT 4.0, Enterprise Edition到Windows 2000 Advanced Server的升级被认为是一种“滚动升级”。您不需要解除故障转移群集；只需要在升级服务器之前将所有的服务故障转移到另一个群集节点上。

请按照下方地址所给的步骤进行升级：//www.microsoft.com/windows2000/server/howtobuy/upgrading/path/winnt4ent.asp

这是一个永久性更改，不能卸载。在开发环境中，Windows 2000 Advanced Server可以用于针对最终的Windows 2000 Datacenter Server升级对您的应用程序进行测试。

更多其他信息，请参考以下资源：

·         一般性升级信息：http：//www.microsoft.com/windows2000/server/howtobuy/upgrading/default.asp

·         有关滚动升级的详细信息，请参考：http：//windows.microsoft.com/windows2000/en/advanced/help/

·         知识库文章“Q249735 – 将服务器群集节点升级到Windows 2000时的错误信息”：http：//support.microsoft.com/support/kb/articles/q249/7/35.asp

·         有关Active Directory™（Windows 2000中包含该目录服务）和群集的信息，请参考知识库文章“Q235529 – Windows 2000域中MSCS虚拟服务器的限制”：http：//support.microsoft.com/support/kb/articles/q235/5/29.asp

从SQL Server 6.5进行升级

SQL Server 6.5群集和SQL Server 2000计算机无法在同样的硬件上进行配置。与操作系统不同，您无法对SQL Server进行滚动升级。在升级时您必然会导致停机时间。在版本升级后，我们建议将所有访问SQL Server 2000的客户端计算机都升级到Microsoft数据访问组件（MDAC）2.6版，这是一个安装在服务器上的版本。

要从SQL Server 6.5进行升级，请考虑下列策略：

·         在同样的硬件上升级

如果您希望使用同样的硬件，并确定针对您所使用的操作系统所用的硬件仍然列在HCL中，那么请参考SQL Server 2000 Books Online，其中给出了两种升级说明：活动/被动升级和活动/活动升级。需要解除SQL Server 6.5群集，安装SQL Server 2000的本地实例，使用升级向导将数据从SQL Server 6.5进行升级，然后将本地实例升级到群集实例。在这个升级过程中，请确保您为数据使用了正确的群集磁盘。确保您具有完整的数据库服务器配置列表（例如，如何构建数据库分段，在何处放置文件等），这样在需要时您可以重新构建这个服务器——不需要重新安装操作系统和SQL Server 6.5。

·         使用新的Windows 2000 Advanced Server或者Windows 2000 Datacenter Server配置进行启动。安装SQL Server 6.5（更多信息，请参考知识库文章“Q192710 –安装SQL Server Version 6.5 或 7.0的基本指南：http：//support.microsoft.com/support/kb/articles/q192/7/10.asp），在新的服务器上恢复您的6.5数据库，然后按照上一点所述的步骤操作。但与上一点不同的是，这是一种更好的意外情况计划，能够应付升级过程中发生的事件，因为您的旧硬件仍然处于配置状态，随时可以使用。

·         使用新的Windows 2000 Advanced Server或者Windows 2000 Datacenter Server配置进行启动，安装SQL Server 2000的群集实例。创建一个空的数据库，使用数据转移服务（DTS）或其它方法（如：BULK INSERT（整体插入）或整体复制（BCP））将数据从SQL Server 6.5导入到这个新的数据库中。与前一点相同，这是一种可靠的意外情况计划，能够应付无法将数据导入到SQL Server 2000中的情况。这可能还可使停机时间降到最低，因为当旧服务器仍在使用时大部分的升级工作已经完成了。您应该对这种方法进行测试，确定其是否会降低性能或可用性。

·         考虑将SQL Server 6.5数据库升级到SQL Server 7.0，作为一个过渡步骤，然后根据下面将介绍的升级SQL Server 7.0配置的方法进行操作。

从SQL Server 7.0进行升级

同SQL Server 6.5一样，SQL Server 7.0群集和SQL Server 2000故障转移群集无法配置在相同的硬件上，SQL Server无法进行滚动升级——这将会导致停机时间。在版本升级后，我们建议将所有访问SQL Server 2000的客户端计算机都升级到Microsoft数据访问组件（MDAC）2.6版，后者是一个安装在服务器上的版本。

要从SQL Server 7.0进行升级，请考虑下列策略：

·         使用日志递送。这种方法假定SQL Server 2000故障转移群集位于新的硬件上。您可以手动配置日志递送，从配置了至少SQL Server 7.0 Service Pack 2的SQL Server 7.0升级到SQL Server Enterprise Edition。更多信息，请参考有关服务器包的文档。这里有几点需要指出：

·         在SQL Server 7.0中，必须使用sp_dboption将 “未决升级”（pending upgrade）选项设置为true。但是，这样用户将无法在数据库中创建索引或统计，而且也会产生错误。这也是为什么实现从SQL Server 7.0到SQL Server 2000的日志递送必须在一定时间内完成。

·         在恢复正确的时间点数据库整体备份以应用后续事务日志备份时，请使用NORECOVERY 恢复SQL Server 2000中的数据库。

·         没有任何图形方式可用以监控这种日志递送，而当在两个SQL Server 2000 Enterprise Edition服务器之间实现日志递送时就可以使用图形方式进行监控。您必须直接查询日志递送表。

针对这些考虑事项，我们建议您不要在SQL Server 7.0和SQL Server 2000之间使用日志递送，因为这会在产品环境中耗费更多的时间。

日志递送能够提供最长的正常工作时间。在升级SQL Server 2000虚拟服务器时，使其成为新的生产数据库的同时，仍将允许当前的生产数据库正常运行并处理请求。同时，这也提供了一个意外事件计划，因为您不会影响到当前的生产硬件。

如要使新的SQL Server 2000数据库实现联机，请执行下面的步骤：

·         在给定的时间点，减少对当前生产数据库的访问。

·         一旦所有的连接都停止时，请确保所有的事务日志都应用于这个SQL Server 2000数据库。

·         使用Transact SQL的RESTORE（恢复）命令的WITH RECOVERY选项实现数据库的联机。这个操作可以在完成最新的事务日志后在数据库上完成。或者将直接将其放在最后一个事务日志恢复声明的末尾。

·         将所有客户端重新定向到新的数据库和服务器。

·         进行测试，确保一切都正常运作，打开数据库用于常规使用。

·         在相同的硬件上升级

这个过程比SQL Server 6.5的类似升级更直接一些。但是您仍然必须检查针对您所用的操作系统，以确定这个硬件解决方案是否仍然列在HCL中。有关升级活动/被动或活动/活动配置的指南可以参考SQL Server 2000 Books Online中的“升级到SQL Server 2000故障转移群集”。如果您的共享群集磁盘没有为数据配置正确的逻辑驱动器，您可能会遇到一些问题。

如果您选择了这个方法，有一点需要特别提醒：与SQL Server 2000一起安装的MDAC 2.6与SQL Server 7.0群集无法兼容。因此您必须返回到SQL Server 7.0和MDAC 2.5，在测试环境中对这个进程进行测试，您只有一次机会可以在生产环境中进行重新绑定。更多信息，请参考知识库文章“Q239473 PRB：用于在群集SQL Server 7.0服务器上进行Windows 2000和MDAC升级的70rebind.exe”：http：//support.microsoft.com/support/kb/articles/q239/4/73.asp

·         使用新的Windows 2000 Advanced Server或者Windows 2000 Datacenter Server配置进行启动，安装一个SQL Server 2000的群集实例。在SQL Server 2000上备份和恢复SQL Server 7.0数据库，或使用复制数据库向导。这也能使SQL Server 7.0数据库保持完整，实现一个可靠的意外事件计划。

·         使用新的Windows 2000 Advanced Server或者Windows 2000 Datacenter Server配置进行启动，安装一个SQL Server 2000的群集实例。创建一个空的数据库，使用数据转移服务（DTS）或其它方法（如：BULK INSERT（整体插入）或整体复制（BCP））将数据从SQL Server 7.0导入到这个新的数据库中。由于旧的服务器仍处于配置状态，因此它也是一种可靠的意外情况计划，能够应付无法将数据导入到SQL Server 2000中的情况。这种方法也能够解决任何文件或文件组位置更改的问题。

　

升级顺序

在您理解并评估了有关升级早期版本SQL Server群集的考虑事项以后，遇到的下一个问题是按照什么样的顺序实现这一升级？如果您同时在同样的硬件上执行操作系统和SQL Server的升级，那么请先进行操作系统升级。因为您可以进行滚动升级，仍然能对数据库的请求提供服务。在从Windows NT 4.0升级到Windows 2000的过程中，请确保注意每个细节，例如：在每个节点上运行comclust.exe以确保对MS DTC进行群集。即使您使用同样的硬件并保持当前的操作系统，在升级SQL Server之前，您也应该确保其能够满足SQL Server 2000的要求（如：服务包版本）。升级到SQL Server 2000应该是最后一步骤，包括恢复所有的自定义配置（如：复制）。

重要须知：在升级产品数据库之前，请在测试/临时环境中测试这个进程。在产品环境中进行升级之前，您应该确信已经了解所有可能遇到的问题。因为在一个高度可用的环境中，停机时间是至关重要的——每一分钟都很重要。您需要了解的最重要的事情是这个升级过程将占用多长时间。即使您无法在群集的机器上进行测试，您也应该在单机上对升级进行测试，这总比完全不测试要好。

　

将独立的（本地）SQL Server 2000实例升级到SQL Server 2000虚拟服务器

从本地实例升级到群集实例是可以实现的。但是，需要注意两点：

·         如果您的硬件没有被配置为群集，您不要将它转换成群集。正如本文前面所提到的（参考“硬件兼容性列表”一节），这个解决方案必须作为群集进行购买。

·         如果您的数据没有在正确的群集磁盘上，或者驱动器阵列没有被正确配置，那么您将会遇到与SQL Server 6.5和7.0升级一样的问题。在安装前，您必须确保数据处于正确的驱动器上，或者能够通过某种方法将其移动，例如：附加和分离。

如果这些考虑事项都不成问题，请确保已经配置了Windows计算机，然后将这个实例升级到群集实例。需要了解如何升级的示例，请参考SQL Server Books Online中的“如何从默认实例升级到SQL Server 2000 (Setup)的默认群集实例”。

　

检验故障转移群集的安装

本节提供了一些方法，可以用来检验您的故障转移群集是否得到了正确的配置。请在将故障转移群集投入使用前，执行这些测试。我们建议您在确保客户端连接时，避免由于测试而干扰可用性。有关信息及可以利用的核对清单请参考本文最后的附录D：“安装前后的核对清单”。

检验连接性和名称解析

要检验专用和公共网络是否正常通讯，请执行下列步骤。了解群集中每个网络适配器的IP地址是强制性的，同时也需要了解所有IP群集资源的IP地址（您可以在本文附录C的工作表中输入这些信息）。

从服务器节点检验连接性和名称解析

这种方式介绍了如何测试服务器层次上的IP连接性和名称解析。

1.      在一个节点的“开始”菜单中，单击“运行”，然后在文本框中输入cmd。单击“确定”。

2.      输入ping ipaddress/servername，其中ipaddress/servername是其它节点对应的网络适配器的IP地址或您群集的虚拟服务器名称。

3.      在每个节点上重复上述操作。

例如，假定IP地址的设置如下表所示。

节点

检测项目

值

1

公用群集连接

199.1.3.16

1

专用群集连接

10.1.1.1

2

公共群集连接

193.1.2.199

2

专用群集连接

10.1.1.2

无

群集IP地址

199.2.6.4

无

SQL Server IP地址

199.10.3.6

无

群集名称

MyCluster

　

在这个例子中，您可以在节点1上输入ping 193.1.2.199和ping 10.1.1.2，在节点2上输入ping 199.1.3.16和 ping 10.1.1.1。这两个节点都应该能够测试“群集IP地址”、“群集名称”以及“SQL Server IP地址”。

从客户端节点检验连接性和名称解析

此方式介绍了如何测试客户端上的IP连通性和名称解析。

1.      在客户端计算机上的“开始”菜单中，单击“运行”，然后在文本框中输入cmd。单击“确定”。

2.      输入ping ipaddress/servername，其中ipaddress/servername是其他节点所对应的网络适配器的IP地址或您群集的虚拟服务器名称。

在这个例子中，如果您仍按照上表的配置，则可以输入ping 193.2.6.4和ping MyCluster来检测到群集的连通性。要检测SQL Server的IP地址，则输入ping 199.10.3.6。要检测使用指定连接或IP到SQL Server的连接，请设置一个ODBC连接或使用客户端网络工具。

故障转移确认

最后，执行一次所有SQL Server虚拟服务器的故障转移，确保所有的资源都成功的实现故障转移并在另一个节点上重新启动，并不影响到其他组的正常工作。有一种例外，那就是如果SQL Server使用仲裁驱动器的情况，而不是以前的推荐配置。这个测试是通过群集管理器完成的。

1.      在“开始”菜单中，执行“程序”和“管理工具”，然后单击“群集管理器”。

所有为故障转移群集配置的节点都应该出现在群集管理器左侧窗格的下方。

2.      在包含SQL Server资源的组（如：SQL Server Ins1）上单击右键，然后单击“移动”。这个选定的组及其资源将移动到首选的故障转移节点上。这一更改将反映在群集管理器中。

检验服务帐户

为了使SQL Server能够正确的管理和执行它的资源，服务帐户必须是群集ACL的一部分。要确保服务帐户被正确的配置，请在SQL 查询分析器窗口中执行下面的命令：

select * from ：：fn_virtualservernodes()

　

如果不存在任何输出活动，则说明SQL Server所运行的帐户属于群集ACL的一部分。

维护SQL Server 2000故障转移群集

维护故障转移群集是一项极具挑战性的工作。例如，如何创建一个无缝的环境，无论哪个节点拥有SQL Server进程都能正常工作？这一节将介绍一些在维护群集环境时所需要注意的事项。

管理SQL Server虚拟服务器

有4种方法您可以用来管理您的SQL Server虚拟服务器。了解这些工具间的相似点及不同点很重要，这样您才能选择最合适的工具。

·         SQL Server工具，特别是SQL Server Enterprise Manager

SQL Server Enterprise Manager和其它SQL Server工具应该用于管理数据库。所有与SQL Server及SQL Server Agent相关的帐户和密码都应该在Enterprise Manager中进行修改。如果需要更改端口号，请使用服务器网络工具。与针对非群集实例一样，使用其它SQL Server工具。

·         SQL Server安装程序

要卸载虚拟服务器，添加或删除参与故障转移群集的节点，或者更改或添加故障转移群集的IP地址，请使用SQL Server安装程序。

·         群集管理器

这是一个操作系统级工具，位于管理工具中。在SQL Server 2000之前，大部分针对SQL Server群集的配置更改是在群集管理器中完成的。请仅在本文特别指出的地方使用群集管理器，确保正确的使用SQL Server 2000故障转移群集。不要使用群集管理器，将节点添加到资源定义中，或用来更改IP地址。

·         命令行CLUSTER实用程序

CLUSTER命令行工具基本上是群集管理器中大部分功能的操作系统命令行界面。与群集管理器一样，仅在必要的时候才使用这个工具。

　

Windows 2000 Datacenter流程控制和SQL Server 2000故障转移群集

重要须知： 不要使用进程控制修改SQL Server虚拟服务器配置。进程控制不是一个支持群集的的应用程序。在进行故障转移时，在一个节点上修改的虚拟服务器将无法从故障节点自动地继承进程控制的限制。请使用SQL Server Enterprise Manager和其他SQL Server提供的工具来修改SQL Server虚拟服务器配置。

更多相关信息，请参考知识库文章“Q296382 – Windows Datacenter Server进程控制服务不支持群集”：

http：//support.microsoft.com/support/kb/articles/Q296/3/82.asp

　

备份和恢复

虽然在群集环境中对数据库的备份与常规服务器中的备份并不完全不同，但它无疑要复杂的多。那您应该如何处理这样的情况呢？当配置了一个群集，它通常被应用于大型关键任务数据库。在千吉字节的范围内备份和恢复数据库不能像您处理10 MB数据库那样，虽然很多人试图同等处之。这里给出了几个常用的最佳实践：

·         进行频繁的备份。

·         将备份文件脱机存储，例如保存在磁带或其它介质上。

·         对所有备份进行测试，并了解备份恢复所需的时间。这样当出现紧急情况时，您不仅知道这个备份完好无损，而且知道它需要多久时间来恢复。在出现某些服务器故障时，了解这些信息至关重要。

重要须知： 不要使用仲裁驱动器存储备份。

备份到磁盘和磁带上

在一般情况下，首先备份到磁盘上是最容易的。创建一个群集磁盘共享，这样当进行故障转移时，所有的节点都能够访问这个备份共享。不要试图备份到任何本地驱动器上。在将数据库备份后，应该将其复制到另一个位置，备份到其它介质（如：磁带）上，然后在经过测试和检验后存放在一个单独的位置。高可靠性环境中的备份是为了消除单点故障。因此如果您进行了备份并只是将它保存在驱动器的某个位置上，既便使用了RAID，当遇到阵列故障时您该怎么办呢？虽然这种情况发生的可能性很小，但是我们必须考虑最糟糕的情况。

另一个种方法是在备份工作中执行两步操作。设置两个备份方式（例如，磁带驱动器以及共享群集磁盘）。设置您的维护计划，然后改变备份任务。如果备份在步骤一上成功完成了，则退出；但是如果备份失败了（出于某种原因），则启用第二种方法。这将能够确保在您的备份策略中不存在单点故障。

快照备份

备份和恢复群集SQL Server方法之一就是采用快照备份。SQL Server 2000支持这种备份方式。首先对您的磁盘进行镜像，然后中断整组磁盘镜像，并将它们作为备份。快照备份需要专门的硬件；SQL Server 2000支持这种备份。

示例

TerraServer（http：//www.terraserver.com/default.asp）是一个提供地理位置的航拍照片和地图的Web站点，其中的内容由美国地质调查局提供。现在他们的数据库拥有接近2兆兆字节的数据，采用Windows 2000 Datacenter Server和N＋1方案的SQL Server 2000故障转移群集。您可以想像，这种超大规模数据库（VLDB）的备份必须精心规划。

TerraServer选择了快照备份。除了RAID以外，他们还拥有3个磁盘镜像（就像3个整齐依次排列的磁卷）。也就是说，硬件拥有三个同步的数据副本。但在某个时刻，其中一个镜像组被中断了，最终变为数据库的备份。在镜像中断的时候，它不再保持同步，而且SQL Server也无法再看到它。SQL Server 2000拥有足够的智能，能够对这种情况作出反应，并合理的处理其内存缓冲。然后他们使用磁带解决方案来备份这个磁卷。在某个时刻，再把这个磁盘组放回去，这样您就又拥有三个镜像了。然后不断重复这个过程。

备份整个群集系统

仅仅备份您的SQL Server 2000数据库是不够的。您必须同时备份整个系统。另外将Windows群集的系统状态进行备份也十分重要。当需要进行恢复时，请在计算机上安装了操作系统后恢复系统状态。这种备份需要一个支持群集的备份程序。一些第三方开发商提供这种服务。

请考虑下面几种本机工具：

·         ntbackup.exe：这个工具可对群集配置进行备份和恢复，其中包括仲裁磁盘和系统状态。这个工具不适用于远程服务器。如果服务器正在运行群集服务，那么系统状态数据也应该包括所有资源注册表检查点和仲裁资源恢复日志。在这个日志中包括最新的群集数据库信息。

·         clusrest.exe：这个工具将备份的仲裁日志内容恢复到活动的仲裁磁盘上。

·         clustool.exe：这个工具可对群集配置的某些部分进行备份和恢复。它还包括一个用于将单机文件和打印共享转移到群集上的工具，但无法恢复一些核心资源，如：群集IP地址、群集名称以及仲裁磁盘等。您可以从Windows 2000 Server Resource Kit (/apps/clustool/)中获得这个工具。该工具取代了clusconb.exe。

·         dumpcfg.exe：这个工具可对磁盘签名进行备份和恢复，属于Windows 2000 Server Resource Kit的一部分。

·         群集自动化服务器：这是一系列用于协助群集服务的ActiveX®控件，属于Windows 2000（msclus.dll）的一部分 。如果使用Windows NT 4.0，那么您可以从Windows 2000 SDK安装光盘（Redist/Cluster/NT4/i386）上获得这个工具。

前面提到的有关备份到磁盘和磁带的考虑事项仍然应该采纳：确保无单点故障，所有的节点能够以同样的方法访问同一个设备。

确保虚拟服务器不会因为其它服务发生故障而失效

为了避免某些服务的故障导致SQL Server组进行故障转移，请使用群集管理器对这些服务进行正确的配置。请参考本文前面的“为资源配置阈值”一节中的步骤4。例如，如果您的解决方案中没有使用SQL Server全文索引功能，您应该确保在这个资源的属性中没有选中“影响组”参数。

添加、修改或更新TCP/IP地址

在SQL Server 2000之前，如果实现了SQL Server群集，对TCP/IP地址的修改需要解除SQL Server群集。而要在SQL Server 2000中修改TCP/IP地址，请再次运行安装程序。另外，由于SQL Server 2000中新增了对多网卡/IP地址的支持，因此可以为实例配置更多的TCP/IP地址。但是，您必须限制每个子网只能有一个IP地址。例如，如果您同时拥有访问这个实例的内部和外部用户，那么您可以为SQL Server分配两个不同的IP地址，以实现网络应用的最大化，并简化对SQL Server 实例使用情况的跟踪。

要添加、修改或更新TCP/IP地址

1.      在CD－ROM驱动器内插入SQL Server 2000 Enterprise Edition安装光盘，选择“安装SQL Server 2000组件”。

2.      单击“安装SQL Server 2000组件”，单击“安装数据库服务器”，然后单击“下一步”。

3.      在“计算机名称”对话框中，选择“虚拟服务器”，输入现有SQL Server 2000群集实例的名称

4.      在“安装选择”对话框中，选择“高级选项”，然后单击“下一步”。

5.      在“高级选项”对话框中，选择“为故障转移群集维护虚拟服务器”，然后单击“下一步”。

6.      在故障转移群集对话框中，可以从选定的SQL Server 2000 实例上添加或删除TCP/IP地址。

要删除一个TCP/IP地址，请选中这个地址，然后单击“删除”。

注意 故障转移群集中的SQL Server 2000 实例需要一个TCP/IP地址才能正常工作。只有当存在一个以上的TCP/IP地址时才执行删除，而且要确保其不会影响到用户或应用程序访问SQL Server。

要添加TCP/IP地址，请在“IP地址”方框中输入新的TCP/IP地址，选择所用的网络，然后单击“添加”。这个新加的IP地址将出现在已有IP地址的后面。

7.      在“群集管理”对话框中，单击“下一步”。

8.      在“远程信息”对话框中，输入用于SQL Server 2000群集实例的域管理员帐户的用户名和密码，然后单击“下一步”。

9.      在结束这个过程后，单击“完成”。

从虚拟服务器定义添加或删除群集节点

SQL Server 2000故障转移群集的另一个新特性就是能够从SQL Server虚拟服务器定义添加或删除群集节点。将节点添加到现有SQL Server虚拟服务器定义中需要在新节点上执行所有必要的操作（包括安装新的二进制、系统组件以及创建服务），并需要对群集配置进行必要的修改。

要添加或删除一个节点

1.      在CD－ROM驱动器内插入SQL Server 2000 Enterprise Edition安装光盘，选择“安装SQL Server 2000组件”。

2.      单击“安装SQL Server 2000组件”，单击“安装数据库服务器”，然后单击“下一步”。

3.      在“计算机名称”对话框中，选择“虚拟服务器”，输入现有SQL Server 2000群集实例的名称。

4.      在“安装选择”对话框中，选择“高级选项”，然后单击“下一步”。

5.      在“高级选项”对话框中，选择“为故障转移群集维护虚拟服务器”，然后单击“下一步”。

6.      在“故障转移群集”对话框中，单击“下一步”。

7.      在群集管理对话框中，选择需要添加或从群集中删除的合适节点，然后在您完成后单击下一步。

8.      在“远程信息”对话框中，输入用于SQL Server 2000群集实例的域管理员帐户的用户名和密码，然后单击“下一步”。

9.      在结束这个过程后，单击“完成”。

重新命名SQL Server 2000虚拟服务器

对SQL Server 2000虚拟服务器进行重命名既不可能，又不受支持。删除虚拟服务器的唯一方法是将其卸载。

应用SQL Server 2000服务包

正如前面所提到的，SQL Server 2000不再要求您在应用服务包时将解除SQL Server群集。我们建议您在安装服务包之前阅读其说明文件，其中可能包含了有关这个服务包的特殊信息。例如，SQL Server 2000 Service Pack 1需要在安装后重新启动，这将影响到可用性。另外，在虚拟服务器上安装服务包之前，请考虑下列一些问题：

·         使用服务包对虚拟服务器进行升级与升级一个单独的SQL Server一样。您必须在Windows群集的所有虚拟服务器上重复这个服务包的安装过程。安装程序将升级虚拟服务器定义中所有节点的基本组件。

·         所选定的虚拟服务器的故障转移群集资源必须处于联机状态，并运行成功的服务包安装。

·         在升级过程中，所选定的虚拟服务器将无法响应客户端请求。另外服务包也可能需要重新启动故障转移群集节点。请对这种可用性的中断进行规划，使您的最终用户提前了解，这样他们才能够根据您的计划指定他们的计划。

·         阅读说明文件，了解在服务包中升级了哪些组件。但是，如果MS DTC是升级组件之一，而群集中有一个以上的虚拟服务器使用MS DTC，那么其他的虚拟服务器可能会在所选虚拟服务器升级过程中受到影响。这是因为MS DTC是群集中的一个共享资源。

·         在安装服务包之前，请备份所有系统和用户数据库，并确认系统数据库拥有足够的空闲空间。

·         要恢复到服务包安装前的SQL Server版本，您需要卸载虚拟服务器，重新安装SQL Server 2000，然后通过附加或恢复重新创建您的用户数据库。

SQL Server 2000故障转移群集的故障诊断

对SQL Server 2000中的故障转移群集配置进行故障诊断与独立服务器并不一样。首先，您需要检验硬件、操作系统和Windows群集是否都工作正常。然后，如果所有的这些都处于良好状态，则检查SQL Server。更多相关信息，请参考SQL Server Books Online中的“故障转移群集故障诊断”。

服务级别协议

请确认您与硬件和软件开发商之间的服务级别协议（SLA）满足您所需要的支持级别。由于故障转移群集通常是一个关键任务的生产系统，因此购买一个保证48小时实现还原的SLA可能并不那么有效。根据停机时间长短的不同，支持合同的价格也会有所不同。在生产环境中，您必须在进行故障诊断之前首先呼叫支持。因为故障诊断可能会增加停机时间，例如在服务器停机的状态下。

第一步

检查操作系统事件查看器中的应用程序、系统和安全性日志。有时问题是很明显的，例如磁盘或网卡故障，或者操作系统或SQL Server可能会给出相关的错误信息。然后，检查群集日志，这些日志在系统变量%clusterlog%设置的地方（通常是//winnt/cluster）。其中包含这些文件：

·         Sqlstpn.log. SQL Server安装的日志，其中n是安装尝试的次数。

·         Sqlclstr.log. SQL Server群集实例的日志。

·         Cluster.log. 群集日志主文件。

　

有关启用和禁用日志的完整说明，请参考知识库文章Q168801“如何在Microsoft群集服务器商启用群集日志：http：//support.microsoft.com/support/kb/articles/q168/8/01.asp。

这些信息对于呼叫您的硬件开发商或Microsoft产品支持服务也是很有价值的。您提供的信息越多，他们将能够更快的帮助您解决问题。

修复单节点故障和仲裁磁盘故障

如果群集中的一个节点出现了故障（由于硬件问题）或仲裁磁盘出现了故障，请按照下面的步骤重新构建这个节点，然后将其加入到群集中：

1.      首先确定所有群集资源组已经成功的移动到群集的另一个节点中，然后使用SQL Server安装程序将这个节点从SQL Server虚拟服务器定义中删除（参考本文前面的“从虚拟服务器定义中添加或删除群集节点”）。安装程序应该能够检测到这个被删除的节点，然后自动的将其移动到“不可用的节点”列表中。

2.      使用群集管理器驱逐这个服务器节点。

3.      修复这个群集节点。这个过程可能需要构建一个新的群集节点或从当前的备份进行恢复。

4.      重新加入到群集中。

5.      如果使用MS DTC，则在这个节点上运行comclust.exe。

6.      重新在没有问题的节点上运行SQL Server 2000安装程序。从“可用节点”列表中选择被驱逐的节点， 将它添加到“已配置的节点”列表中。

注意 如果在将节点从SQL Server虚拟服务器定义中删除之前就试图将节点从群集定义中驱逐出去，这样会导致一些问题。如果一个节点被驱逐了，它将无法显示在SQL Server安装程序中，因此，也就无法正常的从虚拟服务器定义中删除了。如果在被驱逐的节点上仍保留这SQL Server资源DLL，那么在它重新加入到群集中后，群集可能无法正确的将其添加为SQL Server资源的可能所有者。这种情况发生的可能性很小，但是您仍应该加以注意。另外，如果您试图没有首先将其从Windows群集定义种删除之前就添加回这个节点，SQL Server 2000故障转移群集可能会被中断。

多节点故障

如果多个节点出现故障，但并不是所有节点，那么请重复前面的步骤修复所有的节点。但是，如果所有的节点都故障故障，而且仲裁磁盘无法修复，那么您不得不重新构建群集种的所有节点。这也是为什么进行测试及频繁的备份是至关重要的原因。

重新构建群集环境中的master数据库

如果在SQL Server 2000故障转移群集中需要重新构建master数据库，请按照下列步骤进行操作：

1.      进入当前拥有这个SQL Server资源的节点。

2.      使用“群集管理器”驱逐SQL Server虚拟服务器。

3.      确保拥有原始的共享安装文件或SQL Server 安装光盘。

4.      如果您使用SQL Server 安装光盘，将所有文件从光盘中复制到本地硬盘上。在复制到硬盘之后，解除所有文件的只读属性。

5.      执行rebuildm.exe。将其指向原始的共享安装文件或从CD上复制到本地硬盘上的文件。

6.      选择Windows或SQL校对。

7.      在rebuildm.exe完成中，确认资源可以被设置为联机状态，而且它们成功地进行了故障转移。

8.      执行sp_helpsort检验校对过程。

这些步骤并不包括处理用户数据库所需的步骤。在这种情况下，SQL Server 2000是新安装的，仅包括随SQL Server装载的数据库。如果您拥有master数据库的当前备份，那么您可能可以在现在将其恢复。如果您没有备份，那么将不得不恢复或附加用户数据库。

常见的故障诊断问题

在本节中将介绍一些实现故障转移群集时的常见问题和解决方案。

问： 当安装程序试图在其他节点上安装SQL Server二进制时，结果失败了（可能伴随着一个登录请求失败的错误信息）。这是为什么？

答： 如果您从网络共享进行安装，请确认所有节点都能够访问该共享，而且不需要指定网络密码就能连接（例如，您应该不需要指定证书就能够查看）。如果您从节点A的CD-ROM驱动器上进行安装，请确认群集节点被配置为能够进行正常的通讯，每个节点上都有正确的帐户，而其他节点都被设定进行Windows身份验证。映射一个驱动器盘符也不起作用，即使所有节点上都使用同一个盘符，这是因为安装过程需要访问共享的UNC路径。

问： 在安装并重新启动服务器后，SQL Server安装似乎仍然没有完成。为什么？

答：有时由于锁定启动程序（如：MDAC）会导致阻止文件重命名；因此，如果文件仍然是只读的，那么安装过程将无法完成。

问： MSCS无法连接到我的SQL Server虚拟服务器。为什么？

答： 这可能是因为用来执行IsAlive检查的进程在MSCS服务帐户环境中运行。这个帐户必须具有SQL Server的sysadmin权限。如果不是这种情况，请使用群集日志检查所有的登录并前后对照，检查是否存在IsAlive检查。

问：在安装后更改SQL Server的网络名称时出现了问题。请问如何解决？

答： SQL Server将自身与安装时使用的网络名称绑定在一起。如果出于某种原因需要进行修改，在目前的情况下需要进行完整的重新安装。

问：在安装了新的SQL Server虚拟服务器后，客户端无法连接到这个服务器，特别当使用图形用户界面（GUI）工具时。为什么？

答： 需要刷新DNS和WINS服务器才能够识别新的SQL Server 2000虚拟服务器安装，这需要一些时间。在一些情况下，需要在DNS和WINS配置文件中手动插入相关条目。

问： 在“我的群集”中同时安装了Microsoft Exchange 2000和SQL Server 2000；但是似乎无法运行SQL Server的全文服务。为什么？

答：如果两者必须共存于同一个群集中（虽然我们不推荐这样做），请首先安装Exchange 2000，然后再安装SQL Server 2000。

问：在故障转移群集的完整安装中，我遇到了一些问题。什么地方可能出错呢？

答：在一些情况下，安装过程可能会由于不存在基本的Microsoft 搜索服务而失败。如果是这种情况，您可能需要创建这个类型，在下次完成安装。要创建这个资源，请在命令提示符中执行下列命令：

cd %windir%/cluster

regsvr32 gathercl.dll

请确认在所有节点上都注册了这个文件。您可以重新运行安装程序，一切都应该能正常工作了。

总结

SQL Server 2000故障转移群集是一种能够为您的数据库提供高可用性的主要方法，提供了完全的事务一致性，并且能自动地故障转移到其他节点。通过消除单点故障（软件级别和硬件级别）以及指定正确的过程和灾难恢复计划，您可以获得高达99.999%的可用性。

附录A – 其它信息

有关故障转移群集的更多信息，请参考以下资源：

·         Microsoft SQL Server主页：http：//www.microsoft.com/sql/

·         Microsoft SQL Server 2000操作指南：http：//www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/maintain/operate/opsguide/default.asp

·         更多有关Windows群集的体系结构、技术和术语的信息，请参考“Windows群集技术：群集服务体系结构”： http：//www.microsoft.com/windows2000/techinfo/howitworks/cluster/clusterarch.asp

·         更多有关故障转移群集和SQL Server 2000的常规信息，请参考SQL Server 2000 Books Online。

·         更多有关Windows NT 4.0, Enterprise Edition Server中群集的信息，请参考 http：//www.microsoft.com/ntserver/ProductInfo/Enterprise/default.asp；有关 Windows 2000 Advanced Server和Datacenter Server中群集的信息，请参考  http：//www.microsoft.com/windows2000/technologies/clustering/default.asp

·         有关Windows NT Server 4.0高可用性操作指南的信息，请参考 http：//www.microsoft.com/ntserver/techresources/deployment/NTserver/highavail1.asp。

·         更多有关BizTalk和群集的信息，请参考白皮书“部署BizTalk服务器：群集考虑事项”：

http：//www.microsoft.com/biztalk/techinfo/deployment/wp_clusteringconsiderations.asp

·         MSDN® 开发人员计划：http：//msdn.microsoft.com/

·         更多有关SQL Server 2000容量规划的信息，请参考Microsoft SQL Server 2000 管理员指南：http：//www.microsoft.com/mspress/books/4519.asp

·         Microsoft 支持服务Web站点（包括技术文章和可下载的更新程序）：http：//support.microsoft.com

　

附录B – 安装新的虚拟服务器的循序渐进指南

这一节将介绍如何安装一个新的SQL Server 2000虚拟服务器。

1.      根据模块的定义，关闭所有不必要的可能干扰安装过程的服务。如果需要，您可以创建两个能够启动和停止这些服务器的批处理脚本。

2.      在CD-ROM驱动器中插入SQL Server 2000 Enterprise Edition安装光盘。

3.      当光盘菜单出现时，单击“SQL Server 2000组件”，然后单击“安装数据库服务器”。

4.      在“欢迎”对话框中，单击“下一步”。

5.      在“计算机名称”对话框中，单击虚拟服务器，键入您群集虚拟机器的网络名称，然后单击“下一步”。

6.      在“用户信息”对话框的“姓名”方框中，键入您的姓名；在“公司”方框中，输入您的公司名称。单击“下一步”。

7.      在“软件许可协议”对话框中，查阅“最终用户许可协议”，然后单击“是”。

　

8.      输入用于该虚拟服务器的“IP地址”，从“所用的网络”下拉列表中选择群集网络。完成后，单击“添加”。您的条目将在本窗口底部的窗口内显示。您可以一次添加多个IP地址。单击“下一步”，继续安装。

9.      在“群集磁盘选择”对话框中，选择放置数据文件的磁盘。添加额外的驱动器必须在安装前就完成，这在本白皮书中的“在群集配置中添加逻辑磁盘”一节已有介绍。单击“下一步”，继续安装。

　

　

如果您使用“-localquorum”开关配置了一个单节点群集，那么唯一可用的驱动器就是仲裁磁盘。同时您将看到一条类似下面所示的信息。在产品环境中，不要将仲裁磁盘用于数据或日志。

10.  在“群集管理”对话框中，您可以从虚拟服务器定义中添加或删除群集节点。单击“下一步”。

11.  在“远程信息”对话框中，输入用于配置和管理服务器群集的帐户信息。单击“下一步”。

12.  在“实例名称”对话框中，单击“默认”，安装默认实例，或者不选中该项 ，在“实例名称”输入框中为这个实例输入一个唯一的名称。单击“下一步”，继续安装。

13.  在“设置类型”对话框的“目标文件夹”区域中，确认每个节点上的“程序文件”位置都被设置为有效的本地驱动器（例如 C：/Program Files/Microsoft SQL Server），并确认“数据文件”位置被配置为在“群集磁盘选择”对话框中所选择的驱动器。如果您需要为数据配置驱动器上指定目录，单击“浏览”按钮。单击“下一步”。

　

14.  在“服务帐户”对话框中，选择“每个服务使用相同的帐户”或者为“每个服务均定制设置”。在“密码”方框中输入密码。确认“用户名”、“密码”和“域”设置了正确的值。如果您选择了“每个服务均定制设置”，那么您需要为SQL Server和SQL Server Agent服务分别输入“用户名”、“密码”和“域”。单击“下一步”。

15.  在“身份验证模式”对话框中，选择“Windows身份验证模式”或“混合模式”。如果选择了“混合模式”，那么需要输入sa帐户的密码。单击“下一步”。

　

16.  在“开始复制文件”对话框中，单击“下一步”。

17.  在“选择许可模式”对话框中，选择正确的许可方案，输入正确的值，单击“继续”。

18.  在SQL Server 2000虚拟服务器安装过程中会显示一个安装提示框。

19.  在“安装完成”对话框中，单击“完成”。如果试图重新启动您的服务器，请确认您重新启动群集中所有的节点。

　

　

附录C – 配置工作表

服务器群集配置工作表

服务器群集至少具有两个节点，最多4个节点（仅适用于Windows 2000 Datacenter Server）。在使用群集服务配置向导配置服务器群集时，您可以使用服务器群集配置工作表。

　

参数

取值

群集名称

　

群集域管理员帐户

　

群集域管理员密码

　

DNS服务器

　

WINS服务器

　

Cluster IP地址

　

Cluster IP子网

　

MS DTC网络名称(NT 4)

　

MS DTC IP地址(NT 4)

　

MS DTC子网(NT 4)

　

仲裁驱动器盘符

　

节点数量

　

供群集使用的驱动器

参考“SQL Server 2000故障转移群集磁盘配置工作表”

 

节点配置工作表

这个工作表可以用于在群集之前配置每个单独的服务器。当使用群集服务配置向导配置服务器群集时，请将这个工作表与服务器群集配置工作表一起使用。

　

参数

取值

节点号

　

内存

　

处理器数量

　

服务器名称

　

公用IP地址1

　

公用IP 1子网

　

公用IP 1（供群集网络配置向导使用）

网络名称：

 仅允许客户端访问（公用网络）

 所有通讯（专用和公用网络）

适用于公用IP 1的NIC速度

10  100  

其它  值：

公用IP地址2

　

公用IP 2子网

　

公用IP 2（供群集网络配置向导使用）

网络名称：

 仅允许客户端访问（公用网络）

 所有通讯（专用和公用网络）

适用于公用IP 2的NIC速度

10  100  

其它  值：

专用IP地址

　

专用IP子网

　

专用IP（供群集网络配置向导使用）

网络名称：

仅允许内部群集通讯（专用网络）

适用于专用网络的NIC速度

10  100  

其它  值：

　

　

SQL Server 2000虚拟服务器配置工作表

目前，在一个服务器群集上最多可安装16个实例（1个默认的，15个指定的或16个指定的）。这个工作表中的信息按照设置过程中的出现顺序排列。

　

参数

取值

实例编号

　

虚拟服务器名称

　

IP地址1

　

使用的网络（IP 1）

　

IP 2 子网

　

使用的网络（IP 2）

　

数据/日志磁盘位置（一个在设置过程中使用；其余的在安装后作为从属添加）

　

群集定义/首选的所有者顺序（虚拟服务器定义的节点部分）

　

群集管理员信息

用户名：

密码：

实例类型

默认的  指定的

如果是制定的，请给出实例名称：

　

程序文件位置（在所有节点内置驱动器的同一个位置）

　

SQL Server管理员帐户

　

SQL Server管理员密码

　

SQL Server Agent管理员帐户

　

SQL Server Agent管理员密码

　

身份验证模式

Windows  混合的

如果是混合的，请给出SA密码：

　

许可证模式

每个位置  每个处理器

值：

所需的SQL服务（资源的“影响组”属性；在安装后修改）

SQL Server 代理服务  

SQL Server 全文服务  

分配给实例的内存（在安装后修改）

　

将用于移动到SQL Server组的其它磁盘，然后添加为从属磁盘（在安装后进行）

　

共享群集磁盘分区配置工作表

这个工作表将帮助您在硬件层次上配置您的共享群集磁盘阵列。需要注意的是，各个开发商所使用的磁盘阵列术语可能会有所不同，但是其中的概念通常是一样的。

“RAID分区”是共享群集磁盘阵列中的磁盘逻辑组合。“RAID配置”是在配置磁盘时所使用到的RAID配置类型。“磁盘类型”是作为RAID分区一部分的每个驱动器的基本驱动器大小。“磁盘数量”是组成RAID分区的物理驱动器数量。“分区大小”是操作系统可以使用的空间大小。

　

示例：

RAID 分区

RAID 配置

磁盘类型

磁盘数量

分区大小

A

条带镜像（1+0）

18 GB

6

54 GB

　

　

RAID 分区

RAID 层次

磁盘类型

磁盘数量

分区大小

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

　

SQL Server 2000故障转移群集磁盘配置工作表

这个工作表将作为操作系统配置过程中的简要参考。这个操作系统不应该放置在共享群集磁盘中。在这里至少需要配置两个逻辑磁盘：一个用于仲裁，另一个用于SQL Server数据（至少每个实例一个）。所有其他配置都取决于您配置的特定需求。同时需要记住的是，在填写这个工作表时，请考虑配置所有映射的/共享的驱动器、CD-ROM等。所有磁盘必须被配置为基本的，而不是动态的，必须被格式化为NTFS格式。请将这个工作表与“共享群集磁盘分区配置工作表”一起使用。

 “逻辑磁盘”是操作系统将使用的驱动器盘符，是SQL Server可分辨的。“大小”是逻辑磁盘的大小。“RAID分区”是使用的RAID分区（参考“共享群集磁盘分区配置工作表”） － 您可以在一个RAID分区上设置多个逻辑磁盘。“所有者”用于输入特定逻辑磁盘的拥有者。“用途”用于输入驱动器的用途。

示例条目：

逻辑磁盘

大小

RAID分区

所有者

用途

C：/

18 GB

A

本地系统

OS、页文件、SQL Server可执行程序－内置驱动器

Q：/

500 MB

B

服务器群集

仲裁－不用考虑物理分区的大小

R：/

54 GB

C

实例 1

事务日志

S：/

162 GB

D

实例 1

数据文件

　

这个示例显示，驱动器S：/将格式化为一个162 GB的数据分区。最初并不需要为您的SQL Server 2000数据库创建一个设备来填充这个162 GB条目。正确的设置您设备的大小，并为其扩展进行规划。

逻辑磁盘

大小

RAID分区

所有者

用途

C：/

　

　

　

　

D：/

　

　

　

　

E：/

　

　

　

　

F：/

　

　

　

　

G：/

　

　

　

　

H：/

　

　

　

　

I：/

　

　

　

　

J：/

　

　

　

　

K：/

　

　

　

　

L：/

　

　

　

　

M：/

　

　

　

　

N：/

　

　

　

　

O：/

　

　

　

　

P：/

　

　

　

　

Q：/

　

　

　

　

R：/

　

　

　

　

S：/

　

　

　

　

T：/

　

　

　

　

U：/

　

　

　

　

V：/

　

　

　

　

W：/

　

　

　

　

X：/

　

　

　

　

Y：/

　

　

　

　

Z：/

　

　

　

　

　

附录D – 安装前后的核对清单

　

安装前的Windows群集安装核对清单

这个核对清单将帮助判断您是否已经做好安装服务器群集的准备。

　

活动

通过

未通过

校验本地回路地址 127.0.0.1

 节点1

 节点2

 节点3（仅针对Datacenter）

 节点4（仅针对Datacenter）

 节点1

 节点2

 节点3（仅针对Datacenter）

 节点4（仅针对Datacenter）

在每个节点校验每个网络适配器的地址

 节点1

 节点2

 节点3（仅针对Datacenter）

 节点4（仅针对Datacenter）

 节点1

 节点2

 节点3（仅针对Datacenter）

 节点4（仅针对Datacenter）

从不在群集中的计算机校验每个节点上的每个网络适配器的地址

从群集的每个节点校验每个节点的名称

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

从不在群集中的计算机校验每个节点的名称

检验RPC服务是否在所有节点上都正常运行

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

检验所有节点是否够能看到群集磁盘（一次启动一台服务器）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

检验群集磁盘是否被格式化为NTFS

为管理服务器群集创建的域级管理员帐户

WINS服务器已经配置

DNS服务器已经配置

添加到boot.ini中的/3GB 或 /PAE设置（如果使用扩展内存）

对心跳NIC禁用NetBIOS

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

对公用NIC启用NetBIOS

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

网卡设置（速度、双工等）已经配置

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

　

　

安装后的Windows群集安装核对清单

这个核对清单将帮助您检验您的服务器群集。

　

活动

通过

未通过

从群集的所有节点校验群集IP地址

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

从不在群集中的计算机校验群集IP地址

从群集中所有节点校验群集网络名称

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

从不在群集中的计算机校验群集网络名称

从群集中所有节点校验心跳IP地址

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

配置的MS DTC（如果是Windows 2000，在每个节点上运行）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

将MS DTC转移到其它节点

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

将群集磁盘资源转移到其它节点

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

　

　

安装SQL Server 2000虚拟服务器前的核对清单

这个核对清单将帮助检验您是否已经做好安装SQL Server 2000虚拟服务器的准备。

　

活动

通过

未通过

事件查看器中不存在会干扰安装的错误

为SQL Server管理所创建的域帐户（不需要是域管理员）

所有资源都移动到将开始执行SQL Server安装的节点上

所有节点都能够访问安装路径（如果使用网络共享）

　

　

安装SQL Server 2000虚拟服务器后的核对清单

这个核对清单将帮助您检验SQL Server 2000虚拟服务器的安装。

　

活动

通过

未通过

所有SQL Server资源联机并已经配置

所有从属已正确配置

从群集中所有节点校验 SQL Server 虚拟服务器IP地址

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

从不在群集中的计算机校验 SQL Server 虚拟服务器IP地址

 

 

从群集中所有节点校验 SQL Server 虚拟服务器网络名称

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

从不在群集中的计算机校验 SQL Server 虚拟服务器网络名称

将SQL Server虚拟服务器的资源转移到虚拟服务器定义的所有节点上

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

 节点1

 节点2

 节点3 （仅针对Datacenter）

 节点4 （仅针对Datacenter）

运行

select * from ：：fn_virtualservernodes()

查询

将其它驱动器作为从属（如果必要）添加到SQL Server资源

 使SQL Server资源联机

 移动磁盘资源与SQL Server组合在一起

 将磁盘资源作为从属添加到SQL Server资源

 使SQL Server资源联机

N/A

修改SQL Server虚拟服务器内存设置（如果可用，包括设置AWE设置）

 

N/A

应用最新的SQL Server 2000服务包（如果可用）