關於 SQL Server 群集的幾個關鍵技巧

概覽:
在群集上運行 SQL Server 硬體和軟體要求 將一個節點加入群集 節省成本的方法

伺服器叢集允許您串連許多物理伺服器（或節點），用作彼此的容錯移轉夥伴。群集所提供的冗餘性為您的關鍵操作帶來了更多的正常運行

時間。在使用 SQL Server 的 13 年期間，我實現了許多群集，每個群集都有其自己的一系列問題。這些經曆使我積累了許多技巧，它們會協助您輕鬆成功地實現群集。

伺服器叢集利用了 Windows Server
^{系列的 Enterprise Edition 中的內建群集功能。實際上，對於群集，使用 Windows Server 2003 要比
Windows 2000 Advanced Server
好得多。要想使您從群集中獲得的好處最大化，您需要合適的硬體，而這涉及到一些費用。只是利用共用磁碟將幾個伺服器拼湊在一起是不夠的，您不能依賴這樣的
事實，即單獨的硬體組件可能存在於 Windows 目錄（以前稱為硬體相容性列表）中。系統作為整體必須存在於 Windows 目錄中。但不要擔心，還有其他一些經過認可的、低成本群集解決方案可用。圖 1 顯示了一種典型的群集配置。}

Figure 1 A typical cluster (單擊該映像獲得較小視圖)
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 資源。您只需增加額外的磁碟。

Server Load Balancer

讓我們首先揭穿這樣一個常見誤解。MSCS 群集是用於獲得高可用性的，而非用於實現Server Load Balancer。此外，SQL Server 沒有任何內建的、自動Server Load Balancer功能。您必須通過應用程式的實體設計來實現Server Load Balancer。這意味著什嗎？

隨
著表的逐漸增長，您可能會預料到效能會降低，特別是在涉及到表掃描操作時。當行數達到數百萬或數十億時，傳統的解決方案會使用已分區視圖，這種視圖由若干
具有相同結構、使用 UNION ALL 掛接在一起的表組成。此外，還會在適當位置放置 CHECK
約束來區分這些成員表，而這會阻止跨已分區視圖複製資料。如果在 CHECK 條件約束中使用的列也是主鍵的一部分，則該視圖是可更新的。

如
果成員表在其自己的檔案組中，則如果這些檔案組中的檔案分別位於不同的物理磁碟機上，那麼您會獲得更佳的磁碟效能。這些表甚至也可以位於不同的資料庫中。
但是，在 SQL Server 2005 中，只要所有資料均在同一個資料庫中，您就可以使用表分區，而表分區實現起來就容易得多了。

但
是，假設您已經儘可能地利用了表分區或（本地）已分區視圖，但效能仍然很低。如果您擁有 SQL Server 2000 或 SQL Server
2005，就可以利用分布式已分區視圖了。主要差別在於，成員表可以位於不同的 SQL Server 執行個體上，而且這些執行個體可以安裝在 N+1
群集上。為什麼鼓勵您這樣做？如果已分區視圖中的任何一個成員錶轉入離線狀態，則整個視圖也將轉入離線狀態。使這些成員成為群集的一部分可以為您提供支援
效能和實現Server Load Balancer所需的可靠性。

您真的需要群集嗎？

或許您有一些待命伺服器無事可做，但這些伺服器不在 Windows 目錄的群集部分中。如果您在這些伺服器可用的情況下，只是為了支援群集就必須出去購置新伺服器，那麼這是一種浪費可恥的行為。

數
據庫鏡像可能是最適合替代群集的一種方法。鏡像涉及到三個元素：儲存鏡像資料庫的執行個體稱為主體；備份伺服器稱為鏡像；如果要實現自動容錯移轉，還需要第三
台伺服器，稱為見證方。簡而言之，主體上的資料庫中的事務會在鏡像中再次運行。當主體出現故障時，如果有見證方，資料庫會自動容錯移轉到鏡像。您必須為每
個應用程式資料庫設定鏡像，但不能鏡像系統資料庫。

鏡像是單獨的 SQL Server
執行個體，與群集不同的是，鏡像可以位於幾千英裡以外。其快取中填充的是由於從主體中複製事務而發生的更新活動。當然，還可以假設，除了從主體接收鏡像事
務之外，鏡像上沒有其他活動。既然 SQL Server
已經在鏡像中運行，所以，容錯移轉的速度通常要比在群集中快。由於至少有部分快取已準備好，所以，初始效能並不像在群集方案中那樣低。另請注意，當鏡
像資料庫發生容錯移轉時，主體和鏡像會互換角色。

資料庫鏡像的不足之處是，需要的總磁碟容量是群集的兩倍。如果您想在同步模式下運行且不想丟失任何資料，那麼您還會需要更多的 CPU 處理能力。正如我所說的，要想實現高可用性，需要花費很高的成本。

組合方法

由
於鏡像與主體之間的距離可以相當遙遠，所以對於災難恢複 (DR)
計劃來說，選擇鏡像是非常明智的。群集是您的第一道防線。但是，如果您要同時利用群集和鏡像，那會出現什麼情況呢？在群集容錯移轉中，如果您的鏡像配置中
有見證方，則當群集 SQL Server
轉入線上狀態時，鏡像會成為主體。但是，請注意，從新主體回到（群集的）新鏡像的容錯移轉不是自動進行的。因此，當與群集結合使用時，最好不要對您的鏡像
資料庫啟用自動容錯移轉。

災難恢複並不是您使用鏡像的唯一原因；當您必須向主體應用服務包或Hotfix時，
鏡像也是非常有用的。在這種情況下，您可以手動容錯移轉到鏡像。在應用服務包或Hotfix時，舊的主體伺服器暫時處於離線狀態，在新主體上發生的已提交事務
會排隊等候，等待被發送回新鏡像（舊主體）。在完成服務包或Hotfix的安裝之後將會進行同步。最終，這兩台伺服器將完全處於同步狀態。現在您便可以在主體
和鏡像之間轉換角色了。容錯移轉與恢複只需要幾秒鐘的停機時間。您可以使用這種方法將 SQL Server
遷移到另一台電腦。只是不能實現故障恢複。

虛擬伺服器添加靈活性

虛
擬化允許您在一台物理伺服器上並行運行一個或多個作業系統。虛擬化軟體為群集概念添加了另外一層功能，因為您可以將軟體加入群集。因此，如果主機正在其上
啟動並執行伺服器出現故障，則主機及其客體 OS 會容錯移轉到備份節點。這可能是遷移來賓伺服器的最簡便方法。補充一點，客體 OS
不必具有群集功能。因此，您可以在運行於某群集中的 Microsoft Virtual Server 2005 之上的來賓 Windows
Server 2003 內部運行 SQL Server Workgroup Edition。實質上，您會間接擁有群集 Workgroup
Edition（請參見圖 2）。

Figure 2 Using a virtual server (單擊該映像獲得較小視圖)
Figure 2 Using a virtual server (單擊該映像獲得較大視圖)

在控制之下

如果您在負責 SQL Server 實現，您需要確信您的伺服器始終處於可用狀態。伺服器叢集會協助確保您的伺服器始終可用。本文提供了一些來之不易的技巧，以協助您入門。您可以在“叢集資源”側邊欄中找到更多有用資訊。

Tom Moreau 博士曾
獲得理學學士和博士學位，擁有 MCSE 和 MCDBA 認證，他是一位自由顧問，還是 SQL Server
資料庫管理、設計和實現方面的專家，現居住於多倫多地區。Tom 從 1993 年開始就一直使用 SQL Server，並從 2001 年開始擔任
MVP。他曾撰寫過 100 多篇文章，還與人合著過有關 SQL Server 的書籍。感謝 SQL Server MVP Geoff
Hiten 提供的有用資訊。