雲存儲平臺產品淺析

 

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

總結