面向系統可靠性保障的軟件配置錯誤診斷仿真

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

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

1 引言

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

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

基于此,本文面向保障系統的可靠性,給出一種基于軟件間關聯關系的配置錯誤診斷方法。總結軟件組件各配置間的關聯關系,根據推導出的錯誤診斷規則,對錯誤源進行判斷。實驗表明所提方法的診斷精度高,具有可應用于實際的價值。

2 軟件配置項類型匹配

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

(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表示軟件運行時間,令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,系統才能正常運行。設加入數據指令后,同時考慮容錯條件的系統可靠性為R′(t),不考慮容錯條件的可靠性為R″(t),則原系統R′(t)、R(t)的比值r以及R″(t)和R′(t)之間的比值關系分別為:

(5)

式中,u表示錯誤率,通過上文可得,現有系統的可靠性要高于原有系統,則有

(6)

由此可得,軟件配置采用不同結構、不同連接方式相連所得的軟件系統可靠性具有一定的差異[4],因此需要分析系統軟件中各配置間的關聯性,才能更好地完成配置錯誤的診斷。

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

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

3 診斷規則生成

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

表1 診斷規則生成模板

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

4 軟件配置錯誤診斷實現

首先給出2點錯誤源假設如下:

假設1:節點狀態錯誤,根據診斷規則可以得出該錯誤主要體現在兩個方面分別為:各路徑對應的輸入關系流判斷錯誤,任務執行時出現不合理現象。

假設2:輸入數據存在錯誤,因此根據診斷規則可以得出不論系統各個節點的狀態是否正常,錯誤關系都會傳遞到輸出關系流。

根據以上假設得出如下公理:

公理:若某節點的所有輸出關系均為正確的,則可認定該節點沒有錯誤,如果某節點的輸出關系流存在錯誤,則認為該節點中存在錯誤。

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

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

根據以上定理總結出以下兩點錯誤:

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

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

若任意節點vk的執行主體發現前一節點的輸入關系有錯誤,則根據診斷規則可知該任務的前一節點輸出關系流發生錯誤,此時軟件的運行就會出現故障,需要對該故障進行定位和診斷,具體步驟如下:

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

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

步驟3:判斷vk-i的輸出錯誤類型,記錄錯誤內容,分析錯誤原因,儲存至錯誤類型數據庫,避免同樣錯誤繼續發生,轉入步驟5。

步驟4:令i=i+1,并轉入步驟2。

步驟5:診斷結束。

5 仿真研究

5.1 仿真環境

為實現對錯誤診斷算法的有效性測試,搭建具體的診斷環境平臺,平臺包括3臺服務器,一臺用來管理節點,兩臺用來計算節點。收集目標軟件運行過程中的系統調用追蹤信息,采用本文方法對以下常用服務器的軟件配置情況進行診斷,分別為:①多線程HTTP服務器;②關系型數據庫MySQL;③應用程序服務器Java Web;④分布式文件系統Tomcat。

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

為了獲得系統的真實配置錯誤,使用相關術語搜索測試對象的漏洞庫,手動檢測搜索出由配置錯誤所產生的bug,根據錯誤報告重現每個bug。最終得出實驗對象共存在9個由軟件配置錯誤導致的bug,如下:

1)Apache-1

其所在服務器為HTTP,導致其產生的原因為:由于軟件配置錯誤,是節點誤標記導致了無限循環,具體體現在系統中的癥狀為掛起。

2)Apache-2

其所在服務器為HTTP,導致其產生的原因為:由于軟件配置錯誤,誤標記導致SSL重復銷毀和創建,降低系統性能。具體體現在系統中的癥狀為運行速度減慢。

3)Tomcat-1

其所在服務器為Java Web,導致其產生的原因為:過濾器鏈項設置錯誤導致無限循環。具體癥狀為掛起。

4)Tomcat-2

5)Tomcat-3

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

6)HDFS-1

其所在服務器為Tomcat,導致其產生的原因為:無休止等待系統設置原子變量,具體癥狀為掛起。

7)HDFS-2

其所在服務器為Tomcat,導致其產生的原因為:連續讀取套接字直至超時,具體癥狀為掛起。

8)MySQL-1

其所在服務器為MySQL,導致其產生的原因為:兩個線程同時嘗試執行INSERT DELAYED語句,但其中一個線程已鎖定表導致兩個線程進入死鎖狀態,具體癥狀為掛起。

9)MySQL-2

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

5.2 診斷有效性測試

通過本文方法對以上系統進行錯誤診斷,診斷結果如表2所示。

表2 診斷結果表

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

5.3 檢出率測試

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

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

5.4 運行效率測試

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

圖2 不同錯誤診斷耗時

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

5.5 診斷開銷測試

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

圖3 診斷開銷測試結果

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

6 結論

隨著軟件的功能增加,

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