云存儲產品介紹

云上存儲產品主要有對象存儲，塊存儲，網絡文件系統（ 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，延時高。

總結