《MS SQL Server 2000管理員手冊》系列——12. Microsoft SQL Server 與 Microsoft Cluster Services

12. Microsoft SQL Server 與 Microsoft Cluster Services
故障的類型
MSCS 概觀
叢集系統的範例
SQL Server 叢集設定
超越MSCS
本章總結
在最近幾年裡，Microsoft SQL Server 系統已經從桌上型系統與工作群組中轉移為企業後援系統。為了應付商務運作，這些系統變得更為龐大也更為重要，換言之，它們必須更穩定、更易於遠端管理，以及具有更佳的容錯性。為了滿足這些需求，Microsoft 已經然投注了相當多的時間與精力來減少軟體的錯誤並改進系統的支援性。Microsoft 也改善了管理工具、遠端管理能力，並且發展了像是 Microsoft Cluster Services（MSCS）這樣的新技術。 叢集 （Cluster）指的是一組在故障發生時可互為備援系統的電腦。在本章裡，您將學習到 MSCS 如何運作、如何設定，以及如何規劃才能從災難中恢複舊觀。單靠 MSCS 無法讓您的系統容錯；您必須配合謹慎的規劃，才能讓您的系統具有從錯誤中回複的能力。
________________________________________
說明
MSCS 包含在 Microsoft Windows 2000 Advanced Server、Microsoft Windows 2000 Datacenter Server，以及Microsoft Windows NT 4.0 Enterprise Edition之中。
________________________________________
故障的類型
　
作為一個資料庫管理者的主要任務是維護資料庫，並且讓資料庫能夠在指定的時間周期內正常運作，這些通常在服務涵蓋範圍同意書中都會載明。服務涵蓋範圍同意書可能也會指定系統必須提供的最佳執行時間長、執行速率以及發生錯誤時要在多短的時間內複原。使用 MSCS 可以增加最長執行時間並減少複原所需要的時間。儘管伺服器硬體、Windows 2000、Windows NT 以及 SQL Server 一般說來都相當穩定可靠，但是部分組件有時仍會有故障的狀況。事實上，一個複雜的電腦系統可能會發生下列幾種不同類型的故障：
•   硬碟故障 雖然磁碟技術已經有改進，但是硬碟機仍然是一種機械裝置，並且也會磨損。硬碟是最常發生故障問題的組件之一。
　
•   硬體組件故障 硬體組件有可能是導因於組件的磨損或破壞，造成這類問題的元兇則是系統中不可避免的高溫。即便是最佳製程的電腦裝置也有可能因此故障。
　
•   軟體組件故障 有些軟體的瑕疵要在特定的情況下才會被發現。在一些特定狀況發現問題之前，系統可能已經執行了好幾個月或好幾年。此外，新增應用程式到一個穩定的環境中也可能修改關鍵的函式庫或檔案，因而造成了故障問題。
　
•   外部故障 系統也可能因為一些外部因素而出現錯誤，比方電力供應突然中斷。您的系統在這類錯誤中是否有辦法起死回生，要看您是否有使用不斷電系統（Uninterruptible Power Supply，UPS）或其它剩餘的電源。
　
•   人為錯誤 叢集通常無法保護因為人為錯誤而故障的系統。這些人為錯誤包括意外刪除了一個資料表或刪除了 Windows NT 檔案系統分割區。
　
錯誤是不可避免的，如何為這些錯誤做最好的準備，正是我們在本章中要討論的焦點。
MSCS 概觀
　
MSCS 是 Microsoft Windows 2000 Advanced Server、Microsoft Windows 2000 Datacenter Server 以及 Microsoft Windows NT 4.0 Enterprise Edition的內建服務。MSCS 是用來建構一個伺服器叢集；如之前所述，伺服器叢集是指獨立的伺服器集合為一個群組，並且共同運作起來猶如單一的系統。叢集的目的是為了在錯誤事件或預期可能的中斷髮生時，用戶端仍然可以繼續存取應用程式及其它資源。如果叢集中某個伺服器因為任何理由而無法使用，資源與應用程式將移轉到叢集中的其它節點。
當我們談到叢集系統時，多半使用 高可用性 （high availability）這個字眼，而不是 容錯 （fault tolerant）。傳統上， 容錯 這個名詞比較適用於特定的系統，此系統能夠提供極高階的備援性和複原性。這類系統通常使用極為專業的軟體，讓系統能從任何單一硬體或軟體錯誤中瞬間複原。比起無法容錯的系統，容錯系統可說相當昂貴。相對的，一個提供高可用性的叢集系統，其成本並不像容錯系統那麼驚人。叢集系統一般是由標準伺服器硬體與作業系統中的叢集感知軟體來建構。當系統的可用性需求日益增加，叢集之中也可以容易的加入系統為一個節點。儘管一個叢集系統無法保證必定可以進行連續性的操作，但是就大多數具有關鍵任務性質的應用程式而言，叢集系統確實增進了相當的可用性。
MSCS 具備下列的優點：
•   高可用性 系統資源（例如磁碟或 IP 位址）會自動地從故障的伺服器移轉至提供服務的伺服器。這種過程稱作 錯誤移轉 （Failover）。當叢集中的某個應用程式故障時，MSCS 會自動地在另一個提供服務的伺服器中啟動該應用程式，或是將故障伺服器的工作分散給其它的節點。錯誤移轉的過程非常快速，使用者察覺到伺服器的服務暫停將極為短暫。
　
•   容錯回複 當故障的伺服器修複並且重回線上時，MSCS 會自動地重新平衡叢集中的工作負載。這被稱為 錯誤回複 （Failback）。
　
•   可管理性  叢集系統管理員 軟體允許您將整個叢集視同一個單一系統般來進行管理。您可以在 叢集系統管理員 中利用拖曳叢集對象的方式將應用程式簡單的搬移到叢集裡的不同伺服器之中。您也可以利用同樣的方法來搬移資料。這種「拖曳式」的操作可以用來手動平衡伺服器的負載，或是將某伺服器上的負載去除，以讓該伺服器進行維護的工作。 叢集系統管理員 也可以讓您（從網路上的任何位置）監控叢集、每個節點以及所有資源的狀態。圖12-1顯示了 叢集系統管理員 的視窗。
　
•   可延展性 當系統的需求和負載增加時，您可以重新設定 MSCS來支援這些需求。如果整體的負載超過叢集的容量，您也可以在叢集中新增節點。

　
 
圖12-1 Windows 2000 叢集系統管理員
基本概念
　
MSCS 之所以能減少系統停工的時間，是因為 MSCS 能在多個系統之間提供錯誤移轉的功能，要達成錯誤移轉的功能，您必須讓伺服器互連，並且使用 共用磁碟系統 （Shared Disk System），12-2所示。在達成伺服器互連繫統方面，您可以使用任何一種高速聯機系統，例如乙太網路絡或是其它的網路硬體。伺服器互連繫統扮演著伺服器之間的通訊頻道，這個通訊頻道是為了來回傳遞叢集目前的狀態資訊，以及組態資訊。共用磁碟系統則可以讓叢集中所有伺服器的資料庫和資料檔案以相等地方式被存取。共用磁碟系統可以是 SCSI、光纖通道的 SCSI，或是其它專屬的硬體。至於共用的磁碟可以是一顆單獨的磁碟或是 RAID 系統（RAID 系統已在 第5章 討論過）。
________________________________________
注意
如果共用磁碟系統沒有容錯，並且您的磁碟子系統發生故障，MSCS 會錯誤移轉至其它的伺服器，但是新的伺服器仍然會使用已經出錯的磁碟子系統，因此您的系統仍然會處於故障的狀態。由於這類機械裝置容易發生故障的問題，因此一定要使用 RAID 來保護您的磁碟。
________________________________________
一旦您的系統被設定為叢集伺服器的一員，它就會從傳統的伺服器轉變為虛擬伺服器。 虛擬伺服器 （Virtual Server）看起來像是普通的伺服器，但是系統的實體辨識方式已經抽象化了。因為組成虛擬伺服器的電腦硬體也許不斷地改變，在任何時刻使用者都無法確知目前應用程式實際上是在哪一個伺服器中執行。因此，虛擬伺服器為使用者的應用程式提供服務，但是指的卻不是某一組特定的硬體。

　
 
圖12-2 Windows 2000 叢集
虛擬伺服器存在於網路上，並且也分配了一個 TCP/IP 的 IP 位址。這個 IP 位址會在叢集系統之間的伺服器互相切換。因此，不論正在執行的硬體是哪一個，使用者都能看到虛擬伺服器。IP 位址實際上是從一個系統遷移到另一個系統，對外部世界來說，就可以維持一個恒定不變的虛擬伺服器。因此如果伺服器出了問題，一個使用特定 IP 位址的應用程式仍然可以繼續存取該 IP 位址，即使該 IP 位址現在代表一個不同的伺服器。虛擬伺服器讓使用者無法發現錯誤移轉操作，因此使用者可以持續工作，而不知道幕後發生了什麼。
叢集組件
　
建立叢集需要幾個組件：叢集管理軟體、伺服器互連繫統，以及共用磁碟系統。這些組件必須加以設定，並且配合叢集感知應用程式使用以建立叢集。在本節中，您會瞭解這些不同的組件，並學習到它們是如何一起工作以建立叢集。在本章稍後 〈SQL Server叢集設定〉 一節中，您會學習到如何設定 SQL Server 叢集。
MSCS叢集管理軟體
　
 叢集管理軟體 （Cluster Management Software）實際上是一組軟體工具，可用來維護、設定及啟動叢集。它是由下列子組件組成，這些子組件一起工作以維持叢集的功能性，並且在必要時執行錯誤移轉的工作：
•   Node Manager 維護叢集系統之間的成員關係，傳送 心跳 （heartbeats）資訊給其它的叢整合員（節點）（心跳指的是周期性送出 我還活著 （I am alive）的訊息。如果一個節點的心跳停止，另一個節點會認為它不再可用，並且會開始接管它的工作。Node Manager 是叢集最關鍵的部分之一，因為它會監控叢集的狀態與叢集的成員，並決定該採取什麼行動。
　
•   Configuration Database Manager 維護叢集的資料庫設定。這個資料庫保留了叢集中所有組件的追蹤資訊，包括了抽象的邏輯元素（例如虛擬伺服器）以及實體元素（例如共用磁碟）。該資料庫類似於 Windows NT/2000 的登入資料庫（Registry）。
　
•   Resource Manager/Failover Manager 啟動與停止 MSCS。Manager/Failover Manager 會從 Resource Monitor 及 Node Manager 中接收各項資訊，例如遺失節點、新增節點等等。
　
•   Event Processor 負責初始化叢集，以及在叢集組件之間路由事件資訊。Event Processor 也負責藉由指示 Node Manager 新增節點以為叢集系統的延伸進行初始化。
　
•   Communications Manager 管理叢集之中各個節點之間的通訊。叢集之中所有的節點都必須不斷地與其它的節點通訊以維持叢集的運作功能。如果各個節點彼此之間失去聯絡，叢集狀態資訊就會遺失，叢集也就無法正常運作。
　
•   Global Update Manager 將叢集狀態語音總機給叢集中所有的節點，其中包含叢集中節點的新增與刪除等等。
　
•   Resource Monitor 監控叢集中各種不同資源的狀態，並且提供統計資料。這個資訊用以決定叢集中是否該採取任何錯誤移轉的動作。
　
•   Time Service 確保叢集中所有的節點都能報告相同的系統時間。如果沒有 Time Service，事件發生的順序就有可能會弄錯，導致系統作出不正確的決定。舉例來說，如果得到較舊版本檔案的節點認為時間是下午2點，而獲得新版本檔案的節點認為此時是上午10點，叢集就會錯誤地認為第一個系統中的檔案是最新的。
　
伺服器互連繫統
　
 伺服器互連繫統 （Server Interconnect）指的是叢集中節點之間的聯機。因為叢集中的節點彼此之間需要透過 Time Service、Node Manager 等等的組件不斷地通訊，因此維護高速的聯機非常重要。
伺服器互連繫統必須是系統之間用以通訊的可靠通道。
伺服器互連經常是執行 TCP/IP 或 NetBIOS 的高速乙太網路絡。這種設定已經十分足夠，但是您或許會想要使用比乙太網路絡更快的專用、高速互連繫統。這種互連裝置可從硬體廠商那裡買到，其中有些廠商也提供像是 共用磁碟 服務這類通訊服務。Microsoft 網站 http://www.microsoft.com/hcl/ 的相容硬體清單提供了一般的伺服器互連裝置的完整清單。
共用磁碟系統
　
叢集建立的另一個關鍵性組件是 共用磁碟 （Shared-Disk）系統。如果多個電腦系統可以存取相同的磁碟系統，當主要節點故障時，便可移轉至其它節點。共用磁碟系統必須允許多個電腦系統可以同等地存取相同的磁碟－換句話說，每台電腦都必須能夠存取所有的磁碟。在 MSCS 目前的版本中，每次只能有一個系統存取磁碟，但是將來的版本將允許多個系統同時存取磁碟。
目前已經有數種共用磁碟系統，而且新的磁碟技術也正不斷地發展中。SCSI磁碟子系統已支援多引發器（multiple initiators）的功能。利用這個功能，您可以在同一個 SCSI 匯流排上擁有多個 SCSI 控制器，如此一來 SCSI 便相當適於叢集使用。事實上，SCSI 是第一種用於叢集的磁碟子系統。
最近已經設計出一些新的磁碟技術用以支援叢集，例如 光纖通道 （Fiber Channel）和一些專門的解決方案。光纖通道系統允許電腦可以跨越很長的距離來串連磁碟。大多數的光纖通道系統都支援在同一個光纖迴路上使用多個控制器。一些 RAID 控制卡已經被開發或改進來支援叢集。如果不修改或變更設定，絕大多數的磁碟控制卡將無法支援叢集。
如果快取是位在控制卡本身，控制卡快取允許寫入的內容暫存於記憶體中，這會成為叢集的一大問題，12-3所示。在這種情況下，每個節點擁有自己的快取，我們將這種情況稱為 磁碟共用之前（in front of disk sharing） ，因為兩個快取共用相同的磁碟。當系統故障時，由於每個控制卡都有快取，而快取卻位於故障的系統，那麼快取中的資料就會遺失了。因此，若我們在叢集設定中使用內部控制卡快取，它們就該被設定為唯讀模式。（在某些情況下，這種設定可能會降低一些系統的效能。）

　
 
圖12-3 位於磁碟共用之前的控制卡快取
對於共用磁碟系統問題的解決方案牽涉到 RAID，以及位於磁碟系統本身的快取。在這種設定中，所有的節點共用該快取，我們稱之為 在磁碟共用之後（behind the disk sharing） ，12-4所示。RAID 機制和磁碟共用系統的快取會被系統中所有控制卡一致的存取，讀取快取與寫入快取都很安全。

　
 
圖12-4 位於磁碟共用之後的控制卡快取
較新的 SCSI 與光纖通道磁碟系統允許 RAID 控制卡封裝在磁碟中，而不是在電腦系統中。這種系統提供了優秀的執行效能及容錯能力。事實上，許多這類型的 RAID 系統提供備援控制卡和快取。較新的 RAID 系統中有很多已採用這種結構。下面是一些詳細的例子。
 I/O子系統 之前已經提到，有幾種不同類型的 I/O 子系統支援叢集。以下是最主要的三種類型：
•   SCSI JBOD 一種利用 JBOD（Just a Bunch Of Disks）定址，在SCSI 匯流排上有多個引發器（控制器）的系統。在這種設定中，磁碟擁有獨立的地址，必須使用 Windows 2000 或獨立定址的方式來設定至磁碟陣列中。通常不建議使用這種系統。
　
•   內部RAID 每一個伺服器上有一個 RAID 控制卡。這種子系統的缺點是為了避免資料遺失，控制卡快取必須設定為停用。
　
•   外部RAID RAID 控制卡是由叢集中的磁碟系統共用。快取與 RAID邏輯封裝在磁碟內，使一個簡單的主機匯流排卡（HBA）與外部控制卡相串連。
　
接下來兩節僅說明上述兩種 RAID 解決方案。只有在叢集很小，而且費用問題是主要考慮時才使用 SCSI JBOD。
 內部RAID 內部 RAID 控制卡的設計是由硬體來處理RAID過程，並且快取屬於主機系統。使用內部 RAID 時，共用磁碟系統位於 RAID 之後，21-5所示。

　
 
圖12-5 內部 RAID 控制卡
由於快取位於控制卡上，並沒有共用，因此快取中的資料在系統故障時將無法使用。在關聯性資料庫管理系統（RDBMS）中，這是一個很大的問題。當 SQL Server 將資料寫入到磁碟時，資料可能仍在快取中（因為其運作是先寫入磁碟控制卡快取），但在交易記錄檔案裡會記錄該資料為已經寫入。若此時系統出現故障問題，SQL Server 在試圖回複時將不會回複這些資料區塊，因為 SQL Server 認為這些資料已寫入磁碟。在這種設定類型的錯誤事件中，資料庫將因而受損。
因此，廠商必須保證用於叢集的快取 RAID 控制卡的快取功能已經關閉（或至少是寫入快取的功能已經關閉）。如果快取功能已經關閉，SQL Server 在資料尚未被實際的寫入磁碟之前，不會收到寫入操作已經完成的訊號。
________________________________________
說明
SQL Server 是在不使用緩衝區與快取的模式下執行所有寫入到磁碟的操作。不管有多少檔案系統快取可用，SQl Server 都不會使用它們。就如同大多數的 RDBMS 產品一樣，SQL Server 完全忽略檔案系統快取。
________________________________________
在某些情況下，控制卡快取能大大提供執行的效能。尤其是當您使用的是 RAID 10 或 RAID 5，因為這些 RAID 層級在寫入操作時會產生額外的負擔。要在叢集設定中使用控制卡寫入快取，您就必須使用外部 RAID 系統，讓快取可以共用，資料就不會在錯誤移轉時遺失。
 外部RAID 在外部 RAID 系統中，RAID 硬體是在主機系統之外，12-6。每個伺服器都會有一個 HBA，它的工作是儘可能地將更多的 I/O 要求儘速外送給 RAID 系統。RAID 系統決定資料實際儲存的位置。

　
 
圖12-6 外部 RAID 子系統
外部 RAID 子系統有時也被稱為機櫃 RAID 或機箱 RAID，因為 RAID 是在磁碟機櫃內進行。外部 RAID 子系統有著許多優點。它不僅是 MSCS 的理想解決方案，也是一個重要性全面解決方案。機櫃 RAID 有以下優點：
•   易於接線 使用內部 RAID 時，您需要從 RAID 控制卡接出許多電纜－每個磁碟櫃都需要一條。如果使用的是外部 RAID，您僅需一條電纜來串連 HBA 與外部 RAID 控制卡，而磁碟櫃可以用菊花環（daisy chain）的形式串連起來，控制卡再與此菊花環串連，12-7所示。即使需要串連的磁碟有數百個，外部 RAID 仍然可以簡單地完成這個工作。
　
•   允許叢集快取 使用外部 RAID 可以讓您更容易地設定快取 RAID 解決方案。如果您使用外部 RAID，您可以同時擁有快取與容錯功能，而不必擔心在多個控制卡之間的快取一致性（因為只有一個快取及一個控制卡）。事實上，如果使用的是外部 RAID，寫入快取並不會不安全。雖然在您快取 RDBMS 資料時仍有風險，不過在使用外部 RAID 控制卡的情況下這種風險已大大降低。要確定您的外部 RAID 系統廠商支援快取鏡像，當記憶體晶片出錯時，快取鏡像能提供容錯的功能。
　
•   支援更多的磁碟 在大型系統或高效能系統中，有時必須規劃大量的磁碟。在 第6章 中闡述了大量磁碟的必要性，並學習如何規劃系統的大小；在 第36章 學習一般執行問題時，還會再看到它。外部 RAID 裝置讓您可以串連數百個磁碟到一個單獨的 HBA。內部 RAID 系統，每個控制卡只能串連有限的幾打磁碟，如同 SCSI 一樣。

　
 
圖12-7 內部 RAID 接線 vs. 外部RAID接線
在今日這些可用來支援叢集的磁碟子系統中，外部 RAID 機櫃最適用於大型叢集。當然，成本也是必須考慮的，再者有些叢集太小反而不適合使用外部 RAID。不過，在長期執行方案中，外部 RAID 解決方案可以對您的叢集提供最佳的效能、可靠度以及管理性。
叢集應用程式的類型
　
在 MSCS 的系統上執行的應用程式，可分四種類別：
•   非叢集感知應用程式 （Cluster-unaware applications）這類應用程式不會與 MSCS 產生任何互動。雖然它們可以在正常的狀況下順利執行，但在故障發生時它們可能就會當掉，無法強制錯誤移轉到其它的節點繼續工作。
　
•   叢集感知應用程式 （Cluster-aware applications）這類應用程式會意識到 MSCS 的存在。它們可以利用 MSCS 來提升其效能與調適性。它們對叢集事件反應良好，並在組件故障且錯誤移轉寄生之後僅需很少的動作（甚至完全不需要）便能繼續執行。SQL Server 2000 是叢集感知應用程式的一個好例子。
　
•   叢集管理應用程式 這類應用程式用來監控與管理 MSCS 環境。
　
•   自訂資源類型 （Custom resource types）這類應用程式對其他的應用程式，服務及裝置提供自訂的叢集管理資源。
　
MSCS 模式
　
您可以在不同的模式中執行 SQL Server 2000 叢集支援與 MSCS。在 主動/被動 （Active/Passive）模式中，一個伺服器保持備用模式，準備在系統發生故障時立刻接管主要伺服器的工作。在 主動/主動 （Active/Active）模式中，每個伺服器都執行一個不同的 SQL Server 資料庫，無論哪一個伺服器發生了錯誤，另一個伺服器將接管它。在這種情況下，一個伺服器將執行兩個資料庫。在本節中，我們將介紹每一種模式的優點與缺點。

　
 
圖12-8 應用程式類型與 MSCS
主動/被動叢集
　
主動/被動叢集使用主要節點來執行 SQL Server 應用程式，並將用於次要節點的伺服器作為備份或待命伺服器，12-9所示。

　
 
圖12-9 主動/被動叢集
在這種設定中，有一個伺服器實際上是不使用的。這個伺服器可能有好幾個月都不曾被呼叫來執行任何工作。事實上，大部分的情況是，備份伺服器從來不曾使用。因為次要伺服器幾乎沒動過，它看起來就像是一個閑置的昂貴裝置。由於伺服器無法用來執行其它的功能，為了服務使用者或許就需要購買其它的裝置，這使得主動/被動模式可能比您所想象的還要花錢。
雖然主動/被動模式的成本較高，但它也有優點。在主動/被動設定中，如果主要節點出錯，次要節點的所有資源都可用來接管主要節點的活動。如果您執行的是具有關鍵任務性質的應用程式，系統需要負荷指定的流量或是回應時間，這種可靠性就相當重要。在此情況下，對您來說主動/被動模式也許是正確的選擇。
強烈建議次要節點與主要節點擁有完全相同的硬體（也就是說，RAM 的數量相同、CPU 的類型與數量相同等等）。如果兩個節點有完全相同的硬體，您便能確定次要系統的執行效能可與主要系統近乎相同。否則，在錯誤移轉事件中就可能遭遇到效能損失的問題。
主動/主動叢集
　
在主動/主動叢集中，每一個伺服器都執行應用程式，同時也作為另一個節點的次要伺服器，12-10所示。

　
 
圖12-10 主動/主動叢集
在這種設定中，每一個伺服器既是某些應用程式的主要節點，又作為另一些應用程式的次要節點。這是最符合成本效益的設定，因為不會有裝置處於閑置的狀態，等著其它系統出錯。兩個系統都能為使用者服務。此外，也可利用一個單獨的被動節點來作為數個主要節點的次要節點。
主動/主動設定的一個缺點是，在故障事件發生後，次要節點的負擔加重，如此便造成倖存的節點效能明顯下降。倖存的節點現在不僅要執行原先的應用程式，還需執行來自主要節點的應用程式。在某些情況下，如果無法忍受效能的損失，就必須使用主動/被動設定。
叢集系統的範例
　
在本節中，我們來看一下四個使用 MSCS 的叢集系統範例。這些範例將有助於您決定哪一種類型的叢集最符合您的需求與環境。
範例1－具備靜態負載平衡（Static Load Balancing）的高可用性系統
　
這種系統能夠對叢集上的多個應用程式提供高可用性。不過，若所有線上只剩一個節點時，效能就會大打折扣。此系統的硬體資源使用率最高，因為每個節點都可以被存取。圖12-11顯示了這類叢集的設定方式，它是一個主動/主動叢集。

　
 
圖12-11 具備靜態負載平衡的高可用性叢集
叢集中的每個節點會以虛擬伺服器的形式將其擁有的資源通知網路。每個節點在設定上均會保留額外的處理能力，因此在錯誤移轉寄生時可以執行其它節點的應用程式。換言之，藉著這些額外的資源與額外的處理能力，提供錯誤節點用戶端的服務便不會中斷。
範例2－具有最大可用性的熱更換式系統
　
這種系統透過所有的系統資源來提供最大的可用性及效能表現。這種設定的缺點是大量對硬體資源的投資－並且有大部分還用不到。其中一個節點會被當作是主要節點並應付所有用戶端的要求，另一個節點則處於閑置的狀態。閑置的節點事實上是用來作為熱機狀態的備用系統，只有在錯誤事件發生時才會被存取。如果主要節點出錯，這個熱更換節點便可立刻接管所有的操作並繼續對用戶端的要求提供服務。圖12-12顯示了這種設定方式。
這種設定對一些具有最關鍵任務性質的應用程式來說，是再適合不過的了。如果您的公司是在網際網路上進行銷售活動，那麼您的 Web 交易伺服器可能就是以這種設定方式來運作。由於您的生意必須仰仗系統的成敗，多花點錢購置一個閑置的系統以備不時之需，其實還是很值得的。

　
 
圖12-12 具有最大可用性的熱更換式系統
範例3－局部伺服器叢集
　
MSCS 是相當有彈性的叢集方案，從局部伺服器叢集設定上就可以看得出來。在這種系統中，只有您所選取的應用程式允許錯誤移轉。12-13所示，您可以指定某些應用程式在其節點出錯時仍然可用，其它的應用程式則不行。

　
 
圖12-13 局部伺服器叢集
當您打算將硬體資源的使用率最大化，但又必須對一些具有關鍵任務性質的應用程式提供有限的錯誤移轉容量時，這種設定方式就相當理想。此外，這種設定一方面對那些叢集感知應用程式提供錯誤移轉，同時也能支援非叢集感知的應用程式。
範例4－無法錯誤移轉的虛擬伺服器
　
我們的最後一個系統範例其實並不是真正的叢集，不過它仍然利用了 MSCS 對虛擬伺服器的支援性。這種設定其實是一種用來組織資源、發布資源的方法，12-14所示。虛擬伺服器功能允許您為資源命名時採用有意義的、具有描述性質的名稱，而不是一般的伺服器名稱清單。此外，MSCS 在伺服器錯誤解決後會自動地重新啟動應用程式或資源。對一些並不提供內部機制來重新啟動的應用程式而言，這種功能特別有用。這種架構也可說是邁向叢集的最佳預備動作，一旦您在單一節點上定義了虛擬伺服器，便可以很簡單的加入一個次要節點，而不需要更動伺服器定義。

　
 
圖12-14 無法錯誤移轉的虛擬伺服器
SQL Server 叢集設定
　
在您安裝並設定 MSCS 之後，下一個步驟便是設定 SQL Server 在叢集中執行。如之前所言，SQL Server 2000 具有叢集感知的能力，並且可以善用叢集的功能。在本節中，我們先來看一下如何規劃叢集系統，接著回顧在叢集中設定 SQL Server 所必須執行的步驟。
________________________________________
說明
要獲得 MSCS 的所有好處，應用程式必須具有叢集感知的能力。之前已經說過，叢集感知應用程式必須瞭解叢集架構並且能在錯誤事件中錯誤移轉。並不是所有的應用程式都支援叢集，並且在叢集中遇到問題時有能力「逃出樊籠」。
________________________________________
規劃您的設定
　
規劃 SQL Server 叢集的第一個步驟是決定要使用的硬體類型，以及叢集打算採取哪一種作業模式來執行。可以組成叢集系統的硬體架構相當多種，而叢集的運作可以選擇 主動/被動 模式或是 主動/主動 模式。所選的模式會決定您需要的硬體類型與數量。
 主動/被動 叢集設定應該由完全相同的兩個系統組成，每個都有能力掌握整體的工作載量。由於主動/被動模式在正常運作的期間不會使用次要系統，錯誤發生後也不會使用主要系統，虛擬伺服器的效能將可保持不變。當主要系統錯誤移轉至一個完全相同的次要系統，使用者不會察覺到任何效能的變化。
 主動/主動 叢集設定則應該由兩個各自執行一特定工作載量的系統組成。如果發生錯誤，倖存系統會接管錯誤系統的工作載量。在這種情況下，單一系統要執行兩份工作，所有使用者都會面臨效能降低的問題。如果您的規劃夠謹慎，系統的效能也許還能維持一個可接受的最低極限，不過事實上這個效能並不保險。在規劃主動/主動叢集設定時，您應對效能的損失有心理準備，看是要減少一些服務，還是說在錯誤移轉事件中警告使用者，系統效能可能下降。
設定 SQL Server 叢集功能的下一個步驟是檢查或變更一些 SQL Server 的設定。接下來的三個小節中我們會檢查這些設定。
設定複原時間
　
在調整 SQL Server 效能時，您可能已經將組態選項 複原間隔 （recovery interval）設定為其它的值，而不是預設值 0 。變更這個設定可以增加檢查點的間隔時間以改善效能，不過也會增加複原時間。在叢集系統中，預設值 0 不應該變更，它表示複原間隔將由 SQL Server 自動設定。（擁有一個可以錯誤移轉的系統是使用 MSCS 的主要理由，這應該比效能考慮還要重要。）這個設定可以讓資料庫幾乎每分鐘有一次檢查點，並且最大的複原時間為一分鐘左右。
________________________________________
相關資訊
要找到更多的資訊，請參閱線上叢書並索引 複原間隔選項 。
________________________________________
________________________________________
說明
檢查點操作會讓 SQL Server 將快取中修改過的資料寫入到磁碟裡。任何已修改的資料若在系統錯誤時尚未被寫入磁碟，SQL Server 在啟動時會因向前複原已認可交易，以及向後複原未認可的交易，並且複原這些未認可的資料。
________________________________________
設定 SQL Server 在主動/被動叢集上執行
　
要建立主動/被動叢集設定，您可能必須修改 SQL Server 中的一個設定值。如果您的次要伺服器與主要伺服器完全相同，就不需要修改。但若次要伺服器的資源少於主要伺服器，您就必須將 SQL Server 組態選項 min server memory 設為 0 。這個設定指示 SQL Server 依系統可用的資源來分配記憶體。
________________________________________
相關資訊
要找到相關資訊，請參閱線上叢書並索引「伺服器記憶體選項」。
________________________________________
設定 SQL Server 在主動/主動叢集上執行
　
在主動/主動叢集設定中，您必須將 SQL Server 組態選項 min server memory 設為 0 。如果該組態選項設為手動，SQL Sever 可能會在錯誤移轉之後無法分配記憶體。由於 Windows 2000 是一個虛擬記憶體系統，它可以分配比實際可用還要更多的記憶體。事實上，這也是一個常常發生的問題，因為導致了分頁動作。舉例來說，如果每個 SQL Server 系統分配 75% 的系統記憶體，錯誤移轉寄生後合并的 SQL Server 服務就會需要 150% 的可用記憶體，若無法進行動態分配，系統就有可能陷於停滯的狀態。
在叢集中安裝 SQL Server
　
在叢集中安裝 SQL Server 的過程與 第7章 所介紹的 SQL Server 安裝程式相當類似。在開始這個安裝過程之前，您必須決定 SQL Server 要安裝的位置。您應將 SQL Server 檔案安裝在由主要伺服器控制的共用磁碟上。SQL Server 的安裝路徑與 master 資料庫安裝路徑也應該設定指向共用磁碟。您也應指定叢集將要執行的網路通訊協議。接下來，可遵循下列步驟來安裝 SQL Server 錯誤移轉叢集：
1. 將 SQL Server 2000 光碟片片放入您的光碟機中。如果您的系統有自動播放的功能，SQL Server 2000 的主要設定對話方塊就會出現，12-15。否則的話，您就需要手動執行Autorun.exe（可在光碟片片的根目錄中找到）。
　
 
圖12-15 SQL Server 設定對話方塊
2. 如果您尚未安裝必須的作業系統更新套件，或是尚未安裝Microsoft Internet Explorer 的必備版本，或是單純只想檢查一下必要安裝的清單，按一下 SQL Server 2000的必要安裝 ，會出現 SQL Server 2000的必要安裝 對話方塊。
在最適合的系統上按一下以檢視它的需求，並在您需要的選項上按一下以進入安裝。如果您已經載入最適當的軟體，直接跳到步驟3。
________________________________________
說明
在開始安裝 SQL Server 之前，必須已安裝 MSCS。
________________________________________
3. 按一下 SQL Server 2000的組件 ，出現 SQL Server 2000安裝精靈 歡迎畫面。如果您正在執行其它的 Windows 程式，請將它們關閉。按一下 下一步 繼續安裝過程。
4. 在 電腦名稱 畫面，按一下 虛擬伺服器 並輸入伺服器名稱，12-16。按一下 下一步 。
　
 
圖12-16 「電腦名稱」畫面
5. 出現 使用者資訊 畫面。輸入您的名稱與公司名稱。按一下 下一步 。
6. 出現 軟體授權同意書 。按一下 是 接受其授權同意書並繼續安裝過程。
7. 在 安裝 畫面中，輸入 25 個字元的產品識別碼（貼在光碟片盒外的黃色貼標）。按一下 下一步 。
8. 出現 錯誤移轉叢集 畫面，12-17。輸入虛擬伺服器的IP地址，然後按一下 新增 。MSCS 支援子網路地址。按一下 下一步 。
9. 在 叢集管理 畫面檢視 SQL Server 2000 提供的叢集定義。預設情況下，本機端電腦設為優先節點。其它的可用節點會出現在 Additional Node 方塊裡。按一下 下一步 。
10. 在 遠程資訊 畫面中，輸入遠程叢集節點的登入憑證。此登入憑證必須具有叢集的遠程節點之系統管理員許可權。按一下 下一步 。
11. 請在 執行個體名稱 畫面中，選擇一個預設執行個體或指定一個命名的執行個體。若要指定命名的執行個體，請清除 預設值 複選框，然後輸入命名執行個體的名稱。按一下 下一步 。
________________________________________
說明
執行個體不能被命名為 DEFAULT 或 MSSQLSERVER 或其它作為 SQL Server 保留關鍵詞的名稱。
________________________________________

　
 
圖12-17 「錯誤移轉叢集」畫面
12. 請在 安裝類型 畫面中，選擇欲安裝的類型。 安裝 程式會自動將預設值設為您先前選取群組中第一個可用的叢集磁碟資源。然而，若需指定不同的叢集磁碟資源，請在 資料檔案 下按一下 瀏覽 按鈕，然後指定一個位於不同的共用磁碟資源上的路徑。按一下 下一步 。
13. 接著出現 驗證模式 對話方塊，12-18。在此畫面的設定選擇將會決定您的 SQL Server 安裝的安全性層級。您可選擇 Windows驗證模式 或是 合模式 (Windows 的賬戶驗證及 SQL Server 的賬戶驗證) 。若選擇 Windows 驗證模式 ，資料庫使用者的許可權就會繼承自 Windows使用者安全性 設定。若是選擇 合模式 (Windows 的賬戶驗證及 SQL Server 的賬戶驗證) ，您可以個別的定義與管理資料庫使用者的安全性。如果選取的是 合模式 (Windows 的賬戶驗證及 SQL Server 的賬戶驗證) ，就必須輸入並確認 sa（即 SQL Server 系統管理員）登入的密碼。您也可以在sa密碼欄位內留下空白，不過這樣會讓您的 SQL Server 安全性嚴重降低。
　
 
圖12-18 「驗證模式」畫面
14. 在 開始複製檔案 畫面中，按一下 下一步 。
15. 出現 授權模式 畫面。您有兩種 SQL Server 用戶端授權模式可選，一種是每一伺服器授權，另一種是每一基座授權。在每一伺服器授權模式中，您必須對特定伺服器指定個別的 用戶端存取授權 （CAL），每個授權允許一個與伺服器的聯機。不論在任何時刻，可以聯機至伺服器的用戶端電腦最大數量等於您所指派給該伺服器的 用戶端存取授權 數量。如果您選擇每一伺服器授權，您必須指定為該伺服器所購買的同時聯機 用戶端存取授權 數量。
每一基座授權模式中，每個即將存取 SQL Server 服務器的電腦都需要一個 用戶端存取授權 。電腦一旦獲得授權，它就可以存取網路上任何執行 SQL Server 2000 的機器而不需額外的付費。
如果不確定該選擇哪一種授權模式，按一下 每伺服器 。這個授權同意書讓您可以有一次機會、一種方式來變更設定為每一基座授權模式。
按一下 繼續 便會開始安裝 SQL Server 應用程式及資料檔案。SQL Server 安裝程式會將必要的檔案安裝至您的系統中並設定必須的組件。安裝可能會花幾分鐘，或者更久，這要看您系統的速度而定。
16. 當出現 安裝完成 畫面時，選取重新啟動電腦的選項然後按一下 完成 。
如同您所看到的，設定 SQL Server 叢集相當容易。一旦設定了叢集，就不再需要其它的設定步驟。用戶端將透過 IP 位址存取 SQL Server，這個 IP 位址在錯誤移轉後會重新分配給次要節點。剩餘應考慮的程式問題，我們會在稍後 〈超越MSCS〉 一節中討論。
使用三層式應用程式
　
大部分應用程式都是直接聯機至資料庫。應用程式提出交易，資料庫響應交易。在系統錯誤事件中，交易會逾時，應用程式也會出現執行失敗的狀況。就大多數情況而言，這種設定不會有什麼問題－若交易沒有完成，您會希望應用程式執行失敗。不過，若您採用了錯誤移轉叢集，資料庫會在很短的時間內又重回可用的狀態，並在錯誤後繼續響應交易。您可以謹慎的設計一個 三層式 （Three-Tier）的應用程式，便能確保應用程式可以利用此種快速恢複的服務。
在三層式應用程式中，中介層可以察覺伺服器已停止回應，並等待一段時間，然後重新提交交易。使用者可能會感覺到交易的完成似乎有些延遲，但延遲完成總比交易失敗要好得多。要達到這個目標，則在伺服器與應用程式之間出現聯機失敗的狀況時，應用程式必須有所察覺，並且知道要重建立立聯機。應用程式也應該將目前處理的狀況，利用一個訊息對話方塊或是其它方式通知末端使用者。
利用三層式應用程式，建置一個天衣無縫的錯誤移轉環境就不再是遙不可及的理想。應用程式必須具有叢集感知的能力，並且知道虛擬伺服器不久後就能重回工作崗位繼續工作。將三層式應用程式與 MSCS 架構在一起，您就能提供應用程式與資料堅固性。
超越MSCS
　
我們已經介紹了 MSCS 的基本概念以及 SQL Server 在此架構上如何工作。我們也已經看到 SQL Server 是如何在一些硬體與軟體錯誤中倖免於難，並在短時間內重新執行交易。要達到這種容錯程度，您不僅需要使用 MSCS，還需採取一些措施。有兩個步驟是相當重要的：一是規律並確實的執行備份工作，二是準備災難還原計劃。系統備份的程式以及如何準備一份災難還原計劃將在第 32 及 33 章中介紹。並不是有了叢集伺服器或建立一個 RAID 儲存系統就可以不執行備份工作。在許多狀況中，若您的系統出了問題但卻未製作任何備份，這些技術一樣無法給您任何協助。這些狀況包括了以下幾種錯誤：
•   硬體故障 雖然不很常見，但有些硬體故障確實能使資料走樣。如果您的主要系統遭遇到這種足以毀損資料庫的硬體故障，次要系統在錯誤移轉後仍會使用已經受損的資料庫。
　
•   軟體故障 不管是多好的軟體，即使在開發與測試上已儘可能完善，仍然可能藏有 bug。如果某個罕見的軟體 bug 毀損了資料庫，錯誤移轉後該資料庫一樣無法使用。RAID 技術雖然可以簡單地提供一個容錯副本，但副本裡卻可能仍是受損的資料。
　
•   人為錯誤 使用者經常會錯誤地刪除了他們的資料。不論是叢集技術或是 RAID 都無法解決這個問題。
　
在第 32 及 33 章中，您會學習到更多有關於應變計劃以及如何讓系統倖免於難的知識。前面的例子僅僅表示一個事實：叢集與錯誤移轉服務於特定的目的，但在我們與「災變」的戰爭中，這兩個武器僅能提供穩定的資料存取及資料完整性。若希望您的系統能從危機中全身而退，您還需要更多的努力。
本章總結
　
在本章中，您已學習到不同的叢集設定，建立叢集所需的硬體和軟體，以及 SQL Server 叢集設定過程等等相關知識。您也瞭解到 MSCS 在一些狀況確實有所協助，但卻不是完善且完整的系統容錯方案。您也必須使用具有容錯功能的磁碟子系統，並且確實的執行備份工作。將 MSCS 與一個良好的災難還原策略結合，便能提供最大化的系統最佳執行時間與系統可靠度。在下一章，我們將開始介紹 Transact-SQL以及 SQL Server 2000 中可用的 SQL Server 2000 版本新增功能。