一種故障管理系統的層次化結構設計

摘 要:基于故障管理基本原理，提出了一種故障管理系統的層次化結構設計方案，分析了該層次化結構的基本特征，并研究了該結構在高端服務器上的實現技術。實際應用表明，該結構具有可行性，基于該結構實現的故障管理系統可較好地提高服務器可靠性。

關鍵詞:故障管理; 錯誤處理; 故障診斷; 故障修復

中圖分類號:TP311文獻標志碼:A

文章編號:1001-3695(2010)03-00961-05

doi:10.3969/j.issn.10013695.2010.03.042

Design of layered structure for fault management system

TIAN Xin， LIAO Xiang-ke， SHAO Li-song

(College of Computer， National University of Defence Technology， Changsha 410073， China )

Abstract:Based on fault management theory， this paper proposed a layered structure of fault management system. Illustrated the essential characteristics of this layered structure， then studied the implementation of this structure on high performance servers. Practical application demonstrates the structure is feasible and fault management system based on this structure can improve the reliability of servers.

Key words:fault management; error handling; fault diagnosis; fault repair

現代商業應用對于服務器可靠性提出了很高的要求，這需要系統具有可靠的預測性故障檢測功能和自動的故障隔離修復功能。在高端服務器中設計部署故障管理系統，實現故障預測、診斷和處理的集中化、自動化和智能化，這對于服務器可靠穩定地運行具有重大意義[1]。

故障管理系統主要針對硬件故障。硬件故障主要來自三個方面:CPU內存、I/O設備和電源制冷等機架系統。硬件故障管理常常需要硬件、平臺固件和操作系統一起協同實現，甚至還可能需要其他的輔助處理器[2]。本文的主要貢獻為:通過對現代高端服務器的故障管理基本原理和特性的研究，提出了一種故障管理系統的層次化結構設計的基本思想。該層次化結構實現了故障管理系統的錯誤處理、故障診斷和故障修復三大功能組件;具備強大的硬件拓撲結構描述能力，可自主設計與服務器硬件拓撲結構相適應的故障診斷規則;具備可擴展的事件協議，可精確并完備地描述各類錯誤和故障狀況;充分考慮了現代服務器的多域特性，可在多域中部署并協作，以實現故障管理性能的最優化。

1 基本原理

在故障管理研究領域內，錯誤和故障的含義不同。錯誤是指系統某次事務中的異常行為，而故障是指系統組件在物理上的異常狀態[3]。一系列的錯誤可能反映某個系統組件發生故障，但某次系統事務出現錯誤并不意味著一定有系統組件故障。例如，數據傳輸中可能會通過ECC校驗發現一些數據位錯誤，只要錯誤位不是太多，此錯誤就可被糾正，因此只要這種錯誤出現的頻率不高，就可認為傳輸鏈路上沒有故障;然而出錯頻率若高過一定門限，或錯誤位太多無法糾正，就意味著有故障出現了。另一方面，即使某組件客觀上存在故障，相關系統事務也不是肯定會產生錯誤，但是如果有其他因素綜合作用，就可能導致錯誤，故障是潛在的錯誤誘因。

錯誤處理和故障修復也不同。錯誤處理是指糾正某次系統事務的異常行為，對其造成的負面影響進行恢復;故障修復則是從物理上修復或屏蔽故障組件。如果錯誤是由系統組件故障引起的，單靠錯誤處理并不能從源頭上消除故障，必須通過診斷錯誤信息獲知故障源，對故障組件進行修復或替換，才能根除故障。這兩者含義上也可能有重疊的部分，通常將一些更為實時的恢復動作視為錯誤處理。

故障管理系統通過監控系統運行的異常行為，即所謂的錯誤，來及時發現組件的故障。故障管理系統會實時監測并糾正錯誤，并根據系統運行的錯誤信息形成錯誤事件，自動分析、診斷錯誤事件，確定故障狀況，對故障作出力所能及的自動修復相應。

如圖1所示，故障管理系統主要包括錯誤處理器、診斷引擎和故障響應代理三個功能部件[2]。

1)錯誤處理器 負責檢測、糾正和報告錯誤事件。當錯誤處理器檢測到某個硬件組件運行出現問題時，生成描述問題細節的錯誤事件，并將其分派給合適的診斷引擎進行故障診斷。錯誤處理器還可能對錯誤事件進行初步的應急處理，如立即隔離導致致命錯誤的硬件部件等。

2)診斷引擎 負責對錯誤事件的診斷。每個診斷引擎首先需要向故障管理系統預訂一類特定的錯誤事件，也就是說，一個診斷引擎只能診斷一類特定的錯誤，因此系統中存在若干診斷引擎[4];然后，根據預訂，錯誤事件才能轉發給正確的診斷引擎，進行異步故障診斷，并生成描述診斷結論的故障事件。當遇到診斷能力有限，無法將錯誤事件歸結為某個確定的故障事件，診斷引擎會給出所有可能的故障事件列表，并給每個故障事件標記上可信程度[2]。最后，診斷結論會轉發給故障響應代理，作為故障修復的依據。

3)故障響應代理 依據診斷引擎給出的故障事件，對發生故障的硬件組件進行隔離或修復，或者在必要時以日志的形式通知管理員采用人工方式修復故障硬件部件。

2 當前研究現狀

傳統操作系統在發生故障時僅僅是將元件錯誤信息以獨立系統日志消息的形式直接報告給管理員[1]。這種機制缺乏一個統一的錯誤故障報告渠道，錯誤處理工作分散和復雜;更關鍵的是，診斷和修復完全人工化，沒有實現故障管理的自動化。

目前，故障管理研究包括硬件檢錯糾錯、故障管理軟件設計等方面。

Intel和AMD的很多處理器現在都支持MCA[5]，利用此機制實現服務器的錯誤處理和錯誤報告。MCA錯誤處理是軟硬協同實現的，主要包括硬件、固件和操作系統三個層面[6];它有強大的處理器檢錯糾錯能力，為處理器和系統芯片組、系統固件和操作系統提供了可靠運行環境。但是這種故障管理機制具有以下幾個局限性:a)本身不具備故障診斷能力，不能判斷處理器有什么故障，它只能向操作系統報告錯誤信息，由管理員或故障管理軟件進行診斷;b)MCA主要是在操作系統以外，在硬件或固件上實現，由此帶來的平臺相關性使系統管理者必須花費大量時間來閱讀各類平臺特性的錯誤日志消息，才能作故障診斷，判斷如何修復故障。即使有故障管理軟件，管理軟件也面臨著不同平臺與供應商設備錯誤報告標準不統一的問題。

HP提出了一種利用基于Web的企業管理標準、模塊化的硬件診斷工具SFM[7](system fault management)，為來自不同供應商的系統元件提供了統一的故障管理平臺。SFM可監視系統運行狀況，以中間件的形式將獲得的硬件狀態和錯誤狀況向管理員匯報，管理員和診斷工具可根據這些信息定位故障元件。SFM雖然有強大的平臺兼容性和系統監視能力，然而其診斷系統卻不夠完善，不但需要專門的診斷程序配合，且這些診斷程序主要采取主動測試硬件的算法，故障預測能力差，而且其提供的修復能力和力度都很有限。

3 故障管理系統層次化結構

在硬件和固件檢錯部件的基礎上，設計故障管理系統，實現錯誤處理器，診斷引擎和故障響應代理三大部件為不同架構和來源的硬件構建統一的故障管理平臺，這樣才能實現硬件故障預測、診斷和處理的集中化、自動化和智能化。故障管理系統設計的目標是:能夠集中持續有效地進行整個系統的故障管理;能夠有效地檢測錯誤，診斷故障乃至預測故障;能夠對故障元件進行細粒度的隔離和重啟，為管理人員提供可行的故障處理建議。

如圖2所示，本文提出一個故障管理系統的層次化結構，故障管理系統由三個組件組成，即錯誤處理件、故障診斷和故障修復。這三個組件分別完成故障管理系統三個功能部件的功能。在多域服務器系統中，三個組件可以部署在不同的環境中，它們之間通過傳輸層的通信協議聯系。

故障管理系統的設計需要考慮三個問題:為硬件錯誤行為、故障源硬件和故障源產生錯誤的規則等系統運行的實際要素與故障管理系統之間的交互提供抽象接口;為系統運行實現統一的故障管理服務;為故障管理各部件間交互錯誤與故障狀況信息提供一個規范。因此，故障管理系統結構可以分為四層，即資源層、故障層、事件層和傳輸層，這些層次是自頂向下透明的。

1)資源層 是對系統運行中與故障管理相關的三個實體要素的抽象，這三個要素是硬件故障源、硬件故障引發的錯誤行為、故障源引發錯誤行為的規則。在系統運行時，故障管理系統僅與這些要素進行交互即可實現故障管理服務，這些要素為故障管理系統封裝了整個機器硬件實體。資源層為故障管理系統提供了對所有硬件的規范化描述和合理建模，這不但是故障管理服務正確運作的基礎，也便于編程實現，同時也有利于分析系統運行故障的機理。另外，資源層還包括一些接口，供這些要素與故障管理系統交互。

2)故障管理層 該層是故障管理系統的核心層，為硬件資源提供故障管理服務，各組件的具體功能模塊在這一層實現。錯誤處理組件的感知器監控錯誤行為，故障診斷組件的各個診斷者模塊根據錯誤行為和故障源引發錯誤的規則診斷故障，故障修復組件根據故障診斷結果對故障源進行修復。

3)事件層 該層以事件協議的形式為故障管理層各模塊間交互錯誤與故障狀況信息提供統一規范。事件層主要包括描述器和分派器兩種模塊:描述器根據事件協議生成合適類型的錯誤或故障事件來描述錯誤或故障信息;分派器則根據事件協議和故障管理層各模塊對各類事件的預訂將某類事件分派到正確的事件消費者那里，以實現故障管理層各模塊的正確交互和故障管理服務的正確運作。

4)傳輸層 該層是對事件從事件層描述器生成到交給其消費者這一傳遞過程的封裝，為協議事件在產生者和消費者之間的傳輸提供了通道。在多域服務器系統中，可能部署多個故障管理系統協同工作，這些故障管理系統間可能會交互錯誤或故障事件;故障管理系統的三個組件也可能部署在不同域中。這時，協議事件的產生者和消費者間的傳輸可能是遠程的，此時傳輸層可為用戶封裝底層的通信渠道，通信可能基于不同的信道和通信協議。考慮到事件在多域間傳遞的復雜性，事件協議不應對事件的通信編組機制和傳輸機制作定性要求。

3.1 資源層

本文將系統中所有硬件統稱為資源。資源層通過對系統運行中與故障管理相關的故障源、錯誤行為、規則三要素的抽象，為故障管理系統封裝了其故障管理服務的對象，即所有硬件。故障管理系統只需與這些規范化描述的要素交互，就可為硬件提供故障管理服務。錯誤處理組件負責監控硬件故障引發的錯誤行為，若發現錯誤，就會觸發故障診斷、修復等一系列過程;故障診斷組件的診斷過程則需要查詢故障源引發錯誤的規則;故障修復組件的修復行為則作用在硬件故障源上。資源層的三要素正是對系統運行中故障現象的描述:故障源根據規則引發了錯誤行為，而故障管理服務則是其逆過程，由錯誤行為出發依據規則反推出故障源，并進行修復。

故障修復組件的修復行為直接作用于故障源，這需要在硬件拓撲結構中定位故障源位置。為此，資源層需要提供一套資源描述標志符機制，規范化地命名所有硬件資源，此命名攜帶該資源在整個硬件拓撲結構中的位置信息。此外，對于硬件來說，無法無限細微粒度地進行故障修復，還需要根據修復行為的可作用粒度，界定一個合理范圍的故障區域，作為故障修復的對象。

故障診斷組件需要查詢故障源引發錯誤的規則，了解故障和錯誤行為間的關系，作為診斷故障的依據[3]。對于較為復雜的規則，可以設計一套規則描述語言，資源層使用該語言描述故障和錯誤行為的關系，診斷者編譯并閱讀這些語言描述的規則。此外，故障源引發錯誤的規則與硬件拓撲結構息息相關，因而規則的描述也需要規范化的硬件拓撲描述機制，資源層可利用前面提到的資源描述標志符機制來命名資源，在此基礎上描述硬件的拓撲結構。

錯誤處理組件需要監控資源層硬件運行錯誤，這需要資源層提供一定的檢錯報錯接口，常見的如用于CPU的MCA檢錯機制[6]， I/O設備的狀態寄存器、數據傳輸校驗等。發現錯誤的那個資源在硬件拓撲中的位置是診斷的重要依據，如同定位故障源一樣，這也要求資源層利用資源描述標志符機制來描述資源的拓撲位置。

3.1.1 資源描述標志符

資源層對于故障源、錯誤行為、故障源引發錯誤的規則三要素的抽象都離不開對資源的規范化描述機制。本文使用故障管理資源描述標志符(FMRI)來命名資源并描述資源拓撲位置。FMRI包括所有者域和位置域兩部分。在一個由SP和多硬件域組成的系統中， FMRI的所有者域可用來辨別處于平臺、SP中或分配到各域中的資源，而位置域則描述資源在拓撲結構中的物理位置，如CPU的FMRI位置域可由它的CPU ID號和它所在的主板ID號組成。錯誤事件必須攜帶一個FMRI標志符來記錄發現錯誤行為的那個資源，以協助故障診斷。故障事件也可以攜帶故障源的FMRI來指引修復行為。

3.1.2 故障區域

不可能無限細粒度地去修復一個故障，如即使知道內存有哪幾個地址單元故障，也無法單獨對這些單元進行修復，只能將內存整體替換。在描述故障源時，須根據修復行為可以作用的最小粒度對資源作合理的劃分，確定某范圍的資源作為修復對象，這才有可行性。

本文將系統建模成一組分層的、重疊的故障區域，以此作為對軟硬件資源的邏輯劃分。故障區域界定了故障源在系統中的物理位置，如果說資源發生了故障，其實是在說該故障區域內的資源發生了故障。

故障區域的劃分與修復行為能夠作用的資源粒度密切相關。通常，自動的故障修復是通過配置軟件對硬件重新配置(包括屏蔽硬件或進行其他配置狀態修改)來實現的，將系統中可以由軟件進行重新配置的最小粒度的資源單元叫做自動可重配置單元(automatic system reconfiguration unit，ASRU)。考慮到自動修復的需要，故障區域可以沿著ASRU來定。故障事件可攜帶此ASRU信息，告知故障源在哪里，為修復故障該對哪些資源進行重新配置。

有時自動的軟件配置修復已不能徹底恢復故障，需要人工介入，此時須提供更粗粒度的故障源描述。可用整體可替換單元(field replacement unit，FRU)來描述。FRU指可在物理上從系統中整體替換出來的最小單位部件，如一個內存條的每個地址單元都可以視為一個資源，但只能將整個內存條劃分為一個FRU單元;故障事件可提供FRU信息，建議系統維護人員修復或替換此FRU來從系統中消除故障。因此，自動診斷引擎必須具備診斷小到ASRU粒度的資源單元的能力，這樣才能提供足夠詳細的信息來實現故障的自動響應處理，否則就不得不人工介入來修復故障了。

當然，若有更為強大，覆蓋細微資源粒度的診斷和修復能力，故障源描述還可以更細化一些，故障區域的劃分粒度甚至可以小于配置軟件的粒度，小于ASRU。細化故障區域有助于實現修復功能，但這需要診斷系統和修復系統的進步。

3.1.3 規則描述語言

發生故障的硬件(故障源)可能會引發一系列的連鎖錯誤，有時，某種錯誤行為又是多個故障源或其他錯誤綜合作用引發的。若將系統中各個故障源，各種錯誤行為表示成節點，以節點之間的有向連線表示它們之間的引發關系，就形成了一個抽象描述機器系統中硬件故障機理的故障樹[3]。故障樹節點間的引發關系通常需要滿足一定的約束條件，而這些引發關系和約束條件則跟硬件資源結構和硬件運行特性密切相關。故障樹反映的故障機理體現了故障源和錯誤行為之間的關系，是故障診斷的依據。可設計一種規則描述語言，用代碼來描述這種故障樹，故障管理層診斷者模塊編譯這些代碼，即可獲知故障源引發錯誤的規則。

3.2 故障管理層

故障管理層為資源層提供故障管理服務，是故障管理系統的功能實現部分。錯誤處理組件、故障診斷組件、故障修復組件在本層分別實現了故障管理系統的三大功能部件，即錯誤處理器、診斷引擎和故障響應代理。因此，故障管理層是故障管理服務的直接提供者，是故障管理系統的核心層次。

錯誤處理組件在故障管理層部署很多感知器，感知器利用資源層提供的檢錯接口監控資源層硬件的運行錯誤。當感知器觀察到資源層硬件出現錯誤時，首先將進行錯誤處理，嘗試糾正錯誤，恢復錯誤帶來的惡性影響，并搜集錯誤的細節，將這些細節數據交給事件層，申請生成一個錯誤事件。這種監控可以有兩種方式，即操作系統中設備運行上下文實施的自發監控，服務處理器SP 和平臺固件實施的監控[8，9]。前者主要用于監控I/O設備的錯誤，后者主要用于監控CPU、內存等硬件的錯誤。

故障診斷組件在故障管理層實現若干診斷者，事件層生成的錯誤事件最終會被提交給這些診斷者。故障管理層應具備多個診斷者，每個診斷者負責診斷某一大類的錯誤事件[4]，如 CPU有專門負責診斷CPU故障的診斷者，該診斷者還可以有不同的實現以匹配不同平臺架構的CPU。診斷者會根據資源層提供的該硬件系統中故障源引發錯誤的規則，利用一定的診斷算法推斷出故障源在哪里。

通常錯誤事件和故障不是一一對應的，也就是說，常常是一個錯誤序列反映一個故障。為組織這些錯誤序列，定義病歷為包含與某資源某次故障相關的所有錯誤信息的抽象結構。每當出現與某個系統資源相關的錯誤事件時，診斷者判斷此錯誤事件與該資源的哪個現有病歷有相關性，如果有相關，就將錯誤事件放入相關病歷，如果沒相關或者該資源尚無病歷，就新建一個病歷。診斷者分析同一病歷中的癥狀信息(一個錯誤事件集)并根據一定的診斷算法獲得診斷結果，然后通知事件層生成一個故障事件。

故障修復組件在故障管理層實現若干執行器，事件層生成的故障事件會交給這些執行器。故障修復組件有多個職責不同的執行器。執行器在接收故障事件后對其所標記的故障源作自動修復。執行器可以通過重配置軟件屏蔽或再配置故障資源來實現故障的自動隔離與修復，重配置的對象是資源層的某個ASRU。

執行器還必須向系統控制臺發送消息，此消息不但告知系統管理人員故障狀況信息，還攜帶故障源的FRU信息，以提示管理人員在必要時替換故障源所在FRU來從系統中徹底消除故障。這樣就通過軟硬結合、人機協作的形式實現故障的自動隔離和可靠消除。

3.3 事件層

3.3.1 事件協議

本方案的事件層是故障管理系統各組件間交互的媒介，事件流驅動故障管理服務的運作。本文使用FMA(fault management architecture)事件協議[3]來作為描述故障管理系統中錯誤、故障等各類事件數據結構的統一規范。FMA協議定義事件的屬性成員，通過它們就可獲得錯誤事件，故障事件的特性，可把這些事件作為診斷者、執行器等的輸入。

錯誤和故障事件可在許多不同的環境中生成，并在這些環境間傳遞[2]。每個事件生成環境都有自己的限制和需求。鑒于此，FMA協議只規定事件的格式和屬性成員，而不限定數據的編組技術和傳輸機制。數據編組技術可以是SP的郵箱消息[9]、名值對編碼技術等;傳輸機制可以是系統事件傳輸機制[10]、SP的郵箱投遞機制[9]、各種基于網絡的IPC方法等。

FMA協議對事件進行分類，賦予事件全局惟一的類名。事件被組織成一個分層樹型結構，稱此樹為協議事件樹[3]。事件樹的葉節點表示具體某一類事件，而各子樹的根節點則描述了本子樹內各事件的共性。事件樹中某一葉節點所代表事件的類名是從根節點到該葉節點的路徑上各節點描述符的集合，如錯誤事件的類名為“ereport.*.*.*”的形式。這種層次化的類名清晰地反映了各類事件之間的共通性、隸屬性和親緣關系，同時使得協議事件的消費者(診斷者、執行器等)能夠很方便地根據事件的類名向分派器預訂自己需求的事件，并從分派器中過濾出已預訂的事件來投遞到自己的事件隊列中。

3.3.2 事件層的功能

事件層為故障管理服務提供事件協議支持，根據故障管理層的需求生成協議事件，并按照事件消費者對各類協議事件的預訂分派事件。事件層包括生成協議事件描述錯誤或故障狀況的描述器和分派協議事件的分派器。描述器遵循FMA事件協議的規定，利用故障管理層傳遞過來的事件原始數據組裝生成協議事件，根據協議事件的類名，事件在協議事件樹中有一個節點相對應。分派器在收到事件后，按照其類名在協議事件樹中尋找對應節點，從而將事件分派給預訂了該節點代表的那類事件的事件消費者。

錯誤處理組件在本層實現一個錯誤描述器，將故障管理層感知器監控到的錯誤信息按照事件協議組裝成錯誤事件。錯誤事件應包括如下屬性成員:錯誤事件類名、錯誤時序編號、報錯資源、錯誤的其他細節等。其中，類名體現了錯誤的性質，錯誤時序編號與生成錯誤事件的CPU時間相關，體現了錯誤發生的時間和時序關系，報錯資源則反映了發現錯誤行為的資源在硬件資源拓撲中的位置。這樣，診斷者通過錯誤事件，即可得知系統錯誤的性質、發生時間、發生位置、錯誤的其他細節信息，為故障診斷提供了依據。錯誤描述器生成錯誤事件之后，通過傳輸層將其提交給故障診斷組件的分派器。

故障診斷組件在本層實現一個故障描述器，根據診斷者的故障診斷結果按照事件協議生成故障事件。故障事件應包含故障源的資源描述符FMRI，故障源所在的ASRU、FRU，診斷結果可信度等信息，供執行器執行修復行為時參考。故障描述器生成故障事件，將它通過傳輸層交給故障修復組件的分派器。

分派器在故障管理系統中管理協議事件在描述器、診斷者、執行器等部件間的傳遞。協議事件的消費者(診斷者和執行器)均會根據自己的需求和職責在分派器中預訂自己需要的協議事件。分派器中應維護一個FMA協議事件樹，預訂某類事件的事件消費者按照該事件類名檢索它在事件樹中的相應節點，將自己的事件隊列鏈接到該節點，分派器按照類名在事件樹中檢索，找到和對應該類事件的節點，將事件放入該節點的事件隊列從而完成分派。

故障診斷組件在本層部署分派器來分派來自傳輸層的錯誤事件。故障修復組件在本層部署分派器來分派來自傳輸層的故障事件。

實際上，錯誤和故障描述器語義相同，均是按照事件協議來生成協議事件，兩個分派器的語義也相同，均是按照事件協議來預訂、分派協議事件，在實現中它們通常可以合并。當然在多域服務器中，如果三個組件分開部署，考慮到事件的跨域傳輸問題，描述器、分派器需要分別實現。

3.4 優點分析

三個組件分別完成故障管理系統的三個功能部件，并設計傳輸層封裝組件間的事件傳輸，便于在多域服務器上分開部署各組件，進行跨域協同、全局優化的故障管理服務。

各個層次之間自頂向下透明，便于移植和設計變更。例如，可以方便地修改事件協議。

資源層封裝了硬件組件，并提供故障樹規則描述語言和硬件結構的規范化描述機制，這就極大地便利了系統管理員根據各種機器不同的硬件結構特點和復雜多變的故障機理設計適宜的診斷規則;診斷者只需閱讀這些規則即可獲知故障機理，從而推斷故障、完成診斷，因此診斷者設計也得到了簡化。資源層還提供故障區域的劃分，可根據修復能力為故障修復組件界定合適的故障源。

故障管理層為資源層封裝的硬件組件實現故障管理服務，確保故障管理的集中化，并最大限度地保證了平臺無關性。診斷者中病歷的設計可以智能地辨別并搜集與某次故障相關的錯誤信息，使診斷既不遺漏相關信息，也不受到無關錯誤信息的干擾。

事件層中錯誤和故障描述器、分派器語義相同，不考慮多域部署時可合并實現。事件協議中層次化類名方案不但清楚地表達了錯誤或故障信息，也極大地便利了事件的分派。

4 在高端服務器上的實現

4.1 故障管理的設備專用特性

CPU、內存和I/O設備有著不同的故障管理特性，故障管理系統設計必須考慮到各種設備的故障管理特性。

一般來說，CPU和內存的錯誤對系統造成危害更加致命;如果出錯，通常應診斷為元件故障，并進行修復以保證系統可靠性;同時，一般無法將多個CPU和內存錯誤歸結為單個故障。因此在其診斷規則設計中，錯誤和故障一般是一一對應的映射關系，每出現一個錯誤，就作出一個故障診斷。CPU或內存故障經常會導致操作系統失效，而部署在操作系統內的故障管理系統很難預測到CPU或內存的故障，有時甚至來不及覺察到故障，操作系統就失效或重啟了，因此很有必要對于這類故障進行帶外的監控和診斷。很多高端服務器在邏輯域外還有服務處理器SP，在邏輯域操作系統下有平臺固件，利用平臺固件來帶外監控CPU內存的運行錯誤，用SP和平臺固件來對CPU和內存的故障進行帶外的診斷、修復、隔離或重啟，對于提高系統可靠性很有必要[8，9]。在設計中可以充分利用一些處理器自有的檢錯監控系統，如MCA系統等，將檢錯系統作為故障管理層的感知器。

部署在操作系統內的故障管理系統對I/O設備的故障管理一般被認為是可靠的。出于系統運行效能的考慮，對于I/O設備的故障，確診往往比較謹慎，因此其故障診斷規則相對來說復雜一些。對于I/O設備，故障管理層感知器一般部署在驅動里，從而使系統能夠實時監控到設備的錯誤信息。

4.2 高端服務器上的部署

故障管理系統應該部署在信息足夠多的范圍內，從而獲得自動診斷和高效響應。典型的高端服務器如SUN的SPARC等，在邏輯域下有平臺固件，邏輯域操作系統運行在平臺固件搭建的虛擬機上，邏輯域之外還有SP，SP和平臺固件都應對系統運行進行監控和故障管理，以向邏輯域提供可靠運行環境。因此，高端服務器通常需要部署多個故障管理系統:在SP內的平臺故障管理系統、SP故障管理系統和若干邏輯域故障管理系統。錯誤事件可在不同的環境中生成，并可被傳輸到最有利于診斷的環境中。

根據4.1節所述特性，各個故障管理系統作如下分工:SP故障管理系統負責SP自身的故障管理;邏輯域(I/O服務域)故障管理系統主要負責系統中I/O設備的故障管理。CPU和內存的故障、平臺電源故障等往往通過帶外監控的形式獲取錯誤事件，主要由SP內的平臺故障管理系統完成診斷和修復。例如，若邏輯域內發生了惡意寫內核內存頁錯誤，導致域內操作系統失效，操作系統在運行停機命令之前會捕獲并緩存相關錯誤數據，在即將重啟之前或剛剛重啟之后，操作系統立即將錯誤事件從邏輯域發送到平臺故障管理器用于診斷。

本文嘗試在SUN 的SPARC服務器上實現該層次化結構，考慮到平臺兼容性，操作系統使用Linux，診斷引擎的設計參考了SUN openSolaris操作系統中的故障管理系統。

實現方案有以下一些特點需要說明:

高端服務器上平臺固件與SP間一般都存在錯誤報告信道[8]，SPARC服務器也是如此，本方案對于CPU和內存的故障診斷充分利用這一信道。平臺固件監控到的CPU內存致命錯誤或邏輯域操作系統無法及時感知的系統運行錯誤，可直接通過該信道向SP中的平臺故障管理系統傳遞錯誤事件，這對邏輯域內故障管理系統是個補充和支持。

本實現方案需要部署多個故障管理系統，錯誤事件需要被投遞到具備診斷能力的環境中，故障事件可能會被投遞到具備故障修復能力的環境中，因此，錯誤處理組件、故障診斷組件、故障修復組件可能會分開部署。因而在本方案中，故障診斷組件和故障修復組件的分派器需要各自獨立實現。分派器還必須有接受遠程事件消費者的預訂、向遠程事件消費者分派事件的能力。

本方案采用名值對列表的形式編組協議事件:協議事件各個屬性成員都由一個名值對來表示，整個事件編組為一個名值對列表。

本方案中，傳輸層采用的傳輸機制如下:錯誤事件在被錯誤描述器生成后，可經由系統事件傳輸信道[10]交給分派器;SP和邏輯域之間、平臺固件和SP之間可以使用雙端DSRAM進行通信;通過互聯網絡部署的各域之間可以通過IP協議來通信。傳輸層對這些傳輸機制進行封裝，在事件層和傳輸層之間實現了一系列傳輸模塊、用來作為與傳輸層之間事件傳輸，遠程事件預訂等事務的接口。

5 結束語

本文提出了一種層次化結構故障管理系統設計，對其基本特征和設計思想進行了剖析，進一步研究了該方案在高端服務器上部署的相關技術。與舊式的系統檢錯機制和錯誤日志機制相比，這種故障管理系統結構具備了統一的集中化故障管理平臺，具備強大的自動診斷能力，并可為故障源進行細粒度的自動隔離，為管理員提供進一步的修復建議;它建立了一套事件協議，規范、系統地描述了各種硬件錯誤和故障，并有完備的資源拓撲描述，可對故障源進行精確定位;具備了在多域系統中部署并協同運作的能力。即使與其他現代故障管理軟件相比，它也顯得更加完善，可用性更強。

故障管理正由過去硬件檢錯報錯、人工診斷和修復的模式，向軟硬件協同診斷，人機協同修復的方向發展。由專門的故障管理系統對故障進行集中化，自動化的診斷和修復，已是一種必然趨勢，不論邏輯域操作系統的故障管理，還是SP和平臺固件的帶外故障管理，最終都要整合進統一的故障管理系統，在全系統內實現故障診斷和修復的協同。本設計正符合這一趨勢。

參考文獻:

[1]

SHAPIRO M W. Selfhealing in modern operating systems[J]. ACM Queue，2004-2005，2(9):66-75.

[2]MCGUIRE C A， SHAPIRO M W. Solaris FMA event protocol and resource identification[EB/OL].(2004-10-11)[2009-07-15].http://es.opensolaris.org/os/community/arc/policies/fmaeventprotocol/protocol_whtppr_v_1.6.pdf.

[3]WILLIAMS E， RUDOFF A. System and method for generating a data structure representative of a fault tree: United States，7200525B1[P]. 2007-04-03.

[4]MCGUIRE C A， HALEY T P， RUDOFF A， et al. Error reporting to diagnostic engine based on their diagnostic capabilities: United States ， 7328376B2[P]. 2008-02-05.

[5]QUACH N. High availability and reliability in the itanium processor[J]. IEEE Micro， 2000，20(5):61-69.

[6]Intel Corporation. Itanium processor family errorhandling guide [EB/OL]. (2004-04)[2009-07-15]. http://www.intel.com/design/itanium/downloads/249278.htm.

[7]HewlettPackard Development Company. HPUX 11isystem fault management[EB/OL]. (2007-02-01)[2009-07-15].http://h71028.www7.hp.com/ERC/downloads/4AA07795ENW.pdf.

[8]BADE S A， CATHERMAN R C， HOFF J P， et al. Method and system for providing a trusted platform module in a hypervisor environment: United States，7484091B2 [P].2009-01-27.

[9]MATHEW T K， KHARGHARIA B. Virtual machine monitor management from a management service processor in the host processing platform:United States， 2008/0005748A1[P].2008-01-03.

[10]Sun Microsystems Inc. Fault management daemonprogrammer’s reference manual[EB/OL].(2008-04)[2009-07-15].http://www.opensolaris.org/os/community/fm/files/FMDPRM.pdf.