不開玩笑，Hadoop集群容量還可以這樣擴展

作者：趙建寧 2020-06-03 10:54:28

企業動態 Hadoop

由戴爾科技集團中國研究院及VMware創新網絡主辦的《前沿“機器學習加速”網絡研討會》第四期來啦。

了解更多數字化轉型方案查看此鏈接：

https://www.dellemc-solution.com/home/index.html

說起Hadoop

它的大名在IT圈已是

無人不知，無人不曉

Hadoop的出現

讓用戶可以在不了解

分布式底層細節的情況下

開發分布式程序

同時還能充分利用集群的威力

進行高速運算和存儲

就好比螞蟻賽大象

廉價的機器群也可以匹敵高性能計算機

但另一方面

越來越多客戶

不斷縮短Hadoop節點的購買周期

原因就是存儲空間不足！

而如果按容量需求購買大量服務器

則會有大量計算資源被浪費

因此，面對突如其來的海量數據，我們是沿用原有的橫向擴展node方式還是縱向擴展存儲呢？如果采用存儲縱向擴展方式，那該如何連接？用什么存儲？是否會帶來管理復雜度？是否會影響性能？架構如何搭建？

Hadoop分布式架構+存儲

不是開玩笑！

聽到Hadoop分布式架構+存儲這一概念，相信會有很多人質疑這種架構，也會有人認為小編不懂Hadoop，沒有互聯網基因。哈哈，不管了，提起Hadoop橫向擴展的全分布式架構，幾乎90%以上的用戶應該都是橫向對等的擴展node（即服務器），很少有人會在Hadoop架構下聯想存儲的使用方法。

其實小編最初也是一樣的想法，Hadoop用什么存儲？用什么存儲看起來都不完美，原諒我對機房的布局有強迫癥，不喜歡那種不對稱的布局。但隨著Hadoop客戶的不斷壯大，他們面臨的現實需求卻在不斷地敲打著我。

[[328741]]

雖然很多客戶對Hadoop架構下使用存儲抱有抵觸的思想，但也有不少客戶在嘗試，逐步認識到Hadoop架構下使用一些特定存儲并沒有破壞Hadoop的全分布式結構，也沒有改變Hadoop對磁盤的管理。只是我們在不斷橫向擴展節點的同時，適時的也可以關注一下存儲磁盤的縱向擴展。

看到這里，你還懷疑小編是來說大話的嗎？哈哈，我們繼續下去，先簡單介紹一下Hadoop。

Hadoop是一個由Apache基金會所開發的分布式系統基礎架構。Hadoop實現了一個分布式文件系統（Hadoop Distributed File System），簡稱HDFS。HDFS有高容錯性特點，并且設計用來部署在低廉的硬件上，它還提供高吞吐量來訪問應用程序的數據，適合那些有著超大數據集的應用程序。

Hadoop的出現，也讓軟件定義存儲的使用達到了一個前所未有的高度，在一些互聯網類的企業里，少則十幾個節點，多則幾千個節點的Hadoop集群拔地而起，應用場景越來越豐富，數據量也帶來了幾何倍數的增長。

從開頭的話題我們知道，面對海量數據，如果繼續沿用橫向擴展node方式擴展，必然會造成浪費，因此本文就來分享一些客戶在Hadoop環境下使用JBOD存儲，從而減低整體成本的使用方法。

關于JBOD

JBOD（Justa bunch of disk）俗稱硬盤擴展柜。也就是說，這套存儲并沒有控制器單元，也沒有配置CPU/內存等部件，也沒有對磁盤的RAID管理，它非常簡單，也非常經典。正因為JBOD本身不配置任何邏輯管理，將全部磁盤管理都交由Hadoop，所以JBOD能和Hadoop完美融合。

下面，我們就來介紹JBOD是如何讓Hadoop集群變得更經濟、更環保。

[[328742]]

一波三折的擴展磁盤方式

首先，Hadoop中除了應用的組件之外，主要有兩種node是我們經常關注的，一個是Master node，一個是Data node，如下圖所示，客戶的Master node繼續沿用R640/R630的1U服務器節點，Data node沿用戴爾易安信R740/R730服務器。通過Edge node與Client端（Hadoop Component Client）進行通訊。

隨著業務不斷的發展，Hadoop集群也需要不斷的擴展，此時細心的客戶運維人員發現，最近幾次的節點擴展都是因為磁盤容量不夠造成的，其實節點內的CPU/內存占用率并不高。所以能否有一種只擴展磁盤的簡單方式呢？

▐ 開始總會走一些彎路。我們推薦了帶有控制器的智能存儲設備，想用智能存儲的功能替代Hadoop的管理，結果使用效果不好。

Hadoop想全控磁盤，而智能存儲對磁盤又有自己的理解，所以造成兩種結果，要么是將一部分業務分拆出來，單獨用存儲提供數據服務；要么是將智能存儲放在Hadoop架構使用，很多高級功能又不能發揮作用。

▐ 于是我們換第二種方案，用低端的帶有控制器的存儲設備，通過FC/iSCSI方式將磁盤映射給Data node使用。

結果在測試過程中，發現條帶化后的磁盤，在Hadoop架構下，反而降低了性能，同時HDFS（Hadoop的文件系統）所提供的節點間數據復制技術已滿足數據備份需求，無需使用RAID的冗余機制。因此這種方案也被否定。

這樣看來，只有最簡單的JBOD可以再次嘗試一下，這是一個不帶任何邏輯管理的磁盤組，他沒有帶控制器存儲的RAID條帶技術。盡管RAID條帶化技術(RAID 0)被廣泛用戶提升性能，但是其速度仍然比用在HDFS里的JBOD配置慢。

JBOD在所有磁盤之間循環調度HDFS塊。RAID 0的讀寫操作受限于磁盤陣列中最慢盤片的速度，而JBOD的磁盤操作均獨立，因而平均讀寫速度高于最慢盤片的讀寫速度。需要強調的是，各個磁盤的性能在實際使用中總存在相當大的差異，即使對于相同型號的磁盤。在一個測試(Gridmix)中，JBOD比RAID 0 快10%；在另一測試（HDFS寫吞吐量）中，JBOD比RAID 0 快30%。

[[328743]]

好了，既然JBOD本身性能不差，那么接口會不會慢呢？

接口當然是4通道的12Gb SAS，轉換一下單位，每個接口可以達到6GB/s左右的速率，要知道每一塊7200轉的機械磁盤實際讀寫速率基本上在100MB/s左右。而一個84盤位的JBOD可以提供6個12Gb SAS接口，理論上可以同時連接6個Data node進行數據訪問，并發帶寬理論上可以達到36GB/s的接口速率。（實際不可能用到這么大帶寬，畢竟后端的磁盤數量是有限的，所以瓶頸不在接口）。

性能看來不是問題，那么Data node上要做什么改變呢？

是否需要很復雜的驅動程序？是否會影響Data node上的組件運行？答案其實很簡單，只需要在Data node上安裝最常用的12Gb SAS卡即可，Linux操作系統下，其驅動也是極其輕量的安裝程序，并不會對上層的組件有任何影響。

于是，就有了上圖。在一個10PB+的Hadoop集群中，已然發現了JBOD的身影，通過JBOD的引入，極大降低了Data node的擴展，從而讓機柜空間降低了65%，功耗降低了37%，總體成本降低了35%！對客戶來說，這可都是真金白銀的成本節省啊。

最后，來介紹一下戴爾易安信的JBOD家族吧

目前，戴爾易安信PowerVault存儲系列有MD1400、MD1420和ME484三款JBOD擴展機柜選項，可與第13代和第14代PowerEdge服務器配合使用，借助豐富的盤柜選項、硬盤類型和操作系統選項幫助用戶實現輕松擴展，并以靈活的設計方案滿足用戶的特定需求。同時節省在空間、電力和冷卻方面的支出。

擴展Hadoop集群容量，這里還有經濟又實用的方式！