雲上儲存產品主要有物件儲存，塊儲存，網路檔案系統（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，延時高。

總結