615
細說自動化運維的前世今生
作者介紹
朱祥磊，山東移動BOSS係統架構師，負責業務支撐係統架構規劃和建設。獲國家級創新獎1項、通信行業級科技進步獎2項、移動集團級業務服務創新獎3項，申請發明專利13項。
係統規模的不斷發展以及應用軟件架構的發展，推動著自動化運維的演進。因此在說自動化運維之前，需要先說說應用軟件架構的發展簡史。回顧過去，應用軟件架構先後經過了單塊架構、多層架構、服務化架構、分布式、微服務架構等：
單塊架構
應用軟件發展早期，係統規模一般很小，特點是應用功能集中、代碼和數據中心化，表現為一個軟件發布包，集中部署，各模塊運行在同一個進程的應用程序。此時一般幾台機器就可以完成全部應用軟件功能。
以Web應用程序為例，在Web應用程序開發的早期，由於受到麵向過程的思維及設計方式的影響，所有的邏輯代碼並沒有明顯的區分，因此代碼之間的調用相互交錯，錯綜複雜。譬如，我們早期使用的ASP、JSP以及PHP，都是將所有的頁麵邏輯、業務邏輯以及數據庫訪問邏輯放在一起，這是我們通常提到的單塊架構。
在這種架構下，所需的機器數量很小，完全的scale-up模式，據說IBM公司在上世紀50年代曾經宣稱， 全世界隻需要5台計算機就夠了！
多層架構
為了解決單塊架構擴展性差的問題，同時解決代碼集中帶來的並行開發測試困難等問題，逐步出現了多層架構，把表示層、業務邏輯層、數據訪問層適當分離，分別打包部署。如通過實現Model-View-Controller的模式將數據、業務、展現進行分離。還有一種RPC架構，通過遠程過程調用實現應用架構分離。
此時每層都獨立打包，獨立部署於容器和單獨的服務器中，應用結構更加複雜但也更加清晰，當然所需的服務器數量就進一步增加了。
服務化架構
多層架構盡管大幅提升了應用的擴展性，但是隨著軟件和係統規模的不斷擴大，垂直應用越來越多，應用之間交互不可避免，此時層間應用接口變得越來越龐大，最終會變得難以管理。通過將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速地相應多變的市場需求，也使不同服務的獨立擴展成為可能。
在這種模式下，可以按服務進一步拆分部署，應用可以擴展到更多的機器和容器上。
分布式雲化架構
隨著業務不斷發展，硬件成本的下降，基於X86架構的廉價硬件+分布式軟件的模式日趨成熟，得到了大規模應用，分布式服務框架逐漸替代傳統的服務化架構，解決了傳統服務化的弊端，例如企業集成總線ESB是實體總線，性能線性擴展能力有限，硬件負載均衡器的壓力越來越大，不斷擴容導致硬件成本增加，隨著業務規模的不斷增長，傳統的數據庫、配置中心等逐漸成為單點瓶頸。當然應用也徹底變為了scale-out架構，導致機器和容器數量大幅上升。
微服務架構
微服務架構是對上麵分布式雲化架構的拓展、服務化的進一步延伸，通過對服務進一步細化，形成微服務，運行於單獨的容器平台，可實現雲的彈性和敏捷，如彈性伸縮、線上線下一致的環境、提升自動化運維能力等。
別著急，下麵再允許我介紹下自動化運維的內容，究竟包含哪些內容？
-
硬件和網絡的自動管理
-
雲化、虛擬機的自動管理
-
操作係統和軟件的自動化安裝、配置
-
常規任務（健康檢查、安全加固和檢查、備份、清理、數據管理、彈性伸縮等）
-
手工任務（容災切換、應急操作、應用部署和起停……）
-
監控
-
問題診斷
-
可視化
其中1、2、3主要是傳統IaaS層關注的工作內容，重點是計算、存儲、網絡的自動化管理，4到8主要是PaaS層關注的工作內容，IaaS層和PaaS層相互結合，共同完成自動化運維。
好了，終於到正題了，自動化運維前世今生來了…..
-
史前時代：此時係統規模很小，一般幾台，不超過幾十台，此時一般通過手工單台登錄即可滿足運維要求。
-
中世紀時代（集中管理階段）：係統規模有了較大擴展，從幾十台到上百台，此時再通過手工方式已經無法進行，於是出現了各種Shell腳本，通過腳本實現相關的運維，腳本僅僅是針對特定的場景，難以實現全流程的自動化。
-
中世紀拓展（集中管理的進階）：為了方便管理以及可視化，出現了各類商用或開源工具軟件實現自動化運維，如HP Openview、puppet、SaltStack、Chef等等，做為腳本方式的提升。
-
新時代：係統規模進一步擴大，從上百台演進到上千上萬台，以前的方式由於存在弊端，如缺乏統一的CMDB或太簡單、不支持複雜環境、缺乏友好的可視化界麵等，難以滿足要求，此時又出現了幾個分枝：
-
分枝一：從底向上的雲平台方案：通過雲管理平台實現計算、網絡、存儲的IaaS層自動化管理，同步建立軟件PaaS層自動管理，最終實現融合。
-
分枝二：從上向下的雲平台方案：通過上層PaaS層自動化管理，逐步向下探索，如容器等。
新生代自動化運維初探
下麵重點介紹幾個自動化運維工具或平台：
Openstack
Openstack是IaaS層目前最活躍的一個開源的雲計算 IaaS 平台，即雲操作係統，類似於AWS（亞馬遜的雲服務），通過各種開源組件實現了不同功能，目前大部分雲管理平台均基於Openstack實現計算、網絡、存儲的統一管理，Openstack支持如下功能組件：
-
計算服務（Nova）：按需提供計算資源，創建和管理批量虛擬機 ，動態虛擬機管理：創建、重啟、調整大小、遷移等。
-
對象存儲服務（Swift）：基於普通硬件的大規模存儲，無中心節點，分布式存儲、水平擴展，同時多數據備份，保證安全，通過API接口對外訪問。
-
塊存儲服務（Cinder)：為虛擬機提供雲硬盤。
-
網絡服務（Neutron）：為虛擬機提供網絡訪問能力。
-
編排服務（Heat）：提供自動化部署及管理服務。
-
數據庫服務（Trove）：提供數據庫管理服務。
-
認證服務（Keystone）：提供身份認證機製服務。
-
鏡像服務（Glance）：提供虛擬機鏡像存儲服務。
-
監控服務（Ceilometer）：提供計量與監控服務。
-
Dashboard（Horizon）：自服務、權限、圖形化界麵。
Openstack盡管對IaaS層的自動化管理比較強大，但仍然需要注意如下幾點：
1、Openstack版本眾多，如何選擇是一個難題。
例如存在社區版、發行版、商業公司定製版本等，如何選擇是一個難題，而且Openstack每半年一個穩定版本，演進很快。一般認為對Openstack項目中的開源代碼進行修改定製是個不錯的主意，但這從長期角度來看不一定最佳。“定製雲”很可能需要付出高昂的代價，不僅投資巨大、成本高昂，企業用戶還將被迫麵對一大堆後續的管理及維護開銷，並被綁定在單一供應商或版本身上。
建議企業如果有很強的技術能力的話，可以根據自己的需求做定製，但需要把握好和社區發展的關係。 一般來說，需要根據自己的需求，選擇合適的版本，盡量不改變社區版本，定製化需求盡量在外圍進行改動。如果采用了廠商的版本，實際上也是某種綁定，可能離社區越來越遠。
2、需要慎重選擇相關組件合功能
由於Openstack理念是分布式、最終一致性，因此所有的原始功能組件都是基於這一設計，企業用戶考慮采納Openstack之前，必須對企業業務應用進行分析：應用程序是否有可擴展性和彈性伸縮的要求？ 應用程序是否可以接受最終一致性？ 應用程序是否無狀態化？ 應用程序的性能要求？應用程序的可靠性要求？ 應用程序的安全要求？ 應用程序的容災備份需求？ 不同的要求決定了Openstack不同的計算、存儲、網絡等模塊設計。
3、Openstack對PaaS層和物理機管理較弱，需借助其他工具實現
Openstack已經能夠支持很多的IaaS自動化運維和部分PaaS自動化運維任務，但不能滿足全部，如批量運維、深入監控、軟件管理等功能缺少，特別是對物理機運維較弱，一般需要結合其他PaaS層管理進一步完善自動化運維體係。
SaltStack+定製
PaaS層自動化運維工具就太多了，例如監控就有Nagios、Ganglia、Zabbix等，運維工具則有Puppet、Chef、SaltStack、Ansible等，不同企業根據企業自身開發實力、結合配置管理工具的資源豐富程度、依賴複雜程度考慮，會有不同的選擇。通過對運維工具本身的研究，結合運維人員的運維經驗和評估企業未來的規模，下麵以開源SaltStack+定製實現的方案進行介紹。
SaltStack是繼 Puppet、Chef 之後新出現的S配置管理及遠程執行工具，與 Puppet 相比，SaltStack較為輕量；不像 Puppet有一套自己的 DSL 用來寫配置，SaltStack 使用 YAML 作為配置文件格式，相對簡單，同時也便於動態生成；此外，SaltStack 在遠程執行命令時的速度快，由於使用了ZeroMQ，這個下發過程可以並行執行，速度比Ansible的無agent ssh通信快得多，是一個分布式遠程執行係統，用來在遠程節點（可以是單個節點，也可以是任意規則挑選出來的節點）上執行命令和查詢數據。
從部署結構上看，SaltStack的在部署上可以分為master和minion兩個部分，其中master相當於統領所有機器的總管，而minion則是部署在被管理機器上麵的agent進程，master通過網絡將配置管理相關的操作下發到minion，由minion在對應機器的本地執行。典型的部署例子如下圖所示：
在現實生產環境中，大批量的用戶創建需求，文件上傳需求、配置變更需求、軟件升級需求占用了維護人員大量的時間，引入SaltStack後，該工具的遠程執行和配置管理可以解決該問題，真正實現批量化和自動化，滿足海量運維的需求。
容器
有了Openstack和SaltStack為代表的的PaaS層自動化工具還不夠，針對應用自動化運維場景，如彈性伸縮、DevOps（開發運維一體化、開發測試一致的環境、自動資源調度、應用日誌統一管控、應用服務的編排、微服務管理等），此時出現了容器技術，容器技術實現有很多種，但最流行的是Docker。
傳統容器技術相較虛擬機優勢不是特別大。Docker能夠流行一大重要因此就是它的創新--Docker鏡像。Docker構建了一整套構建、發布、運行體係：容器（Container）、倉庫（Repository）、鏡像（Images）。傳統容器隻解決了容器運行（run）的問題。而Docker定義了一套容器構建（build）分發（ship）的標準，使應用管理非常便捷，尤其適合微服務管理。
注意容器對應用有特定的要求，並不是所有應用都適合，例如需要無狀態化、鏡像文件不能太大等。
自動化運維需要注意的幾點：
-
一般的自動化運維工具均缺乏良好的可視化界麵，需要進行結合定製開發。良好的界麵可以更易於在企業內部推廣自動化運維。
-
自動化運維工具眾多，各有所長，應結合熟悉程度、技術特點進行針對性選擇。
-
多層的自動化管理工具，多頭的配置管理是個難題，建議考慮定製化，設計統一的CMDB，做到一點配置，多點更新。
Ok，本文就到這裏，由於自動化運維是個很大的話題，涉及話題很大很廣，這次僅僅是答題的概述，後續將結合專題進行細化討論。
原文發布時間為：2017-02-28
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-15 10:03:42