




下載本文檔
版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領
文檔簡介
1、IaaS、 PaaS和 SaaS三種類型,不同的廠家又提供了不同的解決方案,目前對讀者了解云計算的原理構成了障礙。為此, 本文綜合不構造了一個供商榷的云計算體系結構。這個體系結構如圖3 所示, 它概括了每一種方案或許只實現(xiàn)了其中部分功能,或許也還有部分相對次3 云計算技術體系結構4 層:物理資源層、資源池層、管理中間件層和SOA 構建層,如3 所示。物理資源層包括計算機、存儲器、網(wǎng)絡設施、數(shù)據(jù)庫和軟件等;資源池層是將大如計算資源池、數(shù)據(jù)資源池等。構建資源2000 個解決散熱和故障節(jié)點替換的問題并降低能耗;管理中間件負責對云計算的資源進行SOA 構建Web Services 服務,并納入到SOA
2、 體系進行管理和使用,包查找、 訪問和構建服務工作流等。管理中間件和資源池層是云計算技術的最關SOA 構建層的功能更多依靠外部設施提供。任務管理、用戶管理和安全管理等工作。資源管理負責檢測節(jié)點的故障并試圖恢復或屏蔽之,并對資源的使用情況進行監(jiān)(Image)的部署任務執(zhí)行、任務生命期管理等等;用戶管理是實現(xiàn)云計算商業(yè)模式的一包括提供用戶交互接口、管理和識別用戶身份、創(chuàng)建用戶程序的執(zhí)行環(huán)安全管理保障云計算設施的整體安全,包括身份認證、訪問IaaS 云計算為例,簡述云計算的實現(xiàn)機制,如圖4 所示。Web Services 方式提供訪問接口,獲取用戶需求。服務目錄是用戶可系統(tǒng)管理模塊負責管理和分配所有
3、可用的資源,其核心是負載均衡。配置工具負責在分配的節(jié)點上準備任務運行環(huán)境。監(jiān)視統(tǒng)計模塊負責監(jiān)視節(jié)點的運行狀態(tài),并完成用戶使用節(jié)點情況的統(tǒng)計。執(zhí)行過程并不復雜:用戶交互接口允許用戶從目錄中選取并調(diào)用一個服務。該請求傳遞給系統(tǒng)管理模塊后,它將為用戶分配恰當?shù)馁Y源,然后調(diào)用配置工具來為用戶準備運行環(huán)境。Hadoop HDFS 特性簡介一、設計思想1、硬件失效是“常態(tài)事件“,而非“偶然事件”。HDFS可能是有上千的機器組成(文檔中描述的 Yahoo! 一個Hadoop集群有4096個節(jié)點),任何一個組件都有可能一直失效,因此數(shù)據(jù)的健壯性錯誤檢測和快速、自動的恢復是HDFS的核心架構目標。2、 流式數(shù)據(jù)
4、訪問。運行在HDFS上的應用和普通的應用不同,需要流式訪問它們的數(shù)據(jù)集。HDFS的設計中更多的考慮到了數(shù)據(jù)批處理,而不是用戶交互處理。比之數(shù)據(jù)訪問的低延遲問題,更關鍵的在于數(shù)據(jù)并發(fā)訪問的高吞吐量。POSIX標準設置的很多硬性約束對HDFS應用系統(tǒng)不是必需的。為了提高數(shù)據(jù)的吞吐量,在一些關鍵方面對POSIX的語義做了一些修改。3、 HDFS應用對文件要求的是write-one-read-many 訪問模型。一個文件經(jīng)過創(chuàng)建、寫,關閉之后就不需要改變。這一假設簡化了數(shù)據(jù)一致性問題,使高吞吐量的數(shù)據(jù)訪問成為可能。典型的如MapReduce框架,或者一個web crawler 應用都很適合這個模型。4
5、、移動計算的代價比之移動數(shù)據(jù)的代價低。一個應用請求的計算,離它操作的數(shù)據(jù)越近就越高效,這在數(shù)據(jù)達到海量級別的時候更是如此。將計算移動到數(shù)據(jù)附近,比之將數(shù)據(jù)移動到應用所在顯然更好,HDFS提供給應用這樣的接口。5、在異構的軟硬件平臺間的可移植性。二、Namenode和 Datanode 的劃分一個HDFS集群有一個 Namenode和一定數(shù)目的Datanode 組成。Namenode是一個中心服務器,負責管理文件系統(tǒng)的namespace和客戶端對文件的訪問。Datanode 在集群中會有多個,一般是一個節(jié)點存在一個,負責管理其自身節(jié)點上它們附帶的存儲。在內(nèi)部,一個大文件其分成一個或多個block
6、 ,這些 block 存儲在 Datanode 集合里。Namenode執(zhí)行文件系統(tǒng)的namespace相關操作,例如打開、關閉、重命名文件和目錄,同時決定了block 到具體 Datanode 節(jié)點的映射。Datanode 在 Namenode的指揮下進行block的創(chuàng)建、刪除和復制。單一節(jié)點的Namenode大大簡化了系統(tǒng)的架構。Namenode負責保管和管理所有的HDFS元數(shù)據(jù), 因而在請求Namenode得到文件的位置后就不需要通過Namenode參與而直接從Datanode進行。為了提高Namenode的性能,所有文件的namespace數(shù)據(jù)都在內(nèi)存中維護,所以就天生存在了由于內(nèi)存大
7、小的限制導致一個HDFS集群的提供服務的文件數(shù)量的上限。根據(jù)目前的文檔,一個元數(shù)據(jù)(一個HDFS文件塊兒)占用200Bytes ,如果是頁面抓取的小文件,那么32GB內(nèi)存能承載1.5 億左右的文件存儲(有待精確詳細測試)。三、文件系統(tǒng)操作和namespace的關系HDFS支持傳統(tǒng)的層次型文件組織,與大多數(shù)其他文件系統(tǒng)類似,用戶可以創(chuàng)建目錄,并在其間創(chuàng)建、刪除、移動和重命名文件。HDFS不支持user quotas 和訪問權限,也不支持鏈接 ( link) , 不過當前的架構并不排除實現(xiàn)這些特性。Namenode維護文件系統(tǒng)的namespace,任何對文件系統(tǒng)namespace和文件屬性的修改都
8、將被Namenode記錄下來。應用可以設置HDFS保存的文件的副本數(shù)目,文件副本的數(shù)目稱為文件的replication 因子,這個信息也是由Namenode保存。四、數(shù)據(jù)復制HDFS被設計成在一個大集群中可以跨機器地可靠地存儲海量的文件。它將每個文件存儲成block 序列,除了最后一個block ,所有的block 都是同樣的大小。文件的所有block 為了容錯都會被復制。每個文件的block 大小和 replication 因子都是可配置的。Replication因子可以在文件創(chuàng)建的時候配置,以后也可以改變。HDFS中的文件是write-one , 并且嚴格要求在任何時候只有一個writer
9、 。 Namenode全權管理block 的復制,它周期性地從集群中的每個 Datanode 接收心跳包和一個Blockreport 。 心跳包的接收表示該Datanode 節(jié)點正常工作,而Blockreport 包括了該Datanode 上所有的block 組成的列表。1、副本的存放,副本的存放是HDFS可靠性和性能的關鍵。龐大的HDFS實例一般運行在多個機架的計算機形成的集群上,不同機架間的兩臺機器的通訊需要通過交換機,顯然通常情況下,同一個機架內(nèi)的兩個節(jié)點間的帶寬會比不同機架間的兩臺機器的帶寬大。在大多數(shù)情況下,replication 因子是3, HDFS的存放策略是將一個副本存放在本地
10、機架上的節(jié)點, 一個副本放在同一機架上的另一個節(jié)點,最后一個副本放在不同機架上的一個節(jié)點。機架的錯誤遠遠比節(jié)點的錯誤少,這個策略不會影響到數(shù)據(jù)的可靠性和有效性。三分之一的副本在一個節(jié)點上,三分之二在一個機架上,其他保存在剩下的機架中,這一策略改進了寫的性能。2、副本的選擇,為了降低整體的帶寬消耗和讀延時,HDFS會盡量讓reader 讀最近的副本。如果在 reader 的同一個機架上有一個副本,那么就讀該副本。如果一個HDFS集群跨越多個數(shù)據(jù)中心,那么reader 也將首先嘗試讀本地數(shù)據(jù)中心的副本。3、 SafeModeNamenode啟動后會進入一個稱為SafeMode的特殊狀態(tài),處在這個狀
11、態(tài)的Namenode是不會進行數(shù)據(jù)塊的復制的。Namenode從所有的Datanode 接收心跳包和Blockreport 。Blockreport 包括了某個Datanode 所有的數(shù)據(jù)塊列表。每個block 都有指定的最小數(shù)目的副本。當Namenode檢測確認某個Datanode 的數(shù)據(jù)塊副本的最小數(shù)目,那么該Datanode 就會被認為是安全的;如果一定百分比(這個參數(shù)可配置)的數(shù)據(jù)塊檢測確認是安全的,那么Namenode將退出SafeMode狀態(tài),接下來它會確定還有哪些數(shù)據(jù)塊的副本沒有達到指定數(shù)目,并將這些block 復制到其他Datanode。五、文件系統(tǒng)元數(shù)據(jù)的持久化Namenod
12、e存儲HDFS的元數(shù)據(jù)。對于任何對文件元數(shù)據(jù)產(chǎn)生修改的操作,Namenode都使用一個稱為 Editlog 的事務日志記錄下來。例如,在HDFS中創(chuàng)建一個文件,Namenode就會在Editlog 中插入一條記錄來表示;同樣, 修改文件的replication 因子也將往Editlog 插入一條記錄。Namenode在本地OS的文件系統(tǒng)中存儲這個Editlog 。 整個文件系統(tǒng)的namespace,包括 block 到文件的映射、文件的屬性,都存儲在稱為FsImage 的文件中,這個文件也是放在 Namenode所在系統(tǒng)的文件系統(tǒng)上。Namenode在內(nèi)存中保存著整個文件系統(tǒng)namespace
13、和文件 Blockmap 的映像。這個關鍵的元數(shù)據(jù)設計得很緊湊,一般為200Bytes 的內(nèi)存占用,因而一個帶有4G內(nèi)存的Namenode足夠支撐海量的文件和目錄。當Namenode啟動時,它從硬盤中讀取Editlog 和 FsImage,將所有 Editlog 中的事務作用(apply) 在內(nèi)存中的FsImage ,并將這個新版本的FsImage 從內(nèi)存中 flush 到硬盤上, 然后再 truncate 這個舊的Editlog , 因為這個舊的Editlog 的事務都已經(jīng)作用在FsImage 上了。這個過程稱為checkpoint 。在當前實現(xiàn)中,checkpoint 只發(fā)生在 Namen
14、ode啟動時,在不久的將來我們將實現(xiàn)支持周期性的checkpoint 。Datanode 并不知道關于文件的任何東西,除了將文件中的數(shù)據(jù)保存在本地的文件系統(tǒng)上。它把每個HDFS數(shù)據(jù)塊存儲在本地文件系統(tǒng)上隔離的文件中。Datanode 并不在同一個目錄創(chuàng)建所有的文件,相反, 它用啟發(fā)式地方法來確定每個目錄的最佳文件數(shù)目,并且在適當?shù)臅r候創(chuàng)建子目錄。在同一個目錄創(chuàng)建所有的文件不是最優(yōu)的選擇,因為本地文件系統(tǒng)可能無法高效地在單一目錄中支持大量的文件。當一個Datanode 啟動時,它掃描本地文件系統(tǒng),對這些本地文件產(chǎn)生相應的一個所有HDFS數(shù)據(jù)塊的列表,然后發(fā)送報告到Namenode,這個報告就是B
15、lockreport 。六、通訊協(xié)議所有的HDFS通訊協(xié)議都是構建在TCP/IP 協(xié)議上??蛻舳送ㄟ^一個可配置的端口連接到Namenode, 通過ClientProtocol 與 Namenode交互。 而 Datanode 是使用 DatanodeProtocol與 Namenode交互。從ClientProtocol 和 Datanodeprotocol 抽象出一個遠程調(diào)用(RPC),在設計上,Namenode不會主動發(fā)起RPC,而是是響應來自客戶端和Datanode 的RPC請求。七、健壯性HDFS的主要目標就是實現(xiàn)在失敗情況下的數(shù)據(jù)存儲可靠性。常見的三種失?。篘amenodefailu
16、res, Datanode failures 和網(wǎng)絡分割(network partitions) 。1、硬盤數(shù)據(jù)錯誤、心跳檢測和重新復制每個 Datanode 節(jié)點都向Namenode周期性地發(fā)送心跳包。網(wǎng)絡切割可能導致一部分Datanode跟 Namenode失去聯(lián)系。Namenode通過心跳包的缺失檢測到這一情況,并將這些Datanode標記為dead,不會將新的IO 請求發(fā)給它們。寄存在dead Datanode 上的任何數(shù)據(jù)將不再有效。 Datanode 的死亡可能引起一些block 的副本數(shù)目低于指定值,Namenode不斷地跟蹤需要復制的block ,在任何需要的情況下啟動復制。在
17、下列情況可能需要重新復制:某個Datanode 節(jié)點失效,某個副本遭到損壞,Datanode 上的硬盤錯誤,或者文件的replication因子增大。2、集群均衡HDFS支持數(shù)據(jù)的均衡計劃,如果某個Datanode 節(jié)點上的空閑空間低于特定的臨界點,那么就會啟動一個計劃自動地將數(shù)據(jù)從一個Datanode 搬移到空閑的Datanode。 當對某個文件的請求突然增加,那么也可能啟動一個計劃創(chuàng)建該文件新的副本,并分布到集群中以滿足應用的要求。這些均衡計劃目前還沒有實現(xiàn)。3、數(shù)據(jù)完整性從某個 Datanode 獲取的數(shù)據(jù)塊有可能是損壞的,這個損壞可能是由于Datanode 的存儲設備錯誤、網(wǎng)絡錯誤或者
18、軟件bug 造成的。HDFS客戶端軟件實現(xiàn)了HDFS文件內(nèi)容的校驗和。當某個客戶端創(chuàng)建一個新的HDFS文件,會計算這個文件每個block 的校驗和,并作為一個單獨的隱藏文件保存這些校驗和在同一個HDFS namespace下。當客戶端檢索文件內(nèi)容,它會確認從 Datanode 獲取的數(shù)據(jù)跟相應的校驗和文件中的校驗和是否匹配,如果不匹配,客戶端可以選擇從其他Datanode 獲取該 block 的副本。4、元數(shù)據(jù)磁盤錯誤FsImage 和 Editlog 是 HDFS的核心數(shù)據(jù)結構。這些文件如果損壞了,整個HDFS實例都將失效。 因而,Namenode可以配置成支持維護多個FsImage 和 E
19、ditlog 的拷貝。 任何對 FsImage或者 Editlog 的修改,都將同步到它們的副本上。這個同步操作可能會降低Namenode每秒能支持處理的namespace 事務。這個代價是可以接受的,因為HDFS是數(shù)據(jù)密集的,而非元數(shù)據(jù)密集。當Namenode重啟的時候,它總是選取最近的一致的FsImage 和 Editlog 使用。Namenode在 HDFS是單點存在,如果Namenode所在的機器錯誤,手工的干預是必須的。目前,在另一臺機器上重啟因故障而停止服務的Namenode這個功能還沒實現(xiàn)。八、數(shù)據(jù)組織1、數(shù)據(jù)塊兼容HDFS的應用都是處理大數(shù)據(jù)集合的。這些應用都是寫數(shù)據(jù)一次,讀卻
20、是一次到多次,并且讀的速度要滿足流式讀。HDFS支持文件的write-once , read-many。一個典型的block大小是64MB,因而,文件總是按照64M切分成chunk,每個chunk 存儲于不同的Datanode上。2、數(shù)據(jù)產(chǎn)生步驟某個客戶端創(chuàng)建文件的請求其實并沒有立即發(fā)給Namenode,事實上,HDFS客戶端會將文件數(shù)據(jù)緩存到本地的一個臨時文件。應用的寫被透明地重定向到這個臨時文件。當這個臨時文件累積的數(shù)據(jù)超過一個block 的大小(默認64M),客戶端才會聯(lián)系Namenode。 Namenode將文件名插入文件系統(tǒng)的層次結構中,并且分配一個數(shù)據(jù)塊給它,然后返回Datanod
21、e 的標識符和目標數(shù)據(jù)塊給客戶端??蛻舳藢⒈镜嘏R時文件flush 到指定的Datanode 上。當文件關閉時,在臨時文件中剩余的沒有flush 的數(shù)據(jù)也會傳輸?shù)街付ǖ腄atanode,然后客戶端告訴 Namenode文件已經(jīng)關閉。此時Namenode才將文件創(chuàng)建操作提交到持久存儲。如果Namenode在文件關閉前掛了,該文件將丟失。上述方法是對通過對HDFS上運行的目標應用認真考慮的結果。如果不采用客戶端緩存,由于網(wǎng)絡速度和網(wǎng)絡堵塞會對吞估量造成比較大的影響。3、數(shù)據(jù)塊復制當某個客戶端向HDFS文件寫數(shù)據(jù)的時候,一開始是寫入本地臨時文件,假設該文件的replication 因子設置為3, 那么客戶端會從Namenode 獲取一張Datanode 列表來存放副本。然后客戶端開始向第一個Datanode 傳輸數(shù)據(jù),第一個Datanode 一小部分一小部分(4kb)地接收數(shù)據(jù),將每個部分寫入本地倉庫,并且同時傳輸該部分到第二個Datanode 節(jié)點。第二個 Datanode 也是這樣,邊收邊傳,一小部分一小部分地收,存儲在本地倉庫,同時傳給第三個 Datanode,第三個Datanode 就
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
- 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 盈江縣房地產(chǎn)管理辦法
- 監(jiān)理單位績效管理辦法
- 執(zhí)業(yè)質量報備管理辦法
- 成品糧油儲存管理辦法
- 基金執(zhí)業(yè)資格管理辦法
- 境外pos機管理辦法
- 居民住宅噪音管理辦法
- 離職手續(xù)辦理管理辦法
- 電費發(fā)票開具管理辦法
- 2025年幼兒園春季學期教師發(fā)展計劃
- 貴州省貴陽市云巖區(qū)2023-2024學年四年級下學期期末語文試題
- 2024車輛掛靠證明
- DL∕T 1833-2018 柔性直流輸電換流閥檢修規(guī)程
- 近視表征的表觀遺傳機制
- QCT1177-2022汽車空調(diào)用冷凝器
- GB/T 4074.5-2024繞組線試驗方法第5部分:電性能
- 熱水袋燙傷RCA分析2022
- 2024年單獨考試招生嬰幼兒托育與管理專業(yè)考試題庫(含答案)
- 人工智能中的圖像識別技術
- 市場監(jiān)管培訓課件
- 2024年上海市計算機一級考試復習題庫(含答案)
評論
0/150
提交評論