專利名稱：：一種機群容錯系統(tǒng)、裝置及方法
技術領域：
：本發(fā)明涉及計算機并行處理容錯
技術領域：
，特別是涉及一種并行處理的機群容錯系統(tǒng)、裝置及方法。
背景技術：
：以機群為代表的計算機并行處理技術在現(xiàn)代社會中的應用已經(jīng)達到了相當可觀的廣度和深度。作為社會信息化基礎設施的重要組成部分，機群系統(tǒng)中的并行處理的可靠性問題己經(jīng)對經(jīng)濟和社會產(chǎn)生影響。目前，隨著機群系統(tǒng)規(guī)模的不斷擴展和復雜性的逐漸提高，其并行處理的可靠性呈現(xiàn)下降趨勢的現(xiàn)象已經(jīng)引起了學術界和工業(yè)界的廣泛關注，機群并行處理的容錯技術的理論研究及其工程應用的需求日益迫切。機群是以網(wǎng)絡互連并能協(xié)同工作的多個獨立的計算機(稱為機群的結點)構成的并行計算機系統(tǒng)。故障、錯誤和失效是容錯計算領域最基本的概念，是理解容錯技術的基礎。簡而言之，失效是指一個系統(tǒng)偏離其正確服務這一事件，錯誤是指一個系統(tǒng)的全部狀態(tài)中可能導致其后續(xù)的失效的部分，故障則是一個錯誤的原因。故障可能來源于一個系統(tǒng)的內(nèi)部或者外部。如果一個故障已經(jīng)導致了錯誤，就是處于激活(Active)狀態(tài)，否則就是處于休眠(Dormant)狀態(tài)。錯誤可以通過報錯消息或者報錯信號而被檢測出來，己經(jīng)產(chǎn)生但尚未被檢測到的錯誤稱為潛伏(Latent)錯誤。一個錯誤可以通過計算過程而不斷變化或者在系統(tǒng)模塊之間傳播，這一過程稱為錯誤遷移(ErrorPropagation)。目前，對于計算機系統(tǒng)中的軟硬件故障主要有四種處理方法故障避免(FaultPrevention):提前避免故障的出現(xiàn)；故障容許(FaultTolerance):在故障出現(xiàn)之后避免其導致服務失效；故障消除(FaultRemoval):減少故障的數(shù)量及其危害；故障預報(FaultForecasting):預估故障的當前數(shù)量、未來的發(fā)生率以及后果。廣義的容錯技術可以涵蓋故障、錯誤和失效的各種處理方法。故障容許一般是通過錯誤檢測(ErrorDetection)和系統(tǒng)恢復而實現(xiàn)，其中后者根據(jù)其處理對象可以劃分為基于故障處理和基于錯誤處理這兩種類型。根據(jù)故障、錯誤和失效的相互關系，錯誤處理是避免服務失效的關鍵環(huán)節(jié)?，F(xiàn)有的錯誤處理技術主要分為巻回(Rollback)、前滾(Rollforward)和補償(Compensation)三種策略。巻回恢復是在無法確定和排除錯誤原因的情況下，將系統(tǒng)狀態(tài)恢復到一個預先保存的正確狀態(tài)重新運行，以期錯誤不再發(fā)生。前滾恢復則通常基于N模冗余而實現(xiàn)，當通過定期的狀態(tài)比較(N=2)或者表決(N^)發(fā)現(xiàn)錯誤之后，所有冗余模塊繼續(xù)運行，只利用空閑單元重新運行上一周期的計算過程，并根據(jù)其結果判定并剔除錯誤的冗余模塊的狀態(tài)。巻回恢復主要是基于時間冗余，而前滾恢復則需要依賴于硬件冗余。在這兩種策略中，前者的應用更為廣泛。常見的進程檢査點和巻回恢復就是一種典型的巻回錯誤處理技術。故障可以在任何一個系統(tǒng)層次被引入。相應地，不同的系統(tǒng)層次就需要有與之對應的容錯機制。同時，任何容錯機制都對其所能處理的故障或者錯誤有一定的假設，比如故障類型、故障頻率等因素，因此對于不同的故障類型，往往存在不同的容錯方法。于是，一個實際的計算機系統(tǒng)中的失效處理常常需要綜合運用多種容錯技術，并分為多個步驟或者層次進行處理。計算機的錯誤處理中常用的十個步驟，依次是故障抑制(FaultContainment)、故障檢測(FaultDetection)、故障屏蔽(FaultMasking)、重i式(Retry)、診斷(Diagnosis)、重配置(Reconfiguration)、恢復(Recovery)、重啟動(Restart)、修復(Repair)和重新整合(Reintegration)。經(jīng)典的容錯技術包括硬件方面的三模冗余(TripleModularRedundancy,縮寫TMR)和多模冗余(N-tupleModularRedundancy,縮寫為NMR)和軟件方面的恢復塊(RecoveryBlocks)、多版本程序設計(N-VersionProgramming)、算法容錯(Algorithm-BasedFault-Tolerance,ABFT)、軟件自檢等方法，以及軟件老化和再生技術、面向恢復的計算(Recovery-OrientedComputing,ROC)，失效忽略計算(Failure-ObliviousComputing)等技術。機群設計中傳統(tǒng)的挑戰(zhàn)是線性加速比問題。在計算粒度基本不變的情況下，當結點數(shù)增加到一定程度之后，機群的整體性能不但無法達到線性加速比，甚至會不升反降。將機群結點的可靠性問題考慮進去，并且假設每個機群結點的可靠性并不理想，那么，隨著所用結點數(shù)量的增長，不得不擔心的將不再是系統(tǒng)性能是否可以保持線性增長，而是指定規(guī)模的一個計算任務能否無故障地順利完成。機群體系結構中內(nèi)在的冗余性解決了一部分機群容錯的問題。但是，機群容錯面臨更多的挑戰(zhàn)。首先，當機群系統(tǒng)的規(guī)模不斷擴大的時候，按照統(tǒng)計規(guī)律，整個系統(tǒng)的可靠性將不可避免地下降。第二，機群結點之間的并行性使得完整地獲取和恢復應用的狀態(tài)更加困難。進程間通信的存在使并行應用中各進程的狀態(tài)之間存在著復雜的先后依賴關系，對任何單一故障的處理都需要考慮全局狀態(tài)的可恢復性。提高機群系統(tǒng)的可用性有兩種途徑一是繼續(xù)提高單個結點的可靠性，從而使系統(tǒng)整體的可靠性相應地提高。但鑒于機群系統(tǒng)一般采用COTS部件，這一方法所受的限制較多。另一途徑是，著眼于系統(tǒng)整體的可用性，使系統(tǒng)在單一結點出現(xiàn)的故障能夠得到局部化(時間、空間)的恢復處理。在機群容錯領域常用的定期全局檢查點技術可以稱為"時間局部化"機群容錯技術。該技術將連續(xù)運行的機群系統(tǒng)從時間上分割為較短的單元，即傳統(tǒng)的檢查點間隔(CheckpointInterval)。通過在每個時間單元的開始時刻記錄系統(tǒng)狀態(tài)，使得在每個時間單元之內(nèi)發(fā)生的故障僅能破壞整個機群系統(tǒng)在該時間單元內(nèi)的計算結果。該技術已經(jīng)被實踐證明是極為有效的機群容錯策略之一，但是該技術沒有實現(xiàn)機群故障處理的空間局部性，其開銷與系統(tǒng)規(guī)模直接相關。可以說，在每個檢查點間隔的結束時刻為一個機群并行應用中的所有進程都執(zhí)行檢査點操作有過度冗余(AggressiveRedundancy)的傾向。隨著機群計算規(guī)模的不斷擴大，全局檢査點的弊端逐漸變得明顯，機群容錯機制亟待向輕量級的方向發(fā)展。
發(fā)明內(nèi)容本發(fā)明所要解決的問題在于提供一種機群容錯系統(tǒng)、裝置及方法，其為并行處理的機群提供局部化的快速故障恢復，具有較低的開銷和良好的可擴展性，使得百萬、千萬億次規(guī)模的機群系統(tǒng)能夠具有理想的可用性。為實現(xiàn)本發(fā)明目的而提供的一種機群容錯系統(tǒng)，包括如下功能模塊遠程檢査點服務器，用于響應來自故障結點的遠程檢查點請求，執(zhí)行檢査點操作；結點故障檢測模塊，用于監(jiān)測本地結點的操作系統(tǒng)和指定進程的運行狀態(tài)，觸發(fā)遠程檢查點；通信系統(tǒng)檢查點模塊，用于實現(xiàn)通信設備的檢査點，并支持通信斷點恢復功能。所述的機群容錯系統(tǒng)，還包括下列功能模塊-并行應用進程管理器，用于為故障時檢査點系統(tǒng)提供被監(jiān)測應用的進程信息，并管理進程恢復過程；檢査點文件服務器，用于存儲檢査點文件，并在故障時檢查點的恢復過程中提供檢查點文件訪問支持。一種機群容錯處理方法，包括下列步驟步驟Al.應用注冊；步驟Bl.遠程檢查點切?。徊襟ECl.進程恢復。所述的機群容錯處理方法，所述步驟A1之后，步驟B1之前，還包括下列步驟步驟Sl.結點監(jiān)測；步驟S2.故障報告；一種遠程檢査點切取系統(tǒng)，包括內(nèi)核符號尋址模塊，用于對目標進程所在結點的操作系統(tǒng)的內(nèi)核符號的尋址；數(shù)據(jù)緩存模塊，用于數(shù)據(jù)的緩存和預??；指針模塊，用于指針操作。一種遠程檢査點切取方法，包括下列步驟步驟SIO，加載目標結點的操作系統(tǒng)符號表；步驟S20，加載目標結點的操作系統(tǒng)核心類型表；步驟S30，根據(jù)目標進程號查找目標進程的進程控制塊，并復制到本地緩沖區(qū)中；步驟S40，創(chuàng)建遠程檢査點映像的文件頭；步驟S50，保存根目錄和當前工作目錄的完整路徑；步驟S60，保存目標進程的文件描述符表；步驟S70，逐一保存目標進程已打開文件的基本信息；步驟S80，為遠程檢査點映像文件加入末尾標記。一種遠程檢查點恢復系統(tǒng)，包括狀態(tài)區(qū)分模塊，用于區(qū)分目標進程的狀態(tài)，以避免對RCX等寄存器的誤用；跳板模塊，用于恢復完整的通用寄存器狀態(tài)，使進程都以IRET指令退出核心態(tài)，從核心空間返回用戶空間。一種遠程檢査點恢復方法，包括如下步驟步驟S10'，檢查點恢復工具創(chuàng)建一個子進程，并開始等待其執(zhí)行完成或異常退出；步驟S20'，根據(jù)檢查點文件的頭部信息判斷其合法性；如果頭部信息中標明的操作系統(tǒng)不符合預期，則退出；否則，進入下一步驟；步驟S30'，重新設置目標進程的基本屬性；步驟S40'，恢復目標進程核心棧中的CPU狀態(tài)部分；步驟S50'，恢復目標進程中信號處理的相關信息；步驟S60'，解除宿主進程的所有虛擬存儲區(qū)域的映射；步驟S70'，加載目標進程的所有虛擬存儲區(qū)域的映射；步驟S80'，設置目標進程的虛擬地址空間描述信息；步驟S90'，恢復目標進程的根目錄和當前工作目錄的路徑；步驟S100'，關閉宿主進程的各個文件；步驟S110'，逐一恢復目標進程已打開文件的基本信息；步驟S120'，設置目標進程的狀態(tài)為可運行，使其退出遠程檢査點恢復過程之后可以被正常地調(diào)度執(zhí)行。一種通信系統(tǒng)的檢查點切取方法，包括下列步驟步驟SIOO，讀取通信設備文件所指向的端口狀態(tài)結構；步驟S200，向目標端口所在的網(wǎng)卡發(fā)送凍結指定端口的命令；步驟S300，如果已確認主機方的目標進程己經(jīng)停止運行，保存用戶進程能夠寫入的發(fā)送請求隊列和各發(fā)送緩沖區(qū)，否則需要首先向目標進程發(fā)送暫停運行的遠程中斷；步驟S400，在通信協(xié)處理器確認目標端口已凍結之后，保存用戶空間的接收緩沖區(qū)和事件隊列，以及網(wǎng)卡上的端口控制塊和所有該端口正在使用中的發(fā)送句柄。一種通信系統(tǒng)的檢查點恢復方法，包括下列步驟步驟S100'，端口的重建；步驟S200'，端口的重定位。一種通信的斷點恢復方法，包括下列步驟步驟l.凍結本地通信端口的收發(fā)操作步驟2.保存已凍結端口的狀態(tài)步驟3.向其它MCP廣播。一種單機故障時檢查點切取方法，包括下列步驟步驟SIOOO，進程完整狀態(tài)保存；步驟S2000，結點故障的檢測；步驟S3000，遠程檢査點目標進程的狀態(tài)檢測。一種遠程中斷中止的進程檢測方法，包括下列步驟步驟N1，查找指定進程號對應的進程控制塊；步驟N2，填寫遠程中斷請求結構；步驟N3，若該進程所在的CPU標識等于執(zhí)行遠程中斷服務程序的CPU標識，則直接設置被中斷進程的標志；否則，向該進程所在的CPU發(fā)送處理器間中斷；隨后，該進程所在的CPU在進程調(diào)度模塊中響應遠程中斷請求結構中注冊的請求，并在完成該請求之后更新其中的請求狀態(tài)標志。本發(fā)明的有益效果是本發(fā)明的一種機群容錯系統(tǒng)、裝置及方法，其是一種針對并行應用的機群故障時檢査點機制，旨在為并行應用提供局部化的快速故障恢復。對于全局檢查點系統(tǒng)，并行應用中所有進程的狀態(tài)需要在其正常運行的過程中周期性地寫入非易失性存儲設備并保持進程間通信狀態(tài)的一致性，而機群故障時檢査點機制的核心思想則是在并行應用正常運行時僅保存CPU狀態(tài)等在結點故障時無法獲取的狀態(tài)。當發(fā)現(xiàn)故障時，對故障結點上的進程遠程執(zhí)行檢查點，保存其通信系統(tǒng)的狀態(tài)，并通過機群通信協(xié)議保證通信中斷后的正確恢復；本發(fā)明還提出了基于遠程直接內(nèi)存訪問技術的遠程檢査點方法機制。該技術利用遠程直接內(nèi)存訪問的通信過程無需目標結點的CPU和操作系統(tǒng)參與的特點和機群高速通信系統(tǒng)的優(yōu)異性能，在目標結點的操作系統(tǒng)拒絕服務等故障條件下能高效地切取應用狀態(tài)。該技術使應用程序與操作系統(tǒng)的依賴關系變得松散，操作系統(tǒng)的故障不會威脅到被服務進程的繼續(xù)運行。本發(fā)明還實現(xiàn)了用戶級機群通信系統(tǒng)的檢査點和恢復方法機制。該機制利用機群通信系統(tǒng)中的應答、重發(fā)和消息緩沖等通信可靠性保障方法機制，降低了并行檢査點過程對維護通信系統(tǒng)全局一致性狀態(tài)的要求，減少了進程的檢査點和恢復過程的開銷。本發(fā)明還在用戶級機群通信系統(tǒng)的檢查點和恢復機制的基礎上，探索了機群通信協(xié)議如何對并行應用的故障時檢査點和恢復操作提供支持，提出了針對并行應用中單個進程的檢査點的通信斷點恢復的方法機制。本發(fā)明還實現(xiàn)了支持故障時檢査點的結點級容錯方法機制，包括基于協(xié)處理器的結點故障檢測技術和基于進程運行上下文切換的CPU寄存器狀態(tài)保存技術，能夠實現(xiàn)結點故障的快速檢測并確保目標進程的狀態(tài)在結點故障發(fā)生之后的完整性。本發(fā)明還實現(xiàn)了一個輕量級的并行程序故障時檢査點和恢復系統(tǒng)(Crash-TimeChecKpointandRestartsystem,CTCKR)。該系統(tǒng)僅當一個并行應用因其所在的一結點的操作系統(tǒng)崩潰而無法繼續(xù)運行時才觸發(fā)檢查點和恢復操作，避免了定期地頻繁執(zhí)行檢查點所帶來的時間開銷，并且該系統(tǒng)僅僅針對故障結點中的相關進程進行檢查點和恢復，而無需執(zhí)行全局檢查點，因而存儲開銷也顯著降低。通過利用NPB(NASParallelBenchmarks)、LINPACK等基準測試程序的評測實驗表明，本發(fā)明的機群容錯系統(tǒng)、裝置及方法在各項性能測試和基于故障注入的正確性測試中都很好地達到了設計目標，這充分表明了本發(fā)明的機群容錯系統(tǒng)、裝置及方法是一種可行的輕量級機群容錯技術。圖1為進程信息項結構示意圖2為本發(fā)明的機群容錯系統(tǒng)工作過程示意圖3為遠程檢査點切取方法的操作對象示意圖4為用戶空間虛擬地址的轉換示意圖5為分布式系統(tǒng)的一致性狀態(tài)示意圖6為環(huán)形接收緩沖區(qū)的檢査點切取優(yōu)化示意圖7為MX通信協(xié)議中的斷點恢復支持方法示意圖；、圖8為二叉樹廣播方法示意圖9為MX檢查點開銷測試結果圖IO為核心堆棧頂部示意圖。具體實施例方式為了使本發(fā)明的目的、技術方案及優(yōu)點更加清楚明白，以下結合附圖及實施例，對本發(fā)明的一種機群容錯系統(tǒng)、裝置和方法進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。機群容錯系統(tǒng)追求如下目標1)對應用程序廣泛的適應性。機群容錯應該盡可能地獨立于應用程序、并行應用中間件，甚至不依賴于結點操作系統(tǒng)，方便應用開發(fā)人員和系統(tǒng)管理人員，即容錯機制應盡量保持對應用的透明性。2)在系統(tǒng)無故障運行的條件下的低開銷。容錯機制對系統(tǒng)性能造成的損失應該力求最小，對存儲等資源的占用也應力求最少。3)低恢復開銷。降低巻回恢復的層次，從而減少恢復開銷。本發(fā)明的機群容錯系統(tǒng)，基于以下技術1)當一個機群結點出現(xiàn)操作系統(tǒng)拒絕服務，甚至崩潰等故障之后，基于協(xié)處理器的故障檢測機制使得該結點的狀態(tài)得以為外界所知曉；2)遠程檢査點技術使得該結點上任一進程的檢査點能夠被遠程切取；3)而機群通信系統(tǒng)的檢査點機制又使并行應用的通信過程可以被隨時中止和恢復。本發(fā)明的機群容錯系統(tǒng)，包括如下功能模塊遠程檢査點服務器，用于響應來自故障結點的遠程檢査點請求，執(zhí)行檢查點操作；結點故障檢測模塊，用于監(jiān)測本地結點的操作系統(tǒng)和指定進程的運行狀態(tài)，觸發(fā)遠程檢査點；并行應用進程管理器，用于為故障時檢査點系統(tǒng)提供被監(jiān)測應用的進程信息，并管理進程恢復過程；作為一種可實施的方式，本發(fā)明的機群容錯系統(tǒng)，選擇MPI應用作為測試對象，因此該并行應用進程管理器實現(xiàn)于MPI進程管理器的功能擴展之中。檢查點文件服務器，用于存儲檢查點文件，并在故障時檢查點的恢復過程中提供檢查點文件訪問支持。通信系統(tǒng)檢査點模塊，用于實現(xiàn)通信設備的檢査點，并支持通信斷點恢復功能。作為本發(fā)明實施例的一種可實施方式，該通信系統(tǒng)檢查點模塊實現(xiàn)于MX通信系統(tǒng)的擴展之中。下面進一步說明本發(fā)明的遠程檢査點服務器。遠程檢查點服務器響應來自故障結點的遠程檢查點請求，執(zhí)行檢查點操作，其工作流程如下1、加載目標平臺中各結點的操作系統(tǒng)內(nèi)核符號表和數(shù)據(jù)結構類型表。2、循環(huán)等待應用程序的故障時檢査點注冊消息或者來自故障結點的求救消息(A)對于應用程序的注冊消息Al)向該應用中各進程所在的結點廣播應用拓撲信息。各結點的通信協(xié)處理器在收到該消息之后啟動本地狀態(tài)監(jiān)測。A2)開始能夠處理該應用中各結點發(fā)送的求救消息。(B)對于故障結點的求救消息Bl)應答求救消息。在配置多個遠程檢查點服務器的系統(tǒng)中，最先返回求救應答消息的服務器才能繼續(xù)執(zhí)行此次檢査點過程。B2)繼續(xù)執(zhí)行遠程檢查點。B3)通知MPI控制程序被切取進程的mnk、檢査點的完整路徑。C)對于恢復進程的注冊消息向恢復進程返回其所在并行應用的應用拓撲信息，以使其可以發(fā)起通信斷點恢復過程。下面進一步說明本發(fā)明的結點故障檢測模塊。本發(fā)明的機群容錯系統(tǒng)中的結點故障檢測模塊的功能是監(jiān)測本地結點的操作系統(tǒng)和指定進程的運行狀態(tài)，觸發(fā)遠程檢査點過程。其利用的是基于協(xié)處理器的結點狀態(tài)監(jiān)測方法。遠程中斷機制，即一種通過機群通信系統(tǒng)中的消息向目標結點的操作系統(tǒng)傳遞控制命令的機制。其中，遠程中斷功能主要用于控制尚未崩潰的遠程結點中某個進程的運行狀態(tài)。下面進一步說明本發(fā)明的并行應用進程管理器盡管故障時檢查點系統(tǒng)所依賴的通信系統(tǒng)檢查點機制可以支持位于機群通信系統(tǒng)之上的各種并行應用中間件，如MPI、PVM等，但是不同的并行應用中間件需要不同的并行進程管理機制。鑒于MPI目前是機群并行計算中間件事實上的標準，本發(fā)明實施例選擇MPI應用作為故障時檢査點系統(tǒng)的測試對象。MPI標準目前有多種實現(xiàn)版本，本發(fā)明實施例選擇的是支持MX通信系統(tǒng)的MPICH1.2.5版。MPICH默認的進程管理器是MPIRUN，其原有流程為1、解析命令行輸入，設置本次應用運行的控制參數(shù)。2、根據(jù)備選結點列表生成目標結點數(shù)組。3、建立用于接收子進程基本信息的監(jiān)聽端口。4、按照MPI進程序號(RANK)逐一創(chuàng)建執(zhí)行遠程命令(RSH/SSH)的子進程。這些MPIRUN的子進程進而在對應的目標結點中創(chuàng)建MPI并行應用的子進程。5、在監(jiān)聽端口中接收所有子進程返回的進程號、網(wǎng)卡號、端口號等基本信息。6、在收集完畢所有子進程的基本信息之后，向所有子進程廣播該并行應用中所有子進程的基本信息。當各個子進程收到該廣播之后，MPI初始化過程結束。7、在上述監(jiān)聽端口中等待接收子進程調(diào)用MPI、Abort()發(fā)送的消息。若收到一個這種消息，向其余子進程廣播進程終止命令。在本發(fā)明的機群容錯系統(tǒng)中，并行應用進程管理器不但要為MPI應用提供進程加載服務，而且要為遠程檢査點服務器提供目標應用的拓撲信息，并管理進程恢復過程。為此，本發(fā)明對MPIRUN的流程進行了擴充1)在向所有子進程廣播收集到的子進程基本信息之后，MPIRUN向遠程檢査點服務器注冊該應用的進程信息，其中每個條目的格式如圖1所示。每個條目中包含有進行的信息RANK、PID、NIC—ID、PORT一ID、STATUS。遠程檢査點服務器會根據(jù)應用的注冊信息，進一步通知所有相關結點的結點故障檢測模塊開始監(jiān)控本地結點的運行狀態(tài)。2)當遠程檢査點服務器成功地切取了某個進程的故障時檢査點之后，會通知MPIRUN，由其負責后續(xù)的進程恢復過程。MPIRUN創(chuàng)建一個新的子進程，并由后者向指定的備用結點發(fā)送進程恢復命令。隨后，MPIRUN更新其子進程與MPI進程序號的映射表，以使該MPI應用的退出過程正常進行。經(jīng)過擴充的MPIRUN從命令行參數(shù)中獲取遠程檢査點服務器的地址，并支持備用結點列表文件、命令行輸入等多種提供備用結點的方法。下面進一步說明本發(fā)明的檢査點文件服務器。本發(fā)明的檢査點文件服務器實現(xiàn)了一個基于MX通信系統(tǒng)的虛擬文件系統(tǒng)MXFS，用于訪問故障時檢查點的映像文件。其通過Linux操作系統(tǒng)中的procfs虛擬文件系統(tǒng)提供了標準的open()、read()、lseek()、write()等文件操作接口。當用戶程序打開如"/proc/mxfs/NODE/FILENAME"的文件名時，MXFS的客戶端核心模塊會自動地向結點"NODE"中運行的MXFS服務器發(fā)送建立鏈接，以訪問"FILENAME"文件的請求。MXFS服務器在該請求的應答消息中向客戶端發(fā)送指定的本地文件打開命令的返回值。在該文件的訪問鏈接建立之后，MXFS客戶端就可以通過正常的讀寫命令訪問該文件。當MXFS服務器所選的本地文件系統(tǒng)為RAMFS時，MXFS的讀性能可以達到97MB/s。這一性能僅達到MX通信系統(tǒng)的峰值性能的42%，這主要是由于MXFS服務器和procfs的實現(xiàn)效率較低的原因。在故障時檢査點系統(tǒng)的實現(xiàn)中，MXFS服務器與遠程檢查點服務器運行于同一個結點，甚至在同一個程序中實現(xiàn)，以使MXFS服務器可以直接訪問遠程檢査點服務器所保存的檢查點文件。下面詳細描述本發(fā)明的一種機群容錯處理方法的工作流程。本發(fā)明實施例以一個N進程MPI應用中的一個結點發(fā)生操作系統(tǒng)故障為背景，詳細地描述本發(fā)明的機群容錯方法的故障時檢査點的工作流程。步Sl.應用注冊。當MPI進程管理器加載一個MPI應用時，在收集到所有子進程的基本信息之后，向遠程檢查點服務器發(fā)送應用注冊請求。遠程檢查點服務器在接收該請求之后，根據(jù)其中包含的進程信息，向所有相關結點的結點故障檢測模塊發(fā)送結點監(jiān)控請求。該請求中包含被監(jiān)測應用的注冊號及其所有進程的基本信息、可用的遠程檢查點服務器地址(列表)和結點監(jiān)控策略碼。結點監(jiān)控策略碼用于配置結點監(jiān)控模塊對本地的系統(tǒng)狀態(tài)做何種監(jiān)測，包括監(jiān)測時間間隔、監(jiān)測內(nèi)容等。步S2.結點監(jiān)測。在被監(jiān)測應用的運行過程中，結點故障檢測模塊定期地主動監(jiān)測本結點的操作系統(tǒng)的故障，同時也能被動地接收和處理主機方發(fā)送的結點故障恢復請求。步S3.故障報告。當結點故障檢測模塊探測到故障或者收到故障恢復請求時首先，凍結本地所有被監(jiān)測的進程打開的通信端口；然后，向預設的遠程檢查點服務器發(fā)送故障報告，請求后者對指定的本地進程實施遠程檢査點；最后，通過遠程中斷廣播通知被監(jiān)測應用中其它進程的MCP指定進程的檢查點正在啟動，如圖2(2)所示。步S4.遠程檢査點切取。當一個遠程檢査點服務器收到有效的故障報告之后，就啟動遠程檢査點過程，如圖2(3)所示。在該過程成功結束之后，遠程檢查點服務器將所得到的檢查點映像文件的位置和對應進程的RANK等信息發(fā)送給MPI進程管理器，由其負責后續(xù)的進程恢復過程。步S5.進程恢復。MPI進程管理器首先需要確定進程恢復所用的結點，例如從預設的空閑結點列表中選擇新的結點，或者等待故障結點的重啟動。然后，MPI進程管理器向目標結點發(fā)送恢復進程的命令，如圖2(4)所示。在該命令中，檢査點文件的位置以其在MXFS文件系統(tǒng)中的地址的形式給出。在目標進程的恢復過程中，其通信端口在恢復之后，會廣播通知其它進程繼續(xù)通信，如圖2(5)所示。如果在該進程的檢查點和恢復過程中沒有其它結點故障，則被監(jiān)測應用繼續(xù)運行。較佳地，在上述過程的最后一步，MPI進程管理器可以通過遠程電源管理軟件重啟動故障結點。目前，已經(jīng)有較為成熟的遠程電源管理的解決方案，如CPS公司推出的多種基于以太網(wǎng)、RS-232等連接的遠程電源管理設備。在本發(fā)明實施例中，采用Linux系統(tǒng)在panic()函數(shù)中提供的超時重啟機制。通過設置Linux操作系統(tǒng)的啟動選項panic,使操作系統(tǒng)在進入panic狀態(tài)指定時間之后自動重啟動。為了進一步說明本發(fā)明的機群容錯系統(tǒng)和處理方法，本發(fā)明實施例以開發(fā)平臺為硬件配置為兩路AMDOpteron處理器的NUMA服務器；網(wǎng)卡為MyricomPCIXD-2，其通信協(xié)處理器為LanaiX版。開發(fā)平臺的操作系統(tǒng)核心為Linux-2.6.12版本；并行計算中間件MPICH的版本為1.2.6;底層的通信系統(tǒng)為MyricomMXl丄0版。說明本發(fā)明的機群容錯系統(tǒng)和方法，其將按照操作系統(tǒng)、底層通信系統(tǒng)、遠程檢査點服務器等三個層次分別介紹該系統(tǒng)和方法的實現(xiàn)細節(jié)。1、操作系統(tǒng)層11)進程狀態(tài)保存Linux操作系統(tǒng)核心代碼中的arch/x86\—64/kernel/entry.S文件的內(nèi)容是OpteronCPU通過系統(tǒng)調(diào)用、中斷、異常等方式進出核心態(tài)的匯編程序。為了使用戶進程上下文中的CPU寄存器、FPU寄存器的狀態(tài)在CPU每次進入核心態(tài)的時侯得到保存，本發(fā)明對該文件進行了修改。在從每個CPU的x8664\_pda結構中取出核心堆棧的指針之后，將完整地保存上述狀態(tài)。對于系統(tǒng)調(diào)用入口的主要修改片斷如下SAVE—RESTpushq%raxpushq%rdxcallctckr—save—fpupopq%rdxpopq%raxcall*sys—call_table(,%rax,8)movq%rax,RAX(%rsp)RESTORE—REST其中，SAVE\—REST/RESTORE\—REST是對RBX、RBP、R12sR15寄存器進行保存和恢復。所述代碼中保存FPU的函數(shù)接口設置為voidctckr—save—Qdu(void)structtask—struct*tsk-current;if(!used一math(》return;if((tsk)-〉thread一info-〉status&TS—USEDFPU){asmvolatile("rex64;fksave%0":"=m"(tsk陽〉thread.i387.fksave));return;其中，F(xiàn)XSAVE為OpteronCPU保存XMM、MMX和x87寄存器狀態(tài)的指令。鑒于FPU狀態(tài)的保存是本發(fā)明機群容錯系統(tǒng)和方法的進程狀態(tài)保存中最耗時的操作，從上述代碼可以看出，對于不使用FPU的非科學計算程序，本發(fā)明機群容錯系統(tǒng)和方法所帶來的無故障運行時的性能開銷將可以忽略不計。12)操作系統(tǒng)故障檢測為了支持基于操作系統(tǒng)故障計數(shù)的機群容錯的故障檢測機制，本發(fā)明設置一整數(shù)類型的ctckr—danger—level[]數(shù)組，每個CPU按其序號分別對應于該數(shù)組中的一個元素。為了使協(xié)處理器可以通過一次DMA讀操作得到該數(shù)組的內(nèi)容和當前的時鐘中斷計數(shù)，本發(fā)明修改了生成操作系統(tǒng)核心映像的鏈接器腳本，即arch/x86一64/kernel/vmlinux，lds.S文件，以使該數(shù)組與時鐘中斷計數(shù)變量的地址相鄰。在通信網(wǎng)卡的核心模塊加載過程中，所述地址將被注冊到通信協(xié)處理器中，以便后者定期對主機方的故障狀態(tài)進行檢測。2、底層通信系統(tǒng)機群容錯系統(tǒng)和方法所需的對通信系統(tǒng)的擴充包括遠程中斷、RDMA讀、MX端口凍結、MX端口恢復等功能。上述功能的實現(xiàn)都涉及對MX通信系統(tǒng)的MCP、用戶庫兩個部分的修改，其中MCP由于屬于通信網(wǎng)卡中的嵌入式軟件，其開發(fā)和調(diào)試的難度都比主機方程序高。本發(fā)明將以RDMA讀的實現(xiàn)為例說明上述功能的實現(xiàn)方式。在用戶庫中，添加新的請求類型MX__REQUEST—TYPE—RMA—GET，并在用戶請求數(shù)據(jù)結構unionmx—request中添加對應的子類型structrma一get。struct{structmx—basic—requestbasic;mx一segment—t*segments;uint32—tcount;mx—segment_tsegment;uint64一tremote—addr;mx—endpoint—addr—tdest_address;uintl6—tlib—seqnum;uintl6—tpad;uint32—tremote—len;uintl6—tmsg—seq;uint8—tunexpected)uint8一tpad2;structmxpartner*partner;}rma—get;用戶庫在處理所述用戶請求之后，繼而向MCP發(fā)出請求，因此，本發(fā)明添加設置MCP層的用戶請求類型MX—MCPJJREQ—RMA—GET,及對應的MCP請求結構mcp—ureq__rma—get—t。typedefstructuintl6一ttarget_peer—index;uint8一ttarget一endpt;uint8一tis—reply;uint32—ttarget—session;uint32—ttimeout;uintl6—tlib—seqnum;uint32—tremote—addr—high;uint32_tremote—addr_low;uint32—tremote—len;uintl6—tlib—cookie;uint8—tpadl;uint8—ttype;}mcp—ureq_nna—get—MCP層在處理該請求之后，將按新設置的MX數(shù)據(jù)包類型PKT—TYPE—RMA一GET，發(fā)送如下格式的數(shù)據(jù)包typedefstruct{pkt—data—common—tcommon;uint32_tremote—len;uint32—tremote—addr—high;uint32一tremote_addr—low;uint8一tis—reply;uint8—tpad;uintl6一treturn_peer_index;uint32—tsrc—mac一low32;}pkt—data—rma—get—t;接收方的MCP在收到該消息之后，啟動指定的DMA讀操作，并返回新定義的PKTJTYPE一RMA一GET一REPLY類型的數(shù)據(jù)包。發(fā)送方的MCP在收到該消息時，先啟動接收數(shù)據(jù)的DMA，再向主機方的用戶庫DMA類型為MXMCP—UEVT—RECV—RMA—GET的事件。在MX端口恢復的實現(xiàn)中，本發(fā)明在進程恢復模塊中首先創(chuàng)建一個新的MX核心端口，再將其狀態(tài)按照進程檢查點的內(nèi)容進行修改，以達到對用戶進程完全透明的目的。3、遠程檢査點服務器遠程檢査點服務器被實現(xiàn)為一個后臺服務進程方法。鑒于一般的機群系統(tǒng)中各結點的操作系統(tǒng)版本相同，該方法支持在啟動時配置默認的結點操作系統(tǒng)的版本。作為一種可實施的方式，該方法的用戶界面為Usage:rmac[options]-m,—map<System.map〉System.mapfile-k,—kerntypes〈Kerntypes〉Kerntypesfile-s,—serverDaemonmode-g，—debugLEVELDebuglevel-h,—helpDisplaythishelp在本發(fā)明的機群容錯系統(tǒng)和方法的故障時檢查點的恢復過程中，恢復進程要向遠程檢査點服務器注冊，以獲得其所在并行應用的應用拓撲信息。這是因為遠程檢查點服務器具有已注冊應用的最新的進程狀態(tài)信息(包括尚在遠程檢查點過程中的進程的信息)，同時MPIRUN只是一個Perl腳本程序，除了可以設置進程恢復命令中的參數(shù)之外，無法與被恢復進程進行方便的通''士sMPIRUN在進程恢復命令中會將遠程檢査點服務器的地址通知被恢復進禾k該命令的形式如下rshNEW—NODE、'cdCTCKR一IMG一PATH;\ctck—restart-rCTCKR—SERV一MAC:CTCKR—SERV一PORTctckr,TARGET一PID"應當說明的是，本發(fā)明實施例選擇了Myrinet/MX通信系統(tǒng)作為本發(fā)明機群容錯系統(tǒng)和方法的實現(xiàn)平臺，但是本發(fā)明同樣也可以實現(xiàn)于其它的通信系統(tǒng)之上，例如QsNet、InfiniBand等。下面詳細說明本發(fā)明的遠程檢査工作的過程，其包括一種遠程檢查點切取系統(tǒng)和方法，以及一種遠程檢査點恢復系統(tǒng)和方法。檢查點技術是一種廣泛用于巻回和前滾錯誤恢復的容錯技術，其設計思想簡單明了。該機制可以在處理器、物理存儲器、虛擬存儲器等級別實現(xiàn)，而在基于COTS部件的機群系統(tǒng)中，該技術常實現(xiàn)于操作系統(tǒng)、應用程序等軟件層次之中。檢查點技術的主要功能是減少單次故障所造成的時間損失。在具有進程副本(Process/TaskDuplication)的容錯方案中，例如DMR-F(DoubleModularRedundancywithForwardRecovery)、TMR-F(TripleModularRedundancywithForwardRecovery)和RFCS(Roll-ForwardCheckpointingScheme)等，檢査點的比較還是極為方便和準確的故障檢測方法。除了用于所述容錯目的之外，該技術還被用于負載均衡、作業(yè)調(diào)度和系統(tǒng)維護等場合。在工程實踐中，IBM公司在20世紀60年代末推出的OS/360操作系統(tǒng)就己經(jīng)對應用程序提供了檢査點和恢復機制的支持。隨著用戶對可靠性和可用性的需求不斷提高，該技術已經(jīng)開始在高端的科學和工程計算平臺中得到普及。在本發(fā)明中，進程檢査點和恢復技術是指在某一時刻保存一個目標進程的運行狀態(tài)，并在隨后的某一時刻以此狀態(tài)為起點重建該進程，使其繼續(xù)運行。在該過程中，被保存的進程狀態(tài)叫做該進程的檢査點，保存檢査點的操作稱為切取(Checkpointing)，而利用檢査點重建進程，使其能夠繼續(xù)運行的操作稱為恢復(Recovery或Restart)。對于在應用的運行過程中周期性執(zhí)行的檢查點操作，相鄰兩次操作之間的時間跨度稱為檢査點間隔(CheckpointInterval)。進程檢查點的內(nèi)容不但包括基本的進程屬性，用戶地址空間中的數(shù)據(jù)段、堆棧段、堆等存儲區(qū)域的當前內(nèi)容，而且包括用于進程間通信和i/o的各種系統(tǒng)資源的當前狀態(tài)，例如已創(chuàng)建的套接字、信號量、共享內(nèi)存、消息隊列和已打開的各種文件等等。盡管進程檢査點和恢復技術的思想簡單明了，但是其實現(xiàn)的復雜程度卻往往較高。以機群計算領域常用的Linux操作系統(tǒng)平臺為例，到目前為止仍然沒有一個檢查點和恢復系統(tǒng)可以實現(xiàn)任意進程在任意時刻的檢查點和恢復。該技術的實現(xiàn)難度主要源于以下兩方面的原因一，操作系統(tǒng)的設計日趨復雜，在對進程的運行和管理提供更多支持的同時，也使進程檢査點的內(nèi)容不斷增加；二，對于和外界存在通信、文件i/o和交互式操作等行為的進程，其檢査點和恢復過程需要特別考慮對外界，包括其它進程、存儲系統(tǒng)、用戶等，的影響。根據(jù)檢査點的不同層次，檢查點可以分為系統(tǒng)級檢査點、用戶級檢查點，其中用戶級檢査點主要是文件檢查點。系統(tǒng)級檢查點通過修改操作系統(tǒng)或者加載核心擴展模塊的方式，在核心層實現(xiàn)進程狀態(tài)的保存和恢復。用戶級檢査點技術在目標進程的用戶態(tài)上下文中對其狀態(tài)進行保存和恢復。文件檢查點的主要目的就是以盡可能小的開銷，盡可能對應用透明的方式使一個文件在兩個相鄰檢查點之間的狀態(tài)變化能夠得到巻回。隨著機群文件系統(tǒng)的發(fā)展，本發(fā)明的檢查點系統(tǒng)和方法，利用WAFL等日志結構文件系統(tǒng)(Log-StructuredFileSystem)中的快照功能(Snapshot)來代替文件檢查點。該方法充分利用特定文件系統(tǒng)中的現(xiàn)有功能，實現(xiàn)方便且效率較高，尤其能夠避免在檢査點間隔較長的情況下，文件檢査點的開銷趨于顯著的問題。對于較大規(guī)模的機群應用，如果其多個進程通過網(wǎng)絡存儲系統(tǒng)在一個共享的文件系統(tǒng)中進行文件I/O，則該方法的效率更佳。本發(fā)明的遠程檢查點切取系統(tǒng)和方法，是基于遠程直接內(nèi)存訪問(RemoteDirectMemoryAccess,RDMA)的遠程檢査點切取系統(tǒng)和方法，是一種無需目標進程所在結點的CPU和操作系統(tǒng)參與的檢査點系統(tǒng)和方法。遠程存儲訪問(RemoteMemoryAccess,RMA)是一種通過共享內(nèi)存、通信協(xié)處理器、DMA控制器或者硬件實現(xiàn)的遠程Put/Get操作等硬件機制實現(xiàn)的數(shù)據(jù)傳遞方式，能夠使一個結點直接讀取或者寫入另一結點的一段存儲區(qū)域。本發(fā)明實施例所述的遠程檢查點切取系統(tǒng)和方法，利用RDMA無需目的結點的CPU和操作系統(tǒng)參與通信過程的特點。在本發(fā)明實施例中，作為一種可實施的方式，RDMA基于Myrinet網(wǎng)絡中的LANai通信協(xié)處理器，對MX通信系統(tǒng)進行的RDMA讀功能的擴展。該RDMA可以實現(xiàn)對目標結點中指定物理地址的內(nèi)存空間的讀取。一個進程的完整的狀態(tài)信息可能分布于CPU中的通用寄存器、浮點寄存器和數(shù)據(jù)高速緩存，以及內(nèi)存和磁盤中。本發(fā)明實施例借助于硬件實現(xiàn)的高速緩存一致性協(xié)議(CacheCoherenceProtocol,CCP)來實現(xiàn)RDMA操作對高速緩存內(nèi)容的讀取。CCP協(xié)議是一種現(xiàn)有技術，本領域技術人員根據(jù)本發(fā)明的描述，可以重現(xiàn)其過程，因此，在本發(fā)明實施例中，不再一一詳細描述。本發(fā)明的遠程檢查點切取系統(tǒng)，可以視為一種特殊的核心級檢査點機制。在遠程檢査點過程中，檢査點工具程序遠程訪問的進程狀態(tài)信息與BLCR等核心級檢查點系統(tǒng)所訪問的進程狀態(tài)信息基本相同。本發(fā)明遠程檢查點系統(tǒng)在檢査點映像的格式上與BLCR保持一致。本發(fā)明的遠程檢査點切取系統(tǒng)與核心級檢查點主要區(qū)別于如下三個方面，對目標進程所在結點的操作系統(tǒng)的內(nèi)核符號的尋址，數(shù)據(jù)的緩存和預取，以及指針操作，上述三個方面也構成了遠程檢査點設計和實現(xiàn)中的三個模塊。本發(fā)明的遠程檢査點切取系統(tǒng)包括內(nèi)核符號尋址模塊，用于對目標進程所在結點的操作系統(tǒng)的內(nèi)核符號的尋址;數(shù)據(jù)緩存模塊，用于數(shù)據(jù)的緩存和預??；以及指針模塊，用于指針操作。下面詳細描述內(nèi)核符號尋址模塊。為了提取目標進程的狀態(tài)信息，遠程檢査點系統(tǒng)需要訪問管理目標進程的操作系統(tǒng)內(nèi)核的各種變量和數(shù)據(jù)結構。在本發(fā)明實施例的平臺上，作為一種可實施方式，本發(fā)明遠程檢查點系統(tǒng)利用Linux操作系統(tǒng)內(nèi)核的編譯過程中生成的System.map禾卩Kerntypes兩個文件。其中，前者是Linux操作系統(tǒng)的所有內(nèi)核符號，包括所有的核心變量和函數(shù)，與其虛擬地址的映射表；后者則包含Linux內(nèi)核中所有的數(shù)據(jù)結構的類型描述信息。結合以上兩個文件的內(nèi)容，可以計算出每一個內(nèi)核變量，及其數(shù)據(jù)結構中的任意一個成員，的虛擬地址和長度。同時，Linux操作系統(tǒng)內(nèi)核所采用的虛擬地址與RDMA操作所用的物理地址之間的映射關系固定，因此，本發(fā)明遠程檢查點系統(tǒng)就能夠實現(xiàn)對目標操作系統(tǒng)中的各種內(nèi)核符號的訪問。本發(fā)明實施例中，遠程檢查點切取系統(tǒng)需要訪問的Linux內(nèi)核中的數(shù)據(jù)結構可以按存儲位置分為兩類一類位于靜態(tài)分配的內(nèi)核數(shù)據(jù)段和BSS段，另一類在內(nèi)核動態(tài)分配的存儲單元中。前一類數(shù)據(jù)結構對應于已初始化或者未初始化的全局變量，其標識符和地址可以在System.map中被直接査到；后一類數(shù)據(jù)結構的地址則需要通過已知的全局變量間接地査找。例如，在查找一進程號P對應的進程控制塊(task—struct結構)時，首先讀取Linux內(nèi)核中task—struct類型的全局變量init—task,然后根據(jù)task—struct結構中l(wèi)ist—_head類型的tasks域，依次訪問進程控制塊鏈表中的下一個單元，直到找出進程號等于P的進程。當?shù)玫揭粋€目標進程的進程控制塊之后，可以根據(jù)其中包含的各個指針，逐個訪問賦予該進程的各種系統(tǒng)資源，如圖3所示。對于目標進程的用戶地址空間，遠程檢查點系統(tǒng)需要按照目標結點中CPU的虛擬地址轉換機制進行訪問。為了提高檢查點性能，本發(fā)明系統(tǒng)以頁面為單位讀取目標進程的用戶空間。在本發(fā)明實施例的平臺中，作為一種可實施方式，OpteronCPU采用基于四級頁表的頁式存儲管理，如圖4所示。本發(fā)明的遠程檢查點系統(tǒng)首先根據(jù)存儲管理結構mm—struct所包含的頁表目錄基址PGD(PageGlobalDirectory)，讀取PGD表所在的物理頁面，然后按圖4中所示步驟通過虛擬地址中的PGD索引、PUD(PageUpperDirectory)索弓l、PMD(PageMiddleDirectory)索引和PTE(PageTableEntry)索引依次査詢對應的頁表，直到查出一個用戶空間虛擬地址所在的物理頁面。下面詳細說明本發(fā)明的數(shù)據(jù)緩存模塊.通過RDMA訪存方式訪問遠程結點內(nèi)存的性能遠遠低于結點內(nèi)訪存性能。為了解決這一問題，在本發(fā)明的遠程檢査點系統(tǒng)中，采用緩存機制和數(shù)據(jù)預取機制來緩解RDMA訪存方式對檢查點性能所帶來的影響。遠程檢査點過程中的訪存操作存在較高的數(shù)據(jù)局部性。針對大量存在的目的地址和長度都相同的重復RDMA讀操作，僅通過緩存讀取內(nèi)容以供后續(xù)査找的方法就可以將RDMA操作的數(shù)量降低到原來的25。/。。針對呈現(xiàn)的大量目的地址相鄰的RDMA讀操作，通過設定RDMA最小讀取長度的方法就能夠極大地減少遠程檢查點過程所需的RDMA讀操作的數(shù)量。下面詳細說明指針模塊。本發(fā)明實施例所述的遠程檢査點切取系統(tǒng)在本質上屬于核心級檢査點，并且具有管理目標進程的操作系統(tǒng)核心與檢査點系統(tǒng)分別位于獨立的上下文的特點。由于一個指針的有效性僅局限于其所針對的地址空間，當通過遠程讀取方式將管理目標進程的操作系統(tǒng)核心中的指針變量復制到遠程檢査點服務器中的時候，應當采取措施避免因遠程指針變量的不當引用而造成程序故障。在指針的比較運算方面，有可能出現(xiàn)緩存于遠程檢查點服務器中的一個數(shù)據(jù)結構的地址(即緩存地址)和一個直接讀取自目標結點內(nèi)存中的指針變量的賦值(即原始地址)的比較。前者的取值屬于遠程檢查點服務器進程的用戶地址空間中的虛擬地址，而后者的取值屬于目標結點的操作系統(tǒng)的核心地址空間中的虛擬地址。顯然，這兩者之間的比較沒有任何實際意義。為此，本發(fā)明遠程檢查點系統(tǒng)中維護了所有涉及地址比較操作的數(shù)據(jù)結構的原始地址和緩存地址的對應關系。在目標結點中數(shù)據(jù)結構的地址進行比較之前，要先査詢維護上述的地址對應關系的哈希表，將緩存地址全部轉換為目標結點中的原始地址再進行比較。在指針的算術運算方面，對一個復雜數(shù)據(jù)結構或者數(shù)組中的某個元素的尋址經(jīng)常涉及指針的運算，如果遠程讀取和本地緩存操作使數(shù)據(jù)之間原有的相對位置發(fā)生了變化，就有可能導致數(shù)據(jù)錯誤，甚至指針越界。因此，本發(fā)明遠程檢查點系統(tǒng)對于涉及指針運算的數(shù)據(jù)結構都完整地予以復制，以保持其內(nèi)部元素之間的相對位置關系。下面詳細說明本發(fā)明的遠程檢查點切取方法遠程檢査點切取的基本流程如下步驟SIO，加載目標結點的操作系統(tǒng)符號表System.map。步驟S20，加載目標結點的操作系統(tǒng)核心類型表Kemtypes。步驟S30，根據(jù)目標進程號査找目標進程的進程控制塊，并復制到本地緩沖區(qū)中。步驟S40，創(chuàng)建遠程檢查點映像的文件頭；步驟S41，保存目標進程的PID，UID，EUID,GID,EGID和名稱(comm[])等基本屬性。步驟S42，保存CPU的狀態(tài)信息，包括通用寄存器、調(diào)試寄存器和協(xié)處理器的狀態(tài)。步驟S43，保存信號(Signal)處理信息。步驟S44,根據(jù)mm一struct結構保存進程的虛擬地址空間。i)首先，保存代碼段、數(shù)據(jù)段、堆空間、堆棧段和環(huán)境變量區(qū)的起止地址；ii)然后，保存各個vma—area—struct對應的虛擬內(nèi)存區(qū)域(VirtualMemoryArea,VMA)。數(shù)據(jù)段、堆空間和堆棧段內(nèi)的物理頁面全部會被遠程讀取，所含數(shù)據(jù)并非全零的頁面都將被保存到檢查點映像中。步驟S50，保存root,altroot和當前工作目錄的完整路徑。步驟S60，保存目標進程的文件描述符表。步驟S70，逐一保存目標進程已打開文件的基本信息。步驟S71，對于普通文件，本發(fā)明實施例中，記錄文件名、訪問模式、長度、偏移等信息。較佳地，所述普通文件為只讀文件和通過內(nèi)存映射方式打開的讀/寫文件。步驟S72，對于字符設備，按照不同的主、從設備號，分別調(diào)用對應的設備凍結函數(shù)。本發(fā)明實施例中，例如，對Myrinet通信端口等字符設備的檢查點在此處被調(diào)用。步驟S80，為遠程檢査點映像文件加入末尾標記。相應地，本發(fā)明還提供一種遠程檢查點恢復系統(tǒng)和方法。檢查點恢復系統(tǒng)和方法，利用檢査點文件中保存的進程狀態(tài)信息，重建目標進程，使其能夠正確地繼續(xù)運行。檢査點恢復系統(tǒng)和方法一般需要與其對應的檢查點切取系統(tǒng)和方法實現(xiàn)于機群系統(tǒng)中的同一層次，即核心級和用戶級的檢查點切取過程應該分別對應于核心級和用戶級的恢復過程，這是由于在計算機系統(tǒng)中的不同層次，進程的狀態(tài)信息有不同的位置、格式以及與之相對應的訪問方式。但是，對于本發(fā)明的遠程檢查點切取系統(tǒng)和方法而言，由于其檢查點文件的格式與核心級檢查點系統(tǒng)BLCR的檢査點文件的格式兼容，作為一種可實施方式，遠程檢查點的恢復系統(tǒng)和方法也采用了與BLCR基本相同的恢復流程。遠程檢査點切取系統(tǒng)和方法所處理的目標進程可能通過中斷和系統(tǒng)調(diào)用兩種方式進入操作系統(tǒng)。目標進程在被切取檢査點時的狀態(tài)不會影響其遠程檢査點切取過程，但是可能會造成其恢復過程的初始化階段的差異。例如，對于OpteronCPU，通過中斷或者系統(tǒng)調(diào)用的方式進入核心態(tài)的時候，一些寄存器的功能會有區(qū)別。為了降低CPU在系統(tǒng)調(diào)用過程中進出核心態(tài)的開銷，X86—64處理器為平坦段內(nèi)存模式(Flat-SegmentMemoryModel)提供了SYSCALL和SYSRET兩個指令。在64位長模式(LongMode)下，SYSCALL指令會將指向下一條指令的RIP保存到RCX，并從LSTAR寄存器的低64位加載新的RIP值。LSTAR屬于型號特定寄存器(Model-SpecificRegister,MSR)。在Linux系統(tǒng)初始化時，該寄存器被寫入了系統(tǒng)調(diào)用的入口地址。當通過SYSRET返回用戶空間時，CPU又要從RCX中獲得RIP值。如果CPU是通過中斷方式進入核心態(tài)，并通過IRET指令返回用戶態(tài)，RCX寄存器不會被用到。因此，對于通過中斷方式進入核心態(tài)的進程，在恢復時應當從被中斷指令的下一條指令開始執(zhí)行。對于通過系統(tǒng)調(diào)用進入核心態(tài)的進程，在恢復時應當重新開始執(zhí)行被故障所中斷的系統(tǒng)調(diào)用。本發(fā)明的遠程檢查點恢復系統(tǒng)，包括狀態(tài)區(qū)分模塊，用于區(qū)分目標進程的狀態(tài)，以避免對RCX等寄存器的誤用。如，OpteronCPU在通過中斷方式進入核心態(tài)的時候會將一個中斷向量寫入RAX寄存器，而通過系統(tǒng)調(diào)用進入核心態(tài)時會將系統(tǒng)調(diào)用的編號寫入RAX寄存器，因此RAX寄存器就成為區(qū)別目標進程狀態(tài)的標志。在本發(fā)明遠程檢査恢復系統(tǒng)中，還包括跳板模塊，用于恢復完整的通用寄存器狀態(tài)，使進程都以IRET指令退出核心態(tài)，從核心空間返回用戶空間。下面詳細說明本發(fā)明的遠程檢査點恢復方法，其是所述的遠程檢查點切取方法的逆過程，包括如下步驟步驟S10'，檢査點恢復工具rmac—restart創(chuàng)建一個子進程，并開始等待其執(zhí)行完成或異常退出。該子進程將首先創(chuàng)建與被恢復進程相同數(shù)量的線程，然后通過系統(tǒng)調(diào)用的方式進入操作系統(tǒng)核心。在以下步驟中，該系統(tǒng)調(diào)用將順序讀取檢查點文件的內(nèi)容，以rmac—restart子進程(或稱宿主進程)中的各線程為基礎，重建被恢復進程。步驟S20'，根據(jù)檢査點文件的頭部信息判斷其合法性；如果頭部信息中標明的操作系統(tǒng)內(nèi)核、檢査點工具等版本不符合預期，則退出；否則，進入下一步驟。步驟S30'，重新設置目標進程的PID，UID，EUID,GID，EGID和進程名稱等基本屬性。步驟S40'，恢復目標進程核心棧中的CPU狀態(tài)部分，包括通用寄存器、調(diào)試寄存器。步驟S41'，如果檢查點中的進程狀態(tài)標記表明目標進程是在一系統(tǒng)調(diào)用失敗之后被切取，則設置目標進程的RIP和RAX使目標進程恢復運行之后，重新執(zhí)行該系統(tǒng)調(diào)用。步驟S42'，否則，目標進程是通過中斷、異常進入核心態(tài)之后被切取，直接設置輔助目標進程返回用戶態(tài)的跳板程序的地址。步驟S50'，恢復目標進程中信號處理的相關信息。步驟S60'，解除宿主進程的所有虛擬存儲區(qū)域的映射。步驟S70'，加載目標進程的所有虛擬存儲區(qū)域的映射。對于數(shù)據(jù)段、堆空間和堆棧段內(nèi)的數(shù)據(jù)，檢査點恢復工具將以頁面為單位從檢査點文件中讀取，并拷貝到為對應的虛擬地址所分配的物理頁面中。步驟S80'，設置目標進程的虛擬地址空間描述信息，如mm—struct結構中的代碼段、數(shù)據(jù)段、堆空間、堆棧段和環(huán)境變量區(qū)的起止地址等。步驟S90'，恢復目標進程的root,altroot和當前工作目錄的路徑。步驟S100'，關閉宿主進程的close—on—exec文件描述符組(fd—set)中的各個文件。步驟S110'，逐一恢復目標進程已打開文件的基本信息。步驟Slll'，對于普通文件，恢復訪問模式、長度、偏移等屬性。步驟S112'，對于字符設備，按照不同的主、從設備號，調(diào)用對應的設備恢復函數(shù)。如對Myrinet通信端口的檢査點恢復在此處被調(diào)用。步驟S120'，設置目標進程的狀態(tài)為可運行，使其退出遠程檢查點恢復過程之后可以被正常地調(diào)度執(zhí)行。下面詳細說明本發(fā)明的一種通信系統(tǒng)的檢查點切取和恢復系統(tǒng)和方法，以及通信協(xié)議的斷點恢復方法，其相應于本發(fā)明的機群容錯系統(tǒng)和方法中的通信系統(tǒng)的故障報告和恢復的過程。一般地，故障時檢査點系統(tǒng)無法促使目標進程的通信系統(tǒng)在檢査點操作之前進入指定的狀態(tài)，這就產(chǎn)生了兩個問題。首先，如何獲取目標進程的通信系統(tǒng)的完整狀態(tài)？第二，如何確保因目標進程的檢查點和恢復操作而中斷的進程間通信？針對這兩個問題，本發(fā)明探討了機群通信系統(tǒng)對故障時檢査點和恢復機制的支持，主要包括用戶級機群通信系統(tǒng)中的通信設備檢査點切取和恢復系統(tǒng)和方法，以及支持并行應用中的單個進程進行檢查點切取和恢復操作的通信協(xié)議的斷點恢復方法。通信系統(tǒng)的分布式系統(tǒng)檢査點技術的基礎是分布式系統(tǒng)的全局一致性。在本發(fā)明實施例中，對通信系統(tǒng)的分布式系統(tǒng)及其檢查點技術中，作為一種可實施方式，基于以下系統(tǒng)模型1、一個并行應用是由N(N22)個執(zhí)行目標程序(TargetProgram)的進程Pi(0S〈N)組成的集合，其中運行進程&的處理器表示為pi。2、消息傳遞(MessagePassing)是進程間通信的唯一方式，不存在理想的全局時鐘和共享的存儲器。3、進程間通信的可靠性得到保證，不存在消息錯誤、丟失或重復接收的情況。在本發(fā)明中，稱并行應用的進程間通信所產(chǎn)生的消息為計算消息，為了檢査點等目的而產(chǎn)生的消息屬于控制消息。4、進程間通信的每一條鏈路符合先入先出(First-In-First-Out，F(xiàn)IFO)，即對進程Pi經(jīng)由一條鏈路發(fā)往Pj的兩個消息，若消息M,先于M2發(fā)送，則必有M,先于M2被接收。5、進程的失效模型是Fail-Stop,即在失效狀態(tài)下，進程停止計算和通信。6、進程Pi的第j個檢査點表示為C,j。在一個分布式系統(tǒng)中運行的并行應用的狀態(tài)，不僅包括其各個進程的狀態(tài)，還包括進程間通信所產(chǎn)生的消息的狀態(tài)。如圖5所示，表示由Po、P,和P2三個進程組成的一個并行應用。Co、Cl、C2等三條線表示該并行應用的三個狀態(tài)截面(Cut)。一個并行應用的全局檢查點可以認為是其各個進程與某一狀態(tài)截面相交叉的時刻的檢查點的集合。在獲取并行應用的全局檢査點時，總是希望所選的狀態(tài)截面像c。一樣不與任何一個消息相交，但是像Ml和M2這樣的消息如果不采取專門的措施，實際上很難避免。本發(fā)明中，將M1稱為中途消息(In-TransitMessage)，M2稱為孤兒消息(OrphanMessage)。在一個并行應用的第k個全局檢査點中，對于由Pi發(fā)給Pj的消息M，如果在檢査點Ci,k中M尚未發(fā)出，而在Cj,k中M已經(jīng)接收，則M稱為孤兒消息。在一個并行應用的第k個全局檢查點中，對于由Pi發(fā)給Pj的消息M，如果在檢查點Ci，k中M已經(jīng)發(fā)出，而在Cj,k中M尚未接收，則M稱為中途消息，又稱丟失消息。分布式系統(tǒng)中全局一致性狀態(tài)的涵義就是沒有孤兒消息。在通信系統(tǒng)的并行檢査點系統(tǒng)的實現(xiàn)中，對通信系統(tǒng)狀態(tài)的處理大致分為兩種策略，一種是黑箱策略。在該策略中，檢査點協(xié)議的實現(xiàn)位于通信系統(tǒng)層之上，檢查點系統(tǒng)的設計和實現(xiàn)者無需關心底層的通信系統(tǒng)的內(nèi)部實現(xiàn)。這種策略使得檢查點協(xié)議能夠獨立于底層通信系統(tǒng)，具有可移植性強的優(yōu)勢。例如，對于阻塞式協(xié)同檢査點協(xié)議，通信系統(tǒng)的狀態(tài)在檢查點過程之初就被清空(Quiesce)，從而使進程檢査點中不必記錄通信系統(tǒng)的狀態(tài)。對于非阻塞式的C&L協(xié)議，通信系統(tǒng)的狀態(tài)未在全局范圍內(nèi)被清空，而是根據(jù)檢查點協(xié)議中的標記信息，在進程檢査點中順序地保存指定時間范圍內(nèi)收到的消息。本發(fā)明實施例中，描述的是另一種策略，該策略將檢査點系統(tǒng)與通信系統(tǒng)相結合，旨在降低檢査點和恢復過程的開銷，并提高其靈活性。該策略可以使檢查點過程能夠利用通信系統(tǒng)中的各種內(nèi)部狀態(tài)，從而使進程間通信的狀態(tài)，包括進程所用的通信設備的狀態(tài)、進程發(fā)送和接收的部分消息的狀態(tài)，成為進程檢查點的一部分。在本發(fā)明實施例中，將介紹在機群系統(tǒng)中應用更為普遍的用戶級通信系統(tǒng)的檢查點和恢復支持。在本發(fā)明實施例的用戶級通信系統(tǒng)檢査點切取和恢復中，作為一種可實施方式，以Myrinet網(wǎng)絡上的MX通信系統(tǒng)作為平臺進行說明，但是，應當說明的是，其不是對本發(fā)明的限定，本發(fā)明同樣可以應用于其他通信系統(tǒng)。Myrinet是美國Myricom公司(Myricom，Inc.)于1994年推出的一種機群高速通信網(wǎng)絡。本發(fā)明中，MX通信系統(tǒng)的檢査點支持分為兩部分，即通信設備的檢查點切取和恢復，以及通信協(xié)議中的斷點恢復，其中前者是后者的基礎。本發(fā)明實施例中，將首先探討前者，也就是MX端口的檢查點切取和恢復。對于一個進程來說，一個MX端口只是其打開的一個特殊的字符型設備，因此，MX端口的檢查點切取是故障時進程檢査點過程中的步驟之一。MX端口的檢查點切取首先需要明確MX端口狀態(tài)所包含的內(nèi)容。每個MX端口都有且僅有一個發(fā)送請求隊列、短消息發(fā)送緩沖區(qū)、中消息發(fā)送緩沖區(qū)、接收請求隊列、接收緩沖區(qū)、事件隊列和位于Myrinet網(wǎng)卡上的端口控制結構以及發(fā)送句柄鏈表。在沒有通過檢査點協(xié)議清空信道的情況下，在任意時刻都有可能存在一個消息，其完整的控制信息和數(shù)據(jù)位于以上的一個或者多個結構之中。因此，在MX端口的檢查點過程中，所述結構都要予以完整地保存。本發(fā)明實施例中，將對MX通信系統(tǒng)中的發(fā)送請求隊列、短消息發(fā)送緩沖區(qū)、中消息發(fā)送緩沖區(qū)、接收請求隊列、接收緩沖區(qū)、事件隊列、端口控制結構和發(fā)送句柄列表及其對應的檢査點切取逐一進行介紹，并側重于如何確保所保存內(nèi)容的完整性。(一)發(fā)送請求隊列發(fā)送請求隊列位于映射到用戶地址空間的網(wǎng)卡存儲器中。該隊列在邏輯上組織為環(huán)形，由用戶進程填寫，MCP輪詢和讀取。用戶進程填寫一個發(fā)送請求的最后一個步驟是填寫發(fā)送請求結構末端的發(fā)送請求類型，MCP就是根據(jù)該域是否為空(UREQ—NONE)來判斷是否有新的發(fā)送請求。MCP在處理一個發(fā)送請求時，按照發(fā)送請求的內(nèi)容創(chuàng)建一個發(fā)送句柄之后，一般就會將其發(fā)送請求類型域置為空。在該結構的檢査點切取過程中，不會出現(xiàn)錯誤。首先，當MCP保存該結構的時候，用戶進程已經(jīng)停止運行，不會出現(xiàn)MCP已保存的狀態(tài)因用戶進程的繼續(xù)寫入而變得過時的問題，這也就確保了發(fā)送請求不會丟失。其次，MCP根據(jù)一個發(fā)送請求結構創(chuàng)建發(fā)送句柄和將該發(fā)送請求置空這兩個操作位于同一個MCP子程序模塊，其連續(xù)性不會被一個檢查點過程中斷，因此不會出現(xiàn)重復處理的發(fā)送請求。(二)短消息發(fā)送緩沖區(qū)短消息發(fā)送緩沖區(qū)與上述的發(fā)送請求隊列都位于映射到用戶地址空間的網(wǎng)卡存儲器中，長度約為14KB。在處理一個短消息發(fā)送請求時，MX通信庫首先將用戶數(shù)據(jù)拷貝到短消息發(fā)送緩沖區(qū)中的可用空間，然后才會填寫對應的發(fā)送請求。MCP在處理一個短消息發(fā)送請求時，根據(jù)該緩沖區(qū)在網(wǎng)卡存儲器中的基址和用戶數(shù)據(jù)的偏移值計算出用戶數(shù)據(jù)的地址。MCP不修改該緩沖區(qū)的任何內(nèi)容，也無需維護用于訪問該緩沖區(qū)的任何指針。因此，在MX檢査點中只需要完整地保存該緩沖區(qū)的內(nèi)容。(三)中消息發(fā)送緩沖區(qū)MX中的中消息發(fā)送緩沖區(qū)是4MB的主機內(nèi)存，由用戶進程寫入，MCP讀取。在一個進程的地址空間中，該結構與接收緩沖區(qū)和事件隊列都分別占用一個獨立的虛擬內(nèi)存塊(VirtualMemoryArea,VMA)。本發(fā)明實施例通過在VMA結構中添加標記信息使這三個結構可以在進程檢查點過程中被識別出來。該緩沖區(qū)的分配和使用是以頁面為單位。由于無法確保發(fā)送到不同目的地的長消息發(fā)送請求的完成順序，該緩沖區(qū)沒有采用環(huán)形的邏輯結構。在處理一個長消息發(fā)送請求時，MX通信庫先將用戶數(shù)據(jù)拷貝到中消息發(fā)送緩沖區(qū)中的可用頁面，然后才填寫對應的發(fā)送請求。MCP在處理一個長消息發(fā)送請求時，根據(jù)用戶數(shù)據(jù)所在頁面的物理地址啟動主機方DMA來讀取用戶數(shù)據(jù)。MCP不修改該緩沖區(qū)的任何內(nèi)容，因此MX檢査點中只需完整地保存該緩沖區(qū)的內(nèi)容。在MX端口的恢復過程中，該緩沖區(qū)的虛擬地址可以保持不變，但是其物理地址必然會發(fā)生變化，因而需要在MCP中重新注冊該緩沖區(qū)中各頁面的物理地址。此外，接收緩沖區(qū)和事件緩沖區(qū)在恢復過程中也都需要同樣的處理。(四)接收緩沖區(qū)MX中的接收緩沖區(qū)是8MB的主機內(nèi)存，由MCP寫入，用戶進程讀取。該緩沖區(qū)的使用是以頁面為單位，其邏輯結構為環(huán)形。MCP在處理一個網(wǎng)絡接收事件時，只要接收到的用戶數(shù)據(jù)長于RECV—INLINE—SIZE(默認為43字節(jié))，就會順序地從該緩沖區(qū)分配一個頁面。在對應的用戶級接收事件中，MCP通過該頁面在接收緩沖區(qū)中的編號告知用戶數(shù)據(jù)的位置。MX通信庫在處理短消息和長消息的接收事件時，會將用戶數(shù)據(jù)再次拷貝到由用戶提供的接收緩沖區(qū)中。當MX通信庫將用戶數(shù)據(jù)從接收緩沖區(qū)中的某個頁面讀取完畢之后，出于性能考慮，并不會清空該頁面。對于通信系統(tǒng)的故障時檢查點切取過程，用戶地址空間中未清零的頁面就會被保存到檢査點文件中。這就意味著接收緩沖區(qū)中大量已經(jīng)處理過的內(nèi)容都會被保存。為了避免這一現(xiàn)象，以減少檢查點保存開銷，本發(fā)明實施例采取了如下措施，如圖6所示，MCP在填寫接收緩沖區(qū)之后，遞增recvq_vpage—index。MX通信庫在讀取一個接收緩沖區(qū)頁面之后，遞增recvq_offset。該變量的物理地址被注冊到MCP，以使MCP在檢査點過程中可以讀取其當前值。于是，在MX檢査點中只需要保存圖6中的斜線部分即可。(五)事件緩沖區(qū)MX中的事件緩沖區(qū)是128KB的主機內(nèi)存，由MCP負責填寫，用戶進程讀取。該緩沖區(qū)的分配單位是64字節(jié)，即一個事件結構的長度。MCP所填寫的事件類型包括發(fā)送完成事件、短消息和長消息的接收完成事件、連接請求及其應答等。MX通信庫順序處理事件緩沖區(qū)中新到達的事件，以清空每個事件結構中的類型域作為處理完畢的標志。由于該緩沖區(qū)與接收緩沖區(qū)同為較大的環(huán)形緩沖區(qū)，因此本發(fā)明也采取了上述的減少檢査點保存長度的優(yōu)化措施。(六)RDMA窗口MX采用RDMA方式傳遞大于100KB的消息，而RDMA消息的發(fā)送緩沖區(qū)和接收緩沖區(qū)需要分別被注冊為一個RDMA窗口。每個RDMA窗口的詳細注冊信息位于主機方內(nèi)存中，包括RDMA窗口號、注冊順序號、窗口基址、窗口長度以及每個頁面的物理地址等數(shù)據(jù)。向MCP中注冊的RDMA窗口信息僅包括RDMA窗口號、注冊順序號、窗口長度和主機方注冊頁表的基址。在上述的RDMA消息的發(fā)送或者接收過程中，MCP每次僅讀取8個或者32個頁面的物理地址。MX端口的檢查點切取過程需要對RDMA端口進行特殊處理，以避免被檢查點過程中斷的RDMA通信在恢復過程中導致通信故障。首先，在MX端口檢査點過程中處于打開狀態(tài)的RDMA窗口在MX端口恢復過程中需要重新注冊。其次，在MX端口的恢復過程中，如果發(fā)現(xiàn)有尚未完成的RDMA請求，就從讀取主機方的窗口注冊信息開始重新進行RDMA通信。(七)MCP中的相關數(shù)據(jù)結構位于網(wǎng)卡存儲器中的端口控制塊是記錄一個MX端口當前狀態(tài)的最重要結構，其內(nèi)容包括發(fā)送請求隊列地址、短消息發(fā)送緩沖區(qū)地址、中消息發(fā)送緩沖區(qū)、接收緩沖區(qū)和事件隊列的注冊信息以及后兩者當前的寫指針、發(fā)送句柄鏈表的頭指針等。發(fā)送句柄用于記錄一個發(fā)送請求的處理狀態(tài)，同屬于一個MX端口的發(fā)送句柄都在一個單向鏈表中。在一個MX端口的檢查點過程中，當該端口的收發(fā)操作均被凍結之后，上述端口信息就會被(遠程)讀取并寫入進程檢査點映像中。下面詳細說明本發(fā)明的通信系統(tǒng)的檢查點切取方法，其以MX通信為例說明進行設備檢查點切取過程。MX通信系統(tǒng)將Myrinet網(wǎng)卡以字符設備文件的形式提供給用戶程序使用。于是，如果在進程檢查點過程中發(fā)現(xiàn)目標進程打開了MX設備，就可以開始執(zhí)行MX通信設備的檢查點過程。在本發(fā)明實施例中，MX端口的檢査點切取操作包括以下步驟步驟SIOO，讀取MX設備文件的private—data域所指向的MX端口狀態(tài)結構。該結構位于核心地址空間，包含端口號、網(wǎng)卡號，以及接收緩沖區(qū)和事件隊列等結構的基址和當前的讀取指針等信息。步驟S200,向目標端口所在的Myrinet網(wǎng)卡發(fā)送凍結指定端口的命令。步驟S300,如果已確認主機方的目標迸程已經(jīng)停止運行，保存用戶進程能夠寫入的發(fā)送請求隊列和各發(fā)送緩沖區(qū)，否則需要首先向目標進程發(fā)送暫停運行的遠程中斷。步驟S400,在通信協(xié)處理器確認目標端口已凍結之后，保存用戶空間的接收緩沖區(qū)和事件隊列，以及網(wǎng)卡上的端口控制塊和所有該端口正在使用中的發(fā)送句柄。MX中的接收緩沖區(qū)和事件隊列均由MCP通過DMA方式來填充，而MCP的運行完全獨立于主機方的進程，即使主機方的進程由于正常的進程調(diào)度或者系統(tǒng)崩潰而停止運行之后，MCP仍會接收新的消息并填充主機方的相關隊列。為防止接收數(shù)據(jù)的丟失和保持數(shù)據(jù)完整性，應確保在保存通信協(xié)處理器可寫的各個主機方結構之前，通信協(xié)處理器已經(jīng)停止了對應端口的接收操作。下面說明本發(fā)明的通信系統(tǒng)的檢查點恢復過程。MX端口的檢査點恢復過程的內(nèi)容包括MX端口的重新創(chuàng)建、MX端口的重定位和消息的重新發(fā)送，其中消息的重新發(fā)送是對MX端口的檢查點中保存的所有發(fā)送句柄的按序重新執(zhí)行。(A)MX端口的重建在重新創(chuàng)建MX端口時，需要將原MX端口在檢查點中保存的內(nèi)容分別填入新創(chuàng)建的MX端口中的對應位置，包括MCP中的端口控制塊、發(fā)送請求隊列、小消息發(fā)送緩沖區(qū)和操作系統(tǒng)核心中的端口狀態(tài)結構。對于在用戶地址空間中的中消息發(fā)送緩沖區(qū)、接收緩沖區(qū)和事件緩沖區(qū)，其恢復方法與用戶地址空間中的其它區(qū)域無異。(B)MX端口的重定位在MX端口檢査點的恢復過程中，MX端口的重定位關系到端口恢復之后的通信過程是否可能繼續(xù)進行。該問題涉及到MX通信系統(tǒng)中的多個組成部分。在通信固件層，每一個Myrinet網(wǎng)卡都有一個以00:60:DD開頭的MAC地址，這是其唯一標識。當一個Myrinet網(wǎng)卡接入Myrinet網(wǎng)絡之后，還可以由其在網(wǎng)絡中的位置而被唯一地定位。Myrinet映射器在探測到網(wǎng)絡的拓撲之后，計算出任意兩個網(wǎng)卡之間的路由信息，并填充到通信固件層的指定位置。在通信過程中，一個MX端口與其它每個端口之間的鏈接狀態(tài)都分別維護于一個Partner結構之中，這是實現(xiàn)端到端的可靠通信的重要數(shù)據(jù)結構。該結構中主要包括發(fā)送消息序號、接收消息序號、當前鏈接的會話序號和目標MAC地址等。于是，在MX通信系統(tǒng)中，用戶可見的目的地址由三部分組成目的端口號、目的網(wǎng)卡在本地MCP中的路由索引號和該目的地址對應的Partner結構的指針。在MX端口的恢復過程中，原有通信端口的端口號和所在網(wǎng)卡的地址都有可能發(fā)生變化，因此，端口重定位的目的就是消除上述變化對后續(xù)通信過程的影響。下面詳細說明本發(fā)明的通信協(xié)議的檢査點的斷點恢復方法，其以MX通信斷點恢復方法為例而進行說明。通信協(xié)議的斷點恢復方法用于支持因進程檢査點等原因而導致的通信過程中斷。該方法的思路是首先獲取相互通信的一組底層通信系統(tǒng)的全局檢查點，隨后再進行恢復。在本發(fā)明實施例所采用的MX通信系統(tǒng)中，該方法的實現(xiàn)基于對原有的消息應答機制的擴展。在采用消息應答機制的通信系統(tǒng)中，發(fā)送方通過接收應答消息來確認每個消息的成功送達。對于未在指定時間內(nèi)得到應答的消息，發(fā)送方一般需要重新發(fā)送。這就意味著發(fā)送方記錄著任何一個尚未得到應答的消息。從通信系統(tǒng)的角度來看，己經(jīng)發(fā)出，但尚未得到應答的消息就可以認為是中途消息，而傳統(tǒng)意義上的檢査點過程中的中途消息則是指發(fā)送方的進程已經(jīng)發(fā)送，但是尚未被接收方的進程接收的消息。本文以下所指的中途消息都是相對于通信系統(tǒng)而言的中途消息。在獲取通信系統(tǒng)全局檢查點過程中，發(fā)送方主動地保存本地的中途消息比接收方被動地等待所有接收信道中的驅趕消息要更快捷和靈活，并且其開銷不會隨著系統(tǒng)規(guī)模增大而呈指數(shù)增長，比較適合于大規(guī)模機群應用的檢査點過程。本文所采用的通信系統(tǒng)全局檢查點的獲取方法的特點就是每個通信系統(tǒng)在檢查點過程中只記錄本地通信系統(tǒng)的狀態(tài)，避免全局協(xié)同；在恢復過程中重發(fā)中途消息，并過濾可能的重復消息。在本發(fā)明的斷點恢復方法中，令發(fā)起通信斷點的MCP主動地通知其它MCP停止向其發(fā)送消息，并在斷點恢復過程中主動地通知其它MCP恢復通信。為了減少通信斷點對并行應用的影響，在通信斷點恢復之前，可以使不涉及通信斷點發(fā)起者的通信繼續(xù)進行。設發(fā)起通信斷點的MCP為MCPi，斷點恢復方法的包括如下步驟MCPi:1.凍結本地通信端口的收發(fā)操作2.保存已凍結端口的狀態(tài)3.向其它MCP廣播M(CKPT，i)——進程恢復過程——1.向其它MCP廣播M(WAKE，i)正常結點的MCP:如果收到M(CKPT，i):1.設MCP.state=PRECKPT2.啟動對發(fā)送請求目的地和接收緩沖區(qū)剩余空間的檢查，即如果下一個消息的發(fā)送目的地為MCPi或者接收緩沖區(qū)剩余空間少于預定值(1).凍結本地通信端口的收發(fā)操作(2).通過中斷中止該進程的執(zhí)行(3).設本地MCP.state二CKPT。在該狀態(tài)下對后續(xù)收到的每個消息，都會應答消息M(NACKA一CKPT,i)如果收到M(NACKA一CKPT，i):1.凍結本地通信端口的收發(fā)操作2.通過中斷中止該進程的執(zhí)行3.設本地MCP.state=CKPT如果收到M(WAKE，i):1.如果MCP.state-PRECKPT:(1).若未曾收到M(CKPT，j),(j#i)，則設MCP.state=RUNNING2.如果MCP.state=CKPT:(1).繼續(xù)處理因M(CKPT,i)而受阻的發(fā)送請求(2).若未曾收到M(CKPT,j),(j9H)，則:(a)設MCP.state=RUNNING(b)喚醒主機進程在該方法的實現(xiàn)中，檢査點控制消息采用可靠傳輸模式，即每個消息需要接收方返回應答消息。如圖7所示，是該方法的一個四進程示意圖。當MCPl、MCP2等收到M(CKPT，0)之后，進入PRECKPT狀態(tài)，它們之間的通信仍可繼續(xù)進行，例如消息M1。MCP1在消息M2的第一次發(fā)送過程中發(fā)現(xiàn)其接收方MCPO正處于檢査點狀態(tài)，因而迸入端口凍結狀態(tài)(MCP.state=CKPT)。隨后，當MCP1收到消息M3時，返回應答消息M(NACK—CKPT,O)，從而使MCP3也進入端口凍結狀態(tài)。當MCP1接收到M(WAKE,O)，進入正常運行狀態(tài)時，它將繼續(xù)發(fā)送M2。如果發(fā)起斷點的MCP能夠持續(xù)運行，較佳地，那么還可以利用該MCP維護網(wǎng)絡狀態(tài)的一致性，以減少一次廣播操作，即發(fā)起斷點的MCPi不通過廣播M(CKPT，i)的方式主動通知其它的MCP停止向其發(fā)送消息，而是在應答已經(jīng)收到的消息時，通知該消息的發(fā)送方停止向其發(fā)送。進一步，可以通過記錄每個MCP所發(fā)送的M(CKPT，i)或者M(NACK—CKPT,i)的目的地的方式，避免M(WAKE，i)消息的廣播，但這會增大斷點恢復過程的開銷。較佳地，本發(fā)明采用了以下的二叉樹廣播算法，以加速上述方法中的廣播過程。1、對于發(fā)起廣播的MCPi如果(i>0)，向MCPi-1發(fā)送M(CKPT，i);如果(i<(N-l))，向MCPi+1發(fā)送M(CKPT，i);2、對于收到M(CKPT，i)的MCPj:如果(O《(2*j-i)<N)，向MCP2j-i發(fā)送M(CKPT，i);如果(j<i)且((2"-i-1)20)，向MCP2j-i-l發(fā)送M(CKPT,i):如果(j〉i)且((2"-i+1)<N)，向MCP2j-i+l發(fā)送M(CKPT,i);3、每個MCP只有等到其發(fā)送的所有M(CKPT，i)都被應答之后，才能完成。為了支持多個結點同時出現(xiàn)故障的情況，如果一個MCP通過CKPT消息的接收或者發(fā)送超時發(fā)現(xiàn)其發(fā)送目標MCPk己經(jīng)出現(xiàn)了故障，它就主動代替MCPk發(fā)送上述算法所要求的兩個廣播消息，如圖8所示。顯然，這是一個遞歸處理過程。本發(fā)明實施例在如下的測試平臺上進行了MX設備檢查點的性能測試:結點的硬件平臺為2路1.6GHzAMDOpteron處理器，2GB內(nèi)存；網(wǎng)卡為MyricomPCIXD-2，其通信協(xié)處理器和存儲器的主頻均為225MHz。結點操作系統(tǒng)核心為Linux-2.6.12;MPICH的版本為1.2.6;通信系統(tǒng)檢査點的實現(xiàn)基于MXl丄0版本。該測試所選的程序是在結點間進行不間斷的密集消息傳遞的乒乓測試。在一個MX端口的檢査點過程中，端口凍結和端口喚醒過程的開銷分別約為16.0微秒和8.6微秒，將網(wǎng)卡上的端口狀態(tài)保存在檢査點映像中的開銷約為54微秒，如圖9所示。下面詳細說明本發(fā)明的結點監(jiān)測，即一種單機檢查點切取方法，也可以稱為單機故障時檢查點切取方法。單機故障時檢査點切取是機群故障時檢查點切取的基礎，其實現(xiàn)依賴于進程狀態(tài)的保存、結點故障的檢測等結點級支撐技術和基于遠程內(nèi)存訪問的遠程檢查點機制，不涉及對進程間通信狀態(tài)的保存和恢復。步驟S1000，進程完整狀態(tài)保存一個進程的完整狀態(tài)可能包括位于CPU、內(nèi)存和磁盤等不同部件中的多個部分。針對故障時檢査點的特點，需要根據(jù)以上各個部件的特點分別采取對應的方法獲取其中所含的進程狀態(tài)。對于內(nèi)存中的狀態(tài)，即使目標結點的操作系統(tǒng)陷入崩潰狀態(tài)，依然可以通過RDMA方式進行訪問。對于CPU內(nèi)部的通用寄存器、浮點寄存器，由于無法在系統(tǒng)故障時通過指令來讀取，因此，本發(fā)明采取在進程正常運行時主動地予以保存的策略。步驟S1001，CPU通用寄存器的保存當CPU改變運行級別的時候會因上下文的切換而保存各種寄存器的當前值。以Linux2.6的X86\—64實現(xiàn)代碼為例，當CPU要進入核心態(tài)時，將各個通用寄存器、狀態(tài)寄存器都保存在當前進程的核心堆棧的頂部，如圖IO所示。步驟S1002，浮點寄存器的保存在科學計算應用中頻使用的浮點處理器(Floating-PointProcessor,FPU)中的狀態(tài)往往較多。在本發(fā)明實施例的平臺中，Opteron處理器的FPU狀態(tài)包括16個128位的XMM寄存器(XMM0XMM15)、8個128位的浮點寄存器和數(shù)個FPU的控制寄存器，共計512字節(jié)。為了避免在每次進程上下文切換時都要保存FPU的狀態(tài)，X86/X86—64系列處理器都內(nèi)建了專門的優(yōu)化機制，一般稱為LazyContext-Switching。該機制是基于操作系統(tǒng)中的大部分進程都不用或者不常用FPU,將FPU的狀態(tài)保存推遲到另一個進程需要使用FPU的時刻。當CRO寄存器的TS(TaskSwitch)位為1時，CPU如果試圖執(zhí)行X87指令或者媒體指令就會觸發(fā)弁NM(Device-Not-Available)異常，操作系統(tǒng)在該異常的處理中會先將FPU的內(nèi)容保存至其對應進程的指定空間，然后再加載當前進程的FPU內(nèi)容。步驟S1003，CPU高速緩存的保存故障時檢查點不依賴目標結點的CPU在故障時執(zhí)行任何特定的操作，這意味著CPU高速緩存中的內(nèi)容不能在檢查點切取之前及時地寫入內(nèi)存?；赬86多處理器體系結構中通過總線監(jiān)聽(BusSnoopying)協(xié)議實現(xiàn)的緩存一致性，可以在檢查點切取過程中得到指定內(nèi)存地址的最新數(shù)據(jù)內(nèi)容。在結點故障出現(xiàn)之后，如果CPU收到RESET信號，那么其所有寄存器的狀態(tài)將被重置，內(nèi)部高速緩存中的數(shù)據(jù)也會立刻全部失效，而不會被寫回內(nèi)存。步驟S2000，結點故障的檢測準確而高效的結點故障檢測是實現(xiàn)系統(tǒng)故障的預防和快速恢復的前提。從實現(xiàn)級別的角度，結點故障檢測一般可以在操作系統(tǒng)和應用程序(進程)兩個層次分別實現(xiàn)。對于操作系統(tǒng)故障檢測系統(tǒng)的設計，最主要的問題可以歸結為檢測手段和檢測對象這兩個方面。本發(fā)明實現(xiàn)了基于協(xié)處理器并從多個角度檢測操作系統(tǒng)狀態(tài)的方法。步驟S2100,基于協(xié)處理器的結點故障檢測方法。以往的結點故障檢測系統(tǒng)一般依賴主機方CPU進行操作系統(tǒng)的狀態(tài)自檢，例如基于軟件或者硬件看門狗計數(shù)器(WatchdogTimer)的方法。這些方法對于主機方CPU的依賴使其無法處理CPU關中斷或者相應的控制結構已被破壞等情形。為了避免以上問題，同時避免采購專用的結點狀態(tài)監(jiān)測硬件所帶來的成本，本發(fā)明實施例可以采取利用通信協(xié)處理器監(jiān)測主機狀態(tài)的方法。目前，通信協(xié)處理器在機群高速通信系統(tǒng)中日益普及，其性能也得到了較快的提升。本發(fā)明實施例中，基于協(xié)處理器的結點狀態(tài)監(jiān)測方法是首先將給定的主機狀態(tài)監(jiān)測變量的物理地址向協(xié)處理器注冊，隨后每隔一定時間由協(xié)處理器自動讀取各監(jiān)測變量，并與預設的閾值相比較，以判斷結點狀態(tài)是否正常。在該監(jiān)測功能的實現(xiàn)中，本發(fā)明實施例利用了LanaiX通信協(xié)處理器中的時鐘中斷機制。LanaiX的內(nèi)部計時器IT2會按2MHz的頻率遞減其賦值，一旦變?yōu)?的時侯就觸發(fā)其對應的時鐘中斷。在該中斷中，LanaiX發(fā)起讀取主機方指定內(nèi)存地址的DMA操作以讀取本文所選的各個監(jiān)測變量的當前值。步驟S2200，操作系統(tǒng)故障的檢測方法。步驟S2210，時鐘中斷計數(shù)對于常見的Unix、Linux等通用操作系統(tǒng)而言，進程調(diào)度、系統(tǒng)資源監(jiān)控、系統(tǒng)時間的維護都依賴于時鐘中斷?？梢哉f，時鐘中斷的故障不但是操作系統(tǒng)出現(xiàn)死等嚴重故障的重要原因，也是操作系統(tǒng)陷入嚴重故障的重要表現(xiàn)之一。在Linux操作系統(tǒng)中，時鐘中斷的頻率一般設為每秒鐘100到1000次。在每一次時鐘中斷中遞增的jiffies/jiffies一64變量維護著操作系統(tǒng)已處理的時鐘中斷的計數(shù)。本發(fā)明實施例以該變量在每個監(jiān)測周期中是否發(fā)生與監(jiān)測周期相符的變化作為判斷主機操作系統(tǒng)是否正常的基本標志。時鐘中斷計數(shù)方法需要著重考慮協(xié)處理器監(jiān)測周期的精度問題，以避免由于監(jiān)測周期長度的浮動而造成的故障誤報。LanaiX處理器中有一個頻率為2MHz的實時時鐘寄存器(Real-TimeClock,RTC)，可以根據(jù)其讀數(shù)，精確地記錄每個監(jiān)測周期的時間長度。在本發(fā)明中，設每個監(jiān)測周期的主機方時鐘中斷計數(shù)上下浮動的差值小于5為正常，否則即認為主機方操作系統(tǒng)出現(xiàn)了嚴重的拒絕服務故障。該方法的優(yōu)勢是不需要修改操作系統(tǒng)，同時能夠精確檢測嚴重的操作系統(tǒng)核心拒絕服務故障。步驟S2220，操作系統(tǒng)故障計數(shù)作為一種可實施方式，該監(jiān)測變量基于對Linux操作系統(tǒng)的故障處理方法的擴展。這些擴展包括對關鍵的核心函數(shù)接口和系統(tǒng)調(diào)用接口的返回值的檢測和記錄。在Linux操作系統(tǒng)的核心代碼中存在很多對于用戶進程或者其它核心模塊的正常運行至關重要的函數(shù)接口，例如各種系統(tǒng)調(diào)用接口，以及kmalloc()、kmem—cache—alloc()等核心存儲管理接口。這些函數(shù)接口的失敗返回往往會導致調(diào)用模塊的故障，甚至失效。在原有的Linux核心代碼中，對于這些函數(shù)接口的失敗返回的處理一般較為簡單，例如向更上一級返回錯誤代碼，或者不做任何判斷繼續(xù)執(zhí)行。為了支持對操作系統(tǒng)故障更細粒度、更及時的檢測，本文提供了對關鍵性的核心接口函數(shù)的返回值的檢測功能。本發(fā)明設置unlucky()宏用于檢測函數(shù)返回值。#defineunlucky(condition,level)do{if(unlikely((condition)!=0)){inc—danger一level(level);}while(0)當unluck()的第一個參數(shù)中"返回值為NULL"等條件成立時，其第二個參數(shù)就會被增加到本文定義的操作系統(tǒng)故障計數(shù)變量中。該變量的地址被注冊到了監(jiān)測操作系統(tǒng)狀態(tài)的協(xié)處理器中，并由其定時讀取。unhicky()宏被添加到了存儲管理、進程調(diào)度管理等多個核心功能模塊的代碼之中，其能夠及時地反映系統(tǒng)故障的數(shù)量。與監(jiān)測時鐘中斷計數(shù)的方法相比，該方法能夠支持更高的監(jiān)測頻率，但是需要對操作系統(tǒng)的代碼做少量的修改。同時，該方法也完全可以用于對用戶進程的故障計數(shù)，例如在Glibc中嵌入故障計數(shù)功能。將位于用戶空間的故障計數(shù)變量的物理地址注冊到監(jiān)控系統(tǒng)狀態(tài)的協(xié)處理器中。步驟S2230,操作系統(tǒng)嚴重故障代碼檢測方法。前述的兩種用于監(jiān)測操作系統(tǒng)狀態(tài)的變量都位于主機方內(nèi)存中，由協(xié)處理器通過DMA方式定時讀取，本發(fā)明還提供了第三種向協(xié)處理器報告結點故障狀態(tài)的方法。在該方法中，主機方操作系統(tǒng)會主動地將一個故障代碼通過PIO方式寫入?yún)f(xié)處理器的存儲器中。由于對該故障代碼的訪問不必讀取主機方的內(nèi)存，協(xié)處理器就能夠以更高的頻率監(jiān)測結點狀態(tài)。這一方法主要用于操作系統(tǒng)的故障可以得到確認的場合。目前，該方法主要用于擴展Linux操作系統(tǒng)中原有的處理嚴重故障的BUG()、panic()等函數(shù)接口。步驟S3000，遠程檢查點目標進程的狀態(tài)檢測核心級檢查點系統(tǒng)可以方便地利用信號、系統(tǒng)調(diào)用等機制控制和影響目標進程的運行，使其在檢査點過程開始之前到達指定的狀態(tài)。遠程檢查點系統(tǒng)則無法方便地控制目標進程的運行，因此，在遠程檢査點過程開始之前，目標進程的狀態(tài)存在多種可能性。遠程檢査點可以包括以下兩種狀態(tài)的目標進程檢、、(一)故障結點中的進程檢測對于僅能通過操作系統(tǒng)故障計數(shù)機制檢測出的故障結點，由于目標進程仍可能處于運行狀態(tài)，因此需要利用上述的遠程中斷機制中止其運行。對于通過操作系統(tǒng)時鐘中斷計數(shù)和嚴重故障代碼而檢測出的故障結點，故障時檢查點系統(tǒng)已經(jīng)不能再利用遠程中斷機制控制其任何一個進程的狀態(tài)。盡管無法確認遠程檢查點的目標進程的具體狀態(tài)，但是根據(jù)上述故障的特點，可以確認目標進程已經(jīng)通過系統(tǒng)調(diào)用、中斷或者異常進入了核心態(tài)。只要目標進程不在用戶上下文中運行，遠程檢查點就可以對其執(zhí)行檢查點操作。(二)遠程中斷中止的進程檢測方法為了使遠程檢查點可以用于機群管理等目的，可以在目標進程正常運行的情況下，通過遠程中斷功能中止其運行。遠程中斷是借助通信設備在接收到帶有特定標志的消息之后觸發(fā)主機方中斷而實現(xiàn)。為了避免在中斷處理程序中進行進程調(diào)度，為每個CPU都建立了遠程中斷請求結構。該結構由遠程中斷服務程序填寫；當每個CPU進入調(diào)度模塊時會檢查該結構，以判斷是否需要立即中止或者繼續(xù)某個進程的運行。如果要使目標進程在最短的時間內(nèi)中止運行就是要令其所在的CPU盡快進入進程調(diào)度模塊。作為一種可實施方式，在支持搶占式調(diào)度的Linux2.6操作系統(tǒng)內(nèi)核中，CPU從各種中斷服務程序中退出就是一個進入進程調(diào)度模塊的時機。所述遠程中斷的服務程序的基本流程如下1、査找指定進程號對應的進程控制塊。本發(fā)明實施例記該進程所在的CPU為CPUTarget，而執(zhí)行遠程中斷服務程序的CPU為CPUIntr。2、填寫遠程中斷請求結構。3、若CPUTarget=CPUIntr，則直接設置被中斷進程的NEED—RESCHED標志；否則，向CPUTarget發(fā)送中斷向量為RESCHEDULE—VECTOR的處理器間中斷。隨后，CPUTarget在進程調(diào)度模塊中響應遠程中斷請求結構中注冊的請求，并在完成該請求之后更新其中的請求狀態(tài)標志。本發(fā)明的一種機群容錯系統(tǒng)、裝置及方法，其是一種針對并行應用的機群故障時檢查點機制，旨在為并行應用提供局部化的快速故障恢復。對于全局檢査點系統(tǒng)，并行應用中所有進程的狀態(tài)需要在其正常運行的過程中周期性地寫入非易失性存儲設備并保持進程間通信狀態(tài)的一致性，而機群故障時檢査點機制的核心思想則是在并行應用正常運行時僅保存CPU狀態(tài)等在結點故障時無法獲取的狀態(tài)。當發(fā)現(xiàn)故障時，對故障結點上的進程遠程執(zhí)行檢查點，保存其通信系統(tǒng)的狀態(tài)，并通過機群通信協(xié)議保證通信中斷后的正確恢復；本發(fā)明還提出了基于遠程直接內(nèi)存訪問技術的遠程檢査點方法機制。該技術利用遠程直接內(nèi)存訪問的通信過程無需目標結點的CPU和操作系統(tǒng)參與的特點和機群高速通信系統(tǒng)的優(yōu)異性能，在目標結點的操作系統(tǒng)拒絕服務等故障條件下能高效地切取應用狀態(tài)。該技術使應用程序與操作系統(tǒng)的依賴關系變得松散，操作系統(tǒng)的故障不會威脅到被服務進程的繼續(xù)運行。本發(fā)明還實現(xiàn)了用戶級機群通信系統(tǒng)的檢查點和恢復方法機制。該機制利用機群通信系統(tǒng)中的應答、重發(fā)和消息緩沖等通信可靠性保障方法機制，降低了并行檢査點過程對維護通信系統(tǒng)全局一致性狀態(tài)的要求，減少了進程的檢查點和恢復過程的開銷。本發(fā)明還在用戶級機群通信系統(tǒng)的檢查點和恢復機制的基礎上，探索了機群通信協(xié)議如何對并行應用的故障時檢査點和恢復操作提供支持，提出了針對并行應用中單個進程的檢查點的通信斷點恢復的方法機制。本發(fā)明還實現(xiàn)了支持故障時檢査點的結點級容錯方法機制，包括基于協(xié)處理器的結點故障檢測技術和基于進程運行上下文切換的CPU寄存器狀態(tài)保存技術，能夠實現(xiàn)結點故障的快速檢測并確保目標進程的狀態(tài)在結點故障發(fā)生之后的完整性。本發(fā)明還實現(xiàn)了一個輕量級的并行程序故障時檢查點和恢復系統(tǒng)(Crash-TimeChecKpointandRestartsystem,CTCKR)。該系統(tǒng)僅當一個并行應用因其所在的一結點的操作系統(tǒng)崩潰而無法繼續(xù)運行時才觸發(fā)檢査點和恢復操作，避免了定期地頻繁執(zhí)行檢查點所帶來的時間開銷，并且該系統(tǒng)僅僅針對故障結點中的相關進程進行檢査點和恢復，而無需執(zhí)行全局檢査點，因而存儲開銷也顯著降低。通過利用NPB(NASParallelBenchmarks)、LINPACK等基準測試程序的評測實驗表明，本發(fā)明的機群容錯系統(tǒng)、裝置及方法在各項性能測試和基于故障注入的正確性測試中都很好地達到了設計目標，這充分表明了本發(fā)明的機群容錯系統(tǒng)、裝置及方法是一種可行的輕量級機群容錯技術。通過結合附圖對本發(fā)明具體實施例的描述，本發(fā)明的其它方面及特征對本領域的技術人員而言是顯而易見的。以上對本發(fā)明的具體實施例進行了描述和說明，這些實施例應被認為其只是示例性的，并不用于對本發(fā)明進行限制，本發(fā)明應根據(jù)所附的權利要求進行解釋。權利要求1.一種機群容錯系統(tǒng)，其特征在于，包括如下功能模塊遠程檢查點服務器，用于響應來自故障結點的遠程檢查點請求，執(zhí)行檢查點操作；結點故障檢測模塊，用于監(jiān)測本地結點的操作系統(tǒng)和指定進程的運行狀態(tài)，觸發(fā)遠程檢查點；通信系統(tǒng)檢查點模塊，用于實現(xiàn)通信設備的檢查點，并支持通信斷點恢復功能。2、根據(jù)權利要求1所述的機群容錯系統(tǒng)，其特征在于，還包括下列功能模塊并行應用進程管理器，用于為故障時檢査點系統(tǒng)提供被監(jiān)測應用的進程信息，并管理進程恢復過程；檢查點文件服務器，用于存儲檢查點文件，并在故障時檢查點的恢復過程中提供檢查點文件訪問支持。3、一種機群容錯處理方法，其特征在于，包括下列歩驟步驟Al.并向進程管理器在收集到所有子進程的基本信息之后，向遠程檢査點服務器發(fā)送應用注冊請求，所述遠程檢査點服務器在接收該請求之后，根據(jù)所述注冊請求中包含的進程信息，向所有相關結點的結點故障檢測模塊發(fā)送結點監(jiān)控請求；步驟Bl.所述遠程檢査點服務器收到有效的故障報告之后，啟動遠程檢查點過程，在所述遠程檢査點過程成功結束之后，所述遠程檢査點服務器將所得到的檢査點映像文件的位置和對應進程信息發(fā)送給所述并行進程管理器；步驟Cl.所述并行進程管理器確定進程恢復所用的結點，并向目標結點發(fā)送恢復進程的命令。4、根據(jù)權利要求3所述的機群容錯處理方法，其特征在于，所述步驟A1之后，步驟B1之前，還包括下列步驟步驟Sl.在被監(jiān)測應用的運行過程中，結點故障檢測模塊定期主動監(jiān)測所屬結點的操作系統(tǒng)的故障，同時接收和處理結點故障恢復請求；步驟S2.當所述結點故障檢測模塊探測到故障或者收到故障恢復請求時，凍結所屬結點的所有被監(jiān)測的進程打開的通信端口，向預設的遠程檢査點服務器發(fā)送故障報告，請求所述遠程檢查點服務器對指定的進程實施遠程檢査點。5、一種遠程檢查點切取系統(tǒng)，其特征在于，包括內(nèi)核符號尋址模塊，用于對目標進程所在結點的操作系統(tǒng)的內(nèi)核符號的尋址；數(shù)據(jù)緩存模塊，用于數(shù)據(jù)的緩存和預取；指針模塊，用于指針操作，在目標結點中數(shù)據(jù)結構的地址進行比較之前，査詢維護原地址和緩存地址對應關系的哈希表，將緩存地址全部轉換為目標結點中的原始地址后再進行比較。6、一種遠程檢査點切取方法，其特征在于，包括下列步驟步驟SIO，加載目標結點的操作系統(tǒng)符號表；步驟S20，加載目標結點的操作系統(tǒng)核心類型表；步驟S30，根據(jù)目標進程號査找目標進程的進程控制塊，并復制到本地緩沖區(qū)中；步驟S40，創(chuàng)建遠程檢査點映像的文件頭；步驟S50，保存根目錄和當前工作目錄的完整路徑；步驟S60，保存目標進程的文件描述符表；步驟S70，逐一保存目標進程已打開文件的基本信息；步驟S80，為遠程檢査點映像文件加入末尾標記。7、根據(jù)權利要求6所述的遠程檢查點切取方法，其特征在于，所述步驟40進一步包括步驟S41，保存目標進程的基本屬性；步驟S42，保存CPU的狀態(tài)信息，包括通用寄存器、調(diào)試寄存器和協(xié)處理器的狀態(tài)；步驟S43,保存信號處理信息；步驟S44，保存進程的虛擬地址空間。8、一種遠程檢査點恢復系統(tǒng)，其特征在于，包括狀態(tài)區(qū)分模塊，用于區(qū)分目標進程的狀態(tài)，以避免對寄存器的誤用；跳板模塊，用于恢復完整的通用寄存器狀態(tài)，使進程都以IRET指令退出核心態(tài)，從核心空間返回用戶空間。9、一種遠程檢査點恢復方法，其特征在于，包括如下步驟步驟S10'，檢查點恢復工具創(chuàng)建一個子進程，并開始等待其執(zhí)行完成或異常退出；步驟S20'，根據(jù)檢查點文件的頭部信息判斷其合法性；如果頭部信息中標明的操作系統(tǒng)不符合預期，則退出；否則，進入下一步驟；步驟S30'，重新設置目標進程的基本屬性；步驟S40f,恢復目標進程核心棧中的CPU狀態(tài)部分；步驟S50'，恢復目標進程中信號處理的相關信息；步驟S60'，解除宿主進程的所有虛擬存儲區(qū)域的映射；步驟S70'，加載目標進程的所有虛擬存儲區(qū)域的映射；步驟S80'，設置目標進程的虛擬地址空間描述信息；步驟S90'，恢復目標進程的根目錄和當前工作目錄的路徑；步驟S100'，關閉宿主進程的各個文件；步驟S110'，逐一恢復目標進程已打開文件的基本信息；步驟S120'，設置目標進程的狀態(tài)為可運行，使其退出遠程檢査點恢復過程之后可以被正常地調(diào)度執(zhí)行。10、根據(jù)權利要求9所述的遠程檢査點恢復方法，其特征在于，所述步驟步驟S40'進一步包括步驟S41'，如果檢査點中的進程狀態(tài)標記表明目標進程是在一系統(tǒng)調(diào)用失敗之后被切取，則設置目標進程的RIP和RAX使目標進程恢復運行之后，重新執(zhí)行該系統(tǒng)調(diào)用，否則，執(zhí)行步驟S42';步驟S42'，目標進程是通過中斷、異常進入核心態(tài)之后被切取，直接設置輔助目標進程返回用戶態(tài)的跳板程序的地址。11、一種通信系統(tǒng)的檢査點切取方法，其特征在于，包括下列步驟步驟SIOO，讀取通信設備文件所指向的端口狀態(tài)結構；步驟S200，向目標端口所在的網(wǎng)卡發(fā)送凍結指定端口的命令；步驟S300，如果已確認主機方的目標進程已經(jīng)停止運行，保存用戶進程能夠寫入的發(fā)送請求隊列和各發(fā)送緩沖區(qū)，否則需要首先向目標進程發(fā)送暫停運行的遠程中斷；步驟S400，在通信協(xié)處理器確認目標端口己凍結之后，保存用戶空間的接收緩沖區(qū)和事件隊列，以及網(wǎng)卡上的端口控制塊和所有該端口正在使用中的發(fā)送句柄。12、一種通信系統(tǒng)的檢査點恢復方法，其特征在于，包括下列步驟步驟S100'，端口的重建，將原端口在檢查點保存的內(nèi)容分別填入創(chuàng)建的端口的對應位置；歩驟S200'，端口的重定位。13、一種通信的斷點恢復方法，其特征在于，包括下列步驟步驟l.凍結本地通信端口的收發(fā)操作；步驟2.保存已凍結端口的狀態(tài)；步驟3.向其它MCP廣播。14、一種單機故障時檢査點切取方法，其特征在于，包括下列步驟步驟S1000，進程完整狀態(tài)保存；步驟S2000，結點故障的檢測；步驟S3000，遠程檢查點目標進程的狀態(tài)檢測。15、如權利要求14所述的單機故障時檢査點切取方法，其特征在于，所述步驟SIOOO進一步包括步驟S1001，當CPU改變運行級別時，保存各種寄存器的當前值；步驟S1002，當一個進程需要使用浮點寄存器時，保存所述浮點寄存器的狀態(tài)；步驟S1003，保存CPU高速緩存。16、如權利要求14所述的單機故障時檢査點切取方法，其特征在于，所述步驟S2000進一步包括步驟S2100，將給定的主機狀態(tài)監(jiān)測變量的物理地址向協(xié)處理器注冊，每隔一定時間由所述協(xié)處理器自動讀取各監(jiān)測變量，并與預設的閾值相比較，以判斷結點狀態(tài)是否正常；步驟S2210，對時鐘中斷計數(shù)，通過判斷用于維護操作系統(tǒng)己處理的時鐘中斷的計數(shù)的變量在每個監(jiān)測周期中是否發(fā)生與監(jiān)測周期相符的變化來確定操作系統(tǒng)是否正常；步驟S2220，操作系統(tǒng)故障計數(shù)；步驟S2230，檢測操作系統(tǒng)嚴重故障代碼。17、一種遠程中斷中止的進程檢測方法，其特征在于，包括下列步驟步驟N1，査找指定進程號對應的進程控制塊；步驟N2，填寫遠程中斷請求結構；步驟N3，若該進程所在的CPU標識等于執(zhí)行遠程中斷服務程序的CPU標識，則直接設置被中斷進程的標志；否則，向該進程所在的CPU發(fā)送處理器間中斷；隨后，該進程所在的CPU在進程調(diào)度模塊中響應遠程中斷請求結構中注冊的請求，并在完成該請求之后更新其中的請求狀態(tài)標志。全文摘要本發(fā)明公開了一種機群容錯系統(tǒng)、裝置及方法。該系統(tǒng)包括遠程檢查點服務器，用于響應來自故障結點的遠程檢查點請求，執(zhí)行檢查點操作；結點故障檢測模塊，用于監(jiān)測本地結點的操作系統(tǒng)和指定進程的運行狀態(tài)，觸發(fā)遠程檢查點；通信系統(tǒng)檢查點模塊，用于實現(xiàn)通信設備的檢查點，并支持通信斷點恢復功能。其為并行處理的機群提供局部化的快速故障恢復，具有較低的開銷和良好的可擴展性，使得百萬、千萬億次規(guī)模的機群系統(tǒng)能夠具有理想的可用性。文檔編號G06F11/00GK101369241SQ20081021566公開日2009年2月18日申請日期2008年9月12日優(yōu)先權日2007年9月21日發(fā)明者霍志剛申請人:中國科學院計算技術研究所