丁祥武,張東輝

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

0 概述

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

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

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

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來實現(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é)點,并加入AD域。

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

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

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

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

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

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

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

1.3 實驗驗證

1.3.1 實驗環(huán)境

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

表1 實驗的硬件配置

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

1.3.2 實驗數(shù)據(jù)

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

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

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

表2 實驗測試數(shù)據(jù)

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

圖3 單節(jié)點Windows AD實驗結(jié)果

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

圖4 Windows AD負(fù)載均衡實驗結(jié)果

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

2 字段級訪問控制

2.1 字段級訪問控制策略

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

圖5 HDFS文件上傳下載流程

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

2.1.1 Schema文件

Schema文件為待上傳文件的說明,該文件以JSON格式保存,相比XML、JSON的數(shù)據(jù)格式比較簡單且占用寬帶小,易于解析。Schema文件內(nèi)配置了待上傳文件的字段名稱、字段類型、以及字段的訪問控制列表,Schema文件中存儲的字段信息結(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個字段。其對應(yīng)的Schema說明文件如前文Schema描述所示,fields中每條記錄均由字段名稱、字段類型(Java中的基本數(shù)據(jù)類型)、字段訪問控制列表組成,而每條記錄均是原始文件中某一字段的說明,這樣Schema文件就能完全描述待上傳文件的字段訪問控制信息。

2.1.2 文件上傳

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

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

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

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

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

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

2.1.3 文件下載

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

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

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

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

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

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

2.1.4 權(quán)限操作

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

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

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

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

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

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

2.2 實驗驗證

2.2.1 實驗環(huán)境

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

表5 實驗的硬件配置

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

2.2.2 實驗數(shù)據(jù)

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

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

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

本文字段級訪問控制與傳統(tǒng)Hadoop文件上傳方法對比實驗如下:

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

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

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

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

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

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

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

3 健康評價體系

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

3.1 基于熵值法的集群健康評價

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

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

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

3.2 健康評價體系模型

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

圖8 健康評價體系詳細(xì)設(shè)計流程

健康評價體系模型的計算過程主要分為5個步驟:

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

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

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

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

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

3.3 實驗驗證

3.3.1 實驗環(huán)境

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

表6 實驗的軟硬件配置

3.3.2 實驗數(shù)據(jù)

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

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

本文健康評價體系模型在單一評價指標(biāo)與多個評價指標(biāo)情況下的實驗如下:

1)單一評價指標(biāo)

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

圖9 單一評價指標(biāo)下集群健康走勢

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

2)多個評價指標(biāo)

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

圖10 多個評價指標(biāo)下集群健康走勢

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

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

4 結(jié)束語

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