服务器群集利用了Windows Server系列的Enterprise Edition中的内置群集功能。实际上，对于群集，使用Windows Server 2003要比Windows 2000 Advanced Server 好得多。要想使您从群集中获得的好处最大化，您需要合适的硬件，而这涉及到一些费用。只是利用共享磁盘将几个服务器拼凑在一起是不够的，您不能依赖这样的 事实，即单独的硬件组件可能存在于 Windows目录（以前称为硬件兼容性列表）中。系统作为整体必须存在于Windows目录中。但不要担心，还有其他一些经过认可的、低成本群集解决方 案可用。图 1 显示了一种典型的群集配置。
Figure 1 A typical cluster
当然，群集比硬件需要更多的条件 - 您还需要选择合适版本的SQL Server 2005。Enterprise Edition 支持群集功能以及其他一些有用功能，如能够利用更多CPU、分布式和可更新已分区视图、内置日志传送、自动使用索引视图。如果已经拥有 Enterprise Edition 许可证，则应考虑群集：您是否有构成传统群集所必需的两到八台服务器（我们马上会讨论单节点群集）。如果拥有SQL Server 2005 Standard Edition，则可以安装两节点群集。
Windows Server 2003 Enterprise Edition和Datacenter Edition 附带内置群集功能。安装群集只需运行群集管理器。您可以同时添加所有节点，也可以每次添加一个节点。类似地，在安装 SQL Server 时，您可以选择安装在单独的非群集服务器上，也可以选择将虚拟实例安装在群集上。如果选择安装虚拟实例，可以安装在群集的所有节点上，也可以安装在一部分 节点上，甚至仅安装在一个节点上。
最后，为了达到群集的真正目标，即高可用性，需要为您提供合格的人员以及在出现问题时所遵循的预先演练好的过程。尽管群集是防止出现硬件故障的有力 保障，但它无法阻止用户出错。例如，午夜时分，一位睡眼朦胧的DBA删除了一份重要的表。
单节点群集
尽管您在此刻只拥有一台服务器，也可以考虑创建一个单节点群集。如果这样做，您可以在以后选择升级到群集，从而无需重建。但是，请务必确保您所选择 的硬件位于 Windows目录的群集部分。
这样做不仅仅只是为了实现能够在以后添加节点这个高可用性。如果您发现您的服务器恰好没有必需的功能，那么您猜会发生什么事情。这意味着您需要迁移 - 既费时又费力。如果您有一个单节点群集，则迁移过程就会变得很容易，停机时间也少得多。您需要向群集中添加新节点，将SQL Server二进制文件和服务包添加到该新节点，然后故障转移到该新节点。接下来，添加任何服务包之后的更新程序，最后删除旧节点。停机时间只是故障转移 时间与添加更新程序（如果有）时间之和。
添加节点
由于一个群集中的所有节点必须相同，您应该立刻（而不是稍后）采取行动，获得另外的节点。如果等待时间太长，节点可能会退出生产。曾经就有这样一个 项目，我不得不在 SQL Server 2000群集中重建节点。我请操作系统/网络管理员处理了基本的计算机构建，然后我投入工作，将构建的计算机添加回群集并准备将其用作 SQL Server 节点。一切都进行得很顺利，直到我需要故障转移到新节点。但令我非常沮丧的是，它却直接执行了故障恢复。长话短说，尽管我已经准备了有关如何构建新群集的 详细文档，其中包括如何将群集服务帐户和SQL Server服务帐户添加到这两个节点，但显然管理员并没有遵循该文档。管理员没有将这些服务帐户添加到重建节点，所以，他们在重建之前所拥有的权限便不 再存在。
我花了很长时间才追捕到这个原因。有一天，我突然想到查看一下本地组成员身份。当我添加了这两个帐户之后，故障转移便顺利进行了。于是我开始思考。 虽然您只是偶尔才需要重建节点，但如果需要重建节点，那便是在紧急时刻。尽管我已经提供了文档，但人们并不利用它。只需编写一个简短的脚本来添加这两个帐 户及进行任何其他必要的自定义，就能使安全部分自动完成。在SQL Server 2005中，事情得到了改善。安装程序要求您为SQL Server服务帐户设置域级组。
当然，这让我想得更多。您可以创建几个脚本，它们调用CLUSTER.EXE将节点添加到Microsoft Cluster Server (MSCS)群集中。您只需为脚本提供节点名称，然后由脚本处理其余工作。在紧急情况下，自动化确实是您的朋友。
N+1群集
有时，向群集添加节点的原因不是您要更换节点。您可以将更多的SQL Server实例添加到群集中且每个实例都需要不同的磁盘资源。虽然多个实例可以在一个节点上运行，但这些实例会共享CPU和RAM，因此可能会导致性能 降低。理想情况下，在一个节点上仅运行一个实例。但在发生故障转移时如何能确保做到这一点呢？很简单：答案是，有一个节点上不运行任何服务，而其他节点则 是每个节点上运行一个SQL Server实例。实际上，这就是N+1群集的定义： N+1个节点上运行N个实例。额外的节点是备用节点。
升级SQL Server
升级SQL Server的群集实例不是因为胆小：构建群集只为一个原因 - 您需要正常运行时间。但SQL Server 2005提供了许多您想利用的增强功能。所以，如果您准备升级，无需太多停机时间便可以继续进行。
您会选择哪种方案？我们首先看一看成本最高的解决方案：创建整个新群集。这意味着要创建若干新服务器，或许还要创建新的存储区域网络(SAN)。您 或许可以保留现有的网络交换机，但这大约就是您所要保留的全部。显然，这种方法的成本很高，但它具有一定的优势。与旧硬件相比，新硬件的运行通常要好得 多，因为磁盘容量和速度都得到了增长。因此，仅仅使用新硬件，您的性能就会得到迅速提高。您甚至可能会租用设备，而这只是为了保持领先地位。
硬件 到位后，您可以在此安装上创建新的虚拟SQL Server，将生产数据库复制过来，然后考察新系统的性能，从而在移交日期之前留有充足的时间来解决程序错误。但别忘了编写脚本，从现有服务器中退 出。（万一发生灾难性故障，最好访问support.microsoft.com/kb/246133来更新登录构建脚本。）
为了将停机时间减到最少，您很可能必须使用日志传送，除非您的数据库相当小并且在一段时间内没有用户建立连接。在移交之前，您都可以正确执行日志传 送。接着，删除这些用户，剪切并传送最后的日志，然后指向新实例上的应用程序。（有关感兴趣的日志传送替代方法，请参阅下面的数据库镜像部分。）如果使用 DNS别名，您甚至可能不需要指向新实例上的应用程序，而是只需更新 DNS 别名。这种方法的优点是，如果您的迁移只进行了一部分，但必须要回退到原始状态，那您至少还有原始文件。
您还可以采用一种成本较低的方案，但需要您做更多的预先规划。一个群集可以支持多个SQL Server实例，但每个实例必须有其自己的磁盘资源。因此，在划分SAN时，请留出一个LUN，以备将来升级。要执行升级，请在此磁盘资源上安装 SQL Server 二进制文件。您可以演习一下该系统。当您准备好后，关闭当前SQL Server，将磁盘资源从旧的 SQL Server组中移出，更新依赖关系，然后使新SQL Server实例在线。连接旧实例中的数据库，然后启动并运行。（您已提早备份了所有数据，对吗？）
这就是成本较低的方法，实行这个方法需要承担 一些风险。如果出现故障，您无法将数据库与新实例分离开来并放回原来位置。您的操作已简化为从备份恢复 - 这意味着需要很长的停机时间。
还有一种方法是将两个SQL Server实例都放在您的SAN中，前提是您有足够的磁盘空间。将生产备份（和日志传送）恢复为新实例，然后按前面介绍的步骤继续进行。但现在您有退路 了。而且，一旦完成迁移，您还可以释放旧实例占用的SAN资源。您只需增加额外的磁盘。
负载平衡
让我们首先揭穿这样一个常见误解。MSCS群集是用于获得高可用性的，而非用于实现负载平衡。此外，SQL Server没有任何内置的、自动负载平衡功能。您必须通过应用程序的物理设计来实现负载平衡。这意味着什么？
随着表的逐渐增长，您可能会预料到性能会降低，特别是在涉及到表扫描操作时。当行数达到数百万或数十亿时，传统的解决方案会使用已分区视图，这种视 图由若干具有相同结构、使用 union ALL 挂接在一起的表组成。此外，还会在适当位置放置 CHECK 约束来区分这些成员表，而这会阻止跨已分区视图复制数据。如果在 CHECK 约束中使用的列也是主键的一部分，则该视图是可更新的。
如果成员表在其自己的文件组中，则如果这些文件组中的文件分别位于不同的物理驱动器上，那么您会获得更佳的磁盘性能。这些表甚至也可以位于不同的数 据库中。但是，在SQL Server 2005 中，只要所有数据均在同一个数据库中，您就可以使用表分区，而表分区实现起来就容易得多了。
但是，假设您已经尽可能地利用了表分区或（本地）已分区视图，但性能仍然很低。如果您拥有SQL Server 2000 或SQL Server 2005，就可以利用分布式已分区视图了。主要差别在于，成员表可以位于不同的 SQL Server 实例上，而且这些实例可以安装在 N+1 群集上。为什么鼓励您这样做？如果已分区视图中的任何一个成员表转入离线状态，则整个视图也将转入离线状态。使这些成员成为群集的一部分可以为您提供支持 性能和实现负载平衡所需的可靠性。
您真的需要群集吗？
或许您有一些备用服务器无事可做，但这些服务器不在 Windows 目录的群集部分中。如果您在这些服务器可用的情况下，只是为了支持群集就必须出去购置新服务器，那么这是一种浪费可耻的行为。
数据库镜像可能是最适合替代群集的一种方法。镜像涉及到三个元素：存储镜像数据库的实例称为主体；备份服务器称为镜像；如果要实现自动故障转移，还 需要第三台服务器，称为见证方。简而言之，主体上的数据库中的事务会在镜像中再次运行。当主体出现故障时，如果有见证方，数据库会自动故障转移到镜像。您 必须为每个应用程序数据库设置镜像，但不能镜像系统数据库。
镜像是单独的SQL Server 实例，与群集不同的是，镜像可以位于几千英里以外。其高速缓存中填充的是由于从主体中复制事务而发生的更新活动。当然，还可以假设，除了从主体接收镜像事 务之外，镜像上没有其他活动。既然 SQL Server 已经在镜像中运行，所以，故障转移的速度通常要比在群集中快。由于至少有部分高速缓存已准备好，所以，初始性能并不像在群集方案中那样低。另请注意，当镜 像数据库发生故障转移时，主体和镜像会互换角色。
数据库镜像的不足之处是，需要的总磁盘容量是群集的两倍。如果您想在同步模式下运行且不想丢失任何数据，那么您还会需要更多的 CPU 处理能力。正如我所说的，要想实现高可用性，需要花费很高的成本。
组合方法
由于镜像与主体之间的距离可以相当遥远，所以对于灾难恢复 (DR) 计划来说，选择镜像是非常明智的。群集是您的第一道防线。但是，如果您要同时利用群集和镜像，那会出现什么情况呢？在群集故障转移中，如果您的镜像配置中 有见证方，则当群集 SQL Server 转入在线状态时，镜像会成为主体。但是，请注意，从新主体回到（群集的）新镜像的故障转移不是自动进行的。因此，当与群集结合使用时，最好不要对您的镜像 数据库启用自动故障转移。
灾难恢复并不是您使用镜像的唯一原因；当您必须向主体应用服务包或修补程序时，镜像也是非常有用的。在这种情况下，您可以手动故障转移到镜像。在应 用服务包或修补程序时，旧的主体服务器暂时处于离线状态，在新主体上发生的已提交事务会排队等候，等待被发送回新镜像（旧主体）。在完成服务包或修补程序 的安装之后将会进行同步。最终，这两台服务器将完全处于同步状态。现在您便可以在主体和镜像之间转换角色了。故障转移与恢复只需要几秒钟的停机时间。您可 以使用这种方法将 SQL Server 迁移到另一台计算机。只是不能实现故障恢复。
虚拟服务器添加灵活性
虚拟化允许您在一台物理服务器上并行运行一个或多个操作系统。虚拟化软件为群集概念添加了另外一层功能，因为您可以将软件加入群集。因此，如果主机 正在其上运行的服务器出现故障，则主机及其来宾 OS 会故障转移到备份节点。这可能是迁移来宾服务器的最简便方法。补充一点，来宾 OS 不必具有群集功能。因此，您可以在运行于某群集中的 Microsoft Virtual Server 2005 之上的来宾 Windows Server 2003 内部运行 SQL Server Workgroup Edition。实质上，您会间接拥有群集 Workgroup Edition
在控制之下
如果您在负责 SQL Server 实现，您需要确信您的服务器始终处于可用状态。服务器群集会帮助确保您的服务器始终可用。本文提供了一些来之不易的技巧，以帮助您入门。您可以在“群集资 源”边栏中找到更多有用信息。
