《細說自動化運維的前世今生》要點：
本文介紹了細說自動化運維的前世今生，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者介紹：
朱祥磊,山東移動BOSS系統(tǒng)架構師,負責業(yè)務支撐系統(tǒng)架構規(guī)劃和建設.獲國家級創(chuàng)新獎1項、通信行業(yè)級科技進步獎2項、移動集團級業(yè)務服務創(chuàng)新獎3項,申請發(fā)明專利13項.

系統(tǒng)規(guī)模的不斷發(fā)展以及應用軟件架構的發(fā)展,推動著自動化運維的演進.因此在說自動化運維之前,需要先說說應用軟件架構的發(fā)展簡史.回顧過去,應用軟件架構先后經(jīng)過了單塊架構、多層架構、服務化架構、分布式、微服務架構等：

單塊架構

應用軟件發(fā)展早期,系統(tǒng)規(guī)模一般很小,特點是應用功能集中、代碼和數(shù)據(jù)中心化,表現(xiàn)為一個軟件發(fā)布包,集中部署,各模塊運行在同一個進程的應用程序.此時一般幾臺機器就可以完成全部應用軟件功能.

以Web應用程序為例,在Web應用程序開發(fā)的早期,由于受到面向過程的思維及設計方式的影響,所有的邏輯代碼并沒有明顯的區(qū)分,因此代碼之間的調(diào)用相互交錯,錯綜復雜.譬如,我們早期使用的ASP、JSP以及PHP,都是將所有的頁面邏輯、業(yè)務邏輯以及數(shù)據(jù)庫訪問邏輯放在一起,這是我們通常提到的單塊架構.

在這種架構下,所需的機器數(shù)量很小,完全的scale-up模式,據(jù)說IBM公司在上世紀50年代曾經(jīng)宣稱, 全世界只需要5臺計算機就夠了!

多層架構

為了解決單塊架構擴展性差的問題,同時解決代碼集中帶來的并行開發(fā)測試困難等問題,逐步出現(xiàn)了多層架構,把表示層、業(yè)務邏輯層、數(shù)據(jù)訪問層適當分離,分別打包部署.如通過實現(xiàn)Model-View-Controller的模式將數(shù)據(jù)、業(yè)務、展現(xiàn)進行分離.還有一種RPC架構,通過遠程過程調(diào)用實現(xiàn)應用架構分離.

此時每層都獨立打包,獨立部署于容器和單獨的服務器中,應用結構更加復雜但也更加清晰,當然所需的服務器數(shù)量就進一步增加了.

服務化架構

多層架構盡管大幅提升了應用的擴展性,但是隨著軟件和系統(tǒng)規(guī)模的不斷擴大,垂直應用越來越多,應用之間交互不可避免,此時層間應用接口變得越來越龐大,最終會變得難以管理.通過將核心業(yè)務抽取出來,作為獨立的服務,逐漸形成穩(wěn)定的服務中心,使前端應用能更快速地相應多變的市場需求,也使不同服務的獨立擴展成為可能.

在這種模式下,可以按服務進一步拆分部署,應用可以擴展到更多的機器和容器上.

分布式云化架構

隨著業(yè)務不斷發(fā)展,硬件成本的下降,基于X86架構的廉價硬件+分布式軟件的模式日趨成熟,得到了大規(guī)模應用,分布式服務框架逐漸替代傳統(tǒng)的服務化架構,解決了傳統(tǒng)服務化的弊端,例如企業(yè)集成總線ESB是實體總線,性能線性擴展能力有限,硬件負載均衡器的壓力越來越大,不斷擴容導致硬件成本增加,隨著業(yè)務規(guī)模的不斷增長,傳統(tǒng)的數(shù)據(jù)庫、配置中心等逐漸成為單點瓶頸.當然應用也徹底變?yōu)榱藄cale-out架構,導致機器和容器數(shù)量大幅上升.

微服務架構

微服務架構是對上面分布式云化架構的拓展、服務化的進一步延伸,通過對服務進一步細化,形成微服務,運行于單獨的容器平臺,可實現(xiàn)云的彈性和敏捷,如彈性伸縮、線上線下一致的環(huán)境、提升自動化運維能力等.

別著急,下面再允許我介紹下自動化運維的內(nèi)容,究竟包含哪些內(nèi)容?

1、硬件和網(wǎng)絡的自動管理

2、云化、虛擬機的自動管理

3、操作系統(tǒng)和軟件的自動化安裝、配置

4、常規(guī)任務(健康檢查、安全加固和檢查、備份、清理、數(shù)據(jù)管理、彈性伸縮等)

5、手工任務(容災切換、應急操作、應用部署和起停……)

6、監(jiān)控

7、問題診斷

8、可視化

其中1、2、3主要是傳統(tǒng)IaaS層關注的工作內(nèi)容,重點是計算、存儲、網(wǎng)絡的自動化管理,4到8主要是PaaS層關注的工作內(nèi)容,IaaS層和PaaS層相互結合,共同完成自動化運維.

好了,終于到正題了,自動化運維前世今生來了…..

1、史前時代：此時系統(tǒng)規(guī)模很小,一般幾臺,不超過幾十臺,此時一般通過手工單臺登錄即可滿足運維要求.
2、中世紀時代(集中管理階段)：系統(tǒng)規(guī)模有了較大擴展,從幾十臺到上百臺,此時再通過手工方式已經(jīng)無法進行,于是出現(xiàn)了各種Shell腳本,通過腳本實現(xiàn)相關的運維,腳本僅僅是針對特定的場景,難以實現(xiàn)全流程的自動化.
3、中世紀拓展(集中管理的進階)：為了方便管理以及可視化,出現(xiàn)了各類商用或開源工具軟件實現(xiàn)自動化運維,如HP Openview、puppet、SaltStack、Chef等等,做為腳本方式的提升.
4、新時代：系統(tǒng)規(guī)模進一步擴大,從上百臺演進到上千上萬臺,以前的方式由于存在弊端,如缺乏統(tǒng)一的CMDB或太簡單、不支持復雜環(huán)境、缺乏友好的可視化界面等,難以滿足要求,此時又出現(xiàn)了幾個分枝：
分枝一：從底向上的云平臺方案：通過云管理平臺實現(xiàn)計算、網(wǎng)絡、存儲的IaaS層自動化管理,同步建立軟件PaaS層自動管理,最終實現(xiàn)融合.
分枝二：從上向下的云平臺方案：通過上層PaaS層自動化管理,逐步向下探索,如容器等.

新生代自動化運維初探

下面重點介紹幾個自動化運維工具或平臺：

Openstack

Openstack是IaaS層目前最活躍的一個開源的云計算 IaaS 平臺,即云操作系統(tǒng),類似于AWS(亞馬遜的云服務),通過各種開源組件實現(xiàn)了不同功能,目前大部分云管理平臺均基于Openstack實現(xiàn)計算、網(wǎng)絡、存儲的統(tǒng)一管理,Openstack支持如下功能組件：

計算服務(Nova)：按需提供計算資源,創(chuàng)建和管理批量虛擬機 ,動態(tài)虛擬機管理：創(chuàng)建、重啟、調(diào)整大小、遷移等.
對象存儲服務(Swift)：基于普通硬件的大規(guī)模存儲,無中心節(jié)點,分布式存儲、水平擴展,同時多數(shù)據(jù)備份,保證安全,通過API接口對外訪問.
塊存儲服務(Cinder)：為虛擬機提供云硬盤.
網(wǎng)絡服務(Neutron)：為虛擬機提供網(wǎng)絡訪問能力.
編排服務(Heat)：提供自動化部署及管理服務.
數(shù)據(jù)庫服務(Trove)：提供數(shù)據(jù)庫管理服務.
認證服務(Keystone)：提供身份認證機制服務.
鏡像服務(Glance)：提供虛擬機鏡像存儲服務.
監(jiān)控服務(Ceilometer)：提供計量與監(jiān)控服務.
Dashboard(Horizon)：自服務、權限、圖形化界面.

Openstack盡管對IaaS層的自動化管理比較強大,但仍然需要注意如下幾點：

1、Openstack版本眾多,如何選擇是一個難題.

例如存在社區(qū)版、發(fā)行版、商業(yè)公司定制版本等,如何選擇是一個難題,而且Openstack每半年一個穩(wěn)定版本,演進很快.一般認為對Openstack項目中的開源代碼進行修改定制是個不錯的主意,但這從長期角度來看不一定最佳.“定制云”很可能需要付出高昂的代價,不僅投資巨大、成本高昂,企業(yè)用戶還將被迫面對一大堆后續(xù)的管理及維護開銷,并被綁定在單一供應商或版本身上.

建議企業(yè)如果有很強的技術能力的話,可以根據(jù)自己的需求做定制,但需要把握好和社區(qū)發(fā)展的關系. 一般來說,需要根據(jù)自己的需求,選擇合適的版本,盡量不改變社區(qū)版本,定制化需求盡量在外圍進行改動.如果采用了廠商的版本,實際上也是某種綁定,可能離社區(qū)越來越遠.

2、需要慎重選擇相關組件合功能

由于Openstack理念是分布式、最終一致性,因此所有的原始功能組件都是基于這一設計,企業(yè)用戶考慮采納Openstack之前,必須對企業(yè)業(yè)務應用進行分析：應用程序是否有可擴展性和彈性伸縮的要求? 應用程序是否可以接受最終一致性? 應用程序是否無狀態(tài)化? 應用程序的性能要求?應用程序的可靠性要求? 應用程序的安全要求? 應用程序的容災備份需求? 不同的要求決定了Openstack不同的計算、存儲、網(wǎng)絡等模塊設計.

3、Openstack對PaaS層和物理機管理較弱,需借助其他工具實現(xiàn)

Openstack已經(jīng)能夠支持很多的IaaS自動化運維和部分PaaS自動化運維任務,但不能滿足全部,如批量運維、深入監(jiān)控、軟件管理等功能缺少,特別是對物理機運維較弱,一般需要結合其他PaaS層管理進一步完善自動化運維體系.

SaltStack+定制

PaaS層自動化運維工具就太多了,例如監(jiān)控就有Nagios、Ganglia、Zabbix等,運維工具則有Puppet、Chef、SaltStack、Ansible等,不同企業(yè)根據(jù)企業(yè)自身開發(fā)實力、結合配置管理工具的資源豐富程度、依賴復雜程度考慮,會有不同的選擇.通過對運維工具本身的研究,結合運維人員的運維經(jīng)驗和評估企業(yè)未來的規(guī)模,下面以開源SaltStack+定制實現(xiàn)的方案進行介紹.

SaltStack是繼 Puppet、Chef 之后新出現(xiàn)的S配置管理及遠程執(zhí)行工具,與 Puppet 相比,SaltStack較為輕量；不像 Puppet有一套自己的 DSL 用來寫配置,SaltStack 使用 YAML 作為配置文件格式,相對簡單,同時也便于動態(tài)生成；此外,SaltStack 在遠程執(zhí)行命令時的速度快,由于使用了ZeroMQ,這個下發(fā)過程可以并行執(zhí)行,速度比Ansible的無agent ssh通信快得多,是一個分布式遠程執(zhí)行系統(tǒng),用來在遠程節(jié)點(可以是單個節(jié)點,也可以是任意規(guī)則挑選出來的節(jié)點)上執(zhí)行命令和查詢數(shù)據(jù).

從部署結構上看,SaltStack的在部署上可以分為master和minion兩個部分,其中master相當于統(tǒng)領所有機器的總管,而minion則是部署在被管理機器上面的agent進程,master通過網(wǎng)絡將配置管理相關的操作下發(fā)到minion,由minion在對應機器的本地執(zhí)行.典型的部署例子如下圖所示：

在現(xiàn)實生產(chǎn)環(huán)境中,大批量的用戶創(chuàng)建需求,文件上傳需求、配置變更需求、軟件升級需求占用了維護人員大量的時間,引入SaltStack后,該工具的遠程執(zhí)行和配置管理可以解決該問題,真正實現(xiàn)批量化和自動化,滿足海量運維的需求.

容器

有了Openstack和SaltStack為代表的的PaaS層自動化工具還不夠,針對應用自動化運維場景,如彈性伸縮、DevOps(開發(fā)運維一體化、開發(fā)測試一致的環(huán)境、自動資源調(diào)度、應用日志統(tǒng)一管控、應用服務的編排、微服務管理等),此時出現(xiàn)了容器技術,容器技術實現(xiàn)有很多種,但最流行的是Docker.

傳統(tǒng)容器技術相較虛擬機優(yōu)勢不是特別大.Docker能夠流行一大重要因此就是它的創(chuàng)新–Docker鏡像.Docker構建了一整套構建、發(fā)布、運行體系：容器(Container)、倉庫(Repository)、鏡像(Images).傳統(tǒng)容器只解決了容器運行(run)的問題.而Docker定義了一套容器構建(build)分發(fā)(ship)的標準,使應用管理非常便捷,尤其適合微服務管理.

注意容器對應用有特定的要求,并不是所有應用都適合,例如需要無狀態(tài)化、鏡像文件不能太大等.

自動化運維需要注意的幾點：
?
一般的自動化運維工具均缺乏良好的可視化界面,需要進行結合定制開發(fā).良好的界面可以更易于在企業(yè)內(nèi)部推廣自動化運維.
自動化運維工具眾多,各有所長,應結合熟悉程度、技術特點進行針對性選擇.
多層的自動化管理工具,多頭的配置管理是個難題,建議考慮定制化,設計統(tǒng)一的CMDB,做到一點配置,多點更新.

Ok,本文就到這里,由于自動化運維是個很大的話題,涉及話題很大很廣,這次僅僅是答題的概述,后續(xù)將結合專題進行細化討論.

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4355.html