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

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

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

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

海量小文件帶來的問題

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

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

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

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

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

解決小文件問題的幾點想法

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

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

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

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

Sandstone Mos海量小文件的方案

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

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

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

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

xiesc