應用級叢集系統的設計

叢集系統在企業 IT 應用中的部署越來越廣泛，基於某個具體業務的應用級叢集服務系統也越來越得到重視，圍繞這個主題，本文簡要地探討了應用級叢集一般性的設計思路，重點針對分層業務資源、業務資源監測器、負載均衡器和故障轉移管理器等四部分。

叢集型別

按叢集系統的應用範圍，大體可分為作業系統級叢集和業務應用級叢集。通常，作業系統級叢集作為底層基礎叢集架構為業務應用級叢集提供作業系統級的叢集服務；而業務應用級叢集則作為作業系統級叢集的子叢集，部署在作業系統級叢集之上，完成特定業務的叢集服務。

作業系統級叢集

Linux 下主要的幾個作業系統叢集：

1. LSF：通過網路將多個異構的叢集體系相聯絡，共享計算資源 ，而使用者則以透明的方式來訪問這些資源。
2. TurboCluster：是一個企業級軟體叢集系統解決方案，支援異構的網路環境。有較強的可用性和可擴充套件性。
3. Linux Virtual Server：LVS 專案是國內章文嵩博士領導開發的 Linux 服務叢集系統，它集合了叢集技術和 Linux 作業系統核心實現了一個具有高伸縮性、高可靠性和高可管理性的叢集解決方案，同時也為完成大訪問量、可靈活部署、高可用的企業級叢集系統的開發提供了一個完美的架構。LSF、TurboCluster 和 LVS 三者類似，在體系中都部署了一個負責完成平衡訪問負載的主控制機，由它來根據環境資料決定負載均衡策略完成整個訪問請求的轉發，內部核心處理部分基本上是對外端客戶完全透明的。
4. MOSIX：與前三者對比有很大的不同，它沒有一個單獨的專用部件來完成訪問請求的負載均衡，所有的伺服器節點是都平等的和完全分佈的。
5. EDDIE：它由 HTTP 閘道器和特殊的 DNS 伺服器組成，共同構成了一個分散式的 WEB 服務叢集。

作業系統叢集具備的基本特點：

• 提供強大的計算處理能力
• 提供高可用性的應用
• 提供可伸縮的軟體硬體部署
• 提供對系統資源強大全面的排程與管理

業務應用級叢集

業務應用級叢集在繼承作業系統級叢集特性的基礎上，重點集中在自身所支援的業務特性，也有自身的特點。

業務應用級叢集基於具體的業務規則，它將關注焦點放在框架內執行的各個業務資源，以及資源內部或資源之間的業務資料流，結合事先定製的業務策略，進而做出符合業務的管理操作。

業務應用級叢集對資源的管理與排程範圍相對有限，侷限於框架內部的元件；而對於框架之外的元件無能為力，須藉助於底層的作業系統級叢集的功能進行間接的管理。

業務應用級叢集執行在作業系統叢集之上作為其子部分，要接受作業系統叢集的監管。

本文中討論的內容就是基於 LVS 體系架構的業務應用級叢集的開發。它提供針對物件生命週期的管理、差錯檢測、自我修復和自我遷移等功能。以下的章節介紹業務應用叢集軟體框架 BRMF（Business Resource Management Framework，業務資源管理框架）的設計。

回頁首

叢集業務資源的設計

分析大多數的業務系統，我們都可以將其業務資源分為兩類：形成業務特徵的邏輯業務資源和最終執行業務服務執行的物理業務資源。對於這兩類資源，往往又以“部分”從屬於“整體”的樹形層次結構來展現，物理業務資源從屬於邏輯業務資源，“從屬”的關係決定了二者已具有功能上的一致性。其中，劃分粒度的最細單位為 BRU（Business Resource Unit，業務資源單元）；若干的 BRU 可以組成 BRG（Business Resource Group，業務資源組），每一個 BRG 就代表了一個完整的業務處理服務過程；若干個 BRG 可以組成一個 BRC（Business Resource Container，業務資源容器），形成一個服務節點。其中，BRU 屬於物理業務資源，BRG 和 BRC 屬於邏輯業務資源。

BRMF 框架採用嚴格的分層管理機制，至上而下來看，當前業務資源層只能對下一層的業務資源進行管理；至下而上來看，當前層業務資源層只能接受上一層的管理。總之，只能在相鄰的上下兩層之間產生管理與被管理的關係，不允許縱向跨層管理，例如 BRC 不能對 BRU 直接進行管理；類似的，也不允許橫向上的平層管理，即處於同一層次的業務資源不能相互管理，它們之間是平行且獨立的關係，例如從屬於 BRC_A 的 BRG_A 不能對從屬於 BRC_B 的 BR_B 直接進行管理。如果 BRC 需要對 BRU 實施管理操作，BRC 就必須通過 BRU 所屬的 BRG 進行管理指令的下達；對於 BRU 的回饋資訊也只能層層上報，即 BRC 只能通過 BRG 才能瞭解相關的 BRU 的資訊。如 表 1 所示為 BRMF 框架中業務資源部署結構。

表 1.BRMF 櫃架業務資源部署結構圖

BRU 表示處理業務服務的最細節過程，它是業務服務的直接載體，它與真實的業務之間表現為兩種對映關係：

1. 一對一關係，即一個 BRU 對映一個業務功能，它能獨立的表示某個完整業務生命週期。這種關係下的 BRU 一般只能處理簡單的業務服務。
2. 多對一關係，這種關係下單一 BRU 只代表業務過程的一個片段，多個 BRU 之間相互依存，並協同處理某個複雜度較高的業務。

通過 BRU，我們可以看到真實的業務規則實施和業務資料流。每一個 BRU 都只從屬某一個 BRG，接受 BRG 的管理。

BRG 實現了某個完整的業務生命週期。BRG 由若干 BRU 組合的方式來表現，這種方式更多的是體現出實際業務的邏輯性上，它是若干 BRU 業務邏輯集合的反映，與完整的真實業務功能呈現一對一的關係。BRG 的集合粒度可根據軟硬體技術因素和業務規則等因素進行集合或拆分，可分為兩種：

1. 一般而言，簡單的 BRG 體現出了 BRU 與業務之間的一對一關係，即一個 BRG 只集合了一個 BRU，此 BRG 負責處理某個較簡單的業務；稍微複雜的 BRG 集合了若干（大於 1）個 BRU 協調處理較複雜的業務服務；
2. 特殊情況下，若干 BRG 可以再次被集合形成一個體積更大功能含蓋範圍更廣層次更高的 BRG，以便於表示更加複雜的業務。不過這種情況增加了業務資源的管理複雜度，特別是在發生故障需要做遷移操作時，所以不建議採用。為了在不影響業務服務的前提下，避免這種情況的發生，可考慮重新選擇業務資源的粒度進行劃分。

在 BRG 的屬性中，包括了對 BRU 組成的業務鏈的定義，從起始輸入點，中間過程處理點，到最終輸出點。

從邏輯上引入 BRG 的概念，還有一個更重要的原因，就是為了劃定出在叢集應用系統中故障管理情況下最小的邏輯遷移單元，因此，BRG 還需要具有叢集特性 ---- BRG 中所有的 BRU 必須作為一個完整的實體存在，任何一個 BRU 執行失敗都代表所屬的整個 BRG 執行的失敗。在故障轉移發生的情況下，BRG 只能做整體性操作，包括重啟和遷移等。每一個 BRG 都只從屬某一個 BRC，接受 BRC 的管理。

BRC 表示物理上的服務節點，一個 BRC 對外提供若干完整的業務服務過程，若干個 BRC 便形成了更加全面綜合的業務服務體系，或者一個提供冗餘特性的業務服務體系。BRC 接收負載均衡器轉發的客戶端訪問請求，每個 BRC 都有各自的內部 IP 地址。

在叢集系統當中，一般都提供資源的冗餘配置，如將兩個相同的 BRG 部署在不同的 BRC 上，為實現均衡的負載和故障的平滑處理，以提高服務響應度和保證服務可用性。

可以觀察到 BRC、BRG 和 BRU 三者之間存在一種“整體－部分”的樹形層次結構。在業務操作方面，為了使這種具有明顯樹形特點的物件組合擁有操作簡易性和一致性，可以用“複合模式（composite design pattern）”來設計展現三者之間的層次關係。這種設計下，樹形複合體內部的各個元素物件都擁有共同的介面。當呼叫元素物件的某個介面時，自動遞迴地遍歷以當前元素為起始根節點的以下的所有節點元素，在遍歷的同時對每個經歷的元素物件呼叫相同的介面，達到“一令齊動”的效果。具體講，就是隻需要操作 BRC 即可完成對 BRC 中所有 BRG 的相同操作，操作 BRG 即可完成對 BRG 中所有 BRU 的相同操作。

清單 1. BR 相關介面的設計

				 
// 根據業務資源展現出的形態，採用 composite 模式作為開發實現
public interface IElement { 
    // 基本屬性
    public void setName ( String name ); 
    public String getName ( ); 
    public void setId ( int id ); 
    public int getId ( ); 
    // 業務資料
    public void setData ( Object data ); 
    public Object getData ( ); 
    // 結構管理，實現樹形的結構
    public void addChildElement ( IElement child ); 
    public boolean contains ( IElement child ); 
    public void removeChildElement ( int index ); 
    public void removeChildElement ( IElement child ); 
    public void removeChildrenAll ( ); 
    public void enable(); 
    public void disable(); 
    public IElement getChildElement ( int index ); 
    public int getChildCount(); 
    public int getIndexOfChild ( IElement child); 
    public IElement[] getChildElements ( ); 
    public IElement getParentElement ( ); 
    public void setLeaf ( boolean leaf ); 
    // 如果返回為 true 則表示此業務資源為 BRU，返回 false 則有可能為 BRG 或 BRC 
    public boolean isLeaf ( ); 
 } 
 
// 定義業務操作介面
public interface IOperation { 
    // 讓 parentElement 業務資源及其以下的所有業務資源執行業務服務 business_1 
    public boolean doBusiness_1 ( IElement parentElement ); 
    public boolean doBusiness_2 ( IElement parentElement ); 
    public boolean checkDetailsOfBusiness ( IElement parentElement, Map details ); 
} 

public interface IBR extends IElement, IOperation { } 

public class AbstractBR implements IBR { 
    .... 
    public boolean doBusiness_1 ( IElement parentElement ) { 
        // TODO: 實現 parentElement 真實的業務操作
        ........ 
        // 實現 parentElement 節點下所有節點的 doBusiness_1 業務的遞迴操作
        for ( int i=0; i<parentElement.getChildCount(); i++) { 
            IElement childElement = parentElement.getChildElement ( i ) ; 
            childElement.doBusiness_1 ( childElement ); 
        } 
    } 
} 

// 完成 BRC 自身的服務後，將服務命令傳遞給 BRG 
public class BRC extends AbstractBR { ...... } 

// 完成 BRG 自身的服務後，將服務命令傳遞給 BRU 
public class BRG extends AbstractBR { ...... } 

// 負責完成通過 BRC 和 BRG 下達的服務命令，它是服務處理最核心最主要的執行者
public class BRU extends AbstractBR { ...... } 

// 測試程式碼
public class Test { 
    ..... 
    public void fun ( ) { 
        AbstractBR BR = new BRG ( ); 
        // BR 完成 business_1 業務 : 
        // 最終由此業務資源組中的業務資源單元來完成相關的業務實現
        BR.doBusiness_1 ( BR ); 
    } 
} 

回頁首

叢集資源監測器

為了保證叢集系統執行時質量，提升叢集的可用性，往往會採用軟硬體冗餘部署和分析利用業務資源監測資料兩種手段。叢集可用性是度量一個叢集是否有良好表現的重要綜合指標。它由叢集可靠性和叢集可維護性組成。

• 可靠性：以平均無故障時間為衡量標準，即叢集系統能夠正常持續執行的平均時長。故障發生的頻度越低，系統的平均無故障時間越長，可靠性也就表現越好。
• 可恢復性：以平均恢復時間為衡量標準，即叢集系統發生故障之後，系統維修到重新恢復正常執行狀態所花銷的平均時間。用於維修的平均時間越短，叢集系統的可維護性表現就越好。

叢集可用性定義為：

可靠性／（可靠性＋可恢復性）* 100% 

通常，根據叢集不同的部署環境要求將叢集的可用性歸納為 5 個等級。如 表 2 所示為叢集系統可用性等級的劃分。

表 2. 叢集系統可用性等級劃分

本節以資源監測器為例，它主要監測各個資源的執行時資料以獲得相關資源的健康度，它負責監測的內容十分全面，按性質不同分為物理監測和業務邏輯監測。

• 物理資源監測包括：非業務相關的技術指標，如 CPU、Memory/swap、I/O 和 Network 資料等。
• 邏輯資源監測包括：業務規則執行，業務資料流量，業務響應速率，業務資料有效性等。

綜合兩種資料的監測對業務資源執行時健康狀態做出判定，判定原則根據具體的物理環境和業務規則決定。當業務資源處於執行時狀態下，如果有任何達不到要求的最低指標資料的情況發生，則視為此業務資源當前正處於非健康狀態。這個判定結果在全系統中發揮著極其重要的作用，它為叢集執行負載均衡決策和故障轉移操作提供了資料支撐。

BRMF 叢集框架提供叢集監測器，監測叢集中相關軟硬體資源的健康度。按監測範圍和層級不同分為三種型別：系統資源監測器 ( SRM， System Resource Monitor )、業務資源心跳探測器 ( BRHD，Business Resource Heartbeat Detector ) 和業務資源監測器 ( BRM，Business Resource Monitor )。

系統資源監測器

由於 BRMF 叢集框架是構築於作業系統級叢集之上的叢集系統，所以它可以藉助於底層作業系統級叢集提供的硬體監測功能，完成對其自身關心的相關硬體執行時系統層面的健康度監測。如系統 CPU 佔用率、Memory/swap 開銷、I/O 速率、節點網路流量、埠網路流量和 TCP/IP 負載等資料。硬體資料監測器可以快速給出全系統總體健康度資料，但是這只是一個很粗略的評估，我們還要依靠更加精細的監測手段。

業務資源心跳探測器

BRMF 叢集框架內部通過心跳包來判斷各業務資源的網路通訊狀態。它週期性地向所有業務資源（BRC/BRG/BRU）發出心跳命令。探測器只收集業務資源當前是否能夠通訊的資訊，並根據這個資訊計算得到兩組資料：

• 最近週期內心跳有效率：它以當前時刻之前最近最完整的週期作為參考基準點，為負載均衡策略等提供實時（及時）趨勢資料的支援。

	週期內心跳有效率 = 週期內心跳響應次數 / 週期內心跳傳送次數 * 100% 

• 平均心跳有效率：它將當前時刻之前收集到的所有完整週期積累的心跳活動總量作為參考基準點，衡量系統長期以來的健康情況，提供對下一個長期時間段的健康度預期。

	平均心跳成功率 = 心跳響應總次數 / 心跳傳送總次數 * 100% 

根據“最近週期內心跳有效率”得出的資料，可以將業務資源的網路狀態分為：暢通、不穩定、無響應（未啟動 / 假死）等三種情況。如 表 3 所示為網路心跳狀態劃分。

表 3. 網路心跳狀態劃分

業務資源監測器

對於系統資料監測器和業務資源心跳探測器而言，我們只能從它們身上獲得粗略的監測資料，可以即時瞭解系統現在總體的執行狀態，但對於全面細緻瞭解各個業務資源具體執行資料和定位系統瓶頸甚至故障等則束手無策，所以必須建立針對所有業務資源的監測器－－業務資源監測器，以深入其全面細緻的執行資料。

業務資源監測器有不同的監測尺度，一般而言，可以按照 BRMF 叢集業務資源部署的層次結構來確定，即按自下而上縱向地分為業務資源單元監測器（BRU Monitor）、業務資源組監測器（BRG Monitor）和業務資源容器監測器（BRC Monitor）三個監測層次，每個層次的監測器對感興趣的監測內容各有側重。

業務資源單元監測器

業務資源單元監測器是尺度最小的監測器，它侷限於一個業務資源組的範圍內，監測目標直接指向業務資源組內部已註冊的所有具體單一的業務資源單元。它對內部所有資源單元做出業務邏輯上的檢查，是否符合業務規則，是否滿足業務資料有效性等；監測業務服務執行情況；同時，也監測每個資源單元花銷記憶體等情況。

對於業務資源單元的監測內容需要在開發就確定下來，它真實的反映出業務資源單元在執行時的每一個細節表現，下表只是一個監測模型。如 表 4 所示為業務資源單元細節資料。

表 4. 業務資源單元細節資料

根據監測資料，結合事先定義的健康度演算法和健康度閾值，業務資源單元監測器為每個業務資源單元生成健康度評估表。如 表 5 所示為業務資源單元健康度評估情況表。

表 5. 業務資源單元健康度評估表

業務資源組監測器

業務資源組監測器關注業務資源容器之下分佈的各個業務資源組，可以跟蹤收集每個資源組的具體細節。它結合業務資源單元健康度評估表得出此組監測器的健康度。同時，它也有自身的細節監測內容，例如資源組接受的訪問請求事件數、組內所有資源單元程式 ID 列表。業務資源組的健康度為負載均衡決策提供了直接的資料依據。如 表 6 所示為業務資源組細節資料。

表 6. 業務資源組細節資料

根據監測資料，結合事先定義的健康度演算法和健康度閾值，業務資源組監測器為每個業務資源組生成健康度評估表。如 表 7 所示為業務資源組健康度評估情況表。

表 7. 業務資源組健康度評估表

業務資源容器監測器

業務資源容器監測器負責監測叢集內所有的資源容器，它收集整個叢集系統中接收到的客戶端訪問請求總數、資源容器對訪問請求的響應度等。通過容器監測器做出的評估，我們可以判斷容器的負載，它也為負載均衡器提供了的負載決策的資料依據。

表 8. 業務資源容器健康度評估表

表 9. 業務資源容器細節資料

故障資源監測器

系統在系統資料監測器、業務資源心跳探測器和業務資源監測器收集資料的同時，應建立一個專門負責管理故障資訊資料的元件 ---- 故障資源監測器（Trouble Monitor），它收集所有發生故障的業務資源，併產生一張動態的“全域性故障資源分佈列表”，記錄當前正處於故障處理狀態下的資源。故障資源監測器為以後提到的故障資源轉移管理器提供了故障資料。

表 10. 全域性故障資源分佈列表

清單 2. 業務資源監測器介面設計

				 
public interface IMonitor { 
    // 1. 將關心“全域性故障資源分佈列表”的元件註冊到監測器，如故障轉移管理器
    // 2. 將關心“資源健康度列表”的元件註冊到監測器，如負載均衡器
    // 3.TroubleMonitor 也需要作為 listener 註冊到業務資源監測器當中
    public void addBRLinstener ( IListener listener ); 
    // 當監測資料發生變化時，通知在 monitor 中已註冊的 listener, 
    // 隨即每個 listener 取到最新的資料來更新其本地資料，
    // 以及進行相關的處理操作。
    public void notify ( ); 
    public void notify ( Class listenerClass ); 
    // 得到業務資源的詳細資訊
    public IDetail getDetail ( final IBR BR ); 
} 

在部署系統前即為不同的業務資源預先定義出若干健康度演算法，為了靈活適應不同執行時環境（業務資料環境和網路環境等），每一種資源都配置有健康度的預設演算法和若干次級演算法，一般情況下使用預設演算法，次級演算法只是用來應對某些特定的執行時環境。演算法之間既有獨立性又有相似性。將採集到的資料完全委託給演算法器，演算法器使用演算法對資料計算得出對應業務資源的健康度。每個演算法被設計為可以動態載入和相互替換的模式，演算法和資料之間處於弱連線的關係。

清單 3. 健康度演算法與資料介面設計

				 
public interface IHealth { 
    // 為滿足需求，監測資料可以委託給各式各樣的演算法
    public IDegree delegate ( IStrategy strategy ); 
} 

public interface IStrategy { 
    // 不同的演算法此處有不同的實現方式
    public IDegree operate (IHealth health ) { 
        
    }
}

回頁首

負載均衡器

在傳統的網路系統尤其是兩層架構的系統中，單一裝置承載了巨大的資料流量和計算強度，即便是採用最優的軟硬體配置來建設網路系統，也會很快感到資源捉襟見肘，無法高效地完成應用。在現有網路系統中加入負載均衡器則可以從根本上改變過去的窘迫局面。負載均衡器在如今的叢集應用系統中也毫無爭辯地扮演了一個承上啟下的關鍵角色，它是聯絡客戶端訪問請求與真實業務處理的中轉站，提供了一種高效的手段擴充套件伺服器頻寬和增加吞吐量來提高資料處理能力。它採用適應的負載處理策略，對來自前端客戶大量型別各異的訪問請求資料，有選擇的進行“分路”轉發，最大程度地為其分配系統中較為“閒散”的業務處理資源，從而避免了大量請求資料集中湧向同一個業務處理資源，防範後端出現單點效能瓶頸和多點資源閒置的“尷尬局面”。負載均衡器應盡力使同類的若干業務處理資源都獲得大致相同的負載效果。

負載均衡器的使用可以為系統增添許多的價值：

1. 解決了網路擁塞問題；
2. 伺服器資源得到了充分利用，為客戶端提供高質量的訪問體驗；
3. 從體系架構的角度來講，
   1. 負載均衡器作為中間層，它將訪問核心業務處理資源的操作聚合為一組介面，為客戶端的訪問提供了一個一致的介面，使訪問更加容易；
   2. 客戶端訪問請求由負載均衡器接受，避免直接同核心業務處理資源耦合，從而極大提高了系統的可擴充套件性（資源可擴充套件性、應用可擴充套件性和技術的升級換代）並保證了叢集系統和客戶端軟體的相容性；
   3. 為實現物理位置上業務處理資源部署的分佈性提供了條件；
4. 從客戶端的訪問體驗來看，客戶端並不知道也無需關心真正的核心業務處理資源的所有細節，負載均衡器是一組簡單的訪問介面，是業務處理訪問請求的唯一入口，它常被客戶端“誤認為”是代表了所有核心業務處理資源。客戶端軟體只要符合負載均衡器的訪問規範即可以訪問整個叢集系統。

目前，負載均衡器技術按資料流層次分為基於客戶端的負載均衡技術、網路接入協議交換、高層協議交換和應用伺服器技術等幾種實現方式。

此處的負載均衡器被設計為兩層，第一層藉助 LVS 叢集架構提供的 IP 級負載均衡技術，第二層採用高層協議交換技術來達到均衡負載的目的。

首先，作為 LVS 叢集結構中的子叢集，LVS 的負載均衡器完成作業系統級的 IP 負載均衡（LVS 提供了三種負載模型：地址轉換、IP 隧道和直接路由。這裡不做具體介紹）；之後，由 BRMF 提供的軟體負載均衡器解析客戶端訪問請求，根據請求型別和業務處理資源健康度情況，將請求轉發到正確的節點。

本節介紹的重點是 BRMF 提供的負載均衡器，它屬於高層協議交換方式，可以針對具體的業務邏輯特徵實現對訪問請求的高層控制 -- 訪問請求分發策略，它根據業務特徵的不同，由基於內容的分發器（Content-based Distributor）和基於健康度的分發器（Health-based Distributor）兩部分組成。

• 基於內容的分發器作為負載均衡器的第一級，首先完成對客戶端訪問請求內容的解析，確定其應該轉發到哪些目標：所有滿足型別匹配要求的合法目標，包括業務資源容器和業務資源組；
• 在第一級中通過內容分發器的解析得到了所有與訪問請求匹配的候選分發目標，進而可以從“資源監測器”中提取出這些資源的健康度評估資料，從而甄選出最優目標資源作為訪問請求的最終目的地。

經過內容解析和健康度評估兩級的過濾篩選後，得出了一個完整且預期處理效果最優的訪問請求傳輸路徑。

基於內容的分發器（Content-based Distributor）

它掌握了應用叢集環境中完整的業務功能列表。

根據協議定義，解析訪問請求的所屬“業務型別”，然後通過“業務型別識別符號與業務資源對映表”找出所有匹配的目標資源。對於叢集系統，通常都為處理每種業務型別的訪問請求提供至少兩個以上的業務資源組，以提高系統的可靠性和可用性。

表 11. 業務型別與業務資源的對映

基於健康度的分發器

在不同型別的業務資源監測器中，都會生成相應的業務資源健康度評估列表。健康度分發器就是以這些評估列表提供的資料為基準點。結合在第一級分發器解析後得到的符合匹配條件的若干目標資源，根據相關聯評估列表，從中篩選出最優的目標資源。健康度分發器在“業務型別與業務資源對映表”的基礎上，最終形成最優目標資源分發路徑表，它包括了當前系統中每種“業務型別”對應訪問請求的最優分發目標資源。

表 12. 最優目標資源分發表

分發器與業務資源監測器的關係

分發器並未實時地向業務資源監測器傳送詢問請求來得到當前最新的最優目標資源的分佈情況，而是作為業務資源監測器的資料監聽者，等待更新資料的通知。

1. 分發器必須要作為監聽方，註冊到相關的業務資源監測器當中
2. 當業務資源監測器在資源相關資料發生變化時，應立即向分發器發出更新通知。
   1. 資源正常執行，只是負載發生變化而引發的更新通知
   2. 資源發生故障，其分佈資訊發生變化而引發的更新通知
3. 分發器獲得更新通知後，從業務資源監測器中取出最新的資料，
   1. 更新“業務型別與業務資源對映表”
   2. 更新“最優目標資源分發表”

基於內容的分發器與基於健康度的分發器組合成一個負載均衡器，共同完成對客戶端訪問請求的路由選擇，通過這個路由篩選過程，達到了用最優秀的資源服務客戶端的目的。

清單 4. 分發器的介面設計

				 
public interface IDistributor extends IListener { 
     public void update ( Object data ); 
} 

回頁首

故障轉移管理器

任何一個系統都不能百分之一百的保證永遠不發生任何故障，故障的發生將導致相關成本的提升，那麼對於如何處理和管理故障以減少成本支出就顯得尤為重要。故障管理器通過故障資源監測器可以得到當前所有處理故障狀態的業務資源。故障管理器對這些資源完成停止、重啟和轉移等操作。

前面已經提到了，在叢集系統執行時，對所有相關業務資源均受到 BRMF 的監測。當故障管理器接收到業務資源故障通知後，會遵循一個管理原則，即當某業務資源發生後立刻停止被中止，然後試圖進行本地重啟，如果重啟不成功則對資源進行適當的遷移再執行。遵循這一原則的目的是為了能夠保證元件在業務邏輯角度上的完整性和一致性。

從業務資源監測器與故障轉移管理器的關係入手，以 BRG 發生故障為例，展開故障轉移管理的基本過程：

1. 當業務資源容器監測器監測到 RG 資源發生故障時，立即觸發資源故障事件
   1. 業務資源容器監測器向 BRC 傳送業務資源登出事件訊息，將 BRC 中的這個故障 BRG 登出，停止對該 BRG 資源的監測
   2. 故障資源監測器將此故障 BRG 資訊加入“故障資源分佈列表”。
   3. 向故障轉移管理器傳送資源故障事件訊息，並將此故障 BRG 的管理權移交給故障轉移管理器。首先，故障轉移管理器對資源進行重啟操作，如果重啟失敗（一般而言，硬體發生故障是導致重啟失敗的常見原因）：
      1. 首先在系統中檢查是否還有某些系統資源因此故障 BRG 而處於被佔用狀態，如果有則系統強制釋放這些資源
      2. 檢查 BRG 中的 BRU 程式是否還有遺留記憶體，如果有則將其從記憶體中清除。
      3. 此時系統中已沒有任何與故障 BRG 相關的業務資源存在，可以開始轉移工作，根據故障資源轉移策略的裁定，在新 BRC 節點上以新 BRC 的名義重新啟用先前發生故障的 BRG 資源。此時的 BRG 資源擁有權屬於當前這個新的 BRC 節點。
2. 當故障轉移管理器成功完成故障資源重啟或轉移工作後，通知業務資源監測該 BRG 資源當前的分佈資訊，此時業務資源容器監測器重新開始對該 BRG 資源的監測工作。

表 13. 業務資源與故障轉移策略配置

回頁首

結束語

在大型的應用級叢集服務系統的實施過程當中，設計人員需要考慮相當多的要素：功能、可靠性、可用性和效能等若干方面，本文僅從叢集的業務資源設計、資源監測器、負載均衡器和故障轉移管理器四個部分簡要的闡述了叢集系統的基本設計，拋磚引玉，希望能與大家共同深入探討叢集系統的設計與實施。

參考資料

學習

• “基於 Linux 的叢集系統”（developerWorks，2001 年 6 月）：Linux Virtual Server 開源專案創立人章文嵩博的相關技術文章。
  
• 檢視 developerWorks 上更多關於 叢集 的文章和教程。
  
• developerWorks Java 技術專區：可以找到幾百篇關於 Java 程式設計的各個方面的文章。
  

討論

• 參與 developerWorks blogs 並加入 developerWorks 社群。

關於作者

		陳鬆，軟體架構設計師。有豐富的軟體開發及架構設計經驗，目前主要精力集中在企業級應用 Java 大型系統的前期架構和實施當中，並致力至系統的重構優化。閒暇之餘，對中國古典哲學思想有著濃厚的興趣。