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

轉自：http://database.ctocio.com.cn/200/8863200_1.shtml

伺服器叢集利用了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資源。您只需增加額外的磁碟。

　　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

　　在控制之下

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