為Hadoop叢集選擇合適的硬體配置

儲存，學習，共享

最近3天一直在搞hadoop叢集CDH的安裝，本來很easy的事情，搞了3天崩潰。。。。

最後在最信任，技術最牛的領導的幫助下，總算搭建成功，服務都跑起來，而且監控顯示綠色的。。。。很開心。。。

但是，在hbase上建立表時，發現。。。無法建立成功，而且，日誌也不報錯。。。最後發現hdfs,hbase  ，data節點，RegionServer不在同一個組內，調整到同一個組內後，建立表成功，但是在put 資料時，又遇到了毫無反應的結果。。。資料寫入不成功，而且報錯。master,hdfs

上的日誌只是一直重複報錯如下：

最後我們反思總結如下：我們在雲虛擬機器上建立hadoop叢集本身就是有問題的。在虛擬化的基礎上虛擬化就造成如下問題：

2015-03-13 15:59:00,316 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: there are no corrupt file blocks.
2015-03-13 15:59:00,353 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* allocateBlock: /tmp/.cloudera_health_monitoring_canary_files/.canary_file_2015_03_13-15_59_00. BP-87519020-10.105.33.34-1426218223633 blk_1073742066_1250{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1, replicas=[ReplicaUnderConstruction[[DISK]DS-fbf7c49f-0eac-481c-a85c-b32fa7e4e876:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-109ff584-e6cb-4169-8928-00f5f8b4cd70:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-022f1e9a-27a4-48c3-be3a-d3a179b6fd78:NORMAL|RBW]]}
2015-03-13 15:59:00,374 INFO BlockStateChange: BLOCK* addStoredBlock: blockMap updated: 10.143.34.48:50010 is added to blk_1073742066_1250{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1, replicas=[ReplicaUnderConstruction[[DISK]DS-fbf7c49f-0eac-481c-a85c-b32fa7e4e876:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-109ff584-e6cb-4169-8928-00f5f8b4cd70:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-022f1e9a-27a4-48c3-be3a-d3a179b6fd78:NORMAL|RBW]]} size 0
2015-03-13 15:59:00,376 INFO BlockStateChange: BLOCK* addStoredBlock: blockMap updated: 10.105.33.34:50010 is added to blk_1073742066_1250{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1, replicas=[ReplicaUnderConstruction[[DISK]DS-fbf7c49f-0eac-481c-a85c-b32fa7e4e876:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-109ff584-e6cb-4169-8928-00f5f8b4cd70:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-022f1e9a-27a4-48c3-be3a-d3a179b6fd78:NORMAL|RBW]]} size 0
2015-03-13 15:59:00,377 INFO BlockStateChange: BLOCK* addStoredBlock: blockMap updated: 10.237.142.111:50010 is added to blk_1073742066_1250{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1, replicas=[ReplicaUnderConstruction[[DISK]DS-fbf7c49f-0eac-481c-a85c-b32fa7e4e876:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-109ff584-e6cb-4169-8928-00f5f8b4cd70:NORMAL|RBW], ReplicaUnderConstruction[[DISK]DS-022f1e9a-27a4-48c3-be3a-d3a179b6fd78:NORMAL|RBW]]} size 0
2015-03-13 15:59:00,379 INFO org.apache.hadoop.hdfs.StateChange: DIR* completeFile: /tmp/.cloudera_health_monitoring_canary_files/.canary_file_2015_03_13-15_59_00 is closed by DFSClient_NONMAPREDUCE_806837337_74
2015-03-13 15:59:00,386 INFO BlockStateChange: BLOCK* addToInvalidates: blk_1073742066_1250 10.237.142.111:50010 10.105.33.34:50010 10.143.34.48:50010 
2015-03-13 15:59:01,545 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* BlockManager: ask 10.237.142.111:50010 to delete [blk_1073742001_1185, blk_1073742066_1250]
2015-03-13 15:59:04,545 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* BlockManager: ask 10.143.34.48:50010 to delete [blk_1073742001_1185, blk_1073742066_1250]
2015-03-13 15:59:07,546 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* BlockManager: ask 10.105.33.34:50010 to delete [blk_1073742066_1250]
2015-03-13 15:59:25,293 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Rescanning after 30000 milliseconds
2015-03-13 15:59:25,294 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Scanned 0 directive(s) and 0 block(s) 

隨著Apache Hadoop的起步，雲客戶的增多面臨的首要問題就是如何為他們新的的Hadoop叢集選擇合適的硬體。

儘管Hadoop被設計為執行在行業標準的硬體上，提出一個理想的叢集配置不想提供硬體規格列表那麼簡單。 選擇硬體，為給定的負載在效能和經濟性提供最佳平衡是需要測試和驗證其有效性。（比如，IO密集型工作負載的使用者將會為每個核心主軸投資更多）。

在這個部落格帖子中，你將會學到一些工作負載評估的原則和它在硬體選擇中起著至關重要的作用。在這個過程中，你也將學到Hadoop管理員應該考慮到各種因素。

結合儲存和計算

過去的十年，IT組織已經標準化了刀鋒伺服器和儲存區域網(SAN)來滿足聯網和處理密集型的工作負載。儘管這個模型對於一些方面的標準程式是有相當意義 的，比如網站伺服器，程式伺服器，小型結構化資料庫，資料移動等，但隨著資料數量和使用者數的增長，對於基礎設施的要求也已經改變。網站伺服器現在有了快取 層；資料庫需要本地硬碟支援大規模地並行；資料遷移量也超過了本地可處理的數量。

大部分的團隊還沒有弄清楚實際工作負載需求就開始搭建他們的Hadoop叢集。

硬體提供商已經生產了創新性的產品系統來應對這些需求，包括儲存刀鋒伺服器，序列SCSI交換機，外部SATA磁碟陣列和大容量的機架單元。然 而，Hadoop是基於新的實現方法，來儲存和處理複雜資料，並伴隨著資料遷移的減少。 相對於依賴SAN來滿足大容量儲存和可靠性，Hadoop在軟體層次處理大資料和可靠性。

Hadoop在一簇平衡的節點間分派資料並使用同步複製來保證資料可用性和容錯性。因為資料被分發到有計算能力的節點，資料的處理可以被直接傳送到儲存有資料的節點。由於Hadoop叢集中的每一臺節點都儲存並處理資料，這些節點都需要配置來滿足資料儲存和運算的要求。

 工作負載很重要嗎？

在幾乎所有情形下，MapReduce要麼會在從硬碟或者網路讀取資料時遇到瓶頸（稱為IO受限的應用），要麼在處理資料時遇到瓶頸（CPU受限）。排序是一個IO受限的例子，它需要很少的CPU處理（僅僅是簡單的比較操作），但是需要大量的從硬碟讀寫資料。模式分類是一個CPU受限的例子，它對資料進行復雜的處理，用來判定本體。

下面是更多IO受限的工作負載的例子：

• 索引
• 分組
• 資料匯入匯出
• 資料移動和轉換

下面是更多CPU受限的工作負載的例子：

• 聚類/分類
• 複雜文字挖掘
• 自然語言處理
• 特徵提取

Cloudera的客戶需要完全理解他們的工作負載，這樣才能選擇最優的Hadoop硬體，而這好像是一個雞生蛋蛋生雞的問題。大多數工作組在沒有徹底剖 析他們的工作負載時，就已經搭建好了Hadoop叢集，通常Hadoop執行的工作負載隨著他們的精通程度的提高而完全不同。而且，某些工作負載可能會被 一些未預料的原因受限。例如，某些理論上是IO受限的工作負載卻最終成為了CPU受限，這是可能是因為使用者選擇了不同的壓縮演算法，或者演算法的不同實現改變 了MapReduce任務的約束方式。基於這些原因，當工作組還不熟悉要執行任務的型別時，深入剖析它才是構建平衡的Hadoop叢集之前需要做的最合理 的工作。

接下來需要在叢集上執行MapReduce基準測試任務，分析它們是如何受限的。完成這個目標最直接的方法是在執行中的工作負載中的適當位置新增監視器來 檢測瓶頸。我們推薦在Hadoop叢集上安裝Cloudera Manager，它可以提供CPU，硬碟和網路負載的實時統計資訊。（Cloudera Manager是Cloudera 標準版和企業版的一個元件，其中企業版還支援滾動升級）Cloudera Manager安裝之後，Hadoop管理員就可以執行MapReduce任務並且檢視Cloudera Manager的儀表盤，用來監測每臺機器的工作情況。

第一步是弄清楚你的作業組已經擁有了哪些硬體

在為你的工作負載構建合適的叢集之外，我們建議客戶和它們的硬體提供商合作確定電力和冷卻方面的預算。由於Hadoop會執行在數十臺，數百臺到數千臺節 點上。通過使用高效能功耗比的硬體，作業組可以節省一大筆資金。硬體提供商通常都會提供監測功耗和冷卻方面的工具和建議。

為你的CDH(Cloudera distribution for Hadoop) Cluster選擇硬體

選擇機器配置型別的第一步就是理解你的運維團隊已經在管理的硬體型別。在購買新的硬體裝置時，運維團隊經常根據一定的觀點或者強制需求來選擇，並且他們傾 向於工作在自己業已熟悉的平臺型別上。Hadoop不是唯一的從規模效率上獲益的系統。再一次強調，作為更通用的建議，如果叢集是新建立的或者你並不能準 確的預估你的極限工作負載，我們建議你選擇均衡的硬體型別。

Hadoop叢集有四種基本任務角色:名稱節點（包括備用名稱節點），工作追蹤節點，任務執行節點，和資料節點。節點是執行某一特定功能的工作站。大部分你的叢集內的節點需要執行兩個角色的任務，作為資料節點（資料儲存）和任務執行節點（資料處理）。

 這是在一個平衡Hadoop叢集中，為資料節點/任務追蹤器提供的推薦規格：

• 在一個磁碟陣列中要有12到24個1~4TB硬碟
• 2個頻率為2~2.5GHz的四核、六核或八核CPU
• 64~512GB的記憶體
• 有保障的千兆或萬兆乙太網（儲存密度越大，需要的網路吞吐量越高）

名位元組點角色負責協調叢集上的資料儲存，作業追蹤器協調資料處理（備用的名位元組點不應與叢集中的名位元組點共存，並且執行在與之相同的硬體環境上。）。 Cloudera推薦客戶購買在RAID1或10配置上有足夠功率和企業級磁碟數的商用機器來執行名位元組點和作業追蹤器。

  NameNode也會直接需要與群集中的資料塊的數量成比列的RAM。一個好的但不精確的規則是對於儲存在分散式檔案系統裡面的每一個1百萬的資料塊，分 配1GB的NameNode記憶體。於在一個群集裡面的100個DataNodes而言，NameNode上的64GB的RAM提供了足夠的空間來保證群集 的增長。我們也推薦把HA同時配置在NameNode和JobTracker上，

這裡就是為NameNode／JobTracker／Standby NameNode節點群推薦的技術細節。驅動器的數量或多或少，將取決於冗餘數量的需要。

• 4–6 1TB 硬碟驅動器 採用 一個  JBOD 配置 (1個用於OS, 2個用於檔案系統映像[RAID 1], 1個用於Apache ZooKeeper, 1個用於Journal節點)
• 2 4-/16-/8-核心 CPUs, 至少執行於 2-2.5GHz
• 64-128GB 隨機儲存器
• Bonded Gigabit 乙太網卡 or 10Gigabit 乙太網卡

記住, 在思想上，Hadoop 體系設計為用於一種並行環境。

  如果你希望Hadoop叢集擴充套件到20臺機器以上，那麼我們推薦最初配置的叢集應分佈在兩個機架，而且每個機架都有一個位於機架頂部的10G的乙太網交 換。當這個叢集跨越多個機架的時候，你將需要新增核心交換機使用40G的乙太網來連線位於機架頂部的交換機。兩個邏輯上分離的機架可以讓維護團隊更好地理 解機架內部和機架間通訊對網路需求。

Hadoop叢集安裝好後，維護團隊就可以開始確定工作負載，並準備對這些工作負載進行基準測試以確定硬體瓶頸。經過一段時間的基準測試和監視，維護團隊 將會明白如何配置新增的機器。異構的Hadoop叢集是很常見的，尤其是在叢集中使用者機器的容量和數量不斷增長的時候更常見-因此為你的工作負載所配置的 “不理想”開始時的那組機器不是在浪費時間。Cloudera管理器提供了允許分組管理不同硬體配置的模板，通過這些模板你就可以簡單地管理異構叢集了。

 下面是針對不同的工作負載所採用對應的各種硬體配置的列表，包括我們最初推薦的“負載均衡”的配置：

• 輕量處理方式的配置(1U的機器）:兩個16核的CPU，24-64GB的記憶體以及8張硬碟（每張1TB或者2TB)。

• 負載均衡方式的配置(1U的機器）:兩個16核的CPU，48-128GB的記憶體以及由主機板控制器直接連線的12-16張硬碟（每張1TB或者2TB)。通常在一個2U的櫃子裡使用2個主機板和24張硬碟實現相互備份。

• 超大儲存方式的配置(2U的機器）:兩個16核的CPU，48-96GB的記憶體以及16-26張硬碟（每張2TB-4TB)。這種配置在多個節點/機架失效時會產生大量的網路流量。

• 強力運算方式的配置(2U的機器）:兩個16核的CPU，64-512GB的記憶體以及4-8張硬碟（每張1TB或者2TB)。

（注意Cloudera期望你配置它可以使用的2×8,2×10和2×12核心CPU的配置。)

下圖向你展示瞭如何根據工作負載來配置一臺機器：

其他要考慮的

記住Hadoop生態系統的設計是考慮了並行環境這點非常重要。當購買處理器時，我們不建議購買最高頻率(GHZ)的晶片，這些晶片都有很高的功耗 （130瓦以上）。這麼做會產生兩個問題：電量消耗會更高和熱量散發會更大。處在中間型號的CPU在頻率、價格和核心數方面價效比是最好的。

當我們碰到生成大量中間資料的應用時-也就是說輸出資料的量和讀入資料的量相等的情況-我們推薦在單個乙太網介面卡上啟用兩個埠，或者捆綁兩個乙太網 卡，讓每臺機器提供2Gbps的傳輸速率。繫結2Gbps的節點最多可容納的資料量是12TB。一旦你傳輸的資料超過12TB，你將需要使用傳輸速率為捆 綁方式實現的4Gbps(4x1Gbps)。另外，對哪些已經使用10Gb頻寬的乙太網或者無線網路使用者來說，這樣的方案可以用來按照網路頻寬實現工作負 載的分配。如果你正在考慮切換到10GB的乙太網路上，那麼請確認作業系統和BIOS是否相容這樣的功能。

當計算需要多少記憶體的時候，記住Java本身要使用高達10%的記憶體來管理虛擬機器。我們建議把Hadoop配置為只使用堆，這樣就可以避免記憶體與磁碟之間 的切換。切換大大地降低MapReduce任務的效能，並且可以通過給機器配置更多的記憶體以及給大多數Linux釋出版以適當的核心設定就可以避免這種切 換。

優化記憶體的通道寬度也是非常重要的。例如，當我們使用雙通道記憶體時，每臺機器就應當配置成對記憶體模組（DIMM）。當我們使用三通道的記憶體時，每臺機器都應當使用三的倍數個記憶體模組（DIMM）。類似地，四通道的記憶體模組（DIMM)就應當按四來分組使用記憶體。

 超越MapReduce

Hadoop不僅僅是HDFS和MapReduce；它是一個無所不包的資料平臺。因此CDH包含許多不同的生態系統產品（實際上很少僅僅做為 MapReduce使用）。當你在為叢集選型的時候，需要考慮的附加軟體元件包括Apache HBase、Cloudera Impala和Cloudera Search。它們應該都執行在DataNode中來維護資料區域性性。

關注資源管理是你成功的關鍵。

HBase是一個可靠的列資料儲存系統，它提供一致性、低延遲和隨機讀寫。Cloudera Search解決了CDH中儲存內容的全文字搜尋的需求，為新型別使用者簡化了訪問，但是也為Hadoop中新型別資料儲存提供了機會。Cloudera Search基於Apache Lucene/Solr Cloud和Apache Tika，並且為與CDH廣泛整合的搜尋擴充套件了有價值的功能和靈活性。基於Apache協議的Impala專案為Hadoop帶來了可擴充套件的並行資料庫技 術，使得使用者可以向HDFS和HBase中儲存的資料發起低延遲的SQL查詢，而且不需要資料移動或轉換。

由於垃圾回收器（GC）的超時，HBase 的使用者應該留意堆的大小的限制。別的JVM列儲存也面臨這個問題。因此，我們推薦每一個區域伺服器的堆最大不超過16GB。HBase不需要太多別的資源 而執行於Hadoop之上，但是維護一個實時的SLAs，你應該使用多個排程器，比如使用fair and capacity 排程器，並協同Linux Cgroups使用。

 

Impala使用記憶體以完成其大多數的功能，在預設的配置下，將最多使用80％的可用RAM資源，所以我們推薦，最少每一個節點使用96GB的RAM。與MapReduce一起使用Impala的使用者，可以參考我們的建議 － “Configuring Impala and MapReduce for Multi-tenant Performance.” 也可以為Impala指定特定程式所需的記憶體或者特定查詢所需的記憶體。

搜尋是最有趣的訂製大小的元件。推薦的訂製大小的實踐操作是購買一個節點，安裝Solr和Lucene，然後載入你的文件群。一旦文件群被以期望的方式來 索引和搜尋，可伸縮性將開始作用。持續不斷的載入文件群，直到索引和查詢的延遲，對於專案而言超出了必要的數值 － 此時，這讓你得到了在可用的資源上每一個節點所能處理的最大文件數目的基數，以及不包括欲期的叢集複製此因素的節點的數量總計基數。

結論

購買合適的硬體，對於一個Hapdoop群集而言，需要效能測試和細心的計劃，從而全面理解工作負荷。然而，Hadoop群集通常是一個形態變化的系統， 而Cloudera建議，在開始的時候，使用負載均衡的技術文件來部署啟動的硬體。重要的是，記住，當使用多種體系元件的時候，資源的使用將會是多樣的， 而專注與資源管理將會是你成功的關鍵。

我們鼓勵你在留言中，加入你關於配置Hadoop生產群集伺服器的經驗！

Kevin O‘Dell 是一個工作於Cloudera的系統工程師。

英文原文：How-to: Select the Right Hardware for Your New Hadoop Cluster

翻譯：http://www.oschina.net/translate/how-to-select-the-right-hardware-for-your-new-hadoop-cluster

附：

淘寶Hadoop叢集機器硬體配置

國內外使用Hadoop的公司比較多，全球最大的Hadoop叢集在雅虎，有大約25000個節點，主要用於支援廣告系統與網頁搜尋。國內用Hadoop的主要有百度、淘寶、騰訊、華為、中國移動等，其中淘寶的Hadoop叢集屬於較大的（如果不是最大）。

淘寶Hadoop叢集現在超過1700個節點，服務於用於整個阿里巴巴集團各部門，資料來源於各部門產品的線上資料庫（Oracle, MySQL）備份，系統日誌以及爬蟲資料，截止2011年9月，數量總量已經超過17個PB，每天淨增長20T左右。每天在Hadoop叢集執行的MapReduce任務有超過4萬（有時會超過6萬），其中大部分任務是每天定期執行的統計任務，例如資料魔方、量子統計、推薦系統、排行榜等等。這些任務一般在凌晨1點左右開始執行，3-4個小時內全部完成。每天讀資料在2PB左右，寫資料在1PB左右。

 

this picture is from Taobao

Hadoop包括兩類節點Master和Slave節點，

• Master節點包括Jobtracker，Namenode, SecondName, Standby，
  • 硬體配置：16CPU*4核，96G記憶體。
• Slave節點主要是TaskTracker和DataNode，
  • 硬體配置存在一定的差別：8CPU*4核-16CPU*4核，16G-24G記憶體
  • （注：通常是一個slave節點同時是TaskTracker和DataNode，目的是提高資料本地性data locality）。
  • 每個slave節點會劃分成12~24個slots。整個叢集約34,916個slots，其中Map slots是19,643個，Reduce slots是15，273個

所有作業會進行分成多個Group，按照部門或小組劃分，總共有38個Group。整個叢集的資源也是按各個Group進行劃分，定義每個Group的最大併發任務數，Map slots與Reduce slots的使用上限。每個作業只能使用自己組的slots資源。