【文章內(nèi)容簡介】 lhost:50030，若出現(xiàn)如下頁面，則說明hadoop成功啟動： 下面是運行hadoop自帶的wordcount例子的過程，先在hdfs的根目錄下創(chuàng)建一個input文件夾，然后將bin目錄下的所有。sh文件放入input中： 運行程序： 下面是例子運行的結(jié)果，結(jié)果保存在output文件夾中： 至此，我們已經(jīng)在單機上成功安裝了hadoop。接下來結(jié)合其它兩臺電腦部署一個hadoop的集群。3．7 在三臺電腦上部署hadoop集群機器名ip地址作用master10。42。43。10JobTrackerslaver110。42。43。1TaskTrackerslaver210。42。43。20TaskTracker修改etc/hosts中配置主機名和ip地址對應的關(guān)系將master節(jié)點中的~/。ssh/id_rsa。pub文件拷貝到slaver節(jié)點的~/。ssh目錄下，然后再slaver節(jié)點的~/。ssh目錄下運行cat 。/id_rsa。put authorized_keys。這一步很重要，這一步可以使得master節(jié)點訪問slaver節(jié)點時不需要密碼。 l 修改mapredsite。xml和coresite。xml文件，將原來的localhost改成master 至此，三臺電腦的hadoop集群就配置好了。啟動hadoop： 第四章 hadoop安全分析4．1 云安全技術(shù)4．1．1 可信訪問控制由于無法信賴服務商忠實實施用戶定義的訪問控制策略,所以在云計算模式下,研究者關(guān)心的是如何通過非傳統(tǒng)訪問控制類手段實施數(shù)據(jù)對象的訪問控制。其中得到關(guān)注最多的是基于密碼學方法實現(xiàn)訪問控制,包括:基于層次密鑰生成與分配策略實施訪問控制的方法。利用基于屬性的加密算法(如密鑰規(guī)則的基于屬性加密方案(KPABE),或密文規(guī)則的基于屬性加密方案(CPABE),基于代理重加密的方法。以及在用戶密鑰或密文中嵌入訪問控制樹的方法等?；诿艽a類方案面臨的一個重要問題是權(quán)限撤銷,一個基本方案是為密鑰設(shè)置失效時間,每隔一定時間,用戶從認證中心更新私鑰。文獻對其加以改進,引入了一個在線的半可信第三方維護授權(quán)列表,文獻提出基于用戶的唯一 ID 屬性及非門結(jié)構(gòu),實現(xiàn)對特定用戶進行權(quán)限撤銷。但目前看,上述方法在帶有時間或約束的授權(quán)、權(quán)限受限委托等方面仍存在許多有待解決的問題。 4．1．2 密文檢索與處理數(shù)據(jù)變成密文時喪失了許多其他特性,導致大多數(shù)數(shù)據(jù)分析方法失效。密文檢索有兩種典型的方法:基于安全索引的方法通過為密文關(guān)鍵詞建立安全索引,檢索索引查詢關(guān)鍵詞是否存在?；诿芪膾呙璧姆椒▽γ芪闹忻總€單詞進行比對,確認關(guān)鍵詞是否存在,以及統(tǒng)計其出現(xiàn)的次數(shù)。由于某些場景(如發(fā)送加密郵件)需要支持非屬主用戶的檢索,Boneh 等人提出支持其他用戶公開檢索的方案密文處理研究主要集中在秘密同態(tài)加密算法設(shè)計上。早在 20 世紀 80 年代,就有人提出多種加法同態(tài)或乘法同態(tài)算法。但是由于被證明安全性存在缺陷,后續(xù)工作基本處于停頓狀態(tài)。而近期,IBM 研究員 Gentry 利用“理想格(ideal lattice)”的數(shù)學對象構(gòu)造隱私同態(tài)(privacy homomorphism)算法,或稱全同態(tài)加密,使人們可以充分地操作加密狀態(tài)的數(shù)據(jù),在理論上取得了一定突破,使相關(guān)研究重新得到研究者的關(guān)注,但目前與實用化仍有很長的距離。 4．1．3 數(shù)據(jù)存在與可使用性證明由于大規(guī)模數(shù)據(jù)所導致的巨大通信代價,用戶不可能將數(shù)據(jù)下載后再驗證其正確性。因此,云用戶需在取回很少數(shù)據(jù)的情況下,通過某種知識證明協(xié)議或概率分析手段,以高置信概率判斷遠端數(shù)據(jù)是否完整。典型的工作包括:面向用戶單獨驗證的數(shù)據(jù)可檢索性證明(POR)方法、公開可驗證的數(shù)據(jù)持有證明(PDP)方法。NEC實驗室提出的 PDI(provable data integrity)方法改進并提高了 POR 方法的處理速度以及驗證對象規(guī)模,且能夠支持公開驗證。其他典型的驗證技術(shù)包括:Yun 等人提出的基于新的樹形結(jié)構(gòu) MAC Tree的方案。Schwarz 等人提出的基于代數(shù)簽名的方法。Wang 等人提出的基于 BLS 同態(tài)簽名和 RS 糾錯碼的方法等。 4．1．4 數(shù)據(jù)隱私保護云中數(shù)據(jù)隱私保護涉及數(shù)據(jù)生命周期的每一個階段。Roy等人將集中信息流控制(DIFC)和差分隱私保護技術(shù)融入云中的數(shù)據(jù)生成與計算階段,提出了一種隱私保護系統(tǒng) airavat,防止 map reduce 計算過程中非授權(quán)的隱私數(shù)據(jù)泄露出去,并支持對計算結(jié)果的自動除密。在數(shù)據(jù)存儲和使用階段,Mowbray 等人提出了一種基于客戶端的隱私管理工具,提供以用戶為中心的信任模型,幫助用戶控制自己的敏感信息在云端的存儲和使用。 MuntsMulero 等人討論了現(xiàn)有的隱私處理技術(shù),包括 K 匿名、圖匿名以及數(shù)據(jù)預處理等,作用于大規(guī)模待發(fā)布數(shù)據(jù)時所面臨的問題和現(xiàn)有的一些解決方案。Rankova 等人則在文獻中提出一種匿名數(shù)據(jù)搜索引擎,可以使得交互雙方搜索對方的數(shù)據(jù),獲取自己所需要的部分,同時保證搜索詢問的內(nèi)容不被對方所知,搜索時與請求不相關(guān)的內(nèi)容不會被獲取。 虛擬安全技術(shù)虛擬技術(shù)是實現(xiàn)云計算的關(guān)鍵核心技術(shù),使用虛擬技術(shù)的云計算平臺上的云架構(gòu)提供者必須向其客戶提供安全性和隔離保證。Santhanam 等人提出了基于虛擬機技術(shù)實現(xiàn)的 grid 環(huán)境下的隔離執(zhí)行機。Raj 等人提出了通過緩存層次可感知的核心分配,以及給予緩存劃分的頁染色的兩種資源管理方法實現(xiàn)性能與安全隔離。這些方法在隔離影響一個 VM 的緩存接口時是有效的,并整合到一個樣例云架構(gòu)的資源管理(RM)框架中。Wei等人在文獻中關(guān)注了虛擬機映像文件的安全問題,每一個映像文件對應一個客戶應用,它們必須具有高完整性,且需要可以安全共享的機制。所提出的映像文件管理系統(tǒng)實現(xiàn)了映像文件的訪問控制、來源追蹤、過濾和掃描等,可以檢測和修復安全性違背問題。 4．1．5 云資源訪問控制在云計算環(huán)境中,各個云應用屬于不同的安全管理域,每個安全域都管理著本地的資源和用戶。當用戶跨域訪問資源時,需在域邊界設(shè)置認證服務,對訪問共享資源的用戶進行統(tǒng)一的身份認證管理。在跨多個域的資源訪問中,各域有自己的訪問控制策略,在進行資源共享和保護時必須對共享資源制定一個公共的、雙方都認同的訪問控制策略,因此,需要支持策略的合成。這個問題最早由 Mclean 在強制訪問控制框架下提出,他提出了一個強制訪問控制策略的合成框架,將兩個安全格合成一個新的格結(jié)構(gòu)。策略合成的同時還要保證新策略的安全性,新的合成策略必須不能違背各個域原來的訪問控制策略。為此,Gong 提出了自治原則和安全原則。Bonatti提出了一個訪問控制策略合成代數(shù),基于集合論使用合成運算符來合成安全策略。Wijesekera 等人提出了基于授權(quán)狀態(tài)變化的策略合成代數(shù)框架。Agarwal 構(gòu)造了語義 Web 服務的策略合成方案。Shafiq 提出了一個多信任域 RBAC 策略合成策略,側(cè)重于解決合成的策略與各域原有策略的一致性問題。 4．1．6 可信云計算將可信計算技術(shù)融入云計算環(huán)境,以可信賴方式提供云服務已成為云安全研究領(lǐng)域的一大熱點。Santos 等人在文獻中提出了一種可信云計算平臺 TCCP,基于此平臺,IaaS 服務商可以向其用戶提供一個密閉的箱式執(zhí)行環(huán)境,保證客戶虛擬機運行的機密性。另外,它允許用戶在啟動虛擬機前檢驗 Iaas 服務商的服務是否安全。 Sadeghi 等人認為,可信計算技術(shù)提供了可信的軟件和硬件以及證明自身行為可信的機制,可以被用來解決外包數(shù)據(jù)的機密性和完整性問題。同時設(shè)計了一種可信軟件令牌,將其與一個安全功能驗證模塊相互綁定,以求在不泄露任何信息的前提條件下,對外包的敏感(加密)數(shù)據(jù)執(zhí)行各種功能操作[7]。 4．2 Hadoop 企業(yè)級應用的弱點分析4．2．1 Hadoop 系統(tǒng)單點設(shè)計瓶頸當前Hadoop 單一NameNode，單一JobTracker 的設(shè)計嚴重制約了整個Hadoop可擴展性和可靠性。尤其Namenode 是HDFS 集群中的單點故障(single point of failure)的關(guān)鍵所在。單一的NameNode 主要存在以下三方面的問題。第一，單一NameNode 如果出現(xiàn)宕機或者需要重啟，那么整個Hadoop 集群將不能正常運行，一般重新啟動NameNode 需要數(shù)小時。對于一個對生產(chǎn)環(huán)境要求比較嚴格的企業(yè)來說，Hadoop 集群不能夠保證7*24 的穩(wěn)定生產(chǎn)環(huán)境，這一點是Hadoop 的致命弱點。第二，單一Namenode 的內(nèi)存容量有限，使得Hadoop 集群的節(jié)點數(shù)量被限制到2000 個左右，能支持的文件系統(tǒng)大小被限制在1050PB, 最多能支持的文件數(shù)量大約為 1。5 億左右。第三，單一 Namenode 造成DataNode 的blocks report 也會對Namenode 的性能造成嚴重的影響。例如系統(tǒng)有1800 個Datanode, 每個Datanode 有3T 存儲，整個集群大約有1。8P 有效存儲。那么每個Datanode 上有大約50000 個左右的block，假設(shè)Datanode 每小時會發(fā)送一次block report， 那么 Namenode 每兩秒會收到一次block report，每個block report 包含50000 條數(shù)據(jù)，處理這些數(shù)據(jù)無疑會占用相當多的資源。4．2．2 作業(yè)調(diào)度方式單一Hadoop 內(nèi)置有一種簡單的先進先出(FIFO)的作業(yè)調(diào)度算法，對于不同大小的作業(yè)，F(xiàn)IFO 調(diào)度算法對于小作業(yè)就表現(xiàn)出了嚴重的不公平性，為了緩解這一問題，又有一些新的調(diào)度算法被以插件的形式集成到Hadoop 中去，使用比較多的有公平調(diào)度算法(Fair Scheduler) 和計算能力調(diào)度算法(Capacity Scheduler)。雖然相對FIFO 算法已經(jīng)有了較大的進步。但是由于企業(yè)環(huán)境復雜，作業(yè)類型繁多，作業(yè)的個性化需求也很多，使得Hadoop 現(xiàn)有的作業(yè)調(diào)度算法很難滿足企業(yè)的需求，所以為了有效地滿足企業(yè)復雜的需求，就需要更多的作業(yè)調(diào)度算法。LSF 是在企業(yè)經(jīng)過多年驗證的一個網(wǎng)格計算框架，其中內(nèi)置了大量的作業(yè)調(diào)度算法，論文通過將LSF 與Hadoop 集成來彌補Hadoop 作業(yè)調(diào)度算法匱乏的問題。4．2．3 異構(gòu)平臺兼容性從 Hadoop 應用的諸多成功案例中可以看出，主要是互聯(lián)網(wǎng)企業(yè)，例如Facebook，Yahoo 等。而互聯(lián)網(wǎng)應用模式是一種簡單的應用模式，傳統(tǒng)IT 行業(yè)則復雜得多，傳統(tǒng)的IT 企業(yè)由于發(fā)展時間比較長，企業(yè)內(nèi)部存在大量的異構(gòu)機器，目前的Hadoop 只考慮了同構(gòu)的環(huán)境，在異構(gòu)環(huán)境下效率低下。論文提出的LSF與Hadoop 的系統(tǒng)整合會讓Hadoop 在異構(gòu)平臺上也能夠發(fā)揮很高的效率[8]。第五章 hadoop安全協(xié)議5．1 RPC它是一種通過網(wǎng)絡(luò)從遠程計算機程序上請求服務，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應用程序更加容易。RPC采用客戶機/服務器模式。請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先，客戶機調(diào)用進程發(fā)送一個有進程參數(shù)的調(diào)用信息到服務進程，然后等待應答信息。在服務器端，進程保持睡眠狀態(tài)直到調(diào)用信息的到達為止。當一個調(diào)用信息到達，服務器獲得進程參數(shù)，計算結(jié)果，發(fā)送答復信息，然后等待下一個調(diào)用信息，最后，客戶端調(diào)用進程接收答復信息，獲得進程結(jié)果，然后調(diào)用執(zhí)行繼續(xù)進行。有多種 RPC模式和執(zhí)行。最初由 Sun 公司提出。IETF ONC 憲章重新修訂了 Sun 版本，使得 ONC RPC 協(xié)議成為 IETF 標準協(xié)議?，F(xiàn)在使用最普遍的模式和執(zhí)行是開放式軟件基礎(chǔ)的分布式計算環(huán)境（DCE）。5．1．1 工作原理運行時,一次客戶機對服務器的RPC調(diào)用,其內(nèi)部操作大致有如下十步：；執(zhí)行傳送參數(shù)，調(diào)用遠程系統(tǒng)內(nèi)核RPC OVER HTTPMicrosoft RPCoverHTTP 部署(RPC over HTTP)允許RPC客戶端安全和有效地通過Internet 連接到RPC 服務器程序并執(zhí)行遠程過程調(diào)用。這是在一個名稱為RPCoverHTTP 代理，或簡稱為RPC 代理的中間件的幫助下完成的。RPC 代理運行在IIS計算機上。它接受來自Internet 的RPC 請求，在這些請求上執(zhí)行認證，檢驗和訪問檢查，如果請求通過所有的測試，RPC 代理將請求轉(zhuǎn)發(fā)給執(zhí)行真正處理的RPC 服務器。通過RPC over HTTP，RPC客戶端不和服務器直接通信，它們使用RPC 代理作為中間件。5．1．2 協(xié)議結(jié)構(gòu)遠程過程調(diào)用（RPC）信息協(xié)議由兩個不同結(jié)構(gòu)組成：調(diào)用信息和答復信息。信息流程如下所示：RPC：遠程過程調(diào)用流程RPC 調(diào)用信息：每條遠程過程調(diào)用信息包括以下無符號整數(shù)字段，以獨立識別遠程過程：程序號（Program number）程序版本號（Program version number）過程號（Procedure number）RPC 調(diào)用信息主體形式如下：struct call_body {unsigned int r