云存儲產品淺析
云上存儲產品主要有對象存儲，塊存儲，網絡文件系統(NAS)，還有***錢的CDN，我們將針對這些主流產品，講講他們產品特點，有云上存儲時候知道如何選型，當然我們是技術型作者也會簡單講講實現思路，出于信息安全，不可能完全闡述工業界方案。 工業界各大廠商很多上層存儲產品都重度依賴底層文件系統，我們也捎帶說說存儲祖師爺DFS。
一、Linux IO STACK
云計算本質就是單機計算能力的***擴展，我們先看看單機的文件及IO管理。 linux操作系統一個IO操作要經由文件系統vfs，調度算法，塊設備層，最終落盤
- 其中vfs層有具體的NFS/smbfs 支持網絡協議派生出來NAS產品
- VFS還有一個fuse文件系統，可切換到用戶態上下文。上層分布式存儲只要適配了Libfuse接口，就可訪問后端存儲
- 在設備層，通過擴展ISCSI網絡協議，衍生出了塊存儲
二、存儲產品架構流派
1. 分層或平層
如hbase，底層基于hdfs文件系統，hbase不用考慮replication，專注于自身領域問題
特點：大大降低開發成本，穩定性依賴底層存儲，底層不穩定，上層遭殃。
2. 豎井
自己做replication，自己做副本recover，自己做寫時recover
master-slave體系架構
兩層索引體系，解決lots of small file：
- ***層，master維護一個路由表，通過fileurl找到對應slave location(ip+port)
- 第二層，slave單機索引體系，找到具體的location，讀出raw data
DFS
3. 特點
豐富類posix語意，特點Append-only存儲，不支持pwrite
4. 可能存在問題
- Pb級別存儲方案，非EB級別。 原因namenode集中式server，內存&qps瓶頸，bat體量公司需運維上百個集群
- 默認三副本，成本高
- 強一致寫，慢節點問題
5. 演進
GFS2拆分了namenode，拆分成目錄樹，blockservice，外加ferdaration，但namespace集中式server缺陷依舊，同時切分image是要停服，水平擴展不是那么友好。
三、對象存儲
1. 元數據管理
Blobstorage： blobid->[raw data]
Metastore，aws s3又稱為keymap，本質上是個kv系統。存儲內容file_url->[blobid list]
2. I/O 路徑
- httpserver收到muti-part form,收到固定大小raw data，切成K份等長條帶
- 條帶做EC，生成(N-K)份編碼塊，共得到N份shard。現在的問題變成了這N份數據存哪
- 客戶端的代理繼續向blobstorage申請一個全局的id，這個id代表了了后端實際node的地址，以及這個node管理的實際物理卷，我們的每個分片數據均等的存在這些物理卷上。
- 分發寫N份數據，滿足安全副本數即可返回寫成功，寫失敗的可延時EC方式修復
- httpserver將文件file及對應的分片列表以KV形式寫入metastore。
3. 特點
基于http協議 ws服務，接口簡單，put/get，延時高。 EB級別存儲方案，適合云上產品形態。深度目錄樹變成兩層目錄結構(bucket+object)。
4. 缺點
posix語意接口太少，不提供append語意(其實是通過覆蓋寫提供)，更別說隨機寫。
四、塊存儲
1. iscsi模型
與后端交互的的部分在內核實現，后端target解析iscsi協議并將請求映射到后端分布式存儲
2. 特點
- 絕大多數請求大小是4K對齊的blocksize. 塊設備的使用一般上層文件系統，而大多數主流文件系統的塊大小是4KB，文件最小操作粒度是塊，因此絕大多數的IO請求是4KB對齊的。
- 強一致. 塊設備必須提供強一致，即寫返回后，能夠讀到寫進去的數據。
- 支持隨機寫，延時要低 用戶基于虛擬塊設備構建文件系統(ext4)，對于文件編輯操作很頻繁，所以需要支持隨機寫。 比NAS/Fuse類產品性能好，只hack塊設備讀寫，上層dentry lookup還是走原來的IO path，沒有像NAS/FUSE dentry的lookup發起多次rpc問題
- 產品層面需要預先購買容量，擴容需要重新掛載，跟NAS比容易浪費空間
3. 實現模型
云盤邏輯卷按block切分，為了便于recover，按1G切分，***層路由由blockManager管理，按volumeid+offset 映射到邏輯block，邏輯block location在三臺blockserver上。Blockserver預先創建一個1G文件(falloc，防止寫過程中空間不夠)，稱為物理block。對于邏輯卷這段區間所有的IO操作都會落到這個物理block文件上，很容易實現pwrite。當然也可以基于裸盤，在os看來是一個大文件，分割成不同的1G文件
4. IO路徑
塊設備上層會有文件系統，經過io調度算法，合并io操作，isici協議發出的IO請求的都是對扇區LBA的操作，所以可以簡單抽象成對于卷id加上偏移的操作，我們簡單講講EBS(Elastic Block Store)層IO路徑：
- 網絡發出來的IO請求是針對volume+offerset操作，假定是個寫請求
- 通過blockManager查找到邏輯block
- 在內存中找到block對應的物理地址(ip+port)，block的replicationGroup
- 使用業界通用復制鏈方式如raft協議向replicationGroup發送io請求，raft幫我們解決寫時失敗tuncate問題
- 單節點接到IO請求，把LBA換算成真實的文件偏移，pwrite寫下去
5. 優化
- 可想而知，這種存儲模型下，后端node會有大量的隨機寫，吞吐肯定不高，有很大的優化空間 可以通過類似LSM引擎方式，將隨機寫變成順序寫，讀者可深入思考，本文不詳細探討了。
- 虛擬磁盤可以切條掉，相當于raid盤思路，單塊盤的IO變成多多塊盤，增大吞吐。
五、NAS
用戶通過mount目錄訪問共享文件，mount點掛在的是一個NFS協議的文件系統，會通過tcp訪問到NFS server。
NFS server是一個代理，通過libcfs最終會訪問到我們后端的存儲系統。
1. 后端存儲系統
DS包含管理inode的metastore和datastore
(1) 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表
(2) Dentry表
(3) Inode表
比如lookup 子節點
- SELECT i.* FROM Dentry d, Inode i WHERE d.PARENT_DID=$PARENT_ID AND d.NAME=$NAME AND d.FSID=$FSID and i.inode_id = d.inode_id;
(4) datastore
特點：要求提供隨機寫，所以跟塊存儲EBS設計思路是一樣的，大文件切塊，按塊組織，dataserver上有真實的物理block文件，提供pwrite操作。
2. 特點
彈性容量，不限容量，多機掛載并行讀寫，IO線性增長，支持隨機寫 比塊存儲優勢在于用多少花多少，不需要提前申請容量，真彈性
3. 缺點
vfs層 dentry lookup每個層級目錄會發起rpc，延時高。
六、總結
【本文為51CTO專欄作者“大數據和云計算”的原創稿件，轉載請通過微信公眾號獲取聯系和授權】
