吳金壇 章超 李樹楠
摘要:隨著大數據的發(fā)展,傳統(tǒng)的集群混合部署模式逐漸暴露出管理難、資源競爭、性能相互制約等問題。計算與存儲分離部署方案不斷發(fā)展,開始呈現其優(yōu)勢,但是在解決計算與存儲資源彈性擴展、高容錯和高可靠問題上,且具備兼顧虛擬機和容器兩種部署方式的能力要求上,目前的方案都相形見絀?;诖?,提出并實現了一種基于Ceph的大數據平臺分離存儲方案,解耦了計算與存儲之間的綁定關系,同時實現了資源的彈性利用,并兼容了虛擬機和容器的兩種大數據部署方式。最后我們搭建了試驗環(huán)境對方案的功能及性能進行了測試,對上述能力進行了驗證。
關鍵詞:大數據;計算與存儲分離;Ceph
中圖分類號:TP31文獻標識碼:A
文章編號:1009-3044(2020)27-0024-04
開放科學(資源服務)標識碼(OSID):
1 引言
隨著大數據的發(fā)展,傳統(tǒng)的集群混合部署模式逐漸暴露出管理難、資源競爭、性能相互制約等問題[1]。由于網絡已不再成為計算機的瓶頸,在這種情況下,計算與存儲分離部署方式開始顯現出它的優(yōu)勢,不僅能解決上述問題,而且能實現計算與存儲資源的彈性擴展,為企業(yè)大幅度降低成本[2][3]。HDFS( Ha-doop Distributed File System)作為主流的分布式系統(tǒng)基礎架構Hadoop的默認后端存儲,具有高容錯、高可靠性、高可擴展性等優(yōu)點,但也存在一些不足之處,不能復用給虛擬機和容器,同時采用主從模式[4],存在單點故障以及內存受限等問題。針對上述這些問題,本文設計并實現了一種Hadoop對接Ceph對象存儲方案,采用Ceph對象存儲作為Hadoop的后端存儲,避免了HDFS的不足之處,在實現了計算與存儲分離的情況下同時兼顧了虛擬機大數據與容器大數據的統(tǒng)一存儲。
2 Hadoop計算與存儲分離
2.1 Hadoop計算與存儲分離概述
Hadoop大數據集群的計算存儲分離指的是將Hadoop大數據處理系統(tǒng)中的計算組件和存儲組件分別部署到不同的物理服務器中,通過高速網絡實現計算組件和存儲組件的消息通信與數據傳輸。計算與存儲分離的優(yōu)點:一、系統(tǒng)更健壯,計算存儲可以各自進行檢錯,系統(tǒng)出錯排查速度快,恢復效率高;二、系統(tǒng)調度更靈活,各自均衡負載實現簡單;三、擴展性好,根據需求動態(tài)調整計算或存儲的資源。計算與存儲分離的缺點:計算與存儲分離,使得中間數據傳輸更依賴于外部網絡,數據的傳輸性能下降。
2.2 現有技術方案
Hadoop計算存儲分離方案目前有三種:第一種是Hadoop與HDFS分離部署方案,通過Yarn進程遠程調用;第二種是Ha-doop與S3A分離部署方案,通過S3A網關的形式把Hadoop的10請求以HTTP的方式訪問遠程存儲;第三種是Hadoop3.x提出的Provided Storage存儲方案,通過HDFS來遠程訪問其他異構存儲。
2.2.1 Hadoop與HDFS分離部署方案
圖1展示了Hadoop HDFS計算存儲分離方案。Hadoop2.x版本的主要進程分為兩部分:一部分進程運行的是資源調度模塊Yarn,包括資源調度ResourceManager以及節(jié)點代理Nodma-nager;另一部分是分布式文件存儲(HDFS)的進程,包括元數據處理NameNode以及數據管理DataNode。這兩個模塊可以獨立運行,可以將NameNode和DataNode部署在一部分物理機上,而Yarn進程部署在其他虛擬機、容器或者物理機上。二者的網絡能夠通信,則計算與存儲就可以分割開。
這種方案的優(yōu)點是配置簡單,兼容性好,因為獨立使用Ha-doop與HDFS進程,在網絡互適時,通過對配置文件修改即可完成大數據集群配置的更改。相應的缺點也很明顯,首先是HDFS屬于文件系統(tǒng),文件過多數據量過大會導致NameNode出現瓶頸;其次,服務器重啟后,NameNode和DataNode進程需要手動重啟;最后,多個大數據集群無法做到文件權限隔離。
2.2.2 Hadoop與S3A分離部署方案
圖2是以S3A網關的形式對提供了對象存儲服務的存儲進行訪問的方案。Hadoop提供了aws相關的jar包來訪問帶有S3A網關形式的對象存儲,這種訪問方式需要數據先經過RGW網關,再到物理磁盤設備上,很明顯會出現網絡帶寬瓶頸的問題,并且S3A網關是通過HTTP短連接的形式來進行數據傳輸,對于大文件非常不友好,性能很差。
2.2.3 Hadoop Provided Storage分離部署方案
圖3展示了Hadoop Provided Storage的存儲方案[5],這種方案允許底層的HDFS調用其他存儲,以達到計算與存儲分離的效果,但是這種方案的不足之處也比較明顯,首先是這種特性只支持文件的讀操作,不支持文件的寫操作,無法做到文件的更新。同時這種數據訪問路徑變長理論上性能會有影響。另外這種特性較新,工業(yè)界還沒有確切的使用案例,因此在實驗與分析章節(jié)沒有做相關實驗。
3 基于Ceph的Hadoop分離存儲方案
Ceph因其高性能、高可用性、高可擴展性、特性豐富等已經成為私有云平臺OpenStack的默認后端存儲[6][7]。Ceph提供三種存儲方式:對象存儲、塊存儲和文件存儲。相對于塊存儲和文件存儲,對象存儲采用鍵值存儲機制,性能更好。
Hadoop的MapReduce框架底層使用的是HDFS分布式文件存儲系統(tǒng),然而Hadoop本身提供了文件系統(tǒng)的擴展機制,使用者可以根據自己的需求來擴展底層的存儲方式,達到替代HDFS的效果?;诖宋覀兲岢隽嘶贑eph的對象存儲實現Hadoop的分離存儲方案:系統(tǒng)底層使用Ceph對象存儲,通過JNA的方式調用封裝了Ceph對象存儲接口的so文件,并在上層擴展了Hadoop的文件系統(tǒng)接口,完成MapReduce、Spark等使用FileSystem接口作為文件系統(tǒng)交互層的大數據集群的遠程文件調用。
如圖4,在Hadoop與Ceph對象存儲架構中,Hadoop與Ceph對象存儲對接器包括Hadoop文件系統(tǒng)兼容接口模塊、Hadoop文件系統(tǒng)操作實現模塊、分布式存儲對象數據訪問模塊三部分組成,其功能如下:
Hadoop文件系統(tǒng)兼容接口模塊:兼容實現Hadoop計算組件所需的FileSystem抽象接口,以屏蔽Hadoop計算應用對文件10的調用差異;實現Yarn資源調用所需要的文件系統(tǒng)接口,以實現對Ceph集群的讀寫。
Hadoop文件系統(tǒng)操作實現模塊:在HDFS接口下實現了文件系統(tǒng)中目錄、文件等的增、刪、改、查能力。
分布式存儲對象數據訪問模塊:對Hadoop文件系統(tǒng)操作實現模塊中所涉及的操作轉化為對Ceph集群中RADOS(包括OSD以及Moniter)集群的訪問。具體的調用流程如圖5所示:
1)首先通過Hadoop Common包中的Configuration配置類讀取core-site.xml配置文件內容,獲取xml文件中fs.defaultFS配置項與fs.cephRgw.impl配置項的值,接著通過Java反射機制加載實現了Hadoop抽象文件接口FileSystem的具體實現類CephRg-wFileSystem。
2)Hadoop的計算應用數據訪問請求調用Hadoop文件系統(tǒng)兼容接口模塊。上層的Yam資源管理器讀取fs.AbstractFile-System.cephRgw.impl的值,找到Yarn的DelegateToFileSystem抽象類的具體實現類CephRgw,發(fā)送數據傳遞的請求。
3)對于上層傳遞過來的1/0請求。Hadoop文件系統(tǒng)兼容接口模塊將做判斷對于符合要求的1/0請求傳遞給下層文件系統(tǒng)操作實現模塊,否則返回相應的錯誤。
4)文件系統(tǒng)操作實現模塊先對要操作的文件或者文件夾加上讀鎖或者寫鎖,然后將Java請求通過JNA框架轉換成對so動態(tài)鏈接庫的C++請求,進行數據訪問的操作。
5)接下來進入到Ceph的具體實現中,文件系統(tǒng)操作實現模塊通過調用Ceph的LIBRADOS以及LIBRGW接口,先與遠程集群上的Mon節(jié)點進行通信,獲取到整個集群的Crush Map,再在本地通過Crush計算模塊計算出操作文件的具體位置,把對文件夾的操作轉換成對Bucket的操作,對文件的操作轉換成對Object的操作。此時還需要根據Crush算法計算出數據寫入的具體OSD并返回給文件讀寫模塊。
6)最后文件讀寫模塊跳過Mon節(jié)點,直接和集群的OSD建立通信,并將讀寫請求封裝成Socket請求發(fā)送給具體Bucket或者Object所在的主OSD,由主OSD進行讀寫,讀寫完成后將結果信息返回給文件讀寫模塊,文件讀寫模塊再把結果向上層傳遞,最終完成整個1/0數據流的操作。
從整個數據訪問流程中可以看出,Hadoop的1/0數據流到Ceph層面的數據流讀寫,不需要和Mon節(jié)點建立長時間的連接。另外,Ceph集群搭建好之后,Crush Map短時間內不太會出現比較大的變動,比較穩(wěn)定。直接和OSD進行數據傳輸,不存在文件系統(tǒng)的元數據瓶頸以及S3A網關的單點瓶頸問題。
此外,Ceph分布式存儲可以通過其他服務接口向云計算等其他平臺提供存儲服務,提供多種存儲方式。
4 實驗與分析
本章將建立實驗環(huán)境,首先對Hadoop計算存儲分離模塊的功能進行驗證,主要為HDFS的文件操作嘲。接著測試三種不同部署方案的性能,即Hadoop與HDFS分離部署方案、Ha-doop與S3A分離部署方案以及本文提出的基于Ceph對象存儲的Hadoop分離存儲方案。
實驗環(huán)境總共分為兩部分,一部分是功能測試環(huán)境,另一部分是性能測試環(huán)境。
4.1 功能測試
功能測試實驗環(huán)境有三部分:第一部分是Kubernetes集群,用來啟動容器大數據集群;第二部分是OpenStack集群,用來啟動虛擬機大數據集群;最后一部分是Ceph存儲環(huán)境,用來存儲容器集群與虛擬機集群的數據,并供大數據集群調用。
如表1所示:Kubemetes集群有3臺服務器,以Kubernetesl為Master節(jié)點,以Kubernetes2和Kubemetes3為Node節(jié)點,提供容器編排服務;OpenStack集群共有19臺服務器,以3臺服務器為控制節(jié)點,以16臺服務器為計算節(jié)點,使用Kolla自動化部署工具搭建了基于容器的OpenStack平臺,提供虛擬機服務;Ceph集群共有10臺大存儲機器,其中Cephl-3為Mon節(jié)點,10臺服務器上均部署OSD,對外提供Ceph對象存儲服務。
實驗用到的軟件及版本信息如表2所示:
Hadoop提供了HDFS的Shell命令,可以直接操作Hadoop配置的文件系統(tǒng)。HDFS命令有多個,包括文件以及文件夾的創(chuàng)建、查看、移動、重命名、本地文件的上傳與下載功能、文件復制、文件權限修改等等。
Hadoop對文件系統(tǒng)的操作有很多,表3給出了使用Hadoop與Ceph存儲對接器的大數據集群支持的命令。從表中可以看出,相比于使用HDFS分布式文件系統(tǒng),使用對接器的Hadoop集群僅僅不能支持文件的追加。這是因為Ceph對象存儲暫時還不支持文件的追加操作。
從測試結果可以看出,Hadoop與Ceph對象存儲對接器實現了從文件到對象轉化的功能,提供了直接操作Ceph對象存儲的Java接口。通過這些接口,HBase、Spark等大數據處理框架都能良好的運行。
4.2 性能測試
和功能性驗證的實驗環(huán)境相比,性能實驗對硬件的要求要高,特別是大數據計算任務,要求Ceph中存儲大量的數據。表
4 列出了本次性能測試使用的硬件環(huán)境。
為減少Hadoop計算任務所需時間,Hadoop集群使用十臺大存儲以及大內存的服務器搭建。Ceph集群使用十臺大存儲服務器部署。另外,為了與HDFS的情況做對比,在測試完Ceph相關的性能之后,又在Ceph集群所在的服務器重新搭建了HDFS分布式文件系統(tǒng),Hadoop集群通過遠程調用的方式進行測試。
圖6給出了性能測試的網絡拓撲圖,Hadoop集群和Ceph集群之間的交換機帶寬在40Gb*3量級上,因此,網絡不會成為Hadoop計算任務的瓶頸。
表5給出了性能測試的相關命令。性能測試主要分成四個任務:100G文件Put(上傳)、100G文件Get(下載)、TeraGen生成IT數據、TeraSort對IT數據進行排序。分別對以下三種情況做性能測試:使用HDFS作為底層的文件存儲;以S3A的方式對接Ceph對象存儲;使用本論文實現的Hadoop與Ceph存儲對接器對接Ceph對象存儲。
圖7為100G文件Put、100G文件Get、TeraGen生成IT數據、TeraSort對1T數據排序的結果對比圖。從圖中可以看出,CephRGW存儲對接器與HDFS相比,100G文件Put、Get性能相差在10%以下,TeraGen、TeraSort性能在10%-20%之間,而S3A相比于HDFS,IOOG文件Put、Get性能相差30%-50%.TeraGen以及TeraSort性能相差一倍以上。實驗結果表明CephRGW存儲對接器相比較HDFS性能差距不大,較S3A有較大性能提升。
5 結束語
本文提出了一種基于Ceph的大數據分離存儲方案,并對該方案的功能及性能進行了測試。經驗證,該方案功能上已能達到要求,性能上也接近了原生的HDFS方案,可以應用于實際的生產部署。
但方案仍有待完善之處,后續(xù)將從以下幾個方面開展工作:
第一,對于網絡I/O的問題,可以在此計算與存儲分離架構下進行緩存模塊設計,進一步提升系統(tǒng)性能。
第二,Ceph對象存儲由于采用CRUSH算法,沒有元數據服務器來存儲相關的目錄結構,故在做涉及rename命令操作的時候會影響到系統(tǒng)的性能,之后的工作可以重設rename機制,設計一個元數據管理模塊來對rename的源文件與目標文件進行管理。
第三,我們也對業(yè)界的商業(yè)存儲方案進行了調研,發(fā)現華為的大數據分離存儲方案能夠較好地解決上述問題,后續(xù)將會對華為存儲開展相關功能與性能測試。
參考文獻:
[1]馬一力,傅湘林,韓曉明,等,存儲與計算的分離[J].計算機研究與發(fā)展,2005,42(3):520-530.
[2]Bernstein P A,Reid C W,Das S,et al.Hyder—A Transac—tional Record Manager for Shared Flash[C]//Conference on Ci—dr.2011.
[3]Aguilem M K,MerchantA,Shah M A,etal.Sinfonia:anew para—digm for building scalable distributed systems[J].ACM Transac—tions on Computer Systems,2009,27(3):5.
[4]GhemawatS,GobioffH,Leung S T.The Goode file system[J].ACM SIGOPS 0perating Systems Review,2003,37(5):29—43.
[5]李大江.HDFS糾刪碼機制的優(yōu)化研究[D],哈爾濱:哈爾濱工業(yè)大學,2018.
[6]0'DriscollA,DaugelaiteJ,Sleator R D.‘Big data,Hadoop andcloud computing in genomics[J].Joumal of Biomedical Infor—matics,2013,46(5):774—781.
[7]Jain P,GoelA,Gupta S C.Monitoringchecklist for cephobjectstorage infrastmcture[J]. CompmerScienceandItsApplicatioⅡs,2015:456:61 1—623..
[8]翟永東.Hadop分布式文件系統(tǒng)(HDFS)可靠性的研究與優(yōu)化[D].武漢:華中科技大學,2011.
【通聯(lián)編輯:梁書】
作者簡介:吳金壇(1968-),男,天津人,高級工程師,學士,研究方向為金融支付;章超(1994-),男,湖北荊州人,碩士在讀,研究方向:大數據與云計算;李樹楠(1993-),男,安徽阜陽人,碩士,研究方向:大數據與云計算。