Global Sources
電子工程專輯
 
電子工程專輯 > 嵌入式技術
 
 
嵌入式技術  

高可用性系統的硬體和軟體設計模式

上網時間: 2003年05月10日     打印版  Bookmark and Share  字型大小:  

關鍵字:High Availability  高可用性  automated teller machine  自動播音器  redit card verification network 

嵌入式系統設計人員經常需要實現那些能在99.999%的業務時間內可靠執行的系統,這意味著一天內系統故障的時間將少於一秒。這些系統稱為高可用性系統。高可用性系統的設計透過對冗餘硬體和軟體進行組合,無需人為干預即可管理故障檢測和糾錯。本文首先簡要回顧了與高可用性系統和故障管理相關的一些概念,然後研究了容錯系統的一些硬體和軟體設計模式。

故障與失效

在設計高可用性系統時,需要重點關注‘故障’和‘失效’。為了更好地說明,這?將‘失效’定義為系統提供的業務與設計規格不符的情況。故障則是與系統相互作用的一種錯誤,它是人們通常所指的不期望產生事件的可能原因。因此,故障可能是系統的子系統失效、元件失效、外部系統失效或程式錯誤。

故障可以是瞬時故障、永久故障或周期性故障。故障一旦產生,將導致系統或子系統的狀態出錯,而這些錯誤將引發系統失效。故障處理主要有以下四種主要方法:


1. 故障預測;


2. 故障避免;


3. 故障消除;


4. 容錯。

圖1: 3路再使用或3重冗餘硬體設計,這三重覆制均位於方框圖的底端附近。

故障預測利用數學模型和試驗提供故障及其後果的預估。例如,實際中採用的一種故障預測技術就是在系統中插入故障,研究可能出現的各種系統失效。

故障避免和消除則透過嚴格的系統、硬體和軟體開發製程及正式規格和驗證技術加以實現。

容錯藉由採用各種冗餘系統實現,因而避免了故障影響。‘失效弱化’是實現容錯的一種方法:即便該方法難以提供整體系統性能,也能提供切合實際的部份功能。‘失效保護(fail safe)或失效即停(fail stop)’則是另一種容錯方法:當故障產生時,該方法在一個安全狀態終止系統,而不讓系統繼續執行。

容錯涉及的主要概念是冗餘。容錯基於這樣的思想(或願望):多個獨立的故障不會同時攻擊系統。容錯系統應能規避單點失效,換言之,如果系統的某部份可能出現故障,那麼系統中應當存在解決該故障的冗餘部份,因而避免失效。

冗餘具有很多種形式:


1. 硬體冗餘(低階、高階或兩者兼有);


2. 軟體冗餘;


3. 時間冗餘;


4. 資訊冗餘。

飛機內的自校驗邏輯電路及多台飛行電腦即為典型的硬體冗餘。軟體冗餘可採用兩種完全不同的算法,得到的結果也完全相同。時間冗餘可以利用通訊重傳實現,而資訊冗餘則可採用備份、校驗及糾錯代碼實現。

冗餘可以是動態的,也可以是靜態的,兩者均需複製系統的基本要素。在靜態冗餘中,同一時刻所有的複製要素均保持啟動。如果一個複製‘拋出’故障,系統能夠馬上使用另一複製,並繼續正確的作業。在動態冗餘中,只有一個複製保持啟動,而其餘複製則不啟動。如果被啟動的複製產生故障,先前未被啟動的一個複製將被啟動並接管臨界作業。

那麼上述各種方法是如何實現高可用性的呢?首先,必須對高可用性進行定義。高可用性表徵系統容錯並根據規格繼續提供業務的能力。系統可以採用本文給出的所有概念和方法實現高可用性。

可用性通常採用‘可用度’或‘每年故障時間’進行量度。常規的容錯系統可以達到99.99%的可靠度,即相當於每年故障1小時(每天故障10秒鐘)。但高可用性系統則可望實現高達99.999%的可用度,即每年故障少於5分鐘(簡單地說,即每天故障1秒鐘)。這意味著當故障出現時,系統必須能自動處理,因為作業人員難以在很短的時間內移除或掩蓋任何故障。

硬體冗餘

與採用極可用元件建構單個極可用模組的硬體設計相較,使用由常規商業級品質的元件構成的常規商業級品質硬體進行冗餘複製模組設計,無疑具有更高的成本效益。

每個複製通常都要求具有‘快速失效’或‘失效即停’特性,這大幅簡化了故障管理決策。每次失效都使硬體在執行中停止,而不是試圖勉強執行下去並要求管理人員指出模組中哪些輸出產生故障,哪些則一切正常。

對於採用靜態冗餘的容錯,每個複製模組都具有常規的商用可用性。採用雙重覆制的模式稱為配對或雙路再使用(duplexing)。如果採用了N個複製,則稱為N路再使用(N-plexing)。

圖1顯示了3路再使用或3重冗餘硬體設計,這三重覆制均位於方框圖的底端附近。這些複製向‘表決器’提交輸出,表決器決定了子系統的最終實際輸出。在N路再使用設計中,當N≧3時,表決器通常採用多數決策策略。但是,這需要佔不失效複製的絕大多數,而不僅僅是佔複製總數(失效和不失效複製)的簡單多數。

然而,表決器的硬體和軟體不是類似於系統中的任何其他模組,也會失效嗎?實際上,確實如此;而且一旦失效,還會給系統帶來災難性的影響。但表決器通常極為簡單,因此可以透過設計和測試保證其強韌性。此外,還可以設計複雜表決器和二級表決器等複雜系統,但本文不準備進行深入討論。

對於採用動態冗餘的容錯,複製模組仍然只需具有常規的商用可用性。一種實現方法是採用由一個被啟動模組和一個備用模組組成的冗餘對。另一方法則採用一簇模組,這些模組不必是其他模組的精確複製,可以具有不同的特徵、介面和容量。這簇複製需要採用失效接替策略,這樣當主模組出現故障時,就能確定如何對多個模組進行管理。下面給出了一些選擇:

1. 熱備用。主模組在系統中執行時,備份模組處於‘熱備用’狀態,一旦主模組出現故障,備份模組將啟動並接管主模組。例如,可以採用這種方法設計高可用性的網際網路伺服器。

2. 轉動備用。主模組在系統執行時,可以具有許多備用模組。一旦主模組出現故障,一個備用模組將接管系統的執行。航空飛機上飛行電腦的設計就基於該原理:主模組由兩台總穩定工作的電腦組成,其中一個備用模組是一個相似對(similar pair),而第二個備用模組則是一台只能根據作業員指令接管系統的電腦。

3. 非關鍵模組的失效接替。主模組佔用系統的關鍵資源,備用模組則佔用其他非關鍵資源。一旦主模組出現故障,備用模組就能接管主模組佔用的大部份關鍵資源。日常生活中我們也常常這麼做:當我們試圖發送一封緊急的電子郵件時,如果電腦的高速網際網路連接出現故障,我們會立即切換到舊式的數據機。

4. 共同接管。每個模組均執行自帶的關鍵資源,而且一旦某個模組產生故障,其他模組還能接管故障模組的關鍵資源。例如,在功能增強的心護理室中,每8位病人將設置一台心臟監控電腦。如果一台心臟監控電腦崩潰,那麼鄰近的電腦也能對故障電腦監控的8位病人進行監控(或許性能將有所降低)。圖3:檢驗點設計模式的缺陷在於啟動或重啟伺服器需要進行許多處理才能恢復到

正確的失效接替實現非常關鍵。如果故障的主模組需要拋棄故障並繼續執行,而同時另一模組也試圖接管其業務,那麼後果將是災難性的,因為它們的業務有可能產生衝突。如果主模組拋棄故障後停止執行,而又沒有其他模組接管其業務,這樣的後果同樣是災難性的。因此失效接替的驗證和測試非常關鍵,儘管我們當中的許多人並不熱衷於此。

軟體冗餘

大多數硬體故障都是隨機產生並由實體缺陷導致,這些缺陷要麼在生產過程中維持不變,要麼隨元件的老化而不斷變化,要麼將受到外部實體環境的衝擊。相反,軟體故障與實體條件無關,因為軟體不會老化。與硬體故障不同,軟體故障源自對軟體設計或實現中固有故障的軟體路徑調用。由於軟體通常比硬體複雜,因此軟體中可能具有比硬體多得多的內建缺陷,因而導致軟體中的故障更多,容錯設計成本也更高。

N版編程(N-version programming)是久經考驗的一種軟體容錯設計方法。20世紀70年代偶然接觸到該方法時,那時還被稱為異質軟體(dissimilar software)。這是硬體N路再使用(如圖1所示)的等價軟體實現。但該方法比硬體N路再使用的複製機制複雜,N路再使用中相同軟體的N個複製將包含相同的故障並產生N次相同的錯誤。在N版編程中,如果N套軟體功能需要平行執行,那麼它們應當是該功能的N個不同實現,而且是由N個單獨的開發團隊獨立開發完成。這就是N版編程的基本原理。

1996年6月,當首次發射的阿麗安娜-5衛星發送火箭上升到4000米高空時,突然產生了爆炸。該事故的原因在於火箭的慣性參考系統(這是數位飛行控制的一部份)產生了故障。儘管慣性參考系統中導入了硬體冗餘,但軟體冗餘沒有得到正確的處理。阿麗安娜-5具有兩台慣性參考電腦,一台處於工作狀態,而另一台則處於‘開機’備用狀態。這兩套系統平行執行,並具有完全一樣的硬體和軟體。系統上的軟體也與先前已經成功發射的阿麗安娜-4幾乎一模一樣,但由於阿麗安娜-5上的某些飛行參數值比阿麗安娜-4大,因此數據產生了溢出。解決問題的方法是關閉電腦,由於冗餘電腦也在執行相同的軟體,因此也將受到數據溢出的衝擊,因而很快關閉,這樣整個慣性參考系統就完全崩潰。結果,引擎的噴管被回旋至極限位置,導致火箭突然轉向,並在自毀之前裂成兩半。這種處理數據溢出錯誤的方法適用於處理隨機出現的硬體錯誤,但不適用於處理兩台電腦上出現的類似軟體錯誤。N版編程可以避免兩台電腦出現類似的軟體錯誤。

在20世紀70年代,N版編程(N-version programming)是先進的軟體容錯設計方法。此後,這種設計模式引發了一系列問題:隨著該技術的採用,軟體開發成本直線飆升,因為必須成立N個單獨的團隊開發N套相互獨立的軟體。如果期望降低成本,則將陷入所謂的‘平均智商(Average IQ)’怪圈:較低成本的開發團隊意味著較低品質的軟體工程師,而這些工程師只能開發出較低品質的代碼。因此,最終只能得到充斥著以N種不同方式產生故障的N種不同程式。

N版編程面臨的另一個問題在於如何為N個獨立開發團隊提供輸入。一般情況下,將為所有的N個開發團隊提供相同的規格標準。然而,一旦規格存在缺陷,那麼將得到N個獨立開發的包含類似軟體故障的版本。如果系統發佈之後,規格或使用錯誤得到識別,那麼每個新錯誤都需要糾正N次,即N個不同的實現都需要加以糾正,這樣維護成本就相當驚人。現在,最佳的N版編程方法是讓第一流的軟體開發團隊,利用最可靠的底層架構、軟體開發工具、技術和測試來開發出高品質的軟體版本。

校驗點恢復

與基於靜態冗餘的N版編程不同,許多軟體容錯設計模式均基於動態冗餘。這些設計模式均包含以下四個步驟:


1. 故障檢測


2. 損害評估與 限制(有時也稱為‘防火牆處理’)


3. 故障恢復


4. 故障處理和業務繼續

步驟二中,當檢測到軟體錯誤時,一般可以採用失效保護。但軟體往往極其複雜,因此消除故障軟體導致的後果也並非輕而易舉。事務的概念是解決該問題的一個有效工具,事務是應用狀態下作業的集合,這樣事務的起始點和結束點均是應用的穩定狀態。例如,每個城市的市政廳都具有一個包含該城市所有居民資訊的文件系統。當一對夫妻結婚時,他們的姓名和結婚日期都記錄在一個命名為‘已婚夫妻’的文件中。另外,記載新郎從單身到已婚狀態變化的文件稱為‘男性居民’;記載新娘從單身到已婚狀態變化的文件稱為‘女性居民’。如果上述3個文件中的一個未能得到有效更新或者軟體在更新過程中突然崩潰,我們將不得不返回到該婚姻‘事務’的起始點。否則,將只會以不穩定狀態而告終,如新郎顯示為已婚狀態,而新娘則仍然顯示為單身狀態。穩定狀態只出現在婚姻事務的起始點以及得到成功處理的結束點。圖4:動態軟體冗餘的另一種設計是選擇一種數據處理方式作為主方式。

如果希望在容錯中導入事務概念,系統必須能在事務的起始點保存系統狀態,這稱為檢驗指示。檢驗指示需要在開始新事務之前迅速保存系統狀態,並且必須要求先前的事務以無差錯狀態結束。這?,一種基本的恢復策略是再執行方法:一旦事務中檢測到錯誤,事務將進行失效保護,系統將重新載入最近保存的檢驗點。這樣業務又能從檢驗點繼續執行下去,並允許在該穩定狀態上進行新的事務處理。然而,這樣將丟失進行失效保護的事務。這類故障恢復也稱為後向故障恢復,因為軟體狀態將還原到先前的一個無差錯點上。

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

流程對設計模式

檢驗點設計模式的一個缺陷在於故障恢復時間過長。啟動或重啟伺服器需要進行許多處理,才能恢復到檢驗點狀態。‘熱備用’伺服器與其自帶的?定大容量儲存設備的直接協同工作可以加速恢復,該設計模式也稱為流程對(process pair)設計,如圖3所示。

圖3中,方框圖中央是一個工作原理與先前檢驗點情形非常相似的主伺服器,客戶機直接與主伺服器協同工作。一旦主伺服器成功地完成整個事務,將傳送與新的穩定狀態相關的資訊至備用伺服器(右端的伺服器)。主伺服器和備用伺服器都將在?定大容量設備中記錄數據。這樣,備用伺服器就能保存完整事務的目前資訊。當主伺服器準備就緒並可供客戶機使用,將向備用伺服器發送常規的‘心跳消息(heartbeat message)’,這些心跳消息還可以同某些檢驗點消息相結合。一旦檢測到心跳消息流終止,備用伺服器就知道主伺服器已關閉或無法使用,進而作為一個新的主伺服器迅速接管事務。

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

儘管流程對設計模式具有諸多優勢,但仍有一些問題需要解決。例如,備用伺服器丟失了檢驗點消息或消息的順序不對,而且,當主伺服器是實體設備的控制器並在作業中產生故障時,也會產生問題。當備用伺服器接管事務時,不必知道如何完成作業,因為備用伺服器並不知道主伺服器失效之前究竟執行到哪一步。

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

恢復程式塊

動態軟體冗餘的另一種設計模式稱為恢復程式塊。該方法基於檢驗指示,但添加了對軟體處理結果的驗收測試。設計中必須準備數據處理的替代方法(就像在N版編程中一樣),但不必對每個事務執行所有的數據處理方法。相反,可以選擇一種數據處理方式作為主方式,並且首先只採用主方式處理事務。一旦主處理完成,即可執行驗收測試。如果驗收測試通過,則顯示主數據處理方式完全有效。如果驗收測試失敗,則可如圖4所示,繼續試驗下一個替代方案。

如方框圖所示,必須在首次進入恢復程式塊之前進行檢驗指示。每次失效的驗收測試之後,軟體必須還原到檢驗點狀態。每次嘗試替代的處理方法之後,都必須進行驗收測試。這樣,需要不斷進行處理方式更迭,直到提供通過驗收測試的處理方式。這些‘良好’的輸出構成了恢復程式塊的最終結果。

前向故障恢復圖5:為了控制飛機,要採用了兩套數位飛行數位系統。

檢驗點恢復、流程對和恢復程式塊都是後向故障恢復方法。大多數動態軟體容錯都採用後向故障恢復方法,但前向故障恢復也是不錯的選擇。前向故障恢復的基本思想是從錯誤狀態繼續進行並透過校正清除故障。前向故障恢復基於精確的錯誤損失評估,因此通常取決於具體的系統。異常處理就是前向故障恢復的一個典型例子,當檢測到問題,該方法就發送命令至專用的異常處理軟體,而不是返回到先前某個檢驗點狀態並繼續執行下去。

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

圖5中,為了控制飛機(波音777),同時採用了兩套數位飛行數位系統。框圖右側的決策邏輯電路將簡單飛行控制系統的輸出作為測試複雜的主飛行控制系統輸出的衡量標準。如果驗收測試失效,簡單飛行控制系統的輸出也可作為失效主輸出的替代,向左的箭頭表示替代處理的結果也可為主處理提供反饋。

上述設計模式使採用常規商業級品質的硬體和軟體為真正的高可用性系統構造程式塊成為可能,這樣的高性能系統無需人為干預,即可實現高達99.999%或更高的可靠性。

高可用性系統的基本概念

高可用性(High Available)系統,是指在某一台主機上特定的作業因主機設備異常而無法繼續運作時,可在最短的時間內在其它正常的主機上重新啟動該項作業。當前許多企業的系統是關鍵業務系統,需要不間斷為客戶提供服務,即使產生短暫的業務中斷,也會導致難以估量的經濟和名譽損失。

電腦系統的可靠性用平均無故障時間(MTTF)來度量,即電腦系統平均能夠正常運行多長時間,才產生一次故障。系統的可靠性越高,平均無故障時間越長。可維護性用平均維修時間(MTTR)來度量,即系統產生故障後維修和重新恢復正常運行平均花費的時間。系統的可維護性越好,平均維修時間越短。電腦系統的可用性定義為:MTTF/(MTTF+MTTR)*100%。

由此可見,電腦系統的可用性定義為系統保持正常運行時間的百分比。

藉由硬體冗餘或軟體的方法都可以從很大程度上提高系統的可用性。硬體冗餘主要是藉由在系統中維護多個冗餘部件如硬盤、網線等來保證工作部件失效時可以繼續使用冗餘部件來提供服務;而軟體的方法是藉由軟體對集群中的多台機器的運行狀態進行監測,在某台機器失效時啟動備用機器接管失效機器的工作來繼續提供服務。

參考文獻

1. SIAM (Society for Industrial and Applied Mathematics) News, vol. 29, #8, October 1996.


2. Chandra, Ramesh and Lui Sha. "On Scheduling Tasks in Reliable Real-Time Control Systems," Proceedings of the 20th IEEE Real-Time Systems Symposium, 1998

.

David Kalinsky是OSE Systems公司的客戶培訓主任,他是嵌入式軟體技術的講師和研究帶頭人。最近,David為即時和嵌入式系統開發的軟體工程編著了高科技培訓程式。之前,他還參與了許多嵌入式醫療和航空系統的設計。David於耶魯大學獲得核實體博士學位,他的聯繫方式是david@enea.com。





投票數:   加入我的最愛
我來評論 - 高可用性系統的硬體和軟體設計模式
評論:  
*  您還能輸入[0]個字
*驗證碼:
 
論壇熱門主題 熱門下載
 •   將邁入40歲的你...存款多少了  •  深入電容觸控技術就從這個問題開始
 •  我有一個數位電源的專利...  •  磷酸鋰鐵電池一問
 •   關於設備商公司的工程師(廠商)薪資前景  •  計算諧振轉換器的同步整流MOSFET功耗損失
 •   Touch sensor & MEMS controller  •  針對智慧電表PLC通訊應用的線路驅動器
 •   下週 深圳 llC 2012 關於PCB免費工具的研討會  •  邏輯閘的應用


EE人生人氣排行
 
返回頁首