google云計算原理2.ppt

1、Google在線文檔,Google云計算應用場景,1,Google地圖,Google云計算應用場景,2,Google郵件,Google云計算應用場景,3,Google日歷,Google云計算應用場景,4,Google Wave 信息分享、協(xié)作、發(fā)布平臺,Google云計算應用場景,5,隸屬于PaaS的Google云計算 屬于部署在云端的應用執(zhí)行環(huán)境 支持Python和Java兩種語言 通過SDK提供Google的各種服務，如圖形、MAIL和數(shù)據(jù)存儲等 用戶可快速、廉價（可免費使用限定的流量和存儲）地部署自己開發(fā)的應用（如創(chuàng)新的網(wǎng)站、游戲等）,Google云計算應用場景,6,應用場景特點,Goo

2、gle云計算應用場景,應用（功能實現(xiàn)）在云端 存儲在云端 計算在云端,7,Google云計算平臺技術(shù)架構(gòu) 文件存儲，Google Distributed File System，GFS 并行數(shù)據(jù)處理MapReduce 分布式鎖Chubby 結(jié)構(gòu)化數(shù)據(jù)表BigTable,Google如何實現(xiàn)？,8,Google云計算原理,分布式文件系統(tǒng)GFS Google Distributed File System,9,什么是文件系統(tǒng)？ FAT, FAT32, NTFS, EXT, 用于持久地存儲數(shù)據(jù)的系統(tǒng) 通常覆蓋在底層的物理存儲介質(zhì)上 硬盤、CD、磁帶等 數(shù)據(jù)組織的基本單元：文件 具有文件名（1.txt

3、） 通常支持層次化嵌套（目錄結(jié)構(gòu)）,文件系統(tǒng)基礎,10,文件路徑 文件與目錄的結(jié)合，用于定位文件 絕對路徑，/home/aaron/foo.txt 相對路徑，docs/someFile.doc 規(guī)范路徑 定位文件的最短絕對路徑 /home/aaron/foo.txt, /home/./home/aaron/./foo.txt 所有規(guī)范路徑的集合構(gòu)成了文件系統(tǒng)的目錄結(jié)構(gòu),文件系統(tǒng)基礎,11,文件系統(tǒng)的存儲內(nèi)容 主要內(nèi)容：用戶的實際數(shù)據(jù) 元數(shù)據(jù)：驅(qū)動器元數(shù)據(jù)與文件元數(shù)據(jù),文件系統(tǒng)基礎,12,文件分塊存儲,文件系統(tǒng)基礎,13,文件系統(tǒng)設計的考慮因素 最小存儲單元 較小可減少浪費空間，較大則可提高文件

4、順序讀取速度（隨機訪問呢？） 文件系統(tǒng)的設計目標是提高訪問速度還是提高使用率？ 文件系統(tǒng)的安全性 多用戶環(huán)境下的文件安全 讀/寫權(quán)限分配 文件附帶訪問控制列表（ACL） 文件系統(tǒng)緩存 提高文件系統(tǒng)讀寫效率,文件系統(tǒng)基礎,14,Google需要一個支持海量存儲的文件系統(tǒng) 購置昂貴的分布式文件系統(tǒng)與硬件？,Google設計GFS的動機,是否可以在一堆廉價且不可靠的硬件上構(gòu)建可靠的分布式文件系統(tǒng)？,15,為什么不使用當時現(xiàn)存的文件系統(tǒng)？ Google所面臨的問題與眾不同 不同的工作負載，不同的設計優(yōu)先級（廉價、不可靠的硬件） 需要設計與Google應用和負載相符的文件系統(tǒng),Google設計GFS的動

5、機,16,GFS的假設與目標,硬件出錯是正常而非異常 系統(tǒng)應當由大量廉價、易損的硬件組成 必須保持文件系統(tǒng)整體的可靠性 主要負載是流數(shù)據(jù)讀寫 主要用于程序處理批量數(shù)據(jù)，而非與用戶的交互或隨機讀寫 數(shù)據(jù)寫主要是“追加寫”，“插入寫”非常少 需要存儲大尺寸的文件 存儲的文件尺寸可能是GB或TB量級，而且應當能支持存儲成千上萬的大尺寸文件,17,將文件劃分為若干塊（Chunk）存儲 每個塊固定大?。?4M） 通過冗余來提高可靠性 每個數(shù)據(jù)塊至少在3個數(shù)據(jù)塊服務器上冗余 數(shù)據(jù)塊損壞概率？ 通過單個master來協(xié)調(diào)數(shù)據(jù)訪問、元數(shù)據(jù)存儲 結(jié)構(gòu)簡單，容易保持元數(shù)據(jù)一致性 無緩存 Why?,GFS的設計思路

6、,18,單一Master, 若干ChunkServer,GFS的架構(gòu),1、文件存儲方式 2、數(shù)據(jù)讀寫流程,GFS的架構(gòu)有什么問題嗎？,19,20,分布式系統(tǒng)設計告訴我們： 這是單點故障 這是性能瓶頸 GFS的解決辦法 單點故障問題,單一Master問題,采用多個（如3個）影子Master節(jié)點進行熱備，一旦主節(jié)點損壞，立刻選舉一個新的主節(jié)點服務,21,GFS的解決辦法 性能瓶頸問題,單一Master問題,盡可能減少數(shù)據(jù)存取中Master的參與程度,不使用Master讀取數(shù)據(jù)，僅用于保存元數(shù)據(jù),客戶端緩存元數(shù)據(jù),采用大尺寸的數(shù)據(jù)塊（64M）,數(shù)據(jù)修改順序交由Primary Chunk Server

7、完成,Simple, and good enough!,22,存儲元數(shù)據(jù) 文件系統(tǒng)目錄管理與加鎖 與ChunkServer進行周期性通信 發(fā)送指令，搜集狀態(tài)，跟蹤數(shù)據(jù)塊的完好性 數(shù)據(jù)塊創(chuàng)建、復制及負載均衡 對ChunkServer的空間使用和訪問速度進行負載均衡，平滑數(shù)據(jù)存儲和訪問請求的負載 對數(shù)據(jù)塊進行復制、分散到ChunkServer上 一旦數(shù)據(jù)塊冗余數(shù)小于最低數(shù)，就發(fā)起復制操作,Master節(jié)點的任務,23,垃圾回收 在日志中記錄刪除操作，并將文件改名隱藏 緩慢地回收隱藏文件 與傳統(tǒng)文件刪除相比更簡單、更安全 陳舊數(shù)據(jù)塊刪除 探測陳舊的數(shù)據(jù)塊，并刪除,Master節(jié)點的任務,24,采用中

8、心服務器模式 可以方便地增加Chunk Server Master掌握系統(tǒng)內(nèi)所有Chunk Server的情況，方便進行負載均衡 不存在元數(shù)據(jù)的一致性問題,GFS架構(gòu)的特點,25,不緩存數(shù)據(jù) GFS的文件操作大部分是流式讀寫，不存在大量的重復讀寫，使用Cache對性能提高不大 Chunk Server上的數(shù)據(jù)存取使用本地文件系統(tǒng)，如果某個Chunk讀取頻繁，文件系統(tǒng)具有Cache 從可行性看，Cache與實際數(shù)據(jù)的一致性維護也極其復雜,GFS架構(gòu)的特點,?,26,在用戶態(tài)下實現(xiàn) 直接利用Chunk Server的文件系統(tǒng)存取Chunk，實現(xiàn)簡單 用戶態(tài)應用調(diào)試較為簡單，利于開發(fā) 用戶態(tài)的GFS

9、不會影響Chunk Server的穩(wěn)定性 提供專用的訪問接口 未提供標準的POSIX訪問接口 降低GFS的實現(xiàn)復雜度,GFS架構(gòu)的特點,27,GFS的容錯方法,GFS的容錯機制 Chunk Server容錯 每個Chunk有多個存儲副本（通常是3個），分別存儲于不通的服務器上 每個Chunk又劃分為若干Block（64KB），每個Block對應一個32bit的校驗碼，保證數(shù)據(jù)正確（若某個Block錯誤，則轉(zhuǎn)移至其他Chunk副本）,28,GFS的容錯方法,GFS的容錯機制 Master容錯 三類元數(shù)據(jù)：命名空間（目錄結(jié)構(gòu)）、Chunk與文件名的映射以及Chunk副本的位置信息 前兩類通過日志提供容錯，Chunk副本信息存儲于Chunk Server，Master出現(xiàn)故障時可恢復,29,GFS的性能,30,超過50個GFS集群 每個集