重磅乾貨！蘇寧100000級伺服器規模的自動化運維實踐！
運維的演進
人力運維階段
在IT產業的早期，伺服器運維是通過各種Ad Hoc命令或者Shell腳本來完成基礎設施的自動化工作。這種方式對於簡單或一次性的工作很方便，但是對於複雜和長期的項目，後期的腳本維護非常麻煩。
自動化工具階段
現時的大型互聯網公司都已經有了成千上萬台伺服器，對於這麼龐大體量的伺服器規模，以往原始的人工運維方式顯然已經過時。大規模伺服器的自動化快速運維就成為了不得不探討的課題。
目前Salt、Chef、Puppet和Ansible等配置管理工具是運維界非常流行的工具，它們定義了各自的語法規則來管理伺服器。這些工具定義的代碼和Ad Hoc腳本語言非常相似，但是它們強制要求代碼具有結構化、一致性和清晰的參數命名，能夠遠程管理大量的伺服器，並且兼容早期的Ad hoc腳本。
DevOPS階段
隨著自動化維護的相關工具層出不窮，有些大公司已經把它上升到了戰略層面，並引入了各種各樣的自動化工具與自己的業務系統進行組裝。
自動化運維平台ACM平台的建設
從傳統業務轉型互聯網的蘇寧隨著業務量的上升，伺服器本身的標準化掃描、內核批量升級、全局變數設定等操作逐漸變得常態化，動輒上千台的主機運維的工作已經不是通過堡壘機系統就可以輕鬆完成了。
並且隨著不斷有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一樣持續活躍。
從表格中可以看出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上。
主要的配置項如下：
該方案的優點是基於SaltStack原生的高可用支持，不需別的組合方案進行支撐，理論上可以實現Master的高可用，但是經過實際的驗證和測試，存在一些明顯的不足：
Minon在啟動的時候會隨機連接一台Master，假如此時連接的Master恰好宕機，Minion不會再隨機選擇另外一台Master，從而導致連接失敗的情況。
Minion 檢測間隔，根據Master_alive_interval的設置時間，Minion會主動對現有的Master進行TCP連接一次檢查，查看Master是否響應。如果探測間隔設置過長，則可能影響到切換的時效；如果探測間隔設置過短，在大規模伺服器場景下，則在短時間內產生過多的網路請求，對Master主機以及網路帶寬產生巨大衝擊，相當於一次DDOS攻擊。
Salt-key同步沒有提供解決方案。
假如需要更換Master的IP或者追加新的Master的IP，則需要對該Master下的所有的Minon進行配置變更，更恐怖的是Minion需要重啟才能生效。
方案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已經最大支持K級伺服器的同步調用。
ACM同步簡單任務的調用平均開銷時間約200ms。
平台日均調用量已經接近40萬次。
請求成功率99.99%。
TAG:全球大搜羅 |