《MS SQL Server 2000管理员手册》系列——12. Microsoft SQL Server 与 Microsoft Cluster Services

12. Microsoft SQL Server 与 Microsoft Cluster Services
故障的类型
MSCS 概观
丛集系统的范例
SQL Server 丛集设定
超越MSCS
本章总结
在最近几年里，Microsoft SQL Server 系统已经从桌上型系统与工作群组中转移为企业后援系统。为了应付商务运作，这些系统变得更为庞大也更为重要，换言之，它们必须更稳定、更易于远程管理，以及具有更佳的容错性。为了满足这些需求，Microsoft 已经然投注了相当多的时间与精力来减少软件的错误并改进系统的支持性。Microsoft 也改善了管理工具、远程管理能力，并且发展了像是 Microsoft Cluster Services（MSCS）这样的新技术。 丛集 （Cluster）指的是一组在故障发生时可互为备援系统的计算机。在本章里，您将学习到 MSCS 如何运作、如何设定，以及如何规划才能从灾难中恢复旧观。单靠 MSCS 无法让您的系统容错；您必须配合谨慎的规划，才能让您的系统具有从错误中回复的能力。
________________________________________
说明
MSCS 包含在 Microsoft Windows 2000 Advanced Server、Microsoft Windows 2000 Datacenter Server，以及Microsoft Windows NT 4.0 Enterprise Edition之中。
________________________________________
故障的类型
　
作为一个数据库管理者的主要任务是维护数据库，并且让数据库能够在指定的时间周期内正常运作，这些通常在服务范围同意书中都会载明。服务范围同意书可能也会指定系统必须提供的最佳执行时间长、执行速率以及发生错误时要在多短的时间内复原。使用 MSCS 可以增加最长执行时间并减少复原所需要的时间。尽管服务器硬件、Windows 2000、Windows NT 以及 SQL Server 一般说来都相当稳定可靠，但是部分组件有时仍会有故障的状况。事实上，一个复杂的计算机系统可能会发生下列几种不同类型的故障：
•   硬盘故障 虽然磁盘技术已经有改进，但是硬盘机仍然是一种机械装置，并且也会磨损。硬盘是最常发生故障问题的组件之一。
　
•   硬件组件故障 硬件组件有可能是导因于组件的磨损或破坏，造成这类问题的元凶则是系统中不可避免的高温。即便是最佳制程的计算机设备也有可能因此故障。
　
•   软件组件故障 有些软件的瑕疵要在特定的情况下才会被发现。在一些特定状况发现问题之前，系统可能已经执行了好几个月或好几年。此外，新增应用程序到一个稳定的环境中也可能修改关键的函式库或档案，因而造成了故障问题。
　
•   外部故障 系统也可能因为一些外部因素而出现错误，比方电力供应突然中断。您的系统在这类错误中是否有办法起死回生，要看您是否有使用不断电系统（Uninterruptible Power Supply，UPS）或其它剩余的电源。
　
•   人为错误 丛集通常无法保护因为人为错误而故障的系统。这些人为错误包括意外删除了一个数据表或删除了 Windows NT 档案系统分割区。
　
错误是不可避免的，如何为这些错误做最好的准备，正是我们在本章中要讨论的焦点。
MSCS 概观
　
MSCS 是 Microsoft Windows 2000 Advanced Server、Microsoft Windows 2000 Datacenter Server 以及 Microsoft Windows NT 4.0 Enterprise Edition的内建服务。MSCS 是用来建构一个服务器丛集；如之前所述，服务器丛集是指独立的服务器集合为一个群组，并且共同运作起来犹如单一的系统。丛集的目的是为了在错误事件或预期可能的中断发生时，客户端仍然可以继续存取应用程序及其它资源。如果丛集中某个服务器因为任何理由而无法使用，资源与应用程序将移转到丛集中的其它节点。
当我们谈到丛集系统时，多半使用 高可用性 （high availability）这个字眼，而不是 容错 （fault tolerant）。传统上， 容错 这个名词比较适用于特定的系统，此系统能够提供极高阶的备援性和复原性。这类系统通常使用极为专业的软件，让系统能从任何单一硬件或软件错误中瞬间复原。比起无法容错的系统，容错系统可说相当昂贵。相对的，一个提供高可用性的丛集系统，其成本并不像容错系统那么惊人。丛集系统一般是由标准服务器硬件与操作系统中的丛集感知软件来建构。当系统的可用性需求日益增加，丛集之中也可以容易的加入系统为一个节点。尽管一个丛集系统无法保证必定可以进行连续性的操作，但是就大多数具有关键任务性质的应用程序而言，丛集系统确实增进了相当的可用性。
MSCS 具备下列的优点：
•   高可用性 系统资源（例如磁盘或 IP 地址）会自动地从故障的服务器移转至提供服务的服务器。这种过程称作 错误移转 （Failover）。当丛集中的某个应用程序故障时，MSCS 会自动地在另一个提供服务的服务器中启动该应用程序，或是将故障服务器的工作分散给其它的节点。错误移转的过程非常快速，使用者察觉到服务器的服务暂停将极为短暂。
　
•   容错回复 当故障的服务器修复并且重回在线时，MSCS 会自动地重新平衡丛集中的工作负载。这被称为 错误回复 （Failback）。
　
•   可管理性  丛集系统管理员 软件允许您将整个丛集视同一个单一系统般来进行管理。您可以在 丛集系统管理员 中利用拖曳丛集对象的方式将应用程序简单的搬移到丛集里的不同服务器之中。您也可以利用同样的方法来搬移数据。这种「拖曳式」的操作可以用来手动平衡服务器的负载，或是将某服务器上的负载去除，以让该服务器进行维护的工作。 丛集系统管理员 也可以让您（从网络上的任何位置）监控丛集、每个节点以及所有资源的状态。图12-1显示了 丛集系统管理员 的窗口。
　
•   可延展性 当系统的需求和负载增加时，您可以重新设定 MSCS来支持这些需求。如果整体的负载超过丛集的容量，您也可以在丛集中新增节点。

　
 
图12-1 Windows 2000 丛集系统管理员
基本概念
　
MSCS 之所以能减少系统停工的时间，是因为 MSCS 能在多个系统之间提供错误移转的功能，要达成错误移转的功能，您必须让服务器互连，并且使用 共享磁盘系统 （Shared Disk System），如图12-2所示。在达成服务器互连系统方面，您可以使用任何一种高速联机系统，例如以太网络或是其它的网络硬件。服务器互连系统扮演着服务器之间的通讯频道，这个通讯频道是为了来回传递丛集目前的状态信息，以及组态信息。共享磁盘系统则可以让丛集中所有服务器的数据库和数据文件以相等地方式被存取。共享磁盘系统可以是 SCSI、光纤信道的 SCSI，或是其它专属的硬件。至于共享的磁盘可以是一颗单独的磁盘或是 RAID 系统（RAID 系统已在 第5章 讨论过）。
________________________________________
注意
如果共享磁盘系统没有容错，并且您的磁盘子系统发生故障，MSCS 会错误移转至其它的服务器，但是新的服务器仍然会使用已经出错的磁盘子系统，因此您的系统仍然会处于故障的状态。由于这类机械装置容易发生故障的问题，因此一定要使用 RAID 来保护您的磁盘。
________________________________________
一旦您的系统被设定为丛集服务器的一员，它就会从传统的服务器转变为虚拟服务器。 虚拟服务器 （Virtual Server）看起来像是普通的服务器，但是系统的实体辨识方式已经抽象化了。因为组成虚拟服务器的计算机硬件也许不断地改变，在任何时刻使用者都无法确知目前应用程序实际上是在哪一个服务器中执行。因此，虚拟服务器为使用者的应用程序提供服务，但是指的却不是某一组特定的硬件。

　
 
图12-2 Windows 2000 丛集
虚拟服务器存在于网络上，并且也分配了一个 TCP/IP 的 IP 地址。这个 IP 地址会在丛集系统之间的服务器互相切换。因此，不论正在执行的硬件是哪一个，使用者都能看到虚拟服务器。IP 地址实际上是从一个系统迁移到另一个系统，对外部世界来说，就可以维持一个恒定不变的虚拟服务器。因此如果服务器出了问题，一个使用特定 IP 地址的应用程序仍然可以继续存取该 IP 地址，即使该 IP 地址现在代表一个不同的服务器。虚拟服务器让使用者无法发现错误移转操作，因此使用者可以持续工作，而不知道幕后发生了什么。
丛集组件
　
建立丛集需要几个组件：丛集管理软件、服务器互连系统，以及共享磁盘系统。这些组件必须加以设定，并且配合丛集感知应用程序使用以建立丛集。在本节中，您会了解这些不同的组件，并学习到它们是如何一起工作以建立丛集。在本章稍后 〈SQL Server丛集设定〉 一节中，您会学习到如何设定 SQL Server 丛集。
MSCS丛集管理软件
　
 丛集管理软件 （Cluster Management Software）实际上是一组软件工具，可用来维护、设定及启动丛集。它是由下列子组件组成，这些子组件一起工作以维持丛集的功能性，并且在必要时执行错误移转的工作：
•   Node Manager 维护丛集系统之间的成员关系，传送 心跳 （heartbeats）信息给其它的丛集成员（节点）（心跳指的是周期性送出 我还活着 （I am alive）的讯息。如果一个节点的心跳停止，另一个节点会认为它不再可用，并且会开始接管它的工作。Node Manager 是丛集最关键的部分之一，因为它会监控丛集的状态与丛集的成员，并决定该采取什么行动。
　
•   Configuration Database Manager 维护丛集的数据库设定。这个数据库保留了丛集中所有组件的追踪信息，包括了抽象的逻辑元素（例如虚拟服务器）以及实体元素（例如共享磁盘）。该数据库类似于 Windows NT/2000 的登录数据库（Registry）。
　
•   Resource Manager/Failover Manager 启动与停止 MSCS。Manager/Failover Manager 会从 Resource Monitor 及 Node Manager 中接收各项信息，例如遗失节点、新增节点等等。
　
•   Event Processor 负责初始化丛集，以及在丛集组件之间路由事件信息。Event Processor 也负责藉由指示 Node Manager 新增节点以为丛集系统的延伸进行初始化。
　
•   Communications Manager 管理丛集之中各个节点之间的通讯。丛集之中所有的节点都必须不断地与其它的节点通讯以维持丛集的运作功能。如果各个节点彼此之间失去联系，丛集状态信息就会遗失，丛集也就无法正常运作。
　
•   Global Update Manager 将丛集状态信息通知给丛集中所有的节点，其中包含丛集中节点的新增与删除等等。
　
•   Resource Monitor 监控丛集中各种不同资源的状态，并且提供统计资料。这个信息用以决定丛集中是否该采取任何错误移转的动作。
　
•   Time Service 确保丛集中所有的节点都能报告相同的系统时间。如果没有 Time Service，事件发生的顺序就有可能会弄错，导致系统作出不正确的决定。举例来说，如果得到较旧版本档案的节点认为时间是下午2点，而获得新版本档案的节点认为此时是上午10点，丛集就会错误地认为第一个系统中的档案是最新的。
　
服务器互连系统
　
 服务器互连系统 （Server Interconnect）指的是丛集中节点之间的联机。因为丛集中的节点彼此之间需要透过 Time Service、Node Manager 等等的组件不断地通讯，因此维护高速的联机非常重要。
服务器互连系统必须是系统之间用以通讯的可靠信道。
服务器互连经常是执行 TCP/IP 或 NetBIOS 的高速以太网络。这种设定已经十分足够，但是您或许会想要使用比以太网络更快的专用、高速互连系统。这种互连装置可从硬件厂商那里买到，其中有些厂商也提供像是 共享磁盘 服务这类通讯服务。Microsoft 网站 http://www.microsoft.com/hcl/ 的兼容硬件清单提供了一般的服务器互连装置的完整清单。
共享磁盘系统
　
丛集建立的另一个关键性组件是 共享磁盘 （Shared-Disk）系统。如果多个计算机系统可以存取相同的磁盘系统，当主要节点故障时，便可移转至其它节点。共享磁盘系统必须允许多个计算机系统可以同等地存取相同的磁盘－换句话说，每台计算机都必须能够存取所有的磁盘。在 MSCS 目前的版本中，每次只能有一个系统存取磁盘，但是将来的版本将允许多个系统同时存取磁盘。
目前已经有数种共享磁盘系统，而且新的磁盘技术也正不断地发展中。SCSI磁盘子系统已支持多引发器（multiple initiators）的功能。利用这个功能，您可以在同一个 SCSI 总线上拥有多个 SCSI 控制器，如此一来 SCSI 便相当适于丛集使用。事实上，SCSI 是第一种用于丛集的磁盘子系统。
最近已经设计出一些新的磁盘技术用以支持丛集，例如 光纤信道 （Fiber Channel）和一些专门的解决方案。光纤信道系统允许计算机可以跨越很长的距离来连接磁盘。大多数的光纤信道系统都支持在同一个光纤回路上使用多个控制器。一些 RAID 控制卡已经被开发或改进来支持丛集。如果不修改或变更设定，绝大多数的磁盘控制卡将无法支持丛集。
如果快取是位在控制卡本身，控制卡快取允许写入的内容暂存于内存中，这会成为丛集的一大问题，如图12-3所示。在这种情况下，每个节点拥有自己的快取，我们将这种情况称为 磁盘共享之前（in front of disk sharing） ，因为两个快取共享相同的磁盘。当系统故障时，由于每个控制卡都有快取，而快取却位于故障的系统，那么快取中的数据就会遗失了。因此，若我们在丛集设定中使用内部控制卡快取，它们就该被设定为只读模式。（在某些情况下，这种设定可能会降低一些系统的效能。）

　
 
图12-3 位于磁盘共享之前的控制卡快取
对于共享磁盘系统问题的解决方案牵涉到 RAID，以及位于磁盘系统本身的快取。在这种设定中，所有的节点共享该快取，我们称之为 在磁盘共享之后（behind the disk sharing） ，如图12-4所示。RAID 机制和磁盘共享系统的快取会被系统中所有控制卡一致的存取，读取快取与写入快取都很安全。

　
 
图12-4 位于磁盘共享之后的控制卡快取
较新的 SCSI 与光纤信道磁盘系统允许 RAID 控制卡封装在磁盘中，而不是在计算机系统中。这种系统提供了优秀的执行效能及容错能力。事实上，许多这类型的 RAID 系统提供备援控制卡和快取。较新的 RAID 系统中有很多已采用这种结构。下面是一些详细的例子。
 I/O子系统 之前已经提到，有几种不同类型的 I/O 子系统支持丛集。以下是最主要的三种类型：
•   SCSI JBOD 一种利用 JBOD（Just a Bunch Of Disks）寻址，在SCSI 总线上有多个引发器（控制器）的系统。在这种设定中，磁盘拥有独立的地址，必须使用 Windows 2000 或独立寻址的方式来设定至磁盘阵列中。通常不建议使用这种系统。
　
•   内部RAID 每一个服务器上有一个 RAID 控制卡。这种子系统的缺点是为了避免数据遗失，控制卡快取必须设定为停用。
　
•   外部RAID RAID 控制卡是由丛集中的磁盘系统共享。快取与 RAID逻辑封装在磁盘内，使一个简单的主机总线卡（HBA）与外部控制卡相连接。
　
接下来两节仅说明上述两种 RAID 解决方案。只有在丛集很小，而且费用问题是主要考虑时才使用 SCSI JBOD。
 内部RAID 内部 RAID 控制卡的设计是由硬件来处理RAID过程，并且快取属于主机系统。使用内部 RAID 时，共享磁盘系统位于 RAID 之后，如图21-5所示。

　
 
图12-5 内部 RAID 控制卡
由于快取位于控制卡上，并没有共享，因此快取中的数据在系统故障时将无法使用。在关联性数据库管理系统（RDBMS）中，这是一个很大的问题。当 SQL Server 将数据写入到磁盘时，数据可能仍在快取中（因为其运作是先写入磁盘控制卡快取），但在交易记录文件里会记录该数据为已经写入。若此时系统出现故障问题，SQL Server 在试图回复时将不会回复这些数据区块，因为 SQL Server 认为这些数据已写入磁盘。在这种设定类型的错误事件中，数据库将因而受损。
因此，厂商必须保证用于丛集的快取 RAID 控制卡的快取功能已经关闭（或至少是写入快取的功能已经关闭）。如果快取功能已经关闭，SQL Server 在数据尚未被实际的写入磁盘之前，不会收到写入操作已经完成的信号。
________________________________________
说明
SQL Server 是在不使用缓冲区与快取的模式下执行所有写入到磁盘的操作。不管有多少档案系统快取可用，SQl Server 都不会使用它们。就如同大多数的 RDBMS 产品一样，SQL Server 完全忽略档案系统快取。
________________________________________
在某些情况下，控制卡快取能大大提供执行的效能。尤其是当您使用的是 RAID 10 或 RAID 5，因为这些 RAID 层级在写入操作时会产生额外的负担。要在丛集设定中使用控制卡写入快取，您就必须使用外部 RAID 系统，让快取可以共享，资料就不会在错误移转时遗失。
 外部RAID 在外部 RAID 系统中，RAID 硬件是在主机系统之外，如图12-6。每个服务器都会有一个 HBA，它的工作是尽可能地将更多的 I/O 要求尽速外送给 RAID 系统。RAID 系统决定数据实际储存的位置。

　
 
图12-6 外部 RAID 子系统
外部 RAID 子系统有时也被称为机柜 RAID 或机箱 RAID，因为 RAID 是在磁盘驱动器柜内进行。外部 RAID 子系统有着许多优点。它不仅是 MSCS 的理想解决方案，也是一个重要性全面解决方案。机柜 RAID 有以下优点：
•   易于接线 使用内部 RAID 时，您需要从 RAID 控制卡接出许多电缆－每个磁盘柜都需要一条。如果使用的是外部 RAID，您仅需一条电缆来连接 HBA 与外部 RAID 控制卡，而磁盘柜可以用菊花环（daisy chain）的形式连接起来，控制卡再与此菊花环连接，如图12-7所示。即使需要连接的磁盘有数百个，外部 RAID 仍然可以简单地完成这个工作。
　
•   允许丛集快取 使用外部 RAID 可以让您更容易地设定快取 RAID 解决方案。如果您使用外部 RAID，您可以同时拥有快取与容错功能，而不必担心在多个控制卡之间的快取一致性（因为只有一个快取及一个控制卡）。事实上，如果使用的是外部 RAID，写入快取并不会不安全。虽然在您快取 RDBMS 数据时仍有风险，不过在使用外部 RAID 控制卡的情况下这种风险已大大降低。要确定您的外部 RAID 系统厂商支持快取镜像，当内存芯片出错时，快取镜像能提供容错的功能。
　
•   支持更多的磁盘 在大型系统或高效能系统中，有时必须规划大量的磁盘。在 第6章 中阐述了大量磁盘的必要性，并学习如何规划系统的大小；在 第36章 学习一般执行问题时，还会再看到它。外部 RAID 装置让您可以连接数百个磁盘到一个单独的 HBA。内部 RAID 系统，每个控制卡只能连接有限的几打磁盘，如同 SCSI 一样。

　
 
图12-7 内部 RAID 接线 vs. 外部RAID接线
在今日这些可用来支持丛集的磁盘子系统中，外部 RAID 机柜最适用于大型丛集。当然，成本也是必须考虑的，再者有些丛集太小反而不适合使用外部 RAID。不过，在长期执行方案中，外部 RAID 解决方案可以对您的丛集提供最佳的效能、可靠度以及管理性。
丛集应用程序的类型
　
在 MSCS 的系统上执行的应用程序，可分四种类别：
•   非丛集感知应用程序 （Cluster-unaware applications）这类应用程序不会与 MSCS 产生任何互动。虽然它们可以在正常的状况下顺利执行，但在故障发生时它们可能就会当掉，无法强制错误移转到其它的节点继续工作。
　
•   丛集感知应用程序 （Cluster-aware applications）这类应用程序会意识到 MSCS 的存在。它们可以利用 MSCS 来提升其效能与调适性。它们对丛集事件反应良好，并在组件故障且错误移转发生之后仅需很少的动作（甚至完全不需要）便能继续执行。SQL Server 2000 是丛集感知应用程序的一个好例子。
　
•   丛集管理应用程序 这类应用程序用来监控与管理 MSCS 环境。
　
•   自订资源类型 （Custom resource types）这类应用程序对其他的应用程序，服务及装置提供自订的丛集管理资源。
　
MSCS 模式
　
您可以在不同的模式中执行 SQL Server 2000 丛集支持与 MSCS。在 主动/被动 （Active/Passive）模式中，一个服务器保持备用模式，准备在系统发生故障时立刻接管主要服务器的工作。在 主动/主动 （Active/Active）模式中，每个服务器都执行一个不同的 SQL Server 数据库，无论哪一个服务器发生了错误，另一个服务器将接管它。在这种情况下，一个服务器将执行两个数据库。在本节中，我们将介绍每一种模式的优点与缺点。

　
 
图12-8 应用程序类型与 MSCS
主动/被动丛集
　
主动/被动丛集使用主要节点来执行 SQL Server 应用程序，并将用于次要节点的服务器作为备份或备用服务器，如图12-9所示。

　
 
图12-9 主动/被动丛集
在这种设定中，有一个服务器实际上是不使用的。这个服务器可能有好几个月都不曾被呼叫来执行任何工作。事实上，大部分的情况是，备份服务器从来不曾使用。因为次要服务器几乎没动过，它看起来就像是一个闲置的昂贵设备。由于服务器无法用来执行其它的功能，为了服务使用者或许就需要购买其它的设备，这使得主动/被动模式可能比您所想象的还要花钱。
虽然主动/被动模式的成本较高，但它也有优点。在主动/被动设定中，如果主要节点出错，次要节点的所有资源都可用来接管主要节点的活动。如果您执行的是具有关键任务性质的应用程序，系统需要负荷指定的流量或是响应时间，这种可靠性就相当重要。在此情况下，对您来说主动/被动模式也许是正确的选择。
强烈建议次要节点与主要节点拥有完全相同的硬件（也就是说，RAM 的数量相同、CPU 的类型与数量相同等等）。如果两个节点有完全相同的硬件，您便能确定次要系统的执行效能可与主要系统近乎相同。否则，在错误移转事件中就可能遭遇到效能损失的问题。
主动/主动丛集
　
在主动/主动丛集中，每一个服务器都执行应用程序，同时也作为另一个节点的次要服务器，如图12-10所示。

　
 
图12-10 主动/主动丛集
在这种设定中，每一个服务器既是某些应用程序的主要节点，又作为另一些应用程序的次要节点。这是最符合成本效益的设定，因为不会有设备处于闲置的状态，等着其它系统出错。两个系统都能为使用者服务。此外，也可利用一个单独的被动节点来作为数个主要节点的次要节点。
主动/主动设定的一个缺点是，在故障事件发生后，次要节点的负担加重，如此便造成幸存的节点效能明显下降。幸存的节点现在不仅要执行原先的应用程序，还需执行来自主要节点的应用程序。在某些情况下，如果无法忍受效能的损失，就必须使用主动/被动设定。
丛集系统的范例
　
在本节中，我们来看一下四个使用 MSCS 的丛集系统范例。这些范例将有助于您决定哪一种类型的丛集最符合您的需求与环境。
范例1－具备静态负载平衡（Static Load Balancing）的高可用性系统
　
这种系统能够对丛集上的多个应用程序提供高可用性。不过，若所有在线只剩一个节点时，效能就会大打折扣。此系统的硬件资源使用率最高，因为每个节点都可以被存取。图12-11显示了这类丛集的设定方式，它是一个主动/主动丛集。

　
 
图12-11 具备静态负载平衡的高可用性丛集
丛集中的每个节点会以虚拟服务器的形式将其拥有的资源通知网络。每个节点在设定上均会保留额外的处理能力，因此在错误移转发生时可以执行其它节点的应用程序。换言之，借着这些额外的资源与额外的处理能力，提供错误节点客户端的服务便不会中断。
范例2－具有最大可用性的热更换式系统
　
这种系统透过所有的系统资源来提供最大的可用性及效能表现。这种设定的缺点是大量对硬件资源的投资－并且有大部分还用不到。其中一个节点会被当作是主要节点并应付所有客户端的要求，另一个节点则处于闲置的状态。闲置的节点事实上是用来作为热机状态的备用系统，只有在错误事件发生时才会被存取。如果主要节点出错，这个热更换节点便可立刻接管所有的操作并继续对客户端的要求提供服务。图12-12显示了这种设定方式。
这种设定对一些具有最关键任务性质的应用程序来说，是再适合不过的了。如果您的公司是在因特网上进行销售活动，那么您的 Web 交易服务器可能就是以这种设定方式来运作。由于您的生意必须仰仗系统的成败，多花点钱购置一个闲置的系统以备不时之需，其实还是很值得的。

　
 
图12-12 具有最大可用性的热更换式系统
范例3－局部服务器丛集
　
MSCS 是相当有弹性的丛集方案，从局部服务器丛集设定上就可以看得出来。在这种系统中，只有您所选取的应用程序允许错误移转。如图12-13所示，您可以指定某些应用程序在其节点出错时仍然可用，其它的应用程序则不行。

　
 
图12-13 局部服务器丛集
当您打算将硬件资源的使用率最大化，但又必须对一些具有关键任务性质的应用程序提供有限的错误移转容量时，这种设定方式就相当理想。此外，这种设定一方面对那些丛集感知应用程序提供错误移转，同时也能支持非丛集感知的应用程序。
范例4－无法错误移转的虚拟服务器
　
我们的最后一个系统范例其实并不是真正的丛集，不过它仍然利用了 MSCS 对虚拟服务器的支持性。这种设定其实是一种用来组织资源、发布资源的方法，如图12-14所示。虚拟服务器功能允许您为资源命名时采用有意义的、具有描述性质的名称，而不是一般的服务器名称清单。此外，MSCS 在服务器错误解决后会自动地重新启动应用程序或资源。对一些并不提供内部机制来重新启动的应用程序而言，这种功能特别有用。这种架构也可说是迈向丛集的最佳预备动作，一旦您在单一节点上定义了虚拟服务器，便可以很简单的加入一个次要节点，而不需要更动服务器定义。

　
 
图12-14 无法错误移转的虚拟服务器
SQL Server 丛集设定
　
在您安装并设定 MSCS 之后，下一个步骤便是设定 SQL Server 在丛集中执行。如之前所言，SQL Server 2000 具有丛集感知的能力，并且可以善用丛集的功能。在本节中，我们先来看一下如何规划丛集系统，接着回顾在丛集中设定 SQL Server 所必须执行的步骤。
________________________________________
说明
要获得 MSCS 的所有好处，应用程序必须具有丛集感知的能力。之前已经说过，丛集感知应用程序必须了解丛集架构并且能在错误事件中错误移转。并不是所有的应用程序都支持丛集，并且在丛集中遇到问题时有能力「逃出樊笼」。
________________________________________
规划您的设定
　
规划 SQL Server 丛集的第一个步骤是决定要使用的硬件类型，以及丛集打算采取哪一种作业模式来执行。可以组成丛集系统的硬件架构相当多种，而丛集的运作可以选择 主动/被动 模式或是 主动/主动 模式。所选的模式会决定您需要的硬件类型与数量。
 主动/被动 丛集设定应该由完全相同的两个系统组成，每个都有能力掌握整体的工作载量。由于主动/被动模式在正常运作的期间不会使用次要系统，错误发生后也不会使用主要系统，虚拟服务器的效能将可保持不变。当主要系统错误移转至一个完全相同的次要系统，使用者不会察觉到任何效能的变化。
 主动/主动 丛集设定则应该由两个各自执行一特定工作载量的系统组成。如果发生错误，幸存系统会接管错误系统的工作载量。在这种情况下，单一系统要执行两份工作，所有使用者都会面临效能降低的问题。如果您的规划够谨慎，系统的效能也许还能维持一个可接受的最低极限，不过事实上这个效能并不保险。在规划主动/主动丛集设定时，您应对效能的损失有心理准备，看是要减少一些服务，还是说在错误移转事件中警告使用者，系统效能可能下降。
设定 SQL Server 丛集功能的下一个步骤是检查或变更一些 SQL Server 的设定。接下来的三个小节中我们会检查这些设定。
设定复原时间
　
在调整 SQL Server 效能时，您可能已经将组态选项 复原间隔 （recovery interval）设定为其它的值，而不是默认值 0 。变更这个设定可以增加检查点的间隔时间以改善效能，不过也会增加复原时间。在丛集系统中，默认值 0 不应该变更，它表示复原间隔将由 SQL Server 自动设定。（拥有一个可以错误移转的系统是使用 MSCS 的主要理由，这应该比效能考虑还要重要。）这个设定可以让数据库几乎每分钟有一次检查点，并且最大的复原时间为一分钟左右。
________________________________________
相关信息
要找到更多的信息，请参阅在线丛书并索引 复原间隔选项 。
________________________________________
________________________________________
说明
检查点操作会让 SQL Server 将快取中修改过的数据写入到磁盘里。任何已修改的数据若在系统错误时尚未被写入磁盘，SQL Server 在启动时会因向前复原已认可交易，以及向后复原未认可的交易，并且复原这些未认可的资料。
________________________________________
设定 SQL Server 在主动/被动丛集上执行
　
要建立主动/被动丛集设定，您可能必须修改 SQL Server 中的一个设定值。如果您的次要服务器与主要服务器完全相同，就不需要修改。但若次要服务器的资源少于主要服务器，您就必须将 SQL Server 组态选项 min server memory 设为 0 。这个设定指示 SQL Server 依系统可用的资源来分配内存。
________________________________________
相关信息
要找到相关信息，请参阅在线丛书并索引「服务器内存选项」。
________________________________________
设定 SQL Server 在主动/主动丛集上执行
　
在主动/主动丛集设定中，您必须将 SQL Server 组态选项 min server memory 设为 0 。如果该组态选项设为手动，SQL Sever 可能会在错误移转之后无法分配内存。由于 Windows 2000 是一个虚拟内存系统，它可以分配比实际可用还要更多的内存。事实上，这也是一个常常发生的问题，因为导致了分页动作。举例来说，如果每个 SQL Server 系统分配 75% 的系统内存，错误移转发生后合并的 SQL Server 服务就会需要 150% 的可用内存，若无法进行动态的分配，系统就有可能陷于停滞的状态。
在丛集中安装 SQL Server
　
在丛集中安装 SQL Server 的过程与 第7章 所介绍的 SQL Server 安装程序相当类似。在开始这个安装过程之前，您必须决定 SQL Server 要安装的位置。您应将 SQL Server 档案安装在由主要服务器控制的共享磁盘上。SQL Server 的安装路径与 master 数据库安装路径也应该设定指向共享磁盘。您也应指定丛集将要执行的网络通讯协议。接下来，可遵循下列步骤来安装 SQL Server 错误移转丛集：
1. 将 SQL Server 2000 光盘片放入您的光驱中。如果您的系统有自动播放的功能，SQL Server 2000 的主要设定对话框就会出现，如图12-15。否则的话，您就需要手动执行Autorun.exe（可在光盘片的根目录中找到）。
　
 
图12-15 SQL Server 设定对话框
2. 如果您尚未安装必须的操作系统更新套件，或是尚未安装Microsoft Internet Explorer 的必备版本，或是单纯只想检查一下必要安装的清单，按一下 SQL Server 2000的必要安装 ，会出现 SQL Server 2000的必要安装 对话框。
在最适合的系统上按一下以检视它的需求，并在您需要的选项上按一下以进入安装。如果您已经加载最适当的软件，直接跳到步骤3。
________________________________________
说明
在开始安装 SQL Server 之前，必须已安装 MSCS。
________________________________________
3. 按一下 SQL Server 2000的组件 ，出现 SQL Server 2000安装精灵 欢迎画面。如果您正在执行其它的 Windows 程序，请将它们关闭。按一下 下一步 继续安装过程。
4. 在 计算机名称 画面，按一下 虚拟服务器 并输入服务器名称，如图12-16。按一下 下一步 。
　
 
图12-16 「计算机名称」画面
5. 出现 使用者信息 画面。输入您的名称与公司名称。按一下 下一步 。
6. 出现 软件授权同意书 。按一下 是 接受其授权同意书并继续安装过程。
7. 在 安装 画面中，输入 25 个字符的产品识别码（贴在光盘盒外的黄色贴标）。按一下 下一步 。
8. 出现 错误移转丛集 画面，如图12-17。输入虚拟服务器的IP地址，然后按一下 新增 。MSCS 支援子网络地址。按一下 下一步 。
9. 在 丛集管理 画面检视 SQL Server 2000 提供的丛集定义。预设情况下，本机端计算机设为优先节点。其它的可用节点会出现在 Additional Node 方块里。按一下 下一步 。
10. 在 远程信息 画面中，输入远程丛集节点的登入凭证。此登入凭证必须具有丛集的远程节点之系统管理员权限。按一下 下一步 。
11. 请在 执行个体名称 画面中，选择一个预设执行个体或指定一个命名的执行个体。若要指定命名的执行个体，请清除 默认值 复选框，然后输入命名执行个体的名称。按一下 下一步 。
________________________________________
说明
执行个体不能被命名为 DEFAULT 或 MSSQLSERVER 或其它作为 SQL Server 保留关键词的名称。
________________________________________

　
 
图12-17 「错误移转丛集」画面
12. 请在 安装类型 画面中，选择欲安装的类型。 安装 程序会自动将默认值设为您先前选取群组中第一个可用的丛集磁盘资源。然而，若需指定不同的丛集磁盘资源，请在 数据文件 下按一下 浏览 按钮，然后指定一个位于不同的共享磁盘资源上的路径。按一下 下一步 。
13. 接着出现 验证模式 对话框，如图12-18。在此画面的设定选择将会决定您的 SQL Server 安装的安全性层级。您可选择 Windows验证模式 或是 合模式 (Windows 的账户验证及 SQL Server 的账户验证) 。若选择 Windows 验证模式 ，数据库使用者的权限就会继承自 Windows使用者安全性 设定。若是选择 合模式 (Windows 的账户验证及 SQL Server 的账户验证) ，您可以个别的定义与管理数据库使用者的安全性。如果选取的是 合模式 (Windows 的账户验证及 SQL Server 的账户验证) ，就必须输入并确认 sa（即 SQL Server 系统管理员）登入的密码。您也可以在sa密码字段内留下空白，不过这样会让您的 SQL Server 安全性严重降低。
　
 
图12-18 「验证模式」画面
14. 在 开始复制档案 画面中，按一下 下一步 。
15. 出现 授权模式 画面。您有两种 SQL Server 客户端授权模式可选，一种是每一服务器授权，另一种是每一基座授权。在每一服务器授权模式中，您必须对特定服务器指定个别的 客户端存取授权 （CAL），每个授权允许一个与服务器的联机。不论在任何时刻，可以联机至服务器的客户端计算机最大数量等于您所指派给该服务器的 客户端存取授权 数量。如果您选择每一服务器授权，您必须指定为该服务器所购买的同时联机 客户端存取授权 数量。
每一基座授权模式中，每个即将存取 SQL Server 服务器的计算机都需要一个 客户端存取授权 。计算机一旦获得授权，它就可以存取网络上任何执行 SQL Server 2000 的机器而不需额外的付费。
如果不确定该选择哪一种授权模式，按一下 每服务器 。这个授权同意书让您可以有一次机会、一种方式来变更设定为每一基座授权模式。
按一下 继续 便会开始安装 SQL Server 应用程序及数据文件。SQL Server 安装程序会将必要的档案安装至您的系统中并设定必须的组件。安装可能会花几分钟，或者更久，这要看您系统的速度而定。
16. 当出现 安装完成 画面时，选取重新启动计算机的选项然后按一下 完成 。
如同您所看到的，设定 SQL Server 丛集相当容易。一旦设定了丛集，就不再需要其它的设定步骤。客户端将透过 IP 地址存取 SQL Server，这个 IP 地址在错误移转后会重新分配给次要节点。剩余应考虑的程序问题，我们会在稍后 〈超越MSCS〉 一节中讨论。
使用三层式应用程序
　
大部分应用程序都是直接联机至数据库。应用程序提出交易，数据库响应交易。在系统错误事件中，交易会逾时，应用程序也会出现执行失败的状况。就大多数情况而言，这种设定不会有什么问题－若交易没有完成，您会希望应用程序执行失败。不过，若您采用了错误移转丛集，数据库会在很短的时间内又重回可用的状态，并在错误后继续响应交易。您可以谨慎的设计一个 三层式 （Three-Tier）的应用程序，便能确保应用程序可以利用此种快速恢复的服务。
在三层式应用程序中，中介层可以察觉服务器已停止响应，并等待一段时间，然后重新提交交易。使用者可能会感觉到交易的完成似乎有些延迟，但延迟完成总比交易失败要好得多。要达到这个目标，则在服务器与应用程序之间出现联机失败的状况时，应用程序必须有所察觉，并且知道要重新建立联机。应用程序也应该将目前处理的状况，利用一个讯息对话框或是其它方式通知末端使用者。
利用三层式应用程序，建置一个天衣无缝的错误移转环境就不再是遥不可及的理想。应用程序必须具有丛集感知的能力，并且知道虚拟服务器不久后就能重回工作岗位继续工作。将三层式应用程序与 MSCS 架构在一起，您就能提供应用程序与数据坚固性。
超越MSCS
　
我们已经介绍了 MSCS 的基本概念以及 SQL Server 在此架构上如何工作。我们也已经看到 SQL Server 是如何在一些硬件与软件错误中幸免于难，并在短时间内重新执行交易。要达到这种容错程度，您不仅需要使用 MSCS，还需采取一些措施。有两个步骤是相当重要的：一是规律并确实的执行备份工作，二是准备灾难还原计划。系统备份的程序以及如何准备一份灾难还原计划将在第 32 及 33 章中介绍。并不是有了丛集服务器或建立一个 RAID 储存系统就可以不执行备份工作。在许多状况中，若您的系统出了问题但却未制作任何备份，这些技术一样无法给您任何帮助。这些状况包括了以下几种错误：
•   硬件故障 虽然不很常见，但有些硬件故障确实能使资料走样。如果您的主要系统遭遇到这种足以毁损数据库的硬件故障，次要系统在错误移转后仍会使用已经受损的数据库。
　
•   软件故障 不管是多好的软件，即使在开发与测试上已尽可能完善，仍然可能藏有 bug。如果某个罕见的软件 bug 毁损了数据库，错误移转后该数据库一样无法使用。RAID 技术虽然可以简单地提供一个容错副本，但副本里却可能仍是受损的数据。
　
•   人为错误 使用者经常会错误地删除了他们的数据。不论是丛集技术或是 RAID 都无法解决这个问题。
　
在第 32 及 33 章中，您会学习到更多有关于应变计划以及如何让系统幸免于难的知识。前面的例子仅仅表示一个事实：丛集与错误移转服务于特定的目的，但在我们与「灾变」的战争中，这两个武器仅能提供稳定的数据存取及数据完整性。若希望您的系统能从危机中全身而退，您还需要更多的努力。
本章总结
　
在本章中，您已学习到不同的丛集设定，建立丛集所需的硬件和软件，以及 SQL Server 丛集设定过程等等相关知识。您也了解到 MSCS 在一些状况确实有所帮助，但却不是完善且完整的系统容错方案。您也必须使用具有容错功能的磁盘子系统，并且确实的执行备份工作。将 MSCS 与一个良好的灾难还原策略结合，便能提供最大化的系统最佳执行时间与系统可靠度。在下一章，我们将开始介绍 Transact-SQL以及 SQL Server 2000 中可用的 SQL Server 2000 版本新增功能。