Ceph讀寫性能估算方法

08-24

Ceph讀寫性能估算方法

2 人贊了文章

前言

最近在做Ceph性能測試相關工作，在測試初期由於沒有得到理想的測試結果，因此對Ceph集群進行了優化，但是一直有個問題縈繞在我的腦海：基於當前硬體配置，這個Ceph集群的極限是多少？

由於這個問題和Ceph的配置息息相關，為了簡化問題，在本文中我們只會會討論3個變數：冗餘策略（糾刪碼、多副本），讀/寫，ObjectStore。我們將會基於磁碟、網路、CPU性能來估算出一個集群的性能，除此以外的參數影響均歸併到損耗係數μ這個變數。本文會分別解釋寫性能公式推演、讀性能公式推演，並且在每個推演中加入冗餘策略和ObjectStore的討論。

ObjectStore簡介

Ceph目前提供了三種存儲後端:

FileStore
KStore
BlueStore

而KStore由於接納程度不高，目前很少有廠商使用，因此在本文中只介紹和對比FileStore和BlueStore。

FileStore

在FileStore中，每個Ceph對象都被保存在本地文件系統中(XFS, ZFS等)。Ceph為了保證一致性，要求讀寫操作都是atomic的，因此會需要在Ceph內部做一次Journal，也就是說，每次客戶端數據寫入時，首先會採用Append-only的模式將數據寫入到Journal中去，隨後再執行真正的數據寫入操作。然而在本地文件系統又會做一次Journal，因此就會產生Journaling of journal問題，也就是記錄了2次Journal。為了提高寫入性能，一般在部署Ceph集群時，會將單獨劃分SSD給Ceph journal。

BlueStore

為了提高Ceph的寫入性能，社區開發了BlueStore這一存儲後端，讓數據繞開了本地文件系統直接裸盤，從而解決了Journaling of journal問題。BlueStore採用RocksDB來管理對象元數據，因此為了跑RocksDB，BlueStore內部有一個微型用戶態的文件系統-BlueFS。得益於RocksDB，Ceph可以很方便的獲取和枚舉所有的對象。

讀性能公式推演

讀性能公式目前推測較為簡單，無論在FileStore還是BlueStore下，均推斷為 Wnμ

W: 單塊裸盤讀帶寬

n: OSD數量

μ：損耗係數一般為0.7~0.8

下面注重來介紹一下寫性能公式推演：我們會逐一探討：

FileStore + 多副本寫性能公式推演
BlueStore + 多副本寫性能公式推演
FileStore + 糾刪碼寫性能公式推演
BlueStore + 糾刪碼寫性能公式推演

寫性能公式推演

FileStore + 多副本

在當前情況下，我們假設Ceph集群的ObjectStore是FileStore, 並且對應的Pool的冗餘策略為多副本，SSD作為一個OSD，其journal和data都放在這塊SSD上。因此我們一次寫入的流程可以簡化成下圖：數據先寫到Ceph的journal上，然後再寫入data中，並且在本地文件系統會再做一次journal，由於journaling of journal問題，單個OSD的WAF(寫放大係數)為2。在當前冗餘策略下，一個文件寫入需要產生多個副本N，因此集群放大係數為2*N。

然而在寫入對象時，我們寫入的不單單是數據本身，在Ceph RBD的journal中，RBD寫操作是變成transaction操作，transaction會包含一些元數據用於描述transaction，這些元數據也寫到journal上，這就也會導致寫放大。因此一次寫入的WAF不僅僅需要考慮多副本、journaling of journal問題，還需要考慮transaction元數據。

韓國成均館大學曾經對Ceph存儲後端對寫入放大係數的影響做過一定的研究，在其發表的《Understanding Write Behaviors of Storage Backends in Ceph Object Store》論文中，測試了在3副本+FileStore情況下，用Ceph RBD寫入不同數據塊與WAF的關係。從Figure 5我們可以看到，當數據寫入量較大時，WAF逐漸收斂於6，符合我們上文WAF=2*N的推理；但是當寫入對象很小時，WAF則會很大。

這是因為當數據量很小時，同時完成的transaction元數據量所佔比重會很大，根據上圖數據，我推測每次寫入所產生的transaction元數據大概在5KiB左右，因此可以推斷，在包含transaction元數據的情況下，WAF為：

$WAF=[(X+5)*2*N]/X$

X為寫入數據塊大小(KiB)
N為副本數

隨著數據塊增大，在FileStore、多副本冗餘策略下WAF最終將向2N收斂。假設我們知道了一塊SSD的寫性能可以達到W MB/s的帶寬，那麼在理想情況下，我們可以很容易推斷出，一個大小為n的SSD集群的寫帶寬能達到 $W*n$ MB/s。

如果考慮外部因素多帶來的損耗為μ，我們最終可以推斷出BlueStore+多副本情況下，寫性能可以達到：

$BW=[(W*n)/WAF]*μ\ WAF=[(X+5)*2*N]/X$

WAF為寫放大係數
X為寫入數據塊大小(KiB)
N為副本數
n為OSD數量
μ為損耗係數一般為0.7~0.8

BlueStore + 多副本

在當前情況下，我們假設Ceph集群的ObjectStore是BlueStore, 並且對應的Pool的冗餘策略為多副本，SSD作為一個OSD，劃分為2塊分區，一個分區作為裸盤來寫入數據，另一塊做BlueFS用來跑RocksDB。因此我們一次寫入的流程可以簡化成下圖：數據會被直接寫入到data分區(裸盤）中，而對象元數據會被寫到RocksDB和RocksDB的WAL中，隨後RocksDB將數據壓縮後存放到磁碟中。我們不再需要在文件系統層做journal，而WAL只在覆寫操作時才會用到，因此在副本數量為N的條件下，我們可以推測WAF將收斂於N。

值得注意的一點，在BlueStore中，磁碟分區會以『bluestore_min_alloc_size』的大小分配管理，這個數值默認為64KiB。也就是說，如果我們寫入<64KiB的數據，剩餘的空間會被0填充，也即是Zero-filled data，然後寫入磁碟，也正是這樣，BlueStore的小文件隨機寫性能並不好。

這裡同樣引用《Understanding Write Behaviors of Storage Backends in Ceph Object Store》論文中針對BlueStore在三副本策略下，不同數據塊寫入時WAF的變化圖：

可以看到，當寫入數據塊很小時，WAF的數值很大。灰色曲線正是做了前文所說的『小文件隨機寫』，因此性能較差；覆寫操作時，由於Ceph為了保證一致性，會將數據先寫入到RocksDB WAL中去，然後再由RocksDB WAL將數據落到磁碟上去，因此覆蓋性能也會稍差一些。隨著數據塊的增大，所有曲線最終收斂於3，符合我們前文中推斷的 $WAF=N$ 。

綜上所述，在多副本策略下，BlueStore的WAF的推演公式需要考慮：數據塊大小，RocksDB壓縮數據大小, Zero-filled數據大小以及副本數量。當隨機寫入小數據塊的時候，會產生較多的Zero-filled數據，同時RocksDB壓縮數據大小所佔比重也會較大；當順序寫入大數據時，Zero-filled數據則基本為0，並且RocksDB壓縮數據所佔比重也可以忽略不計，因此公式整理如下：

$WAF=[(X+20)*N]/X X<16KiB(HDD) | 64KiB(SSD)\ WAF=[(X+5)*N]/X X>=16KiB(HDD) | 64KiB(SSD)$

這裡的推算主觀性較強，當寫入數據量小的時候( $X<16KiB(HDD) | 64KiB(SSD)$ )，估算ceph會產生的zero-filled數據15kib和rocksdb壓縮後存入磁碟的數據量5kib，共計20kib；而當寫入數據量大時( $X>=16KiB(HDD) | 64KiB(SSD)$ )，Zero-filled數據幾乎為0，剩餘RocksDB壓縮後存入磁碟的數據量的5KiB。

如果考慮外部因素多帶來的損耗為μ，我們最終可以推斷出BlueStore+多副本情況下，寫性能可以達到：

$BW=[(W*n)/WAF]*μ\ WAF=[(X+20)*N]/X X<16KiB(HDD) | 64KiB(SSD)\ WAF=[(X+5)*N]/X X>=16KiB(HDD) | 64KiB(SSD)$

WAF為寫放大係數
X為寫入數據塊大小(KiB)
N為副本數
n為OSD數量
μ為損耗係數一般為0.7~0.8

FileStore + 糾刪碼

相比較多副本冗餘策略，糾刪碼的出現大大節省了磁碟空間，以下圖舉例，如果我們有5個OSD，並且按照K=3, M=2配置糾刪碼冗餘策略，當有一組數據寫入時(ABCDEFGHI)，該數據會被分成3份分別寫入3個OSD中，同時Ceph也會生成2個編碼塊寫入到另外2個OSD中，寫就是說，一次寫入操作，實際上會產生(K+M)/K倍的實際寫入量。而由於這裡使用的存儲後端是FileStore，journaling of journal問題會讓寫放大兩倍，因此結合糾刪碼本身特性，WAF最終會收斂於：

$(K+M)/K*2$