雲端儲存-Google的雲端儲存技術細節 GFS

雲端儲存和雲端運算的出現是在資訊海量儲存和處理的需求下產生的，所以是否是真正的雲，首先要解決儲存和計算的問題。

 

一：雲端儲存

採用類似Key/value模式和Schema Free列表模式 屬於抽象化的資料模型，在轉向商業應用的實際過程中，需要解決目前的流行系統所能夠完成的可能性問題；

 

PC機可以Linux,Windows,Mac,但是後兩者都難以承擔作為廉價叢集的任務，更適合作為使用者的終端機；

Linux系統下，如果搭建雲端儲存呢，Distributed File System，分散式資料庫，分布式搜尋引擎，分布式Web伺服器，分布式緩衝，呵呵，的確可以找出很多；

但是這些眾多的分布式組件能否彼此有效組合為支援雲端儲存呢，只有具體的實踐才能夠見證。

 

Google的設計具有顛覆性，起始也是在充分借鑒了這些分布式組件的基礎上，全新設計出一套適合自身業務要求的儲存引擎:

1:Distributed File SystemGFS

2:BigTable提供資料的結構化和半結構化視圖

3:MegaStore則在BigTable基礎上在事務支援方面有更加面向資料庫，支援組內資料ACID原則

4:Chubby則對GFS和BigTable起到控制器的作用，主伺服器的選舉、中繼資料的儲存、粗粒度的鎖服務

5:SSTable作為BigTable內部用來儲存的檔案，具有特定的格式

 

針對上述的幾個核心模組，每一個都涵蓋了很多的技術細節，為了通俗易懂，只有儘可能簡單的分析：

一: GFSDistributed File System，這個不屬於Google的最先發明，也有很多類似的Distributed File System

Distributed File System需要解決的問題

a:抽象在作業系統的檔案系統之上的一個應用程式

b:能夠支援大規模儲存的規劃和複製的合理方案【多個副本的負載平衡，非同步複製】

c:檔案如何儲存，如何快速被檢索、訪問

d:儲存結構的多樣性，key/value格式，目錄格式，多維格式 【儲存節點如何設計】

e:用戶端如何和多個儲存節點互動【追蹤器如何設計】

f:如何在多個用戶端跟多個儲存節點實現平衡【負載平衡、任務調度】

g:為用戶端訪問提供透明一致性的提供者

h:如何管理多個節點的容錯移轉，提供系統的可用性

 

總結：Distributed File System，需要設計好儲存節點和控制節點【追蹤器】，以及提供儘可能好的管理工具和提供者；

 

 帶著這些問題，可以看一下Google的GFS是如何解決這些問題的

GFS：海量非結構化資訊的儲存平台，並提供了資料的冗餘備份、上萬台伺服器的自動負載平衡以及失效伺服器的檢測等機制

 

GFS的設計原則：

一：以普通PC作為儲存節點、控制節點，資料支援冗餘備份、自動檢測機器是否有效提供服務，故障機器的自動回復。

二：隱藏檔為大檔案100M到10G之間，必須對大檔案的讀寫操作做出最佳化

三：系統存在大量的追加寫，寫入的內容很少變化，很少出現隨機寫，支援高效的追加寫

四：資料的讀取多數為順序讀，少量的隨機讀

 

這些設計原則讓我想起此前所設計的企業級文檔引擎的部分原則：

一：提供對非結構化的資料的有效儲存、儲存支援靈活的分級和目錄

二：對大資料檔案G層級的檔案的上傳、備份、下載

三：能夠對大資料的內容快速的檢索並且定位

四：對大檔案的操作比較費時，不要影響其他業務的正常操作

 

根據上述的設計原則，瞭解一下GFS的整體架構

 三部分組成：

1:唯一的主控伺服器{Master}

   負責管理工作

2: 眾多的Chunk伺服器

  負責資料存放區並響應GFS用戶端的讀、寫請求

3:GFS用戶端

  負載跟資料存放區節點互動，屏蔽訪問的細節，讓具體應用操作跟本地操作一樣

 

GFS的檔案系統：

類似Linux/Windows的檔案系統，有目錄和存放在整個目錄下的檔案構成的樹形結構,可以理解為命名空間

/data/bizdomain/module/timestamp/datafile

GFS提供類似的檔案建立、刪除、讀取和寫入等常見的操作介面(API)

 

Chunk:儲存資料的物理單元，比如一個大檔案，最終還是被分割為具體的固定大小的塊來儲存 【Chunk】，每個chunk的大小為64M,一個檔案通常有多個Chunk組成

 

每個檔案可能擁有不同的Chunk，而且這些Chunk可以儲存到不同的Chunk伺服器上，每個Chunk伺服器儲存的Chunk可以是來自不同檔案的chunk,

而在Chunk伺服器內部，會對Chunk進一步分割，為具體的一個Block, Block為一個基本的儲存操作單元。

 

GFS的整體架構描述如下：

1：主控伺服器，維護GFS命名空間，維護Chunk命名空間

為了識別不同的Chunk,每個Chunk都有一個唯一編號，所有的編號構成了Chunk命名空間，GFS主控伺服器還記錄每個Chunk儲存在那台Chunk伺服器上的資訊；

GFS系統內部必須維持檔案到Chunk之間的映射關係

 

2：chunk伺服器，負載對Chunk的實際儲存，同時響應GFS用戶端對自己負責的Chunk的讀、寫請求

 

3：GFS用戶端，負責讀取、更新資料

 執行個體：一個客戶請求，讀取支援檔案，從P位置開始，讀取長度為L

app--->send (filename,start_position,read_length) 到 GFS用戶端，用戶端介紹到後，內部轉換為具體的Chunk序號，再發給

GFS主控伺服器，主控伺服器根據管理中繼資料，擷取對應的儲存Chunk伺服器的位置，再返回給GFS用戶端

GFS用戶端然後，和具體的Chunk伺服器建立串連，發送對應的讀取的chunk編號的讀取範圍，Chunk伺服器收到請求後，返回對應的資料

 

上述的實作類別似文檔引擎的實現：

1:有用戶端供客戶上傳、下載檔案 【該用戶端需要接受檔案、或者檔案編號】，無需關注檔案儲存體的位置

2:接受到檔案編號，主控端首先根據檔案編號，擷取對應的儲存節點位置，以及儲存節點路徑，將資訊返回給用戶端

3:用戶端建立跟儲存節點串連後，下載指定的檔案

 

GFS主控伺服器

採用主從架構，單一主控伺服器，多個儲存伺服器

GFS管理如下中繼資料

1：GFS命名空間和Chunk命名空間

2:  從檔案到其所屬Chunk之間的映射關係

3：每個Chunk在那台Chunk伺服器上儲存的資訊 【為了防止故障，每個chunk會被複製多份】

 

GFS將命名空間以及檔案到Chunk映射表都記錄在系統日誌中，日誌被儲存在多台機器上

對於第三類別中繼資料，主控伺服器啟動時會詢問每個Chunk伺服器，並定期詢問來保持最新的資訊

 

主控伺服器的其它職能：

建立新Chunk以及備份資料，不同的Chunk伺服器之間的負載平衡，如果那個chunk不可用，則負責產生新的備份，以及記憶體回收。

 

在資料備份和遷移時，需要考慮：

1：保持Chunk資料的可用性，當某個chunk不可用時，及時備份

2：儘可能減少網路傳輸壓力

 

系統的寫互動能力：

一個Chunk有多個備份，如果需要更新，則多個備份都需要同步更新

GFS的實現思路：

選擇一個主備份，兩個次備份，當需要更新時，發出3個Chunk備份請求，如果所有備份請求都接受到返回，則通知主備份開始寫入，

待主備份寫入完畢，返回給用戶端，用戶端通知次備份寫入開始，如果次備份寫入完畢，整體返回備份完成；

 

如果中間出現問題，則撤銷返回；

 

http://hi.baidu.com/huareal/item/c488ade7fa2e4bf8e0a5d4be