作為歡聚集團旗下品牌,BIGO當前的業務涵蓋直播,短視頻和社交,目前已經服務于全球150個國家4億用戶。BIGO的產品業務特性決定了其對海量小文件的存儲需求,如內容審核截圖,用戶社交溝通過程中發送的小文件,用戶的頭像等。目前BIGO每天會新增約幾十億個小文件,占用約30TB存儲空間。對于海量小文件存儲,如何在保證高性能的同時降低存儲的成本,成為BIGO存儲團隊必須解決的問題。

01海量小文件存儲的挑戰

為了解決海量小文件的存儲問題,必須采用分布式存儲,目前分布式存儲主要采用兩種架構:集中式元數據管理架構和去中心化架構。

(1)集中式元數據架構:

典型的集中式元數據架構的分布式存儲有GFS,HDFS,MooseFs等。其采用的典型架構如下圖1所示:

此架構主要包含3個部分:

1)客戶端:主要用于提供訪問分布式存儲系統的接口;

2) 元數據服務器:主要用于存放分布式存儲系統的命名空間和文件的一些元數據信息。

3)存儲服務器: 主要負責存儲文件的具體數據。

使用集中式的元數據管理的方式,其主要優點如下:

1) 元數據的操作性能高: 存儲系統的命令空間和文件的元數據都存放在元數據服務器上,元數據操作如list directory和create file等元數據的操作性能會比較高;

2) 擴容時不需要數據遷移:元數據服務器上存放有所有文件的位置信息,在集群需要擴容增加新的節點時,這些位置信息不需要變動,因此集群在擴容時不需要進行數據遷移。

其主要缺點如下:

1) 元數據節點是瓶頸:客戶端在訪問文件數據之前通常都需要到元數據節點上查詢文件的位置信息,因此元數據節點不可避免地成為了整個系統的性能瓶頸。

2) 文件的數量受限:為了提高性能,元數據節點中的數據一般都會保存到內存中,而元數據節點的內存不是無限增長的。

基于以上缺點,集中式的元數據管理方式非常不適合于海量小文件的存儲。

(2)    去中心化架構:

為了解決集中式元數據架構的問題,去中心化架構的分布式存儲產生,典型的去中心化分布式存儲有GlusterFs,Ceph等。其采用的典型的架構如下圖2所示:

此架構主要包含3個部分:

1) 客戶端: 主要用于提供訪問分布式存儲系統的接口。

2) 存儲服務器:主要負責存儲文件的具體數據和元數據。

去中心化架構沒有單獨的元數據節點去保存文件的命名空間和元數據,元數據依然存儲在存儲節點上,文件的尋址一般采用DHT(一致性HASH)的方式計算。此架構一般會將多個存儲節點進行邏輯分組,組內復制保證數據可靠性,因此會有可選的中心端服務器保存整個集群的存儲節點以及分組信息。例如Ceph使用Ceph monitor保存整個集群的成員和狀態信息(不保存文件信息),而GlusterFs選擇將這些信息存放在所有的存儲節點上。

使用去中心化的的方式,其主要優點如下:

1)無單點的性能瓶頸: 沒有單獨的元數據節點,客戶端可以直接通過Hash的方式尋址文件,直接到存儲節點上訪問。

2) 文件的數量幾乎不受限制: 沒有單獨的元數據節點,理論上文件的數量不受中心端節點容量的限制。

3) 讀寫性能更高: 讀寫請求不用到元數據節點上尋址而采用Hash計算的方式,理論上性能更高。

從以上優點可以得出去中心化的架構還是比較適合海量小文件的存儲。由于GlusterFs的存儲節點采用Linux本地文件系統存儲數據,沒有對小文件的讀寫進行優化,而Ceph從Jewel版本開始引入BlueStore存儲引擎,對海量小文件的讀寫有較大的優化,因此我們選擇使用Ceph存儲海量小文件。

Ceph相對其他的分布式存儲更適合海量小文件的存儲,但還是有幾個問題待解決:

1) Index數據量太大:海量小文件會導致bucket index中的數據量增長過快,從而導致bucket index需要經常resharding,而在bucket index resharding過程中會阻塞讀寫請求,對于大多數不需要list bucket的場景,此問題可以通過使用indexless bucket解決。對于必須bucket index的場景,增加了順序分布的bucket index優化解決方案,此方案不在本文的討論范圍內,會在后面的文章中進行介紹。

2) 擴容時需要數據遷移:Ceph在數據擴容的過程中,需要對文件的位置進行重新哈希,并會帶來大量的數據遷移操作,數據遷移過程中會帶來巨大的性能損耗。同時海量小文件的數據遷移會耗費較長的時間,如果在此過程中磁盤故障或機器故障,數據恢復的時間將不確定,會帶來極大的數據安全風險。

3) 存儲效率問題:Ceph默認的最小分配單元為64KB,而當前小文件的平均size為15KB。為了提高存儲效率,可以將最小分配單元調整為4KB(讀寫性能會隨之降低)。當使用糾刪碼的方式存儲存儲小文件,如(4+2)的糾刪碼,此時文件的最小分配單元變為6 * 4KB = 24KB。為了提高存儲效率而采用糾刪碼的方式存儲小文件,反而更加浪費存儲資源。

為了解決Ceph存儲海量小文件的問題,需要設計一個滿足以下目標的系統:

1) 高性能:分布式存儲系統需要承載終端用戶的讀寫需求,低延時地滿足用戶對數據的存取需求,是任何分布式存儲系統的重要目標。

2)擴容時避免大量的數據遷移: 避免大量的數據遷移操作增加對存儲系統的負載,從而影響存儲系統對終端用戶的服務質量,也是該系統設計的重要目標。

3) 加快故障恢復速度: 機器故障或磁盤故障會導致數據遷移,海量小文件導致故障恢復緩慢,故障恢復的時間越長,在此期間其他機器或磁盤發生故障的概率越大,數據丟失的風險越大,因此加快故障的恢復速度也是系統設計的目標之一。

4) 提升存儲效率: 海量的小文件會占用大量的存儲資源,同時大量的文件經過一段時間后就會變成冷數據,如何提升存儲效率降低存儲成本也是系統設計的目標之一。

02系統設計

目前業界解決海量小文件存儲主要有以下的解決幾種優化方式:

1) 硬件優化: 海量小文件的讀寫請求,瓶頸一般在機械硬盤上。硬件優化主要是采用支持隨機讀寫的SSD硬盤代替機械硬盤,可以顯著提高海量小文件的讀寫性能。但是考慮到成本因素,在數據量很大的情況下SSD硬盤一般只會在系統做作為Cache存在。

2) 文件元數據管理優化:分布式存儲系統中文件的元數據包含文件的位置信息,文件的size,創建時間等。在讀寫小文件之前,都需要先得到文件的元數據信息,例如需要得到文件的位置信息才能到對應的存儲節點上讀寫文件數據,只有拿到文件的size才能知道需要讀取數據的長度。為了減小訪問元數據的開銷,應該盡量減少元數據的數量,元數據的數量越少,cache命中率越高,性能越高。

3) 小文件合并成大文件: 通過將大量的小文件合并成一個大文件,可以顯著減少文件的數量,也就減少了元數據的數量,元數據的查詢會更快。對于大文件機械硬盤可以做到順序讀寫,可以顯著降低硬盤的負載。

本系統結合以上的方式設計了一種基于雙層存儲池的小文件合并優化方案解決Ceph海量小文件存儲的問題,其系統設計如下圖3所示:

系統分為兩級存儲池,分別是高性能SSD副本存儲池和大容量(副本/EC)存儲池。可以配置不同的存儲策略,將不同bucket或不同size的文件寫到不同的存儲池上。對于海量小文件優先寫到高性能存儲池中,這樣可以保證小文件讀寫的高性能。

然后通過配置策略,開啟合并功能將高性能存儲池中的小文件合并成大文件存儲到大容量存儲池中。當大容量存儲池中的空閑空間不足時,增加新的存儲節點創建新的大容量存儲池,而不是對已有的存儲池進行擴容,這樣可以避免大量的數據遷移操作對終端用戶的讀寫請求產生影響。

對于大容量存儲池,可以通過EC方式存儲,提升已合并的文件的存儲效率。由于存儲的是大文件,最小分配單元可以調整的比較大,如:128KB,這樣可以減小BlueStore中的元數據的數量,提升性能。

03

對于以上的系統設計,在具體實現上主要包含以下幾個關鍵問題。

3.1 小文件的合并方式

將大文件看做一個Volume,每個小文件占其中的一個部分空間,如下圖4所示:

將小文件順序的追加到Volume中,每個小文件在Volume中分成3個部分:

1) Header: 保存文件的一些元數據信息,如文件名,文件size,文件的校驗信息,在Volume中的offset。

2)Data: 小文件的實際數據內容。

3)Footer: 保存固定的magic,做校驗用。

3.2 數據從高性能存儲池遷移到大容量存儲池

將數據從高性能存儲池遷移到大容量存儲的具體方式,如下圖5所示:

存儲網關的操作日志會記錄當前存儲網關上的操作,操作日志按照bucket和時間存放,遷移工具可以按照不同的bucket策略(如延遲遷移的時間間隔)去讀取當前bucket的操作日志文件。具體的遷移流程可分成4個步驟:

1) 讀取操作日志: 根據bucket的遷移策略,讀取操作日志文件并解析每個操作,得到文件的名稱和一些操作信息。為了支持并行的遷移,可以將文件名通過hash方式放到多個隊列中。

2) 讀取文件內容: 從隊列中的得到待處理的文件名,從高性能存儲池中讀取文件的數據。

3) 小文件數據寫到大容量存儲池: 從大容量存儲池中申請一個Volume,將當前的小文件追加到Volume中,按照Header,Data,Footer的順序遷移文件。

4) 刪除高性能存儲池中的文件數據: 刪除高性能存儲池中的文件數據,只是將數據清空,保留文件的元數據信息,并在元數據中添加當前小文件在Volume中的位置信息,方便后面讀取數據時的檢索。

3.3 文件讀取

在文件的數據被遷移到大容量存儲池后,存儲網關讀取數據的流程也會隨之變化,如下圖6所示:

     此時文件的數據內容存儲在大容量存儲池中,文件的元數據和文件內容的位置信息存放在高性能存儲池中,因此在讀取數據內容之前,存儲網關要先到高性能存儲池中讀取文件的位置信息。從讀取流程上看,相對于直接在大容量存儲池中存儲小文件增加了一次網絡往返的開銷,但是該方案有以下幾個優點:

1) 大量的熱數據已經在高性能存儲池中完成了讀取操作,遷移到大容量存儲中的一般是冷數據,讀取的請求會少很多。

2)  文件元數據的讀取還是在高性能存儲池中進行的,性能相對直接在大容量存儲池中好很多。

3) 該方案大容量存儲池BlueStore的分配單元較大,BlueStore的元數3.4文件的刪除和空間回收

文件的刪除需要刪除文件的數據內容和文件的元數據兩個部分,文件的元數據在高性能存儲池中存放可以直接刪除,而文件的數據內容只是大容量存儲池中Volume的一部分,不能直接刪除回收存儲空間,因此將文件的刪除和空間回收分開進行。

在服務終端用戶的刪除請求時,在Volume中找到對應的文件Header,并寫入一個刪除標記,表示文件已經刪除不能訪問,并修改當前Volume的有效size信息(實際存在的文件的size總和),后續作為開始空間回收的判斷依據。如下圖7所示:

假設紅色的Header表示當前的文件已經被標記為刪除。根據空間回收策略,如有效空間相對Volume存儲空間的占比小于50%,表明已經刪除的空間占比超過50%,此時需要對Volume進行Compaction操作,方法如下:

1) 掃描整個Volume里面的每個文件,如果已經刪除直接跳過這個文件。

2) 如果是沒有被刪除的文件,將文件的內容追加到新的Volume中,并修改高性能存儲池中文件的元數據,修改位置信息重新指向新Volume中的位置。

3) 整個Volume掃描完成,有效文件遷移完畢后,刪除當前的Volume大文件。

除了文件刪除操作,文件修改操作也需要回收老的數據內容占用的空間,采用類似的方法。在處理修改的操作日志時,將舊數據內容的Header標記為刪除,在后續Compaction操作時回收這部分數據空間。

04評價

為了驗證此設計方案的優化效果,在相同的網絡環境上搭建了兩套分布式存儲系統:

優化前系統:

1) 3臺服務器,每臺部署5個機械硬盤存儲節點,最小分配單元4KB。

2) 在15個存儲節點上創建一個大容量3副本存儲池。

優化后系統:

1) 3臺服務器,每臺部署5個機械硬盤存儲節點和一個SATA SSD存儲節點,最小分配單元64KB。

2) 在15個存儲節點上創建一個大容量3副本存儲池,在3個SATA SSD存儲節點上創建一個高性能3副本存儲池。

3) 設置高性能存儲池中的小文件在寫入2小時后,自動遷移到大容量存儲池中,大容量存儲池中的volume size默認為4MB。

可以從以下幾個方面評價該設計方案的優化效果:

4.1熱數據的讀寫性能

在海量小文件數據還沒有遷移到大容量存儲池之前的性能比較。

(1) 寫入性能:

如下圖8所示,分別在多種不同并發情況下寫入1000萬20KB文件的性能測試結果:

     由于高性能存儲池采用的存儲硬件是SATA SSD,雖然高性能存儲池只有3個存儲節點,大容量存儲池有15個存儲節點,優化后系統的寫入QPS依然達到優化前的3倍。

(2) 讀取性能:

如下圖9所示,分別在多種不同并發情況下讀取1000萬 20KB文件的性能測試結果:

可以看到優化后系統的讀取QPS相對優化前提高20%～30%,沒有達到寫入的優化效果主要是存儲節點緩存的作用。

4.2冷數據的讀取性能

數據在高性能存儲池中寫入后,按照策略數據變冷會遷移到大容量存儲池中,優化前和優化后(小文件合并之后)的讀取性能對比結果如下圖10所示:

     由于小文件合并之后,文件的讀取需要先到高性能存儲池中讀取元數據,然后到大容量存儲池中讀取文件的數據,實際上多經過了一次網絡RTT,因此會導致一定的讀取性能下降,從結果看讀取QPS下降了約12%。后續系統會采用性能更好的NVME SSD搭建高性能存儲池進行測試。

4.3存儲效率提升

在優化后的系統中,在小文件合并前與合并后,存儲資源的使用情況如下圖11所示:

合并前最小存儲單元是64KB,因此一個20KB的文件也需要占用64KB的存儲空間,而且是3副本,因此不算元數據需要的存儲空間是:64KB * 3 * 10000000 = 1831GB。

合并之后的Volume size是4MB,1個20KB的文件,只需要占據20KB的數據存儲空間加上少量元數據的存儲空間,因此不算元數據需要的存儲空間是:20KB * 3 * 10000000 = 572GB。

因此合并之后的存儲效率是合并之前存儲效率的3倍多。

4.4故障恢復速度

同樣的1000萬文件,下線1個存儲節點,此時會導致數據遷移恢復數據,完全采用默認的配置,優化前和優化后耗費的數據恢復時間如下圖12所示:

由于優化后大容量存儲池中只存放大文件,因此其恢復速度比較快,從結果看優化后的故障恢復速度是優化前的16倍。

05結論

本文分析了使用Ceph存儲海量小文件的挑戰和一些問題,并從硬件優化,元數據管理優化和小文件合并優化幾個層面考慮并設計實現了一套基于雙層存儲池的小文件合并優化分案,通過比較可以發現新方案在讀寫性能,存儲效率以及故障恢復速度上都有較大的提升。