邱子賢,徐月云,王曉偉,3,胡滿江,3,秦洪懋,3
(1.湖南大學(xué) 機(jī)械與運(yùn)載工程學(xué)院,湖南 長沙 410082;2.國汽(北京)智能網(wǎng)聯(lián)汽車研究院有限公司,北京 100176;3.湖南大學(xué) 無錫智能控制研究院,江蘇 無錫 214115)
當(dāng)前,我國露天礦山開采的機(jī)械化程度較高。為減少人力投入,提高作業(yè)安全性和效率,智能化與數(shù)字化發(fā)展已成為露天礦山開采的一種趨勢。云服務(wù)技術(shù)是信息化時代的主要管理方式,已成為企業(yè)信息集成、信息資源開發(fā)和決策支持系統(tǒng)建立的最佳解決方案。利用云服務(wù)平臺整合礦山資源已然成為一種新模式[1],其中露天礦山智能調(diào)度管理系統(tǒng)[2-3]就是基于云應(yīng)用技術(shù)背景所建立的;然而由于結(jié)構(gòu)的復(fù)雜性和部署方式的多樣性,其可靠性指標(biāo)[4-6]難以被獲得。可靠性是保證系統(tǒng)正常運(yùn)行的重要指標(biāo),在露天礦山自動駕駛場景中,調(diào)度系統(tǒng)的不可靠可能會導(dǎo)致其獲取不到無人礦用卡車(簡稱“礦卡”)的實(shí)時工作狀態(tài)信息,同時無人礦卡也可能無法收到調(diào)度指令,這將會嚴(yán)重影響作業(yè)效率。
與可靠性改進(jìn)相關(guān)的研究有很多。文獻(xiàn)[7]提出了基于任務(wù)復(fù)制的高可靠性調(diào)度(HRSA)算法和基于多任務(wù)復(fù)制的多有向無環(huán)圖(direct acyclic graph,DAG)任務(wù)高可靠性調(diào)度(HRSAMD)算法,通過主動復(fù)制的方式,將任務(wù)及其多個備份任務(wù)公平地映射到多個處理機(jī)上,從而提高執(zhí)行過程的可靠性。文獻(xiàn)[8]針對多DAG可靠性調(diào)度問題,提出了一種考慮虛擬機(jī)之間鏈路通信競爭的動態(tài)多DAG分層調(diào)度算法,解決了當(dāng)多個DAG中任務(wù)的權(quán)值相差較大時之前到達(dá)的DAG因剩余任務(wù)遲遲得不到調(diào)度而導(dǎo)致執(zhí)行時間跨度增大的問題。文獻(xiàn)[9]在給定DAG節(jié)點(diǎn)分配給處理器的條件下,分別提出了齊次系統(tǒng)和異構(gòu)系統(tǒng)的能量最優(yōu)分配(OEA)方法和基于搜索的OEA(SOEA)方法,可以在滿足可靠性要求的情況下,使能耗最小化。以上傳統(tǒng)DAG調(diào)度雖然在一定程度上能提升任務(wù)可靠性,但對處理機(jī)的描述和研究較為抽象。
本文對露天礦山智能調(diào)度管理系統(tǒng)(簡稱“智能調(diào)度系統(tǒng)”)進(jìn)行了深入研究,通過分析系統(tǒng)架構(gòu),將其部署棧建模為考慮相對全面的組件及其依賴關(guān)系的分層依賴關(guān)系圖,并通過蒙特卡羅方法[5]對各個組件進(jìn)行仿真,最終根據(jù)分層依賴關(guān)系圖,確定調(diào)度系統(tǒng)的狀態(tài)及其接近真實(shí)狀態(tài)下的可靠性。同時,為獲得調(diào)度系統(tǒng)的最佳可靠性,本文提出一種露天礦山智能調(diào)度系統(tǒng)可靠性高效評估方法,深入研究了服務(wù)實(shí)例部署方式對系統(tǒng)可靠性的影響,并提出了一種逐步遍歷算法以獲取最佳的服務(wù)實(shí)例部署方式。
由于露天礦山智能調(diào)度管理技術(shù)與傳統(tǒng)云應(yīng)用技術(shù)具有相似之處,因此露天礦山智能調(diào)度系統(tǒng)模型的研究可以基于云應(yīng)用的研究而開展。
在云上部署應(yīng)用程序時,使用者通常將應(yīng)用程序劃分為多個子模塊,每個子模塊代表一個微服務(wù)。在容錯方面,一個微服務(wù)通常部署多個服務(wù)實(shí)例(service instance,SI),根據(jù)不同的容錯需求來確定需部署的服務(wù)實(shí)例數(shù)量。服務(wù)實(shí)例由虛擬機(jī)(virtual machine,VM)或容器(Container)所承載。容器既可被部署在虛擬機(jī)中,也可被直接部署在物理服務(wù)器(physical server,PS)上;同時虛擬機(jī)也可被直接部署在物理服務(wù)器上。根據(jù)所執(zhí)行功能的性質(zhì),虛擬機(jī)或容器可被部署在位于不同地理位置的物理服務(wù)器上。例如,在私有云中,部署包含用戶隱私信息的容器或虛擬機(jī);在公有云中,部署包含對處理可靠性要求較高的任務(wù)的容器或虛擬機(jī)。如圖1所示,服務(wù)、容器、虛擬機(jī)和物理服務(wù)器是構(gòu)成云應(yīng)用程序分層部署棧的主要組件。
圖1 混合云應(yīng)用的分層部署棧Fig.1 Layered deployment stack of hybrid-cloud applications
值得注意的是,組件和組件之間存在依賴關(guān)系。本文將依賴關(guān)系定義為一個組件需要另一個組件來完成其自身功能的關(guān)系。例如,如果一個服務(wù)需要根據(jù)另一個服務(wù)的計(jì)算結(jié)果來完成任務(wù),則認(rèn)為前者依賴于后者。同樣,虛擬機(jī)的正常運(yùn)行需要物理服務(wù)器的正常運(yùn)行,所以虛擬機(jī)組件依賴于物理服務(wù)器組件,容器與承載它們的虛擬機(jī)和物理服務(wù)器之間也存在依賴關(guān)系。
本文將一個應(yīng)用程序劃分成若干微服務(wù),并用實(shí)線箭頭表示2個服務(wù)之間的依賴關(guān)系。圖2展示了一個應(yīng)用示例。圖中,S0~S6代表服務(wù),其中S0依賴于S1、S2和S3,且S4和S5都依賴于S6。
圖2 應(yīng)用程序和子服務(wù)的實(shí)例Fig.2 An instance of application program and sub-services
S5的狀態(tài)由其本身的狀態(tài)和S6的狀態(tài)共同決定,即S5=S5ΛS6;相似地,該應(yīng)用程序的狀態(tài)由所有子服務(wù)的狀態(tài)共同決定。因此,該應(yīng)用程序的狀態(tài)(Sapp)可表示為
本文使用分層依賴關(guān)系圖(layered dependency graph,LDG)[10]對部署棧建模,并通過添加容器作為新組件對其進(jìn)行改進(jìn)。如圖3所示,LDG自上而下包含4層,即服務(wù)層、容器層、VM層和PS層,其中PS包括公有云、私有云和邊緣云中的服務(wù)器。假設(shè)每個PS可以同時承載多個VM和多個容器,則每個VM可以托管多個服務(wù)或容器,而每個容器只能托管一個服務(wù)。根據(jù)4層依賴關(guān)系,LDG可被定義為DAG G(V,E)。其中,V代表組件集合,V={v1,v2,v3,…,va},a代表節(jié)點(diǎn)數(shù);E代表組件間的依賴關(guān)系集合,E={e1,e2,e3,…,eb},b為邊數(shù)。
圖3 4層依賴關(guān)系圖Fig.3 LDG of four layers
圖3中,任意一個組件可以被定義為一個節(jié)點(diǎn)v(t,m,k,n)。其中,t為節(jié)點(diǎn)類型,其可以是物理服務(wù)器、虛擬機(jī)、容器、服務(wù);m為組件的名稱;k和n代表一個微服務(wù)擁有n個服務(wù)實(shí)例,并且該微服務(wù)至少需要k個服務(wù)實(shí)例才能成功,可表示為“k-out-of-n”。圖中,任意一種依賴關(guān)系可以被定義為一條邊e(p,s,d,w),其中p和s分別代表頭和尾,d代表類型,w代表所依賴的權(quán)重。類型d可以是“k-out-of-n”,表示一個微服務(wù)與其服務(wù)實(shí)例間的依賴關(guān)系,或者是“normal”,表示其他類型的依賴關(guān)系。本文假設(shè)權(quán)重w為1,這意味著如果一個組件發(fā)生故障,則依賴于該組件的其他組件也會出現(xiàn)故障。
露天礦山作業(yè)是通過大量、多類型的工程車輛實(shí)時配合完成的[11],如無人礦卡時常需要與有人駕駛的挖掘機(jī)配合作業(yè)。為保障生產(chǎn)效率,無人礦卡需要與云平臺上的調(diào)度系統(tǒng)進(jìn)行實(shí)時的數(shù)據(jù)接收和發(fā)送,調(diào)度系統(tǒng)可依此對無人礦卡進(jìn)行實(shí)時監(jiān)控和故障診斷;在對關(guān)鍵數(shù)據(jù)進(jìn)行實(shí)時流計(jì)算[12]后,將計(jì)算結(jié)果存儲到時序數(shù)據(jù)庫與關(guān)系型數(shù)據(jù)庫中。同時,調(diào)度系統(tǒng)還負(fù)責(zé)露天礦山地圖的管理,并依據(jù)高精度地圖和礦上實(shí)時作業(yè)情況對無人礦卡進(jìn)行調(diào)度管理與運(yùn)營管理。圖4示出露天礦山智能調(diào)度管理系統(tǒng)的架構(gòu)。
圖4 露天礦山智能調(diào)度管理系統(tǒng)架構(gòu)Fig.4 Architecture of the mine intelligent dispatching system
如上所述,每個微服務(wù)都有多個服務(wù)實(shí)例,并且有容錯需求“k-out-of-n”。如圖5所示,數(shù)據(jù)收發(fā)、監(jiān)控和故障診斷、地圖管理、作業(yè)調(diào)度、運(yùn)營管理、實(shí)時流計(jì)算均具有多個部署在不同容器的服務(wù)實(shí)例;而容器又被部署在虛擬機(jī)中。因此,為了避免單點(diǎn)故障,讓隸屬于同一個服務(wù)的容器散布在不同的虛擬機(jī)中,這有利于提升系統(tǒng)的可靠性。然而,隨著技術(shù)的發(fā)展,如今的容器編排技術(shù)已能滿足虛擬機(jī)負(fù)載均衡的要求,因此不用再考慮單點(diǎn)故障和虛擬機(jī)負(fù)載不均對系統(tǒng)可靠性的影響。同時,對服務(wù)實(shí)例被直接部署在虛擬機(jī)中的時序數(shù)據(jù)庫服務(wù)和關(guān)系型數(shù)據(jù)庫服務(wù)而言,同樣可以應(yīng)用類似的編排技術(shù),使得隸屬于同一服務(wù)的實(shí)例得到合理的散布。
圖5 露天礦山智能調(diào)度管理系統(tǒng)組件結(jié)構(gòu)-公有云Fig.5 Component structure of the mine intelligent dispatching system with public cloud
此外,本文還考慮了3種物理服務(wù)器的選擇。由于公有云具有可靠性高且價格低廉的優(yōu)點(diǎn),圖5所示組件結(jié)構(gòu)將所有虛擬機(jī)均部署在公有云中;而私有云的安全性高,圖6所示組件結(jié)構(gòu)將所有虛擬機(jī)都部署在私有云中,同時本文假設(shè)一個私有云物理服務(wù)器中最多部署2個虛擬機(jī);圖7將數(shù)據(jù)庫這類安全性要求較高的服務(wù)部署在私有云中,而將其他服務(wù)部署在公有云中來獲取較高的可靠性。
圖6 露天礦山智能調(diào)度管理系統(tǒng)組件結(jié)構(gòu)-私有云Fig.6 Component structure of the mine intelligent dispatching system with private clouds
圖7 露天礦山智能調(diào)度管理系統(tǒng)組件結(jié)構(gòu)-混合云Fig.7 Component structure of the mine intelligent dispatching system with hybrid clouds
在設(shè)計(jì)蒙特卡羅仿真(Monte Carlo simulation,MCS)時,必須考慮2個主要規(guī)則:輸入規(guī)則和停止規(guī)則。本文根據(jù)組件的故障分布來設(shè)計(jì)輸入,并且根據(jù)可變精度要求來設(shè)計(jì)停止規(guī)則。
在進(jìn)行仿真之前,本文必須確定獲取各類型部件初始可靠性的方法。
根據(jù)組件的歷史故障信息,可以分析得到單位時間內(nèi)的故障率λ和可靠性r,其中取單位時間為一天。例如,如果一個組件平均每天發(fā)生a次故障,那么其單位時間的故障率λ=a。本文假設(shè)非服務(wù)組件(物理服務(wù)器、虛擬機(jī)、容器)的故障率λ為常數(shù),則可以用指數(shù)可靠性模型計(jì)算非服務(wù)組件的可靠度r,即r=e-λt,其中t代表時間。如果考慮一個單位時間,即t=1,則組件的可靠性為e-λ;相應(yīng)地,該組件處于故障狀態(tài)的概率為(1-e-λ)。
不同類型組件的失敗率并不完全相同:一個軟件組件的故障率可通過分析其在一段時間內(nèi)的運(yùn)行日志中的單位時間故障次數(shù)得到,其中軟件組件是指除了PS組件的其他組件。對于硬件組件,除了分析其運(yùn)行日志外,還可以根據(jù)其理論MTTF(修復(fù)前平均時間,用tMTTF表示)計(jì)算故障率,即
在仿真過程中,當(dāng)故障率已經(jīng)給定時,可以根據(jù)r=e-λt確定單位時間后的組件狀態(tài)。本文假設(shè)經(jīng)過單位時間后的組件狀態(tài)為正常(用1表示)或者故障(用0表示),并且處于每個狀態(tài)的概率分別等于r和(1-r),則對于每個單位時間,可以隨機(jī)抽取一個(0,1]間的小數(shù)并且通過式(2)確定組件的狀態(tài)Si:
式中:di——第i個組件的可靠度;λi——單位時間第i個組件的故障率。
在獲得每個組件的仿真狀態(tài)后,可以根據(jù)DAG模型中每個組件的狀態(tài)來確定調(diào)度系統(tǒng)的狀態(tài)。從下到上,如果一個PS組件處于故障狀態(tài),則該組件上的所有VM組件也都處于故障狀態(tài);當(dāng)一個VM組件處于故障狀態(tài)時,則該VM組件上的所有容器組件或SI組件也都處于故障狀態(tài);當(dāng)一個容器組件處于故障狀態(tài)時,則部署在該容器上的SI組件也處于故障狀態(tài)。此外,每個微服務(wù)的狀態(tài)是根據(jù)它所依賴的SI組件而確定的。具體來說,每個微服務(wù)對應(yīng)一個容錯需求,表示為k-out-of-n,即一個微服務(wù)有n個服務(wù)實(shí)例,且需要至少k個服務(wù)實(shí)例處于正常狀態(tài),才能保障微服務(wù)處于正常狀態(tài);否則將會處于故障狀態(tài)。
對于第j個微服務(wù),本文將其容錯需求表示為kjout-of-nj,并將其狀態(tài)表示為Sj,Sj∈{0,1}。假設(shè)正常的服務(wù)實(shí)例個數(shù)為gj,則:
在確定每個服務(wù)的狀態(tài)之后,可以根據(jù)服務(wù)之間的依賴關(guān)系確定應(yīng)用程序的狀態(tài)。以圖2為例,根據(jù)式(1),在任意一輪仿真中,如果有任何服務(wù)處于故障狀態(tài),則應(yīng)用處于失敗狀態(tài);如果所有服務(wù)都處于成功狀態(tài),則應(yīng)用處于成功狀態(tài)。
取一個單位時間作為一輪仿真的時間并進(jìn)行n輪MCS仿真,則調(diào)度系統(tǒng)的仿真可靠度-----Rsim等于所有輪仿真可靠度的平均值為
式中:n——總輪數(shù);i——輪數(shù),i=2,3,…,n;Rsimi——應(yīng)用程序第i輪仿真的狀態(tài),且該狀態(tài)只能為0或1。
輪數(shù)由MCS的停止規(guī)則決定。本文定義了停止MCS的3個條件:置信區(qū)間、小數(shù)點(diǎn)后的有效數(shù)字位數(shù)和最小失效次數(shù)。當(dāng)仿真結(jié)果同時滿足這3個約束條件時,仿真結(jié)束。
2.2.1 置信區(qū)間
置信區(qū)間約束保證了仿真結(jié)果的可信度。正如文獻(xiàn)[11]中所提到的,對于置信水平α,-----Rsim的置信區(qū)間應(yīng)滿足以下條件:
式中:s——仿真結(jié)果的標(biāo)準(zhǔn)差,s=;Rreal——應(yīng)用程序的真實(shí)可靠度;?——標(biāo)準(zhǔn)正態(tài)分布累積分布函數(shù)(CDF)。
為了減少計(jì)算量,本文定義[13]:
依據(jù)式(8),每一輪仿真后,s值均被更新,避免了的重復(fù)計(jì)算。
2.2.2 有效數(shù)字位數(shù)
有效位數(shù)的限制保證了仿真結(jié)果的準(zhǔn)確性。本文將模擬結(jié)果的小數(shù)點(diǎn)后的有效位數(shù)用β表示。對于n輪MCS,β應(yīng)該滿足如下要求:
2.2.3 最小失效次數(shù)
最小失效次數(shù)約束保證了仿真結(jié)果的有效性。一些高可靠性的硬件和軟件,其單位時間可靠度可能達(dá)到99.999%,此時的值非常小,使得模擬結(jié)果在幾輪后就滿足了第一和第二約束要求,而這卻與MCS使用大量隨機(jī)實(shí)驗(yàn)來近似真實(shí)概率的基本思想相違背。
本文用F表示應(yīng)用程序失敗次數(shù)的約束。F可以是一個經(jīng)驗(yàn)值,每一輪模擬根據(jù)應(yīng)用的狀態(tài)更新累積失敗次數(shù)f。在模擬結(jié)束時,f需要不小于F,即f≥F。
結(jié)合以上3個約束條件同時滿足式(10)要求時,MCS停止。式(10)中,α為置信水平,α,β和F可以根據(jù)特定的精度要求進(jìn)行調(diào)整。
基于輸入規(guī)則和停止規(guī)則,本文提出了一種MCS算法,如算法1(表1)所示,其用于在一個單位時間內(nèi)模擬應(yīng)用的可靠性。應(yīng)用程序狀態(tài)的模擬步驟如下:
表1 算法1Tab.1 Algorithm 1
(1)非服務(wù)組件的狀態(tài)是根據(jù)它們的可靠性和依賴關(guān)系來確定的。例如,當(dāng)一個PS故障時,該P(yáng)S上的所有VM也會故障。
(2)根據(jù)成功服務(wù)實(shí)例的數(shù)量來確定微服務(wù)狀態(tài),根據(jù)微服務(wù)狀態(tài)來確定應(yīng)用程序狀態(tài)。
由于不同服務(wù)具有不同的復(fù)雜程度和重要性,不同服務(wù)的容錯需求也并不完全相同。例如,當(dāng)露天礦山中需要調(diào)度的無人礦卡數(shù)量較多或作業(yè)情況較復(fù)雜時,作業(yè)調(diào)度服務(wù)則需要更多的資源,故滿足作業(yè)調(diào)度服務(wù)需求的最低服務(wù)實(shí)例個數(shù)k應(yīng)比其他服務(wù)需求的最低服務(wù)實(shí)例個數(shù)k'要高。同理,關(guān)系型數(shù)據(jù)庫作為存儲無人礦卡運(yùn)行日志文件以及其他關(guān)鍵數(shù)據(jù)的重要服務(wù),其要求的k值也應(yīng)較高。因此,本文采取一種逐步遍歷算法來找尋最佳的服務(wù)實(shí)例部署方式,如算法2(表2)所示。在分配給每一個服務(wù)所需的最低實(shí)例數(shù)量后,從剩余的服務(wù)實(shí)例集合中,每次取出一個服務(wù)實(shí)例就嘗試將其部署在每一個服務(wù)上;通過MCS算法探尋使得系統(tǒng)可靠性獲得最大增量時這一實(shí)例所部署的位置,并將這一位置確定為該實(shí)例的最終部署位置;然后,逐個將剩余的服務(wù)實(shí)例依次按照該方案部署完畢。
表2 算法2Tab.2 Algorithm 2
本文使用的仿真軟件是在Java(JDK 1.8和IntelliJ IDEA 2021.2.3)中實(shí)現(xiàn)的,并運(yùn)行在帶有64位版本的Windows 10、Intel Core i7@2.80 GHz和8 GB RAM的筆記本電腦上。
本文提出了兩種對比方法來驗(yàn)證上述服務(wù)實(shí)例部署方法:
(1)隨機(jī)部署方式。為保證該對比方法的參考價值,應(yīng)在保證所有服務(wù)都被分配了其需要的最少服務(wù)實(shí)例的前提下,將剩余服務(wù)實(shí)例隨機(jī)分配給各個服務(wù);并且取10次隨機(jī)結(jié)果的平均值代表該方式獲取的可靠性。
(2)均布部署方式。其將所有服務(wù)實(shí)例均勻分配給各個服務(wù)。由于本文設(shè)定的作業(yè)調(diào)度服務(wù)最小需求實(shí)例數(shù)量為5,總服務(wù)數(shù)量為8,故均布部署方式將從總服務(wù)實(shí)例為40起進(jìn)行實(shí)驗(yàn),而其他兩種方法將從最小需求服務(wù)實(shí)例總數(shù)的1.5倍起開始實(shí)驗(yàn)。
實(shí)驗(yàn)參數(shù)根據(jù)分析組件運(yùn)行日志以及經(jīng)驗(yàn)設(shè)置。由于公有云的特性,可以將其可靠性設(shè)為1。容器和虛擬機(jī)的失效率設(shè)置為0.005。停止規(guī)則方面,本文將置信水平α設(shè)為0.99,小數(shù)點(diǎn)后有效位數(shù)β設(shè)為4。對于最小失效次數(shù)約束,設(shè)置其為100,即可確保MCS仿真不會過早結(jié)束。根據(jù)前文所討論的,本文設(shè)定數(shù)據(jù)收發(fā)、監(jiān)控與故障管理、地圖管理、作業(yè)調(diào)度、運(yùn)營管理、實(shí)時流計(jì)算、關(guān)系型數(shù)據(jù)庫、時序數(shù)據(jù)庫的最少服務(wù)實(shí)例數(shù)量需求分別為2、2、2、5、2、2、3、2。總服務(wù)實(shí)例數(shù)量由最少服務(wù)實(shí)例總需求的1.5倍起開始設(shè)定,虛擬機(jī)數(shù)量設(shè)為8。
圖8~圖10分別示出3種云系統(tǒng)下露天礦山智能調(diào)度管理系統(tǒng)經(jīng)過3種不同方式的服務(wù)實(shí)例部署后的單位時間可靠性。可以觀察到,遍歷部署方式整體優(yōu)于隨機(jī)和均布部署方式。以公有云作為物理服務(wù)器的調(diào)度系統(tǒng)為例,其經(jīng)過遍歷部署后,在總服務(wù)實(shí)例為40時,就可以獲得99.99%以上的可靠度;而隨機(jī)部署方式需要總服務(wù)實(shí)例達(dá)到47時,才能達(dá)到99.99%以上的可靠性;并且在總資源較少時,遍歷部署的調(diào)度系統(tǒng)最多可比隨機(jī)部署的調(diào)度系統(tǒng)高出3.87%的可靠性數(shù)值。
圖8 公有云系統(tǒng)不同總服務(wù)實(shí)例下可靠性Fig.8 Reliability of public cloud system under different total SIs
圖9 私有云系統(tǒng)不同總服務(wù)實(shí)例下可靠性Fig.9 Reliability of private cloud system under different total SIs
圖10 混合云系統(tǒng)不同總服務(wù)實(shí)例下可靠性Fig.10 Reliability of hybrid clouds system under different total SIs
作業(yè)調(diào)度服務(wù)的最少服務(wù)實(shí)例需求量為5;為保證均布部署方式的有效性,均布部署實(shí)驗(yàn)從總服務(wù)實(shí)例為40開始。然而,相比前面兩種部署方式,均布部署方式的表現(xiàn)最差,這是因?yàn)椴煌?wù)的最少服務(wù)實(shí)例需求不一樣,盲目均勻分配忽視了不同服務(wù)的不同需求,導(dǎo)致系統(tǒng)總體可靠性不高。
不難發(fā)現(xiàn),以公有云、私有云、混合云作為物理服務(wù)器的調(diào)度系統(tǒng)在單位時間內(nèi)的可靠性差距都不大。因此,本文考慮對不同時間下3種云系統(tǒng)的可靠性進(jìn)行研究。圖11展示了遍歷部署方式下3種云系統(tǒng)在不同天數(shù)內(nèi)的可靠性數(shù)值??梢钥闯?,在任意天數(shù)下,公有云系統(tǒng)可靠性最高,而混合云系統(tǒng)可靠性其次,私有云系統(tǒng)可靠性最低,這一結(jié)果符合客觀事實(shí);而且,隨著時間的推移,三者的可靠性都逐漸降低,且三者之間的差距越來越大,以15天內(nèi)的可靠性為例,公有云系統(tǒng)的比混合云系統(tǒng)的以及私有云系統(tǒng)的分別高出1.65%和3.18%。
圖11 不同天數(shù)下各類云系統(tǒng)的可靠性Fig.11 Reliability of various cloud systems in different days
本文提出了一種用于評估露天礦山智能調(diào)度管理系統(tǒng)可靠性的MCS算法。其考慮硬件和軟件故障,通過使用基于調(diào)度系統(tǒng)部署棧中的組件圖和依賴關(guān)系對調(diào)度系統(tǒng)進(jìn)行建模;并且在LDG模型的基礎(chǔ)上,設(shè)計(jì)了輸入規(guī)則和停止規(guī)則。同時,通過利用該算法的評估結(jié)果,提出了一種尋求最優(yōu)服務(wù)實(shí)例部署方式的逐步遍歷算法。實(shí)驗(yàn)結(jié)果表明,用該MCS算法可以有效地評估出具有一定精度的調(diào)度系統(tǒng)可靠性,并且通過逐步遍歷算法獲得的服務(wù)實(shí)例部署方式,可以顯著提升系統(tǒng)可靠性。
本文提出的方法主要針對在確定云服務(wù)器以及確定調(diào)度系統(tǒng)組件結(jié)構(gòu)的條件下的可靠性評估以及提升方法。未來,可以考慮更加多樣的組件結(jié)構(gòu)以及搜索范圍更廣的進(jìn)化算法來探尋調(diào)度系統(tǒng)的最佳全局部署策略。