云上存儲(chǔ)產(chǎn)品主要有對(duì)象存儲(chǔ)，塊存儲(chǔ)，網(wǎng)絡(luò)文件系統(tǒng)(NAS)，還有***錢的CDN，我們將針對(duì)這些主流產(chǎn)品，講講他們產(chǎn)品特點(diǎn)，有云上存儲(chǔ)時(shí)候知道如何選型，當(dāng)然我們是技術(shù)型作者也會(huì)簡(jiǎn)單講講實(shí)現(xiàn)思路，出于信息安全，不可能完全闡述工業(yè)界方案。 工業(yè)界各大廠商很多上層存儲(chǔ)產(chǎn)品都重度依賴底層文件系統(tǒng)，我們也捎帶說說存儲(chǔ)祖師爺DFS。

一、Linux IO STACK

云計(jì)算本質(zhì)就是單機(jī)計(jì)算能力的***擴(kuò)展，我們先看看單機(jī)的文件及IO管理。 linux操作系統(tǒng)一個(gè)IO操作要經(jīng)由文件系統(tǒng)vfs，調(diào)度算法，塊設(shè)備層，最終落盤

• 其中vfs層有具體的NFS/smbfs 支持網(wǎng)絡(luò)協(xié)議派生出來NAS產(chǎn)品
• VFS還有一個(gè)fuse文件系統(tǒng)，可切換到用戶態(tài)上下文。上層分布式存儲(chǔ)只要適配了Libfuse接口，就可訪問后端存儲(chǔ)
• 在設(shè)備層，通過擴(kuò)展ISCSI網(wǎng)絡(luò)協(xié)議，衍生出了塊存儲(chǔ)

二、存儲(chǔ)產(chǎn)品架構(gòu)流派

1. 分層或平層

如hbase，底層基于hdfs文件系統(tǒng)，hbase不用考慮replication，專注于自身領(lǐng)域問題

特點(diǎn)：大大降低開發(fā)成本，穩(wěn)定性依賴底層存儲(chǔ)，底層不穩(wěn)定，上層遭殃。

2. 豎井

自己做replication，自己做副本recover，自己做寫時(shí)recover

master-slave體系架構(gòu)

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

• ***層，master維護(hù)一個(gè)路由表，通過fileurl找到對(duì)應(yīng)slave location(ip+port)
• 第二層，slave單機(jī)索引體系，找到具體的location，讀出raw data

DFS

3. 特點(diǎn)

豐富類posix語意，特點(diǎn)Append-only存儲(chǔ)，不支持pwrite

4. 可能存在問題

• Pb級(jí)別存儲(chǔ)方案，非EB級(jí)別。 原因namenode集中式server，內(nèi)存&qps瓶頸，bat體量公司需運(yùn)維上百個(gè)集群
• 默認(rèn)三副本，成本高
• 強(qiáng)一致寫，慢節(jié)點(diǎn)問題

5. 演進(jìn)

GFS2拆分了namenode，拆分成目錄樹，blockservice，外加ferdaration，但namespace集中式server缺陷依舊，同時(shí)切分image是要停服，水平擴(kuò)展不是那么友好。

三、對(duì)象存儲(chǔ)

1. 元數(shù)據(jù)管理

Blobstorage： blobid->[raw data]

Metastore，aws s3又稱為keymap，本質(zhì)上是個(gè)kv系統(tǒng)。存儲(chǔ)內(nèi)容file_url->[blobid list]

2. I/O 路徑

• httpserver收到muti-part form,收到固定大小raw data，切成K份等長(zhǎng)條帶
• 條帶做EC，生成(N-K)份編碼塊，共得到N份shard。現(xiàn)在的問題變成了這N份數(shù)據(jù)存哪
• 客戶端的代理繼續(xù)向blobstorage申請(qǐng)一個(gè)全局的id，這個(gè)id代表了了后端實(shí)際node的地址，以及這個(gè)node管理的實(shí)際物理卷，我們的每個(gè)分片數(shù)據(jù)均等的存在這些物理卷上。
• 分發(fā)寫N份數(shù)據(jù)，滿足安全副本數(shù)即可返回寫成功，寫失敗的可延時(shí)EC方式修復(fù)
• httpserver將文件file及對(duì)應(yīng)的分片列表以KV形式寫入metastore。

3. 特點(diǎn)

基于http協(xié)議 ws服務(wù)，接口簡(jiǎn)單，put/get，延時(shí)高。 EB級(jí)別存儲(chǔ)方案，適合云上產(chǎn)品形態(tài)。深度目錄樹變成兩層目錄結(jié)構(gòu)(bucket+object)。

4. 缺點(diǎn)

posix語意接口太少，不提供append語意(其實(shí)是通過覆蓋寫提供)，更別說隨機(jī)寫。

四、塊存儲(chǔ)

1. iscsi模型

與后端交互的的部分在內(nèi)核實(shí)現(xiàn)，后端target解析iscsi協(xié)議并將請(qǐng)求映射到后端分布式存儲(chǔ)

2. 特點(diǎn)

• 絕大多數(shù)請(qǐng)求大小是4K對(duì)齊的blocksize. 塊設(shè)備的使用一般上層文件系統(tǒng)，而大多數(shù)主流文件系統(tǒng)的塊大小是4KB，文件最小操作粒度是塊，因此絕大多數(shù)的IO請(qǐng)求是4KB對(duì)齊的。
• 強(qiáng)一致. 塊設(shè)備必須提供強(qiáng)一致，即寫返回后，能夠讀到寫進(jìn)去的數(shù)據(jù)。
• 支持隨機(jī)寫，延時(shí)要低 用戶基于虛擬塊設(shè)備構(gòu)建文件系統(tǒng)(ext4)，對(duì)于文件編輯操作很頻繁，所以需要支持隨機(jī)寫。 比NAS/Fuse類產(chǎn)品性能好，只hack塊設(shè)備讀寫，上層dentry lookup還是走原來的IO path，沒有像NAS/FUSE dentry的lookup發(fā)起多次rpc問題
• 產(chǎn)品層面需要預(yù)先購(gòu)買容量，擴(kuò)容需要重新掛載，跟NAS比容易浪費(fèi)空間

3. 實(shí)現(xiàn)模型

云盤邏輯卷按block切分，為了便于recover，按1G切分，***層路由由blockManager管理，按volumeid+offset 映射到邏輯block，邏輯block location在三臺(tái)blockserver上。Blockserver預(yù)先創(chuàng)建一個(gè)1G文件(falloc，防止寫過程中空間不夠)，稱為物理block。對(duì)于邏輯卷這段區(qū)間所有的IO操作都會(huì)落到這個(gè)物理block文件上，很容易實(shí)現(xiàn)pwrite。當(dāng)然也可以基于裸盤，在os看來是一個(gè)大文件，分割成不同的1G文件

4. IO路徑

塊設(shè)備上層會(huì)有文件系統(tǒng)，經(jīng)過io調(diào)度算法，合并io操作，isici協(xié)議發(fā)出的IO請(qǐng)求的都是對(duì)扇區(qū)LBA的操作，所以可以簡(jiǎn)單抽象成對(duì)于卷id加上偏移的操作，我們簡(jiǎn)單講講EBS(Elastic Block Store)層IO路徑：

• 網(wǎng)絡(luò)發(fā)出來的IO請(qǐng)求是針對(duì)volume+offerset操作，假定是個(gè)寫請(qǐng)求
• 通過blockManager查找到邏輯block
• 在內(nèi)存中找到block對(duì)應(yīng)的物理地址(ip+port)，block的replicationGroup
• 使用業(yè)界通用復(fù)制鏈方式如raft協(xié)議向replicationGroup發(fā)送io請(qǐng)求，raft幫我們解決寫時(shí)失敗tuncate問題
• 單節(jié)點(diǎn)接到IO請(qǐng)求，把LBA換算成真實(shí)的文件偏移，pwrite寫下去

5. 優(yōu)化

• 可想而知，這種存儲(chǔ)模型下，后端node會(huì)有大量的隨機(jī)寫，吞吐肯定不高，有很大的優(yōu)化空間 可以通過類似LSM引擎方式，將隨機(jī)寫變成順序?qū)懀x者可深入思考，本文不詳細(xì)探討了。
• 虛擬磁盤可以切條掉，相當(dāng)于raid盤思路，單塊盤的IO變成多多塊盤，增大吞吐。

五、NAS

用戶通過mount目錄訪問共享文件，mount點(diǎn)掛在的是一個(gè)NFS協(xié)議的文件系統(tǒng)，會(huì)通過tcp訪問到NFS server。

NFS server是一個(gè)代理，通過libcfs最終會(huì)訪問到我們后端的存儲(chǔ)系統(tǒng)。

1. 后端存儲(chǔ)系統(tǒng)

DS包含管理inode的metastore和datastore

(1) metastore

我們充分吸取業(yè)界DFS缺點(diǎn)，解決Namenode集中式server瓶頸，充分考慮bigtable的各種優(yōu)點(diǎn)。Metastore可基于分布式數(shù)據(jù)庫(kù)(newsql)，回想一下bigtable，一個(gè)用戶的文件散落在多個(gè)tabletserver上，允許用戶跨tabletserver rename操作，所以需要分布式事務(wù)完成上述保證，出于對(duì)DFS改進(jìn)，我們把目錄樹持久化 模仿linux fs dentry管理，映射規(guī)則如下 兩張表，dentry表和inode表，dentry表描述目錄樹，inode表描述文件block列表及atime，mtime，uid，gid等源信息，一般來講硬鏈夠用，該場(chǎng)景下dentry可以多份，共同指向一個(gè)inode。 dentry通過外健關(guān)聯(lián)到inode表

(2) Dentry表

(3) Inode表

比如lookup 子節(jié)點(diǎn)

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

特點(diǎn)：要求提供隨機(jī)寫，所以跟塊存儲(chǔ)EBS設(shè)計(jì)思路是一樣的，大文件切塊，按塊組織，dataserver上有真實(shí)的物理block文件，提供pwrite操作。

2. 特點(diǎn)

彈性容量，不限容量，多機(jī)掛載并行讀寫，IO線性增長(zhǎng)，支持隨機(jī)寫 比塊存儲(chǔ)優(yōu)勢(shì)在于用多少花多少，不需要提前申請(qǐng)容量，真彈性

3. 缺點(diǎn)

vfs層 dentry lookup每個(gè)層級(jí)目錄會(huì)發(fā)起rpc，延時(shí)高。

六、總結(jié)

【本文為51CTO專欄作者“大數(shù)據(jù)和云計(jì)算”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過微信公眾號(hào)獲取聯(lián)系和授權(quán)】

戳這里，看該作者更多好文