專利名稱：一種執(zhí)行環(huán)境的管理方法、裝置及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，尤其涉及一種執(zhí)行環(huán)境的管理方法、集群系統(tǒng) 平臺管理子系統(tǒng)和執(zhí)行環(huán)境管理實體。
背景技術(shù)：
當(dāng)今電信系統(tǒng)多采用計算集群(Computer Cluster)的方式作為核心控制 設(shè)備，如CPCI、 ATCA等刀片式服務(wù)架構(gòu)。通常計算集群環(huán)境中采用分布式的 方式進行業(yè)務(wù)的部署，如圖l所示，為計算集群的邏輯模塊示意圖， 一般包含 網(wǎng)絡(luò)管理Agent (Network Management Agent)、 高可用性(HA ， High Availability)管理子系統(tǒng)，軟件管理(Software Management)子系統(tǒng)，平 臺管理(PLM， Platform Management)子系統(tǒng)，業(yè)務(wù)模塊(Application)， 其中，網(wǎng)絡(luò)管理Agent負責(zé)接收或者返回網(wǎng)絡(luò)管理者發(fā)出的命令，并返回設(shè)備 的故障信息，用以故障定位和修復(fù)；HA管理子系統(tǒng)負責(zé)集群環(huán)境中的冗余和 業(yè)務(wù)倒換等管理，保證業(yè)務(wù)能不受軟硬件故障而停止；軟件管理子系統(tǒng)負責(zé)集 群中的軟件版本和軟件包管理，控制軟件升級過程；PLM負責(zé)實時監(jiān)控和發(fā)現(xiàn) 硬件資源的狀態(tài)和故障，以及執(zhí)行硬件的修復(fù)、重啟等管理操作，例如，PLM 發(fā)現(xiàn)硬件故障后通知HA管理中間件處理；且PLM平臺管理子系統(tǒng)通過外部連 接硬件管理hardware Management子系統(tǒng)來實現(xiàn)不同平臺的石更件資源管理。目 前的PLM通常包含兩種資源，即執(zhí)行環(huán)境(EE, Execution Environment)資 源、硬件實體(HE, Hardware Entity)資源(如單板，傳感器，看門狗等)， 其中執(zhí)行環(huán)境EE對應(yīng)集群環(huán)境中一個成員(即業(yè)務(wù)模塊所在的單板)的操作 系統(tǒng)，硬件實體HE對應(yīng)HPI中的硬件資源實體；
發(fā)明人在實現(xiàn)本發(fā)明的過程中，發(fā)現(xiàn)隨著技術(shù)的發(fā)展，盡管電信操作系統(tǒng)由過去以嵌入式操作系統(tǒng)為主逐漸轉(zhuǎn)化成以服務(wù)器式操作系統(tǒng)為主，但是目
前的PLM仍然無法有效管理執(zhí)行環(huán)境EE資源，例如現(xiàn)有的PLM無法感知所 管理的EE的狀態(tài)變化。

發(fā)明內(nèi)容
本發(fā)明實施例提供一種執(zhí)行環(huán)境的管理方法、平臺管理子系統(tǒng)、執(zhí)行環(huán)境 管理實體和集群系統(tǒng)，以實現(xiàn)能感知執(zhí)行環(huán)境EE的狀態(tài)變化。
本發(fā)明實施例提供如下技術(shù)方案
一種集群系統(tǒng)，包括平臺管理子系統(tǒng)和至少一個l丸行環(huán)境管理實體，
所述執(zhí)行環(huán)境管理實體，用于根據(jù)維護的計算資源CR對象信息，監(jiān)控對 應(yīng)的執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源CR對象，在監(jiān)控到CR對象的狀態(tài)發(fā)生變化 時，向所述平臺管理子系統(tǒng)上報相應(yīng)的狀態(tài)變化事件報文；
所述平臺管理子系統(tǒng)，用于根據(jù)該狀態(tài)變化事件報文中的狀態(tài)變化信息以 及預(yù)設(shè)的第一處理策略，向?qū)?yīng)的執(zhí)行環(huán)境管理實體發(fā)送相應(yīng)的管理命令。
以及， 一種平臺管理PLM子系統(tǒng)，包括
第一通信模塊，用于接收執(zhí)行環(huán)境管理EEM實體上報的狀態(tài)變化事件報 文，所述狀態(tài)變化事件報文包含狀態(tài)變化信息，以及向?qū)?yīng)的執(zhí)行環(huán)境管理實 體發(fā)送相應(yīng)的管理命令；
第一處理才莫塊，用于根據(jù)預(yù)設(shè)的第一處理策略和所述狀態(tài)變化信息確定待 發(fā)的管理命令，通過所述第一通信模塊向?qū)?yīng)的執(zhí)行環(huán)境管理實體下發(fā)所述管 理命令。
以及， 一種執(zhí)行環(huán)境管理EEM實體，包括
監(jiān)控模塊，用于根據(jù)維護的計算資源CR對象信息，監(jiān)控與當(dāng)前EEM實 體對應(yīng)的執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源CR對象，在監(jiān)控到CR對象的狀態(tài)發(fā)生 變化時，通過第二通信模塊發(fā)送相應(yīng)的狀態(tài)變化事件報文；第二通信模塊，用于向平臺管理PLM子系統(tǒng)上報相應(yīng)的狀態(tài)變化事件報 文，所述狀態(tài)變化事件報文包含狀態(tài)變化信息。
以及， 一種執(zhí)行環(huán)境的管理方法，所述方法包括
根據(jù)維護的計算資源CR對象信息，監(jiān)控當(dāng)前執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源 CR對象；
當(dāng)監(jiān)控到CR對象的狀態(tài)發(fā)生變化時，向平臺管理子系統(tǒng)PLM上報相應(yīng) 的狀態(tài)變化事件報文，使得所述平臺管理PLM子系統(tǒng)根據(jù)預(yù)設(shè)的第一處理策 略和所述狀態(tài)變化事件報文下發(fā)相應(yīng)的管理命令。
以及， 一種執(zhí)行環(huán)境的管理方法，所述方法包括
接收執(zhí)行環(huán)境管理EEM實體上報的狀態(tài)變化事件報文，該狀態(tài)變化事件 報文包含狀態(tài)變化信息；
根據(jù)該狀態(tài)變化事件報文中的狀態(tài)變化信息和預(yù)設(shè)的第一處理策略，向該 EEM實體下發(fā)相應(yīng)的管理命令。
本發(fā)明實施例的集群系統(tǒng)、PLM子系統(tǒng)、EEM實體，以及執(zhí)行環(huán)境的管 理方法中，PLM通過EEM實體監(jiān)控與當(dāng)前執(zhí)行環(huán)境EE所關(guān)聯(lián)的計算資源CR, 實現(xiàn)監(jiān)控執(zhí)行環(huán)境EE (即實現(xiàn)對執(zhí)行環(huán)境EE細粒度的監(jiān)控)，當(dāng)EEM實體 監(jiān)控到CR對象的狀態(tài)發(fā)生變化時，向PLM上報相應(yīng)的事件報文，以實現(xiàn)PLM 能及時感知當(dāng)前執(zhí)行環(huán)境EE的狀態(tài)變化。


為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施 例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述 中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付 出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。
圖1為現(xiàn)有技術(shù)的一種集群系統(tǒng)的組網(wǎng)示意圖2為本發(fā)明實施例涉及的對象模型依賴關(guān)系示意圖3為本發(fā)明實施例提供的CR類示意圖4為本發(fā)明實施例提供的一種集群系統(tǒng)的邏輯示意圖；圖5為本發(fā)明實施例提供的另一種集群系統(tǒng)的邏輯示意圖； 圖6為本發(fā)明實施例提供的一種集群系統(tǒng)的部署示意圖； 圖7為本發(fā)明提供的平臺管理PLM子系統(tǒng)實施例一的結(jié)構(gòu)示意圖； 圖8為本發(fā)明提供的平臺管理PLM子系統(tǒng)實施例二的結(jié)構(gòu)示意圖； 圖9為本發(fā)明提供的執(zhí)行環(huán)境管理實體實施例一的結(jié)構(gòu)示意圖； 圖10為本發(fā)明提供的執(zhí)行環(huán)境管理實體實施例二的結(jié)構(gòu)示意圖； 圖11為本發(fā)明提供的執(zhí)行環(huán)境管理實體實施例三的結(jié)構(gòu)示意圖； 圖12為本發(fā)明提供的執(zhí)行環(huán)境管理實體實施例四的結(jié)構(gòu)示意圖； 圖13為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例一的流程示意圖； 圖14為為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例二的流程示意圖; 圖15為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例三的流程示意圖； 圖16為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例四的交互示意圖； 圖17為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例五的交互示意圖； 圖18為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例六的交互示意圖； 圖19為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例七的流程示意圖； 圖20為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例八的流程示意圖； 圖21為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例九的交互示意圖； 圖22為本發(fā)明提供的執(zhí)行環(huán)境的啟動方法實施例一的流程示意圖。
具體實施例方式
下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清 楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是 全部的實施例。基于本發(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造 性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。
針對現(xiàn)有的平臺管理(Platform Management、 PLM)子系統(tǒng)與執(zhí)行環(huán)境 (Execution Environment, EE)之間由于其異構(gòu)性不能直接進行管理的現(xiàn)狀， 本發(fā)明實施例提供一種4丸行環(huán)境管理(Execution Environment Managements EEM)實體，平臺管理(Platform Management, PLM)子系統(tǒng)，以及一種在集
9群系統(tǒng)中管理執(zhí)行環(huán)境的方法，來統(tǒng)一對不同的執(zhí)行環(huán)境EE進行管理，這里 不同的執(zhí)行環(huán)境EE可以包括不同構(gòu)架的操作系統(tǒng)(如Linux與Vxworks )， 不同版本的搡作系統(tǒng)(如Linux2.4、 Linux2.6 ),操作系統(tǒng)和虛擬化系統(tǒng)之間等， 應(yīng)當(dāng)理解的是:執(zhí)行環(huán)境EE指能夠為中間件和應(yīng)用程序提供執(zhí)行環(huán)境的實體， 如操作系統(tǒng)OS,或者虛擬機等；相應(yīng)的，本發(fā)明實施例還提供一種集群系統(tǒng)；
需要說明的是為了便于后續(xù)描述，將平臺管理PLM子系統(tǒng)簡稱為PLM， 將執(zhí)行環(huán)境管理EEM實體簡稱為EEM，將執(zhí)行環(huán)境EE簡稱為EE;
本發(fā)明實施例中，通過引入執(zhí)行環(huán)境管理EEM實體與平臺管理PLM子 系統(tǒng)通信以實現(xiàn)感知執(zhí)行環(huán)境EE的狀態(tài)變化；EEM實體通過監(jiān)控與當(dāng)前執(zhí)行 環(huán)境EE所關(guān)聯(lián)的計算資源(Computing Resource, CR)，實現(xiàn)監(jiān)控執(zhí)行環(huán)境 EE (即實現(xiàn)對執(zhí)行環(huán)境EE細粒度的監(jiān)控)，當(dāng)監(jiān)控到CR對象的狀態(tài)發(fā)生變 化時，向PLM上報相應(yīng)的事件報文，以實現(xiàn)PLM能及時感知當(dāng)前執(zhí)行環(huán)境 EE的狀態(tài)變化。
本發(fā)明實施例中，在PLM中引入計算資源(Computing Resource、 CR) 的概念。CR概念的層次在EE之下，從對象角度，EE依賴CR的狀態(tài)，CR 故障則EE故障，CR是EE的自對象；EE依賴于特定的CR來為上層的組件 環(huán)境和應(yīng)用程序提供必要的執(zhí)行資源。CR在不同的硬件環(huán)境下包含CPU、 內(nèi)存、存儲資源、網(wǎng)絡(luò)適配器、其他IO資源等。在一種實現(xiàn)下，計算資源CR 可以包括
基本計算資源CPU占用率，磁盤占用率，內(nèi)存占用率，網(wǎng)口使用率等； 在另一種實現(xiàn)下，計算資源CR可以包括
本地計算資源其包括虛擬的計算資源，如內(nèi)核模塊，進程；以及，物理 計算資源，如網(wǎng)絡(luò)適配器；
計算資源的使用狀態(tài)如CPU占用率，磁盤占用率，內(nèi)存占用率。應(yīng)當(dāng) 理解的是前述為例，計算資源CR的劃分不限于此。
請參閱圖2，為本發(fā)明實施例涉及的對象模型依賴關(guān)系示意圖，如圖2所
示，HPI Domain是指HPI模塊范疇的，HPI Entity是HPI范疇內(nèi)的管理對象
類；
Cluster Domain是指集群管理模塊的范疇，而Cluster Member集群成員則 是其管理的對象類。
中間較為詳細的部分都是平臺管理范疇的管理對象類；
PLMEntity是所有CR、 HE和EE對象的父類，主要用于集中管理所有對 象，簡化存儲和查詢過程，沒有實際的意義，主要功能都是子類來提供；
HE類是硬件資源抽象，例如單板等，是映射硬件管理的對象，與HPI 的HPI Entity--對應(yīng)。
EE類是執(zhí)行環(huán)境的抽象類，例如Linux OS,虛擬機等，它依賴于一個 或多個HE。 EE類因存在Host方式的虛擬化環(huán)境，可能存在EE與EE的依賴 關(guān)系。
CR是EEM領(lǐng)域的對象，可以理解的是EEM可以是PLM外部擴展模塊， CR類是EE類的細化抽象類，主要代表系統(tǒng)資源下的其他小資源，例如內(nèi) 核模塊，系統(tǒng)服務(wù)，CR是用來細化EE的管理粒度而抽象的對象，EE類依賴 CR類。CR類支持自己再細化，所以存在CR與CR方式的依賴關(guān)系。
請參閱圖3，為本發(fā)明實施例涉及的CR類示意圖，其中，CR資源的狀
態(tài)和信息就抽象成CR對象的屬性，CR資源操作就抽象成CR對象的方法；
如圖3所示，在一種實現(xiàn)下，CR對象屬性包括
CR的名字，CR的唯一標(biāo)識；
CR的類型，標(biāo)志此CR屬于何種類型；
CR的就緒狀態(tài)，標(biāo)志CR是否能正常工作；
CR的在位狀態(tài)，標(biāo)注CR是不是己經(jīng)啟動，與CRReadinessState 的區(qū)別為檢査是否存在而不是能不能正常工作； CR出現(xiàn)故障后的默認修復(fù)策略，可以配置成復(fù)位、修復(fù)、重新實 例化等。
CR通知級別，關(guān)鍵、重要、 一般、較低等，關(guān)鍵故障在修復(fù)上一 般采取隔離EE重新啟動；
CRN柳e: CRType:
CRReadinessState: CRPresenceState:
CRDefaultPolicy:
CRNotificationLevel:
11在一種實現(xiàn)下，CR對象方法包括:
CR—INSTANTIATION: CR—UNINSTANTIATION: CR_HEALTHCHECK:
CR—REPAIRE: CR RESET:
實例化該CR管理對象；
銷毀該CR的管理對象；
CR的健康狀態(tài)檢査； 一般有EEM定時執(zhí)行，校驗失敗將產(chǎn)生故障
Notification上報。 CR出現(xiàn)故障的修復(fù)方法； CR的復(fù)位方法；
請參見圖4為本發(fā)明實施例提供的一種集群系統(tǒng)的示意圖，如圖4所示， 本發(fā)明實施例的集群系統(tǒng)包括平臺管理PLM子系統(tǒng)200和執(zhí)行環(huán)境管理 EEM實體300 ( EEM實體可以理解為EEM模塊)，集群系統(tǒng)中一般包括至少 兩個集群成員，每個集群成員 一般包含至少一個執(zhí)行環(huán)境EE(如OS )，而EEM 與執(zhí)行環(huán)境EE對應(yīng)，應(yīng)當(dāng)理解的是本發(fā)明實施例集群系統(tǒng)可以包括一個或 多個EEM實體300,每個EEM實體300對應(yīng)一個EE400,這里的EE400包 括操作系統(tǒng)0S、虛擬才幾等；PLM200通過EEM300對相應(yīng)的執(zhí)行環(huán)境、計算資源 CR進行管理，這里的管理可以包括升級、故障檢測、故障修復(fù)或重啟等； 應(yīng)當(dāng)理解的是從對象角度，EEM實體300管理的對象是計算資源CR,而執(zhí) 行環(huán)境EE依賴CR;
其中，EEM300，用于根據(jù)維護的計算資源CR對象信息，監(jiān)控對應(yīng)的執(zhí) 行環(huán)境EE所關(guān)聯(lián)的計算資源CR對象，在監(jiān)控到CR對象的狀態(tài)發(fā)生變化， 向PLM200上報相應(yīng)的事件報文，所述事件報文包含狀態(tài)變化信息；
其中，這里的計算資源CR對象信息，在一種實現(xiàn)下，可以是CR對象表， 該CR對象表可以包含從當(dāng)前EEM300對應(yīng)的EE抽象出的每個CR對象的屬 性信息和方法信息；以及，這里的狀態(tài)變化信息，例如EE故障類型信息、EE 故障級別信息和/或故障附加信息；
在一種實現(xiàn)下，可以將CR類型(CRType)與EE故障類型進行映射，如 關(guān)鍵進程或關(guān)鍵模塊故障映射成EE核心部件故障；CPU占用率超過閾值事件， 內(nèi)存占用率超過閾值事件，或網(wǎng)口流量超過閾值事件映射成EE基本部件故障；
以及，可以將CR通知級別(CRNotificationLevel)與EE故障級別進行映射，如EE故障級別信息表示關(guān)鍵故障、重要故障、 一般故障等。
在一種實現(xiàn)下，EEM300為第一EEM，用于根據(jù)維護的計算資源CR對象 信息，監(jiān)控對應(yīng)的執(zhí)行環(huán)境EE所關(guān)聯(lián)的計算資源CR對象，在監(jiān)控到CR對 象的狀態(tài)發(fā)生變化，獲得與所述CR對象狀態(tài)變化對應(yīng)的EE狀態(tài)變化信息， 向所述平臺管理子系統(tǒng)上報相應(yīng)的狀態(tài)變化事件報文，所述報文中包含EE狀 態(tài)變化信息。
以及，PLM200，用于根據(jù)該事件報文中的狀態(tài)變化信息以及預(yù)設(shè)的第一 處理策略，向?qū)?yīng)的EEM300下發(fā)相應(yīng)的管理命令；在一種實現(xiàn)下，這里的 第一處理策略可以理解為EE故障恢復(fù)策略,PLM中保存有EE故障恢復(fù)策略； 這里的管理命令包括但不限于鎖定Lock、解鎖Unlock、關(guān)閉Shutdown、啟 動start、重啟Restart和修復(fù)Repair等。其中，Lock命令用于使EE停止提供 服務(wù)，停止應(yīng)用程序的運行，但可以運行EEM程序；Unlock命令用于使EE 重新開始提供服務(wù)；Shutdown命令用于關(guān)機，比如，在檢測到設(shè)備溫度過高 時，PLM下發(fā)關(guān)機命令)Restart命令用于使EE重新啟動；在重啟過程中， 可進行啟動配置校-瞼。Repair命令用于指EE已經(jīng)準(zhǔn)備好重新進入服務(wù)態(tài)，在 此之前要重新評估原先造成EE失效的狀態(tài)。
以及，本發(fā)明實施例集群系統(tǒng)中，EEM300進一步用于接收并執(zhí)行PLM200 下發(fā)的管理命令，從而實現(xiàn)相應(yīng)的操作，如重啟操作系統(tǒng)、鎖定操作系統(tǒng)、或 修復(fù)故障等。這里的管理命令包括與所述上報的事件報文對應(yīng)的管理命令， 或由平臺管理PLM用戶觸發(fā)PLM200所發(fā)出的管理命令。
以及，為了實現(xiàn)通過PLM直接管理EE，本發(fā)明實施例集群系統(tǒng)中， PLM200，進一步用于根據(jù)PLM用戶發(fā)出的操作信息，向該操作信息關(guān)聯(lián)的 EE所對應(yīng)的EEM實體下發(fā)相應(yīng)的管理命令，并接收該EEM實體返回的處理 結(jié)果信息。這里的操作信息，如腳本，其中描述了被操作的對象，表示進行 何種操作的信息等。
請參見圖5為本發(fā)明實施例提供的另一種集群系統(tǒng)的示意圖，如圖5所示， 與圖4的區(qū)別在于，本發(fā)明實施例的集群系統(tǒng)進一步可以包括硬件資源管理 HPI400,用于管理集群系統(tǒng)中的硬件資源HE Entity,例如單板資源，單板
13上的傳感器，單板上的子卡資源等；應(yīng)當(dāng)理解的是從對象角度，EEM實體 300管理的對象是計算資源CR,而執(zhí)行環(huán)境EE依賴CR;
可見，本發(fā)明實施例的集群系統(tǒng)中通過PLM接收到EEM實體在監(jiān)控到 CR對象的狀態(tài)發(fā)生變化時所上報的事件報文，以實現(xiàn)PLM能及時感知當(dāng)前 執(zhí)行環(huán)境EE的狀態(tài)變化；
以及，通過PLM接收事件報文后，向?qū)?yīng)的EEM300下發(fā)相應(yīng)的管理命 令，由EEM300執(zhí)行管理命令完成相應(yīng)的操作(如修復(fù)故障，或重新加載某 個故障的內(nèi)核模塊)，以克服現(xiàn)有嵌入式操作系統(tǒng)中， 一旦應(yīng)用程序和操作系 統(tǒng)本身兩者中一個出現(xiàn)問題，都必須重啟系統(tǒng)的問題；
進一步的，本發(fā)明實施例的集群系統(tǒng)中通過PLM在收到PLM用戶發(fā)出 的操作命令后，向該操作命令關(guān)聯(lián)的EE對應(yīng)的EEM下發(fā)管理命令，以及接 收事件報文后，向?qū)?yīng)的EEM300下發(fā)管理命令，克服了現(xiàn)有的平臺管理 (Platform Management、 PLM)子系統(tǒng)與執(zhí)行環(huán)境(Execution Environment EE)之間由于其異構(gòu)性不能直接進行管理的缺陷，從而通過PLM與EEM實 體的通信實現(xiàn)了統(tǒng)一、集中的對不同執(zhí)行環(huán)境EE進行管理，使PLM擁有跨 OS類型、OS版本、不區(qū)分OS還是虛擬機環(huán)境等關(guān)鍵特性。
請參見圖6為本發(fā)明實施例提供的一種計算集群系統(tǒng)的部署示意圖，如圖 4所示，機框500包括單板501、單板502和單板503;其中，單板503上部 署有平臺管理PLM子系統(tǒng)200以及操作系統(tǒng)OS 401;單板501上部署有執(zhí)行 環(huán)境管理EEM實體300以及操作系統(tǒng)OS 402,這里的EEM300與OS 402相 關(guān)聯(lián)；單板502上部署有執(zhí)行環(huán)境管理EEM實體300以及操作系統(tǒng)OS 403， 這里的EEM300與OS 403相關(guān)聯(lián)；并且，單板501、 502上部署的EEM300 與部署在單板503上的PLM200通信以實現(xiàn)管理OS。應(yīng)當(dāng)理解的是單板503 為管理單板，單板501、 502為業(yè)務(wù)單板。
請參見圖7為本發(fā)明提供的平臺管理PLM子系統(tǒng)實施例一的結(jié)構(gòu)示意圖， 本發(fā)明實施例PLM通過EEM可以管理執(zhí)行環(huán)境EE、計算資源CR,用于根 據(jù)所接收的EEM上報的事件報文中的狀態(tài)變化信息以及預(yù)設(shè)的第一處理策
14略，向?qū)?yīng)的EEM下發(fā)相應(yīng)的管理命令；如圖5所示，本發(fā)明實施例平臺管 理PLM子系統(tǒng)包括
第一通信模塊203，用于接收來自EEM實體上報的狀態(tài)變化事件報文， 所述事件報文包含狀態(tài)變化信息，以及向?qū)?yīng)的EEM下發(fā)相應(yīng)的管理命令；
第一處理模塊202，用于根據(jù)預(yù)設(shè)的第一處理策略和所述狀態(tài)變化信息確 定待發(fā)的管理命令，通過第一通信模塊203向?qū)?yīng)的EEM下發(fā)相應(yīng)的管理命 令。
本發(fā)明實施例的PLM中，可以進一步包括對象管理模塊201，用于根 據(jù)所述狀態(tài)變化事件報文中的狀態(tài)變化信息，維護上報所述狀態(tài)變化事件報文 的EEM實體所對應(yīng)的執(zhí)行環(huán)境EE對象。應(yīng)當(dāng)理解的是對象管理模塊201 查找并維護所有管理對象的狀態(tài)，這里的管理對象包括EE對象、HE對象、 PLM Entity對象等；并且，EEM實體可以通過注冊/注銷等影響PLM中EE對 象的狀態(tài)。
以及，本發(fā)明實施例的PLM中，可以進一步包括轉(zhuǎn)發(fā)模塊204,用于 根據(jù)來自PLM用戶發(fā)出的操作信息，從對象管理模塊201中找到與所述操作 信息關(guān)聯(lián)的EE對象，通過第一通信模塊203將相應(yīng)的管理命令發(fā)送給與所述 EE對象對應(yīng)的EEM實體；
可見，本發(fā)明實施例的PLM子系統(tǒng)通過接收到EEM實體上報的事件報 文，以實現(xiàn)PLM能及時感知當(dāng)前執(zhí)行環(huán)境EE的狀態(tài)變化；
以及，通過PLM接收事件報文后，向?qū)?yīng)的EEM下發(fā)相應(yīng)的管理命令， 由EEM執(zhí)行管理命令完成相應(yīng)的操作(如修復(fù)故障，或重新加載某個故障的 內(nèi)核模塊)，以克服現(xiàn)有嵌入式搡作系統(tǒng)中， 一旦應(yīng)用程序和操作系統(tǒng)本身兩 者中一個出現(xiàn)問題，都必須重啟系統(tǒng)的問題；
進一步的，通過PLM在收到PLM用戶發(fā)出的操作命令后，向該操作命 令關(guān)聯(lián)的EE對應(yīng)的EEM下發(fā)管理命令，以及接收事件報文后，向?qū)?yīng)的 EEM300下發(fā)管理命令，克服了現(xiàn)有的平臺管理PLM子系統(tǒng)與執(zhí)行環(huán)境EE 之間由于其異構(gòu)性不能直接進行管理的缺陷，從而使PLM擁有跨OS類型、 OS版本、不區(qū)分OS還是虛擬機環(huán)境等關(guān)鍵特性。請參見圖8為本發(fā)明提供的平臺管理PLM子系統(tǒng)實施例二的結(jié)構(gòu)示意圖， 如圖8所示，本發(fā)明實施例平臺管理PLM子系統(tǒng)包括
第一通信模塊213,用于接收來自EEM實體上報的事件報文，所述事件 報文包含狀態(tài)變化信息，并向?qū)?yīng)的EEM下發(fā)相應(yīng)的管理命令，以及接收來 自EEM的校驗請求，所述校驗請求包含當(dāng)前EEM對應(yīng)的EE本地實際配置信 息，并向相應(yīng)的EEM返回校驗結(jié)果信息；在一種實現(xiàn)下，這里校驗請求為EE 系統(tǒng)啟動時，由EEM發(fā)送的。
第一處理模塊212，用于根據(jù)預(yù)設(shè)的第一處理策略和所述狀態(tài)變化信息確 定待發(fā)的管理命令，通過第一通信模塊213向?qū)?yīng)的EEM下發(fā)相應(yīng)的管理命
令；
對象管理模塊211，用于根據(jù)所述狀態(tài)變化信息，維護上才艮所述狀態(tài)變化 事件報文的EEM實體所對應(yīng)的執(zhí)行環(huán)境EE對象；
轉(zhuǎn)發(fā)模塊214,用于根據(jù)來自PLM用戶發(fā)出的操作信息，從對象管理模 塊211中找到與所述操作信息關(guān)聯(lián)的EE對象，通過第一通信模塊213將相應(yīng) 的管理命令(如鎖定、重啟、解鎖命令)發(fā)送給與所述EE對象對應(yīng)的EEM 實體； 以及，配置校驗?zāi)K215，用于根據(jù)所述校驗請求，校驗EE的實際配置 信息和參照配置信息是否一致，并通過第一通信才莫塊213返回校驗結(jié)果信息。
可見，本發(fā)明實施例的PLM子系統(tǒng)通過接收到EEM實體上報的事件報 文，以實現(xiàn)PLM能及時感知當(dāng)前執(zhí)行環(huán)境EE的狀態(tài)變化；
以及，通過PLM接收事件報文后，向?qū)?yīng)的EEM下發(fā)相應(yīng)的管理命令， 由EEM執(zhí)行管理命令完成相應(yīng)的操作(如修復(fù)故障，或重新加載某個故障的 內(nèi)核模塊)，以克服現(xiàn)有嵌入式操作系統(tǒng)中， 一旦應(yīng)用程序和操作系統(tǒng)本身兩 者中一個出現(xiàn)問題，都必須重啟系統(tǒng)的問題；
以及，通過PLM在收到PLM用戶發(fā)出的操作命令后，向該操作命令關(guān) 聯(lián)的EE對應(yīng)的EEM下發(fā)管理命令，以及接收事件報文后，向?qū)?yīng)的EEM300 下發(fā)管理命令，克服了現(xiàn)有的平臺管理PLM子系統(tǒng)與執(zhí)行環(huán)境EE之間由于 其異構(gòu)性不能直接進行管理的缺陷，從而使PLM擁有跨OS類型、OS版本、 不區(qū)分OS還是虛擬機環(huán)境等關(guān)鍵特性；進一步的，通過在EE系統(tǒng)啟動時，進行EE配置數(shù)據(jù)的校驗，完善了 EE (操作系統(tǒng))的啟動認證，避免了因出現(xiàn)版本不匹配所造成的業(yè)務(wù)程序不能正 常運行，對系統(tǒng)的可靠性造成的沖擊。
請參見圖9為本發(fā)明提供的執(zhí)行環(huán)境管理EEM實體實施例一的結(jié)構(gòu)示意 圖，本發(fā)明實施例EEM實體用于向PLM提供CR資源監(jiān)控和查詢的能力，將 狀態(tài)變化事件(用于故障通知或區(qū)間變化)上報給PLM，并執(zhí)行PLM下發(fā)的 管理命令；如圖9所示，包括
監(jiān)控模塊302，用于根據(jù)維護的計算資源CR對象信息，監(jiān)控與當(dāng)前EEM 實體對應(yīng)的執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源CR對象，在監(jiān)控到CR對象的狀態(tài)發(fā) 生變化，通過第二通信模塊301發(fā)送相應(yīng)的狀態(tài)變化事件報文；其中，這里的 CR對象的狀態(tài)發(fā)生變化，如CPU占用率區(qū)間變化、內(nèi)存占用率區(qū)間變化或 磁盤占用率區(qū)間變化，網(wǎng)口丟包率或者錯包率的區(qū)間變化；關(guān)鍵進程或關(guān)鍵內(nèi) 核模塊發(fā)生故障，以及用戶自定義資源發(fā)生變化等。
在一種實現(xiàn)下，可以將CR類型(CRType)與EE故障類型進行映射，如 關(guān)鍵進程或關(guān)4建才莫塊故障映射成EE核心部件故障；再如CPU占用率超過閾 值事件，內(nèi)存占用率超過閾值事件，或網(wǎng)口流量超過閾值事件映射成EE基本 部件故障；
以及，可以將CR通知級別(CRNotificationLevel)與EE故障級別進行映 射，如EE故障級別信息表示關(guān)鍵故障、重要故障、 一般故障等。
相應(yīng)的，在一種實現(xiàn)下，監(jiān)控模塊302,具體用于根據(jù)維護的計算資源 CR對象信息，監(jiān)控與當(dāng)前EEM實體對應(yīng)的執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源CR對 象，在監(jiān)控到CR對象的狀態(tài)發(fā)生變化時，獲得與所述CR對象狀態(tài)變化對應(yīng) 的EE狀態(tài)變化信息(如EE故障類型信息、EE故障級別信息等)，通過第二 通信模塊301發(fā)送相應(yīng)的狀態(tài)變化事件報文，所述狀態(tài)變化事件報文包含EE 狀態(tài)變化信息。
以及，第二通信模塊301，用于向平臺管理子系統(tǒng)PLM上報相應(yīng)的狀態(tài) 變化事件報文，所述事件報文包含狀態(tài)變化信息，該狀態(tài)變化信息例如EE故 障類型信息、EE故障級別信息和/或故障附加信息。需要說明的是在實際應(yīng)用中，本發(fā)明實施例EEM實體可以作為對應(yīng)的執(zhí)行環(huán)境的后臺進程，如Daemon進程。
可見，本發(fā)明實施例中，通過EEM實體在監(jiān)控到CR對象的狀態(tài)發(fā)生變化時向PLM上報事件報文，以實現(xiàn)PLM能及時感知當(dāng)前執(zhí)行環(huán)境EE的狀態(tài)變化。
請參見圖10為本發(fā)明提供的執(zhí)行環(huán)境管理EEM實體實施例二的結(jié)構(gòu)示意圖，如圖IO所示，本發(fā)明實施例EEM包括策略模塊313，用于保存有第二處理策略；
監(jiān)控模塊312，用于根據(jù)維護的計算資源CR對象信息，監(jiān)控與當(dāng)前EEM實體對應(yīng)的執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源CR對象，在監(jiān)控到CR對象的狀態(tài)發(fā)生變化時，根據(jù)所述策略模塊313中與該CR對象狀態(tài)變化所匹配的第二處理策略通過第二通信模塊311發(fā)送相應(yīng)的狀態(tài)變化事件報文，所述匹配的第二處理策略為上報的處理方式；
第二通信模塊311,用于向平臺管理子系統(tǒng)PLM上報相應(yīng)的狀態(tài)變化事件報文，所述事件報文包含狀態(tài)變化信息；
本發(fā)明實施例EEM,進一步包括本地修復(fù)才莫塊314，用于進行本地修復(fù)或復(fù)位處理；
相應(yīng)的，監(jiān)控模塊312，進一步用于根據(jù)所述策略模塊313中與該CR對象狀態(tài)變化所匹配的第二處理策略由本地修復(fù)^f莫塊314進4亍修復(fù)處理，所述匹配的第二處理策略為本地^修復(fù)處理方式；/人而實現(xiàn)在EEM實體中也可以針對小故障進行一些簡單的修復(fù)，以減少上報PLM的事件。
請參見圖11為本發(fā)明提供的執(zhí)行環(huán)境管理EEM實體實施例三的結(jié)構(gòu)示意圖，如圖11所示，本發(fā)明實施例EEM包括
監(jiān)控模塊323，用于根據(jù)維護的計算資源CR對象信息，監(jiān)控與當(dāng)前EEM實體對應(yīng)的執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源CR對象，在監(jiān)控到CR對象的狀態(tài)發(fā)生變化，通過第二通信模塊321發(fā)送相應(yīng)的狀態(tài)變化事件報文；
第二通信模塊321，用于向平臺管理子系統(tǒng)PLM上報相應(yīng)的狀態(tài)變化事
18件報文，所述事件報文包含狀態(tài)變化信息；具體的是第二通信模塊321與PLM接口；
在PLM感知到EE (如OS)發(fā)生變化后，如EE核心部件故障，確定進行的鎖定或修復(fù)或重啟時，PLM下發(fā)相應(yīng)管理命令；或者由PLM用戶觸發(fā)PLM下發(fā)相應(yīng)管理命令，相應(yīng)的，第二通信模塊321,進一步用于接收PLM下發(fā)的管理命令；
則，本發(fā)明實施例EEM，進一步包括命令解析模塊322,用于解釋并執(zhí)行PLM下發(fā)的管理命令，通過第二通信模塊將命令執(zhí)行結(jié)果返回給PLM;這里執(zhí)行管理命令，有些管理命令，可以是命令解析模塊322直接執(zhí)行相應(yīng)的命令；也可以是解釋命令之后調(diào)用其他模塊執(zhí)行命令，例如當(dāng)管理命令為Restart命令時，由命令解析模塊322調(diào)用啟動管理沖莫塊324重啟相應(yīng)的EE(OS )。
以及，啟動管理模塊324,用于進行執(zhí)行環(huán)境(操作系統(tǒng))啟動管理以及在啟動過程中與PLM通信完成當(dāng)前執(zhí)行環(huán)境配置信息的校驗，包括通過第二通信模塊321向PLM發(fā)送校驗請求及接收PLM返回的校驗結(jié)果信息，并根據(jù)校驗結(jié)果信息繼續(xù)進行處理(掛起或繼續(xù)啟動)；從而完善了操作系統(tǒng)的啟動認證。
如當(dāng)業(yè)務(wù)單板上部署有多個執(zhí)行環(huán)境時，本發(fā)明實施例EEM,進一步包括EE適配模塊325，用于適配不同的執(zhí)行環(huán)境，例如屏蔽不同操作系統(tǒng)、或操作系統(tǒng)的不同版本等。應(yīng)當(dāng)理解的是如果操作系統(tǒng)相同，本發(fā)明實施例的EEM可以不包括EE適配才莫塊325。
請參見圖12為本發(fā)明提供的執(zhí)行環(huán)境管理EEM實體實施例四的結(jié)構(gòu)示意圖，如圖12所示，本發(fā)明實施例四的EEM與實施例三的EEM的區(qū)別在于進一步包括策略;f莫塊334,用于保存有第二處理策略，這里的第二處理策略為EEM實體本地的處理策略；
監(jiān)控模塊333，用于根據(jù)維護的計算資源CR對象信息，監(jiān)控與當(dāng)前EEM實體對應(yīng)的執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源CR對象，在監(jiān)控到CR對象的狀態(tài)發(fā)生變化時，根據(jù)所述策略模塊334中與該CR對象狀態(tài)變化所匹配的第二處理
19策略通過第二通信模塊331發(fā)送相應(yīng)的事件報文，所述匹配的第二處理策略為故障上報的處理方式；
本發(fā)明實施例EEM，進一步包括本地修復(fù)模塊335，用于進行本地修復(fù)或復(fù)位處理；
相應(yīng)的，監(jiān)控模塊333，進一步用于根據(jù)所述策略模塊334中與該CR對象狀態(tài)變化所匹配的第二處理策略由本地修復(fù)模塊335進行修復(fù)處理，所述匹配的第二處理策略為本地修復(fù)處理方式。由于其他模塊的功能與實施例三的EEM實體相同，故不贅述！
請參見圖13為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例一的流程示意
圖，如圖13所示， 一種執(zhí)行環(huán)境的管理方法，應(yīng)用于本發(fā)明實施例的集群系
統(tǒng)中的EEM實體，包括如下步驟
步驟S601、才艮據(jù)維護的計算資源CR對象信息，監(jiān)控當(dāng)前執(zhí)行環(huán)境所關(guān)
聯(lián)的計算資源CR對象；
具體可以為才艮據(jù)維護的計算資源CR對象表，監(jiān)控當(dāng)前EEM實體對應(yīng)
的執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源CR對象；
在一種實現(xiàn)下，這里的計算資源CR對象可以包括兩部分基本計算資源CPU占用率，磁盤占用率，內(nèi)存占用率，網(wǎng)口使用率等；擴展計算資源關(guān)鍵進程，關(guān)鍵內(nèi)核模塊，用戶自定義資源。在另一種實現(xiàn)下，這里的計算資源CR對象可以包括兩部分本地計算資源又可以分成兩部分虛擬的計算資源，如內(nèi)核模塊，進程；
物理計算資源，如網(wǎng)絡(luò)適配器；
計算資源的使用狀態(tài)，如CPU占用率，磁盤占用率，內(nèi)存占用率。步驟S602、當(dāng)監(jiān)控到CR對象的狀態(tài)發(fā)生變化時，向平臺管理子系統(tǒng)PLM
上報相應(yīng)的狀態(tài)變化事件報文，使得所述平臺管理PLM子系統(tǒng)根據(jù)預(yù)設(shè)第一
處理策略和所述狀態(tài)變化事件報文下發(fā)相應(yīng)的管理命令。
以及，步驟S602中，向平臺管理子系統(tǒng)PLM上報相應(yīng)的狀態(tài)變化事件報文包括
獲得與所述CR對象狀態(tài)變化對應(yīng)的EE狀態(tài)變化信息，向所述平臺管理
20子系統(tǒng)上報相應(yīng)的狀態(tài)變化事件報文，所述狀態(tài)變化事件報文包含EE狀態(tài)變化信息，如故障級別信息、故障類型信息和/或故障附加信息。
可見，本發(fā)明實施例中，通過EEM實體在監(jiān)控到CR對象的狀態(tài)發(fā)生變化時向PLM上報事件才艮文，以實現(xiàn)PLM能及時感知當(dāng)前執(zhí)行環(huán)境EE的狀態(tài)變化。
請參見圖14為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例二的流程示意圖，如圖14所示， 一種執(zhí)行環(huán)境的管理方法，應(yīng)用于本發(fā)明實施例的集群系統(tǒng)中的EEM實體，包括如下步驟
步驟S701、才艮據(jù)維護的計算資源CR對象信息，監(jiān)控當(dāng)前執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源CR對象；
步驟S702、當(dāng)監(jiān)控到CR對象的狀態(tài)發(fā)生變化時，確定與該CR對象狀態(tài)變化所匹配的第二處理策略；
步驟S703、當(dāng)匹配的第二處理策略為故障上^^方式時，向平臺管理PLM子系統(tǒng)上報相應(yīng)的狀態(tài)變化事件報文，并執(zhí)行步驟S704;
步驟S704、接收所述平臺管理PLM子系統(tǒng)下發(fā)的管理命令，所述管理命令包括與該狀態(tài)變化事件報文對應(yīng)的管理命令；例如鎖定Lock、解鎖Unlock、重啟Restart、關(guān)閉Shutdown或修復(fù)Repair等。
步驟S705、解釋和執(zhí)行所述PLM下發(fā)的管理命令，并返回所述管理命令的執(zhí)行結(jié)果。
步驟S706、當(dāng)匹配的第二處理策略為本地修復(fù)時，進行本地的修復(fù)或復(fù)位處理。
其中，當(dāng)所述狀態(tài)變化事件報文用于表示EE核心部件發(fā)生故障(故障通知報文)時，所述平臺管理PLM子系統(tǒng)根據(jù)預(yù)設(shè)的第 一處理策略(即故障恢復(fù)策略)和所述狀態(tài)變化事件報文向?qū)?yīng)的EEM實體下發(fā)相應(yīng)的管理命令，如用于重啟執(zhí)行環(huán)境EE的Restart命令。
請參見圖15為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例三的流程示意圖，如圖15所示， 一種執(zhí)行環(huán)境的管理方法，應(yīng)用于本發(fā)明實施例的集群系統(tǒng)中的EEM實體，包括如下步驟
步驟S801 、 EEM啟動EE健康檢查；
具體可以是系統(tǒng)定時器定時觸發(fā)EEM啟動EE健康4企查(周期進行EE健康檢查)，或者是PLM強制觸發(fā)EE監(jiān)控檢查。
步驟S802、從EEM自身維護的CR對象表中獲取第一個CR對象；
步驟S803 - S804、檢查該CR對象的當(dāng)前狀態(tài)，當(dāng)檢查結(jié)果是CR健康時，執(zhí)行步驟S808;當(dāng)檢查結(jié)果是CR故障時，執(zhí)行步驟S805;
這里的CR對象，例如CPU占用率，》茲盤占用率，Mem占用率，網(wǎng)口使用率(流量、速率、丟包率、錯包率)，關(guān)鍵進程，關(guān)鍵內(nèi)核模塊，用戶自定義資源；
這里的CR故障，例如CPU占用率超過閾值，內(nèi)存占用率超過閾值，網(wǎng)口流量超過閾值，或關(guān)鍵進程故障等；
步驟S805、確定與所述CR故障匹配的第二處理策略；當(dāng)與所述CR故障匹配的第二處理策略為本地修復(fù)或復(fù)位時，執(zhí)行步驟S806;當(dāng)與所述CR故障匹配的第二處理策略為故障上報方式時，執(zhí)行步驟S807;
在一種實現(xiàn)下，步驟S805前，可以進一步包括出現(xiàn)健康檢查失敗后，對檢查失敗計數(shù)器作加1處理，(應(yīng)當(dāng)理解的是恢復(fù)健康情況下對檢查失敗計數(shù)器作清零處理)；；險查失敗計數(shù)器超過閾值進行故障后處理，即執(zhí)行步驟S805;以及，在一種實現(xiàn)下，可以預(yù)先設(shè)置上報故障事件報文的故障級別，對于一般故障或較低故障，可以采用在本地修復(fù)或復(fù)位處理，以避免向PLM上報相應(yīng)的事件報文，增加告警信息；對于關(guān)鍵、重要級別的故障，可以采用向PLM上報狀態(tài)變化事件報文(故障事件報文)；
或者，在另一種實現(xiàn)下，本地修復(fù)或者復(fù)位超過設(shè)定閾值時，也可以采用向PLM上報故障事件報文。
步驟S806、對所述故障進行^修復(fù)或復(fù)位處理；并轉(zhuǎn)步驟S810;
步驟S807、向PLM上報相應(yīng)的狀態(tài)變化事件報文；并轉(zhuǎn)步驟S810;
在一種實現(xiàn)下，所述狀態(tài)變化事件報文包含狀態(tài)變化信息，如故障類型信息、故障級別信息等，故障類型信息表示當(dāng)前EE發(fā)生的故障類型(核心部件故障、基本部件故障)，故障級別信息表示故障的嚴重程度(致命、關(guān)鍵、重要、一般、較低)。
步驟S808 -S809、從EEM自身維護的CR對象表中獲取下一個CR對象，并檢查該CR對象的當(dāng)前狀態(tài)；當(dāng)檢查結(jié)果是CR健康時，執(zhí)行步驟S810;當(dāng)檢查結(jié)果是CR故障時，返回執(zhí)行步驟S805;
步驟S810 、判斷當(dāng)前CR對象是否為所述CR對象表中的最后 一個CR對象，如果當(dāng)前CR對象是最后一個CR對象，執(zhí)行步驟S811;如果當(dāng)前CR對象不是最后一個對象，返回執(zhí)行步驟S808;
步驟S811、結(jié)束本次EE健康檢查。
在一種實現(xiàn)下，實現(xiàn)的代碼如下EEM—Do—Health—Check()
{—— —
RC—Item = Get—First—RC—Item—From—Table();〃從RC對象表獲取第一個RC對象While(RC—Item != NULL)
Switch(RC—Item.Status)〃根據(jù)當(dāng)前CR的狀態(tài)分別處理
case HEALTH:〃處于健康狀態(tài)的CR對象
〃出現(xiàn)健康檢查失敗后對檢査失敗計數(shù)器加1,恢復(fù)健康情況下做清零if(RC—Item.CR—HEALTHCHECK() != HEALTH)
{—
RC一Item.FaultCount ++;
} 一else
RC—Item.FaultCount = 0;
} 一
〃檢査失敗計數(shù)器超過閾值進行故障后處理
if (RC—Item.FaultCount >= RC_Item.MAX_FAULTTIME)
{ _ _ _
〃根據(jù)本地修復(fù)策略進行switch(RC—Item.CRRepairePolicy) {case REPAIRE:〃進行修復(fù)處理
RC—Item,CR—REPAIRE();
RC—Item.RepaireCount++;
break;
case RESET:Z/進行復(fù)位處理RC Item.CR—RESET();RC—Item.ResetCount++;break;case REPORT—FAULT—EVENT:〃上報PLM故障事件 EEM—Report—CR—Fault—EVENT(RC Item); break;
RC—Item. Status = FAULT;〃置此CR為故障狀態(tài) break;
case 八111^://處于故障狀態(tài)的01對象 〃恢復(fù)健康則轉(zhuǎn)換回健康狀態(tài) if (RC—Item.CR一HEALTHCHECK() == HEALTH)
RC—Item. Status = HEALTH; RC一Item.RepaireCount = 0; RC—Item.ResetCount = 0;
} —
〃修復(fù)或者復(fù)位超過設(shè)定閾值,需要上報PLM故障事件
if (RC一Item.R印aireCount >= RC—Item.MAX—REP AIRE—TIME ||
RC—Item.ResetCount >= RC—Item.MAX—RESET—TIME)
^ _ 一 —
EEM—Report—CR—Fault—EVENT(RC—Item);
} —— 一
〃繼續(xù)修復(fù)或者復(fù)位
switch(RC—Item.CRRepairePolicy) {
C3S6 :
RC—Item.CR—REPAIRE(); RC—Item.RepaireCount++; break; case :
RC一Item.CR—RESET(); RC—Item.ResetCount++; break;
break;
RC—Item = Get—Next—RC—Item—From—Table();〃獲取表中下一個RC對象
本發(fā)明實施例中，當(dāng)EE的CR對象狀態(tài)發(fā)生變化時，與該EE對應(yīng)EEM 可以向PLM上報相應(yīng)的狀態(tài)變化事件報文，由PLM才艮據(jù)保存的第一處理策 略向?qū)?yīng)的EEM下發(fā)相應(yīng)的管理命令。為了更好的理解，請參見圖16為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例四的交互示意圖，如圖16所示， 一種
執(zhí)行環(huán)境的管理方法，應(yīng)用于本發(fā)明實施例的集群系統(tǒng)，包括如下步驟
步驟901、 EEM監(jiān)控對應(yīng)的EE，這里的EE可以理解為正在處理業(yè)務(wù)(處
于服務(wù)狀態(tài))的操作系統(tǒng)OS;
步驟902、 EE (操作系統(tǒng))發(fā)生關(guān)鍵故障，比如內(nèi)存泄漏，硬件設(shè)備鎖
死，文件系統(tǒng)被破壞等。
步驟903、 EEM實體監(jiān)控到關(guān)鍵故障發(fā)生，具體可以采用實施例三的具
體方法進行監(jiān)控；
在一種實現(xiàn)下，EEM通過監(jiān)控關(guān)鍵進程發(fā)現(xiàn)EE (操作系統(tǒng))故障； 步驟904、 EEM實體確定與當(dāng)前關(guān)鍵故障匹配的第二處理策略；這里的
第二處理策略可以為關(guān)鍵故障則上報；
步驟905、 EEM根據(jù)所述第二處理策略，向PLM上報關(guān)鍵故障事件； 步驟906、 PLM根據(jù)關(guān)鍵故障事件確定與所述事件匹配的第一處理策略；
這里的第一處理策略可以為關(guān)^T建故障則重啟EE;
步驟907、 PLM向EEM下發(fā)用于重啟EE ( OS )的管理命令；這里的管
理命令為Restart命令；
步驟908、 EEM根據(jù)所述管理命令(Restart命令)，重啟相應(yīng)的EE (操
作系統(tǒng))。
請參見圖17為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例五的交互示意 圖，如圖17所示， 一種執(zhí)行環(huán)境的管理方法，應(yīng)用于本發(fā)明實施例的集群系 統(tǒng)，包括如下步驟
步驟911、 EEM監(jiān)控對應(yīng)的EE，這里的EE可以理解為正在處理業(yè)務(wù)(處 于服務(wù)狀態(tài))的操作系統(tǒng)OS;
步驟912、 EE (操作系統(tǒng))發(fā)生故障。
步驟913、 EEM實體監(jiān)控到故障發(fā)生，具體可以采用實施例三的具體方 法進行監(jiān)控；
步驟914、 EEM實體確定與當(dāng)前故障匹配的第二處理策略；這里的第二 處理策略可以為普通故障則本地^修復(fù)；
25步驟915、 EEM對發(fā)生故障的EE執(zhí)行本地修復(fù)處理； 步驟916、 EEM接收EE返回的修復(fù)成功信息。
請參見圖18為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例六的交互示意 圖，如圖18所示， 一種執(zhí)行環(huán)境的管理方法，應(yīng)用于本發(fā)明實施例的集群系 統(tǒng)，包括如下步驟
步驟921、 EEM監(jiān)控對應(yīng)的EE,這里的EE可以理解為正在處理業(yè)務(wù)(處 于服務(wù)狀態(tài))的操作系統(tǒng)OS;
步驟922 、 EE操作系統(tǒng)發(fā)生關(guān)鍵故障；
步驟923、 EEM實體監(jiān)控到關(guān)鍵故障發(fā)生，具體可以采用實施例三的具 體方法進行監(jiān)控；
步驟924、 EEM向PLM上報故障事件；本發(fā)明實施例中，是EEM監(jiān)控 到發(fā)生故障后，即時通知PLM;步驟925、 PLM #4居該故障事件確定與所述 事件匹配的第一處理策略；這里的第一故障策略可以為關(guān)鍵故障則重啟；步 驟926、 PLM向EEM下發(fā)用于重啟EE ( OS )的管理命令；這里的管理命令 為restart命令；
步驟927、 EEM重啟該EE ( OS );
步驟928、 EEM接收該EE (OS)重啟成功信息；
步驟929、 EEM向PLM上報EE重啟成功信息。
針對傳統(tǒng)的PLM無法有效管理執(zhí)行環(huán)境資源的問題，本發(fā)明實施例的 PLM能實現(xiàn)有效管理EE,其中，本發(fā)明實施例的PLM能向?qū)?yīng)的EEM實體 下發(fā)管理命令，使得該EEM實體執(zhí)行收到的管理命令，以進行相應(yīng)的鎖定或 修復(fù)或重啟等操作，從而實現(xiàn)使得狀態(tài)變化的CR對象狀態(tài)恢復(fù)。
本發(fā)明實施例PLM向?qū)?yīng)的EEM實體下發(fā)管理命令，包括如下情況
a. EEM上報狀態(tài)變遷事件給PLM后，PLM根據(jù)(第一處理策略)恢復(fù) 策略，向?qū)?yīng)的EEM實體下發(fā)相應(yīng)的管理指令；
b. PLM接收PLM用戶發(fā)出的操作命令，向?qū)?yīng)的EEM實體下發(fā)相應(yīng)的 管理命令。請參見圖19為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例七的流程示意 圖，如圖19所示， 一種執(zhí)行環(huán)境的管理方法，應(yīng)用于本發(fā)明實施例的集群系 統(tǒng)中的PLM，包括如下步驟
步驟S930、接收執(zhí)行環(huán)境管理EEM實體上報的狀態(tài)變化事件報文，該狀 態(tài)變化事件報文包含狀態(tài)變化信息；
具體可以是接收執(zhí)行環(huán)境管理EEM實體上報的狀態(tài)變化事件報文，該 狀態(tài)變化事件報文包含故障類型信息、故障級別信息，表示EE發(fā)生關(guān)鍵故障；
步驟S931、根據(jù)該狀態(tài)變化事件報文中的狀態(tài)變化信息和預(yù)設(shè)的第一處 理策略，向該EEM實體下發(fā)相應(yīng)的管理命令。
其中，步驟S931具體可以包括根據(jù)該狀態(tài)變化事件報文中的狀態(tài)變化 信息，確定與所述事件匹配的第一處理策略；
根據(jù)所述匹配的第 一處理策略下發(fā)對應(yīng)的管理命令。
在一種實現(xiàn)下，狀態(tài)變化信息包含故障類型信息，如EE核心部件故障、 EE基本部件故障等，和/或故障級別信息，如致命故障、關(guān)鍵故障、重要故障、 一般故障、較低故障等；
當(dāng)狀態(tài)變化事件報文中包含"關(guān)鍵故障"的級別信息時，確定的與所述事 件匹配的第一處理策略為"關(guān)鍵故障"采取隔離EE重新啟動；則相應(yīng)的， 下發(fā)用于重啟EE操作系統(tǒng)的重啟命令；
當(dāng)狀態(tài)變化事件"^艮文中包含"一般故障"的級別信息時，確定的與所述事 件匹配的第一處理策略為針對發(fā)生故障的CR對象，"一般故障，，采取重新 加載CR對象進行修復(fù)；則相應(yīng)的，下發(fā)用于修復(fù)執(zhí)行環(huán)境EE的修復(fù)命令。
當(dāng)狀態(tài)變化事件報文中包含"EE核心部件故障"的故障類型信息、"關(guān)鍵 故障，，的級別信息時，確定的與所述事件匹配的第一處理策略為"EE核心部 件發(fā)生關(guān)鍵故障"采取隔離EE重新啟動；則相應(yīng)的，下發(fā)用于重啟EE操作 系統(tǒng)的重啟命令；
可見，本發(fā)明實施例中通過PLM接收到EEM實體在監(jiān)控到CR對象的狀 態(tài)發(fā)生變化時所上報的事件報文，以實現(xiàn)PLM能及時感知當(dāng)前執(zhí)行環(huán)境EE 的狀態(tài)變化；
27以及，通過PLM接收事件4艮文后，向?qū)?yīng)的EEM下發(fā)相應(yīng)的管理命令， 使得EEM執(zhí)行管理命令完成相應(yīng)的操作，以克服現(xiàn)有嵌入式操作系統(tǒng)中，一 旦應(yīng)用程序和操作系統(tǒng)本身兩者中 一個出現(xiàn)問題，都必須重啟系統(tǒng)的問題。
以及，本發(fā)明實施例中，通過PLM在收到事件報文后，向?qū)?yīng)的EEM下 發(fā)管理命令，克服了現(xiàn)有的平臺管理PLM子系統(tǒng)與執(zhí)行環(huán)境EE之間由于其 異構(gòu)性不能直接進行管理的缺陷，從而通過PLM與EEM實體的通信實現(xiàn)了 統(tǒng)一、集中的對不同執(zhí)行環(huán)境EE進行管理，使PLM擁有跨OS類型、OS版 本、不區(qū)分OS還是虛擬機環(huán)境等關(guān)鍵特性。
請參見圖20為本發(fā)明提供的執(zhí)行環(huán)境的管理方法實施例八的流程示意 圖，如圖20所示， 一種執(zhí)行環(huán)境的管理方法，應(yīng)用于本發(fā)明實施例的集群系 統(tǒng)中的PLM,包括如下步驟
步驟S940、接收平臺管理用戶發(fā)出的操作信息；
例如當(dāng)集群系統(tǒng)啟動且集群成員的操作系統(tǒng)需要升級更新時，平臺管理 用戶下發(fā)用于升級該集群成員的操作系統(tǒng)的操作信息，如軟件升級腳本；
步驟S941、根據(jù)該操作信息，向與該操作信息關(guān)聯(lián)的執(zhí)行環(huán)境EE對應(yīng)的 EEM實體下發(fā)相應(yīng)的管理命令；
例如當(dāng)操作信息是軟件升級腳本時，首先下發(fā)鎖定命令，該鎖定命令用 于使EE停止提供服務(wù)，停止應(yīng)用程序的運行，但可以運行EEM程序；然后 等鎖定成功后，下發(fā)Restart命令，該Restart命令用于使EE ( OS )重啟；最 后下發(fā)解鎖命令。
步驟S942、接收該EEM實體返回的處理結(jié)果信息，并向平臺管理用戶返 回相應(yīng)的操作結(jié)果信息。
例如當(dāng)操作信息是軟件升級腳本時，這里的處理結(jié)果可以是鎖定命令執(zhí) 行結(jié)果，或重啟命令執(zhí)行結(jié)果，或解鎖命令執(zhí)行結(jié)果；這里的操作結(jié)果信息可 以是軟件升級成功信息。
可見，本發(fā)明實施例中，通過PLM在收到PLM用戶發(fā)出的操作信息后， 向該操作信息關(guān)聯(lián)的EE對應(yīng)的EEM下發(fā)管理命令，克服了現(xiàn)有的平臺管理 PLM子系統(tǒng)與執(zhí)行環(huán)境EE之間由于其異構(gòu)性不能直接進行管理的缺陷，從而
28通過PLM與EEM實體的通信實現(xiàn)了統(tǒng)一、集中的對不同凈丸行環(huán)境EE進行管 理，使PLM擁有跨OS類型、OS版本、不區(qū)分OS還是虛擬機環(huán)境等關(guān)鍵特 性。
傳統(tǒng)的PLM無法有效管理執(zhí)行環(huán)境(為了便于理解，下面以EE為操作 系統(tǒng)來進行描述)，只能通過復(fù)位操作系統(tǒng)依賴的硬件來實現(xiàn)操作系統(tǒng)的升級、 或重啟，這種粗粒度的管理造成了系統(tǒng)無法運用當(dāng)前先進的快速重啟機制，而 硬件級別的重啟耗費的時間是很長的， 一旦出現(xiàn)升級失敗，想回退為原來的操 作系統(tǒng)將更加費時和困難。針對這種現(xiàn)狀，本發(fā)明實施例的集群系統(tǒng)能夠快速 啟動操作系統(tǒng)，無需通過硬件級別的重啟來升級操作系統(tǒng)，大大減少重新啟動 時間，提高了系統(tǒng)的可用性。
請參見圖21為本發(fā)明提供執(zhí)行環(huán)境的管理方法實施例九的流程示意圖， 這里的管理具體為升級，應(yīng)當(dāng)理解的是PLM通過EEM可以對執(zhí)行環(huán)境進行 管理，這里的管理包括但不限于升級、故障檢測、故障修復(fù)、重啟等，為了 方便理解，如下以O(shè)S為EE的例子進行描述；如圖21所示， 一種執(zhí)行環(huán)境的 管理方法，應(yīng)用于本發(fā)明實施例的集群系統(tǒng)，包括如下步驟
步驟SlOOl、維護人員通過網(wǎng)管系統(tǒng)下發(fā)軟件升級腳本；
步驟S1002、 PLM根據(jù)該軟件升級腳本，向?qū)?yīng)的EEM下發(fā)鎖定命令， 使得OS停止提供服務(wù)，停止應(yīng)用程序的運行；
步驟S1003、 EEM返回鎖定成功信息；
步驟S1004、操作系統(tǒng)退出集群，停止提供服務(wù)；
步驟S1005、 PLM下發(fā)Restart命令給EEM;
步驟S1006、 EEM從鏡像文件服務(wù)器中獲取新的鏡像文件(Boot Image 文件)；
步驟S1007、 EEM對該操作系統(tǒng)部署新的鏡像文件；
具體可以是EEM下發(fā)新的Boot Image文件，將Boot Image存放到該操 作系統(tǒng)的啟動目錄，同時修改該操作系統(tǒng)的啟動配置，將啟動選項指向新的 Boot Image。
步驟S1008、 EEM重啟該操作系統(tǒng)；步驟S1009、該操作系統(tǒng)啟動進程向EEM請求自身的配置數(shù)據(jù)； 步驟SIOIO、 EEM向PLM請求該梯:作系統(tǒng)的配置數(shù)據(jù)； 步驟SlOll、 PLM向EEM下發(fā)相應(yīng)的配置數(shù)據(jù)； 步驟S1012、 EEM對該配置數(shù)據(jù)進行校驗；
步驟S1013、在對該配置數(shù)據(jù)校驗成功后，EEM將配置數(shù)據(jù)傳遞給操作 系統(tǒng)的啟動進程；
步驟S1014、操作系統(tǒng)啟動成功； 步驟S1015、 EEM監(jiān)控到操作系統(tǒng)啟動成功； 步驟S1016、 EEM向PLM返回啟動成功信息；
步驟S1017、 PLM下發(fā)解鎖命令給EEM,使得EEM重新開始對操作系統(tǒng) 進行CR對象監(jiān)控和事件上報；
步驟S1018、 EEM返回解鎖成功信息； 步驟S1019、操作系統(tǒng)進入集群，開始提供服務(wù)； 步驟S1020、 PLM向網(wǎng)管返回軟件升級成功信息。
需要說明的是在升級之前執(zhí)行軟件升級腳本，主要用于將系統(tǒng)備份，備 份舊的版本鏡像文件(如果在本地)，釋放相關(guān)資源(內(nèi)存)，如果系統(tǒng)升級失 敗回退版本用。
而鏡像文件(Boot Image)是完整的OS版本，是用于引導(dǎo)啟動操作系統(tǒng)， Boot Image的版本就是操作系統(tǒng)的版本。
進一步的，在集群系統(tǒng)中，某個集群成員是否為合法成員是通過此成員向 集群服務(wù)器注冊來進行認證的，認證通過的成員才允許正常的執(zhí)行應(yīng)用程序， 以及接納業(yè)務(wù)，這是對集群系統(tǒng)業(yè)務(wù)安全性的考慮。目前認證一般包含兩個方 面，硬件配置屬性的認證和應(yīng)用軟件模塊版本的認證。對于配置信息的認證而 言，由于電信系統(tǒng)多采用服務(wù)器式(Linux、 Sorilars等)操作系統(tǒng)中，應(yīng)用程 序除了對硬件配置信息很敏感，對于操作系統(tǒng)的內(nèi)核版本、配置，內(nèi)核模塊版 本等配置信息也十分敏感，如果出現(xiàn)配置信息不匹配將造成業(yè)務(wù)程序不能正常 運行，對系統(tǒng)的可靠性造成極大的沖擊。針對這種現(xiàn)狀，本發(fā)明實施例在執(zhí)行 環(huán)境的啟動過程中，提供對執(zhí)行環(huán)境(操作系統(tǒng))的配置信息的驗證，以進一步完善執(zhí)行環(huán)境(操作系統(tǒng))的啟動認證；
請參閱圖22，為本發(fā)明實施例的執(zhí)行環(huán)境的啟動方法的流程圖，如圖22 所示，包括如下步驟
開始操作系統(tǒng)啟動；
步驟S1100、操作系統(tǒng)初始進程啟動；
步驟S1101、 EEM進程啟動；
步驟S1102、 EEM獲取本地操作系統(tǒng)實際配置信息，例如操作系統(tǒng)的 內(nèi)核版本、內(nèi)核模塊版本等；
步驟S1103、 EEM向PLM發(fā)送校驗請求，其中所述校-瞼請求包含所述實 際配置信息；
步驟S1104、 EEM接收PLM返回的實際配置信息和參照配置信息的匹配 是否一致的結(jié)果；當(dāng)兩者不一致時，執(zhí)行步驟S1105;當(dāng)兩者一致時，執(zhí)行步 驟S1109;
步驟S1105、 EEM請求PLM確認操作，當(dāng)返回的確認結(jié)果是等待時，則 執(zhí)行步驟S1106;當(dāng)返回的確認結(jié)果是重啟操作系統(tǒng)時，則執(zhí)行步驟S1107;
步驟S1106、判斷等待超時次數(shù)是否達到閥值N,如果等待超時次數(shù)〈N, 則繼續(xù)等待；反之，則執(zhí)行步驟S1109;
步驟S1107、判斷是否重新加載，當(dāng)確定是重新加載時，執(zhí)行步驟S1108; 反之，執(zhí)行步驟S1100;
步驟S1108、加載指定鏡像文件；
步驟S1109、繼續(xù)啟動其他系統(tǒng)進程，等其他系統(tǒng)進程都啟動完成，則操 作系統(tǒng)啟動完成。
可見，在操:作系統(tǒng)啟動過程中，在獲得正確的配置信息前，初始進程掛起 等待。在PLM對配置信息進行校驗成功的情況下，EEM將配置信息傳遞給操 作系統(tǒng)，啟動過程繼續(xù)進行；通it^f操作系統(tǒng)的配置信息的驗證，以進一步完 善操作系統(tǒng)的啟動認證；從而避免了 一旦出現(xiàn)配置信息不匹配所造成的業(yè)務(wù)程 序不能正常運行的后果。
應(yīng)當(dāng)理解的是也可以通過EEM在系統(tǒng)引導(dǎo)過程中嘗試與PLM通信發(fā) 送啟動事件，獲取操作系統(tǒng)配置校驗信息(參照值)，并校驗本地保存配置信息和配置校驗信息(參照值)是否一致，當(dāng)校驗成功時，EEM向操作系統(tǒng)初 始化進程傳遞校驗通過的配置數(shù)據(jù)，啟動過程繼續(xù)進行。
綜上所述，本發(fā)明實施例的集群系統(tǒng)、PLM子系統(tǒng)、EEM實體，以及執(zhí) 行環(huán)境的管理方法中通過PLM接收到EEM實體在監(jiān)控到CR對象的狀態(tài)發(fā)生 變化時所向上報的事件報文，以實現(xiàn)PLM能及時感知當(dāng)前執(zhí)行環(huán)境EE的狀 態(tài)變化；
以及，通過PLM接收事件報文后，向?qū)?yīng)的EEM下發(fā)相應(yīng)的管理命令， 由EEM執(zhí)行管理命令完成相應(yīng)的操作(如修復(fù)故障，或重新加載某個故障的 內(nèi)核模塊)，以克服現(xiàn)有嵌入式操作系統(tǒng)中， 一旦應(yīng)用程序和操作系統(tǒng)本身兩 者中一個出現(xiàn)問題，都必須重啟系統(tǒng)的問題；
以及，本發(fā)明實施例的集群系統(tǒng)中通過PLM在收到PLM用戶發(fā)出的操 作命令后，向該操作命令關(guān)聯(lián)的EE對應(yīng)的EEM下發(fā)管理命令，以及接收事 件報文后，向?qū)?yīng)的EEM下發(fā)管理命令，克服了現(xiàn)有的平臺管理PLM子系 統(tǒng)與執(zhí)行環(huán)境EE之間由于其異構(gòu)性不能直接進行管理的缺陷，從而通過PLM 與EEM實體的通信實現(xiàn)了統(tǒng)一、集中的對不同執(zhí)行環(huán)境EE進行管理，使PLM 擁有跨OS類型、OS版本、不區(qū)分OS還是虛擬機環(huán)境等關(guān)鍵特性。
以及，本發(fā)明實施例中，當(dāng)需要升級EE (OS)時，PLM接收到網(wǎng)管下發(fā) 的升級腳本后，通過向?qū)?yīng)的EEM下發(fā)鎖定、重啟、和解鎖命令，EEM解析 并執(zhí)行該命令后，升級或重啟相應(yīng)的操作系統(tǒng)，從而實現(xiàn)快速啟動操作系統(tǒng)， 無需通過硬件級別的重啟來升級操作系統(tǒng)，大大減少重新啟動時間，提高了系 統(tǒng)的可用性。
進一步的，本發(fā)明實施例在執(zhí)行環(huán)境的啟動過程中，提供對執(zhí)行環(huán)境(操 作系統(tǒng))的配置信息的驗證，以進一步完善執(zhí)行環(huán)境(操作系統(tǒng))的啟動認證； 從而避免了一旦出現(xiàn)配置信息不匹配所造成的業(yè)務(wù)程序不能正常運行的后果。
是可以通過計算機程序來指令相關(guān)的硬件來完成，所述的程序可存儲于一計算 機可讀取存儲介質(zhì)中，該程序在執(zhí)行時，可包括如上述各方法的實施例的流程。 其中，所述的存儲介質(zhì)可為磁碟、光盤、只讀存儲記憶體(Read-Only Memory, ROM)或隨機存儲記憶體(Random Access Memory, RAM)等。
32以上所述僅為本發(fā)明的幾個實施例，本領(lǐng)域的技術(shù)人員依據(jù)申請文件公開 的可以對本發(fā)明進行各種改動或變型而不脫離本發(fā)明的精神和范圍。
權(quán)利要求
1、一種集群系統(tǒng)，其特征在于，包括平臺管理子系統(tǒng)和至少一個執(zhí)行環(huán)境管理實體，其中，所述執(zhí)行環(huán)境管理實體，用于根據(jù)維護的計算資源CR對象信息，監(jiān)控對應(yīng)的執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源CR對象，在監(jiān)控到CR對象的狀態(tài)發(fā)生變化，向所述平臺管理子系統(tǒng)上報相應(yīng)的狀態(tài)變化事件報文；所述平臺管理子系統(tǒng)，用于根據(jù)該狀態(tài)變化事件報文中的狀態(tài)變化信息以及預(yù)設(shè)的第一處理策略，向?qū)?yīng)的執(zhí)行環(huán)境管理實體發(fā)送相應(yīng)的管理命令。
2、 如權(quán)利要求l所述的系統(tǒng)，其特征在于，所述平臺管理子系統(tǒng)，進一 步用于根據(jù)平臺管理用戶發(fā)出的操作信息，向該操作信息關(guān)聯(lián)的執(zhí)行環(huán)境所對 應(yīng)的執(zhí)行環(huán)境管理實體發(fā)送相應(yīng)的管理命令，并接收該執(zhí)行環(huán)境管理實體返回 的處理結(jié)果信息。
3、 如權(quán)利要求1或2所述的系統(tǒng)，其特征在于，所述執(zhí)行環(huán)境管理實體， 進一步用于執(zhí)行所述平臺管理子系統(tǒng)發(fā)送的管理命令。
4、 一種平臺管理PLM子系統(tǒng)，其特征在于，包括 第一通信模塊，用于接收執(zhí)行環(huán)境管理EEM實體上報的狀態(tài)變化事件報文，所述狀態(tài)變化事件報文包含狀態(tài)變化信息，以及向?qū)?yīng)的執(zhí)行環(huán)境管理實 體發(fā)送相應(yīng)的管理命令；第一處理模塊，用于根據(jù)預(yù)設(shè)的第一處理策略和所述狀態(tài)變化信息確定待 發(fā)的管理命令，通過所述第一通信模塊向?qū)?yīng)的執(zhí)行環(huán)境管理實體下發(fā)所述管 理命令。
5、 如權(quán)利要求4所述的平臺管理PLM子系統(tǒng)，其特征在于，所述平臺管 理PLM子系統(tǒng)進一步包括對象管理模塊，用于根據(jù)所述狀態(tài)變化信息，維護上報所述狀態(tài)變化事件 報文的EEM實體所對應(yīng)的執(zhí)行環(huán)境EE對象。
6、 如權(quán)利要求5所述的平臺管理PLM子系統(tǒng)，其特征在于，所述平臺管理PLM子系統(tǒng)進一步包括轉(zhuǎn)發(fā)模塊，用于根據(jù)來自平臺管理用戶發(fā)出的操作信息，從所述對象管理 模塊中找到與所述操作信息關(guān)聯(lián)的EE對象，通過所述第一通信模塊將相應(yīng)的 管理命令發(fā)送給與所述EE對象對應(yīng)的EEM實體。
7、 如權(quán)利要求4所述的平臺管理PLM子系統(tǒng)，其特征在于，所述第一通 信模塊，進一步用于接收來自EEM實體的校驗請求，所述校驗請求包含所述 EEM實體對應(yīng)的EE的實際配置信息，并向所述EEM實體返回校驗結(jié)果信息；所述平臺管理PLM子系統(tǒng)進一步包括配置校驗?zāi)K，用于根據(jù)所述校 驗請求，校驗EE的實際配置信息和參照配置信息是否一致，并通過所述第一 通信模塊返回校驗結(jié)果信息。
8、 一種執(zhí)行環(huán)境管理EEM實體，其特征在于，包括監(jiān)控模塊，用于根據(jù)維護的計算資源CR對象信息，監(jiān)控與當(dāng)前EEM實 體對應(yīng)的執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源CR對象，在監(jiān)控到CR對象的狀態(tài)發(fā)生 變化時，通過第二通信模塊發(fā)送相應(yīng)的狀態(tài)變化事件報文；第二通信模塊，用于向平臺管理PLM子系統(tǒng)上報相應(yīng)的狀態(tài)變化事件報 文，所述狀態(tài)變化事件報文包含狀態(tài)變化信息。
9、 如權(quán)利要求8所述的執(zhí)行環(huán)境管理EEM實體，其特征在于，所述第 二通信模塊，進一步用于接收平臺管理PLM子系統(tǒng)下發(fā)的管理命令；所述執(zhí)行環(huán)境管理EEM實體，進一步包括命令解析模塊，用于解釋并執(zhí)行或調(diào)用其他模塊執(zhí)行所述管理命令，通過 所述第二通信模塊向所述PLM子系統(tǒng)返回相應(yīng)的命令執(zhí)行結(jié)果。
10、 如權(quán)利要求9所述的執(zhí)行環(huán)境管理EEM實體，其特征在于，進一步 包括啟動管理模塊，用于進行執(zhí)行環(huán)境啟動管理以及在啟動過程中通過所述第 二通信模塊向所述PLM子系統(tǒng)發(fā)送校-險請求及接收所述PLM子系統(tǒng)返回的 校驗結(jié)果信息，并根據(jù)校驗結(jié)果信息進行處理。
11、 如權(quán)利要求10所述的執(zhí)行環(huán)境管理EEM實體，其特征在于，進一步包括EE適配模塊，用于適配不同的執(zhí)行環(huán)境。
12、 如權(quán)利要求8至11任一項所述的執(zhí)行環(huán)境管理EEM實體，其特征在 于，所述監(jiān)控模塊為第一監(jiān)控模塊，用于根據(jù)維護的計算資源CR對象信息， 監(jiān)控與當(dāng)前EEM實體對應(yīng)的執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源CR對象，在監(jiān)控到 CR對象的狀態(tài)發(fā)生變化時，根據(jù)與該CR對象狀態(tài)變化所匹配的第二處理策 略通過所述第二通信模塊發(fā)送相應(yīng)的狀態(tài)變化事件報文，所述匹配的第二處理 策略為上報處理方式。
13、 如權(quán)利要求12所述的執(zhí)行環(huán)境管理EEM實體，其特征在于，進一 步包括本地修復(fù)模塊，用于進行本地修復(fù)或復(fù)位處理；所述第一監(jiān)控模塊，進一步用于根據(jù)與該CR對象狀態(tài)變化所匹配的第一 處理策略通過所述本地^修復(fù);f莫塊進行^"復(fù)處理，所述匹配的第 一處理策略為本 地》務(wù)復(fù)處理方式。
14、 一種執(zhí)行環(huán)境的管理方法，其特征在于，所述方法包括根據(jù)維護的計算資源CR對象信息，監(jiān)控當(dāng)前執(zhí)行環(huán)境所關(guān)聯(lián)的計算資源 CR對象；當(dāng)監(jiān)控到CR對象的狀態(tài)發(fā)生變化時，向平臺管理子系統(tǒng)PLM上報相應(yīng) 的狀態(tài)變化事件報文，使得所述平臺管理PLM子系統(tǒng)根據(jù)預(yù)設(shè)的第一處理策 略和所述狀態(tài)變化事件報文下發(fā)相應(yīng)的管理命令。
15、 如權(quán)利要求14所述的方法，其特征在于，所述向平臺管理子系統(tǒng)PLM 上報相應(yīng)的狀態(tài)變化事件報文包括獲得與所述CR對象的狀態(tài)變化對應(yīng)的EE狀態(tài)變化信息，向所述平臺管 理子系統(tǒng)上報相應(yīng)的狀態(tài)變化事件報文，所述狀態(tài)變化事件報文包含EE狀態(tài) 變化信息。
16、 如權(quán)利要求14所述的方法，其特征在于，所述向平臺管理子系統(tǒng)PLM 上報相應(yīng)的狀態(tài)變化事件報文的步驟前，進一步包括根據(jù)監(jiān)控到的CR對象的狀態(tài)變化，確定與該CR對象狀態(tài)變化所匹配的 第二處理策略，所述匹配的第二處理策略為上^l艮處理方式；則，所述向平臺管理子系統(tǒng)PLM上報相應(yīng)的狀態(tài)變化事件報文為根據(jù) 所述匹配的上^^處理方式的第二處理策略向平臺管理子系統(tǒng)PLM上報相應(yīng)的 狀態(tài)變化事件報文。
17、 如權(quán)利要求14所述的方法，其特征在于，所述方法進一步包括 執(zhí)行所述平臺管理PLM子系統(tǒng)下發(fā)的管理命令，并返回所述管理命令的執(zhí)行結(jié)果，所述管理命令包括與該狀態(tài)變化事件報文對應(yīng)的管理命令，或由 平臺管理PLM用戶觸發(fā)所述平臺管理PLM子系統(tǒng)所發(fā)出的管理命令。
18、 一種執(zhí)行環(huán)境的管理方法，其特征在于，所述方法包括 接收執(zhí)行環(huán)境管理EEM實體上報的狀態(tài)變化事件報文，該狀態(tài)變化事件報文包含狀態(tài)變化信息；根據(jù)該狀態(tài)變化事件報文中的狀態(tài)變化信息和預(yù)設(shè)的第一處理策略，向該 EEM實體下發(fā)相應(yīng)的管理命令。
19、 如權(quán)利要求18所述的方法，其特征在于，所述根據(jù)該狀態(tài)變化事件 報文中的狀態(tài)變化信息和預(yù)設(shè)的第一處理策略，向該EEM實體下發(fā)相應(yīng)的管 理命令包括根據(jù)該狀態(tài)變化事件報文中的狀態(tài)變化信息，確定與所述狀態(tài)變化事件匹 配的第一處理策略；才艮據(jù)所述匹配的第 一處理策略下發(fā)對應(yīng)的管理命令。
20、 如權(quán)利要求18或19所述的方法，其特征在于，所述管理命令至少包 括鎖定命令、解鎖命令、關(guān)閉命令、啟動命令、重啟命令或修復(fù)命令。
21、 如權(quán)利要求18或19所述的方法，其特征在于，所述方法進一步包括 接收平臺管理用戶發(fā)出的操作信息；根據(jù)該操作信息，向與該操作信息關(guān)聯(lián)的執(zhí)行環(huán)境EE對應(yīng)的EEM實體 下發(fā)相應(yīng)的管理命令。
全文摘要
本發(fā)明實施例公開了一種集群系統(tǒng)，包括平臺管理子系統(tǒng)和至少一個執(zhí)行環(huán)境管理實體，其中，所述執(zhí)行環(huán)境管理實體，用于根據(jù)維護的計算資源CR對象信息，監(jiān)控對應(yīng)的執(zhí)行環(huán)境EE所關(guān)聯(lián)的計算資源CR對象，在監(jiān)控到CR對象的狀態(tài)發(fā)生變化，向所述平臺管理子系統(tǒng)上報相應(yīng)的狀態(tài)變化事件報文；所述平臺管理子系統(tǒng)，用于接收所述執(zhí)行環(huán)境管理實體上報的狀態(tài)變化事件報文，根據(jù)該狀態(tài)變化事件報文中的狀態(tài)變化信息以及預(yù)設(shè)的第一處理策略，向?qū)?yīng)的執(zhí)行環(huán)境管理實體下發(fā)相應(yīng)的管理命令；從而實現(xiàn)PLM能感知當(dāng)前執(zhí)行環(huán)境EE的狀態(tài)變化。
文檔編號H04L12/26GK101677276SQ20081021627
公開日2010年3月24日 申請日期2008年9月16日 優(yōu)先權(quán)日2008年9月16日
發(fā)明者唐冠軍, 真 巢, 鑫 張, 金雪鋒 申請人:華為技術(shù)有限公司