SQL Server群集的幾個關(guān)鍵技巧
服務(wù)器群集利用了Windows Server系列的Enterprise Edition中的內(nèi)置群集功能。實際上，對于群集，使用Windows Server 2003要比Windows 2000 Advanced Server 好得多。要想使您從群集中獲得的好處最大化，您需要合適的硬件，而這涉及到一些費用。只是利用共享磁盤將幾個服務(wù)器拼湊在一起是不夠的，您不能依賴這樣的事實，即單獨的硬件組件可能存在于 Windows目錄（以前稱為硬件兼容性列表）中。系統(tǒng)作為整體必須存在于Windows目錄中。但不要擔心，還有其他一些經(jīng)過認可的、低成本群集解決方案可用。圖 1 顯示了一種典型的群集配置。
Figure 1 A typical cluster
當然，群集比硬件需要更多的條件 - 您還需要選擇合適版本的SQL Server 2005。Enterprise Edition 支持群集功能以及其他一些有用功能，如能夠利用更多CPU、分布式和可更新已分區(qū)視圖、內(nèi)置日志傳送、自動使用索引視圖。如果已經(jīng)擁有Enterprise Edition 許可證，則應(yīng)考慮群集：您是否有構(gòu)成傳統(tǒng)群集所必需的兩到八臺服務(wù)器（我們馬上會討論單節(jié)點群集）。如果擁有SQL Server 2005 Standard Edition，則可以安裝兩節(jié)點群集。
Windows Server 2003 Enterprise Edition和Datacenter Edition 附帶內(nèi)置群集功能。安裝群集只需運行群集管理器。您可以同時添加所有節(jié)點，也可以每次添加一個節(jié)點。類似地，在安裝 SQL Server 時，您可以選擇安裝在單獨的非群集服務(wù)器上，也可以選擇將虛擬實例安裝在群集上。如果選擇安裝虛擬實例，可以安裝在群集的所有節(jié)點上，也可以安裝在一部分節(jié)點上，甚至僅安裝在一個節(jié)點上。
最后，為了達到群集的真正目標，即高可用性，需要為您提供合格的人員以及在出現(xiàn)問題時所遵循的預(yù)先演練好的過程。盡管群集是防止出現(xiàn)硬件故障的有力保障，但它無法阻止用戶出錯。例如，午夜時分，一位睡眼朦朧的DBA刪除了一份重要的表。
單節(jié)點群集
盡管您在此刻只擁有一臺服務(wù)器，也可以考慮創(chuàng)建一個單節(jié)點群集。如果這樣做，您可以在以后選擇升級到群集，從而無需重建。但是，請務(wù)必確保您所選擇的硬件位于 Windows目錄的群集部分。
這樣做不僅僅只是為了實現(xiàn)能夠在以后添加節(jié)點這個高可用性。如果您發(fā)現(xiàn)您的服務(wù)器恰好沒有必需的功能，那么您猜會發(fā)生什么事情。這意味著您需要遷移 - 既費時又費力。如果您有一個單節(jié)點群集，則遷移過程就會變得很容易，停機時間也少得多。您需要向群集中添加新節(jié)點，將SQL Server二進制文件和服務(wù)包添加到該新節(jié)點，然后故障轉(zhuǎn)移到該新節(jié)點。接下來，添加任何服務(wù)包之后的更新程序，最后刪除舊節(jié)點。停機時間只是故障轉(zhuǎn)移時間與添加更新程序（如果有）時間之和。
添加節(jié)點
由于一個群集中的所有節(jié)點必須相同，您應(yīng)該立刻（而不是稍后）采取行動，獲得另外的節(jié)點。如果等待時間太長，節(jié)點可能會退出生產(chǎn)。曾經(jīng)就有這樣一個項目，我不得不在 SQL Server 2000群集中重建節(jié)點。我請操作系統(tǒng)/網(wǎng)絡(luò)管理員處理了基本的計算機構(gòu)建，然后我投入工作，將構(gòu)建的計算機添加回群集并準備將其用作 SQL Server 節(jié)點。一切都進行得很順利，直到我需要故障轉(zhuǎn)移到新節(jié)點。但令我非常沮喪的是，它卻直接執(zhí)行了故障恢復(fù)。長話短說，盡管我已經(jīng)準備了有關(guān)如何構(gòu)建新群集的詳細文檔，其中包括如何將群集服務(wù)帳戶和SQL Server服務(wù)帳戶添加到這兩個節(jié)點，但顯然管理員并沒有遵循該文檔。管理員沒有將這些服務(wù)帳戶添加到重建節(jié)點，所以，他們在重建之前所擁有的權(quán)限便不再存在。
我花了很長時間才追捕到這個原因。有一天，我突然想到查看一下本地組成員身份。當我添加了這兩個帳戶之后，故障轉(zhuǎn)移便順利進行了。于是我開始思考。雖然您只是偶爾才需要重建節(jié)點，但如果需要重建節(jié)點，那便是在緊急時刻。盡管我已經(jīng)提供了文檔，但人們并不利用它。只需編寫一個簡短的腳本來添加這兩個帳戶及進行任何其他必要的自定義，就能使安全部分自動完成。在SQL Server 2005中，事情得到了改善。安裝程序要求您為SQL Server服務(wù)帳戶設(shè)置域級組。
當然，這讓我想得更多。您可以創(chuàng)建幾個腳本，它們調(diào)用CLUSTER.EXE將節(jié)點添加到Microsoft Cluster Server (MSCS)群集中。您只需為腳本提供節(jié)點名稱，然后由腳本處理其余工作。在緊急情況下，自動化確實是您的朋友。
N+1群集
有時，向群集添加節(jié)點的原因不是您要更換節(jié)點。您可以將更多的SQL Server實例添加到群集中且每個實例都需要不同的磁盤資源。雖然多個實例可以在一個節(jié)點上運行，但這些實例會共享CPU和RAM，因此可能會導(dǎo)致性能降低。理想情況下，在一個節(jié)點上僅運行一個實例。但在發(fā)生故障轉(zhuǎn)移時如何能確保做到這一點呢？很簡單：答案是，有一個節(jié)點上不運行任何服務(wù)，而其他節(jié)點則是每個節(jié)點上運行一個SQL Server實例。實際上，這就是N+1群集的定義： N+1個節(jié)點上運行N個實例。額外的節(jié)點是備用節(jié)點。
升級SQL Server
升級SQL Server的群集實例不是因為膽小：構(gòu)建群集只為一個原因 - 您需要正常運行時間。但SQL Server 2005提供了許多您想利用的增強功能。所以，如果您準備升級，無需太多停機時間便可以繼續(xù)進行。
您會選擇哪種方案？我們首先看一看成本最高的解決方案：創(chuàng)建整個新群集。這意味著要創(chuàng)建若干新服務(wù)器，或許還要創(chuàng)建新的存儲區(qū)域網(wǎng)絡(luò)(SAN)。您或許可以保留現(xiàn)有的網(wǎng)絡(luò)交換機，但這大約就是您所要保留的全部。顯然，這種方法的成本很高，但它具有一定的優(yōu)勢。與舊硬件相比，新硬件的運行通常要好得多，因為磁盤容量和速度都得到了增長。因此，僅僅使用新硬件，您的性能就會得到迅速提高。您甚至可能會租用設(shè)備，而這只是為了保持領(lǐng)先地位。
硬件到位后，您可以在此安裝上創(chuàng)建新的虛擬SQL Server，將生產(chǎn)數(shù)據(jù)庫復(fù)制過來，然后考察新系統(tǒng)的性能，從而在移交日期之前留有充足的時間來解決程序錯誤。但別忘了編寫腳本，從現(xiàn)有服務(wù)器中退出。（萬一發(fā)生災(zāi)難性故障，最好訪問support.microsoft.com/kb/246133來更新登錄構(gòu)建腳本。）
為了將停機時間減到最少，您很可能必須使用日志傳送，除非您的數(shù)據(jù)庫相當小并且在一段時間內(nèi)沒有用戶建立連接。在移交之前，您都可以正確執(zhí)行日志傳送。接著，刪除這些用戶，剪切并傳送最后的日志，然后指向新實例上的應(yīng)用程序。（有關(guān)感興趣的日志傳送替代方法，請參閱下面的數(shù)據(jù)庫鏡像部分。）如果使用DNS別名，您甚至可能不需要指向新實例上的應(yīng)用程序，而是只需更新 DNS 別名。這種方法的優(yōu)點是，如果您的遷移只進行了一部分，但必須要回退到原始狀態(tài)，那您至少還有原始文件。
您還可以采用一種成本較低的方案，但需要您做更多的預(yù)先規(guī)劃。一個群集可以支持多個SQL Server實例，但每個實例必須有其自己的磁盤資源。因此，在劃分SAN時，請留出一個LUN，以備將來升級。要執(zhí)行升級，請在此磁盤資源上安裝 SQL Server 二進制文件。您可以演習(xí)一下該系統(tǒng)。當您準備好后，關(guān)閉當前SQL Server，將磁盤資源從舊的 SQL Server組中移出，更新依賴關(guān)系，然后使新SQL Server實例在線。連接舊實例中的數(shù)據(jù)庫，然后啟動并運行。（您已提早備份了所有數(shù)據(jù)，對嗎？）
這就是成本較低的方法，實行這個方法需要承擔一些風(fēng)險。如果出現(xiàn)故障，您無法將數(shù)據(jù)庫與新實例分離開來并放回原來位置。您的操作已簡化為從備份恢復(fù) - 這意味著需要很長的停機時間。
還有一種方法是將兩個SQL Server實例都放在您的SAN中，前提是您有足夠的磁盤空間。將生產(chǎn)備份（和日志傳送）恢復(fù)為新實例，然后按前面介紹的步驟繼續(xù)進行。但現(xiàn)在您有退路了。而且，一旦完成遷移，您還可以釋放舊實例占用的SAN資源。您只需增加額外的磁盤。
負載平衡
讓我們首先揭穿這樣一個常見誤解。MSCS群集是用于獲得高可用性的，而非用于實現(xiàn)負載平衡。此外，SQL Server沒有任何內(nèi)置的、自動負載平衡功能。您必須通過應(yīng)用程序的物理設(shè)計來實現(xiàn)負載平衡。這意味著什么？
隨著表的逐漸增長，您可能會預(yù)料到性能會降低，特別是在涉及到表掃描操作時。當行數(shù)達到數(shù)百萬或數(shù)十億時，傳統(tǒng)的解決方案會使用已分區(qū)視圖，這種視圖由若干具有相同結(jié)構(gòu)、使用 union ALL 掛接在一起的表組成。此外，還會在適當位置放置 CHECK 約束來區(qū)分這些成員表，而這會阻止跨已分區(qū)視圖復(fù)制數(shù)據(jù)。如果在 CHECK 約束中使用的列也是主鍵的一部分，則該視圖是可更新的。
如果成員表在其自己的文件組中，則如果這些文件組中的文件分別位于不同的物理驅(qū)動器上，那么您會獲得更佳的磁盤性能。這些表甚至也可以位于不同的數(shù)據(jù)庫中。但是，在SQL Server 2005 中，只要所有數(shù)據(jù)均在同一個數(shù)據(jù)庫中，您就可以使用表分區(qū)，而表分區(qū)實現(xiàn)起來就容易得多了。
但是，假設(shè)您已經(jīng)盡可能地利用了表分區(qū)或（本地）已分區(qū)視圖，但性能仍然很低。如果您擁有SQL Server 2000 或SQL Server 2005，就可以利用分布式已分區(qū)視圖了。主要差別在于，成員表可以位于不同的 SQL Server 實例上，而且這些實例可以安裝在 N+1 群集上。為什么鼓勵您這樣做？如果已分區(qū)視圖中的任何一個成員表轉(zhuǎn)入離線狀態(tài)，則整個視圖也將轉(zhuǎn)入離線狀態(tài)。使這些成員成為群集的一部分可以為您提供支持性能和實現(xiàn)負載平衡所需的可靠性。
您真的需要群集嗎？
或許您有一些備用服務(wù)器無事可做，但這些服務(wù)器不在 Windows 目錄的群集部分中。如果您在這些服務(wù)器可用的情況下，只是為了支持群集就必須出去購置新服務(wù)器，那么這是一種浪費可恥的行為。
數(shù)據(jù)庫鏡像可能是最適合替代群集的一種方法。鏡像涉及到三個元素：存儲鏡像數(shù)據(jù)庫的實例稱為主體；備份服務(wù)器稱為鏡像；如果要實現(xiàn)自動故障轉(zhuǎn)移，還需要第三臺服務(wù)器，稱為見證方。簡而言之，主體上的數(shù)據(jù)庫中的事務(wù)會在鏡像中再次運行。當主體出現(xiàn)故障時，如果有見證方，數(shù)據(jù)庫會自動故障轉(zhuǎn)移到鏡像。您必須為每個應(yīng)用程序數(shù)據(jù)庫設(shè)置鏡像，但不能鏡像系統(tǒng)數(shù)據(jù)庫。
鏡像是單獨的SQL Server 實例，與群集不同的是，鏡像可以位于幾千英里以外。其高速緩存中填充的是由于從主體中復(fù)制事務(wù)而發(fā)生的更新活動。當然，還可以假設(shè)，除了從主體接收鏡像事務(wù)之外，鏡像上沒有其他活動。既然 SQL Server 已經(jīng)在鏡像中運行，所以，故障轉(zhuǎn)移的速度通常要比在群集中快。由于至少有部分高速緩存已準備好，所以，初始性能并不像在群集方案中那樣低。另請注意，當鏡像數(shù)據(jù)庫發(fā)生故障轉(zhuǎn)移時，主體和鏡像會互換角色。
數(shù)據(jù)庫鏡像的不足之處是，需要的總磁盤容量是群集的兩倍。如果您想在同步模式下運行且不想丟失任何數(shù)據(jù)，那么您還會需要更多的 CPU 處理能力。正如我所說的，要想實現(xiàn)高可用性，需要花費很高的成本。
組合方法
由于鏡像與主體之間的距離可以相當遙遠，所以對于災(zāi)難恢復(fù) (DR) 計劃來說，選擇鏡像是非常明智的。群集是您的第一道防線。但是，如果您要同時利用群集和鏡像，那會出現(xiàn)什么情況呢？在群集故障轉(zhuǎn)移中，如果您的鏡像配置中有見證方，則當群集 SQL Server 轉(zhuǎn)入在線狀態(tài)時，鏡像會成為主體。但是，請注意，從新主體回到（群集的）新鏡像的故障轉(zhuǎn)移不是自動進行的。因此，當與群集結(jié)合使用時，最好不要對您的鏡像數(shù)據(jù)庫啟用自動故障轉(zhuǎn)移。
災(zāi)難恢復(fù)并不是您使用鏡像的唯一原因；當您必須向主體應(yīng)用服務(wù)包或修補程序時，鏡像也是非常有用的。在這種情況下，您可以手動故障轉(zhuǎn)移到鏡像。在應(yīng)用服務(wù)包或修補程序時，舊的主體服務(wù)器暫時處于離線狀態(tài)，在新主體上發(fā)生的已提交事務(wù)會排隊等候，等待被發(fā)送回新鏡像（舊主體）。在完成服務(wù)包或修補程序的安裝之后將會進行同步。最終，這兩臺服務(wù)器將完全處于同步狀態(tài)。現(xiàn)在您便可以在主體和鏡像之間轉(zhuǎn)換角色了。故障轉(zhuǎn)移與恢復(fù)只需要幾秒鐘的停機時間。您可以使用這種方法將 SQL Server 遷移到另一臺計算機。只是不能實現(xiàn)故障恢復(fù)。
虛擬服務(wù)器添加靈活性
虛擬化允許您在一臺物理服務(wù)器上并行運行一個或多個操作系統(tǒng)。虛擬化軟件為群集概念添加了另外一層功能，因為您可以將軟件加入群集。因此，如果主機正在其上運行的服務(wù)器出現(xiàn)故障，則主機及其來賓 OS 會故障轉(zhuǎn)移到備份節(jié)點。這可能是遷移來賓服務(wù)器的最簡便方法。補充一點，來賓 OS 不必具有群集功能。因此，您可以在運行于某群集中的 Microsoft Virtual Server 2005 之上的來賓 Windows Server 2003 內(nèi)部運行 SQL Server Workgroup Edition。實質(zhì)上，您會間接擁有群集 Workgroup Edition
在控制之下
如果您在負責(zé) SQL Server 實現(xiàn)，您需要確信您的服務(wù)器始終處于可用狀態(tài)。服務(wù)器群集會幫助確保您的服務(wù)器始終可用。本文提供了一些來之不易的技巧，以幫助您入門。您可以在“群集資源”邊欄中找到更多有用信息。
【編輯推薦】
