雲端儲存產品介紹

雲上儲存產品主要有物件儲存，塊儲存，網路檔案系統（ NAS），還有最賺錢的CDN，我們將針對這些主流產品，講講他們產品特點，有云上儲存時候知道如何選型，當然我們是技術型作者也會簡單講講實現思路，出於資訊保安，不可能完全闡述工業界方案。工業界各大廠商很多上層儲存產品都重度依賴底層檔案系統，我們也捎帶說說儲存祖師爺DFS。

Linux IO STACK

 

雲端計算本質就是單機計算能力的無限擴充套件，我們先看看單機的檔案及 IO 管理。 linux 作業系統一個 IO 操作要經由檔案系統 vfs ，排程演算法，塊裝置層，最終落盤 ：

（ 1 ） 其中 vfs層有具體的NFS/smbfs 支援網路協議派生出來NAS產品

（ 2 ） VFS還有一個fuse檔案系統，可切換到使用者態上下文。上層分散式儲存只要適配了Libfuse介面，就可訪問後端儲存

 

（ 3 ） 在裝置層，通過擴充套件 ISCSI網路協議，衍生出了塊儲存

 

儲存產品架構流派

分層或平層 :

如 hbase ，底層基於 hdfs 檔案系統， hbase 不用考慮 replication ，專注於自身領域問題  
特點：大大降低開發成本，穩定性依賴底層儲存，底層不穩定，上層遭殃。

豎井 :

自己做 replication ，自己做副本 recover ，自己做寫時 recover   master-slave 體系架構

 

兩層索引體系，解決 lots of small file

第一層， master維護一個路由表，通過fileurl找到對應slave location（ip+port）

第二層， slave單機索引體系，找到具體的location，讀出raw data   DFS

 

 

特點 : 豐富類 posix語意，特點Append-only儲存，不支援pwrite

可能存在問題 :

（ 1 ） Pb級別儲存方案，非EB級別。 原因namenode集中式server，記憶體&qps瓶頸，bat體量公司需運維上百個叢集

（ 2 ） 預設三副本，成本高

（ 3 ） 強一致寫，慢節點問題

演進 :

GFS2拆分了namenode，拆分成目錄樹，blockservice，外加ferdaration，但namespace集中式server缺陷依舊，同時切分image是要停服，水平擴充套件不是那麼友好。

物件儲存 :

 

 

後設資料管理

Blobstorage： blobid->[raw data]
Metastore，aws s3又稱為keymap，本質上是個kv系統。儲存內容file_url->[blobid list]

I/O 路徑

（ 1 ） httpserver收到muti-part form,收到固定大小raw data，切成K份等長條帶

（ 2 ） 條帶做 EC，生成（N-K）份編碼塊，共得到N份shard。現在的問題變成了這N份資料存哪

（ 3 ） 客戶端的代理繼續向 blobstorage申請一個全域性的id，這個id代表了了後端實際node的地址，以及這個node管理的實際物理卷，我們的每個分片資料均等的存在這些物理捲上。

（ 4 ） 分發寫 N份資料，滿足安全副本數即可返回寫成功，寫失敗的可延時EC方式修復

（ 5 ） httpserver將檔案file及對應的分片列表以KV形式寫入metastore。

 

 

特點 :

基於 http 協議 ws 服務，介面簡單， put/get ，延時高。 EB 級別儲存方案，適合雲上產品形態。深度目錄樹變成兩層目錄結構（ bucket+object ）。

缺點 :

posix 語意介面太少，不提供 append 語意（其實是通過覆蓋寫提供），更別說隨機寫。

iscsi模型

與後端互動的的部分在核心實現，後端 target 解析 iscsi 協議並將請求對映到後端分散式儲存

 

特點：

（ 1 ） 絕大多數請求大小是 4K 對齊的 blocksize. 塊裝置的使用一般上層檔案系統，而大多數主流檔案系統的塊大小是 4KB ，檔案最小操作粒度是塊，因此絕大多數的 IO 請求是 4KB 對齊的。

（ 2 ） 強一致 . 塊裝置必須提供強一致，即寫返回後，能夠讀到寫進去的資料。

（ 3 ） 支援隨機寫，延時要低使用者基於虛擬塊裝置構建檔案系統（ ext4 ），對於檔案編輯操作很頻繁，所以需要支援隨機寫。比 NAS/Fuse 類產品效能好，只 hack 塊裝置讀寫，上層 dentry lookup 還是走原來的 IO path ，沒有像 NAS/FUSE dentry 的 lookup 發起多次 rpc 問題

（ 4 ） 產品層面需要預先購買容量，擴容需要重新掛載，跟 NAS 比容易浪費空間

實現模型：

 

 

雲盤邏輯卷按 block切分，為了便於recover，按1G切分，第一層路由由blockManager管理，按volumeid+offset 對映到邏輯block，邏輯block location在三臺blockserver上。Blockserver預先建立一個1G檔案（falloc，防止寫過程中空間不夠)，稱為物理block。對於邏輯卷這段區間所有的IO操作都會落到這個物理block檔案上，很容易實現pwrite。當然也可以基於裸盤，在os看來是一個大檔案，分割成不同的1G檔案

IO路徑：

塊裝置上層會有檔案系統，經過 io排程演算法，合併io操作，isici協議發出的IO請求的都是對扇區LBA的操作，所以可以簡單抽象成對於卷id加上偏移的操作，我們簡單講講EBS（Elastic Block Store）層IO路徑

（ 1 ） 網路發出來的 IO 請求是針對 volume+offerset 操作，假定是個寫請求

（ 2 ） 通過 blockManager 查詢到邏輯 block

（ 3 ） 在記憶體中找到 block 對應的實體地址（ ip+port ）， block 的 replicationGroup

（ 4 ） 使用業界通用複製鏈方式如 raft 協議向 replicationGroup 傳送 io 請求， raft 幫我們解決寫時失敗 tuncate 問題

（ 5 ） 單節點接到 IO 請求，把 LBA 換算成真實的檔案偏移， pwrite 寫下去

優化

a、 可想而知，這種儲存模型下，後端 node會有大量的隨機寫，吞吐肯定不高，有很大的優化空間 可以通過類似LSM引擎方式，將隨機寫變成順序寫，讀者可深入思考，本文不詳細探討了。

b、 虛擬磁碟可以切條掉，相當於 raid盤思路，單塊盤的IO變成多多塊盤，增大吞吐。

 

NAS

 

 

使用者通過 mount目錄訪問共享檔案，mount點掛在的是一個NFS協議的檔案系統，會通過tcp訪問到NFS server。
NFS server是一個代理，通過libcfs最終會訪問到我們後端的儲存系統。

後端儲存系統

 

 

DS包含管理inode的metastore和datastore，metastore

我們充分吸取業界 DFS缺點，解決Namenode集中式server瓶頸，充分考慮bigtable的各種優點。Metastore可基於分散式資料庫（newsql），回想一下bigtable，一個使用者的檔案散落在多個tabletserver上，允許使用者跨tabletserver rename操作，所以需要分散式事務完成上述保證，出於對DFS改進，我們把目錄樹持久化模仿linux fs dentry管理，對映規則如下兩張表，dentry表和inode表，dentry表描述目錄樹，inode表描述檔案block列表及atime，mtime，uid，gid等源資訊，一般來講硬鏈夠用，該場景下dentry可以多份，共同指向一個inode。  dentry通過外健關聯到inode表

 

比如 lookup 子節點

SELECT i.* FROM Dentry d, Inode i WHERE d.PARENT_DID=$PARENT_ID

datastore

特點：要求提供隨機寫，所以跟塊儲存 EBS設計思路是一樣的，大檔案切塊，按塊組織，dataserver上有真實的物理block檔案，提供pwrite操作。

特點

彈性容量，不限容量，多機掛載並行讀寫， IO線性增長，支援隨機寫比塊儲存優勢在於用多少花多少，不需要提前申請容量，真彈性

缺點

vfs層 dentry lookup每個層級目錄會發起rpc，延時高。

總結

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31524777/viewspace-2214553/，如需轉載，請註明出處，否則將追究法律責任。