







摘 要:針對嵌入式領域多功能、多任務,以及復雜多變環境下系統的可重構性、面向較長裝備生命周期的可擴展性與可維護性等應用需求,為實現嵌入式系統下計算、存儲、網絡等資源的統一管理,設計了一種面向嵌入式系統的高可靠資源管理平臺。平臺采用XML可擴展標記語言、Redis數據庫、選舉策略設計與故障恢復機制等關鍵技術,重點實現了資源管理平臺與平臺內應用軟件的高可靠設計,并結合嵌入式應用軟件實例充分驗證了資源管理平臺的功能、指標性能與高可靠特性。
關鍵詞:嵌入式系統;資源管理平臺;高可靠設計
中圖分類號:TP311 文獻標識碼:A 文章編號:2096-4706(2024)17-0115-05
0 引 言
嵌入式系統是以應用為中心,以現代計算機技術為基礎,能夠根據用戶需求(功能、可靠性、成本、體積、功耗、環境等)靈活裁剪軟硬件模塊的專用計算機系統。嵌入式系統的應用十分廣泛,涉及工業生產、日常生活、工業控制、航空航天等多個領域[1-2]。
隨著電子技術、計算機軟件技術、人工智能、大數據以及云計算等信息技術飛速發展,嵌入式系統領域逐漸向著需求可定制、硬件可重組、軟件可重構等特征發展,相關的嵌入式應用面臨著巨大的挑戰,針對嵌入式系統的計算、存儲、網絡等資源的管理平臺設計需求也愈來愈多,如何高效實現嵌入式資源的統一管理成為領域內的熱門研究方向。
較早期時,大部分小規模的嵌入式資源管理平臺是一種基于中心節點的中心式管理架構,雖然這種中心式架構具有資源占用率低、更加輕量、實時性較高等優勢,但過分依賴中心節點,壓力集中,使得此類架構在可靠性、靈活性等方面有所欠缺,因此適用性較低。目前在商用領域資源管理的主流方式大都為使用商用服務器搭建的一種分布式資源管理系統,具有可靠性高、靈活性高、支持更大集群系統等優勢,但這類系統一般為批處理系統,資源占用率較高,需要占用更多的資源來滿足系統運行需求,通常難以滿足嵌入式系統高帶寬、低時延等實時性要求。
現階段,在常見的通用計算平臺上已經有很多資源管理軟件和框架,像Map Reduce、Hadoop、Spark、Storm等[3-5]。文獻[6]設計了一種面向DRE系統的自適應資源管理架構,實現動態任務管理、實時資源分配和自適應控制;文獻[7]提出一個面向嵌入式實時系統的自適應圖形處理器(GPU)資源管理框架。
基于上述研究,本文設計了一種面向嵌入式系統的高可靠資源管理平臺,解決傳統嵌入式應用與硬件綁定,資源無法重用的問題,實現計算、存儲、網絡等資源的統一管理與調度,支持平臺資源池化管理、統一調度與按需分配,支持資源的分時復用,提升軟件資源利用率。
1 系統架構分析
目前主流的系統架構主要有中心式與分布式兩種。
1.1 中心式架構
中心式架構是一種常見的架構設計模式,如圖1所示,是以一個中央控制節點為中心,其他普通節點圍繞該中心進行組織和交互。中央控制節點和每一個普通節點進行通信,而普通節點之間不需要通信,因此中心式架構所產生的額外通信開銷為N×T(其中N代表普通節點個數,T代表單次通信耗時)。
中心式的管理方式具有可集中控制與管理、簡潔和易于理解與維護、系統具備強一致性和規范性等優點。但是也存在一系列的潛在缺點,一是單點故障風險,即中央控制器的故障會導致整個系統的癱瘓;二是性能瓶頸問題,即整個系統的性能優劣過分依賴于中央控制器的負載情況;三是靈活性和受限,即整個系統的擴展、調整、重組等都比較困難。
1.2 分布式架構
分布式架構是一種無中央控制節點的架構設計模式,如圖2所示,每一個節點之間是對等的關系,他們之間互相進行數據的組織和交互。由于每一個節點之間均需要進行通信,因此分布式架構所產生的額外通信開銷為N×(N-1)×T(其中N代表普通節點個數,T代表單次通信耗時)。
、
通過分布式架構搭建的資源管理系統,一般適用于大流量網站(處理高并發訪問)、云服務平臺(提供靈活的資源分配)、大數據處理(處理海量數據)、人工智能系統(支持大規模模型訓練)等,具有可擴展性、高可靠性、安全性強等優點。
可擴展性,能夠方便地增加或減少系統節點數量,以滿足系統能力需求的動態變化。
可靠性高,部分節點發生故障時,系統仍然能夠正常運行。
安全性強,系統數據信息分布在各個節點上,進一步降低了數據丟失的風險。
同時由于分布式架構的復雜程度,使其也面臨著一系列的挑戰,一是在復雜的協調與同步下,需時刻確保各節點的協同工作,在分布式環境下保證各節點的數據一致性;二是潛在的網絡延遲或故障,大量的數據交互壓力可能會影響系統的整體性能與可靠性,反而降低整體的資源利用率;三是龐大的節點數量,跨區域的部署與管理等[8],需要有效的管理和監控眾多節點。
2 資源管理平臺設計
結合中心式與分布式架構的優缺點,針對嵌入式應用軟件的高帶寬、低時延、強實時性等要求,本文設計了一種面向嵌入式系統的高可靠資源管理平臺,其軟件框架示意圖如圖3所示。
資源管理平臺位于嵌入式應用軟件與操作系統之間,由節點管理器NM(Node Manager)、資源管理器RM(Resource Manager)、從屬資源管理器RM_S(Resource Manager Slave)三部分組成。由于RM與NM、RM與RM_S之間需要進行通信交互,因此當前架構下的額外通信開銷是(N+M)×T(其中N代表NM節點個數,M代表RM_S節點個數,T代表單次通信耗時)。
2.1 節點管理器NM
節點管理器NM主要由資源采集與信息上報組成。資源采集模塊通過調用操作系統相關接口實時獲取硬件節點的計算、存儲、網絡等信息,并按照鍵值對(key-value)的形式統一存儲,形成節點資源池,采集節拍可配置,支持對節點資源池的增、刪、改、查操作;信息上報模塊負責將實時查詢節點資源池中的資源信息,并通過TCP形式統一打包發送給RM。
2.2 資源管理器RM
資源管理器RM主要由信息接收與資源分配組成。信息接收模塊負責接收所有NM上報的資源信息,形成系統資源池,由RM統一管控,支持對系統資源池的增、刪、改、查操作;資源分配模塊負責實時響應嵌入式應用的資源請求(核、內存、帶寬等),依據資源類型、資源需求量、資源剩余量、資源負載、應用關聯性五個因素從資源池中分配當前應用所需資源,支持對系統資源池的改、查操作,可分時工作的嵌入式應用,分配過程中資源可復用。為實現RM的高可靠設計,RM需通過UDP組播的形式按可配置的節拍定期發送心跳信息給各個RM_S。
2.3 從屬資源管理器RM_S
從屬資源管理器RM_S,NM的一種,同時還負責實時接收RM的心跳信息,在RM正常工作時,RM_S處于未激活狀態,只執行NM的功能,當RM的心跳信息連續丟失三次時,認定RM異常,此時多個RM_S之間通過選舉打分的方式,選擇最優的RM_S主動激活成為新的RM,當原先故障的RM又恢復正常并成功上線后,該RM只會發揮RM_S的功能。
3 關鍵技術分析
本文所設計的資源管理平臺,所采用的關鍵技術包括XML(Extensible Markup Language)可擴展標記語言、Redis數據庫、選舉策略設計、故障恢復機制等。
3.1 XML可擴展標記語言
XML是一種用于存儲和交換數據的標記語言,常被選用為應用程序的配置文件,以樹狀結構組織數據,具有良好的可讀性與規范性[9]。
資源管理平臺采用XML配置文件的方式設計系統配置文件,描述了各個節點的角色信息(NM、RM、RM_S)以及計算、存儲、網絡等資源信息。同時要求應用軟件通過應用XML配置文件來描述實際的資源需求。
通常角色信息配置中RM_S的占比情況與系統的節點規模有關,為充分保障資源管理平臺的高可靠運行,當系統節點規模在10個以內時,要求RM_S個數至少為2個,系統節點規模每增加10個,至少需要增加一個RM_S。
3.2 Redis數據庫
Redis是一個開源的、高性能的鍵值對數據庫,支持多種數據類型,讀寫速度快,設有哨兵機制,可以將數據存儲到磁盤,以防止數據丟失等優點[10]。
NM采集的資源信息、嵌入式應用的資源請求、系統的狀態信息等,通過鍵值對的方式存儲在Redis數據庫中,RM_S通過Redis數據庫實現與RM的實時同步,利用Redis的哨兵機制,每當鍵值對信息發送改變時,RM_S自動同步更新該信息,同時每隔一定周期,RM_S主動同步所有的鍵值對信息,保證RM與RM_S之間的信息強一致性,使得RM_S在RM發生故障時,能夠無縫接手RM功能,保障整個系統的高可靠運行。
3.3 選舉策略設計
當RM發生故障時,系統中多個RM_S之間通過選舉的方式,選出一個最優的RM_S來充當RM的功能。采用打分制的選舉策略,對RM_S節點的物理鏈路遠近(有無跨硬件、跨插箱、跨機柜等)、資源總量、余量、負載、網絡、存儲帶寬等進行綜合打分,并設置權重占比,打分項與權重占比情況可通過系統XML配置文件進行具體配置,計算并選擇分數最高的RM_S節點激活成為新的RM。
當RM_S發生故障時,RM會采用相同的打分策略從所有的NM中選擇分數最高的激活成為新的RM_S。
3.4 故障恢復機制
嵌入式應用軟件通過RM的資源分配模塊部署在綜合分數最優的NM上。應用軟件運行起來后,NM實時監測該應用軟件的運行狀態,并實現兩種場景下的故障重構設計。
場景一,應用故障。當NM內應用發生故障時,NM會在當前節點重構該應用,若多次嘗試后,依然無法恢復,NM會反饋給RM,再重新部署運行到其他NM上;
場景二,NM故障。當NM自身發生故障時,RM會依據該NM上的資源占用情況,將NM內所有應用重新部署運行到其他NM上;
場景三,RM故障。當RM發生故障后,多個RM_S之間會迅速決策出綜合評分最高的RM_S,激活RM相關任務,迅速接手RM功能;
場景四,RM_S故障。當RM_S發生故障后,RM會從多個NM之間選出綜合評分最高的NM,激活RM_S相關任務,迅速接手RM_S功能。
4 使用流程
以某嵌入式應用軟件為例,資源管理平臺的使用步驟如圖4所示。
第一步,資源管理平臺依據系統XML配置文件啟動RM、NM、RM_S等節點的相關任務,該配置文件中主要描述了各節點的角色信息、系統資源信息、資源采集節拍、打分權重等。
第二步,嵌入式應用軟件準備好可執行程序與應用XML配置文件,該文件主要描述了當前應用的資源需求、平臺與操作系統要求、應用交互拓撲結構、運行時長等。
第三步,應用軟件向資源管理平臺RM發送部署運行請求,由RM依據資源請求和系統資源余量為嵌入式應用分配合適的NM或RM_S部署運行。
第四步,應用部署運行起來后,資源管理平臺負責實時監測各節點與各應用的狀態。
5 測試驗證
基于上述四步具體使用流程,本文搭建了1個RM、3個RM_S、10個NM規模的資源管理平臺,并設計了Dpc.out/Mti.out/Detect.out三個應用實例。其中RM的運行過程如圖5所示,IP地址為192.9.200.210,主要負責接收應用部署任務、發送心跳信息給RM_S并實時監聽各RM_S與NM的心跳信息。
RM接收到應用部署任務后,將其分別部署在其中兩個NM(IP地址為192.9.200.211與192.9.200.212)上,其中一個NM部署了Dpc與Mti兩個應用,一個NM部署了Detect一個應用,NM的運行過程如圖6所示,除了負責啟動并監聽所部署的應用外,還需周期性地發送心跳信息給RM。
每個RM_S其實也屬于一個NM,只是會額外監聽RM的心跳信息,隨時準備激活成為新的RM,以某個RM_S(192.9.200.213)為例,其運行過程如圖7所示。
針對資源管理平臺的高可靠特性,本文在測試驗證過程分別模擬了應用故障、NM故障、RM故障、RM_S故障場景下資源管理平臺的工作情況,測試故障恢復時間,其中故障判斷周期設置為50 ms,連續丟失3次則認為發生故障,具體恢復時間結果(測100次取平均)如表1所示。
結果顯示四種場景下都能夠實現ms級左右的故障恢復,基本上不影響整個系統的正常運行。其中NM、RM、RM_S的恢復時間包括從診斷故障開始到NM、RM、RM_S啟動成功后的時間,應用故障的恢復時間不包括應用自身的啟動時間(與具體應用相關)。
6 結 論
本文設計了一種以RM、NM、RM_S為核心的資源管理平臺軟件,采用了XML可擴展標記語言、Redis數據庫、選舉策略設計、故障重構設計等關鍵技術,重點描述了該平臺自身以及平臺上應用的故障后的快速恢復機制,進一步體現了該資源管理平臺的高可靠設計,并結合嵌入式應用軟件實例充分驗證了資源管理平臺的功能、指標性能指標與高可靠特性。
參考文獻:
[1] 張志慧.嵌入式系統的特點與發展趨勢分析 [J].電子技術,2023,52(7):286-287.
[2] 馬志剛.嵌入式系統的現狀及發展趨勢 [J].中國設備工程,2020(21):145-147.
[3] 鄭百衡.高實時要求的嵌入式智能計算云平臺設計 [J].單片機與嵌入式系統應用,2022,22(1):48-50.
[4] 邵永杰,王志敏.基于嵌入式云計算平臺的分布式實時計算框架研究 [J].通信技術,2019,52(7):1708-1712.
[5] 尚葳蕤,黨紀紅,張錦江.空間站大規模復雜控制軟件基于數據池的軟件框架設計 [J].載人航天,2024,30(1):89-93.
[6] 吳曉,劉文祥,張凱龍.嵌入式分布實時系統自適應資源管理架構 [J].計算機測量與控制,2012,20(2):457-459.
[7] KIM J,RAJKUMAR R,KATO S. Towards Adaptive GPU Resource Management for Embedded Real-Time Systems [J].ACM SIGBED Review,2013,10(1):14-17.
[8]王姝,溫曉玲.基于資源共享的分布式機載軟件測試系統設計 [J].飛機設計,2024,44(1):76-80.
[9] 張嵩,許蕾,吳永亮.基于XML的標準結構化架構設計 [J].航天標準化,2023(2):47-51+33.
[10] 鄧秀輝,李民,方惠.基于分布式集群高可用管理信息系統設計 [J].制造業自動化,2022,44(7):43-45+122.
作者簡介:程杭林(1993—),男,漢族,安徽六安人,工程師,碩士,研究方向:信息處理軟件工程實現與軟件總體設計;李路野(1986—),男,漢族,湖北漢川人,高級工程師,博士,研究方向:信息處理軟件架構設計和軟件化雷達;王鵬(1990—),男,漢族,河北石家莊人,工程師,博士,研究方向:智能化信息處理與軟件總體設計。
DOI:10.19850/j.cnki.2096-4706.2024.17.022
收稿日期:2024-04-29
Design of Highly Reliable Resource Management Platform for Embedded System
CHENG Hanglin, LI Luye, WANG Peng
(Nanjing Research Institute of Electronics Technology, Nanjing 210039, China)
Abstract: In view of the application requirements of the multi-function and multi-task of embedded domain, the reconstruction of system in complex and ever-changing environment, and scalability and maintainability for long equipment life cycles and so on, in order to achieve unified management of computing, storage, network and other resources in embedded systems, a highly reliable resource management platform for embedded systems is designed. The platform uses key technologies such as XML, Redis database, election policy design, and fault recovery mechanisms, then it focuses on achieving a highly reliable design for the resource management platform and the application software within the platform.
The functions, metric performance and highly reliable characteristics of the resource management platform are fully verified using examples from embedded application software.
Keywords: embedded system; resource management platform; highly reliable design