【20年品牌建站】找北京網站建設公司就選新鴻儒/提供北京網站建設報價/北京網站制作/北京網站設計/網站開發、北京網站建設公司電話【010-51267718】有優惠哦!
簡體
繁體 簡體
我們的服務遍布中國

我們的服務遍布中國
乃至世界

新鴻儒所服務的品牌地域與城市
北京 天津 上海 廣州 深圳 香港 廈門 江蘇 浙江 山東
重慶 長沙 武漢 成都 西安 寧夏 麗江 青海 云南 烏魯木齊
黑龍江 內蒙古 河北 ...
新鴻儒服務與合作的全球各地
美國 加拿大 德國 法國 英國 瑞士 意大利 荷蘭
印度 日本 韓國 ...

不論你的品牌在何處
我們都可以提供完善的服務與幫助

致電

010-5126 7718

細說自動化運維的前世今生

發布時間:2018-02-12 瀏覽:82打印字號:

  系統規模的不斷發展以及應用軟件架構的發展,推動著自動化運維的演進。因此在說自動化運維之前,需要先說說應用軟件架構的發展簡史?;仡欉^去,應用軟件架構先后經過了單塊架構、多層架構、服務化架構、分布式、微服務架構等:


  單塊架構


  應用軟件發展早期,系統規模一般很小,特點是應用功能集中、代碼和數據中心化,表現為一個軟件發布包,集中部署,各模塊運行在同一個進程的應用程序。此時一般幾臺機器就可以完成全部應用軟件功能。


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


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


  多層架構


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



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


  服務化架構


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



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


  分布式云化架構


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


  微服務架構


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


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


  1、硬件和網絡的自動管理

  2、云化、虛擬機的自動管理
  3、操作系統和軟件的自動化安裝、配置
  4、常規任務(健康檢查、安全加固和檢查、備份、清理、數據管理、彈性伸縮等)
  5、手工任務(容災切換、應急操作、應用部署和起?!?/span>
  6、監控
  7、問題診斷
  8、可視化


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


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

  1、史前時代:此時系統規模很小,一般幾臺,不超過幾十臺,此時一般通過手工單臺登錄即可滿足運維要求。
  2、中世紀時代(集中管理階段):系統規模有了較大擴展,從幾十臺到上百臺,此時再通過手工方式已經無法進行,于是出現了各種Shell腳本,通過腳本實現相關的運維,腳本僅僅是針對特定的場景,難以實現全流程的自動化。
  3、中世紀拓展(集中管理的進階):為了方便管理以及可視化,出現了各類商用或開源工具軟件實現自動化運維,如HP Openview、puppet、SaltStack、Chef等等,做為腳本方式的提升。
  4、新時代:系統規模進一步擴大,從上百臺演進到上千上萬臺,以前的方式由于存在弊端,如缺乏統一的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項目中的開源代碼進行修改定制是個不錯的主意,但這從長期角度來看不一定優質?!岸ㄖ圃啤焙芸赡苄枰冻龈甙旱拇鷥r,不僅投資巨大、成本高昂,企業用戶還將被迫面對一大堆后續的管理及維護開銷,并被綁定在單一供應商或版本身上。


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


  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,做到一點配置,多點更新。

 ?。ㄔ膩碜赃\維派)

現在就與新鴻儒客服交流

010 - 51267718

您也可進行在線咨詢或預約項目顧問
我要預約
在線咨詢
亚洲 小说区 亚洲 另类 小说 春色 小说区 图片区 综合区