基于ＲＴＥＭＳ的軟件容錯系統設計
2009-01-01 00:00:00李小群張文君潘遠明肖賀郭亮姜志穎
計算機應用研究 2009年3期
(中國科學院 軟件研究所， 北京 100190)
摘 要：在空間環境下運行的計算機系統，高空輻射可能引發各種各樣的異常或錯誤而導致故障。為了提高系統的可靠性，同時盡可能減少對系統實時性能的影響，需要對其進行有效的容錯。針對節點和應用軟件的故障檢測和故障恢復進行研究與分析，提出了多種靈活有效的軟件容錯策略與設計方案，并基于四節點的多機硬件體系結構和RTEMS軟件操作系統，設計并實現了一個系統原型。運行結果顯示，該方案有效地提高了嵌入式實時系統的可靠性。
關鍵詞：實時多處理器系統； 軟件容錯； 高可用； 高可靠； 硬實時
中圖分類號：TP302.8 文獻標志碼：A
文章編號：10013695(2009)03091103
Design of software faulttolerant system based on RTEMS
LI Xiaoqun， ZHANG Wenjun， PAN Yuanming， XIAO He， GUO Liang， JIANG Zhiying
(Institute of Software， Chinese Academy of Sciences， Beijing 100190， China）
Abstract:Computer systems running in the space environment need faulttolerant mechanisms to enhance their reliability. This paper gave various flexible and effective ways of software fault and system design scheme， and also designed and implemented a tolerant system based on four nodes hardware system and RTEMS OS. The results show that this scheme effectively improves the reliability of embedded realtime system.
Key words：RTEMS（realtime executive for multiprocessor systems); software faulttolerance; high available; high reliability; hard realtime
0 引言
在航空航天領域應用的計算機系統中，由于使用的集成電路日趨復雜，因惡劣太空環境而引起的器件失效是導致系統可靠性下降或者失效的根本原因之一。低軌衛星可以受到地球磁場保護，而運行于較高軌道的衛星則會經歷來自地球輻射帶、銀河宇宙射線、太陽粒子事件等明顯的輻射環境，航天設備受輻射的影響將非常大，因此空間輻射效應是航空航天系統設計必須要考慮的首要問題。高空計算機系統最主要的破壞源來自于單事件效應(單事件效應是指單個高能粒子導致的電子器件狀態改變，它對星載器件尤其是微電路和功率器件有著嚴重影響）。這些對航天器的高容錯技術提出了挑戰。
為了保障航天器安全可靠地運行，在通常的避錯和被動式容錯技術的基礎上，需要大力發展和應用自主式故障診斷及系統重構等容錯技術，發展空間智能自主控制技術，對航天器控制系統故障進行分析和對策研究，使系統具有自主故障診斷和重組、重構的容錯控制能力，以提高系統可靠性。而在硬件環境已經確定的情況下，如何在系統運行時監控應用的運行狀態；快速檢測系統中軟件故障并快速將系統從非正常狀態恢復過來；如何為高空環境下的計算機系統提供更有彈性的軟件容錯組件配置，使系統具有更好的彈性與容錯支持；如何在容錯狀態下確保硬實時等方面的性能均是實踐中值得進一步探討的問題。
本文針對以上問題和實際的應用需求，在四個完全相同CPU節點的容錯硬件環境上，分別從操作系統選型、節點間心跳、代碼糾錯、檢查點以及容錯策略的配置等角度考慮軟件的容錯，設計并實現了一個針對節點和應用軟件的故障檢測和故障恢復系統原型。
1 軟件容錯方案
1.1 基于RTEMS的軟件環境
在空間環境中運行的系統需要具備較好的容錯能力，并要求支持硬實時，即系統必須對某些事件作出及時響應，否則將會產生災難性的后果。RTEMS是一個開源的實時嵌入操作系統[1，2]。目前，航空航天、軍工以及民用領域都有極為廣泛的應用。它具有以下優點：
a）實時性能：(a)支持硬實時和軟實時（可搶占內核）;(b)支持優先級繼承，防止優先級反轉;(c)支持單調周期調度;(d)支持優先級高度協議。
b)支持多種CPU，如ARM、MIPS、PowerPC、i386、DSP等。
c）高度可剪裁內核，占用系統資源小。
d）支持多處理器。
e）提供POSIX API。
f）提供完整的BSD的TCP/IP協議棧。
g）支持ISO/ANSI C/C++庫以及STL庫，支持精簡的可重入glibc庫。
h）支持圖形用戶界面（Microwindows/NanoX）。
i）支持文件系統（FAT、IMFS等）。
RTEMS經過長期的發展和應用，整個系統穩定成熟、可靠且體積小、運行速度快，適合于空間嵌入式環境中。因此本文選擇RTEMS作為整個容錯軟件系統的基礎運行平臺。
1.2 容錯層次結構
整個系統的硬件環境為原先設計和研究的多計算機體系結構。如圖1所示，多機系統由一個主節點和三個從節點組成。主節點運行應用任務主控程序，負責控制各種應用任務在整個系統中的部署、應用數據的分發、系統內外的數據交換等；從節點運行應用任務執行程序，負責執行具體的應用任務。假定各應用任務相互獨立。
以上四個節點處理器完全相同，主、從節點關系從邏輯上劃分，各節點在硬件上相互冗余備份。
如圖2所示，容錯系統自底向上分為容錯硬件、操作系統內核、容錯軟件組件和應用程序四個層，其中容錯硬件與應用程序超出了本文的討論范圍，在此不作討論。
1.3 容錯組件與整個系統的關系
整個系統由硬件和軟件兩大部分構成。容錯組件與整個系統的軟/硬件關系如圖3所示。系統的軟件部分在開源的RTEMS操作系統基礎上，采用心跳檢測、檢查點、不變量檢測、海明碼糾錯等技術增強系統的容錯功能。
1.4 容錯組件的體系結構
本系統僅關注軟件容錯，主要包括如下幾個方面的功能：
a)失效檢測。對于用戶的應用程序，提供了海明碼檢測、不變量檢測、基于RTEMS的異常處理機制、軟件看門狗四種策略；對于節點級的軟件檢測策略，采用心跳機制實現。
b)失效處理。無論是節點故障還是應用程序故障，均可以選擇采用整個節點重新啟動，或者基于檢查點的保存和回滾恢復方法。圖4具體描述了本系統中容錯組件的主要框架結構。
1.5 容錯策略的定制
為了增加系統的靈活性，盡可能地滿足各種應用場景和用戶的需求，同時最大限度地保證系統的容錯和強實時性能，本系統對應用程序故障檢測和節點故障檢測，以及故障恢復均提供了多種策略供用戶配置和選擇。
用戶可以通過動態、靜態兩種方式來定制系統的容錯策略。一種方式是通過配置文件的方式靜態設置，若用戶事先沒有建立自己的配置文件，系統將自動啟用默認的配置文件；另一種是通過API接口函數，用戶需要哪種策略，直接調用系統管理模塊進行設置即可。兩種方式各有優缺點，詳細實現將在下一章中介紹。
2 實現與分析
2.1 應用失效檢測
對于應用失效的檢測，主要提供海明碼檢測、不變量檢測、異常處理機制、看門狗機制四種方式，供用戶依據實際應用場景選擇。
2.1.1 海明碼檢測
該方法檢測運行過程中，對系統和應用程序的代碼部分是否受到環境中粒子的影響而發生變化進行檢測。如圖5所示，代碼段檢測通過周期性地計算代碼段的簽名與內存中的代碼段簽名是否由于外界環境影響而出現錯誤。在RTEMS系統加載之后，計算并保存整體代碼部分的簽名，作為檢測的評判標準；而檢測系統則定時遍歷整個系統的代碼段，重新計算代碼段的簽名，并與保存的簽名相比較，依據比較結果判定代碼段部分是否在運行過程中出現了錯誤。當系統檢測到錯誤時，調用應用失效處理模塊進行處理。
2.1.2 不變量檢測
系統運行過程中，應用程序的不變量可能受到外界環境的影響而發生變化。當值發生改變時，可能導致計算結果錯誤甚至系統崩潰。為檢測應用程序不變量在系統運行過程中是否因外界環境的干擾或應用程序本身的缺陷而發生變化，系統采用周期性執行針對該不變量的測試函數來檢測內存中的不變量值是否已發生改變。其中，檢測函數在開發階段由開發工具自動生成。為滿足開發需求，對開發工具作了相應的修改，本文對此不作討論。
2.1.3 異常處理
利用RTEMS異常處理機制，實現應用失效檢測。任何系統都無法預見所有異常，程序員也無法完全保證設計的程序捕獲了所有異常；外界環境的改變也可能對系統產生干擾而造成不可預知的異常，如處于高輻射環境的計算機，存儲當前任務某條指令的存儲器單元可能因為一個粒子的轟擊而導致某個狀態的改變，這種存儲器跑飛的情況，也會造成異常的產生。對于以上不可預知類型的錯誤，RTEMS采取了一種簡單而有效的處理方式：當異常產生時，操作系統發生一次陷入，進入到RTEMS的異常處理例程中。RTMES的異常處理函數首先查看是否有用戶自定義的出錯處理函數，如果有，則調用執行；否則執行RTEMS本身自帶的默認異常處理函數。因此，可以利用RTEMS的異常處理機制，自定義異常處理函數，當任務發生無法預料的異常時，RTEMS的異常處理例程就會自動調用它。
2.1.4 軟件看門狗機制
利用看門狗進行應用失效檢測的基本思想是：應用失效檢測模塊創建一個定時器（稱為看門狗定時器），應用程序需要在一定時間內復位該定時器，以表明自己在正常運行；否則，定時器超時將觸發其服務例程，從而轉入應用失效處理模塊的失效處理過程。整個檢測過程需要應用程序與應用失效檢測模塊共同完成，基本的定時器功能由RTEMS定時器管理器提供。
2.2 節點失效檢測——心跳檢測
對于節點失效檢測，目前本系統中采用心跳檢測機制進行檢測。主節點與從節點間利用已有的通信機制傳遞心跳消息。主節點根據獲得的消息，對從節點是否失效進行檢測。節點之間的心跳消息傳遞如圖6所示。
系統采用定時器驅動的心跳檢測機制。定時器到期，所有從節點上的心跳模塊向主節點發送心跳消息，主節點上的心跳模塊對所有從節點發送心跳反饋消息，并根據從節點發送的消息是否到達來判定從節點是否失效。若主節點在一定時限內沒有收到某從節點發來的心跳消息，則判定該從節點失效，并調用失效處理模塊，執行失效處理任務。
2.3 失效處理
用戶可根據具體的應用場景配置系統采用以下兩種方式進行失效處理。
1)節點重新啟動
無論是應用失效，還是節點失效，都可以依據配置系統的配置采用失效節點重新啟動來處理失效。如果在規定的時限范圍內連續三次重啟失敗，則認為該節點已經徹底損毀，通知管理模塊，并隔離該節點，系統降階運行。該機制由硬件容錯處理模塊處理，具體細節本文不再詳述。
2)檢查點保存—回滾恢復機制
利用檢查點保存—回滾恢復機制進行失效處理。系統正常運行過程中，在離散時刻（稱為檢查點）保存從節點系統狀態；在檢測到應用失效時，回滾至最近保存的檢查點的系統狀態，并繼續執行。檢查點狀態保存在如圖7所示的主、從節點共享內存中的預留區域。
根據用戶或者系統設定的策略，保存所有從節點的內存信息。具體有如下兩種策略：
a）主節點保存
主節點如果能夠讀取到從節點所有內存信息， 在主節點對每個從節點執行檢查點保存操作。
b）從節點保存
(a)主動保存。從節點啟動時得到配置信息， 自己定時作檢查點保存，或者按照一定策略作檢查點保存。
(b)被動保存。主節點由配置信息確定檢查點保存策略， 定時或者手工方式向從節點發出保存請求， 從節點進行相應操作。
2.4 容錯策略的定制
2.4.1 API函數接口
由應用程序調用系統提供的容錯API時，系統可以不作任何容錯功能的配置，而是將各種容錯機制以API接口函數的形式提供給用戶，由用戶根據應用的需要在應用程序中調用。調用方式有手動調用、定時器調用等多種方式。限于篇幅，具體API函數接口不在本文中詳細描述。
2.4.2 系統配置文件
系統中有多種策略可供用戶靈活選擇，甚至有些項可以多選，用戶可以通過配置文件配置整個系統，或者采用系統默認的配置文件。部分配置項如表1所示。
3 結束語
在空間環境中運行的系統，對強實時性和高容錯性都有很高的要求，采用多種靈活、可靠的方式設計系統是非常重要的。針對某種特定的應用，用戶可以根據其具體應用背景，定制不同的策略組合，從而兼顧用戶期望的實時性與容錯性。本文從軟件容錯角度對這些問題進行了探討，并在此基礎上實現了系統原型。
參考文獻：
[1][EB/OL].http://www.rtems.net/article.htm.
[2][EB/OL].http://www.rtems.com/.
[3]孫鵬，趙軍鎖，張文君. 基于RTEMS的軟件容錯系統設計研究[J].計算機工程與科學， 2007，29(8):9498.
[4]張靚，劉光明.RTEMS嵌入式系統中的軟件容錯設計[J].計算機工程與科學，2007，29(5):147151.
[5]田東，陳蜀宇，陳峰. 一種網格環境下的動態故障檢測算法[J]. 計算機研究與發展，2006，43(11):18701875.
[6]謝斌，高揚. Linux高可用集群心跳機制研究[J]. 計算機工程與應用，2004，40(1):6567.
[7]ROBERTSON A. LinuxHA heartbeat system design[C]//Proc of the 4th Conference on Annual Linux Showcase Conference. 2000:20.
[8]CHEN W， TOUEG S， AGUILERA M K. On the quality of service of failure detectors[J]. IEEE Trans on Computers，2002，51(2):1332.
[9]CHANDRA T D， TOUEG S. Unreliable failure detectors for reliable distributed systems[J]. Journal of ACM，1996，43(2):225267.
[10]AGUILERA M K， CHEN W， TOUEG S. Failure detection and consensus in the crashrecovery model[J]. Distributed Computing， 2000，13(2):99125.
[11]ROBERTSON A L. The highavailability Linux project[EB/OL]. http://linuxha.org/.
[12]HARALD M. The Linux high availability HOWTO[EB/OL].（1997）.http://www.vergenet.net/linux/redudant_content/related/linuxha/highAvailabilityHowto.html.
[13][EB/OL].http://linux.math.tifr.res.in/sysadmin/HighAvailability HOWTO.html.
