Hadoop平臺(tái)的安全加固方案

丁祥武,張東輝

(東華大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院,上海 201620)

0 概述

21世紀(jì)是數(shù)據(jù)信息高速發(fā)展的時(shí)代,利用大數(shù)據(jù)平臺(tái)存儲(chǔ)與分析海量數(shù)據(jù)已經(jīng)成為一種趨勢(shì),開(kāi)源式分布框架Hadoop作為大數(shù)據(jù)平臺(tái)的標(biāo)準(zhǔn)解決方案,被廣大企業(yè)、科研機(jī)構(gòu)以及個(gè)人所認(rèn)可。然而,由于在最初設(shè)計(jì)Hadoop時(shí)并未考慮安全問(wèn)題,隨著其使用量的增加以及使用形式的豐富,如使用Hadoop構(gòu)建云存儲(chǔ)、云計(jì)算平臺(tái),相比于傳統(tǒng)環(huán)境,在云平臺(tái)中木馬病毒、拒絕服務(wù)、身份偽造、數(shù)據(jù)竊取、信息泄露等一系列安全問(wèn)題尤為突出[1],這使得Hadoop集群上的安全漏洞日益增多,進(jìn)而導(dǎo)致安全隱患問(wèn)題日益凸顯,逐漸演變?yōu)樽璧KHadoop在云應(yīng)用相關(guān)領(lǐng)域發(fā)展的重要因素之一[2-3]。由此,云存儲(chǔ)、云計(jì)算平臺(tái)的安全問(wèn)題成為近年來(lái)學(xué)術(shù)界以及工業(yè)界的一個(gè)研究熱點(diǎn)。

目前,在最新的Hadoop 3.0.0-alpha3-SNAPSHOT版本中,使用Kerberos認(rèn)證體系作為其安全機(jī)制的基礎(chǔ),用于在Hadoop平臺(tái)中提供用戶認(rèn)證、節(jié)點(diǎn)認(rèn)證以及服務(wù)認(rèn)證,從而解決Hadoop平臺(tái)中可能出現(xiàn)的冒充威脅;使用服務(wù)等級(jí)協(xié)議SLA將指定的Hadoop服務(wù)授權(quán)給特定的合法用戶,從而更加規(guī)范化、安全地管理、存儲(chǔ)和計(jì)算資源;使用安全套接層協(xié)議SSL提供數(shù)據(jù)傳輸加密,防止數(shù)據(jù)在網(wǎng)絡(luò)傳送過(guò)程中被監(jiān)聽(tīng)、盜取和篡改,保護(hù)瀏覽器、服務(wù)器以及節(jié)點(diǎn)間網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)陌踩院屯暾?使用KMS實(shí)現(xiàn)Hadoop分布式文件系統(tǒng)(Hadoop Distribute File System,HDFS)在多租戶環(huán)境下的數(shù)據(jù)隔離能力,KMS還提供了數(shù)據(jù)以密文形式存儲(chǔ)到磁盤(pán)的功能,有效地防止了當(dāng)節(jié)點(diǎn)被黑客攻擊后,后者直接從硬盤(pán)中獲取集群隱私數(shù)據(jù)的威脅;使用類Unix/Linux的權(quán)限控制機(jī)制決定Hadoop集群中文件的可訪問(wèn)用戶及組,進(jìn)而提供豐富的文件級(jí)訪問(wèn)控制策略。

但是,目前Hadoop在有些安全方面仍存在缺陷,如:Hadoop集群用戶及權(quán)限管理復(fù)雜[4];Kerberos認(rèn)證服務(wù)器單點(diǎn)失效[5];HDFS中缺乏面向數(shù)據(jù)字段的細(xì)粒度訪問(wèn)控制策略[6];缺乏Hadoop集群專有的評(píng)價(jià)體系,不便于及時(shí)監(jiān)控并評(píng)測(cè)Hadoop集群的健康狀況等。針對(duì)以上問(wèn)題,本文設(shè)計(jì)了相應(yīng)的Hadoop平臺(tái)安全加固方案,主要包括企業(yè)安全系統(tǒng)與Hadoop集群集成、字段級(jí)訪問(wèn)控制以及健康評(píng)價(jià)體系。

1 企業(yè)安全系統(tǒng)集成

1.1 Windows AD與Hadoop集成

Windows AD認(rèn)證協(xié)議有2種:NTLM(NT LAN Manager)以及Kerberos[7]。前者主要應(yīng)用于Windows NT和Windows Server 2005及之后的工作組環(huán)境,而后者主要應(yīng)用于Windows Server 2000及之后的域環(huán)境。Hadoop使用Kerberos來(lái)實(shí)現(xiàn)用戶認(rèn)證,因此本文選取Kerberos作為認(rèn)證協(xié)議,Hadoop集成后的整體架構(gòu)如圖1所示。

圖1 Hadoop集成Kerberos認(rèn)證架構(gòu)

Hadoop集成Kerberos的主要步驟為:

1) 搭建Windows AD服務(wù)器,并創(chuàng)建AD域。

2) 配置Hadoop集群中的節(jié)點(diǎn),并加入AD域。

3) 統(tǒng)一Hadoop與AD對(duì)票據(jù)的加密算法。

4) 在AD中配置管理Hadoop用戶憑據(jù)。

5) 用指定加密方式生成keytab文件,并做相應(yīng)配置。

1.2 認(rèn)證高可用與負(fù)載均衡

Hadoop集群中可能會(huì)同時(shí)具有數(shù)以萬(wàn)計(jì)的任務(wù),如果每個(gè)任務(wù)均需要進(jìn)行Kerberos認(rèn)證,就可能導(dǎo)致在一個(gè)很短的時(shí)間段內(nèi)由于存在大量的認(rèn)證請(qǐng)求而造成AD服務(wù)器超負(fù)載,從而形成整個(gè)集群的瓶頸,最終影響到Hadoop集群的正常運(yùn)行[8]。為此,本文提出配置具有負(fù)載均衡能力的AD架構(gòu)[9],其可提高AD的可用性,又可持續(xù)提供身份驗(yàn)證及其他使用Kerberos的服務(wù)。由于AD和管理服務(wù)器需要主體數(shù)據(jù)庫(kù)的可讀寫(xiě)拷貝來(lái)完成所需的修改,因此需要用LDAP服務(wù)器來(lái)存儲(chǔ)Kerberos數(shù)據(jù)[10-11],具有負(fù)載均衡能力的認(rèn)證系統(tǒng)架構(gòu)如圖2所示。

圖2 負(fù)載均衡拓?fù)?/p>

客戶端默認(rèn)以輪詢方式訪問(wèn)不同的AD服務(wù)器,因而提供了AD服務(wù)器的負(fù)載均衡,既可以降低AD的負(fù)載又可以消除單點(diǎn)故障。在使用LDAP時(shí),一種常見(jiàn)的配置是使用一個(gè)LDAP主服務(wù)器和另外幾個(gè)LDAP副本服務(wù)器,這種配置可以實(shí)現(xiàn)存儲(chǔ)數(shù)據(jù)的負(fù)載均衡和高可用性。本文配置了多臺(tái)認(rèn)證機(jī)器并多次使用負(fù)載均衡,使得該架構(gòu)能夠提供持續(xù)且高效的認(rèn)證服務(wù)。雖然本文配置方式需要額外的機(jī)器且配置復(fù)雜,增加了部署復(fù)雜度、管理復(fù)雜度及成本,但典型的Kerberos生產(chǎn)環(huán)境卻常常結(jié)合使用上述2種配置方式。在企業(yè)的實(shí)際生產(chǎn)應(yīng)用中,如果僅僅有一臺(tái)AD服務(wù)器是十分危險(xiǎn)的,且AD上存儲(chǔ)的數(shù)據(jù)十分重要,一旦丟失后果不堪設(shè)想。除此之外,企業(yè)的所有運(yùn)行環(huán)境,如Hadoop集群、郵件系統(tǒng)、辦公系統(tǒng)等,都使用統(tǒng)一的認(rèn)證服務(wù),這樣AD負(fù)載很容易達(dá)到其瓶頸,而一旦AD性能下降或崩潰將會(huì)影響整個(gè)企業(yè)的正常運(yùn)轉(zhuǎn)。因此,本文配置方式的弊端在企業(yè)的可承受范圍之內(nèi)。

1.3 實(shí)驗(yàn)驗(yàn)證

1.3.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)環(huán)境為2臺(tái)Windows AD服務(wù)器、2臺(tái)Linux LDAP主服務(wù)器、3臺(tái)LDAP副本服務(wù)器以及3臺(tái)測(cè)試機(jī),上述10臺(tái)服務(wù)器的硬件配置完全相同,主要的硬件配置如表1所示。

表1 實(shí)驗(yàn)的硬件配置

2臺(tái)AD服務(wù)器的操作系統(tǒng)為Windows Server 2012,其他服務(wù)器的操作系統(tǒng)均為CentOS-6.4_64,程序開(kāi)發(fā)環(huán)境為Eclipse-Luna,JDK版本為1.8.0_11。

1.3.2 實(shí)驗(yàn)數(shù)據(jù)

實(shí)驗(yàn)以adtest[12]標(biāo)準(zhǔn)測(cè)試集為例,生成20個(gè)3層結(jié)構(gòu)的組織單元,每個(gè)組織單元生成5 000位用戶信息,共產(chǎn)生100 000位用戶信息。

1.3.3 測(cè)試與結(jié)果分析

實(shí)驗(yàn)使用adtest測(cè)試集生成的用戶,對(duì)單節(jié)點(diǎn)Windows AD以及Windows AD負(fù)載均衡2種架構(gòu),結(jié)合多線程以及定時(shí)任務(wù),分別對(duì)其進(jìn)行壓力測(cè)試。實(shí)驗(yàn)測(cè)試數(shù)據(jù)如表2所示。

表2 實(shí)驗(yàn)測(cè)試數(shù)據(jù)

在每臺(tái)測(cè)試主機(jī)上的測(cè)試程序開(kāi)啟100、200、400、800、1 600個(gè)線程,同時(shí)發(fā)起認(rèn)證請(qǐng)求,單節(jié)點(diǎn)Windows AD實(shí)驗(yàn)結(jié)果如圖3所示。當(dāng)認(rèn)證用戶數(shù)量達(dá)到1 200時(shí),單節(jié)點(diǎn)的Windows AD基本已經(jīng)達(dá)到其認(rèn)證的最大的負(fù)載(成功認(rèn)證用戶數(shù)量/認(rèn)證所需時(shí)間,700/s),當(dāng)再次成倍提升認(rèn)證用戶數(shù)量時(shí),成功認(rèn)證的用戶數(shù)量波動(dòng)不大,而失敗的用戶數(shù)量大幅上升。從圖3的耗時(shí)曲線可知,在AD負(fù)載達(dá)到最大時(shí),每次對(duì)用戶認(rèn)證所消耗的時(shí)間增長(zhǎng)率也急速提升。

圖3 單節(jié)點(diǎn)Windows AD實(shí)驗(yàn)結(jié)果

顯然,使用單節(jié)點(diǎn)Windows AD提供認(rèn)證服務(wù)并不能滿足企業(yè)生產(chǎn)環(huán)境下的需求。因此,本文提出以集群方式為Windows AD認(rèn)證服務(wù)提供高可用與負(fù)載均衡特性,在集群環(huán)境下的Windows AD認(rèn)證性能將成倍提升,實(shí)驗(yàn)結(jié)果如圖4所示。

圖4 Windows AD負(fù)載均衡實(shí)驗(yàn)結(jié)果

在使用負(fù)載均衡架構(gòu)的認(rèn)證服務(wù)后,Windows AD提供的認(rèn)證性能大幅提升,認(rèn)證服務(wù)的最大負(fù)載(3 400/s)大約是單節(jié)點(diǎn)AD的4.8倍,對(duì)比圖3的耗時(shí)曲線,可以看到在未達(dá)到最大負(fù)載時(shí)(測(cè)試用例1～測(cè)試用例4),成倍增長(zhǎng)的認(rèn)證用戶所需消耗的時(shí)間相比于單節(jié)點(diǎn)大約降低了4.2倍。除此之外,在達(dá)到最大負(fù)載時(shí),雖然每次對(duì)用戶認(rèn)證所消耗的時(shí)間增長(zhǎng)率仍急速提升,但相比于單節(jié)點(diǎn)認(rèn)證用戶所消耗時(shí)間仍提升了3.4倍左右。綜合上述對(duì)比實(shí)驗(yàn)可以得出,在企業(yè)中使用具有負(fù)載均衡能力的認(rèn)證架構(gòu)是有必要的,且該架構(gòu)帶來(lái)的成本代價(jià)是可以接受的。

2 字段級(jí)訪問(wèn)控制

2.1 字段級(jí)訪問(wèn)控制策略

數(shù)據(jù)的訪問(wèn)控制是數(shù)據(jù)防泄漏[13]的重要前提,尤其是在Hadoop集群中,隨著集群中隱私數(shù)據(jù)量的不斷增大以及數(shù)據(jù)分析與處理方式的不斷豐富,傳統(tǒng)基于用戶、用戶組及訪問(wèn)控制列表的粗粒度訪問(wèn)控制策略已經(jīng)不能滿足需求。針對(duì)上述問(wèn)題,借助于對(duì)訪問(wèn)控制模型以及Hadoop中安全組件源碼的分析與研究,本文提出在其開(kāi)源框架內(nèi),增加面向字段的細(xì)粒度訪問(wèn)控制流程,以在保障其他功能(如認(rèn)證、數(shù)據(jù)靜態(tài)加密、傳輸加密等)不受影響的前提下,實(shí)現(xiàn)面向數(shù)據(jù)字段的細(xì)粒度訪問(wèn)控制,進(jìn)而提升用戶對(duì)數(shù)據(jù)管理的靈活性。在保留原有文件訪問(wèn)控制的前提下,本文增加面向字段的訪問(wèn)控制流程,數(shù)據(jù)擁有者可同時(shí)對(duì)文件以及文件中具體的字段設(shè)置對(duì)應(yīng)的訪問(wèn)控制列表項(xiàng)。當(dāng)用戶請(qǐng)求獲取數(shù)據(jù)時(shí),需要同時(shí)具有文件以及具體字段的讀取權(quán)限,應(yīng)用字段級(jí)訪問(wèn)控制策略后,文件上傳及下載的流程如圖5所示。

圖5 HDFS文件上傳下載流程

改進(jìn)后的文件上傳及下載流程與傳統(tǒng)Hadoop文件上傳流程相比,主要增加了Schema解析、權(quán)限操作以及格式轉(zhuǎn)換3個(gè)過(guò)程。

2.1.1 Schema文件

Schema文件為待上傳文件的說(shuō)明,該文件以JSON格式保存,相比XML、JSON的數(shù)據(jù)格式比較簡(jiǎn)單且占用寬帶小,易于解析。Schema文件內(nèi)配置了待上傳文件的字段名稱、字段類型、以及字段的訪問(wèn)控制列表,Schema文件中存儲(chǔ)的字段信息結(jié)構(gòu)及描述如表3所示。

表3 Schema文件字段信息結(jié)構(gòu)組成

Schema文件示例如下:

text:

n_nationkey|n_name|n_regionkey|n_comment

0|ALGERIA|0|hanggle.carefully final deposits

1|ETHIOPIA|0|ven packages wake quickly.regu

2|FRANCE|3|refully final requests.Regular,ironi

3|JAPAN|2|ously.final,express gifts cajole a

schema:

{

“fields”:[

{“name”:”n_nationkey”,”type”:”int”,”acl”:”rw-r--r--”},

{“name”:”n_name”,”type”:”String”,”acl”:”rw-rw-rw-”},

{“name”:”n_regionkey”,”type”:”int”,”acl”:”rw--w-r--”},

{“name”:”n_comment”,”type”:”String”,”acl”:”r--r--r--”}

]

}

其中,待上傳文件的內(nèi)容如示例text部分所示,包含n_nationkey、n_name、n_regionkey、n_comment 4個(gè)字段。其對(duì)應(yīng)的Schema說(shuō)明文件如前文Schema描述所示,fields中每條記錄均由字段名稱、字段類型(Java中的基本數(shù)據(jù)類型)、字段訪問(wèn)控制列表組成,而每條記錄均是原始文件中某一字段的說(shuō)明,這樣Schema文件就能完全描述待上傳文件的字段訪問(wèn)控制信息。

2.1.2 文件上傳

為使Hadoop支持面向字段的訪問(wèn)控制策略,本文擴(kuò)展了Hadoop的文件上傳命令。當(dāng)用戶使用本文方式上傳數(shù)據(jù)文件時(shí),程序?qū)⒏鶕?jù)用戶定義的Schema文件對(duì)原始數(shù)據(jù)文件進(jìn)行解析,然后NameNode提取Schema中的內(nèi)容,并在NameNode的內(nèi)存中保存該字段的訪問(wèn)控制列表,最后將相關(guān)信息寫(xiě)入到EditsLog中。具體實(shí)現(xiàn)步驟如下:

1) 對(duì)原有的hdfs dfs -put [-f] [-p] [-l] [-d] …命令進(jìn)行擴(kuò)展,擴(kuò)展后的命令格式為:hdfs dfs -put [-f] [-p] [-l] [-d] [-fs -s ] …。其中,-fs用來(lái)指定字段間的分隔符,-s用來(lái)指定Schema文件的物理存儲(chǔ)地址。

2) HDFS客戶端向NameNode發(fā)起文件上傳請(qǐng)求以獲取用于存儲(chǔ)數(shù)據(jù)的數(shù)據(jù)塊輸入流。由于字段級(jí)訪問(wèn)控制實(shí)現(xiàn)的依據(jù)是Schema中存儲(chǔ)的信息,因此需要在原有PRC向NameNode傳遞信息的基礎(chǔ)上增加Schema字段,用來(lái)向NameNode發(fā)送Schema信息。

3) NameNode獲取到Schema字段內(nèi)容后,將其作為文件的元屬性寫(xiě)入對(duì)應(yīng)NameNode的內(nèi)存中,最后將此信息寫(xiě)入EditsLog進(jìn)行持久化,以便于NameNode重啟后仍能加載文件的字段訪問(wèn)控制列表到內(nèi)存中。

4) 建立DataNode數(shù)據(jù)塊的數(shù)據(jù)輸出流后,程序通過(guò)動(dòng)態(tài)代理方式截獲所有的數(shù)據(jù)輸出流,并將數(shù)據(jù)以[(,< name,value>,…)]格式重新寫(xiě)入數(shù)據(jù)輸入流中。使用該格式進(jìn)行存儲(chǔ)的目的是在后續(xù)文件下載過(guò)程中,程序能夠通過(guò)截獲數(shù)據(jù)輸出流對(duì)數(shù)據(jù)流中的字段進(jìn)行權(quán)限判定及過(guò)濾。

5) 修改FsImage與EditsLog合并的源碼,并增加合并相關(guān)元信息到FsImage的功能。

2.1.3 文件下載

為保障用戶的使用習(xí)慣,本文未對(duì)文件的下載命令進(jìn)行擴(kuò)展,而是通過(guò)程序判定的方式,對(duì)待讀取文件是否啟用本文的下載流程進(jìn)行判斷,具體實(shí)現(xiàn)步驟如下:

1) 獲取待下載分布式文件的元信息,若其存在則說(shuō)明用戶正在讀取支持字段級(jí)訪問(wèn)控制的文件,若其不存在則說(shuō)明用戶讀取的是普通文件。

2) 驗(yàn)證用戶是否具有對(duì)該文件的讀權(quán)限,若具有則允許讀取該文件。然后,判斷用戶讀取的文件類型,若用戶讀取的是普通文件,則進(jìn)入普通文件下載的處理流程;若用戶讀取的文件已配置字段級(jí)訪問(wèn)控制策略,則繼續(xù)下述步驟。

3) NameNode提取待下載文件在DataNode中存儲(chǔ)的數(shù)據(jù)塊并為數(shù)據(jù)塊創(chuàng)建數(shù)據(jù)塊輸入流,然后程序?qū)⒔孬@所有的數(shù)據(jù)輸入流,并根據(jù)元信息將數(shù)據(jù)解析為[(,< name,value>,…)]格式。

4) 程序通過(guò)元信息中存儲(chǔ)的訪問(wèn)控制列表并結(jié)合當(dāng)前用戶基本信息,即可對(duì)數(shù)據(jù)輸入流中的字段進(jìn)行權(quán)限判定,并將該用戶不具備讀權(quán)限的字段進(jìn)行濾除。

5) 將數(shù)據(jù)的格式還原為文件上傳前的存儲(chǔ)格式。

2.1.4 權(quán)限操作

文件共享主體數(shù)量的增加以及數(shù)據(jù)文件共享方式的豐富,要求必須為用戶提供查詢及修改指定文件訪問(wèn)控制列表的功能,具體實(shí)現(xiàn)步驟如下:

1) 擴(kuò)展hdfs命令,提供字段的查看以及修改功能,擴(kuò)展后字段權(quán)限相關(guān)的命令列表如表4所示。

表4 字段權(quán)限相關(guān)命令

2) NameNode接收用戶通過(guò)HDFS客戶端發(fā)送RPC請(qǐng)求后,判斷當(dāng)前用戶是否是該文件的擁有者,進(jìn)而決定是否提供該文件字段訪問(wèn)控制列表的修改以及查看功能。

3) 若用戶是該數(shù)據(jù)文件的擁有者,且所指定的字段及控制列表權(quán)限符合本文提出的規(guī)則,則將更新后的元信息寫(xiě)入EditsLog并更新內(nèi)存中的訪問(wèn)控制列表信息。對(duì)于查詢操作,若具有權(quán)限則直接返回相關(guān)的元信息。

4) 若用戶不是該文件的擁有者,則返回未授權(quán)。

2.2 實(shí)驗(yàn)驗(yàn)證

2.2.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)采用Hadoop開(kāi)源框架中提供的測(cè)試環(huán)境MiniDFSCluster,程序開(kāi)發(fā)環(huán)境為Eclipse-Luna,JDK版本為1.8.0_11,所有的進(jìn)程均在測(cè)試主機(jī)中運(yùn)行。實(shí)驗(yàn)過(guò)程中分別啟動(dòng)NameNode、StandbyNameNode以及2個(gè)DataNode。這4個(gè)進(jìn)程共享測(cè)試主機(jī)內(nèi)存、CPU以及磁盤(pán),測(cè)試機(jī)的主要配置如表5所示。

表5 實(shí)驗(yàn)的硬件配置

在Hadoop集群模式下,數(shù)據(jù)的存儲(chǔ)與網(wǎng)絡(luò)等因素密切相關(guān),而采用MiniDFSCluster測(cè)試環(huán)境可消除由于網(wǎng)絡(luò)不穩(wěn)定而造成實(shí)驗(yàn)結(jié)果數(shù)據(jù)失真的情況。除此之外,采用MiniDFSCluster測(cè)試環(huán)境,還可消除因軟硬件性能不同等各種差異帶來(lái)的影響,從而能夠產(chǎn)生最精確的對(duì)比數(shù)據(jù)。

2.2.2 實(shí)驗(yàn)數(shù)據(jù)

為探索文件大小對(duì)上傳耗時(shí)的影響,本文借助于隨機(jī)生成器分別生成10 MB、40 MB、160 MB、640 MB、1 280 MB的數(shù)據(jù)文件。

為探索文件字段數(shù)量對(duì)上傳速率的影響,本文借助于隨機(jī)算法分別生成字段數(shù)量為3、6、12、24、48,大小為640 MB的數(shù)據(jù)文件。

2.2.3 測(cè)試與結(jié)果分析

本文字段級(jí)訪問(wèn)控制與傳統(tǒng)Hadoop文件上傳方法對(duì)比實(shí)驗(yàn)如下:

1) 文件大小與性能關(guān)系,本次實(shí)驗(yàn)用于驗(yàn)證文件大小對(duì)上傳耗時(shí)的影響。為降低偶然因素帶來(lái)的干擾,本文對(duì)相同文件上傳30次,每次重新上傳文件之前,均格式化測(cè)試集群。實(shí)驗(yàn)將最終統(tǒng)計(jì)結(jié)果中上傳速率最快及最慢的2項(xiàng)去除,取剩余數(shù)據(jù)的平均值,實(shí)驗(yàn)結(jié)果如圖6所示。

圖6 上傳消耗時(shí)間與文件大小的關(guān)系

本文方法在對(duì)原始數(shù)據(jù)流處理后,需要額外增加字段空間,導(dǎo)致實(shí)際上傳文件所占空間大于待上傳文件所占空間,因此帶來(lái)額外的上傳時(shí)間消耗。假設(shè)10 MB文件帶來(lái)的額外字段所占空間為10 KB,則40 MB文件需要40 KB的額外空間。盡管所需額外空間呈線性增長(zhǎng),然而由于直線斜率較低,對(duì)于較大的文件,該額外空間上傳的時(shí)間消耗在可接受的范圍內(nèi)。

2) 文件字段數(shù)量與性能關(guān)系,本次實(shí)驗(yàn)用于驗(yàn)證文件大小相同,字段數(shù)量不同對(duì)上傳速率的影響。同樣,為了降低偶然因素帶來(lái)的影響,本文對(duì)相同文件上傳30次,每次重新上傳文件之前,均格式化測(cè)試集群。實(shí)驗(yàn)將最終統(tǒng)計(jì)結(jié)果中上傳速率最快及最慢的2項(xiàng)去除,取剩余數(shù)據(jù)的平均值,實(shí)驗(yàn)結(jié)果如圖7所示。

圖7 上傳消耗時(shí)間與字段數(shù)量的關(guān)系

本文方法對(duì)原始數(shù)據(jù)流的處理是以行為最小處理單位,在文件大小不變的前提下,字段數(shù)量的增多會(huì)減少處理次數(shù),因此便可提升處理效率。盡管字段數(shù)量會(huì)影響文件的上傳速率,但從圖7可以看出,該模型文件上傳消耗時(shí)間相比于整體的消耗時(shí)間可以忽略不計(jì),且當(dāng)字段成倍增加時(shí),文件上傳消耗時(shí)間逐步加速趨近于傳統(tǒng)上傳方式。

綜合上述對(duì)比實(shí)驗(yàn)可以得出,本文提出的字段級(jí)訪問(wèn)控制在效率上的降低在可容忍范圍之內(nèi),且在加固后的系統(tǒng)中使用傳統(tǒng)上傳方式,效率也幾乎沒(méi)有發(fā)生變化,由此可得本文字段級(jí)訪問(wèn)控制具有可行性。

3 健康評(píng)價(jià)體系

隨著企業(yè)數(shù)據(jù)量的增加以及業(yè)務(wù)的拓展,Hadoop集群規(guī)模也在不斷擴(kuò)大,這導(dǎo)致維護(hù)集群的復(fù)雜度呈直線上升,目前的Hadoop集群中仍然存在大量的軟件錯(cuò)誤和硬件故障,要求系統(tǒng)7×24 h不間斷運(yùn)行,因此對(duì)于這些系統(tǒng)的持續(xù)監(jiān)控就至關(guān)重要。目前對(duì)于Hadoop集群尚無(wú)一個(gè)評(píng)價(jià)體系可以體現(xiàn)集群的健康走勢(shì),這導(dǎo)致管理者很難及時(shí)發(fā)現(xiàn)并定位集群中潛在的隱患。為此,本文提出建立基于集群資源的健康評(píng)價(jià)體系,以對(duì)集群的健康狀態(tài)進(jìn)行把控,進(jìn)而為整個(gè)Hadoop集群的安全運(yùn)行提供保障,提高集群的健壯性。

3.1 基于熵值法的集群健康評(píng)價(jià)

集群健康是一個(gè)相對(duì)概念,需要建立基準(zhǔn)點(diǎn)即健康狀態(tài)下的集群系統(tǒng),并在對(duì)比的基礎(chǔ)上進(jìn)行集群健康狀況的評(píng)估。集群健康的不可確定性及復(fù)雜性,導(dǎo)致集群健康狀態(tài)的評(píng)判不可避免地帶有人為主觀性,而對(duì)資源狀態(tài)進(jìn)行評(píng)判時(shí),常常采用主觀賦權(quán)的方法來(lái)確定各個(gè)指標(biāo)的影響因子。主觀賦權(quán)是指專家根據(jù)各個(gè)指標(biāo)的重要性來(lái)確定權(quán)重,其容易受專家主觀意識(shí)的影響而帶來(lái)偏差,并且不能反映各指標(biāo)統(tǒng)計(jì)數(shù)據(jù)的相互關(guān)系[14-15]。在信息論中,信息熵是系統(tǒng)無(wú)序程度的度量。信息熵越小,信息的效用值越大,反之信息熵越大,信息的效用值越小[16]。熵值法在確定屬性權(quán)重方面克服了主觀意識(shí)等因素帶來(lái)的影響,對(duì)于集群的健康評(píng)價(jià)體系,本文提出基于熵值法的集群健康評(píng)價(jià)算法,選取某段時(shí)間序列,將序列中的指標(biāo)進(jìn)行歸一化,然后借助信息熵值法計(jì)算各個(gè)指標(biāo)的熵權(quán)[17],其具體計(jì)算步驟如下:

1)收集集群健康狀態(tài)的評(píng)價(jià)指標(biāo)。通過(guò)Linux腳本收集節(jié)點(diǎn)健康狀態(tài)的評(píng)價(jià)指標(biāo),如內(nèi)存大小、HDFS使用率、內(nèi)存使用率、CPU使用率、CPU溫度、節(jié)點(diǎn)數(shù)量、MapReduce任務(wù)數(shù)量、網(wǎng)絡(luò)時(shí)延、網(wǎng)絡(luò)IO、磁盤(pán)IO。

2)構(gòu)建決策矩陣。設(shè)X={x1,x2,…,xm}為集群評(píng)價(jià)指標(biāo)記錄的集合,U={u1,u2,…,un}為集群評(píng)價(jià)指標(biāo)集合。對(duì)于記錄xi,按指標(biāo)uj進(jìn)行測(cè)度,得到xi關(guān)于uj的指標(biāo)aij,從而構(gòu)成決策矩陣A={aij}m×n。

3.2 健康評(píng)價(jià)體系模型

在使用基于熵值法的集群健康評(píng)價(jià)算法計(jì)算集群的健康走勢(shì)之前,首先需要無(wú)間斷地從集群中各個(gè)節(jié)點(diǎn)收集指標(biāo)數(shù)據(jù)并對(duì)數(shù)據(jù)進(jìn)行統(tǒng)一處理;然后,將處理后的數(shù)據(jù)交由評(píng)分計(jì)算流程,對(duì)集群各個(gè)時(shí)間點(diǎn)的健康狀態(tài)進(jìn)行評(píng)分;最后,根據(jù)得出的各個(gè)時(shí)間點(diǎn)的評(píng)分繪制健康走勢(shì)圖。健康評(píng)價(jià)體系模型詳細(xì)設(shè)計(jì)流程如圖8所示。

圖8 健康評(píng)價(jià)體系詳細(xì)設(shè)計(jì)流程

健康評(píng)價(jià)體系模型的計(jì)算過(guò)程主要分為5個(gè)步驟:

1) 收集指標(biāo),程序在運(yùn)行中可以動(dòng)態(tài)設(shè)置是否開(kāi)啟集群健康評(píng)價(jià)體系監(jiān)控,若開(kāi)啟,首先判斷用戶是否已經(jīng)設(shè)置需要清空數(shù)據(jù)(默認(rèn)不清空);然后通過(guò)Linux腳本收集節(jié)點(diǎn)健康狀態(tài)的評(píng)價(jià)指標(biāo),如內(nèi)存、HDFS使用率、內(nèi)存使用率、CPU使用率、CPU溫度、節(jié)點(diǎn)數(shù)量、MapReduce任務(wù)數(shù)量、網(wǎng)絡(luò)IO、磁盤(pán)IO。

2) 異常提醒,在收集數(shù)據(jù)過(guò)程中,一旦發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)的某項(xiàng)指標(biāo)低于或者高于預(yù)定義閾值,則直接向管理員發(fā)送異常警告。

3) 數(shù)據(jù)存儲(chǔ),數(shù)據(jù)由各個(gè)節(jié)點(diǎn)收集并發(fā)送到分析服務(wù)器,分析服務(wù)器將傳輸?shù)臄?shù)據(jù)取均值后存儲(chǔ)于內(nèi)存中。

4) 熵值法計(jì)算,通過(guò)定時(shí)器或管理員手動(dòng)觸發(fā)的方式,利用熵值法計(jì)算集群健康評(píng)分流程。

5) 圖形展示,根據(jù)計(jì)算的結(jié)果以時(shí)間為線索繪制集群健康走勢(shì)圖。

3.3 實(shí)驗(yàn)驗(yàn)證

3.3.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)使用了7臺(tái)物理機(jī)器,這7臺(tái)機(jī)器配置完全相同且在同一個(gè)局域網(wǎng)中,主要的軟硬件配置如表6所示。其中,包括一臺(tái)NameNode節(jié)點(diǎn)、一臺(tái)StandbyNameNode節(jié)點(diǎn),其余均為DataNode節(jié)點(diǎn)。同時(shí),這些節(jié)點(diǎn)還運(yùn)行了Yarn服務(wù)。

表6 實(shí)驗(yàn)的軟硬件配置

3.3.2 實(shí)驗(yàn)數(shù)據(jù)

實(shí)驗(yàn)每隔20 s對(duì)集群的評(píng)價(jià)指標(biāo)進(jìn)行收集,將其作為一個(gè)單位時(shí)間,最終計(jì)算集群的歷史健康評(píng)分,繪制集群健康曲線走勢(shì)圖。在監(jiān)控的過(guò)程中,實(shí)驗(yàn)通過(guò)模擬軟硬件故障,如網(wǎng)絡(luò)時(shí)延、磁盤(pán)故障、CPU使用率高、HDFS使用率持續(xù)上升、MapReduce任務(wù)運(yùn)行等情況分析該模型的實(shí)用性。

3.3.3 測(cè)試與結(jié)果分析

本文健康評(píng)價(jià)體系模型在單一評(píng)價(jià)指標(biāo)與多個(gè)評(píng)價(jià)指標(biāo)情況下的實(shí)驗(yàn)如下:

1)單一評(píng)價(jià)指標(biāo)

實(shí)驗(yàn)使用Linux系統(tǒng)下的開(kāi)源流量控制工具TC[18]模擬網(wǎng)絡(luò)阻塞,編寫(xiě)Linux定時(shí)任務(wù)周期性地將網(wǎng)絡(luò)時(shí)延由200 ms逐步增加至1 800 ms,程序在無(wú)間斷情況下運(yùn)行1 h,并最終繪制健康走勢(shì)圖,實(shí)驗(yàn)結(jié)果如圖9所示。

圖9 單一評(píng)價(jià)指標(biāo)下集群健康走勢(shì)

在內(nèi)存利用率、CPU使用率、磁盤(pán)I/O等因素波動(dòng)不大的前提下,集群健康指數(shù)可近似看作隨著網(wǎng)絡(luò)I/O時(shí)延的增加而線性減小。由此可見(jiàn),該模型能夠有效檢測(cè)集群評(píng)價(jià)指標(biāo)的變化,并能夠正確反映到集群健康走勢(shì)圖中。

2)多個(gè)評(píng)價(jià)指標(biāo)

Hadoop集群環(huán)境相對(duì)比較復(fù)雜,僅單一指標(biāo)發(fā)生變化的情況比較少見(jiàn),因此實(shí)驗(yàn)通過(guò)運(yùn)行Hadoop WordCount基準(zhǔn)測(cè)試程序模擬生產(chǎn)環(huán)境,進(jìn)而驗(yàn)證本文模型的實(shí)用性。實(shí)驗(yàn)數(shù)據(jù)使用搜狐新聞數(shù)據(jù)歷史版本2008版完整版,解壓后數(shù)據(jù)大小為2.95 G。實(shí)驗(yàn)使用的中文分詞工具是基于Lucene的IKAnalyzer Java版本(http://code.google.com/p/ik-analyzer/),結(jié)果如圖10所示。

圖10 多個(gè)評(píng)價(jià)指標(biāo)下集群健康走勢(shì)

MapReduce作業(yè)調(diào)度運(yùn)行后,根據(jù)文件的切分將生成多個(gè)Map以及Reduce任務(wù),而任務(wù)的運(yùn)行需要消耗大量的集群資源,比如CPU、內(nèi)存、網(wǎng)絡(luò)I/O等,如圖10所示。從圖10可以看出,在0～120個(gè)單位時(shí)間內(nèi),由于Map以及Reduce任務(wù)的不斷增加、任務(wù)的調(diào)度、數(shù)據(jù)的讀取、Shuffle過(guò)程中數(shù)據(jù)的存儲(chǔ)以及數(shù)據(jù)的移動(dòng),使得集群的健康指數(shù)不斷下降;在120個(gè)～170個(gè)單位時(shí)間內(nèi)絕大部分Map子任務(wù)執(zhí)行階段結(jié)束,由于該階段使用分詞工具對(duì)中文進(jìn)行分詞,因此占用了大量的內(nèi)存以及CPU等主機(jī)資源,雖然Reduce任務(wù)仍在運(yùn)行,但由于只是做簡(jiǎn)單的統(tǒng)計(jì)工作,對(duì)內(nèi)存以及CPU等資源的需求并不是很高,由此集群資源開(kāi)始回收,集群健康指數(shù)提升;在170個(gè)單位時(shí)間之后,Reduce子任務(wù)執(zhí)行階段結(jié)束,標(biāo)志MapReduce作業(yè)的完成,集群健康指數(shù)快速回升。通過(guò)分析可知,該模型在生產(chǎn)環(huán)境下能夠有效檢測(cè)集群評(píng)價(jià)指標(biāo)的變化,并能夠正確反映到集群健康走勢(shì)圖中。

由實(shí)驗(yàn)結(jié)果可以得出,本文提出的健康評(píng)價(jià)體系能夠在指定時(shí)間段內(nèi)準(zhǔn)確反映集群的健康走勢(shì),管理員通過(guò)集群健康走勢(shì)圖可對(duì)集群的整體情況進(jìn)行把控,大幅提升了工作效率,并且為整個(gè)Hadoop集群的持續(xù)健康運(yùn)行提供了有效保障。

4 結(jié)束語(yǔ)

針對(duì)Hadoop集群中的安全隱患,本文設(shè)計(jì)了相應(yīng)的安全加固方案,主要包括企業(yè)安全系統(tǒng)與Hadoop集群集成、字段級(jí)訪問(wèn)控制以及健康評(píng)價(jià)體系,并通過(guò)實(shí)驗(yàn)驗(yàn)證該方案的可行性與有效性。下一步將對(duì)健康評(píng)價(jià)體系的核心算法進(jìn)行優(yōu)化,以期更加精確地反映集群的健康狀態(tài),并結(jié)合機(jī)器學(xué)習(xí)為其提供預(yù)測(cè)能力。另外,由于版本的迭代,Hadoop的安全問(wèn)題會(huì)不斷發(fā)生變化,下一步將繼續(xù)研究Hadoop平臺(tái)中的安全問(wèn)題,并提出相應(yīng)新的安全加固方案。