大數據SRE的總結（1）－－部署

在開始寫第一篇《部署》前，我想寫一個日常運維的小插曲。

今天我司的hadoop集群，突然有3-4台機器報警，錯誤是操作系統盤 「／」滿了。我查閱了一下，在/etc/upstart下，有個docker.log. 寫滿了整個系統盤。

這導致這幾台機器上的所有hadoop 進程都掛了，因為這些hadoop進程需要把日誌寫入/var/log但是寫不進去。這個問題是因為docker的日誌錯配造成的。隔壁組開發了一個docker-on-yarn的app，app會把docker container跑在yarn上，分配到空閑機器的container中。container里的docker app產生的app logs會被寫入node manager的data-dir，當這個data-dir被寫滿後，這台機器的docker守護進程就會把這個報錯輸出到守護進程的log，而這個log指向到/etc/upstart/docker.log.

這裡有兩個錯誤：

1.docker app 沒有log rotation，不應該寫滿數據磁碟。

2.docker守護進程的docker.log 沒有配置 log rotation policy，日誌位置的配置也錯誤，應該配為非系統盤路徑。

錯誤發生後，我很擔心，如果我們的集群里還有很多此類節點存在這種錯配的問題，那麼hadoop集群中大量的機器都存在被拖死的危險。如果一起發生，那整個集群就面臨著危險。

於是我找到了隔壁組值班的小夥伴，他開始認為這是一個很小的問題，以為就是日誌錯配了，改好就ok。在我反覆提醒之下，仍然沒有意識到潛在的問題。在我的push下，才把這類app部署的所有docker日誌配置check並修改了一遍。

我寫這個小故事，其實是想反應運維和開發錯位的問題。在生產環境里，運維工程師 和 應用開發工程師 的立場是差別巨大的。 很可能在 應用開發工程師的眼裡，一個很小的問題，並不影響功能，應該為需求上線而讓步。但是在運維工程師這邊，一個錯配，都可能會給線上集群造成很大的影響。

運維很重要！

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝分割線＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

為什麼hadoop部署要拿出來講呢，因為它是hadoop集群存在的第一步，非常重要(似乎是廢話). 當今的規模以上互聯網公司，hadoop集群動輒成百上千，甚至上萬台。這麼多機器，必須要提高部署的效率來應對每時每刻數據的暴增，應對每隔一段時間就會新加入的很多新的機器。這些操作需要運維工程師來操作，如果自動化做的不好，那麼長期做這個事的工程師，會感覺乏味疲憊，操作的責任心也可能會下降，從而可能引起誤操作。長期下去，會陷入惡性循環。

在講部署前，我先從兩個維度，對部署進行分類：

第一個維度，即時代。我把hadoop的部署分為三個時代：

1.裸腳本時代

2.分散式配置管理腳本時代

3.自動化管理系統時代

每個時期，每個公司所採用的技術落地方案在細節都不同，但是其背後的原理，都逃不出這幾個時代維度。

第二個維度，是hadoop的發行版，一般也分為三種情況。

1.apache版本

2.cdh 版本 (由 cloudera 公司定製。 美國公司，即將上市)

3.hdp 版本 (由 hortonworks 公司定製。美國公司，已上市)

所以就有了以下這張二維表：

不論在哪個時代，哪種hadoop發行版，都是這兩個維度的正交。有些情況，比較少見，比如自動化管理系統＋apache版本，這一般存在某些互聯網公司自研。而裸腳本時代，也不可能安裝部署cdh和hdp。

在部署hadoop集群時，一般要做這樣三件事。

1.在集群的每一台機器，安裝hadoop整個軟體棧

2.在集群的每一台機器，配置好每一個hadoop的角色的 配置文件

3.在相應的機器，啟動／停止 相應的組件的進程

那麼接下來，就按第一個時代的維度，來看看都是怎麼解決這三件事的。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

第一時代 裸腳本時代

這個時代，部署腳本一般都是一些裸寫的shell／python／ruby 腳本，基本思路就是用ssh登錄到每台機器一步一步幹活。

具體步驟一般如下：

1.先把yum/apt-get 的repo文件copy所有節點上。

2.運行yum/apt-get 安裝hadoop軟體。

3.把準備好的配置文件，copy到所有節點上。

4.ssh到所有節點，啟動上面的datanode nodemanager regionserver等進程。

代表項目：

https://github.com/hadoop-deployer/hadoop-deployer/tree/master/cdh4

缺點：

這個時代的解決方案，缺點很明顯，需要編寫很多繁雜的腳本控制代碼，需要一台一台的去ssh執行流程。如果需要並行安裝多台機器，還要用腳本控制並發邏輯的編程。

這些問題不光光是hadoop集群的問題，也是其它分散式程序的問題。為了解決這類問題，市面出現了很多分散式的配置管理框架，例如ansible/puppet/chef/saltstack, 開源自動化配置框架對比 開源自動化配置管理工具ansible、saltstack、Puppet、Chef選擇 & SaltStack 與 Ansible 選擇？

第二時代 分散式配置管理腳本時代

很多公司，都是用分散式配置管理腳本來部署hadoop集群，管理hadoop集群的配置。

我自己也在維護一個saltstack+hdp的集群。那我就來分析一下這類解決方案的優劣。

好處：

好處不需多言，網上有很多介紹這類框架的文章。大致就是隱藏了諸如並行、以及通用的一些控制流程序的編寫。（安裝package，複製文件，控制目錄文件的acl 等等）

壞處：

其實這裡不能說是壞處，而是在解決hadoop部署這個問題面前，「分散式配置管理腳本們」還有一些解決的不是很好，或者很難解決的問題。比如：

1.在一部分機器中，如果需要有特殊配置，那就需要重新創建一個表示這類狀態的描述文件。這是一個很麻煩的事情，設想，如果集群內有特殊配置的機器分類越多。那麼「相同，卻又有一部分不同」的配置腳本，就會越來越多。

2.每次修改配置，都需要到git repo統一提交，那麼就要經歷pull最新代碼，merge代碼，再push回倉庫。這似乎對一次運維「太重」了。 比如我們遇到了namenode內存的瓶頸，需要調大heapsize，經歷這麼一遭，似乎太「慢」了。這也不滿足在《大數據SRE的總結（0）－－開篇》提出的方法論：「讓一切人對機器的操作儘可能的自動化」。

3.對每台機器的「進程狀態」控制。原則上，hadoop集群的每一個節點，都要啟動datanode,nodemanager,regionserver.因為只有這樣，才滿足計算向數據靠攏的大數據思想(data locality)。運維工程師一般都會維護一張機器到組件進程的映射表<host, [roles..]>，會寫一個外部的周期檢測程序，監控對應機器上，各個進程是否健康的運行。 當集群越來越大後，機器的損壞率會增加，有些機器壞了，會被報修了。而這些機器上的進程也會因為這樣的原因被迫遷移到其它機器，比如zookeeper，journalnode這樣的組件進程就有可能會被迫遷移。這時就需要修改映射表<host, [roles..]>。當集群的機器規模到了百台甚至千台，每次機器壞掉，需要遷移role時。或者每次加入／刪除節點到集群時，維護映射表就成了一個頭疼的問題。

代表項目：

彭博社 bloomberg 使用chef管理hadoop

https://github.com/bloomberg/chef-bach

github上一些 使用ansible管理hadoop的開源項目

https://github.com/objectrocket/ansible-hadoop

https://github.com/lizhitao0923/ansible-hadoop/tree/master/roles/common

第三時代 自動化管理系統時代

這個時代的自動化管理系統，架構比較複雜。其主要的設計初衷，都是為了解決運維hadoop的過程中總結／歸納出來的痛點。比如：

1.配置管理，包括配置分組，配置歷史，配置分發。

2.<host,[roles]>映射表，以及每台節點進程狀態的資料庫存儲

3.可視化一切常規運維操作。包括安裝節點，啟動／停止節點，等等。

基本上上規模的互聯網公司，都需要這樣一套SRE系統，來提高公司大數據集群的運維效率，不然運維工程師都該抱怨每天的重複勞動了。這類系統，可以解放運維工程師，做更多的自動化系統，做更好的報警，做更好的調優，和最重要的「自我提升」。

自動化系統，有開源和自研兩條路走。

開源有hortonworks的ambari可供選擇。

小米也開源了自家的hadoop自動化管理系統minos ： https://github.com/XiaoMi/minos

商業版也有cloudera家的cloudera-manager可選。

總之，這類系統的目標，都是為了讓「讓一切人對機器的操作儘可能的自動化

」這個目標得以實現。以解放工程師，提高運維效率為目標。

Ambari

https://hortonworks.com/apache/ambari/

Cloudera-Manager

https://www.cloudera.com/products/product-components/cloudera-manager.html

我司最大的集群，也是使用了cloudera manager進行管理。

• 進程分組 ／進程主機映射 ／進程狀態

• 可視化的配置管理

cloudera也分為：

1.免費版

2.付費版

付費版多一些生猛的功能^_^,還有客服服務， 但免費版已經足夠大部分公司的使用了。（免費版提供hdfs/resourcemanager/hbase-master 的 HA功能哦）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

最終技術選型的參考決策：

作為國內互聯網公司在選擇自動化運維繫統時，我cto們建議先問自己幾個問題。

1.是否願意在商業軟體投入,是想把錢花在買商業軟體直接解決問題，還是想花更多的錢，培養自己的工程師鑽的更細。商業軟體後期面臨被甲方綁架，規模巨大後成本不可控的問題。 工程師團隊面臨早中期投入大，產出慢，維護成本高等問題。

2.即使不願意花錢。那選擇免費時，也有不同。cloudera有免費版。那麼是選擇開源的ambari還是選擇免費的cloudera-manager. 這取決於公司是否有需求做hadoop自動化系統的二次開發。是否自身的需求會超越社區ambari，以及公司是否有實力做開源系統的二次開發。

3.是否自研。 這就更難了，業務需求不大到一定程度，對每個細節的要求不到吹毛求疵，不建議這麼搞。

總之，從1-->2-->3 投入的人力成本是越來越大的，同樣對項目的掌控的難度和帶來的靈活度也是最大的。 這需要公司根據自己的實際情況評估而定。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

最後，到了自動化系統運維時代，運維工程師是否就高枕無憂了呢？

又有一系列的問題被提出來，比如：

• 自動化的運維程序足夠健壯嘛？如果其本身出bug了，怎麼辦？
• 自動化系統，能覆蓋所有的運維需求嘛？是否有很難的需求點，很難覆蓋到的？
• 自動化系統，可以替人決策嘛？可以給我們建議，進行參數調優嘛？ 有足夠的metrics數據支撐我們做出運維的判斷嘛？

要回答這些問題，請看後續的系列文章。^_^.

鏈接：

1. 大數據SRE的總結（0）－－開篇

2.https://hortonworks.com/apache/ambari/ ambari介紹

3.https://www.cloudera.com/products/product-components/cloudera-manager.html cloudera manager 介紹