隨着阿里大數據產品業務的增加,服務器數量不斷增多,IT運維壓力也成比例增大。各類軟、硬件故障而形成的業務中斷,成爲穩定性影響的重要因素之一。本文詳細解讀阿里如何實現硬件故障預測、服務器自動下線、服務自愈以及集羣的自平衡重建,真正在影響業務以前實現硬件故障自動閉環策略,對於常見的硬件故障無需人工干預便可自動閉環解決。ios
1.1.面臨挑戰數據庫
對於承載阿里巴巴集團95%數據存儲及計算的離線計算平臺MaxCompute,隨着業務增加,服務器規模已達到數十萬臺,而離線做業的特性致使硬件故障不容易在軟件層面被發現,同時集團統一的硬件報障閾值經常會遺漏一些對應用有影響的硬件故障,對於每一塊兒漏報,都對集羣的穩定性構成極大的挑戰。服務器
針對挑戰,咱們面對兩個問題:硬件故障的及時發現與故障機的業務遷移。下面咱們會圍繞這兩個問題進行分析,並詳細介紹落地的自動化硬件自愈平臺——DAM。在介紹以前咱們先了解下飛天操做系統的應用管理體系——天基(Tianji)。架構
1.2.天基應用管理運維
MaxCompute是構建在阿里數據中心操做系統——飛天(Apsara)之上,飛天的全部應用均由天基管理。天基是一套自動化數據中心管理系統,管理數據中心中的硬件生命週期與各種靜態資源(程序、配置、操做系統鏡像、數據等)。而咱們的硬件自愈體系正是與天基緊密結合,利用天基的Healing機制構建面向複雜業務的硬件故障發現、自愈維修閉環體系。分佈式
透過天基,咱們能夠將各類物理機的指令(重啓、重裝、維修)下發,天基會將其翻譯給這臺物理機上每一個應用,由應用根據自身業務特性及自愈場景決策如何響應指令。工具
2.1.如何發現性能
咱們所關注的硬件問題主要包含:硬盤、內存、CPU、網卡電源等,下面列舉對於常見硬件問題發現的一些手段和主要工具:大數據
在全部硬件故障中,硬盤故障佔比50%以上,下面分析一下最多見的一類故障:硬盤媒介故障。一般這個問題表象就是文件讀寫失敗/卡住/慢。但讀寫問題卻不必定是媒介故障產生,因此咱們有必要說明一下媒介故障的在各層的表象。阿里雲
a. 系統日誌報錯是指在/var/log/messages中可以找到相似下面這樣的報錯
Sep 3 13:43:22 host1.a1 kernel: : [14809594.557970] sd 6:0:11:0: [sdl] Sense Key : Medium Error [current]
Sep 3 20:39:56 host1.a1 kernel: : [61959097.553029] Buffer I/O error on device sdi1, logical block 796203507
b. tsar io指標變化是指rs/ws/await/svctm/util等這些指標的變化或突變,因爲報錯期間會引發讀寫的停頓,因此一般會體如今iostat上,繼而被採集到tsar中。
c. 系統指標變化一般也因爲io變化引發,好比D住引發load升高等。
d. smart值跳變具體是指197(Current_Pending_Sector)/5(Reallocated_Sector_Ct)的跳變。這兩個值和讀寫異常的關係是:
總結下來,在整條報錯鏈路中,只觀察一個階段是不夠的,須要多個階段綜合分析來證實硬件問題。因爲咱們能夠嚴格證實媒介故障,咱們也能夠反向推導,當存在未知問題的時候能迅速地區分出是軟件仍是硬件問題。
上述的工具是結合運維經驗和故障場景沉澱出來,同時咱們也深知單純的一個發現源是遠遠不夠的,所以咱們也引入了其餘的硬件故障發現源,將多種檢查手段結合到一塊兒來最終確診硬件故障。
2.2.如何收斂
上一章節提到的不少工具和路徑用來發現硬件故障,但並非每次發現都必定報故障,咱們進行硬件問題收斂的時候,保持了下面幾個原則:
2.3.覆蓋率
以某生產集羣,在20xx年x月的IDC工單爲例,硬件故障及工單統計以下:
去除帶外故障的問題,咱們的硬件故障發現佔比爲97.6%。
3.1 自愈流程
針對每臺機器的硬件問題,咱們會開一個自動輪轉工單來跟進,當前存在兩套自愈流程:【帶應用維修流程】和【無應用維修流程】,前者針對的是可熱拔插的硬盤故障,後者是針對餘下全部的整機維修硬件故障。
在咱們的自動化流程中,有幾個比較巧妙的設計:
a. 無盤診斷
b. 影響面判斷/影響升級
c. 未知問題自動化兜底
d. 宕機分析
3.2.流程統計分析
若是是一樣的硬件問題反覆觸發自愈,那麼在流程工單的統計,可以發現問題。例如聯想RD640的虛擬串口問題,在還未定位出根因前,咱們就經過統計發現了:同個機型的機器存在反覆宕機自愈的狀況,即便機器重裝以後,問題也仍是會出現。接下來咱們就隔離了這批機器,保障集羣穩定的同時,爲調查爭取時間。
3.3.業務關聯誤區
事實上,有了上面這套完整的自愈體系以後,某些業務上/kernel上/軟件上須要處理的問題,也能夠進入這個自愈體系,而後走未知問題這個分支。其實硬件自愈解決業務問題,有點飲鴆止渴,容易使愈來愈多還沒想清楚的問題,嘗試經過這種方式來解決兜底。
當前咱們逐步地移除對於非硬件問題的處理,迴歸面向硬件自愈的場景(面向軟件的通用自愈也有系統在承載,這類場景與業務的耦合性較大,沒法面向集團通用化),這樣也更利於軟硬件問題分類和未知問題發現。
4.1.雲化
最第一版本的自愈架構是在每一個集羣的控制機上實現,由於一開始時候運維同窗也是在控制機上處理各類問題。但隨着自動化地不斷深刻,發現這樣的架構嚴重阻礙了數據的開放。因而咱們採用中心化架構進行了一次重構,但中心化架構又會遇到海量數據的處理問題,單純幾個服務端根本處理不過來。
所以咱們對系統進一步進行分佈式服務化的重構,以支撐海量業務場景,將架構中的各個模塊進行拆解,引入了 阿里雲日誌服務(sls)/阿里雲流計算(blink)/阿里雲分析數據庫(ads) 三大神器,將各個採集分析任務由雲產品分擔,服務端只留最核心的硬件故障分析和決策功能。
下面是DAM1與DAM3的架構對比
4.2.數據化
隨着自愈體系的不斷深刻,各階段的數據也有了穩定的產出,針對這些數據的更高維分析,能讓咱們發現更多有價值且明確的信息。同時,咱們也將高維的分析結果進行降維,採用健康分給每臺機器打標。經過健康分,運維的同窗能夠快速知曉單臺機器、某個機櫃、某個集羣的硬件狀況。
4.3.服務化
基於對全鏈路數據的掌控,咱們將整個故障自愈體系,做爲一個硬件全生命週期標準化服務,提供給不一樣的產品線。基於對決策的充分抽象,自愈體系提供各種感知閾值,支持不一樣產品線的定製,造成適合個性化的全生命週期服務。
在AIOps的感知、決策、執行閉環體系中,軟件/硬件的故障自愈是最多見的應用場景,行業中你們也都選擇故障自愈做爲首個AIOps落地點。在咱們看來,提供一套通用的故障自愈閉環體系是實現AIOps、乃至NoOps(無人值守運維)的基石,應對海量系統運維,智能自愈閉環體系尤其重要。
5.1.必要性
在一個複雜的分佈式系統中,各類架構間不可避免地會出現運行上的衝突,而這些衝突的本質就在於信息不對稱。而信息不對稱的緣由是,每種分佈式軟件架構在設計都是內斂閉環的。如今,經過各類機制各類運維工具,能夠抹平這些衝突,然而這種方式就像是在打補丁,伴隨着架構的不斷升級,補丁彷佛一直都打不完,並且越打越多。所以,咱們有必要將這個行爲抽象成自愈這樣一個行爲,在架構層面顯式地聲明這個行爲,讓各軟件參與到自愈的整個流程中,將本來的衝突經過這種方式轉化爲協同。
當前咱們圍繞運維場景中最大的衝突點:硬件與軟件衝突,進行架構和產品設計,經過自愈的方式提高複雜的分佈式系統的總體魯棒性。
5.2.普適性
透過大量機器的硬件自愈輪轉,咱們發現:
所以,自愈其實是在複雜的分佈式系統上,將運維自動化進行充分抽象後,再構築一層閉環的架構,使得架構生態造成更大的協調統一。
本文做者:鍾炯恩
本文來自雲棲社區合做夥伴「阿里技術」,如需轉載請聯繫原做者。