呂曉華,王 諾*,崔建弘,范家熠

(1. 河北工程技術(shù)學(xué)院人工智能與大數(shù)據(jù)學(xué)院,河北 石家莊 050000;2. 江蘇科技大學(xué)蘇州理工學(xué)院,江蘇 張家港 215600)

1 引言

分析軟件配置可以明確該系統(tǒng)的綁定服務(wù)器端口、應(yīng)用算法以及數(shù)據(jù)存儲位置等信息,但由于涉及參數(shù)巨大,不完全滿足要求的配置結(jié)構(gòu),會影響系統(tǒng)正常運(yùn)行、無法執(zhí)行對應(yīng)功能,降低了其可靠性,具體表現(xiàn)如下:配置錯誤是服務(wù)失效、系統(tǒng)異常的主要原因之一,經(jīng)相關(guān)調(diào)查表明50%以上的系統(tǒng)故障是由配置錯誤導(dǎo)致的。配置錯誤所造成的后果也較為嚴(yán)重,直接影響的系統(tǒng)的服務(wù)水平,給開發(fā)商帶來口碑下降、經(jīng)濟(jì)損失等負(fù)面影響。

現(xiàn)階段關(guān)于軟件可靠性的研究有很多,羅玲[1]提出一種采用隨機(jī)Petri網(wǎng)的嵌入式機(jī)載軟件可靠性檢測。該方法采用Petri網(wǎng)對軟件系統(tǒng)建模,獲得判定準(zhǔn)則與檢測策略,隨后再次通過Petri網(wǎng)對系統(tǒng)是否存在設(shè)計缺陷進(jìn)行仿真驗證,結(jié)果表明方法是有效可行的,但多次使用Petri網(wǎng),對其建模要求較高,面對多功能配置系統(tǒng)時,診斷效率和精度不穩(wěn)定,受軟件復(fù)雜程度影響較大;除此之外,還有學(xué)者提出了一種基于代碼路徑的嵌入式軟件可靠度評估方法,采用代碼分析法結(jié)合已有的軟件檢測數(shù)據(jù)驗證原始評估模型,根據(jù)驗證結(jié)果完善對應(yīng)缺陷,給出提高可靠性方案,實驗表明該方法在完善階段可能出現(xiàn)誤差,導(dǎo)致最終評估結(jié)果準(zhǔn)確性低,可操作性和適用性差。

基于此,本文面向保障系統(tǒng)的可靠性,給出一種基于軟件間關(guān)聯(lián)關(guān)系的配置錯誤診斷方法?？偨Y(jié)軟件組件各配置間的關(guān)聯(lián)關(guān)系,根據(jù)推導(dǎo)出的錯誤診斷規(guī)則,對錯誤源進(jìn)行判斷。實驗表明所提方法的診斷精度高,具有可應(yīng)用于實際的價值。

2 軟件配置項類型匹配

設(shè)軟件的組件模塊為M1,M2,M3,…Mn,可靠性可以表示為R1,R2,R3,…Rn,若通過所有模塊匯合來完成系統(tǒng)的一個任務(wù)[2],則其可靠性又可以描述為min{R1,R2,R3,…Rn}。如果一個N模表決系統(tǒng)能夠糾正?(N-1)/2」個錯誤,軟件配置中的每個模塊可靠性是R,那么此時系統(tǒng)的可靠性可以表示為

(1)

RTMR(t)=3{R(t)·R(t)[1-R(t)]}+R(t)·R(t)·R(t)=3R2(t)-2R3(t)=3e-2λt-2e-3λt

(2)

式中,λ表示軟件失效率;t表示軟件運(yùn)行時間,令RTMR(t)>R(t)則有

3e-2λt-2e-3λt>e-λt

(3)

為簡化計算,令e-λt=K,則有

3K2-2K3=K0.5

(4)

通過式(2)、式(3)、式(4)可得,軟件組件的可靠性要高于0.5,系統(tǒng)才能正常運(yùn)行。設(shè)加入數(shù)據(jù)指令后,同時考慮容錯條件的系統(tǒng)可靠性為R′(t),不考慮容錯條件的可靠性為R″(t),則原系統(tǒng)R′(t)、R(t)的比值r以及R″(t)和R′(t)之間的比值關(guān)系分別為:

(5)

式中,u表示錯誤率,通過上文可得,現(xiàn)有系統(tǒng)的可靠性要高于原有系統(tǒng),則有

(6)

由此可得,軟件配置采用不同結(jié)構(gòu)、不同連接方式相連所得的軟件系統(tǒng)可靠性具有一定的差異[4],因此需要分析系統(tǒng)軟件中各配置間的關(guān)聯(lián)性,才能更好地完成配置錯誤的診斷。

通常配置間的關(guān)聯(lián)主要表現(xiàn)在配置項類型的一致上,因此要想理清軟件配置之間的關(guān)系,首先要明確匹配配置項類型,當(dāng)配置項值完全被匹配時,就可以初步判定該配置的類型,憑借相關(guān)指令完成匹配準(zhǔn)確性的驗證。例如檢測到的配置項值為"/var /www/abc"時,將其初步定義為“路徑”,通過分析器調(diào)用路徑類型指令,確認(rèn)該路徑是否存在,檢測出該路徑是絕對路徑還是相對路徑,根據(jù)檢測結(jié)果再次將該路徑分類為絕對路徑或相對路徑。但是某些類型的軟件配置不能夠直接驗證[5],需要根據(jù)大量配置樣本內(nèi)容進(jìn)行訓(xùn)練,并利用分類器確認(rèn)該配置的最終類型。

確定系統(tǒng)中的每個配置類型后,就可以初步通過其所屬類型進(jìn)行關(guān)系關(guān)聯(lián),針對字符串、數(shù)值等通用配置類型關(guān)系可以使用關(guān)聯(lián)算法進(jìn)一步訓(xùn)練生成[6]。具體方法如下:以MySQL監(jiān)聽地址舉例,首先通過系統(tǒng)日志進(jìn)行類型匹配,匹配完成后由MySQL配置監(jiān)聽已被判定的IP網(wǎng)址,此時兩個配置的中間數(shù)據(jù)庫地址以及網(wǎng)絡(luò)接口地址,也會被判定為IP地址,那么識別出的各個地址類型配置項之間就產(chǎn)生了關(guān)聯(lián),相應(yīng)的關(guān)聯(lián)規(guī)則也會就此產(chǎn)生。

3 診斷規(guī)則生成

配置間的關(guān)聯(lián)關(guān)系生成后,可獲得相應(yīng)的診斷規(guī)則。系統(tǒng)中各軟件的實際應(yīng)用環(huán)境與其具體功能密切相關(guān),僅僅依靠數(shù)據(jù)挖掘生成診斷規(guī)則的效率較低[7],在數(shù)據(jù)量較大的系統(tǒng)中不可行。因此本文結(jié)合系統(tǒng)的實際運(yùn)維經(jīng)驗以及各配置之間的關(guān)聯(lián)關(guān)系,給出了診斷規(guī)則,依然以MySQL配置為例,給出其規(guī)則生成模板為[〈組件〉-〈路徑〉]grant[〈組件〉-〈用戶名〉],尖括號中的部分表示占位符。規(guī)則在產(chǎn)生的過程中首先會枚舉所有組件及配置項,例如通過模板給出MySQL配置的一條相關(guān)規(guī)則如下:MySQL-datadir grant CenTOS-MySQL,表示CenTOS賬戶的MySQL需具備訪問MySQL的datadir權(quán)限,其余診斷規(guī)則模板如表1所示。

表1 診斷規(guī)則生成模板

結(jié)合各配置之間的關(guān)聯(lián)關(guān)系,給定診斷規(guī)則生成模板,用戶也可以根據(jù)系統(tǒng)的實際情況自定義刪除或添加模板。針對所有模板系統(tǒng)會根據(jù)全部需要匹配的占位符自動進(jìn)行數(shù)據(jù)填充,生成初始規(guī)則。生成后的初始規(guī)則中可能摻雜了部分垃圾規(guī)則[8],因此還需要進(jìn)行一次初始規(guī)則篩選,刪除無意義的垃圾規(guī)則。

4 軟件配置錯誤診斷實現(xiàn)

首先給出2點(diǎn)錯誤源假設(shè)如下:

假設(shè)1:節(jié)點(diǎn)狀態(tài)錯誤,根據(jù)診斷規(guī)則可以得出該錯誤主要體現(xiàn)在兩個方面分別為:各路徑對應(yīng)的輸入關(guān)系流判斷錯誤,任務(wù)執(zhí)行時出現(xiàn)不合理現(xiàn)象。

假設(shè)2:輸入數(shù)據(jù)存在錯誤,因此根據(jù)診斷規(guī)則可以得出不論系統(tǒng)各個節(jié)點(diǎn)的狀態(tài)是否正常,錯誤關(guān)系都會傳遞到輸出關(guān)系流。

根據(jù)以上假設(shè)得出如下公理:

公理:若某節(jié)點(diǎn)的所有輸出關(guān)系均為正確的,則可認(rèn)定該節(jié)點(diǎn)沒有錯誤,如果某節(jié)點(diǎn)的輸出關(guān)系流存在錯誤,則認(rèn)為該節(jié)點(diǎn)中存在錯誤。

定理:假設(shè)(v1,v2,…,vm-1,vm)表示系統(tǒng)對應(yīng)有向圖的通路,如果輸出數(shù)據(jù)不存在錯誤,則該條通路中沒有錯誤源,如果vm的輸出數(shù)據(jù)有錯誤,則其中至少有一個錯誤源vi。

證明:如果vm的輸出關(guān)系沒有錯誤,則根據(jù)公理可知vm不存在錯誤,vm的輸入關(guān)系流也是不能存在錯誤的,也就是說vm前一節(jié)點(diǎn)的輸出關(guān)系流也沒有錯誤,則通道(v1,v2,…,vm-1,vm)中沒有錯誤。

根據(jù)以上定理總結(jié)出以下兩點(diǎn)錯誤:

1)若vm的輸入數(shù)據(jù)沒有錯誤,則該節(jié)點(diǎn)的前一節(jié)點(diǎn)vm-1輸出是沒有錯誤的,從而可以進(jìn)一步確定該節(jié)點(diǎn)的初始輸入規(guī)則到vm-1節(jié)點(diǎn)之間的通路中沒有錯誤。也就可以得出,若vm存在錯誤,則實施任務(wù)時在該節(jié)點(diǎn)存在不合理行為,是唯一導(dǎo)致該點(diǎn)輸出錯誤的錯誤源。

2)若vm輸入規(guī)則為錯誤的,則該節(jié)點(diǎn)的前一節(jié)點(diǎn)vm-1的輸出規(guī)則也是錯誤的,以此類推往前搜索,直至發(fā)現(xiàn)某一節(jié)點(diǎn)vi的輸入規(guī)則是無錯誤的,則可以判定從初始節(jié)點(diǎn)到該節(jié)點(diǎn)通路上的輸入規(guī)則是正確的,而vi的錯誤沿著通路傳輸至vm,導(dǎo)致vm的輸出規(guī)則出現(xiàn)錯誤。

若任意節(jié)點(diǎn)vk的執(zhí)行主體發(fā)現(xiàn)前一節(jié)點(diǎn)的輸入關(guān)系有錯誤,則根據(jù)診斷規(guī)則可知該任務(wù)的前一節(jié)點(diǎn)輸出關(guān)系流發(fā)生錯誤,此時軟件的運(yùn)行就會出現(xiàn)故障,需要對該故障進(jìn)行定位和診斷,具體步驟如下:

步驟1:確定從原始節(jié)點(diǎn)到vk-1之間的通路為(v1,v2,…,vk-1),令檢查節(jié)點(diǎn)為vk-i。

步驟2:根據(jù)診斷規(guī)則判斷節(jié)點(diǎn)vk-i的輸入數(shù)據(jù)是否有錯誤存在,如果沒有表示從初始點(diǎn)到vk-i之間的通路中只有vk-i節(jié)點(diǎn)上有不合理行為,則按照診斷規(guī)則進(jìn)入錯誤診斷流程,即轉(zhuǎn)入步驟3,如果存在錯誤轉(zhuǎn)入步驟4。

步驟3:判斷vk-i的輸出錯誤類型,記錄錯誤內(nèi)容,分析錯誤原因,儲存至錯誤類型數(shù)據(jù)庫,避免同樣錯誤繼續(xù)發(fā)生,轉(zhuǎn)入步驟5。

步驟4:令i=i+1,并轉(zhuǎn)入步驟2。

步驟5:診斷結(jié)束。

5 仿真研究

5.1 仿真環(huán)境

為實現(xiàn)對錯誤診斷算法的有效性測試,搭建具體的診斷環(huán)境平臺,平臺包括3臺服務(wù)器,一臺用來管理節(jié)點(diǎn),兩臺用來計算節(jié)點(diǎn)。收集目標(biāo)軟件運(yùn)行過程中的系統(tǒng)調(diào)用追蹤信息,采用本文方法對以下常用服務(wù)器的軟件配置情況進(jìn)行診斷,分別為:①多線程HTTP服務(wù)器;②關(guān)系型數(shù)據(jù)庫MySQL;③應(yīng)用程序服務(wù)器Java Web;④分布式文件系統(tǒng)Tomcat。

實驗結(jié)果表明：普通圓弧點(diǎn)云擬合的相對精度在0.003左右，復(fù)雜圓弧點(diǎn)云擬合的相對精度在0.01左右，這說明基于拉格朗日乘子法的空間圓弧擬合優(yōu)化方法有較強(qiáng)的理論研究意義和工程實踐價值。

為了獲得系統(tǒng)的真實配置錯誤,使用相關(guān)術(shù)語搜索測試對象的漏洞庫,手動檢測搜索出由配置錯誤所產(chǎn)生的bug,根據(jù)錯誤報告重現(xiàn)每個bug。最終得出實驗對象共存在9個由軟件配置錯誤導(dǎo)致的bug,如下:

1)Apache-1

其所在服務(wù)器為HTTP,導(dǎo)致其產(chǎn)生的原因為:由于軟件配置錯誤,是節(jié)點(diǎn)誤標(biāo)記導(dǎo)致了無限循環(huán),具體體現(xiàn)在系統(tǒng)中的癥狀為掛起。

2)Apache-2

其所在服務(wù)器為HTTP,導(dǎo)致其產(chǎn)生的原因為:由于軟件配置錯誤,誤標(biāo)記導(dǎo)致SSL重復(fù)銷毀和創(chuàng)建,降低系統(tǒng)性能。具體體現(xiàn)在系統(tǒng)中的癥狀為運(yùn)行速度減慢。

3)Tomcat-1

其所在服務(wù)器為Java Web,導(dǎo)致其產(chǎn)生的原因為:過濾器鏈項設(shè)置錯誤導(dǎo)致無限循環(huán)。具體癥狀為掛起。

4)Tomcat-2

5)Tomcat-3

其所在服務(wù)器為Java Web,導(dǎo)致其產(chǎn)生的原因為:嘗試將讀鎖升級至寫鎖知識服務(wù)器,具體癥狀為掛起。

6)HDFS-1

其所在服務(wù)器為Tomcat,導(dǎo)致其產(chǎn)生的原因為:無休止等待系統(tǒng)設(shè)置原子變量,具體癥狀為掛起。

7)HDFS-2

其所在服務(wù)器為Tomcat,導(dǎo)致其產(chǎn)生的原因為:連續(xù)讀取套接字直至超時,具體癥狀為掛起。

8)MySQL-1

其所在服務(wù)器為MySQL,導(dǎo)致其產(chǎn)生的原因為:兩個線程同時嘗試執(zhí)行INSERT DELAYED語句,但其中一個線程已鎖定表導(dǎo)致兩個線程進(jìn)入死鎖狀態(tài),具體癥狀為掛起。

9)MySQL-2

其所在服務(wù)器為MySQL,導(dǎo)致其產(chǎn)生的原因為:在截取一個大表后,寫入磁盤頻繁異常,具體癥狀為掛起。

5.2 診斷有效性測試

通過本文方法對以上系統(tǒng)進(jìn)行錯誤診斷,診斷結(jié)果如表2所示。

表2 診斷結(jié)果表

從表2中可以看出,本文方法成功地診斷出了不同系統(tǒng)由于軟件配置導(dǎo)致的bug,且診斷結(jié)果均與實際情況相同。

5.3 檢出率測試

對比本文方法與基于隨機(jī)Petri網(wǎng)、基于代碼路徑的軟件配置錯誤診斷檢出率,結(jié)果如圖1所示。可以看出所提方法的總檢出率要高于其它兩種方法,進(jìn)一步證明了本文方法能夠有效地完成配置錯誤診斷,能夠滿足實際需求。

圖1 不同方法檢出率對比圖

5.4 運(yùn)行效率測試

本節(jié)測試錯誤診斷的運(yùn)行時間是否能夠達(dá)到實時性要求,分別記錄出算法診斷不同錯誤的起始與結(jié)束時間,各個診斷耗時如圖2所示。

圖2 不同錯誤診斷耗時

從圖2中可以看出,本文方法的平均耗時較短,其中所有錯誤中診斷耗時最長的為Tomcat-3,共用了12s,最短為MySQL-1,耗時僅用了5s,所提方法能夠在短時間內(nèi)完成大量計算,運(yùn)行效率較高。

5.5 診斷開銷測試

在診斷過程中,會占用額外的運(yùn)行空間,將該空間稱為性能開銷,為驗證所提方法能否在不占用大量額外空間的前提下完成計算,對其性能開銷進(jìn)行測試,并根據(jù)實際數(shù)據(jù)對各測試設(shè)置工作量。針對Apache、Tomcat服務(wù)器,采用httperf以每秒100、50次的頻率向二者分別發(fā)出請求;使HDFS服務(wù)器運(yùn)行Pi程序;使MySQL服務(wù)器每秒執(zhí)行20次select操作。共進(jìn)行5次試驗,試驗結(jié)果如圖3所示。

圖3 診斷開銷測試結(jié)果

從圖3中可以看出,所提方法對MySQL-2產(chǎn)生的額外開銷最低,僅占用系統(tǒng)內(nèi)存約0.1GB,而最高開銷為Tomcat-3,也不超過0.5GB,且對各個bug進(jìn)行診斷時所占用內(nèi)存均低于其它兩種,證明了所提方法能夠在不影響系統(tǒng)正常運(yùn)行的情況下完成診斷,確保系統(tǒng)的可靠性。

6 結(jié)論

隨著軟件的功能增加,

軟件配置的復(fù)雜度也大幅度增加,配置錯誤也就隨之產(chǎn)生,為及時發(fā)現(xiàn)配置錯誤情況,提高系統(tǒng)可靠性,提出一種面向系統(tǒng)可靠性保障的軟件配置錯誤診斷仿真。首先根據(jù)實際參數(shù)給出各配置之間的關(guān)聯(lián)關(guān)系,制定出診斷規(guī)則,根據(jù)診斷規(guī)則判斷系統(tǒng)各節(jié)點(diǎn)的輸出和輸入數(shù)據(jù)流是否正確完成錯誤診斷全過程。通過實驗分析表明,所提方法的診斷準(zhǔn)確率較高、運(yùn)行耗時較短且性能開銷占比較低,能夠滿足實際需求。