分析高可用性系統(tǒng)的硬件和軟件設計模式

N版編程面臨的另一個問題在于如何為N個獨立開發(fā)團隊提供輸入。一般情況下，將為所有的N個開發(fā)團隊提供相同的規(guī)范標準。然而，一旦規(guī)范存在缺陷，那么將得到N個獨立開發(fā)的包含類似軟件故障的版本。如果系統(tǒng)發(fā)布之后，規(guī)范或使用錯誤得到識別，那么每個新錯誤都需要糾正N次，即N個不同的實現(xiàn)都需要加以糾正，這樣維護成本就相當驚人?，F(xiàn)在，最佳的N版編程方法是讓第一流的軟件開發(fā)團隊，利用最可靠的底層架構(gòu)、軟件開發(fā)工具、技術(shù)和測試來開發(fā)出高質(zhì)量的軟件版本。

校驗點恢復

與基于靜態(tài)冗余的N版編程不同，許多軟件容錯設計模式均基于動態(tài)冗余。這些設計模式均包含以下四個步驟：

1. 故障檢測

2. 損害評估與 限制(有時也稱為“防火墻處理”)

3. 故障恢復

4. 故障處理和業(yè)務繼續(xù)

步驟二中，當檢測到軟件錯誤時，一般可以采用失效保護。但軟件往往極其復雜，因此消除故障軟件導致的后果也并非輕而易舉。事務的概念是解決該問題的一個有效工具，事務是應用狀態(tài)下操作的集合，這樣事務的起始點和結(jié)束點均是應用的穩(wěn)定狀態(tài)。例如，每個城市的市政廳都具有一個包含該城市所有居民信息的文件系統(tǒng)。當一對夫妻結(jié)婚時，他們的姓名和結(jié)婚日期都記錄在一個命名為“已婚夫妻”的文件中。另外，記載新郎從單身到已婚狀態(tài)變化的文件稱為“男性居民”；記載新娘從單身到已婚狀態(tài)變化的文件稱為“女性居民”。如果上述3個文件中的一個未能得到有效更新或者軟件在更新過程中突然崩潰，我們將不得不返回到該婚姻“事務”的起始點。否則，將只會以不穩(wěn)定狀態(tài)而告終，如新郎顯示為已婚狀態(tài)，而新娘則仍然顯示為單身狀態(tài)。穩(wěn)定狀態(tài)只出現(xiàn)在婚姻事務的起始點以及得到成功處理的結(jié)束點。

如果希望在容錯中引入事務概念，系統(tǒng)必須能在事務的起始點保存系統(tǒng)狀態(tài)，這稱為檢驗指示。檢驗指示需要在開始新事務之前迅速保存系統(tǒng)狀態(tài)，并且必須要求先前的事務以無差錯狀態(tài)結(jié)束。這里，一種基本的恢復策略是再執(zhí)行方法：一旦事務中檢測到錯誤，事務將進行失效保護，系統(tǒng)將重新載入最近保存的檢驗點。這樣業(yè)務又能從檢驗點繼續(xù)執(zhí)行下去，并允許在該穩(wěn)定狀態(tài)上進行新的事務處理。然而，這樣將丟失進行失效保護的事務。這類故障恢復也稱為后向故障恢復，因為軟件狀態(tài)將還原到先前的一個無差錯點上。

簡單的檢驗指示本身也容易引發(fā)單點失效，因為在保存檢驗點狀態(tài)時有可能出現(xiàn)故障，但我們可以采用一種稱為檢驗點還原(checkpoint-rollback)的方法解決這個問題，如圖2所示。圖中，橢圓符號代表通過發(fā)送隊列消息進行通信的軟件客戶和軟件服務器。一個事務可以包含許多從客戶機發(fā)往服務器的請求消息以及從服務器發(fā)往客戶機的響應消息。在一個事務中，數(shù)據(jù)在服務器中修改。在事務的結(jié)束點，右圖所示的兩個恒定大容量存儲設備將記錄穩(wěn)定的數(shù)據(jù)集和事務序列號。如果某一時刻檢測到錯誤，而服務器已被關(guān)閉，那么服務器將重啟(或啟動備用服務器)。作為啟動恢復過程的一部分，兩個大容量存儲設備還需要檢驗事務序列號。服務器數(shù)據(jù)將根據(jù)包含最高序列號的設備進行恢復。因為故障出現(xiàn)在設備檢驗中，因此另一大容量設備將帶有較低的序列號。

流程對設計模式

檢驗點設計模式的一個缺陷在于故障恢復時間過長。啟動或重啟服務器需要進行許多處理，才能恢復到檢驗點狀態(tài)?！盁醾溆谩狈掌髋c其自帶的恒定大容量存儲設備的直接協(xié)同工作可以加速恢復，該設計模式也稱為流程對(process pair)設計，如圖3所示。

圖3中，方框圖中央是一個工作原理與先前檢驗點情形非常相似的主服務器，客戶機直接與主服務器協(xié)同工作。一旦主服務器成功地完成整個事務，將傳送與新的穩(wěn)定狀態(tài)相關(guān)的信息至備用服務器(右端的服務器)。主服務器和備用服務器都將在恒定大容量設備中記錄數(shù)據(jù)。這樣，備用服務器就能保存完整事務的當前信息。當主服務器準備就緒并可供客戶機使用，將向備用服務器發(fā)送常規(guī)的“心跳消息(heartbeat message)”，這些心跳消息還可以同某些檢驗點消息相結(jié)合。一旦檢測到心跳消息流終止，備用服務器就知道主服務器已關(guān)閉或無法使用，進而作為一個新的主服務器迅速接管事務。

該設計模式不僅適用于客戶機、主服務器和備用服務器均位于同一處理器或模塊上的情形，還適用于三者位于不同處理器或模塊的情形。

盡管流程對設計模式具有諸多優(yōu)勢，但仍有一些問題需要解決。例如，備用服務器丟失了檢驗點消息或消息的順序不對，而且，當主服務器是物理設備的控制器并在操作中發(fā)生故障時，也會產(chǎn)生問題。當備用服務器接管事務時，不必知道如何完成操作，因為備用服務器并不知道主服務器失效之前究竟運行到哪一步。

需要再次重申的是，在流程對設計模式中，當主服務器失效時，仍在進行的事務將在執(zhí)行中丟失或撤銷。備份服務器接管主服務器的狀態(tài)是主服務器失效前報告給備用服務器最后完成的事務的狀態(tài)。

恢復程序塊

動態(tài)軟件冗余的另一種設計模式稱為恢復程序塊。該方法基于檢驗指示，但添加了對軟件處理結(jié)果的驗收測試。設計中必須準備數(shù)據(jù)處理的替代方法(就像在N版編程中一樣)，但不必對每個事務運行所有的數(shù)據(jù)處理方法。相反，可以選擇一種數(shù)據(jù)處理方式作為主方式，并且首先只采用主方式處理事務。一旦主處理完成，即可運行驗收測試。如果驗收測試通過，則表明主數(shù)據(jù)處理方式完全有效。如果驗收測試失敗，則可如圖4所示，繼續(xù)試驗下一個替代方案。

如方框圖所示，必須在首次進入恢復程序塊之前進行檢驗指示。每次失效的驗收測試之后，軟件必須還原到檢驗點狀態(tài)。每次嘗試替代的處理方法之后，都必須進行驗收測試。這樣，需要不斷進行處理方式更迭，直到提供通過驗收測試的處理方式。這些“良好”的輸出構(gòu)成了恢復程序塊的最終結(jié)果。

前向故障恢復

檢驗點恢復、流程對和恢復程序塊都是后向故障恢復方法。大多數(shù)動態(tài)軟件容錯都采用后向故障恢復方法，但前向故障恢復也是不錯的選擇。前向故障恢復的基本思想是從錯誤狀態(tài)繼續(xù)進行并通過校正清除故障。前向故障恢復基于精確的錯誤損失評估，因此通常取決于具體的系統(tǒng)。異常處理就是前向故障恢復的一個典型例子，當檢測到問題，該方法就發(fā)送命令至專用的異常處理軟件，而不是返回到先前某個檢驗點狀態(tài)并繼續(xù)執(zhí)行下去。

替代處理是前向故障恢復的一種設計模式。當某個事務存在兩種(或更多)處理選擇時，就可以采用替代處理方法。在這兩種處理方法中，一種方法非常精確，但計算復雜；另一種方法則相對簡單并具有更高的性能。替代方法不僅可用作測試，而且當主處理方法出現(xiàn)故障時也可用作二級結(jié)果提供器。例如，平方根算法可作為主處理方法，而表查詢插入算法則可作為替代方法。一旦運行了平方根算法，表查詢插入算法不僅可用于測試平方根算法所得結(jié)果的質(zhì)量，還能迅速校正這些結(jié)果中的錯誤。

圖5中，為了控制飛機(波音777)，同時采用了兩套數(shù)字飛行數(shù)字系統(tǒng)?？驁D右側(cè)的決策邏輯電路將簡單飛行控制系統(tǒng)的輸出作為測試復雜的主飛行控制系統(tǒng)輸出的衡量標準。如果驗收測試失效，簡單飛行控制系統(tǒng)的輸出也可用作失效主輸出的替代，向左的箭頭表示替代處理的結(jié)果也可為主處理提供反饋。

上述設計模式使采用常規(guī)商業(yè)級質(zhì)量的硬件和軟件為真正的高可用性系統(tǒng)構(gòu)造程序塊成為可能，這樣的高性能系統(tǒng)無需人為干預，即可實現(xiàn)高達99.999％或更高的可靠性。