本次大會(huì)，以“軟件定義存儲(chǔ)未來”為主題，DOIT主辦，中國開源云聯(lián)盟、中國超融合產(chǎn)業(yè)聯(lián)盟、Ceph中國社區(qū)和騰訊云+社區(qū)提供支持，吸引了來自全國各地的數(shù)百位專業(yè)觀眾參與。大會(huì)探討了SDS業(yè)內(nèi)最熱門的六大話題，包括SDS趨勢與實(shí)踐、開源云存儲(chǔ)、超融合、Ceph、互聯(lián)網(wǎng)云服務(wù)等等。數(shù)十位國內(nèi)外專家、學(xué)者和用戶親臨現(xiàn)場，結(jié)合軟件定義存儲(chǔ)技術(shù)、應(yīng)用、現(xiàn)狀及趨勢進(jìn)行了深入交流。

杉巖數(shù)據(jù)高級存儲(chǔ)技術(shù)專家梁欣鑫

以下內(nèi)容根據(jù)速記整理，未經(jīng)本人審定。

各位下午好！我來自杉巖數(shù)據(jù)，下面跟大家分享使用Ceph存儲(chǔ)海量小文件的實(shí)踐，今天要講的是小文件，解決小文件問題的幾點(diǎn)想法以及Sandstone Mos海量小文件的方案，最后是總結(jié)。

海量小文件帶來的問題

1、海量數(shù)據(jù)的性能問題。這是64K寫的性能測試，一開始的1萬到4億個(gè)對象，這個(gè)時(shí)候會(huì)發(fā)現(xiàn)寫入的性能逐步下降，從開始有15K的oes到下降到2.5，實(shí)際上下滑比例已經(jīng)達(dá)到了80%多，海量小文件的沖擊是非常大的。

究其原因，如果用的是Fd，底下的文件是要從Fd到dentry再到inode，superblock，1億的文件，256B，它已經(jīng)占了24G，小文件帶來的是要直接操作磁盤，直接操作磁盤會(huì)導(dǎo)致性能下降，海量的小文件會(huì)破壞空間的連續(xù)性，會(huì)產(chǎn)生大量的隨即讀寫。海量小文件會(huì)有大量源數(shù)據(jù)，性能還是不能得到流暢。

2、數(shù)據(jù)恢復(fù)效率問題， 數(shù)據(jù)在做恢復(fù)的過程中效率的問題，海量場景下恢復(fù)的速度，后者是前者的10倍，海量的小文件場景下，數(shù)據(jù)恢復(fù)的速度比較緩慢，而且效率很低，在此期間如果剛好不巧有業(yè)務(wù)請求過來，有可能會(huì)看到Slow Requses或是blocked，是存在風(fēng)險(xiǎn)的。

3、擴(kuò)容、恢復(fù)以后集群的性能還會(huì)出現(xiàn)驟降的情況。如果做了擴(kuò)容或是故障恢復(fù)，這個(gè)時(shí)候大量的小文件可能會(huì)被刪除，可能會(huì)出現(xiàn)大量的碎片，這個(gè)碎片可能出現(xiàn)在磁盤上，如果不進(jìn)行碎片的回收，里面系統(tǒng)的性能會(huì)出現(xiàn)驟降的情況，這是我們測的一組數(shù)據(jù)，前面很平穩(wěn)，一旦擴(kuò)容等恢復(fù)以后，這個(gè)比例會(huì)變大。

4、海量小文件的場景，數(shù)據(jù)的遷移效率比較低?？赡芟胗脭?shù)據(jù)冷熱分層的方式把熱數(shù)據(jù)移到冷的存儲(chǔ)池，這個(gè)時(shí)候有大量的小文件在這個(gè)過程中會(huì)產(chǎn)生遷移，而且這個(gè)遷移的過程中前面也會(huì)有，遷移以后數(shù)據(jù)可能進(jìn)行大量的刪除操作。之前測試的4000萬的小文件遷移消耗時(shí)間大于72個(gè)小時(shí)，算下來要兩天多的時(shí)間。這種情況下遷移的效率太低了。

解決小文件問題的幾點(diǎn)想法

海量小文件，是不是可以做合并？合并之后的文件，不是體積很小的文件，空間的使用效率是比較高的，對磁盤還是比較友好的。合并以后是不是可以提高讀寫的性能？

我們都知道，現(xiàn)在流數(shù)據(jù)，而且是寫在對象里，源數(shù)據(jù)是不是可以獨(dú)立？為什么做獨(dú)立？源數(shù)據(jù)獨(dú)立有兩個(gè)好處，源數(shù)據(jù)可以更加靈活的做選擇存儲(chǔ)，可以對這些源數(shù)據(jù)做一些其他的操作，比如說源數(shù)據(jù)是不是可以做其他方面的管理、檢索，都很方便的做。是不是可以把源數(shù)據(jù)部分抽出來？

同步和刪除的流程是不是可以改進(jìn)？如果做到第一點(diǎn)，文件做了合并的話，傳輸也是可以做合并的，而且刪除操作的時(shí)候，批量刪除是可以提升效率的。

基于這三點(diǎn)，Sandstone Mos針對海量小文件的問題提出了方案。

Sandstone Mos海量小文件的方案

第一步我們把源數(shù)據(jù)從Data pool抽出來進(jìn)行分離，源數(shù)據(jù)存在index pool，部署方式是不是和其他的部署方式不一樣，沒必要和Data pool綁在一起。每個(gè)對象把源數(shù)據(jù)抽出來以后，放在BI，源數(shù)據(jù)有它的BI，會(huì)有對應(yīng)的Data pool數(shù)據(jù)實(shí)體。我們?nèi)サ絀D里的Index，多個(gè)對象放在一起管理，這個(gè)時(shí)候很方便的能實(shí)現(xiàn)多個(gè)版本的數(shù)據(jù)管理。

這方面我們也需要一些數(shù)據(jù)，簡化整體的數(shù)據(jù)結(jié)構(gòu)。比如說讀寫數(shù)據(jù)有非常重要的結(jié)構(gòu)，在應(yīng)用數(shù)據(jù)結(jié)構(gòu)的時(shí)候發(fā)現(xiàn)有很多數(shù)據(jù)，這些數(shù)據(jù)不好的地方是沒怎么用、沒什么用，放在這里很占空間。里面有RGW很占空間，讀寫數(shù)據(jù)的時(shí)候其實(shí)沒必要關(guān)心這個(gè)對象是什么樣的，我們也去掉一部分的冗余數(shù)據(jù)簡化數(shù)據(jù)結(jié)構(gòu)。

在這上面我們也做了文件合并的工作。開始的想法是不同的對象可以寫到一個(gè)大項(xiàng)里，實(shí)際上這里會(huì)有幾個(gè)問題，對象寫進(jìn)來以后應(yīng)該朝哪個(gè)地方寫？后面會(huì)講一下大概的流程，處理小文件寫入的時(shí)候可不可以給一些因素簡化流程？不同的bucke的小文件合并到不同的大文件里，如果對象是同一個(gè)bucket會(huì)寫到同一個(gè)大對象里。我們都知道用的是shard的思想，BI分了不同的shard，為了簡化處理流程，，不同bucket的小文件存到不同的大文件。

文件合并以后要讀的時(shí)候應(yīng)該怎么讀？小文件的讀取比較簡單，存進(jìn)去改一下加上offs和lenght就可以了，所有的對象指向的數(shù)據(jù)實(shí)體只有一個(gè)，對象讀的時(shí)候知道開始位置就可以得到對應(yīng)小文件的數(shù)據(jù)。還是會(huì)有問題，簡單的話是合并就完了，問題是這個(gè)東西進(jìn)來以后，應(yīng)該寫到哪個(gè)對象上？所以對象進(jìn)來以后可能好幾層，這里就會(huì)有一個(gè)問題，假設(shè)兩個(gè)對象是寫到同一個(gè)大對象上，這個(gè)大對象的空間分配會(huì)是一個(gè)關(guān)鍵的問題，對象的空間分配一定要統(tǒng)一一個(gè)來源，可以避免寫同一個(gè)對象，保證區(qū)間不會(huì)相互交集。我們在Bucket使用omap_key存儲(chǔ)大對象元數(shù)據(jù)，可以起到空間分配的作用，對象寫進(jìn)來以后，最后是不是要確定對象放在哪個(gè)Bucket shard上，可以看到需要用哪個(gè)merged object，可能第一個(gè)寫0到24，第二個(gè)會(huì)記一個(gè)狀態(tài)，會(huì)把他的狀態(tài)記為已經(jīng)使用，下一次線程過來就不會(huì)用空間。會(huì)把空閑的空間分配給他，我每個(gè)線程寫的時(shí)候拿到的空間分配信息之后，就可以寫相應(yīng)的偏移。我們每個(gè)對象在上面都做了空間的管理。

刪除操作可能會(huì)出現(xiàn)幾個(gè)問題，刪除的空間怎么進(jìn)行回收？可能刪了幾個(gè)小對象后大對象整體會(huì)出現(xiàn)空洞的情況，什么時(shí)候進(jìn)行整體的回收？進(jìn)行整體回收的時(shí)候這些小文件要怎么進(jìn)行適度的遷移？前面說的空間管理情況下有條目的狀態(tài)，既可以在空間分配中用到，也可以在刪除小文件的時(shí)候用到，刪除小文件的時(shí)候是異步刪除的方式，可以在這個(gè)大對象上做個(gè)狀態(tài)的更改，里面會(huì)涉及到兩個(gè)操作，不單只是刪除小文件的時(shí)候要?jiǎng)h原來的小文件BI，還要改大BI的狀態(tài)。

我們有兩個(gè)對象可能被刪除會(huì)標(biāo)deleted的狀態(tài)，刪除的時(shí)候如果數(shù)據(jù)不進(jìn)行立刻的回收，空間是存在一定的浪費(fèi)。這個(gè)時(shí)候要靈活運(yùn)用object的接口，這個(gè)時(shí)候空間做了一定的回收，所以這個(gè)接口是比較友好的，對于快速釋放空間，提高空間的利用率，有可能大對象的區(qū)間被刪除，當(dāng)空間使用率達(dá)到一定程度的時(shí)候，我們要進(jìn)行整體的回收，大對象可以反向索引到每個(gè)小對象上，小對象也需要記錄自己所處的大對象，這兩個(gè)操作是為了后面鋪墊的，要做刪除操作的時(shí)候，小對象必須自己清楚，我是屬于哪個(gè)大對象的？刪除的時(shí)候可以在上面記這個(gè)狀態(tài)，大對象有要記自己被哪些小對象引用，為什么這樣處理？如果說空間使用率低到一定程度的時(shí)候，要進(jìn)行整體的回收，這個(gè)時(shí)候還在使用小文件怎么辦？大對象必須反向索引到有哪些小對象在用它？這個(gè)時(shí)候我們把小文件的數(shù)據(jù)挪出來，遷移到其他大對象里。整體的機(jī)器操作是完全的異步方式，如果你在刪除對象的時(shí)候會(huì)進(jìn)行res的，為了處理其他的問題，把整個(gè)過程變成異步的，包括BI的刪除和數(shù)據(jù)的刪除都變成異步的方式。

同步和數(shù)據(jù)遷移原理是一樣的，無非是把大量的數(shù)據(jù)從一個(gè)站點(diǎn)，從一個(gè)存儲(chǔ)池遷到另一個(gè)存儲(chǔ)池，這一點(diǎn)是最為頭疼的，會(huì)涉及到非常多邏輯的問題，比如說合并后的文件是怎么進(jìn)行同步的？小文件的元數(shù)據(jù)，合并以后的文件進(jìn)行同步，元數(shù)據(jù)怎么同步，是不是會(huì)存在先后順序的問題？

大家如果了解的話，多站點(diǎn)的同步分為兩部分，一個(gè)是全量同步，一個(gè)是增量同步，兩個(gè)同步的方式和base的實(shí)際結(jié)構(gòu)是不太一樣的。如果你是全量投入的情況下，AB兩個(gè)站點(diǎn)是進(jìn)行全量同步的，我做全量同步的時(shí)候會(huì)把里面的對象都拿過來，增量同步就不一樣。先分場景做，我第一步是先把這些合并之后的文件、數(shù)據(jù)整體的拉過去，包括前面提到的大對象，實(shí)際上也有自己的BI，這個(gè)時(shí)候?qū)ξ襾碚f也是一個(gè)對象，我會(huì)把這些數(shù)據(jù)統(tǒng)一丟過去，小文件的元數(shù)據(jù)還是維持。

增量同步的情況比較復(fù)雜，這個(gè)大對象是寫到100，這個(gè)時(shí)候怎么把它同步過來？這里面有點(diǎn)取巧，像這種情況下，我們要處理這個(gè)邏輯，前面全量可能把這個(gè)拉過去，根據(jù)多個(gè)BI，如果發(fā)現(xiàn)是多條邊、是寫在同一個(gè)同類項(xiàng)上，這個(gè)時(shí)候會(huì)把數(shù)據(jù)做合并類似于前面同步的方式，把數(shù)據(jù)合并丟過去。最后源數(shù)據(jù)還是通過BI的方式，把源數(shù)據(jù)拉過來，每次請求的效率會(huì)比以前高一些。

兩個(gè)數(shù)據(jù)池遷移的時(shí)候，跟全量同步的場景是一樣的，全量同步的情況下和存儲(chǔ)數(shù)據(jù)池的遷移是一樣的場景，這個(gè)時(shí)候沒有單列存儲(chǔ)池的場景。

總結(jié)

1.海量小文件的性能。我們在做完文件合并以后，文件數(shù)是能明顯下降的，解決海量數(shù)據(jù)場景下的性能問題，文件合并以后，對于磁盤來說是比較友好的，合并以后可能是比較大的文件，比如說我們合并至少都是4M的文件，合并以后文件的數(shù)據(jù)量會(huì)明顯下降。

2.恢復(fù)效率。文件合并以后效率也可以得到巨大的支撐，原來都是32K的文件，有100個(gè)32K的文件，合并以后是3M多的文件，每次請求要恢復(fù)的文件數(shù)目明顯減少了。

3.擴(kuò)容后的性能驟降的問題，合并后的文件對于空間的使用率更高，就算會(huì)出現(xiàn)大量的數(shù)據(jù)刪除情況，這個(gè)時(shí)候?qū)τ诖疟P的使用也是更加友好的，因?yàn)檫@個(gè)時(shí)候磁盤也不會(huì)出現(xiàn)過度的空洞碎片。

4.數(shù)據(jù)遷移的整體做了優(yōu)化，數(shù)據(jù)合并之后遷移的效率也會(huì)明顯的提高，前面可能分了100個(gè)小文件，可能是請求100次的32K文件，可能是100次32K的請求，合并之后只需要一次移過量就可以了，后面的所有操作都是不需要再跨兩個(gè)Pool。

整體來看，我們的方案可以解決前面所提到的四個(gè)問題。

最后介紹一下杉巖數(shù)據(jù)，杉巖數(shù)據(jù)2014年成立，創(chuàng)始人都是來自于500強(qiáng)企業(yè)，今年已經(jīng)獲得了深圳中小擔(dān)集團(tuán)跟投的B輪融資，針對目前Ceph遇到的問題我們也在做一些積極的投入。這是我們當(dāng)前的客戶（見PPT），今天就講到這里，謝謝。

xiesc