苏宁海量服务器自动化配置运维实践
運(yùn)維的演進(jìn)
人力運(yùn)維階段
在IT產(chǎn)業(yè)的早期，服務(wù)器運(yùn)維是通過各種Ad Hoc命令或者Shell腳本來完成基礎(chǔ)設(shè)施的自動(dòng)化工作，這種方式對(duì)于簡(jiǎn)單，一次性的工作很方便，但是對(duì)于復(fù)雜和長(zhǎng)期的項(xiàng)目，后期的腳本維護(hù)非常麻煩。
自動(dòng)化工具階段
現(xiàn)時(shí)的大型互聯(lián)網(wǎng)公司都已經(jīng)有了成千上萬(wàn)臺(tái)服務(wù)器，對(duì)于這么龐大體量的服務(wù)器規(guī)模，以往那種原始的人工運(yùn)維方式顯然已經(jīng)過時(shí)，大規(guī)模服務(wù)器的自動(dòng)化快速運(yùn)維就成為了不得不探討的課題。
目前Salt,Chef,Puppet和Ansible等配置管理工具是運(yùn)維界非常流行的工具，它們定義了各自的語(yǔ)法規(guī)則來管理服務(wù)器，這些工具定義的代碼和Ad Hoc腳本語(yǔ)言非常相似，但是它們強(qiáng)制要求代碼具有結(jié)構(gòu)化，一致性，和清晰的參數(shù)命名，它們能夠遠(yuǎn)程管理大量的服務(wù)器，并且兼容早期的Ad hoc 腳本。
DevOps階段
隨著自動(dòng)化維護(hù)的相關(guān)工具層出不窮，有些大公司已經(jīng)把它上升到了戰(zhàn)略層面，并引入了各種各樣的自動(dòng)化工具與自己的業(yè)務(wù)系統(tǒng)進(jìn)行組裝。
自動(dòng)化運(yùn)維平臺(tái)ACM平臺(tái)的建設(shè)
從傳統(tǒng)業(yè)務(wù)轉(zhuǎn)型互聯(lián)網(wǎng)的蘇寧隨著業(yè)務(wù)量的上升，服務(wù)器本身的標(biāo)準(zhǔn)化掃描，內(nèi)核批量升級(jí)，在備戰(zhàn)雙11大促時(shí)，運(yùn)維會(huì)接入大量系統(tǒng)擴(kuò)容，配置，全局變量設(shè)定等等操作也逐漸變得常態(tài)化，動(dòng)輒上千臺(tái)的主機(jī)運(yùn)維的工作已經(jīng)不是通過堡壘機(jī)系統(tǒng)就可以輕松完成了。
并且隨著不斷有PAAS業(yè)務(wù)系統(tǒng)提出需要各種可定制化，標(biāo)準(zhǔn)化的服務(wù)器配置管理部署接口。開發(fā)一個(gè)可以批量化配置管理服務(wù)器的通用平臺(tái)就變得迫切起來。
底層工具的選取
目前市場(chǎng)上最主流的開源工具有
Puppet/Chef/Ansible/Saltstack四種，選型時(shí)在github的熱度排名如下:
而在實(shí)際開發(fā)的選取時(shí)優(yōu)先會(huì)考慮以下兩點(diǎn)：
- 第一、語(yǔ)言的選擇（Puppet/Chef vs Ansible/Saltstack）
Puppet、Chef基于Ruby開發(fā)，Ansible、Saltstack基于Python（后期可做二次開發(fā)），所以拋棄較為老舊并且兼容性較差的Puppet和Chef - 第二、速度的選擇 (Ansible vs Saltstack)
運(yùn)維的配置管理講究的是更快更穩(wěn)，Ansible基于SSH協(xié)議傳輸數(shù)據(jù)，Saltstack使用消息隊(duì)列zeroMQ傳輸數(shù)據(jù)。
在Ansible、Saltstack的選擇中，有一些公司放棄Saltstack的主要原因是Saltstack需要安裝客戶端，在服務(wù)器有一定數(shù)量的情況下比較麻煩，而Ansible不需要安裝客戶端。但是目前的Ansible還存在以下難以解決的問題:
- 眾口難調(diào)：和業(yè)務(wù)特點(diǎn)相關(guān)的需求十分離散（有的重效率，有的看重流程的完備性，有的對(duì)易用性要求高）再加上需求方越來越多，沒有合適的通用開放性接口提供 restful API，功能交付的排隊(duì)會(huì)積壓嚴(yán)重。
- 性能差：當(dāng)需要執(zhí)行一個(gè)服務(wù)器數(shù)量級(jí)達(dá)到 K 級(jí)操作，Ansible的響應(yīng)長(zhǎng)達(dá)數(shù)十分鐘，并且還有比較高的錯(cuò)誤率。
反觀SaltStack，它結(jié)合輕量級(jí)消息隊(duì)列（ZeroMQ）與Python第三方模塊構(gòu)建。具備了配置管理、遠(yuǎn)程執(zhí)行、監(jiān)控等功能，具有以下明顯的優(yōu)勢(shì):
速度測(cè)試
從表格中可以看出Ansible和SaltStack性能測(cè)試中，測(cè)試了Ansible和SaltStack在執(zhí)行命令、分發(fā)文件、讀取文件和批量腳本執(zhí)行等自動(dòng)化運(yùn)維場(chǎng)景下的性能，由耗時(shí)數(shù)據(jù)可以看出Ansible的響應(yīng)速度比SaltStack要慢10倍左右。
經(jīng)過的綜合論證考量，最終選擇了在大規(guī)模集群下，適用性最強(qiáng)的SaltStack作為蘇寧所有服務(wù)器的基礎(chǔ)管理工具。
使用穩(wěn)定性的維護(hù)
由于早期版本的Saltstack的穩(wěn)定性不高，各種版本之間也有兼容性問題，為了保證版本升級(jí)時(shí)保持可以向下兼容，團(tuán)隊(duì)進(jìn)行大量的驗(yàn)證和測(cè)試后會(huì)把發(fā)現(xiàn)的bug向社區(qū)報(bào)告，經(jīng)過不斷的溝通與協(xié)商，最終得到社區(qū)的認(rèn)可并接受我們提出的修改建議，目前團(tuán)隊(duì)也積極的參與新版本Salt的檢證測(cè)試與維護(hù)，有力的保障底層平臺(tái)的穩(wěn)定性。
通用外部接口及WEB平臺(tái)的建設(shè)
由于Saltstack社區(qū)并沒有提供WEB管理界面，所有的操作都只能通過命令行操作，而API的調(diào)用也會(huì)暴露出用戶名密碼給外部系統(tǒng)，Master的安全性得不到保障。并且腳本的維護(hù)升級(jí)都十分的麻煩。
所以在選定底層管理工具后還需要開發(fā)一套ACM上層平臺(tái)，包裝出通用的接口對(duì)外提供服務(wù)，并且提供可視化的操作界面提供給主機(jī)運(yùn)維團(tuán)隊(duì)。
ACM提供了一套WEB系統(tǒng)供運(yùn)維管理人員進(jìn)行可視化的運(yùn)維管理。實(shí)現(xiàn)了頁(yè)面化的腳本工具定義, 作業(yè)編排，作業(yè)執(zhí)行，命令執(zhí)行，報(bào)表分析等功能。
外部系統(tǒng)則可以通過ACM開放的API接口實(shí)現(xiàn)對(duì)底層Salt的調(diào)用，從而實(shí)現(xiàn)對(duì)安裝有Salt Minion Agent的機(jī)器進(jìn)行配置管理。
并且在安全的設(shè)計(jì)上，平臺(tái)提供審計(jì)，命令黑名單，通道管理，Agent配置、用戶角色權(quán)限管理，并且僅允許授權(quán)過的外部系統(tǒng)接入ACM。
系統(tǒng)架構(gòu)的演進(jìn)
架構(gòu)1.0
早期采用Order Master + Syndic+Minion的三層架構(gòu)模式，當(dāng)時(shí)全蘇寧的OS虛機(jī)+物理服務(wù)器總數(shù)大概在1萬(wàn)左右，Salt的原生架構(gòu)還能勉強(qiáng)支撐。
但隨著集團(tuán)轉(zhuǎn)型的持續(xù)進(jìn)行，線上業(yè)務(wù)量的急速上升，大促前上線的服務(wù)器數(shù)量也以近乎每天一千臺(tái)的速度上升，接入ACM的系統(tǒng)也從僅有的兩三個(gè)，每天幾百個(gè)總請(qǐng)求量，快速上升到幾十個(gè)系統(tǒng)，一天有近萬(wàn)個(gè)配置任務(wù)；此時(shí)系統(tǒng)的問題也逐步暴露出來，比如任務(wù)返回慢，一個(gè)同步任務(wù)執(zhí)行需要5秒以上的調(diào)用時(shí)間；原生架構(gòu)下Order Master在并發(fā)任務(wù)量大時(shí)，系統(tǒng)壓力過高，任務(wù)失敗率也超過10%
團(tuán)隊(duì)每天都花費(fèi)大量時(shí)間應(yīng)對(duì)客戶苦不堪言，業(yè)務(wù)方也是經(jīng)常提出抱怨，由于業(yè)務(wù)量提升的倒逼，Salt-Minion又是集團(tuán)默認(rèn)的唯一基礎(chǔ)運(yùn)維Agent，除了我們沒有人可以承擔(dān)下自動(dòng)化配置管理的工作。于是乎ACM進(jìn)行了整個(gè)系統(tǒng)的重新設(shè)計(jì)。
架構(gòu)2.0-兩層化拆分
經(jīng)過反復(fù)研究跟論證，ACM可以改造成直接充當(dāng)Order Master的角色，對(duì)服務(wù)器發(fā)起配置任務(wù)時(shí)，ACM可以通過安裝記錄直接查詢到Minion掛載在哪臺(tái)Master上，直接對(duì)需要的Master發(fā)起調(diào)用，任務(wù)如果是多臺(tái)機(jī)器，后期也通過ACM進(jìn)行結(jié)果的聚合。
由于ACM本身就是JBoss集群，這樣做不僅解決了單臺(tái)Order Maser負(fù)擔(dān)太重的問題，還大大加快了請(qǐng)求的響應(yīng)時(shí)間，從原來的五秒+響應(yīng)提升到了毫秒級(jí)響應(yīng)，解決了原生架構(gòu)中官方必須開銷的Syndic等待時(shí)間。
架構(gòu)2.1-Salt Master的高可用化
在實(shí)際生產(chǎn)環(huán)境中如果發(fā)生了某一臺(tái)Salt Master宕機(jī)的情況，就會(huì)有約2K的機(jī)器失去控制，人工的進(jìn)行Master恢復(fù)長(zhǎng)達(dá)幾十分鐘，對(duì)于一些業(yè)務(wù)的調(diào)用是不可以接受的。
所以Master迫切的需要進(jìn)行高可用化的改造，而改造的過程中又需要解決以下幾個(gè)問題：
方案1
采用Saltstack原生的高可用方案，Mutil-Master+Failover-Minion。
Mutil-Master: Saltstack從0.16.0版本開始支持，提供Minion可以連接多Master的功能特性.
Failover-Minion: Minion定期檢測(cè)Master的可用性，當(dāng)發(fā)現(xiàn)Master不可用時(shí)，則在一定時(shí)間切換到備用Master上。
主要的配置項(xiàng)如下：
# multi-MasterMaster: - 10.27.135.188 - 10.27.135.189# 設(shè)置為failover Minion Master_type: failover # 探測(cè)Master的間隔，單位為秒Master_alive_interval: \u0026lt;seconds\u0026gt;該方案的優(yōu)點(diǎn)是基于SaltStack原生的高可用支持，不需別的組合方案進(jìn)行支撐，理論上可以實(shí)現(xiàn)Master的高可用，但是經(jīng)過實(shí)際的驗(yàn)證和測(cè)試，存在一些明顯的不足：
方案2
經(jīng)過不停實(shí)驗(yàn)，發(fā)現(xiàn)Master可以通過由Keepalived維護(hù)的VIP對(duì)外提供Salt服務(wù)，平時(shí)VIP綁定在主Master，當(dāng)主Master宕機(jī)時(shí)VIP漂移至備Master，主備Master通過lsyncd共享Salt-key文件。
**注：Keepalived軟件主要是通過VRRP協(xié)議實(shí)現(xiàn)高可用功能的。VRRP是Virtual Router RedundancyProtocol(虛擬路由器冗余協(xié)議）的縮寫，VRRP出現(xiàn)的目的就是為了解決靜態(tài)路由單點(diǎn)故障問題的，它能夠保證當(dāng)個(gè)別節(jié)點(diǎn)宕機(jī)時(shí)，整個(gè)網(wǎng)絡(luò)可以不間斷地運(yùn)行。
所以，Keepalived 一方面具有配置管理LVS的功能，同時(shí)還具有對(duì)LVS下面節(jié)點(diǎn)進(jìn)行健康檢查的功能，另一方面也可實(shí)現(xiàn)系統(tǒng)網(wǎng)絡(luò)服務(wù)的高可用功能。**
在實(shí)際運(yùn)行時(shí)，Minion會(huì)主動(dòng)向Master（VIP）發(fā)起注冊(cè)，每5分鐘檢測(cè)一次跟Master的TCP連接，如果連接被沖斷則重新發(fā)起TCP握手，建立TCP長(zhǎng)連接；當(dāng)主Master發(fā)生宕機(jī)，Keepalived檢測(cè)到后將VIP漂移至備用Master，Minion最多在5分鐘后將向備用Master的VIP發(fā)起TCP連接請(qǐng)求，并重新掛起長(zhǎng)連接，等待Master發(fā)起任務(wù)。
該方案的需要安裝額外的軟件對(duì)高可用進(jìn)行支撐，由Keepalived對(duì)Master進(jìn)行宕機(jī)檢測(cè)，由lsyncd保證Salt-key的實(shí)時(shí)同步。這樣做的好處是可以避免的方案1的諸多不足。首先，Minion端識(shí)別到的是虛擬的Master的IP地址，所以Master底層的IP地址的變化對(duì)Minion端是無感知的，Minion既不需要更改配置也不需要重啟；其次，Keepalived的檢活機(jī)制是對(duì)本網(wǎng)段內(nèi)的D類地址進(jìn)行檢測(cè)，并設(shè)置了唯一的虛擬路由ID，檢測(cè)間隔控制在5秒以內(nèi)，所以不會(huì)對(duì)集團(tuán)網(wǎng)絡(luò)造成沖擊；最后由lsyncd對(duì)Salt-key進(jìn)行同步，既保證了安全性，又避免了多個(gè)Master之間Salt-key同步的問題。
至此，通過以上的混合解決方案，成功的實(shí)現(xiàn)的Salt Master宕機(jī)自檢測(cè)自動(dòng)遷移的高可用方案，目前新港環(huán)境下的服務(wù)器已經(jīng)全部由采用高可用架構(gòu)的Salt集群接管。
總結(jié)
現(xiàn)在的ACM已經(jīng)基本滿足集團(tuán)在日常以及大促的批量規(guī)模調(diào)用。
- 目前ACM已經(jīng)最大支持K級(jí)服務(wù)器的同步調(diào)用。
- ACM同步簡(jiǎn)單任務(wù)的調(diào)用平均開銷時(shí)間約200ms。
- 平臺(tái)日均調(diào)用量已經(jīng)接近50萬(wàn)次。
- 請(qǐng)求成功率99.99%。
展望
隨著系統(tǒng)可靠性得到保障，接入系統(tǒng)和調(diào)用量將會(huì)越來越高，以后怎么應(yīng)對(duì)日均百萬(wàn)，千萬(wàn)級(jí)的任務(wù)調(diào)用也提上日程。
未來的AIOps對(duì)ACM這種基礎(chǔ)配置服務(wù)平臺(tái)也會(huì)提出的更高要求，因?yàn)楫?dāng)指揮監(jiān)測(cè)系統(tǒng)在采集決策所需的數(shù)據(jù)，做出分析、決策后，ACM則需要擔(dān)當(dāng)起執(zhí)行動(dòng)作的工具，利用自動(dòng)化腳本/命令去執(zhí)行AI大腦的決策。
目前Saltstack已經(jīng)管理了十五萬(wàn)+的服務(wù)器，當(dāng)Salt調(diào)用失敗時(shí)，?可能是因?yàn)闄C(jī)器本身宕機(jī)、防火墻限制，七層網(wǎng)絡(luò)不通、系統(tǒng)負(fù)載過高、磁盤滿了等等各種，這些原因會(huì)造成Salt調(diào)用失敗，我們希望提前對(duì)Salt故障問題作出預(yù)警，并能夠智能的定位問題和解決問題。
而目Salt在批量執(zhí)行時(shí)也有一定的概率產(chǎn)生任務(wù)結(jié)果的丟失，因?yàn)樗腥蝿?wù)的返回結(jié)果時(shí)都需要客戶端主動(dòng)推回服務(wù)器，在批量任務(wù)大時(shí)，少數(shù)機(jī)器的返回結(jié)果會(huì)丟失。
這些課題我們后續(xù)也將繼續(xù)研究，探索！
作者簡(jiǎn)介
徐洋，十年高可用Linux集群、服務(wù)器虛擬化建設(shè)經(jīng)驗(yàn)，現(xiàn)為蘇寧易購(gòu)IT總部技術(shù)經(jīng)理。擅長(zhǎng)Linux服務(wù)器故障診斷與排除，在數(shù)據(jù)同步、SHELL腳本、Linux系統(tǒng)安全等方面有深入研究，精通服務(wù)器集群配置管理的自動(dòng)化、高可用化技術(shù)。
總結(jié)
以上是生活随笔為你收集整理的苏宁海量服务器自动化配置运维实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： vue（el-button的五种类型，三
- 下一篇： java工程师项目简历_java软件工程