服務器群集允許您連接許多物理服務器（或節點），用作彼此的故障轉移合作伙伴。群集所提供的冗余性為您的關鍵操作帶來了更多的正常運行時間。在使用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)群集中。您只需為腳本提供節點名稱，然後由腳本處理其余工作。在緊急情況下，自動化確實是您的朋友。
