简介
对于一个产品环境，无论是数据库驱动的关键任务客户端/服务器应用程序，还是电子商务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的特性之一）使用了以下各种硬件组件：
· 群集节点
节点是群集中的一台服务器。WindowsNT 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 Server2000。从概念上说，群集组是在您硬盘上的一个文件夹，其中含有相关的信息。 虚拟服务器
理解虚拟服务器的概念是理解故障转移群集的关键。对于一个客户端或应用程序来说，虚拟服务器是用于访问的服务器名称或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容量？
如果您在实验室或其他可控环境中对应用程序的性能进行测试，首先应该确定所需的基本处理能力。确定所需基本处理能力的一种方法就是分析您系统随时间的扩展情况，定期记录相关统计数据，然后将这些信息绘制成图表。这是非常重要的一个步骤，产品服务器的配置应该同时考虑目前的工作负载以及工作负载随时间的增长。
从操作系统角度考虑，群集需要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所有分类中搜索关键词“海量内存”进行查找。
下表总结了您设置大量内存时所应该配置的扩展内存设置。
另外，有些网卡可支持多个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配置
在这个例子中，实例 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（网络登录）
· WindowsNT LM Security Support Provider（Windows NT LM安全性支持提供商）
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)的默认群集实例”。
如果不存在任何输出活动，则说明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. 群集日志主文件。
14. 在“服务帐户”对话框中，选择“每个服务使用相同的帐户”或者为“每个服务均定制设置”。在“密码”方框中输入密码。确认“用户名”、“密码”和“域”设置了正确的值。如果您选择了“每个服务均定制设置”，那么您需要为SQL Server和SQL Server Agent服务分别输入“用户名”、“密码”和“域”。单击“下一步”。
QQ群⑧：
窥视卡
雷达卡
发表于 2016-10-31 07:32:12
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡