從時代變化與規模談自動化運維

來源:本站原創 服務器技術 超過747 views圍觀 0條評論

文/余沛

時代變化所引起的運維視角不同

在計算機應用的發展歷史中,運維工作一直是必不可少的重要環節。無論在什么年代、什么場景,保證服務的正常可持續運行都是運維的最終目標。但在不同時期,運維實施的手段、關注的重點卻有所不同。

在計算機應用的早期,計算機仍然是一臺昂貴且嬌氣的設備,那時非但應用場景遠沒有今天這樣廣泛,網絡體系也沒有今天這樣的復雜和敏感,電子技術也遠不如今天 成熟。在那個時期,運維關注的重點通常以硬件為主。除了計算機本身的硬件,與之相關的電力及其他配套設備也在范疇之內。

到了中期,計算機由 大、中型轉向微型化,局域網絡發展迅猛,金融、通信、電力、航空、學校等各類商用、民用場景的快速跟進,不但使得計算機的總體使用量大增,而且單位范圍內 需要管理的計算機規模也在不斷加大和復雜化。在這個過程中,形成了以設備管理(包括網絡設備、操作系統管理)、數據存儲與容災、目錄與內容管理、資產管理和信息安全管理為主的、一體化的早期運維體系。

再到后來,互聯網模式占據了最新潮流且至今未衰,科技和業務模式帶來的變化,也催生整個運維 體系的轉變。早期一體化的運維系統被更加明確與細致的分工所拆散。IDC代替了自建的局域網小機房,使得通信主干的運維工作從原有體系中剝離;規模的爆炸 式擴大也使得即使同一IDC內的局域網管理也更加復雜;安全的挑戰越來越嚴重,使得傳統基于局域網粗暴隔離思想的安全管理無法滿足開放互聯網時代的要求。 同時,人們也發現一些運維事務簡單地隨規模增長而線性增加(如資產管理、自動裝機等),本身不具有復雜度的變化,而另一些與業務相關的事務,則隨著規模增長復雜度成倍增加。

由于這些原因,使得運維工作開始明確分工,逐項剝離。系統、硬件、網絡衍生出專職的系統管理員(SYS)職位,安全也開始從運維獨立,資產管理、自動裝機等工作不再是運維工程師關注的重點。相反,與業務可用性緊密關聯的調度、監控、關系管理變得更加上層。

規模變化所引起的運維手段不同

在互聯網時代以運維的角度來看,對于不同規模、場景的應用,運維所處的位置、發展的歷程也有一定差異。

百臺以下規模的運維

一般來說,小公司有幾臺到數十臺機器的規模,運維主要關注的點還是在系統及應用服務的穩定性上,不一定有專門的運維人員,通常是RD自行維護所開發的系統。不會去系統化地梳理各項運維指標,而是以人的經驗為主,來判斷和設定系統正常與否的標準。

在這種場景下,運維工作通常扮演的是“救火隊員”角色,一旦出故障,運維人員才開始跟進、解決。故障解決也基本是Case by Case的形式,不太會有流程化的總結和問題庫、知識庫。其運維方式無非是靠手工,輔以一些自行編寫的小腳本。這種方式雖較為原始,但對許多初創公司來 說,也算是一種低成本下可靈活實施的手法了。

在這個階段,一些小巧的工具顯得很有特色,例如在系統管理方面,能夠同時對多臺機器進行操作的 PsshOmniTTY等,在數據庫管理方面,phpMyAdmin等足以應付平時的工作。

千臺規模的運維

當規模增長到一定程度,依賴手工管理自然已無力應對。許多互聯網公司的服務器早已跨入幾百甚至千臺規模,腳本化、批量化管理占據非常大的比例。

同時,在這種規模下,按垂直劃分的運維工具也開始大量應用,無論是自行開發的還是利用現有開源軟件,針對某一特定領域的管理系統顯得尤為重要。

在這個階段,運維主要精力放在監控(采集、報警、展現圖表)、部署上線(配置管理)、數據備份方面,因為機器數量龐大,所以集中式的操作平臺是必備的,針對不同的領域,也有相當成熟的開源軟件可以直接使用。

在監控方面,Nagois和Catci應用最為廣泛。

作為一款開源的免費網絡監視工具,Nagios能有效監控Windows、Linux和Unix的主機狀態、交換機路由器等網絡設置。在系統或服務狀態異常時發出郵件或短信報警,在狀態恢復后發出正常的郵件或短信通知(如圖1所示)。

圖1 Nagios報警通知界面

Nagios的特點包括以下幾方面。

  • 可以通過多種協議對目標服務器進行信息采集(SMTP、POP3、HTTP、NNTP、PING等),避免在目標服務器安裝客戶端帶來的風險。
  • 本身體系非常開放,可以自定義編寫采集腳本以監控系統、應用的狀態。簡單的插件設計使得用戶可以方便地擴展自己服務的檢測方法。
  • 具有并行服務檢查機制,同時具備定義網絡分層結構的能力,用“Parent”主機定義來表達網絡主機間的關系,這種關系可被用來發現和明晰主機宕機或不可達狀態。
  • 當服務或主機問題產生與解決時將告警發送給聯系人(通過Email、短信、用戶定義方式)。
  • 可以定義一些處理程序,使之能夠在服務或者主機發生故障時起到預防作用。
  • 自動的日志滾動功能。
  • 可以支持并實現對主機的冗余監控。
  • 友好的Web界面用于查看當前的網絡狀態、通知和故障歷史、日志文件等。

Nagios 和Cacti是經常配合在一起使用的監控系統,Nagios適合監視大量服務器上的大批服務是否正常,重點并不在圖形化的監控,其集成的很多功能例如報警 都是Cacti沒有或者很弱的;Cacti主要用途還是用來收集歷史數據和畫圖,因此界面比Nagios漂亮很多。

而在部署方面,Puppet是用于大規模集群管理的神器。其本身使用Ruby語言開發,基于C/S架構(如圖2所示)。在每臺機器上部署的客戶端每隔一個指定的時間會連接到Master檢查資源變化情況,若資源發生變化,將按配置動作進行相應的操作。

Puppet將所有可操作對象抽象為資源,目前涵蓋了40多種,如:File、User、Group、Host、Package、Service、Cron、Exec等。

Puppet 通過抽象資源的方式,使得每臺機器能夠“清楚”其本身“應該”是什么“狀態”,而客戶端根據當前是否達到這個狀態決定采取指定的動作。這使得Puppet 不僅可用于傳統的應用部署,而且通過合理的手段,也能夠將比應用部署更頻繁的配置管理一并解決。甚至可以在Master端外接自己開發的平臺,通過集中配 置方式管理各項“資源”,實現高度靈活的自動化管理體系。

圖2 Puppet Master-Agent結構圖

這類垂直管理系統的使用及活躍,極大減輕了運維人員在重復性、批量化操作方面的負 擔,能夠非常有效地在各自領域完成既定的運維子目標。但其缺陷在于只能針對某一垂直領域的特定問題進行高效處理,對于它們之間的關聯性很難應對。因為運維 的本質是保證服務的可用性,而自動化運維則是在完全保證這一前提下,盡可能將需要人干涉的部分處理掉,所以判斷其優劣的標準則是——與人工處理比,對服務 的保證有沒有提高。如果僅是解決報警、部署這些單一動作,后續仍然需要人去處理、去關注、去判斷的話,就離這個目標還有距離,談不上真正的自動化,只能算 是工具化。

上萬臺規模的運維

對于規模已達到上萬臺、十萬臺的各互聯網巨頭來說,其業務間交織縱橫,甚至某一單一業務內部可能也已非常復 雜。傳統的開源軟件大多已無法覆蓋這樣場景下的運維工作。另外,在這個階段,除了各服務自身的監控信息、部署信息等需要運維外,服務與服務間的關聯關系、 上下游變更所帶來的影響、業務的串聯也顯得尤為重要,它們經常是牽一發而動全身。互聯網巨頭都在根據自身的業務特點,紛紛自行研發成體系的自動化運維平 臺。在這個階段,各公司更關注各平臺之間的聯動性,更關注運維的本質——即真正的自動化:不僅是自動發現問題,更要能自動協助解決問題,以保證服務的穩 定。

各大公司自主研發的歷程,是由單一的任務解決向平臺化過渡,運維關注的重點也由可用性發展到易用性、靈活性,最終實現自動容災,以及資源可伸縮調度。

以 Google為例,能夠將URL(統一資源定位)的概念用于運維體系,將每一種服務(無論對內、對外)都抽象為一種資源,提供這種資源的服務將自身信息寫 入,使用方通過URL來得到資源的實際位置,當資源發生變化時,使用資源的一方能夠感知,并根據自身業務做出相應的動作。

國內的互聯網公司也有不少家正在往這個方向追趕。這些自主研發的智能運維平臺,除了像開源軟件那樣能滿足常規的監控、部署備份等需求外,更能站在“服務”的角度關注其最終狀態。

例如,某項服務有N臺機器提供負載均衡,會向某個狀態池集中寫入其狀態,相關的監控通過收集這些狀態,按照指定的配置規則進行動態監控。一旦發現狀態異常, 如負載過高時,能夠觸發部署動作,從資源池中再拉幾臺機器進行部署。部署信息都在狀態池中,該安裝什么軟件、什么版本、如何部署都由系統自動完成。完成部 署后,新機器上的服務被啟動,啟動時再向狀態池中注冊自身,負責負載均衡的設備感知到關注的狀態信息變化(有新機器加入)后,刷新配置將新機器的服務納入 對外服務列表。

自動化運維與基礎架構之間的關系

隨著運維技術的進步以及運維體系的完善, 自動化運維作為一個既不算嶄新卻又充滿活力的方向,也隨著規模、場景的變遷迎來新的挑戰和變化。運維的活動范圍,更多介于硬件與操作系統之上、應用之下。 其與基礎架構之間也像是人的兩條腿,相輔相成,總是一前一后交替往前推進。基礎架構決定運維方向,同樣運維體系又使得基礎架構發揮最大收益。

故而自動化運維平臺的根本,不是說僅僅去把操作界面化、OA化,讓人們簡單地在Web上點擊按鈕就能管理系統。而是在底層的基礎架構與上層的業務系統之間搭建一個良好的橋梁,使得業務系統能夠充分、穩定卻又不必過度關注底層架構特性。

這時的運維,已不再僅是消除故障、打掃設備的后置服務,而是能夠在業務開發時期介入、伴隨整個業務共同運行的一種特殊服務。以Google的Borg為例, 通過引入一套標準庫,按照指定的規范編寫應用,使得編寫出來的應用本身就能滿足對應基礎架構下的可靠運維,無論是統一的運維狀態接口,還是災備、自動縮擴 容,以及變更時的關系調整,都能夠很好地應對。

云計算帶來的變革與挑戰

虛擬化、云計算的 發展,又使得運維工作產生了進一步的變化。中小公司不必再考慮諸如容災、備份方面的事宜,資源的按需交易不僅使得資源不再浪費,也使得業務調整時的伸縮變 得更加容易且經濟上更加劃算,的確大大簡化了傳統意義上的運維工作,是未來中小互聯網公司發展的重要趨勢。這時,運維工作的重點將轉移到平臺架構的選型與 優化上來,運維需要更關注業務特性及與之相關的技術體系,幫助研發決定各類云服務的選型、評估其對業務的適用性。

在可預見的未來,運維的角 色將變得越來越重要,這種重要性的提升關鍵在于運維在整個技術體系中的參與度及所處位置發生的變化。自動化運維的興起,將傳統意義上處于后置服務的運維人 員帶到了服務前沿,以往簡單的追查故障、保障服務雖然仍占據運維工作的一部分,但隨著自動化運維技術的發展,運維人員有更多精力、條件,投入到整個服務架 構的梳理、設計中,甚至以提供基礎組件的方式參與到研發過程,使得產品天生具有較高的可運維性。研發要關注運維,運維要有能力介入研發,具有對等能力的角 色配合,各自負責不同的領域方向,這是技術發展大體系下的必然分工,也是運維擺脫苦力勞作,繼續往更深技術發展的必然之路。

作者余沛,藝龍網平臺總監。原百度高級工程師,專注于分布式及自動化運維方向,曾參與百度自動化運維平臺核心構建,現負責藝龍網基礎平臺及自動化控制系統。

本文選自《程序員》雜志2012年09期,未經允許不得轉載。如需轉載請聯系 [email protected]

文章出自:CCIE那點事 http://www.qdxgqk.live/ 版權所有。本站文章除注明出處外,皆為作者原創文章,可自由引用,但請注明來源。 禁止全文轉載。
本文鏈接:http://www.qdxgqk.live/?p=3161轉載請注明轉自CCIE那點事
如果喜歡:點此訂閱本站
?
?
萌宠夺宝游戏