但另一方面
越來越多客戶
不斷縮短Hadoop節(jié)點的購買周期
原因就是存儲空間不足!
而如果按容量需求購買大量服務(wù)器
則會有大量計算資源被浪費
因此,面對突如其來的海量數(shù)據(jù),我們是沿用原有的橫向擴展node方式還是縱向擴展存儲呢?如果采用存儲縱向擴展方式,那該如何連接?用什么存儲?是否會帶來管理復雜度?是否會影響性能?架構(gòu)如何搭建?
Hadoop分布式架構(gòu)+存儲
不是開玩笑!
聽到Hadoop分布式架構(gòu)+存儲這一概念,相信會有很多人質(zhì)疑這種架構(gòu),也會有人認為小編不懂Hadoop,沒有互聯(lián)網(wǎng)基因。哈哈,不管了,提起Hadoop橫向擴展的全分布式架構(gòu),幾乎90%以上的用戶應(yīng)該都是橫向?qū)Φ鹊臄U展(即服務(wù)器),很少有人會在Hadoop架構(gòu)下聯(lián)想存儲的使用方法。
其實小編最初也是一樣的想法,Hadoop用什么存儲?用什么存儲看起來都不完美,原諒我對機房的布局有強迫癥,不喜歡那種不對稱的布局。但隨著Hadoop客戶的不斷壯大,他們面臨的現(xiàn)實需求卻在不斷地敲打著我。
雖然很多客戶對Hadoop架構(gòu)下使用存儲抱有抵觸的思想,但也有不少客戶在嘗試,逐步認識到Hadoop架構(gòu)下使用一些特定存儲并沒有破壞Hadoop的全分布式結(jié)構(gòu),也沒有改變Hadoop對磁盤的管理。只是我們在不斷橫向擴展節(jié)點的同時,適時的也可以關(guān)注一下存儲磁盤的縱向擴展。
看到這里,你還懷疑小編是來說大話的嗎?哈哈,我們繼續(xù)下去,先簡單介紹一下Hadoop。
Hadoop是一個由Apache基金會所開發(fā)的分布式系統(tǒng)基礎(chǔ)架構(gòu)。Hadoop實現(xiàn)了一個分布式文件系統(tǒng)(Hadoop Distributed File System),簡稱HDFS。HDFS有高容錯性特點,并且設(shè)計用來部署在低廉的硬件上,它還提供高吞吐量來訪問應(yīng)用程序的數(shù)據(jù),適合那些有著超大數(shù)據(jù)集的應(yīng)用程序。
Hadoop的出現(xiàn),也讓軟件定義存儲的使用達到了一個前所未有的高度,在一些互聯(lián)網(wǎng)類的企業(yè)里,少則十幾個節(jié)點,多則幾千個節(jié)點的Hadoop集群拔地而起,應(yīng)用場景越來越豐富,數(shù)據(jù)量也帶來了幾何倍數(shù)的增長。
從開頭的話題我們知道,面對海量數(shù)據(jù),如果繼續(xù)沿用橫向擴展node方式擴展,必然會造成浪費,因此本文就來分享一些客戶在Hadoop環(huán)境下使用JBOD存儲,從而減低整體成本的使用方法。
關(guān)于JBOD
JBOD(Justa bunch of disk)俗稱硬盤擴展柜。也就是說,這套存儲并沒有控制器單元,也沒有配置CPU/內(nèi)存等部件,也沒有對磁盤的RAID管理,它非常簡單,也非常經(jīng)典。正因為JBOD本身不配置任何邏輯管理,將全部磁盤管理都交由Hadoop,所以JBOD能和Hadoop完美融合。
下面,我們就來介紹JBOD是如何讓Hadoop集群變得更經(jīng)濟、更環(huán)保。
一波三折的擴展磁盤方式
首先,Hadoop中除了應(yīng)用的組件之外,主要有兩種node是我們經(jīng)常關(guān)注的,一個是Master node,一個是Data node,如下圖所示,客戶的Master node繼續(xù)沿用R640/R630的1U服務(wù)器節(jié)點,Data node沿用戴爾易安信R740/R730服務(wù)器。通過Edge node與Client端(Hadoop Component Client)進行通訊。
隨著業(yè)務(wù)不斷的發(fā)展,Hadoop集群也需要不斷的擴展,此時細心的客戶運維人員發(fā)現(xiàn),最近幾次的節(jié)點擴展都是因為磁盤容量不夠造成的,其實節(jié)點內(nèi)的CPU/內(nèi)存占用率并不高。所以能否有一種只擴展磁盤的簡單方式呢?
? 開始總會走一些彎路。我們推薦了帶有控制器的智能存儲設(shè)備,想用智能存儲的功能替代Hadoop的管理,結(jié)果使用效果不好。
Hadoop想全控磁盤,而智能存儲對磁盤又有自己的理解,所以造成兩種結(jié)果,要么是將一部分業(yè)務(wù)分拆出來,單獨用存儲提供數(shù)據(jù)服務(wù);要么是將智能存儲放在Hadoop架構(gòu)使用,很多高級功能又不能發(fā)揮作用。
? 于是我們換第二種方案,用低端的帶有控制器的存儲設(shè)備,通過FC/iSCSI方式將磁盤映射給Data node使用。
結(jié)果在測試過程中,發(fā)現(xiàn)條帶化后的磁盤,在Hadoop架構(gòu)下,反而降低了性能,同時HDFS(Hadoop的文件系統(tǒng))所提供的節(jié)點間數(shù)據(jù)復制技術(shù)已滿足數(shù)據(jù)備份需求,無需使用RAID的冗余機制。因此這種方案也被否定。
這樣看來,只有最簡單的JBOD可以再次嘗試一下,這是一個不帶任何邏輯管理的磁盤組,他沒有帶控制器存儲的RAID條帶技術(shù)。盡管RAID條帶化技術(shù)(RAID 0)被廣泛用戶提升性能,但是其速度仍然比用在HDFS里的JBOD配置慢。
JBOD在所有磁盤之間循環(huán)調(diào)度HDFS塊。RAID 0的讀寫操作受限于磁盤陣列中最慢盤片的速度,而JBOD的磁盤操作均獨立,因而平均讀寫速度高于最慢盤片的讀寫速度。需要強調(diào)的是,各個磁盤的性能在實際使用中總存在相當大的差異,即使對于相同型號的磁盤。在一個測試(Gridmix)中,JBOD比RAID 0 快10%;在另一測試(HDFS寫吞吐量)中,JBOD比RAID 0 快30%。
好了,既然JBOD本身性能不差,那么接口會不會慢呢?
接口當然是4通道的12Gb SAS,轉(zhuǎn)換一下單位,每個接口可以達到6GB/s左右的速率,要知道每一塊7200轉(zhuǎn)的機械磁盤實際讀寫速率基本上在100MB/s左右。而一個84盤位的JBOD可以提供6個12Gb SAS接口,理論上可以同時連接6個Data node進行數(shù)據(jù)訪問,并發(fā)帶寬理論上可以達到36GB/s的接口速率。(實際不可能用到這么大帶寬,畢竟后端的磁盤數(shù)量是有限的,所以瓶頸不在接口)。
性能看來不是問題,那么Data node上要做什么改變呢?
是否需要很復雜的驅(qū)動程序?是否會影響Data node上的組件運行?答案其實很簡單,只需要在Data node上安裝最常用的12Gb SAS卡即可,Linux操作系統(tǒng)下,其驅(qū)動也是極其輕量的安裝程序,并不會對上層的組件有任何影響。
于是,就有了上圖。在一個10PB+的Hadoop集群中,已然發(fā)現(xiàn)了JBOD的身影,通過JBOD的引入,極大降低了Data node的擴展,從而讓機柜空間降低了65%,功耗降低了37%,總體成本降低了35%!對客戶來說,這可都是真金白銀的成本節(jié)省啊。
最后,來介紹一下戴爾易安信的JBOD家族吧
目前,有MD1400、MD1420和ME484三款JBOD擴展機柜選項,可與第13代和第14代PowerEdge服務(wù)器配合使用,借助豐富的盤柜選項、硬盤類型和操作系統(tǒng)選項幫助用戶實現(xiàn)輕松擴展,并以靈活的設(shè)計方案滿足用戶的特定需求。同時節(jié)省在空間、電力和冷卻方面的支出。
擴展Hadoop集群容量,這里還有經(jīng)濟又實用的方式!
尊敬的讀者
由戴爾科技集團中國研究院及
VMware創(chuàng)新網(wǎng)絡(luò)主辦的
《前沿“機器學習加速”網(wǎng)絡(luò)研討會》
第四期來啦
本期內(nèi)容,我們將聚焦
《基于可編程交換機的網(wǎng)絡(luò)計算加速機器學習》
由戴爾科技集團中國研究院
首席工程師 胡晨曦
為您帶來講解
6月5日(周五)
下午14:00-15:00
我們不見不散
掃描下方二維碼或
點擊文末“閱讀原文”即可報名參加
本文作者： 趙建寧
