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