大規模機器集羣-基礎環境一致性

本篇講 「故障自動維修流程」裏 「環境初始化」這個環節。

 

初始化的問題—環境不一致

可能你們會以爲，環境初始化有什麼好說的，不就是跑一堆設置系統參數的腳本麼? 事實上，設置環境很容易，可是要保證環境設置正確會遇到不少問題。

 

環境不一致影響業務的case

先來看咱們對業務sre 的訪談，因「環境設置不正確」致使業務受損的case有不少，以下所示， 

• 因超線程未開啓，致使服務在流量高峯時性能不足，產生請求拒絕

• 因QoS未設置，致使跨機房查詢數據時，響應延遲飆高，大面積拖慢了了用戶訪問速度

• 因未設置ssd磁盤內核參數，致使磁盤處於低性能狀態，影響業務讀取速度

• 因網卡多隊列未正確設置，致使單個cpu被打滿，產生拒絕請求

• 因基礎agent版本不一致，影響變動、數據配送任務，產生了髒數據

• 因core pattern 未正確設置，業務程序出core打滿磁盤，拉長了止損時間

• 因環境缺失/版本不符致使業務程序依賴異常，產生請求拒絕, 如mysql/hadoop client 缺失, python/perl 版本過老

• 因內核網絡、內存參數未正確設置，致使業務出現性能顛簸問題，產生間歇性請求拒絕，排查成本高

上述case，都是因部分機器環境未正確設置致使的，也就是機器環境存在「不一致」的狀況。

 

環境不一致的緣由

爲何會不一致？咱們分析了各個業務初始化腳本集合，獲得的結論是：「硬件/系統多樣、業務需求差別化、初始化流程不統一不規範」 這3個因素綜合做用致使了「環境不一致」。

 

一、硬件/系統多樣

機器硬件不同，設置某個功能的命令是不同的。

好比開啓超線程，戴爾機器和惠普機器不同，這致使同一個功能，業務sre會寫出多個腳本, 例如 cpu_ht_dell.sh, cpu_ht_hp.sh；

一樣道理，系統發行版不同，開機啓動、參數文件位置、內核參數的設置方式有可能不同，對於同一個需求，就會存在多個腳本，長期下來，幾乎沒法維護。

 

二、業務需求差別化

不一樣的業務類型，一般會根據自身須要，調優設置各類參數。

 

如接入層機器，需設置tcp內核參數，包括緩衝區大小、擁塞窗口大小；

 

存儲層機器，需設置內核換頁、磁盤調度策略、shm參數；

 

計算密集型業務機器，需開啓超線程，QoS優先級設置爲高；

 

這些差別化的存在，使得各個業務sre小組都維護着一套本身的初始化腳本集合，很難共用、複用。

 

三、初始化流程不統1、不規範

業務sre執行初始化時，沒有統一規範，初始化的執行方式多樣(pssh/ansible/部署系統)，並且沒有強制性檢查。

因爲環境初始化失敗，不會影響服務的初期運行，只有在流量大的時候纔會出現問題，若是執行初始化的sre經驗不足或者不夠細心，這些「環境初始化失敗」的機器，也會投入使用，形成隱患。

 

 

怎麼解決不一致

在本身動手解決問題以前，咱們粗略地調研了業界的環境管理方案：puppet，存在如下問題，

• puppet管理的資源中，有file, service, yum 等, 但不包括硬件，如BIOS、超線程、網卡多隊列; 另外，關於service 這個資源，涉及到版本問題，須要和部署系統聯動，puppet彷佛沒有提供相應的功能

• puppet has its own configuration language,  puppet 經過自成體系的配置語言來聲明資源，控制任務的執行，這對咱們來講是一個很大的學習成本，咱們須要的是：低成本地使用已經存在的上百個腳本，而不是用別的語言重寫它們。

• puppet 是 C/S架構，意味着須要部署它本身的agent，在幾萬臺機器的集羣上部署一個新agent，風險性很高，須要經歷漫長的審覈、測試、運行驗證過程

 

解決思路

因此，咱們決定仍是結合自身問題來解決，分如下幾步走，

 

一、引入apply-check機制，規範初始化的執行和檢查，保證交付質量

apply-check強制要求每個初始化的執行和檢查成對出現;

apply 即對文件或內存寫入，check即對文件或內存讀出並作對比判斷，例如，

Item	Apply	Check
超線程	ipmitool raw 0x3e  0x20 0x00 0x00 0x00	cat /proc/cpuinfo  | grep -o ht | uniq

 這樣，能夠明確知道初始化是否成功。

 

二、根據機器品牌，部署硬件/BIOS/系統發行版相關命令工具

 

如圖所示，超線程的初始化apply、check腳本分別軟鏈到了相應廠商的實現腳本，這樣就能夠在執行時，無需關注機器廠商、系統的差別，直接調用，消除適配問題。

 

三、明確業務類型和初始化集合的關係

咱們引入 Pool 的概念，每一個Pool對應一個環境初始化集合，以下表所示，

Pool	超線程	網卡多隊列	QoS	Tcp參數集	Disk io參數集	…
Web	on	on	高	on	off	…
計算	on	on	高	on	off	…
存儲	off	on	高	off	on	…
通用	off	on	中	off	off	…

 

這樣，給定一臺機器，只要知道歸屬於哪一個集羣，就能經過調用相應的check來判斷這機器的環境是否正確，是否一致。

 

 

解決環境不一致問題

 

作了上述優化以後，咱們在機器重裝系統流程中增長了apply-check的邏輯，能夠保證環境必定是正確的，由於只有在全部初始化的check經過以後，系統纔會交付。

 

對於存量機器，咱們把環境不一致看成一種故障來處理，複用了硬件故障維修的流程框架。

環境不一致修復的工做流程，

1. 環境檢測: 每5分鐘發起一次環境檢測，即調用初始化的check腳本，獲取當前時刻整個集羣的環境不一致的機器列表，推送到工做流子系統

2. 安全策略: 遍歷機器列表，依次執行安全策略，過濾不符合要求的機器，獲得一個可安全執行初始化腳本的機器列表

3. 執行初始化: 根據機器所屬pool，執行相應初始化apply腳本

4. 檢查初始化：根據機器所屬pool，執行相應初始化check腳本，若是初始化正確，流程結束

5. 若是初始化不正確，那麼認爲此機器存在硬件或系統級別的故障，生成repair_host流程，本流程結束。

（故障修復流程框架的詳情請參閱 大規模機器集羣-故障自動處理(一) ）

 

經過這兩點，逐步消除存量機器的環境不一致，同時保證新交付的機器必定是正確的。

 

 

在解決基礎環境一致性問題以後，結合硬件故障自動維修，咱們獲得了一個能力，

輸入: 任何一臺機器，不論是否有故障，環境是否正確

輸出: 無硬件故障，符合業務環境需求的可用機器

 

這爲後續作機房建設，災備重建打下了基礎，下一篇會講這部份內容。

---

 

排列文字，重組感覺。

我是曲行人，平常寫碼，閒時寫點兒文字，

若是你以爲有點意思，或者有點用，能夠關注我，

我將在大腦裏的思惟原子作布朗運動時，輸出文字。

公衆號: qxren7

二維碼: