蘇寧海量伺服器自動化配置運維實踐
運維的演進
人力運維階段
在IT產業的早期，伺服器運維是通過各種Ad Hoc命令或者Shell指令碼來完成基礎設施的自動化工作，這種方式對於簡單，一次性的工作很方便，但是對於複雜和長期的專案，後期的指令碼維護非常麻煩。
自動化工具階段
現時的大型網際網路公司都已經有了成千上萬臺伺服器，對於這麼龐大體量的伺服器規模，以往那種原始的人工運維方式顯然已經過時，大規模伺服器的自動化快速運維就成為了不得不探討的課題。
目前Salt,Chef,Puppet和Ansible等配置管理工具是運維界非常流行的工具，它們定義了各自的語法規則來管理伺服器，這些工具定義的程式碼和Ad Hoc指令碼語言非常相似，但是它們強制要求程式碼具有結構化，一致性，和清晰的引數命名，它們能夠遠端管理大量的伺服器，並且相容早期的Ad hoc 指令碼。
DevOPS階段
隨著自動化維護的相關工具層出不窮，有些大公司已經把它上升到了戰略層面，並引入了各種各樣的自動化工具與自己的業務系統進行組裝。
自動化運維平臺ACM平臺的建設
從傳統業務轉型網際網路的蘇寧隨著業務量的上升，伺服器本身的標準化掃描，核心批量升級，在備戰雙11大促時，運維會接入大量系統擴容，配置，全域性變數設定等等操作也逐漸變得常態化，動輒上千臺的主機運維的工作已經不是通過堡壘機系統就可以輕鬆完成了。
並且隨著不斷有PAAS業務系統提出需要各種可定製化，標準化的伺服器配置管理部署介面。開發一個可以批量化配置管理伺服器的通用平臺就變得迫切起來。
底層工具的選取
目前市場上最主流的開源工具有Puppet/Chef/Ansible/Saltstack四種，選型時在github的熱度排名如下。
而在實際開發的選取時優先會考慮以下兩點：
- 第一、語言的選擇（Puppet/Chef vs Ansible/Saltstack）
Puppet、Chef基於Ruby開發，Ansible、Saltstack基於Python（後期可做二次開發），所以拋棄較為老舊並且相容性較差的Puppet和Chef
- 第二、速度的選擇 (Ansible vs Saltstack)
運維的配置管理講究的是更快更穩，Ansible基於SSH協議傳輸資料，Saltstack使用訊息佇列zeroMQ傳輸資料。
在Ansible、Saltstack的選擇中，有一些公司放棄Saltstack的主要原因是Saltstack需要安裝客戶端，在伺服器有一定數量的情況下比較麻煩，而Ansible不需要安裝客戶端。但是目前的Ansible還存在以下難以解決的問題
- 眾口難調：和業務特點相關的需求十分離散（有的重效率，有的看重流程的完備性，有的對易用性要求高）再加上需求方越來越多，沒有合適的通用開放性介面提供 restful API，功能交付的排隊會積壓嚴重。
- 效能差：當需要執行一個伺服器數量級達到 K 級操作，Ansible的響應長達數十分鐘，並且還有比較高的錯誤率。
反觀SaltStack，它結合輕量級訊息佇列（ZeroMQ）與Python第三方模組構建。具備了配置管理、遠端執行、監控等功能，具有以下明顯的優勢
- 速度極快
- 相容性好
- 文件詳細，並且開源社群跟Ansible一樣持續活躍
速度測試
| 測試項 |
場景 |
執行耗時（秒） |
成功率（成功/所有） |
||
| Salt |
Ansible |
Salt |
Ansible |
||
| 1 |
ip a命令 |
0.542 |
5.382 |
10/10 |
10/10 |
| 2 |
檔案分發（20K） |
0.672 |
5.813 |
10/10 |
10/10 |
| 3 |
檔案讀取（100K） |
0.798 |
6.231 |
10/10 |
10/10 |
| 4 |
批量腳步執行（ifconfig） |
1.231 |
8.123 |
10/10 |
10/10 |
| 5 |
多機器（30臺）指令碼執行（ifconfig） |
1.582 |
9.934 |
30/30 |
30/30 |
從表格中可以看出Ansible和SaltStack效能測試中，測試了Ansible和SaltStack在執行命令、分發檔案、讀取檔案和批量指令碼執行等自動化運維場景下的效能，由耗時資料可以看出Ansible的響應速度比SaltStack要慢10倍左右。
經過的綜合論證考量，最終選擇了在大規模叢集下，適用性最強的SaltStack作為蘇寧所有伺服器的基礎管理工具。
使用穩定性的維護
由於早期版本的Saltstack的穩定性不高，各種版本之間也有相容性問題，為了保證版本升級時保持可以向下相容，團隊進行大量的驗證和測試後會把發現的bug向社群報告，經過不斷的溝通與協商，最終得到社群的認可並接受我們提出的修改建議，目前團隊也積極的參與新版本Salt的檢證測試與維護，有力的保障底層平臺的穩定性。
通用外部介面及WEB平臺的建設
由於Saltstack社群並沒有提供WEB管理介面，所有的操作都只能通過命令列操作，而API的呼叫也會暴露出使用者名稱密碼給外部系統，Master的安全性得不到保障。並且指令碼的維護升級都十分的麻煩。
所以在選定底層管理工具後還需要開發一套ACM上層平臺，包裝出通用的介面對外提供服務，並且提供視覺化的操作介面提供給主機運維團隊。
ACM提供了一套WEB系統供運維管理人員進行視覺化的運維管理。實現了頁面化的指令碼工具定義, 作業編排，作業執行，命令執行，報表分析等功能。
外部系統則可以通過ACM開放的API介面實現對底層Salt的呼叫，從而實現對安裝有Salt Minion Agent的機器進行配置管理。
並且在安全的設計上，平臺提供審計，命令黑名單，通道管理，Agent配置、使用者角色許可權管理，並且僅允許授權過的外部系統接入ACM。
系統架構的演進
架構1.0
早期採用Order Master + Syndic+Minion的三層架構模式，當時全蘇寧的OS虛機+物理伺服器總數大概在1萬左右，Salt的原生架構還能勉強支撐。
但隨著集團轉型的持續進行，線上業務量的急速上升，大促前上線的伺服器數量也以近乎每天一千臺的速度上升，接入ACM的系統也從僅有的兩三個，每天幾百個總請求量，快速上升到幾十個系統，一天有近萬個配置任務；此時系統的問題也逐步暴露出來，比如任務返回慢，一個同步任務執行需要5秒以上的呼叫時間；原生架構下Order Master在併發任務量大時，系統壓力過高，任務失敗率也超過10%
團隊每天都花費大量時間應對客戶苦不堪言，業務方也是經常提出抱怨，由於業務量提升的倒逼，Salt-Minion又是集團預設的唯一基礎運維Agent，除了我們沒有人可以承擔下自動化配置管理的工作。於是乎ACM進行了整個系統的重新設計。
架構2.0-兩層化拆分
經過反覆研究跟論證，ACM可以改造成直接充當Order Master的角色，對伺服器發起配置任務時，ACM可以通過安裝記錄直接查詢到Minion掛載在哪臺Master上，直接對需要的Master發起呼叫，任務如果是多臺機器，後期也通過ACM進行結果的聚合。
由於ACM本身就是JBoss叢集，這樣做不僅解決了單臺Order Maser負擔太重的問題，還大大加快了請求的響應時間，從原來的五秒+響應提升到了毫秒級響應，解決了原生架構中官方必須開銷的Syndic等待時間。
架構2.1-Salt Master的高可用化
在實際生產環境中如果發生了某一臺Salt Master宕機的情況，就會有約2K的機器失去控制，人工的進行Master恢復長達幾十分鐘，對於一些業務的呼叫是不可以接受的。
所以Master迫切的需要進行高可用化的改造，而改造的過程中又需要解決以下幾個問題：
- Minion如何探測到Master宕機，並進行快速切換。
- 當Minion探測到主Master宕機後如何切換到備Master。
- 如何解決主備Master之間Salt-key複製的問題，尤其是當主Master關聯新的Minion，新Minion的Salt-key如何同步給備Master。
方案1
採用Saltstack原生的高可用方案，Mutil-Master+Failover-Minion。
Mutil-Master:Saltstack從0.16.0版本開始支援，提供Minion可以連線多Master的功能特性.
Failover-Minion: Minion定期檢測Master的可用性，當發現Master不可用時，則在一定時間切換到備用Master上。
主要的配置項如下：
# multi-Master Master: - 10.27.135.188 - 10.27.135.189 # 設定為failover Minion Master_type: failover # 探測Master的間隔，單位為秒 Master_alive_interval: <seconds>
該方案的優點是基於SaltStack原生的高可用支援，不需別的組合方案進行支撐，理論上可以實現Master的高可用，但是經過實際的驗證和測試，存在一些明顯的不足：
- Minon在啟動的時候會隨機連線一臺Master，假如此時連線的Master恰好宕機，Minion不會再隨機選擇另外一臺Master，從而導致連線失敗的情況。
- Minion 檢測間隔，根據Master_alive_interval的設定時間，Minion會主動對現有的Master進行TCP連線一次檢查，檢視Master是否響應。如果探測間隔設定過長，則可能影響到切換的時效；如果探測間隔設定過短，在大規模伺服器場景下，則在短時間內產生過多的網路請求，對Master主機以及網路頻寬產生巨大沖擊，相當於一次DDOS攻擊。
- 假如需要更換Master的IP或者追加新的Master的IP，則需要對該Master下的所有的Minon進行配置變更，更恐怖的是Minion需要重啟才能生效。
- Salt-key同步沒有提供解決方案。
方案2
經過不停實驗，發現Master可以通過由Keepalived維護的VIP對外提供Salt服務，平時VIP繫結在主Master，當主Master宕機時VIP漂移至備Master，主備Master通過lsyncd共享Salt-key檔案。
注：Keepalived軟體主要是通過VRRP協議實現高可用功能的。VRRP是Virtual Router RedundancyProtocol(虛擬路由器冗餘協議）的縮寫，VRRP出現的目的就是為了解決靜態路由單點故障問題的，它能夠保證當個別節點宕機時，整個網路可以不間斷地執行。
所以，Keepalived 一方面具有配置管理LVS的功能，同時還具有對LVS下面節點進行健康檢查的功能，另一方面也可實現系統網路服務的高可用功能。
在實際執行時，Minion會主動向Master（VIP）發起註冊，每5分鐘檢測一次跟Master的TCP連線，如果連線被沖斷則重新發起TCP握手，建立TCP長連線；當主Master發生宕機，Keepalived檢測到後將VIP漂移至備用Master，Minion最多在5分鐘後將向備用Master的VIP發起TCP連線請求，並重新掛起長連線，等待Master發起任務。
該方案的需要安裝額外的軟體對高可用進行支撐，由Keepalived對Master進行宕機檢測，由lsyncd保證Salt-key的實時同步。這樣做的好處是可以避免的方案1的諸多不足。首先，Minion端識別到的是虛擬的Master的IP地址，所以Master底層的IP地址的變化對Minion端是無感知的，Minion既不需要更改配置也不需要重啟；其次，Keepalived的檢活機制是對本網段內的D類地址進行檢測，並設定了唯一的虛擬路由ID，檢測間隔控制在5秒以內，所以不會對集團網路造成衝擊；最後由lsyncd對Salt-key進行同步，既保證了安全性，又避免了多個Master之間Salt-key同步的問題。
至此，通過以上的混合解決方案，成功的實現的Salt Master宕機自檢測自動遷移的高可用方案，目前新港環境下的伺服器已經全部由採用高可用架構的Salt叢集接管。
總結
現在的ACM已經基本滿足集團在日常以及大促的批量規模呼叫
- 目前ACM已經最大支援K級伺服器的同步呼叫
- ACM同步簡單任務的呼叫平均開銷時間約200ms。
- 平臺日均呼叫量已經接近50萬次
- 請求成功率99.99%
展望
隨著系統可靠性得到保障，接入系統和呼叫量將會越來越高，以後怎麼應對日均百萬，千萬級的任務呼叫也提上日程。
未來的AIOps對ACM這種基礎配置服務平臺也會提出的更高要求，因為當指揮監測系統在採集決策所需的資料，做出分析、決策後，ACM則需要擔當起執行動作的工具，利用自動化指令碼/命令去執行AI大腦的決策。
目前Saltstack已經管理了十五萬+的伺服器，當Salt呼叫失敗時， 可能是因為機器本身宕機、防火牆限制，七層網路不通、系統負載過高、磁碟滿了等等各種，這些原因會造成Salt呼叫失敗，我們希望提前對Salt故障問題作出預警，並能夠智慧的定位問題和解決問題。
而目Salt在批量執行時也有一定的概率產生任務結果的丟失，因為所有任務的返回結果時都需要客戶端主動推回伺服器，在批量任務大時，少數機器的返回結果會丟失。
這些課題我們後續也將繼續研究，探索！
作者簡介
徐洋，十年高可用Linux叢集、伺服器虛擬化建設經驗，現為蘇寧易購IT總部技術經理。擅長Linux伺服器故障診斷與排除，在資料同步、SHELL指令碼、Linux系統安全等方面有深入研究，精通伺服器叢集配置管理的自動化、高可用化技術。