跳轉到內容

大資料實用DevOps/故障注入

來自Wikibooks,開放世界的開放書籍

資料密集型應用程式的操作幾乎總是需要處理各種故障。因此,在應用程式開發過程中,必須進行測試以評估系統的可靠性和彈性。這些測試了系統應對故障的能力,並突出了任何薄弱環節。故障注入工具 (FIT) [1] 允許使用者在其虛擬機器上生成故障,從而為他們提供了一種測試其安裝彈性的方法。使用這種方法,設計人員可以使用穩健的測試,突出顯示在到達商業環境之前需要檢查的薄弱環節。使用者或應用程式所有者可以測試和了解其應用程式設計或部署在雲故障或中斷的情況下,從而在基於雲的部署之前提前減輕風險。

大資料市場當前和預計的增長為該工具提供了三個不同的目標。資料中心所有者、雲服務提供商和應用程式所有者都是潛在的受益者,因為他們對資料的密集要求。基礎設施的彈性對這些領域至關重要。資料中心所有者可以衡量其基礎設施不同部分的壓力水平,從而為其客戶提供建議,解決瓶頸,甚至調整不同保證級別的定價。對於開發人員來說,FIT 提供了評估應用程式彈性和可靠性的缺失且必要的服務,這隻能透過在應用程式執行時故意引入故障來證明。透過將 FIT 設計為輕量級且通用的工具,在持續整合或其他工具中運行復雜故障場景時,使用它非常簡單。與本報告範圍之外的其他工具結合使用,FIT 可以監控和評估各種故障對應用程式的影響,並將反饋提供給開發人員以進行應用程式設計。

現有解決方案

[編輯 | 編輯原始碼]
  • DOCTOR (IntegrateD SOftware Fault InjeCTiOn EnviRonment) [2] 允許注入記憶體和暫存器故障,以及網路通訊故障。它結合使用超時、陷阱和程式碼修改。超時觸發注入瞬態記憶體故障,陷阱注入瞬態模擬硬體故障,如暫存器損壞。程式碼修改用於注入永久性故障。
  • Orchestra [3] 是一種指令碼驅動的故障注入器,基於網路級故障注入。它的主要用途是評估和驗證分散式協議的容錯和時序特性。Orchestra 最初是為 Mach 作業系統開發的,並使用此平臺的某些功能來補償故障注入器引入的延遲。它也已成功移植到其他作業系統。
  • Xception [4] 旨在利用許多現代處理器上可用的高階除錯功能。它被編寫為不需要修改系統原始碼,也不需要插入軟體陷阱,因為處理器的異常處理功能會觸發故障注入。這些觸發器基於對特定記憶體位置的訪問。此類訪問可能是為了獲取資料或獲取指令。因此,可以準確地再現測試執行,因為觸發器可以繫結到特定事件,而不是超時。
  • Grid-FIT (Grid – Fault Injection Technology) [5] 是一種可靠性評估方法和工具,用於透過故障注入評估網格服務。Grid-FIT 來自較早的故障注入器 WS-FIT,該注入器針對使用 Apache Axis 傳輸實現的 Java Web 服務。Grid-FIT 利用一種新穎的故障注入機制,該機制允許使用網路級故障注入來提供類似於程式碼插入故障注入的控制級別,同時侵入性更低。
  • LFI (Library-level Fault Injector) [6] 是一種自動測試工具套件,用於在受控測試環境中模擬程式在執行時需要處理但僅透過輸入測試難以檢查的異常情況。LFI 自動識別共享庫暴露的錯誤,查詢程式二進位制檔案中潛在的錯誤錯誤恢復程式碼,並在共享庫和應用程式之間的邊界注入所需的故障。

FIT的工作原理

[編輯 | 編輯原始碼]

到目前為止,FIT 的設計專門包含最佳實踐策略,以確保資料密集型應用程式的可靠性,從而允許在開發期間和部署後對應用程式進行嚴格的測試。

FIT架構

這將允許雲平臺所有者/應用程式 VM 所有者透過在雲級別生成故障來測試雲安裝和應用程式的彈性。

DICE FIT 也以模組化的方式設計和開發。這允許替換執行故障的任何功能,以及根據需要擴充套件工具的潛力。FIT 被設計為在 VM 上儘可能輕量級,因此出於這個原因,僅實現了現有經過良好測試的工具來導致故障。FIT 只下載、安裝和配置當時需要的內容,因此不會安裝任何不必要的工具或依賴項。FIT 允許 VM 管理員、應用程式所有者和雲管理員生成各種故障。它獨立於任何目標環境執行。圖 1 說明了架構。

FIT 被設計為從命令列或圖形使用者介面工作。使用者可以呼叫連線到目標 VM 的操作,並自動安裝任何所需的工具和依賴項,或呼叫所需的 API。命令列開關和引數允許使用者選擇特定故障以及故障的引數,例如要使用的 RAM 量或要停止的服務。以下是一個使用 SSH 連線到節點並使用 2GB 造成記憶體壓力的示例命令列呼叫

--stressmem 2 2048m Ubuntu@109.231.126.101 -no home/ubuntu/SSHKEYS/VMKey.key

記憶體飽和

此呼叫在真實的雲系統上執行。該工具透過 SSH 連線並透過檢查/etc/*-release(在本例中為 Ubuntu)來確定作業系統版本。然後,它收集適用於 Ubuntu 的記憶體壓力工具,在本例中為 Memtester [7]。最後,FIT 呼叫 Memtester 來飽和目標節點上的記憶體。圖 2 顯示了監控工具檢測到的目標節點在 FIT 呼叫之前(左)和期間(右)的可用記憶體,其中可以看出幾乎所有 2GB 的可用 RAM 都已飽和。

為了訪問 VM 級別併發出命令,DICE FIT 使用 JSCH 透過 SSH 連線到虛擬機器。透過使用 JSCH,該工具能夠連線到任何啟用了 SSH 的 VM,然後以預定義的使用者身份發出命令。這允許更大的命令靈活性以及工具和依賴項的安裝。DICE FIT 在寬鬆的 Apache 許可證 2.0 [8] 下發布,並支援作業系統配置 Ubuntu(已在 14.04 和 15.10 版本上測試)和 Centos,設定了 Repo 配置並安裝了 wget(在 7 版本上測試)。

圖形使用者介面

[編輯 | 編輯原始碼]
FIT 圖形介面

圖形介面提供與工具命令列版本相同的功能。圖形介面為使用者提供了一種與工具進行視覺互動的方式,這使得工具更容易被各種使用者使用。使用者可以從主螢幕中選擇可用的操作,如圖 3 所示。每個按鈕都會連結到一個頁面,使用者可以在該頁面上輸入相關的輸入,然後執行故障。這些輸入等同於命令列引數。

在 CPU 過載頁面中,使用者輸入虛擬機器的詳細資訊以及執行過載的時間長度。使用者可以從檔案上傳 SSH 金鑰來代替密碼。從執行故障中獲得的任何反饋和輸出都顯示在頁面底部。

FIT CPU

使用圖形介面是一個簡單的過程,只需選擇所需的故障並提供虛擬機器詳細資訊即可。在下面的示例中,選擇了高 CPU 使用率故障,並輸入了虛擬機器的地址、使用者名稱和密碼。輸入了機器上的 CPU 數量,然後輸入了使 CPU 過載的時間長度,在本例中為 30 秒,如圖 4 所示。

圖形介面成功地補充了命令列工具實現的目標。它使故障注入工具高度易於訪問,使任何人都可以發現漏洞並測試其系統的彈性。

原始碼可以在 DICE GitHub 倉庫中找到。該倉庫包含原始碼和 WAR 檔案,因此可以將其部署在伺服器上,例如 Apache Tomcat。一旦映象部署在伺服器上,它將立即可用並可以使用。

開放挑戰

[編輯 | 編輯原始碼]

未來的工作將涉及對故障進行更詳細的分類,並結合對各種故障場景的起因、影響和響應的分析。從設計和操作的角度來看,將進行調查以確定如何最好地與相關服務整合。需要強大的監控、圖形和分析功能才能與 FIT 協同工作。這可能意味著從邏輯上打包單個解決方案,使用一組工具或構建新的固有功能。這將首先導致更廣泛的技術能夠像 MongoDB 一樣以類似的方式對工作負載進行壓力測試,例如 Storm、Spark 和 Cassandra。將進一步研究對故障的時間和持續時間的控制。

應用領域

[編輯 | 編輯原始碼]
FIT 部署

故障注入工具開發的一個重大進步是與其他 DICE 工具的整合。這項工作將 FIT 更深入地整合到 DICE 工具集中,併為 FIT 使用者提供更多有用的功能。FIT 已完全整合的工具之一是 DICE 部署服務,由 XLAB 開發,如圖 5 所示。這項新功能允許對構成 DICE 虛擬部署容器的部署中的所有虛擬機器造成故障。此整合的工作方式是透過 FIT 的圖形介面版本。首先,使用者必須從部署服務中獲取一個令牌,以便能夠使用 API 進行身份驗證。從那裡,圖形介面上會提供一個選項來列出 DICE 部署服務上執行的所有容器。然後,使用者可以選擇他們希望在其中造成故障的容器。還可以上傳 JSON 檔案以進一步自定義要在部署中的特定虛擬機器上造成的故障型別。這是透過將故障與與虛擬機器(例如,託管在)關聯的元件型別的名稱匹配來完成的。在提供這些屬性後,所需的故障將自動在容器內的所有選定虛擬機器上引起,以模擬在應用程式級別發生的故障。這使得使用者只需為虛擬部署容器填寫一次表單,然後將相同的資訊用於容器中的所有後續(重新)部署。此外,我們在下一章中展示了 FIT 與新 dmon-gen 實用程式的整合,以自動生成異常。

此外,還有 FIT 與新 dmon-gen 實用程式的整合,以自動生成異常。使用它,我們還可以為每個實驗指定 FIT 特定的引數。例如,我們可以使用它來對給定平臺上的所有主機的 CPU 和記憶體進行壓力測試,或者使用可用資源的 50%。

正在探索整合的另一個領域是將 IeAT 開發的監控軟體與 FIT 圖形介面整合。如果可行,這將為使用者提供有關虛擬機器在造成故障之前、期間和之後效能的詳細資訊和分析。這可以更深入地瞭解 FIT 應用程式造成的故障的影響,以及虛擬機器/應用程式在模擬這些不同故障的壓力下的效能。


FIT 可以生成虛擬機器故障,供應用程式所有者和虛擬機器管理員使用。該工具旨在獨立於任何目標環境執行。

CPU 過載之前
CPU 過載期間

為了驗證 FIT 使用的影響,使用了在許多類 Unix 作業系統中發現的通用任務管理器程式“top”。在目標虛擬機器上使用 Linux 的“top”命令,可以檢視其資源的當前狀態。關於 CPU 飽和,在執行 CPU 過載故障之前,測量 %Cpu 使用率。在執行 CPU 過載時,%Cpu 會迅速上升到接近 100%。FIT 發出的壓力命令通常會佔用大約 99.2% 的可用 CPU 容量。關於記憶體飽和,FIT 的“stressmem”功能將使用指定的引數呼叫。該工具首先透過 SSH 連線到虛擬機器,並透過檢查 /etc/*-release 來確定作業系統版本(在本例中為 Ubuntu)。然後,它會尋找適合 Ubuntu 的記憶體壓力測試工具,例如 Memtester。如果該工具未找到,FIT 會先安裝該工具及其依賴項。最後,FIT 呼叫 Memtester 來使目標節點的記憶體飽和。同樣,標準監控工具(例如“top”中的 %MEM 列)將顯示虛擬機器可用的 2GB(或在 stressmem 的記憶體大小引數中指定的任何值)RAM 處於飽和狀態。使用與作業系統捆綁在一起的標準測量工具意味著使用者可以輕鬆地確保注入的故障具有預期效果。

在以下示例中,在目標虛擬機器上使用 Linux 的“top”命令,可以檢視其資源的當前狀態。在執行 CPU 過載故障之前,%Cpu 使用率為 0.7%,如圖 6 所示。在執行 CPU 過載時,%Cpu 會迅速上升到 100%。在下面的程序中,我們可以看到壓力命令正在使用 99.2% 的 CPU,如圖 7 所示。

與其他解決方案相比,FIT 的主要優勢在於它作為開源解決方案的可用性,易於與其他工具整合的命令列版本,易於非專業使用者使用的圖形介面以及記錄良好的說明。一個重要的區別因素是該工具的雲無關性,以及它在多個目標環境中一致使用的能力。未來的工作將側重於外部使用者可擴充套件性的困難和可能性,調查限制,考慮不同的拓撲、作業系統和與供應商無關的雲提供商基礎設施,以及評估操作的開銷。容器化環境也將被視為未來的 FIT 目標,以幫助瞭解在將故障注入底層主機時對微服務的影響,以及容器化部署的完整性。從長遠來看,其他目標雲 API 可以新增到 FIT 中,以及調查相關的學術工作。

參考文獻

[編輯 | 編輯原始碼]
  1. 故障注入工具
  2. [ S. Han, K. G. Shin 和 H. A. Rosenberg,“DOCTOR:用於分散式即時系統的整合軟體故障注入環境”,在國際計算機效能和可靠性研討會上發表,德國埃爾朗根,1995 年。]
  3. [ S. Dawson, F. Jahanian 和 T. Mitton,“ORCHESTRA:用於測試協議實現的探測和故障注入環境”,在國際計算機效能和可靠性研討會上發表,美國厄巴納-香檳,1996 年。]
  4. xception
  5. GridFIT
  6. LFI
  7. Memtester
  8. Apache 2.0
華夏公益教科書