魏 星，李 京，童飛帆

1(中國科學(xué)技術(shù)大學(xué)，合肥 230000)2(上海隨訓(xùn)通電子科技有限公司，上海 201100)

1 引 言

在數(shù)據(jù)爆炸式生長的時代，分布式系統(tǒng)[1]扮演著至關(guān)重要的角色，為互聯(lián)網(wǎng)用戶提供高可用、高可靠的計算或存儲服務(wù)[2].但分布式系統(tǒng)的復(fù)雜度極高，實際運行環(huán)境中可能發(fā)生各種不可預(yù)測的突發(fā)事件[3]，如節(jié)點宕機(jī)、網(wǎng)絡(luò)分區(qū)、高并發(fā)導(dǎo)致的磁盤讀寫繁忙等等，各種故障的發(fā)生往往對分布式系統(tǒng)帶來無法預(yù)料的災(zāi)難.

混沌工程(Chaos Engineering)[4-6]是一門“在分布式系統(tǒng)上進(jìn)行實驗的學(xué)科，目的是建立對系統(tǒng)承受生產(chǎn)環(huán)境中湍流條件能力的信心.”混沌工程技術(shù)主動地在分布式系統(tǒng)中模擬故障，制造出系統(tǒng)異常，以測試系統(tǒng)在故障下的穩(wěn)定性表現(xiàn)，提前暴露出潛在問題并進(jìn)行修復(fù)，避免實際運行過程中由于突發(fā)故障導(dǎo)致服務(wù)不穩(wěn)定甚至服務(wù)不可用.

傳統(tǒng)異常測試在給定預(yù)期輸入輸出后對系統(tǒng)的特定模塊、代碼邏輯等進(jìn)行測試，檢驗系統(tǒng)反饋是否正常.傳統(tǒng)異常測試的變量限制在各類用戶或開發(fā)者的操作上，如用戶輸入超出規(guī)定長度的字符、開發(fā)者更改配置文件；混沌工程的變量則反映各類現(xiàn)實的異常事件，如服務(wù)器死機(jī)、機(jī)房斷網(wǎng)等.不同于傳統(tǒng)異常測試，混沌工程直接對分布式系統(tǒng)進(jìn)行破壞，隨機(jī)模擬各種故障場景，并支持以可回放、持續(xù)性的故障演練驗證系統(tǒng)穩(wěn)定性.

基于混沌工程的故障實驗系統(tǒng)可分為兩類：一類以ChaosBlade[7]、Chaos Mesh[8]為代表，能面向不同的分布式系統(tǒng)提供故障實驗?zāi)芰?，但前者僅支持指定機(jī)器下的單個故障注入，后者支持故障編排實驗，但僅支持容器化[9]部署的機(jī)器.以上兩者都不支持?jǐn)?shù)據(jù)讀寫或驗證，且實驗粒度僅限于指定IP機(jī)器或指定ID的容器.一類以etcd Functional[10]為代表，由分布式系統(tǒng)開發(fā)者實現(xiàn)以支持某個特定系統(tǒng)的故障實驗，但這類技術(shù)多內(nèi)嵌于定制的系統(tǒng)框架，無法為其他分布式系統(tǒng)提供實驗?zāi)芰?綜上，基于混沌工程的自動化故障實驗技術(shù)面臨以下問題：

1)故障實驗編排指在實驗中支持一系列故障持續(xù)發(fā)生，通過故障編排，可在系統(tǒng)日常迭代時進(jìn)行一系列自動化故障實驗，降低人力實驗成本.現(xiàn)有技術(shù)大多專注于不同的底層故障實現(xiàn)，僅少數(shù)技術(shù)支持故障實驗編排，而支持實驗編排的技術(shù)對系統(tǒng)類型、部署環(huán)境等有較多限制.

2)分布式系統(tǒng)中進(jìn)程根據(jù)職責(zé)分為不同的角色，角色運行在不同機(jī)器上，可能會在機(jī)器間動態(tài)遷移.現(xiàn)有技術(shù)實驗粒度僅限于指定機(jī)器或指定容器，若系統(tǒng)發(fā)生角色遷移仍持續(xù)在原機(jī)器注入故障，無法實現(xiàn)精準(zhǔn)的角色粒度實驗.

3)在故障實驗中，通過系統(tǒng)讀寫(或接口調(diào)用，非嚴(yán)格數(shù)據(jù)讀寫)和數(shù)據(jù)驗證能實時驗證系統(tǒng)功能的可用性、正確性.但現(xiàn)有技術(shù)的實驗流程中僅支持故障操作，用戶需手動進(jìn)行系統(tǒng)數(shù)據(jù)讀寫及驗證等操作，往往具有滯后性.而不同系統(tǒng)的讀寫及驗證邏輯與系統(tǒng)本身強(qiáng)耦合，在故障實驗中支持這類定制化操作具有挑戰(zhàn)性.

針對上述問題，本文面向分布式系統(tǒng)創(chuàng)新性地提出了一種基于混沌工程的自動化故障實驗技術(shù).在該技術(shù)中，提出了一種自動化故障實驗系統(tǒng)架構(gòu)，定義了一套實驗抽象模型和實驗調(diào)度方法：1)支持通過一套標(biāo)準(zhǔn)的模型描述，對不同的故障及用戶定制化操作進(jìn)行自動化編排實驗；2)支持對分布式系統(tǒng)的角色粒度進(jìn)行實驗，并在角色遷移時能動態(tài)地將故障遷移至對應(yīng)節(jié)點；3)實驗?zāi)芰U(kuò)展，支持用戶進(jìn)行定制化操作開發(fā)如實現(xiàn)讀寫或數(shù)據(jù)驗證.與現(xiàn)有技術(shù)相比，上述技術(shù)具有以下優(yōu)勢：1)自動化，支持故障實驗編排，支持包含故障及讀寫驗證的完整故障實驗閉環(huán)；2)靈活度高，實驗中能動態(tài)地感知到分布式系統(tǒng)的角色動態(tài)遷移，支持對角色遷移后的機(jī)器進(jìn)行精準(zhǔn)故障實驗；3)開放度高，用戶可擴(kuò)展性地定制故障、讀寫、驗證操作.

根據(jù)本文所實現(xiàn)的自動化故障實驗系統(tǒng)在不同分布式系統(tǒng)上進(jìn)行實驗，結(jié)果表明相較于其他現(xiàn)有技術(shù)，本文技術(shù)能提供更自動化的故障實驗編排，支持對系統(tǒng)的角色粒度進(jìn)行動態(tài)實驗，支持用戶定制化操作并與實驗流程耦合，解決了現(xiàn)有技術(shù)的缺陷.

2 相關(guān)研究現(xiàn)狀

基于混沌工程，研究者們提出了不同的技術(shù)支持分布式系統(tǒng)上的故障模擬，幫助開發(fā)者通過故障實驗進(jìn)行系統(tǒng)穩(wěn)定性驗證.

Netflix[11]的Chaos Monkey為首個基于混沌工程技術(shù)的開源項目.Chaos Monkey實現(xiàn)了在Netflix云平臺中隨機(jī)關(guān)閉服務(wù)實例的故障，從而驗證服務(wù)整體在某部分實例失敗的情況下是否仍正常工作.該技術(shù)僅支持關(guān)閉服務(wù)實例場景的自動化實驗，提供的故障類型單一.

阿里巴巴的ChaosBlade系統(tǒng)提供豐富的故障類型，支持CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤、進(jìn)程等資源故障[12]，Java、C++ 等代碼級故障[13，14].ChaosBlade致力于提供豐富的故障場景，但未關(guān)注自動化實驗編排，用戶僅可進(jìn)行單故障注入，無法利用該技術(shù)進(jìn)行豐富的故障組合實驗.

PingCAP提出的Chaos Mesh提供自動化故障實驗?zāi)芰ΓС钟脩敉ㄟ^CRD(Custom Resource Definition)對象定義故障，包括故障行為、范圍、時間頻率等，故障根據(jù)用戶定義自動發(fā)生.但Chaos Mesh的自動化程度有限，無法在實驗流程中提供用戶數(shù)據(jù)讀寫、數(shù)據(jù)驗證等操作，且Chaos Mesh僅支持云原生部署的分布式系統(tǒng).

etcd[15]是一個應(yīng)用于分布式系統(tǒng)元數(shù)據(jù)的鍵值存儲系統(tǒng)，為驗證自身系統(tǒng)的穩(wěn)定性，etcd團(tuán)隊提出了一個故障注入框架Functional Testing.該框架可以驗證在各種系統(tǒng)故障、網(wǎng)絡(luò)故障、代碼故障下etcd是否能經(jīng)受住考驗.該框架支持etcd在故障實驗中進(jìn)行數(shù)據(jù)驗證操作，但Functional Testing內(nèi)嵌于etcd系統(tǒng)中，與etcd的其他模塊緊密耦合，無法為etcd以外的分布式系統(tǒng)提供通用的自動化故障實驗?zāi)芰?

Gremlin[16]公司提出了一個面向分布式存儲或計算系統(tǒng)的的“恢復(fù)能力即服務(wù)”(Resilience as a Service)平臺——Gremlin，該平臺提供自動化故障實驗?zāi)芰?Gremlin支持用戶將不同故障進(jìn)行編排實驗，但實驗流程中不支持進(jìn)行讀寫、驗證等操作，實驗粒度也僅限于指定機(jī)器.

綜上所述，現(xiàn)有自動化故障實驗技術(shù)具有明顯的局限性，無法靈活提供將不同故障組合的自動化實驗，無法支持在實驗中進(jìn)行數(shù)據(jù)讀寫、數(shù)據(jù)驗證等操作.同時，以上所有技術(shù)僅支持指定IP機(jī)器或指定ID容器粒度的實驗操作，無法支持在分布式系統(tǒng)的角色遷移過程中進(jìn)行動態(tài)的故障實驗.

3 混沌工程技術(shù)

混沌工程，是一種提高分布式系統(tǒng)高可用、穩(wěn)定性的復(fù)雜技術(shù)手段.其主要思想是主動地在分布式系統(tǒng)上進(jìn)行故障實驗，測試系統(tǒng)在面臨故障時是否能經(jīng)受考驗，提前識別出潛在的風(fēng)險項.若系統(tǒng)面臨故障時出現(xiàn)異常，如服務(wù)不穩(wěn)定或不可用，則認(rèn)為實驗成功，幫助用戶發(fā)現(xiàn)了系統(tǒng)的潛在風(fēng)險，以提前進(jìn)行系統(tǒng)修復(fù)，避免未來實際運行中由于該故障造成更大的損失.最簡單的故障實驗，如在分布式系統(tǒng)的某一臺機(jī)器上運行“kill-9”命令強(qiáng)制殺掉進(jìn)程，以驗證系統(tǒng)是否能在該進(jìn)程被殺后正常運行.

混沌工程技術(shù)常用到以下術(shù)語：“故障實驗”指在機(jī)器上模擬故障的發(fā)生從而進(jìn)行實驗的過程；“故障注入”指機(jī)器上開始進(jìn)行故障模擬，該詞源于將流感疫苗“注入”人體內(nèi)防止未來疾病的描述；“故障釋放”與“故障注入”相對，指在機(jī)器上停止故障模擬的過程；“故障模型”描述單個故障模擬發(fā)生的過程，如：故障的具體行為表現(xiàn)、發(fā)生時長、執(zhí)行頻率等；“編排”指對整體實驗過程進(jìn)行的預(yù)定義描述，如何時開始實驗，發(fā)生哪些故障，故障間的先后次序等.

現(xiàn)有的混沌工程技術(shù)架構(gòu)一般包括實驗管理層及故障模塊兩部分，代表故障操作的故障任務(wù)模型提交至實驗管理層后，由其解析目標(biāo)機(jī)器并下發(fā)至分布式系統(tǒng)的目標(biāo)機(jī)器中，機(jī)器中的預(yù)置的故障模塊接收模型后進(jìn)一步解析為相關(guān)指令，并對所在機(jī)器注入、釋放對應(yīng)故障.

4 基于混沌工程的自動化故障實驗系統(tǒng)

4.1 系統(tǒng)總覽

本文面向分布式系統(tǒng)提出的基于混沌工程的自動化故障實驗系統(tǒng)架構(gòu)如圖1所示.該架構(gòu)以“任務(wù)模型”和“編排模型”為輸入，實驗管理層根據(jù)用戶模型創(chuàng)建實驗并下發(fā)至第三方存儲系統(tǒng).實驗調(diào)度中心從第三方存儲中輪詢實驗狀態(tài)，符合預(yù)期執(zhí)行時間則解析實驗?zāi)Ｐ?，根?jù)模型描述轉(zhuǎn)換成任務(wù)注入、任務(wù)釋放指令，將指令下發(fā)到目標(biāo)角色所在節(jié)點中.節(jié)點中的故障模塊或用戶自定義插件模塊接收指令并實施指令操作.調(diào)度中心將記錄每次下發(fā)的指令，轉(zhuǎn)換為實驗執(zhí)行詳情，由第三方存儲回傳給管理層.

圖1基于混沌工程的自動化故障實驗系統(tǒng)架構(gòu)

現(xiàn)有技術(shù)架構(gòu)中，故障模塊需對任務(wù)模型進(jìn)行狀態(tài)保存，任務(wù)解析及指令轉(zhuǎn)換皆由故障模塊實現(xiàn).本文提出的架構(gòu)則將以上職責(zé)交由實驗調(diào)度中心，調(diào)度中心內(nèi)部分為角色監(jiān)控層、調(diào)度層、任務(wù)轉(zhuǎn)換層.調(diào)度中心與第三方存儲交互，監(jiān)控層實時監(jiān)控分布式系統(tǒng)中的角色遷移，并同步至第三方存儲.調(diào)度層不斷輪詢存儲中的模型，根據(jù)狀態(tài)進(jìn)行調(diào)度，若需要下發(fā)任務(wù)操作至分布式系統(tǒng)，則交由任務(wù)轉(zhuǎn)換層.任務(wù)轉(zhuǎn)換層將任務(wù)操作轉(zhuǎn)換為具體指令，下發(fā)至分布式集群中的目標(biāo)機(jī)器的故障模塊、插件模塊.本架構(gòu)中提出的插件模塊，可支持用戶可通過操作擴(kuò)展在實驗中進(jìn)行數(shù)據(jù)讀寫、一致性驗證[17]等.

4.2 自動化故障實驗編排

自動化故障實驗?zāi)軝z驗系統(tǒng)在一系列故障依次發(fā)生時的穩(wěn)定性，但現(xiàn)有技術(shù)中需要用戶手動進(jìn)行“檢驗”操作.若實驗流程中支持系統(tǒng)的讀寫測試及數(shù)據(jù)驗證等操作，能實時驗證故障下的系統(tǒng)穩(wěn)定性，降低人力成本.本節(jié)在傳統(tǒng)故障模型之上提出“任務(wù)模型”和“編排模型”.以任務(wù)模型的概念統(tǒng)一描述在故障實驗中進(jìn)行的故障、讀寫、數(shù)據(jù)驗證等操作，通過編排模型將不同的操作進(jìn)行組合，以提供自動化故障實驗編排功能.

4.2.1 任務(wù)模型

任務(wù)：故障實驗流程中的操作步驟，如發(fā)生磁盤故障、進(jìn)行數(shù)據(jù)驗證.

本技術(shù)中對任務(wù)定義如上，通過“任務(wù)”可將實驗流程拆分為不同的原子操作.任務(wù)模型對任務(wù)具體操作內(nèi)容進(jìn)行抽象描述，根據(jù)操作內(nèi)容的不同，將任務(wù)模型分為：

故障任務(wù)模型：描述故障操作的任務(wù)模型；

插件任務(wù)模型：描述用戶自定義操作的任務(wù)模型，如讀寫系統(tǒng)數(shù)據(jù)、數(shù)據(jù)驗證等操作.

故障任務(wù)和插件任務(wù)的具體操作在執(zhí)行方式上大相徑庭，但具有如下共同點：需指定操作的目標(biāo)節(jié)點、需指定執(zhí)行發(fā)生時長、支持周期性發(fā)生.任務(wù)模型抽象如表1所示，具有任務(wù)類型、任務(wù)目標(biāo)、調(diào)度參數(shù)及操作執(zhí)行具體參數(shù)等屬性，通過任務(wù)模型定義的任務(wù)操作遵循“開始執(zhí)行”、“停止執(zhí)行”.

表1 任務(wù)模型

故障任務(wù)由系統(tǒng)中內(nèi)置的故障模塊所提供，根據(jù)故障類型的不同，將故障任務(wù)模型的行為屬性擴(kuò)展如表2所示.在分布式系統(tǒng)中，利用網(wǎng)絡(luò)將服務(wù)分散在多臺機(jī)器上，互相協(xié)作以提供存儲、計算等功能，故網(wǎng)絡(luò)故障發(fā)生時會對分布式系統(tǒng)帶來可用性考驗.常見的網(wǎng)絡(luò)故障由物理線路故障、路由器故障、網(wǎng)絡(luò)擁塞、網(wǎng)絡(luò)請求密鑰過期等引發(fā)，但不同故障在分布式系統(tǒng)中體現(xiàn)為3種：網(wǎng)絡(luò)請求延時、網(wǎng)絡(luò)請求拒絕、網(wǎng)絡(luò)請求丟包.底層故障模塊實現(xiàn)時，可采用iptables[18]技術(shù)通過修改機(jī)器配置模擬以上3種網(wǎng)絡(luò)故障.網(wǎng)絡(luò)故障任務(wù)模型中需指定請求下游，即發(fā)往該目標(biāo)下游的請求會發(fā)生故障，可按“ip：port”或“cidr”[19]方式進(jìn)行指定.“probability”屬性幫助指定一個請求發(fā)生故障的概率，提供隨機(jī)性.網(wǎng)絡(luò)延時故障中需具有“延時時間”屬性.

文件系統(tǒng)中提供不同的操作方法，如“open”打開文件，“read”讀取文件內(nèi)容，“sync”將修改過的文件內(nèi)容由緩沖區(qū)寫入磁盤.“methods”指定文件系統(tǒng)中的操作方法列表，僅列出的操作方法發(fā)生故障.文件系統(tǒng)中常發(fā)生的故障可分為返回錯誤碼、操作延時，分別對應(yīng)為“error_no”、“delay”屬性，指定文件操作故障行為.

分布式系統(tǒng)若依賴時鐘進(jìn)行選舉投票等操作，時鐘跳變故障可幫助檢驗系統(tǒng)是否具有時鐘依賴或系統(tǒng)是否能再正確應(yīng)對時鐘跳變.時鐘跳變故障任務(wù)通過“offset”屬性描述系統(tǒng)偏移時間，支持系統(tǒng)時鐘向前或向后撥轉(zhuǎn).

CPU、磁盤等資源競爭會影響分布式系統(tǒng)中的服務(wù)穩(wěn)定性.CPU故障任務(wù)和磁盤故障任務(wù)通過“utils”可指定該類資源競爭時的占用率.

此外某些故障可通過用戶在機(jī)器上執(zhí)行Linux指令實現(xiàn)，如通過“rm-rf”刪除某機(jī)器上的數(shù)據(jù)文件.本文提出自定義指令故障，為保持“故障注入”、“故障釋放”的邏輯，用戶分別通過“start_cmd”及“stop_cmd” 描述該故障開始、結(jié)束時執(zhí)行的指令，指令透傳到目標(biāo)機(jī)器上執(zhí)行.

不同于故障任務(wù)，讀寫、驗證等任務(wù)操作與分布式系統(tǒng)自身的數(shù)據(jù)結(jié)構(gòu)、接口實現(xiàn)等緊密耦合.為支持用戶在實驗中進(jìn)行故障以外的操作，本文提出“插件式任務(wù)”，其實現(xiàn)于4.4節(jié)介紹，此處僅介紹其任務(wù)模型.插件任務(wù)模型符合表1的通用任務(wù)模型定義，“params”屬性為開放式接口定義.用戶需根據(jù)插件式任務(wù)實現(xiàn)時設(shè)置的參數(shù)進(jìn)行該屬性擴(kuò)展，如為etcd分布式系統(tǒng)開發(fā)的一個插件式讀寫任務(wù)中，可設(shè)置“op”參數(shù)表示操作類型，設(shè)置“counts”操作表示操作次數(shù)，則該插件模型定義時“params”字段下包括字符串類型的“op”及整數(shù)類型的“counts”兩參數(shù).

4.2.2 編排模型

編排：故障實驗發(fā)生流程，包括一場實驗中需執(zhí)行的任務(wù)、任務(wù)先后次序等.本技術(shù)對編排定義如上，通過編排可將不同的任務(wù)進(jìn)行組合，從而對一場故障實驗的具體操作內(nèi)容進(jìn)行整體描述.編排模型對實驗編排進(jìn)行抽象，定義好的編排模型可作為實驗?zāi)０鍒?zhí)行，模型屬性及規(guī)則如表3所示，實驗運行時根據(jù)目標(biāo)系統(tǒng)、實驗周期、目標(biāo)系統(tǒng)角色映射接口等屬性進(jìn)行調(diào)度.

表3 編排模型

“狀態(tài)機(jī)”描述實驗操作流程，狀態(tài)機(jī)中定義多個狀態(tài)s1、s2，代表實驗流程的不同階段.每個狀態(tài)內(nèi)部可定義t1、t2等多個任務(wù)，即處于該狀態(tài)的實驗階段需進(jìn)行的具體操作.通過狀態(tài)機(jī)定義的編排模型實驗流程如圖2所示.不同狀態(tài)按照定義次序串行流轉(zhuǎn)，同個狀態(tài)內(nèi)的任務(wù)并發(fā)執(zhí)行，當(dāng)某狀態(tài)下的所有任務(wù)執(zhí)行完畢后才進(jìn)入下一個狀態(tài)階段.

圖2 狀態(tài)機(jī)流程示例

本系統(tǒng)實現(xiàn)時定義的編排模型示例如表4所示，其中“role_url”為期望實驗的分布式系統(tǒng)中提供角色查詢的地址，實驗過程中實時通過該地址獲取系統(tǒng)中不同角色與所在節(jié)點IP的映射關(guān)系，從而實現(xiàn)角色粒度的動態(tài)故障實驗.“schedule”表明該編排是否定時發(fā)生，可指定首次發(fā)生時長和執(zhí)行周期.若不指定“schedule”字段，則該編排應(yīng)由用戶手動觸發(fā)執(zhí)行.“status_machine”描述任務(wù)發(fā)生流程，由該字段示例值描述的實驗發(fā)生時，會先執(zhí)行status1中的“network-reject”網(wǎng)絡(luò)拒絕故障；接著同時執(zhí)行status2的“network-drop”和“cpu-burn”故障，兩個故障都結(jié)束后，最后執(zhí)行“consistency-check”一致性驗證任務(wù).

表4 編排模型示例

4.3 支持角色粒度的動態(tài)調(diào)度

在分布式系統(tǒng)中，將參與進(jìn)程根據(jù)不同職責(zé)定義為“角色”，如Hadoop系統(tǒng)中管理元數(shù)據(jù)的進(jìn)程角色為 “namenode”，負(fù)責(zé)數(shù)據(jù)存儲的進(jìn)程角色為“datanode”.不同的角色運行在集群各個機(jī)器之上，由于機(jī)器故障、選舉、進(jìn)程異常等原因，進(jìn)程的角色會發(fā)生變化甚至消失，即角色在機(jī)器間“動態(tài)遷移”.故障實驗中，故障效果應(yīng)伴隨角色遷移至對應(yīng)的機(jī)器.

實驗調(diào)度中心為無狀態(tài)計算[20]，即無主式的多節(jié)點部署[21]，狀態(tài)信息皆由第三方存儲保存，可快速進(jìn)行實驗擴(kuò)展，也能在某調(diào)度節(jié)點崩潰時由其他節(jié)點快速接任完成調(diào)度.每個調(diào)度節(jié)點上分別獨立運行編排實例調(diào)度器、狀態(tài)轉(zhuǎn)換器、任務(wù)實例調(diào)度器等多個子模塊.調(diào)度中心根據(jù)分布式系統(tǒng)角色信息進(jìn)行動態(tài)實驗的流程如圖3所示，當(dāng)某角色由節(jié)點1遷移至節(jié)點2時，角色監(jiān)控器察覺到并更新存儲系統(tǒng)的角色及節(jié)點映射關(guān)系，編排實例調(diào)度器輪詢發(fā)現(xiàn)后通知任務(wù)實例調(diào)度器，解析后由任務(wù)轉(zhuǎn)換器停止原節(jié)點的故障，并在新節(jié)點中重新開始執(zhí)行.

圖3 故障動態(tài)轉(zhuǎn)移流程

調(diào)度算法中設(shè)計主要對象包括編排實例及任務(wù)實例.編排實例對應(yīng)正在運行的實驗編排，如表5所示具有執(zhí)行狀態(tài)、最近角色信息等屬性，其生命周期示意如圖4(a)所示，從實驗開始持續(xù)至所有狀態(tài)的任務(wù)運行結(jié)束，由編排調(diào)度器管理.

表5 編排實例對象及規(guī)則

任務(wù)實例對應(yīng)正在運行的任務(wù)，由任務(wù)實例調(diào)度器管理，如表6所示描述當(dāng)前是否正在執(zhí)行、最近執(zhí)行的目標(biāo)節(jié)點等信息.任務(wù)實例的生命周期示意如圖4(b)所示，編排流轉(zhuǎn)至該任務(wù)所屬狀態(tài)時，任務(wù)實例被創(chuàng)建即生命周期開始，當(dāng)任務(wù)實例及所有并發(fā)實例超時(根據(jù)用戶定義的任務(wù)運行時長)，則實例被刪除，結(jié)束生命周期.一個任務(wù)實例在其生命周期內(nèi)，可能反復(fù)執(zhí)行多次，如當(dāng)用戶設(shè)置10分鐘內(nèi)每2分鐘執(zhí)行30秒時，該任務(wù)實例將于生命周期內(nèi)先后執(zhí)行5次.

表6 任務(wù)實例對象及規(guī)則

圖4 調(diào)度層實例生命周期

在故障實驗中，調(diào)度算法將所有類型任務(wù)統(tǒng)一調(diào)度.但部分任務(wù)如用戶定制的數(shù)據(jù)讀寫操作不具有冪等性[22]，多個調(diào)度器同時拉取到該任務(wù)實例并執(zhí)行，會帶來不符合預(yù)期的語義操作.算法中通過任務(wù)唯一鍵保證單個任務(wù)不被多個調(diào)度器重復(fù)執(zhí)行，采用“{flow-instance}/{status}/{task-instance}/{counts}”標(biāo)志某個任務(wù)實例的某次具體執(zhí)行.任務(wù)實例調(diào)度器對任務(wù)執(zhí)行唯一鍵的操作邏輯如圖5所示.當(dāng)執(zhí)行或停止執(zhí)行任務(wù)失敗時，需啟用補(bǔ)償機(jī)制，重新刪除或創(chuàng)建該鍵，以便后續(xù)調(diào)度器根據(jù)鍵的存在狀態(tài)重新嘗試操作.

圖5 任務(wù)實例調(diào)度器對任務(wù)唯一鍵的操作流程

4.4 支持定制讀寫、驗證的能力擴(kuò)展

現(xiàn)有混沌技術(shù)不支持用戶進(jìn)行定制化開發(fā)，無法將自定義故障、期望的其他自定義操作與故障實驗流程相結(jié)合.考慮到分布式系統(tǒng)的讀寫模型、接口規(guī)范、數(shù)據(jù)語義等大相徑庭，一般需要用戶自行完成接口適配、代碼編寫.定制任務(wù)應(yīng)由調(diào)度層進(jìn)行統(tǒng)一調(diào)度，保持和其他任務(wù)相同的邏輯規(guī)范，即任務(wù)支持“開始執(zhí)行”、“停止執(zhí)行”操作.

為支持用戶編程、統(tǒng)一任務(wù)調(diào)度，本技術(shù)以插件模塊的形式實現(xiàn)為用戶提供操作(讀寫、驗證、自定義故障等)定制的能力擴(kuò)展.插件模塊可通過服務(wù)注冊方式與系統(tǒng)耦合，其框架模板由實驗系統(tǒng)統(tǒng)一提供，內(nèi)置注冊、解注冊實現(xiàn)，為用戶預(yù)留“開始執(zhí)行”、“停止執(zhí)行”方法接口.用戶根據(jù)插件模塊框架自由開發(fā)期望的任務(wù)操作邏輯，啟動框架后該模塊會自動注冊至第三方存儲，并同步至實驗管理層.當(dāng)啟動的實驗中需要運行插件任務(wù)時，調(diào)度邏輯與內(nèi)置故障任務(wù)一致，但在下發(fā)至節(jié)點時需查詢注冊表中的預(yù)置參數(shù)及類型，將操作轉(zhuǎn)換成對應(yīng)指令下發(fā)至目標(biāo)節(jié)點的插件模塊.

5 系統(tǒng)測試與實驗

為驗證本文技術(shù)的有效性：支持自動化故障實驗編排，支持基于角色粒度進(jìn)行動態(tài)故障實驗，支持用戶進(jìn)行數(shù)據(jù)讀寫、數(shù)據(jù)驗證等插件任務(wù)開發(fā)并耦合至故障實驗流程，本節(jié)進(jìn)行系統(tǒng)實驗如下.

5.1 實驗設(shè)置

按照圖1的實驗架構(gòu)實現(xiàn)自動化故障實驗系統(tǒng)，其中實驗管理平臺及實驗調(diào)度模塊分別多實例部署在一個三節(jié)點集群中，為用戶提供Web界面和API操作兩種實驗方式.系統(tǒng)參照現(xiàn)有的混沌技術(shù)實現(xiàn)了故障模塊，該模塊集成不同的底層技術(shù)，實現(xiàn)4.2.1節(jié)中提到的各種故障效果：網(wǎng)絡(luò)拒絕/丟包/延時故障(iptables技術(shù))、文件系統(tǒng)故障(fuse[23]、hookfs[24]技術(shù))、磁盤讀寫繁忙(stress-ng[25])、時鐘跳變、CPU繁忙、自定義指令故障.該系統(tǒng)包括故障模塊將于GitHub上進(jìn)行開源.

實驗所面向的分布式系統(tǒng)選取Hadoop[26]及etcd.Hadoop部署于OpenStack[27]的10臺虛擬機(jī)中，由一個namenode節(jié)點和多個datanode節(jié)點組成，啟用HA[28]機(jī)制進(jìn)行主備切換.etcd在5臺虛擬機(jī)中進(jìn)行部署，分為一個leader節(jié)點和4個worker節(jié)點.

5.2 故障效果及支持操作定制的自動化編排驗證

為驗證本系統(tǒng)支持操作定制的自動化編排功能及實際故障效果，設(shè)計編排流程如表7所示，首先開啟系統(tǒng)讀寫，然后進(jìn)行一系列故障注入，故障結(jié)束后對讀寫數(shù)據(jù)進(jìn)行驗證.

表7 自動化編排實驗流程設(shè)計

讀寫及驗證任務(wù)皆為插件任務(wù)，系統(tǒng)采用Golang-Gin[29]框架實現(xiàn)插件模塊，為用戶預(yù)留“開始執(zhí)行”、“停止執(zhí)行”兩函數(shù)進(jìn)行自定義代碼開發(fā)，該模塊由用戶啟動后自動注冊于調(diào)度層.Hadoop讀寫任務(wù)于“開始執(zhí)行”函數(shù)內(nèi)調(diào)用10000次“hadoop fs-put”API即進(jìn)行文件上傳操作，文件內(nèi)容為當(dāng)次操作次數(shù)編號，調(diào)用結(jié)果記錄至本地日志；Hadoop驗證任務(wù)于“開始執(zhí)行”函數(shù)進(jìn)行“hadoop fs-get”文件讀取操作，驗證文件最終內(nèi)容并核對本地日志的調(diào)用成功次數(shù).etcd讀寫任務(wù)于“開始執(zhí)行”函數(shù)內(nèi)調(diào)用10000次“etcdctl put”對指定鍵“etcd-chaos-test”進(jìn)行寫操作，寫入值為操作次數(shù)編號，將操作結(jié)果記錄本地日志；etcd驗證任務(wù)于“開始執(zhí)行”函數(shù)內(nèi)調(diào)用“etcdctl get”驗證鍵值并核對日志記錄的操作成功次數(shù).讀寫及驗證任務(wù)的代碼邏輯于“開始執(zhí)行”函數(shù)中執(zhí)行完畢后即返回，無需“停止執(zhí)行”函數(shù)主動停止，故以上任務(wù)的“停止執(zhí)行”函數(shù)為空代碼.將以上插件任務(wù)對應(yīng)實現(xiàn)的模塊分別于集群主節(jié)點啟動，實驗中由調(diào)度層觸發(fā)執(zhí)行.

根據(jù)編排流程通過API設(shè)置實驗，根據(jù)任務(wù)效果創(chuàng)建任務(wù)模型后提交編排配置如圖6所示，該配置為API提交時所需的JSON[30]格式.實驗過程中監(jiān)控各機(jī)器的各項系統(tǒng)指標(biāo).

圖6 通過API實驗的編排配置文件(Json)

Hadoop集群中的實驗效果如圖7(a)所示.status1的插件讀寫啟動后于后臺執(zhí)行，狀態(tài)立即流轉(zhuǎn)至status2開始故障，該過程耗時為秒級，故從status2開啟時為時間原點.在0-10分鐘，由于網(wǎng)絡(luò)丟包故障導(dǎo)致入請求減少，從節(jié)點datanode8所在機(jī)器出現(xiàn)持續(xù)十分鐘的網(wǎng)絡(luò)入流量低谷.10-20分鐘，隨機(jī)節(jié)點發(fā)生的磁盤繁忙故障在datanode3中發(fā)生，節(jié)點磁盤讀寫占用率都拉高至近100%.20-25分鐘，文件系統(tǒng)故障導(dǎo)致datanode6及datanode8(圖中僅顯示datanode6效果)所在機(jī)器的文件讀寫延時超過200ms.25-35分鐘，CPU繁忙故障導(dǎo)致namenode節(jié)點CPU占用率持續(xù)拉高近100%，該繁忙效果每隔1分鐘發(fā)生1分鐘.驗證時發(fā)現(xiàn)，Hadoop集群中的文件上傳操作均成功，即成功應(yīng)對以上故障場景.

圖7 自動化編排實驗效果

etcd集群中故障效果表現(xiàn)如圖7(b)所示.0-10分鐘，從節(jié)點4發(fā)生網(wǎng)絡(luò)入流量低谷；10-20分鐘，從節(jié)點2的磁盤繁忙率提升；20-25分鐘，從節(jié)點3的文件系統(tǒng)操作延時增大至200ms；25-35分鐘，leader節(jié)點的CPU占用率周期性升至100%.驗證任務(wù)發(fā)現(xiàn)，etcd集群中的10000次寫鍵操作均成功，面臨以上故障場景時仍具有可用性.

若使用現(xiàn)有的混沌技術(shù)如ChaosBlade、Chaos Mesh進(jìn)行上述實驗等，用戶需自行開發(fā)實驗?zāi)_本，腳本中采用定時設(shè)置提交對應(yīng)的故障任務(wù).讀寫及驗證任務(wù)需由用戶開發(fā)后手動于故障實驗前后開啟，開發(fā)成本較高，且操作繁瑣.

5.3 動態(tài)角色故障實驗驗證

為驗證分布式系統(tǒng)中角色遷移時故障效果是否跟隨遷移，設(shè)計實驗編排如表8，在主節(jié)點(Hadoop集群的namenode角色、etcd集群的leader角色)持續(xù)注入2分鐘CPU繁忙故障，實驗開啟1分鐘后在Hadoop集群通過自定義指令故障中進(jìn)行namenode主備切換，在etcd集群中通過網(wǎng)絡(luò)丟包故障模擬etcd leader網(wǎng)絡(luò)分區(qū)，使兩集群發(fā)生角色遷移，并驗證CPU故障效果是否發(fā)生轉(zhuǎn)移.實驗分別通過本系統(tǒng)及ChaosBlade進(jìn)行，驗證是否根據(jù)角色遷移進(jìn)行故障轉(zhuǎn)移.

表8 動態(tài)角色故障實驗流程設(shè)計

本文實現(xiàn)系統(tǒng)對Hadoop集群的實驗效果如圖8(a)所示，實驗開始時，namenode角色位于的test-hadoop-001機(jī)器CPU繁忙率達(dá)到100%，一分鐘后由于主動切換namenode使得原namenode進(jìn)入備用狀態(tài)而test-hadoop-002的namenode角色激活，test-hadoop-001機(jī)器的CPU占用率恢復(fù)正常，但test-hadoop-002中的CPU占用率提升至100%.

圖8 動態(tài)角色實驗效果

ChaosBlade系統(tǒng)對Hadoop集群的實驗效果如圖8(b)所示，實驗開始時namenode角色位于的test-hadoop-001機(jī)器CPU繁忙率達(dá)到100%，后因啟動HA機(jī)制激活test-hadoop-002的備份namenode角色，但namenode角色遷移完成后CPU故障仍持續(xù)發(fā)生在原節(jié)點test-hadoop-001，namenode所在新節(jié)點test-hadoop-002未發(fā)生CPU繁忙故障效果.

本文實現(xiàn)系統(tǒng)對etcd集群的實驗效果如圖8(c)所示，實驗開始時leader角色位于test-node-001機(jī)器，CPU繁忙率達(dá)到100%，一分鐘后該機(jī)器發(fā)生網(wǎng)絡(luò)丟包故障，無法與各從節(jié)點通信.從節(jié)點發(fā)現(xiàn)主節(jié)點無響應(yīng)后，集群leader角色空缺，test-node-001的CPU繁忙故障停止.集群重新選主后由test-node-003機(jī)器的etcd進(jìn)程當(dāng)選為leader，CPU繁忙故障重新發(fā)生在leader所位于的新節(jié)點test-node-003.

采用ChaosBlade系統(tǒng)進(jìn)行的實驗效果如圖8(d)所示，leader角色位于節(jié)點test-node-003，該節(jié)點的CPU繁忙達(dá)到100%，1分鐘后手動在該節(jié)點運行丟包故障.多個從節(jié)點發(fā)現(xiàn)主節(jié)點無響應(yīng)后選取test-node-002機(jī)器的etcd進(jìn)程為leader，但CPU繁忙故障繼續(xù)發(fā)生在原節(jié)點test-node-003，新leader所在機(jī)器的CPU未出現(xiàn)繁忙效果.

結(jié)果表明本文實現(xiàn)的系統(tǒng)能通過感知用戶實驗系統(tǒng)中的角色遷移，將故障注入到角色遷移后的機(jī)器.而已有的工具不提供角色粒度的故障注入，僅能對指定IP機(jī)器進(jìn)行實驗.

6 總 結(jié)

采用混沌工程技術(shù)能通過模擬系統(tǒng)中的故障發(fā)生，提前檢驗系統(tǒng)面臨故障時的可用穩(wěn)定性.當(dāng)現(xiàn)有的基于混沌工程的故障實驗系統(tǒng)自動化程度有限，大多不提供故障實驗編排能力，少數(shù)支持編排的系統(tǒng)不支持用戶進(jìn)行系統(tǒng)讀寫、數(shù)據(jù)驗證等操作.且現(xiàn)有系統(tǒng)的故障實驗都基于機(jī)器或容器粒度進(jìn)行，無法支持根據(jù)分布式系統(tǒng)角色進(jìn)行動態(tài)故障注入.

本文面向分布式系統(tǒng)，提出了一種基于混沌工程的自動化故障實驗系統(tǒng)，相比于現(xiàn)有系統(tǒng)，具有以下優(yōu)勢：1)自動化，通過實驗編排支持組合故障實驗，支持包含故障及讀寫驗證的完整故障實驗閉環(huán)；2)靈活度高，實驗中可動態(tài)地感知到分布式系統(tǒng)的角色遷移，對角色遷移后的機(jī)器進(jìn)行精準(zhǔn)的故障實驗；3)開放度高，提供可擴(kuò)展的實驗?zāi)芰?，用戶可進(jìn)行定制化故障或定制化操作開發(fā).

但利用混沌工程技術(shù)在分布式系統(tǒng)中進(jìn)行故障注入是極具風(fēng)險的操作，用戶應(yīng)評估風(fēng)險和故障影響面后進(jìn)行故障實驗，筆者推薦對測試系統(tǒng)進(jìn)行故障實驗后再逐步于生產(chǎn)環(huán)境驗證.此外，本文系統(tǒng)由實驗調(diào)度層而非目標(biāo)機(jī)器進(jìn)行故障調(diào)度，當(dāng)系統(tǒng)宕機(jī)時可能造成故障無法正確釋放，可通過故障模塊設(shè)置兜底時間等方式降低風(fēng)險.