服务器群集允许您连接许多物理服务器（或节点），用作彼此的故障转移合作伙伴。群集所提供的冗余性为您的关键操作带来了更多的正常运行时间。在使用SQL Server的13年期间，我实现了许多群集，每个群集都有其自己的一系列问题。这些经历使我积累了许多技巧，它们会帮助您轻松成功地实现群集。

　　服务器群集利用了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资源。您只需增加额外的磁盘。