一名運(yùn)維者的思考:云計(jì)算時(shí)代的自動(dòng)化運(yùn)維走向

發(fā)表于:2017/7/12 15:02:48??閱讀量:?[關(guān)閉]



  關(guān)于題目“云計(jì)算時(shí)代的自動(dòng)化運(yùn)維”,用通俗的話講,就是應(yīng)用的自動(dòng)化部署。

  第一個(gè)關(guān)鍵詞是自動(dòng)化,自動(dòng)化代表高速效率、低成本;第二個(gè)關(guān)鍵詞是應(yīng)用部署。即,不涉及講物理基礎(chǔ)設(shè)施的運(yùn)維(如機(jī)房基建、能源、消防、安保、布線等等)。

  假設(shè)一個(gè)企業(yè)要做一個(gè)電商網(wǎng)站,典型的運(yùn)維流程是這樣:

  1. 購(gòu)買硬件設(shè)備:服務(wù)器、交換機(jī)??赡苓€有路由器、負(fù)載均衡器、防火墻,不一一窮舉了。

  2. 在服務(wù)器上安裝操作系統(tǒng)

  3. 在服務(wù)器上安裝配置基礎(chǔ)環(huán)境(數(shù)據(jù)庫(kù)、Web服務(wù)器、搜索引擎等)

  4. 在服務(wù)器上安裝配置應(yīng)用軟件(用Java、PHP開(kāi)發(fā)的電商軟件)

  5. 把硬件設(shè)備送進(jìn)機(jī)房托管,開(kāi)通公網(wǎng)訪問(wèn)

  6. 監(jiān)控運(yùn)維中的業(yè)務(wù),并做日常備份、擴(kuò)容/縮容、遷移、升級(jí)

  如果是使用公有云,則沒(méi)有第1,2,5步,直接購(gòu)買公有云的虛擬機(jī)、容器、平臺(tái)服務(wù)(文件存儲(chǔ)、關(guān)系數(shù)據(jù)庫(kù)、內(nèi)容分發(fā)等)

  應(yīng)用環(huán)境和應(yīng)用軟件部署是指第3步和第4步。

  1 操作系統(tǒng)自動(dòng)化部署

  第2步是物理祼機(jī)的部署,現(xiàn)在市面上的主流服務(wù)器,都支持IPMI管理,通電接上管理端口就可以完成BIOS設(shè)置,再輔以DHCP, TFTP, KickStart可以實(shí)現(xiàn)無(wú)人值守的自動(dòng)化安裝操作系統(tǒng)。

  目前虛擬化、私有云、公有云已經(jīng)相當(dāng)普及,除了一些對(duì)特殊硬件有要求的場(chǎng)合,和一些歷史遺留場(chǎng)合,其它大部分場(chǎng)合都可以用虛擬機(jī),物理機(jī)上安裝的是宿主操作系統(tǒng),應(yīng)用軟件裝在虛擬機(jī)里,這樣物理祼機(jī)就只需要安裝宿主操作系統(tǒng),需求相對(duì)簡(jiǎn)單,沒(méi)有應(yīng)用部署那么復(fù)雜。裝完之后不會(huì)經(jīng)常去改動(dòng),運(yùn)行穩(wěn)定。

  2 應(yīng)用部署

  與操作系統(tǒng)部署相比,應(yīng)用部署復(fù)雜性高得多,主要表現(xiàn)在:

  · 場(chǎng)景繁多

  一個(gè)小型的B2C網(wǎng)站,有負(fù)載均衡器、Web服務(wù)器、應(yīng)用服務(wù)器、緩存服務(wù)器、搜索引擎、分布式文件系統(tǒng)、監(jiān)制中心、日志中心、VPN服務(wù)器等十多種服務(wù)器角色

  · 依賴復(fù)雜

  軟件包之間有依賴,服務(wù)器之間有通信依賴

  · 配置各異

  除標(biāo)準(zhǔn)的ini,xml, yaml, json, properties文件外,iptables, sysctl, nginx, haproxy, pptpd等都有自己獨(dú)特的配置文件格式,多達(dá)上百種。文檔描述和運(yùn)維腳本編寫都有相當(dāng)大的難度。

  3 應(yīng)用部署技術(shù)發(fā)展歷程

  下面以在CentOS上安裝nginx為例,回顧一下應(yīng)用部署技術(shù)的發(fā)展歷程:

  3.1 手工安裝配置

  這是很古老的部署方式,直到今天也被廣大小規(guī)模團(tuán)隊(duì)廣泛采用。部署過(guò)程往往會(huì)產(chǎn)生這樣一份文檔供日后參考:

一名運(yùn)維者的思考:云計(jì)算時(shí)代的自動(dòng)化運(yùn)維走向

  3.1.1 優(yōu)點(diǎn)

  3.1.1.1 靈活性高

  可以安裝任何想要的版本,啟用任何想要的模塊(包括自行開(kāi)發(fā)的私有模塊)

  3.1.1.2 學(xué)習(xí)門檻低

  文檔是自然語(yǔ)言寫成,閱讀和書寫都很簡(jiǎn)單,不需要額外學(xué)習(xí)其它技術(shù)語(yǔ)言。安裝配置用到的工具、命令也較少,主要是網(wǎng)絡(luò)下載、解壓縮、編譯、文本編輯幾種,容易掌握。

  3.1.2 缺點(diǎn)

  作為很古老的部署技術(shù),缺點(diǎn)也是顯而易見(jiàn)的:

  3.1.2.1 文檔不精確

  由于文檔是自然語(yǔ)言寫的,是寫給運(yùn)維工程師閱讀的,而不是給機(jī)器執(zhí)行的。文檔寫的是什么,跟機(jī)器上實(shí)際執(zhí)行的是什么,并不是100%一致的,需要人肉轉(zhuǎn)換。在長(zhǎng)期版本變更、人員更替中極容易出現(xiàn)疏漏。當(dāng)然,可以從行政管理上解決這類隱患。很多大公司都喜歡搞流程,用測(cè)試審核流程來(lái)督促人少犯錯(cuò)。然而,只要是這個(gè)文檔是給人看而不是給機(jī)器執(zhí)行的,這個(gè)文檔就會(huì)一直面臨筆誤、表達(dá)不精確、更新不及時(shí)等隱患,要用流程來(lái)徹底杜絕這些隱患,成本很高。

  3.1.2.2 效率低

  上述5個(gè)步驟都是串行的,須做完一步才能進(jìn)行下一步。第1步和第3步是比較耗時(shí)的,若網(wǎng)速不快,或者編譯時(shí)間太長(zhǎng),運(yùn)維工程師會(huì)浪費(fèi)時(shí)間等待。

  另一方面,若有多臺(tái)機(jī)器需要執(zhí)行同樣的部署操作,也無(wú)法減少重復(fù)性操作。

  3.2 自動(dòng)化部署:shell腳本

  若服務(wù)器稍有規(guī)模的團(tuán)隊(duì)里,上述手工部署就成了一個(gè)大問(wèn)題。

  人肉閱讀的文檔急需轉(zhuǎn)換成機(jī)器執(zhí)行的代碼。最早也是廣泛運(yùn)用的自動(dòng)化部署技術(shù)便是shell腳本。以bash為例,上述5步寫成bash shell就像這樣(示例代碼,未經(jīng)測(cè)試):

一名運(yùn)維者的思考:云計(jì)算時(shí)代的自動(dòng)化運(yùn)維走向

  直接運(yùn)行這個(gè)腳本,就可以自動(dòng)安裝配置好nginx了。

  相比手工部署,使用shell腳本的缺點(diǎn)只有兩點(diǎn):一是寫代碼需要一定學(xué)習(xí)門檻。二是維護(hù)的技術(shù)難度會(huì)略高。

  3.2.1 優(yōu)點(diǎn)

  3.2.1.1 精確

  由于shell腳本是給機(jī)器執(zhí)行的,shell腳本自身就是一份精確的可執(zhí)行的文檔,所以,不存在筆誤、表達(dá)不精確、更新不及時(shí)的問(wèn)題。

  3.2.1.2 效率高

  運(yùn)維工程師只要把腳本啟動(dòng)起來(lái)就可以做別的工作了。

  3.2.2 bash的缺點(diǎn)

  Bash是幾乎所有l(wèi)inux發(fā)行版內(nèi)置的,環(huán)境兼容性好,簡(jiǎn)潔易學(xué)。但它卻不是運(yùn)維編程的終極之選。具體來(lái)說(shuō)有兩大缺點(diǎn):

  3.2.2.1 缺少高級(jí)語(yǔ)言特性

  Bash不是一門高級(jí)編程語(yǔ)言,和Perl/Python/Ruby/PHP這些同樣可以用作shell編程的語(yǔ)言相比,缺少很多高級(jí)語(yǔ)言特性,而這些特性在運(yùn)維部署工作中會(huì)用到。

  3.2.2.1 工具鏈不豐富

  由于不支持OOP,因此沒(méi)有完整的單元測(cè)試框架。

  開(kāi)發(fā)框架、缺陷分析、性能分析工具也幾乎是一片空白。IDE支持雖有(JetBrains公司IntelliJ就有bash shell插件),但功能不多。

  3.3 自動(dòng)化部署:運(yùn)維DSL

  得益于虛擬化和公有云的快速普及,效高質(zhì)量地完成應(yīng)用部署不再是大公司專有的需求,也成了中小企業(yè)的剛需,前面分析過(guò)了,bash shell不能勝任大規(guī)模的、復(fù)雜的應(yīng)用部署,自動(dòng)化運(yùn)維編程語(yǔ)言DSL(Domain Specific Language)被發(fā)明出來(lái),puppet, chef,ansible, saltstack是其中杰出的代表。

  4 自動(dòng)化運(yùn)維技術(shù)發(fā)展趨勢(shì)展望

  4.1 部署工作代碼化

  無(wú)論是使用bash / python shell,還是使用puppet、chef等DSL,都可以完成代碼化這個(gè)過(guò)程。把手工操作變成代碼。

  使用代碼自動(dòng)化部署應(yīng)用環(huán)境和應(yīng)用,才能保證無(wú)論在辦公室測(cè)試環(huán)境,還是在機(jī)房生產(chǎn)環(huán)境,每次運(yùn)行這個(gè)部署代碼,都能得到相同的結(jié)果。這是一切自動(dòng)化部署的基礎(chǔ)。

  4.2 運(yùn)維代碼版本化

  運(yùn)維代碼要和Java,PHP等應(yīng)用代碼一樣,納入SVN、GIT代碼倉(cāng)庫(kù),執(zhí)行嚴(yán)格的開(kāi)發(fā)-測(cè)試-上線-回滾流程。

  這樣便可利用svn/git的成熟SCM功能,用于這樣一些場(chǎng)景:

  4.2.1 新建分支

  運(yùn)維代碼由1.0升級(jí)到2.0,增加了緩存層。則可以從1.0復(fù)制出一個(gè)分支出來(lái),命名為2.0,然后再在2.0的基礎(chǔ)上修改。

  4.2.2 差異比較

  若要了解1.0和2.0的運(yùn)維架構(gòu)到底發(fā)生了什么變化,執(zhí)行svn和git的diff即可查看每一行代碼的變化。

  4.2.3 歷史歸檔

  1.0版穩(wěn)定運(yùn)行了半年,升級(jí)到2.0版本,此時(shí)1.0版凍結(jié)寫請(qǐng)求,歸檔留存。2.0上線運(yùn)行一段時(shí)間,發(fā)現(xiàn)穩(wěn)定性不夠??梢詮臍w檔中找出1.0版本的部署代碼,回滾到1.0版本。

  4.3 測(cè)試環(huán)境高保真

  很多公司的測(cè)試和生產(chǎn)環(huán)境存在操作系統(tǒng)不一致、軟件版本不一致、配置項(xiàng)不一致的情況。這種不規(guī)范的運(yùn)維有兩大后果:一是bug在測(cè)試環(huán)境未能測(cè)出,導(dǎo)致線上故障;二是線上出現(xiàn)異常時(shí),測(cè)試環(huán)境不能復(fù)現(xiàn)。

  一個(gè)應(yīng)用至少有兩種環(huán)境:測(cè)試環(huán)境、生產(chǎn)環(huán)境。大一點(diǎn)的公司還會(huì)分成:開(kāi)發(fā)環(huán)境、功能測(cè)試環(huán)境、性能測(cè)試環(huán)境、預(yù)發(fā)環(huán)境、生產(chǎn)環(huán)境。這么多的環(huán)境的自動(dòng)化部署代碼,原則上應(yīng)該是90%以上都相同,只有少數(shù)地方不一樣。

  4.4 自動(dòng)化測(cè)試

  使用代碼自動(dòng)化部署完之后,服務(wù)器是否立即可用,需要測(cè)試驗(yàn)證。自動(dòng)化測(cè)試能讓整個(gè)運(yùn)維過(guò)程更加高時(shí)效。

  在應(yīng)用開(kāi)發(fā)領(lǐng)域,自動(dòng)化測(cè)試、單元測(cè)試已經(jīng)非常普及了,運(yùn)維開(kāi)發(fā)也可以做一些類似的自動(dòng)化驗(yàn)收測(cè)試工作:

  4.4.1 終端應(yīng)用測(cè)試

  模擬一個(gè)客戶端訪問(wèn)剛剛部署好的服務(wù),例如:驗(yàn)證其RESTfulAPI是否得到預(yù)期的結(jié)果。

  優(yōu)點(diǎn)是,很接近實(shí)際用戶,若此測(cè)試通過(guò),則說(shuō)明裝軟件、改配置、啟服務(wù)各項(xiàng)工作都正確。缺點(diǎn)是,若測(cè)試不通過(guò),不能立即定位出哪里出錯(cuò)了。定位問(wèn)題需借助下面更底層的測(cè)試。

  4.4.2 四層網(wǎng)絡(luò)測(cè)試

  使用nmap之類的工具檢測(cè)目標(biāo)端口是否正常響應(yīng)(包括防火墻是否放行)

  4.4.3 本機(jī)測(cè)試

  · 用yum,apt檢測(cè)包是否安裝

  · 用service status檢測(cè)守護(hù)進(jìn)程是否正常支持

  · 用ps檢測(cè)進(jìn)程是否正在運(yùn)行

  · 用ls檢測(cè)文件是否存在

  · 用grep檢查配置薦是否設(shè)置成了指定的值

  自動(dòng)化測(cè)試用例覆蓋足夠全方面,我們便有可能實(shí)現(xiàn)一臺(tái)機(jī)器從祼機(jī)到上線服務(wù)全部自動(dòng)化完成,無(wú)人值守。若沒(méi)有自動(dòng)化測(cè)試,應(yīng)用部署完成之后,仍然需要人工驗(yàn)證是否滿足上線服務(wù)的要求。

  4.5 工作流

  運(yùn)維代碼從開(kāi)發(fā)到上線發(fā)揮作用,也應(yīng)該和應(yīng)用代碼一樣遵循下面的工作流:

一名運(yùn)維者的思考:云計(jì)算時(shí)代的自動(dòng)化運(yùn)維走向

  這個(gè)流程圖只展示了基本的要求:部署到生產(chǎn)環(huán)境前須經(jīng)過(guò)測(cè)試環(huán)境驗(yàn)證。更復(fù)雜的還有代碼reivew、性能測(cè)試環(huán)境驗(yàn)證、漏洞掃描環(huán)境驗(yàn)證、預(yù)發(fā)環(huán)境驗(yàn)證,生產(chǎn)環(huán)境分批發(fā)布等環(huán)節(jié)。

  很多公司的現(xiàn)狀是運(yùn)維工程師開(kāi)兩個(gè)ssh終端,一條命令,先在本地環(huán)境跑一下看看效果,成功就拿到線上去跑了。更有甚者,不經(jīng)過(guò)本地驗(yàn)證直接到線上操作了。這主要是因?yàn)檫\(yùn)維工作沒(méi)有充分代碼化,運(yùn)維代碼沒(méi)入svn、git倉(cāng)庫(kù)。

  4.6 圖形化界面和IDE

  運(yùn)維領(lǐng)域一直都缺少通用的、高時(shí)效的圖形界面和IDE。這大約有兩個(gè)原因:

  一是需求不強(qiáng)勁。運(yùn)維編程的復(fù)雜度畢竟比應(yīng)用編程簡(jiǎn)單好幾個(gè)數(shù)量級(jí)。運(yùn)維日常工作也沒(méi)有代碼化,還有大量的人工操作,所以,運(yùn)維代碼通常像冰糖葫蘆一樣,一個(gè)個(gè)腳本雖然串在一起,但大都是個(gè)獨(dú)立的個(gè)體,沒(méi)有那么強(qiáng)的代碼組織結(jié)構(gòu)。

  二是運(yùn)維社區(qū)極客氛圍濃重。就連應(yīng)用編程領(lǐng)域也只有Java、.NET等語(yǔ)言的用戶比較偏愛(ài)IDE。在PHP、Python、Perl社區(qū),vim黨、emacs黨、sublime text黨、notepad++黨各領(lǐng)風(fēng)騷。這些黨派崇拜的編輯器不同,但有一個(gè)共同信仰:不依賴IDE寫代碼是一個(gè)優(yōu)秀程序員的必備素質(zhì)。

  關(guān)于這個(gè)問(wèn)題,我是這樣認(rèn)為的,有高科技能提升編程生活質(zhì)量,為什么不用用?即使puppet、chef把運(yùn)維編程體驗(yàn)做到這么好了,我仍然期待運(yùn)維業(yè)界涌現(xiàn)一批Eclipse、AdobeFlash這樣的圖形界面、IDE。讓IDE的高效易用和運(yùn)維的命令行操作相得益彰。

  4.7 運(yùn)維代碼分治

  運(yùn)維界有一句祖訓(xùn):沒(méi)有折騰,就沒(méi)有故障。

  但為了快速響應(yīng)業(yè)務(wù)需求和提高資源利用率,運(yùn)維又不得不頻繁折騰。有沒(méi)有什么辦法能打破“折騰越多、故障越多”的魔咒?有,分而治之。

  分治,就是把風(fēng)險(xiǎn)高的和風(fēng)險(xiǎn)低的分開(kāi)、重要性高的和不高的分開(kāi)、簡(jiǎn)單的和復(fù)雜的分開(kāi)、頻繁變動(dòng)的和不頻繁的分開(kāi)。應(yīng)用編程領(lǐng)域,大家積極探索和實(shí)踐的各種架構(gòu)、框架、模式,歸根到底都在做兩件事:封裝復(fù)雜度、隔離變化。

  運(yùn)維架構(gòu)層的分治,在業(yè)界已經(jīng)非常普遍了,比如應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器分離、交易數(shù)據(jù)庫(kù)和用戶數(shù)據(jù)庫(kù)分離;生產(chǎn)環(huán)境和測(cè)試環(huán)境隔絕。

  4.7.1 配置項(xiàng)和邏輯代碼分開(kāi)

  其實(shí)業(yè)界早就在這么做了,puppet的hiera和saltstack的pillar都是做這個(gè)用的。

  有些運(yùn)維變更,可能只改變了配置項(xiàng)的值,而并沒(méi)改變運(yùn)維代碼里的業(yè)務(wù)邏輯、流程控制。如果只改配置文件,不改運(yùn)維腳本。發(fā)布風(fēng)險(xiǎn)就低了很多,起碼不會(huì)導(dǎo)致語(yǔ)法錯(cuò)誤。

  4.7.2 會(huì)變動(dòng)的配置項(xiàng)獨(dú)立

  就像應(yīng)用開(kāi)發(fā)領(lǐng)域里的模板引擎一樣,把配置文件寫成模板,模板中包含變量,運(yùn)維工具或者運(yùn)維平臺(tái)解析模板內(nèi)容,把變量替換成真實(shí)的值。

  4.7.3 服務(wù)發(fā)現(xiàn)

  將會(huì)變動(dòng)的配置項(xiàng)獨(dú)立出來(lái)動(dòng)態(tài)維護(hù),還可以實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)。以haproxy + etcd + confd為例:

  confd就是一個(gè)模板引擎,類似Java里有Velocity和Python里的jinja。不同之處是:confd還有自動(dòng)輪詢etcd的能力。使用confd解析和管理haproxy的配置文件,摘錄如下:

一名運(yùn)維者的思考:云計(jì)算時(shí)代的自動(dòng)化運(yùn)維走向

  跟原生的haproxy配置文件不同,最后三行是confd模板。

  etcd是一個(gè)KV存儲(chǔ),類似memcached,不同之處是etcd生來(lái)就是分布式的,自帶高可用和負(fù)載均衡的基因,同時(shí)還有HTTPRESTful API,存取方便。使用etcd存儲(chǔ)后端服務(wù)器列表。

  當(dāng)后端有一臺(tái)nginx服務(wù)啟動(dòng)的時(shí)候,調(diào)etcd的api把這臺(tái)機(jī)器的ip地址寫入etcd上的列表。confd輪詢etcd時(shí)查到這臺(tái)新加入的機(jī)器,便會(huì)自己把它加進(jìn)haproxy的backend server里。

  這樣便實(shí)現(xiàn)了負(fù)載均衡集群自動(dòng)化擴(kuò)容,下線一臺(tái)nginx機(jī)器亦同此理,先調(diào)etcd的api刪除某臺(tái)機(jī)器,過(guò)一分鐘在這臺(tái)nginx上檢測(cè)不到流量了再把它下線。

  擴(kuò)容過(guò)程中沒(méi)有修改haproxy的配置,也沒(méi)有部署haproxy。只是調(diào)用了etcd的RESTfulAPI,這個(gè)風(fēng)險(xiǎn)就比修改haproxy配置文件再部署上線小多了。

  4.8 整合基礎(chǔ)設(shè)施API

  所有的公有云廠商都提供了HTTPOpenAPI,包括國(guó)外的aws、azure、gce和國(guó)內(nèi)的阿里云、Ucloud、青云。

  市場(chǎng)占有率排名靠前的虛擬化軟件商也都有HTTPOpenAPI,包括:VMware、Hyper-V、XenServer、OpenStack。

  因此技術(shù)上有可能把基礎(chǔ)設(shè)施提供商的API整合進(jìn)來(lái),實(shí)現(xiàn)虛擬機(jī)創(chuàng)建、啟動(dòng)、安裝操作系統(tǒng)、聯(lián)網(wǎng)、執(zhí)行命令、關(guān)機(jī)、銷毀全生命周期的自動(dòng)化。

  和應(yīng)用部署腳本不同,調(diào)用云廠商的API不能由DSL腳本完成,用bash shell來(lái)做也非常不方便。應(yīng)該用PHP、Java之類的應(yīng)用編程語(yǔ)言寫一個(gè)應(yīng)用來(lái)做。

  至此,虛擬機(jī)和操作系統(tǒng)初始化、應(yīng)用環(huán)境部署、應(yīng)用軟件部署全部都實(shí)現(xiàn)了自動(dòng)化,便可以從零創(chuàng)建一臺(tái)可上線服務(wù)的機(jī)器。

  4.9 跨廠商跨城市故障轉(zhuǎn)移

  實(shí)現(xiàn)了部署工作代碼化和基礎(chǔ)設(shè)施API整合之后,便可以自由地跨廠商、跨城市遷移:在不同的機(jī)房維持兩份相同的數(shù)據(jù),每分鐘同步。當(dāng)基礎(chǔ)設(shè)施發(fā)生重大故障難以在短時(shí)間內(nèi)恢復(fù)時(shí),可以迅速在另外一個(gè)有數(shù)據(jù)的機(jī)房將整套應(yīng)用自動(dòng)化部署起來(lái)。

  4.10 彈性伸縮

  幾乎每一個(gè)給人類訪問(wèn)的網(wǎng)站,其服務(wù)器資源利用率都是存在明顯峰谷的:

  · 有的尖峰是一年出現(xiàn)一次,典型的例子是阿里的雙十一。每年11月11日,電商狂歡。大賣家的進(jìn)銷存系統(tǒng)、淘寶生態(tài)鏈上的SaaS服務(wù)商(如在線打印快遞單、發(fā)送短信券碼、物流跟蹤)的系統(tǒng)壓力也跟著猛漲1-2個(gè)數(shù)量級(jí)。他們投資擴(kuò)容的硬件設(shè)備,只有這一天才能充分利用,平時(shí)利用率極低。

  · 有的尖峰是一天出現(xiàn)一次或者多次,比如唯品會(huì)、聚劃算的10點(diǎn)秒殺?;久恳粋€(gè)電商都一天多波次的秒殺、搶購(gòu)。

  · 更普遍的是白天高峰、凌晨到清晨低谷。

  自動(dòng)化運(yùn)維(包括自動(dòng)購(gòu)買分配虛擬機(jī)、自動(dòng)部署應(yīng)用環(huán)境、自動(dòng)部署應(yīng)用軟件、自動(dòng)測(cè)試)使按需調(diào)度計(jì)算資源成為了可能。實(shí)時(shí)的彈性伸縮,意味著每天、甚至每分鐘都在做擴(kuò)容、縮容,這須要靠自動(dòng)化運(yùn)維實(shí)現(xiàn)。

  4.10.1 公有云上的按需采購(gòu)

  主流的公有云計(jì)費(fèi)粒度都已經(jīng)細(xì)到小時(shí)(aws、阿里云、Ucloud),有的做到了按分鐘(azure、gce),甚至還有按秒計(jì)費(fèi)的(青云)。

  對(duì)出現(xiàn)頻率較低、計(jì)劃中的尖峰,人工干預(yù),提前做好擴(kuò)容和縮容預(yù)案,以雙十一為例,人工設(shè)定好11月10日購(gòu)買一批按小時(shí)計(jì)費(fèi)的機(jī)器(不是包年包月),到了11月15日釋放這些機(jī)器,廠商會(huì)停止計(jì)費(fèi)。

  對(duì)出現(xiàn)頻率高的尖峰,運(yùn)維平臺(tái)智能調(diào)度,比如每5秒采樣系統(tǒng)資源利用率,達(dá)到指定的擴(kuò)容閾值就自動(dòng)買機(jī)器并自動(dòng)化部署、測(cè)試、上線服務(wù),低于指定的回收閾值就自動(dòng)下線服務(wù)器、通知廠商停止計(jì)費(fèi)。這種適用于部署上線時(shí)間極短的服務(wù),特別是無(wú)狀態(tài)、無(wú)用戶數(shù)據(jù)的應(yīng)用服務(wù)器。若需要較長(zhǎng)的預(yù)熱時(shí)間(如數(shù)據(jù)庫(kù)、緩存、搜索引擎),則需要提前擴(kuò)容,這就要根據(jù)歷史性能曲線做智能預(yù)測(cè)了。

  按需購(gòu)買對(duì)公有云廠商也有積極意義:

  · 從宏觀角度講,用多少買多少,杜絕浪費(fèi),提升了全球公有云資源池中的資源利用率,任何提升資源利用率的事情都是有積極正面的。

  · 從經(jīng)濟(jì)角度講,公有云按小時(shí)售賣的機(jī)器單價(jià)比包年的貴,如果兩種售賣方式都能100%把機(jī)器賣出去,按小時(shí)計(jì)費(fèi)的總收入更高。

  · 目前有的公有云廠商已經(jīng)出現(xiàn)部分機(jī)房物理資源售罄的情況。如果提供實(shí)時(shí)服務(wù)(如電商、支付、新聞、社交)的客戶都按需采購(gòu),就有可能在閑時(shí)把資源釋放出來(lái)給實(shí)時(shí)性要求不高的客戶(如離線大數(shù)據(jù)處理、動(dòng)畫渲染)使用。

  4.10.2 私有云的業(yè)務(wù)間調(diào)配

  已經(jīng)投資購(gòu)置大量硬件的企業(yè),可以在不同內(nèi)部業(yè)務(wù)之間調(diào)度,比如白天把大多數(shù)機(jī)器用來(lái)為消費(fèi)者提供服務(wù),晚上縮減承擔(dān)消費(fèi)者請(qǐng)求的機(jī)器規(guī)模,釋放出來(lái)的計(jì)算資源用來(lái)做大數(shù)據(jù)處理。

 



本文鏈接:一名運(yùn)維者的思考:云計(jì)算時(shí)代的自動(dòng)化運(yùn)維走向