服務器群集利用了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 實現，您需要確信您的服務器始終處于可用狀態。服務器群集會幫助確保您的服務器始終可用。本文提供了一些來之不易的技巧，以幫助您入門。您可以在“群集資 源”邊欄中找到更多有用信息。