隨着Apache Hadoop的起步,雲客戶的增多面臨的首要問題就是如何爲他們新的的Hadoop集羣選擇合適的硬件。算法
儘管Hadoop被設計爲運行在行業標準的硬件上,提出一個理想的集羣配置不想提供硬件規格列表那麼簡單。 選擇硬件,爲給定的負載在性能和經濟性提供最佳平衡是須要測試和驗證其有效性。(好比,IO密集型工做負載的用戶將會爲每一個核心主軸投資更多)。數據庫
在這個博客帖子中,你將會學到一些工做負載評估的原則和它在硬件選擇中起着相當重要的做用。在這個過程當中,你也將學到Hadoop管理員應該考慮到各類因素。 緩存
Cloudera的客戶須要徹底理解他們的工做負載,這樣才能選擇最優的Hadoop硬件,而這好像是一個雞生蛋蛋生雞的問題。大多數工做組在沒有完全剖析他們的工做負載時,就已經搭建好了Hadoop集羣,一般Hadoop運行的工做負載隨着他們的精通程度的提升而徹底不一樣。並且,某些工做負載可能會被一些未預料的緣由受限。例如,某些理論上是IO受限的工做負載卻最終成爲了CPU受限,這是多是由於用戶選擇了不一樣的壓縮算法,或者算法的不一樣實現改變了MapReduce任務的約束方式。基於這些緣由,當工做組還不熟悉要運行任務的類型時,深刻剖析它纔是構建平衡的Hadoop集羣以前須要作的最合理的工做。 |
接下來須要在集羣上運行MapReduce基準測試任務,分析它們是如何受限的。完成這個目標最直接的方法是在運行中的工做負載中的適當位置添加監視器來檢測瓶頸。咱們推薦在Hadoop集羣上安裝Cloudera Manager,它能夠提供CPU,硬盤和網絡負載的實時統計信息。(Cloudera Manager是Cloudera 標準版和企業版的一個組件,其中企業版還支持滾動升級)Cloudera Manager安裝以後,Hadoop管理員就能夠運行MapReduce任務而且查看Cloudera Manager的儀表盤,用來監測每臺機器的工做狀況。 |
第一步是弄清楚你的做業組已經擁有了哪些硬件 在爲你的工做負載構建合適的集羣以外,咱們建議客戶和它們的硬件提供商合做肯定電力和冷卻方面的預算。因爲Hadoop會運行在數十臺,數百臺到數千臺節點上。經過使用高性能功耗比的硬件,做業組能夠節省一大筆資金。硬件提供商一般都會提供監測功耗和冷卻方面的工具和建議。 |
這是在一個平衡Hadoop集羣中,爲數據節點/任務追蹤器提供的推薦規格:
名字節點角色負責協調集羣上的數據存儲,做業追蹤器協調數據處理(備用的名字節點不該與集羣中的名字節點共存,而且運行在與之相同的硬件環境上。)。Cloudera推薦客戶購買在RAID1或10配置上有足夠功率和企業級磁盤數的商用機器來運行名字節點和做業追蹤器。 |
NameNode也會直接須要與羣集中的數據塊的數量成比列的RAM。一個好的但不精確的規則是對於存儲在分佈式文件系統裏面的每個1百萬的數據塊,分配1GB的NameNode內存。於在一個羣集裏面的100個DataNodes而言,NameNode上的64GB的RAM提供了足夠的空間來保證羣集的增加。咱們也推薦把HA同時配置在NameNode和JobTracker上, 這裏就是爲NameNode/JobTracker/Standby NameNode節點羣推薦的技術細節。驅動器的數量或多或少,將取決於冗餘數量的須要。
記住, 在思想上,Hadoop 體系設計爲用於一種並行環境。 |
若是你但願Hadoop集羣擴展到20臺機器以上,那麼咱們推薦最初配置的集羣應分佈在兩個機架,並且每一個機架都有一個位於機架頂部的10G的以太網交換。當這個集羣跨越多個機架的時候,你將須要添加核心交換機使用40G的以太網來鏈接位於機架頂部的交換機。兩個邏輯上分離的機架可讓維護團隊更好地理解機架內部和機架間通訊對網絡需求。 Hadoop集羣安裝好後,維護團隊就能夠開始肯定工做負載,並準備對這些工做負載進行基準測試以肯定硬件瓶頸。通過一段時間的基準測試和監視,維護團隊將會明白如何配置添加的機器。異構的Hadoop集羣是很常見的,尤爲是在集羣中用戶機器的容量和數量不斷增加的時候更常見-所以爲你的工做負載所配置的「不理想」開始時的那組機器不是在浪費時間。Cloudera管理器提供了容許分組管理不一樣硬件配置的模板,經過這些模板你就能夠簡單地管理異構集羣了。 |
下面是針對不一樣的工做負載所採用對應的各類硬件配置的列表,包括咱們最初推薦的「負載均衡」的配置:
(注意Cloudera指望你配置它可使用的2x8,2x10和2x12核心CPU的配置。) 下圖向你展現瞭如何根據工做負載來配置一臺機器: |
其餘要考慮的 記住Hadoop生態系統的設計是考慮了並行環境這點很是重要。當購買處理器時,咱們不建議購買最高頻率(GHZ)的芯片,這些芯片都有很高的功耗(130瓦以上)。這麼作會產生兩個問題:電量消耗會更高和熱量散發會更大。處在中間型號的CPU在頻率、價格和核心數方面性價比是最好的。 當咱們碰到生成大量中間數據的應用時-也就是說輸出數據的量和讀入數據的量相等的狀況-咱們推薦在單個以太網接口卡上啓用兩個端口,或者捆綁兩個以太網卡,讓每臺機器提供2Gbps的傳輸速率。綁定2Gbps的節點最多可容納的數據量是12TB。一旦你傳輸的數據超過12TB,你將須要使用傳輸速率爲捆綁方式實現的4Gbps(4x1Gbps)。另外,對哪些已經使用10Gb帶寬的以太網或者無線網絡用戶來講,這樣的方案能夠用來按照網絡帶寬實現工做負載的分配。若是你正在考慮切換到10GB的以太網絡上,那麼請確認操做系統和BIOS是否兼容這樣的功能。 |
當計算須要多少內存的時候,記住Java自己要使用高達10%的內存來管理虛擬機。咱們建議把Hadoop配置爲只使用堆,這樣就能夠避免內存與磁盤之間的切換。切換大大地下降MapReduce任務的性能,而且能夠經過給機器配置更多的內存以及給大多數Linux發佈版以適當的內核設置就能夠避免這種切換。 優化內存的通道寬度也是很是重要的。例如,當咱們使用雙通道內存時,每臺機器就應當配置成對內存模塊(DIMM)。當咱們使用三通道的內存時,每臺機器都應當使用三的倍數個內存模塊(DIMM)。相似地,四通道的內存模塊(DIMM)就應當按四來分組使用內存。 |
因爲垃圾回收器(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的系統工程師。 |