越來越多的組織被要求管理數十億個文件和幾百上千PB的數據。無論是在公共云還是本地環境中，Ceph對象存儲都是值得考慮的一個選項。本篇文章將通過七部分的精選內容為下面這些問題提供答案。

• 每個RGW實例的最佳CPU /線程分配比率是多少?
• 建議的Rados網關(RGW)部署策略是什么?
• 固定大小的群集的最大性能是什么?
• 當集群接近10億個對象時，集群性能和穩定性會受到哪些影響?
• 存儲桶分片如何提高存儲桶的可伸縮性，以及對性能有何影響?
• RGW的新Beast前端與Civetweb相比如何?
• RHCS 2.0 FileStore和RHCS 3.3 BlueStore之間的性能差異是多少?
• EC Fast_Read與常規讀取的性能影響?

1、構建健壯的對象存儲基礎架構

本部分主要介紹如何結合使用Red Hat Ceph Storage，Dell EMC存儲服務器和網絡來構建健壯的對象存儲基礎架構。

環境搭建

本環境是Dell EMC實驗室中使用其硬件以及英特爾提供的硬件進行的

硬件配置

 

表1：硬件配置

 

表2：軟件配置

 

表3：資源限制

機架設計

 

 

圖1：實驗室機架設計

 

 

圖2：測試實驗室邏輯設計

有效負載選擇

對象存儲的有效負載差異很大，有效負載大小是設計基準測試用例時的關鍵考慮因素。在理想的基準測試用例中，有效負載大小應代表實際的應用程序工作負載。與通常只讀取或寫入幾千字節的塊存儲工作負載測試不同，其中對象存儲工作負載進行測試需要涵蓋各種有效負載大小。以下是本次實驗對象有效負載的大小。

 

 

表4：經過測試的有效負載

數據處理應用程序傾向于在較大的文件上運行，根據我們的測試，我們發現32MB是COSBench在我們的測試范圍內可以可靠處理的最大對象大小。

執行摘要

紅帽Ceph Storage能夠在多種行業標準的硬件配置上運行。對于那些不熟悉系統硬件和Ceph軟件組件的人來說，這種靈活性可能會令人生畏。設計和優化Ceph集群需要仔細分析應用程序，它們所需的容量和工作負載配置文件。紅帽Ceph存儲集群通常在多租戶環境中使用，承受著各種各樣的工作負載。紅帽，戴爾EMC和英特爾精心挑選了我們認為會對性能產生深遠影響的系統組件。測試評估了三大類的工作負載：

• 大對象工作負載(吞吐量)

紅帽測試顯示，通過添加Rados Gateway(RGW)實例，可以實現讀寫吞吐量的近乎線性的可擴展性，直到由于OSD節點磁盤爭用而達到峰值為止。因此，我們為讀寫工作負載測量了超過6GB/s的聚合帶寬。

• 小對象工作負載(每秒操作數)

與大對象工作負載相比，元數據I/O對小對象工作負載的影響更大?？蛻舳藢懖僮靼创尉€性擴展，最高為6.3K OPS，平均響應時間為8.8 ms，直到被OSD節點磁盤爭用飽和為止。客戶端讀取操作達到3.9K OPS，這可能是由于BlueStore OSD后端缺少Linux頁面緩存所致。

• 對象數量更多的工作負載(十億個對象或更多)

隨著存儲桶中對象總數的增長，需要管理的索引元數據的數量也相應增加。索引元數據分布在許多分片上，以確?？梢杂行У卦L問它。當存儲桶中的對象數量大于使用當前分片數量可以有效管理的數量時，Red Hat Ceph Storage將動態增加分片數量。在我們的測試過程中，我們發現動態分片事件對目的地為動態分片的存儲桶的請求的吞吐量具有短暫有害的影響。如果開發人員具有將存儲桶增長到給定數量的經驗知識，則可以創建該存儲桶或將其手動更新為能夠有效容納元數據量的多個分片。

在大型和小型對象大小的工作負載測試中，相對于以前的性能和規模分析，Red Hat Ceph Storage都顯著提高了性能。我們認為，這些改進可以歸因于BlueStore OSD后端，RGW的新Beast Web前端，BlueStore WAL和block.db使用Intel Optane SSD以及Intel Cascade Lake提供的最新一代處理能力的結合處理器。

體系結構

 

表5：體系結構摘要

Ceph基準性能測試

為了記錄本機Ceph集群的性能，我們使用了Ceph基準測試工具(CBT)，一種用于自動化Ceph群集基準測試的開源工具。目的是找到集群總吞吐量的高水位線。該水位線是吞吐量保持不變或降低的點。

使用Ceph-Ansible playbook部署了Ceph集群。Ceph-Ansible使用默認設置創建一個Ceph集群。因此，基線測試是使用默認的Ceph配置完成的，沒有進行任何特殊調整。使用CBT，每個基準場景運行了7次迭代。第一次迭代從單個客戶端執行基準測試，第二次從兩個客戶端執行基準測試，第三次從三個客戶端并行執行，以此類推等等。

使用了以下CBT配置：

• 工作量：順序寫測試，然后順序讀測試
• 塊大?。?MB
• 片長：300秒
• 每個客戶端的并發線程數：128
• 每個客戶端的RADOS基準實例：1
• 池數據保護：Ec 4 + 2刪除或3x復制
• 客戶總數：7

如表1和表2所示，隨著客戶端數量的增加，寫入和讀取工作負載的性能都呈線性下降。有趣的是，使用擦除編碼數據保護方案的配置為讀寫吞吐量提供了幾乎對稱的8.4GBps。在以前的研究中沒有觀察到這種對稱性，我們認為這可以歸因于BlueStore和Intel Optane SSD的組合。在任何RADOS基準測試中，我們都無法確定任何系統級資源飽和。如果有其他客戶端節點可用來進一步給現有群集施加壓力，我們可能會觀察到更高的性能，并有可能使基礎存儲介質飽和。 

 

圖1：Radosbench 100%寫入測試

 

圖2：Radosbench 100%讀取測試

總結

在本文中，我們詳細介紹了實驗室體系結構，包括硬件和軟件配置，分享了來自基礎集群基準測試的一些結果，并提供了高級執行和體系結構的相關摘要。

2、Ceph RGW 部署策略和大小調整

從Red Hat Ceph Storage 3.0開始，Red Hat添加了對容器化存儲守護程序(CSD)的支持，該支持使軟件定義的存儲組件(Ceph MON，OSD，MGR，RGW等)可以在容器中運行。CSD避免了具有專用于存儲服務的節點的需求，因此通過并置存儲容器化守護進程減少了CAPEX和OPEX。

Ceph-Ansible提供了將資源防護放入每個存儲容器的必需機制，這對于在一個物理節點上運行多個存儲守護程序容器很有用。在這部分內容中，我們將介紹部署RGW容器的策略及其資源調整指南。在探討性能之前，讓我們了解部署RGW的不同方法是什么。

并置的RGW

• 不需要用于RGW的專用節點(可以減少CAPEX和OPEX)。
• Ceph RGW容器的單個實例放置在與其他存儲容器共存的存儲節點上。
• 從Ceph Storage 3.0開始，這是部署RGW的首選方法。

 

 

圖1：共同駐留的RGW部署策略

多主機RGW

• 不需要用于RGW的專用節點(可以幫助減少CAPEX和OPEX)。
• 與其他存儲容器共存的多個Ceph RGW實例(每個存儲節點當前測試2個實例)。
• 我們的測試表明，該選項可提供最高的性能，而不會產生額外的開銷。

 

 

圖2：多個共存(2個RGW實例)部署策略

獨立RGW

• 需要用于RGW的專用節點。
• Ceph RGW組件被部署在專用的物理/虛擬節點上。
• 從Ceph Storage 3.0開始，這不再是部署RGW的首選方法。

 

 

圖3：獨立的RGW部署策略

表現摘要

(一)RGW部署和規模調整指南

在上一節中，我們研究了部署Ceph RGW的不同方法。我們將比較每種方法之間的性能差異。為了評估性能，我們通過調節RGW部署策略以及跨不同的讀寫和工作負載的RGW CPU內核數執行了多個測試。結果如下。

100%寫入工作量

如圖1和圖2所示

• 并置(1x)RGW實例在小型和大型對象方面均優于獨立RGW部署。
• 同樣，多個共存(2x)RGW實例的性能優于共存(1x)RGW實例的部署。這樣，多個共存(2x)RGW實例分別為小型和大型對象提供了 2328 Ops和1879 MBps的性能。
• 在多個測試中，發現 4 CPU Core / RGW實例是CPU資源與RGW實例之間的最佳比率。向RGW實例分配更多的CPU內核并不能提供更高的性能

 

圖表1：小對象100%寫測試 

圖表2：大對象100%寫測試

100%讀取工作負載性能

有趣的是，對于讀取工作負載，每個RGW實例增加的CPU核心數量并不能提高不同大小對象的性能。因此，每個RGW實例1個CPU內核的結果與每個RGW實例10個CPU內核的結果幾乎相似。

實際上，根據我們之前的測試，我們觀察到類似的結果，即讀取工作負載不會消耗大量CPU，這可能是因為Ceph使用了系統擦除編碼，并且在讀取過程中不需要解碼塊。因此，我們發現如果RGW工作負載是讀取密集型的，則過度分配CPU并沒有幫助。

比較獨立RGW與共置(1x)RGW測試的結果非常相似。但是，僅添加一個并置的RGW(2x)，在小對象的情況下，性能提高了約200%，在大對象的情況下，性能提高了約90%。

這樣，如果工作負載是讀取密集型的，則運行多個并置(2x)RGW實例可以顯著提高整體讀取性能。

 

 

圖表3：小對象100%讀取測試

 

 

圖4：大對象100%讀取測試

(二)RGW線程池大小調整準則

在決定將CPU內核分配給RGW實例時，非常相關的RGW調整參數之一rgw_thread_pool_size是負責由Beast生成的與HTTP請求相對應的線程數。這有效地限制了Beast前端可以服務的并發連接數。

為了確定此可調參數最合適的值，我們通過更改rgw_thread_pool_sizeRGW實例的CPU核心計數和CPU計數一起進行了測試。如圖5和6所示，我們發現設置rgw_thread_pool_size為512可以在4個CPU內核預RGW實例上實現最高性能。同時增加CPU核心數rgw_thread_pool_size并沒有任何改善。

我們確實承認，如果我們進行多輪rgw_thread_pool_size低于512 的測試，則本測試會更好。我們的假設是，由于Beast Web服務器基于異步c10k Web服務器，因此不需要每連接一個線程，因此應該在較低的線程上表現良好。不幸的是，我們無法測試，但將來會嘗試解決這個問題。

因此，這樣的多并置(2x)RGW實例(每個RGW實例具有4個CPU內核)和設置rgw_thread_pool_size為512個可以提供最大的性能。 

圖5：小對象100%寫入測試 

圖6：大對象100%寫入測試

總結

在這篇文章中，我們了解到，多并置(2x)RGW實例，每個RGW實例具有4個CPU核心，每個實例rgw_thread_pool_size有512個，可在不增加整體硬件成本的情況下提供最佳性能。

3、從ceph集群中獲得最大性能

我們已經測試了各種配置，對象大小和客戶端數量，以便針對小型和大型對象工作負載最大化七個節點的Ceph集群的吞吐量。如第一篇文章中所述，Ceph集群是使用每個HDD配置的單個OSD(對象存儲設備)構建的，每個Ceph集群總共有112個OSD。在本文中，我們將了解不同對象大小和工作負載的頂級性能。

注意：在本文中，術語“讀取”和HTTP GET可以互換使用，術語HTTP PUT和“寫入”也可以互換使用。

大對象工作量

大對象順序輸入/輸出(I / O)工作負載是Ceph對象存儲最常見的用例之一。這些高吞吐量的工作負載包括大數據分析、備份和檔案系統、圖像存儲以及流音頻和視頻。對于這些類型的工作負載，吞吐量(MB / s或GB / s)是定義存儲性能的關鍵指標。

如圖1所示，當增加RGW主機的數量時，大對象100%HTTP GET和HTTP PUT工作負載表現出亞線性可伸縮性。因此，我們為HTTP GET和HTTP PUT工作負載測量了約5.5 GBps的聚合帶寬，有趣的是，我們沒有注意到Ceph集群節點中的資源飽和。

如果我們可以將更多負載分配給該群集，則它可以產生更多的負載。因此，我們確定了兩種方法。1)添加更多的客戶端節點 2)添加更多的RGW節點。我們不能選擇選項1，因為我們受此實驗中可用的物理客戶端節點的限制。因此，我們選擇了選項2，并進行了另一輪測試，但這次有14個RGW。

如圖2所示，與7個 RGW測試相比，14 RGW測試的寫入性能提高了 14%，最高達到了6.3GBps，類似地，HTTP GET工作負載顯示的讀取性能提高了16%，最高達到6.5GBps。這是在此群集上觀察到的最大聚合吞吐量，此后如圖1所示，注意到了設備(HDD)飽和。根據結果，我們相信，如果我們向該集群添加了更多的Ceph OSD節點，則性能可能會進一步擴展，直到受到資源飽和的限制。 

圖1：大對象測試

圖2：具有14個RGW的大型對象測試

圖1：Ceph OSD(HDD)媒體利用率

小對象工作量

如圖3所示，當增加RGW主機的數量時，小型對象100%HTTP GET和HTTP PUT工作負載表現出次線性可伸縮性。因此，我們測量了9ms應用程序寫入延遲時HTTP PUT的6.2K Ops吞吐量，以及具有7個RGW實例的HTTP GET工作負載的3.2K Ops吞吐量。

直到7個RGW實例，我們才注意到資源飽和，因此我們將RGW實例擴展到14個，從而使RGW實例增加了一倍，并觀察到HTTP PUT工作負載的性能下降，這歸因于設備飽和，而HTTP GET性能則向上擴展并達到4.5萬個，如果我們添加更多的Ceph OSD節點，寫性能可能會更高。就讀取性能而言，我們認為添加更多的客戶端節點應該可以改善讀取性能，但是我們在實驗室中沒有更多的物理節點可以驗證這一假設。

從圖3中可以看到的另一個有趣的觀察結果是HTTP PUT工作負載的平均響應時間減少了9ms，而HTTP GET顯示了從應用程序生成工作負載測得的平均延遲為17ms。我們認為，導致寫入工作負載出現個位數的應用程序延遲的原因之一是BlueStore OSD后端的性能提高以及用于支持BlueStore元數據設備的高性能Intel Optane NVMe的結合。值得注意的是，從對象存儲系統中實現一位數的寫入平均延遲并非易事。如圖3所示，將Ceph對象存儲與BlueStore OSD后端和Intel Optane用于元數據一起部署時，可以在較低的響應時間實現寫入吞吐量。

 

圖3：小對象測試

總結

此測試中使用的固定大小群集分別為寫入和讀取工作負載提供了約6.3GBps和約6.5GBps的大對象帶寬。相同的小對象集群分別為讀寫工作量提供了約6.5K Ops和約4.5K Ops。

結果還表明，BlueStore OSD與Intel Optane NVMe的結合使用實現了平均應用程序延遲個位數的好成績，這對于對象存儲系統而言是非常重要的。

4、RGW存儲桶分片策略及其性能影響

在有關Ceph性能的系列文章的第4部分中，我們介紹了RGW存儲桶分片策略及其性能影響。

Ceph RGW為每個存儲桶維護一個索引，該索引保存存儲桶包含的所有對象的元數據。RGW需要索引才能在請求時提供此元數據。例如，列出存儲桶內容會拉出存儲的元數據，維護用于對象版本控制、存儲桶配額、多區域同步元數據等的日志。因此，概括地說，存儲桶索引存儲了一些有用的信息。存儲區索引不會影響對對象的讀取操作，但是會在寫入和修改RGW對象時添加額外的操作。

大規模編寫和修改存儲桶索引具有某些含義。首先，可以存儲在單個存儲桶索引對象上的數據量有限，這是因為用于存儲桶索引對象的基礎RADOS對象鍵值接口不是無限的，并且默認情況下每個存儲桶僅使用一個RADOS對象。其次，大索引對象可能會導致性能瓶頸，因為對已填充存儲桶的所有寫操作最終都會修改支持該存儲桶索引的單個RADOS對象。

為了解決與非常大的存儲桶索引對象相關的問題，RHCS 2.0中引入了存儲桶索引分片功能。這樣，每個存儲桶索引現在都可以分布在多個RADOS對象上，通過允許存儲桶可以容納的對象數量與索引對象(碎片)的數量成比例，可以擴展存儲桶索引元數據。

但是，此功能僅限于新創建的存儲桶，并且需要對未來的存儲桶對象進行預先規劃。為了緩解此存儲桶重新分片可以使用管理員命令，該命令可幫助修改現有存儲桶的存儲桶索引分片數量。但是，使用這種手動方法，通常會在群集中執行存儲區重新分片看到性能下降的癥狀。同樣，手動重新分片要求在重新分片過程中停止對存儲區的寫操作。

動態存儲分區重新分片的意義

RHCS 3.0引入了動態存儲區重新分片功能。利用此功能，存儲桶索引現在將隨著存儲桶中對象數的增加而自動重新分片。重新分片發生時，您無需停止在存儲桶中讀取或寫入對象。動態重新分片是RGW的本機功能，如果該存儲桶中的對象數量超過100K，則RGW會自動識別需要重新分片的存儲桶，RGW通過產生一個負責處理已調度的特殊線程來為該存儲桶調度重新分片操作。動態重新分片現在是默認功能，管理員無需采取任何措施即可激活它。

在本文中，我們將深入探討與動態重新分片功能相關的性能，并了解如何使用預分片的存儲區將其中的某些內容最小化。

測試方法

為了研究在單個存儲桶中存儲大量對象以及動態存儲桶重新分片所帶來的性能影響，我們特意為每種測試類型使用單個存儲桶。同樣，使用默認的RHCS 3.3調整創建了存儲桶。測試包括兩種類型：

1. 動態存儲桶重新分片測試，單個存儲桶最多可存儲3000萬個對象
2. 預先進行存儲桶測試，其中存儲了大約2億個對象

對于每種類型的測試，COSBench測試分為50個回合，其中每個回合寫入1小時，然后分別進行15分鐘的讀取和RWLD(70Read，20Write，5List，5Delete)操作。因此，在整個測試周期中，我們在兩個存儲桶中寫入了約2.45億個對象。

動態存儲桶重新分片：性能洞察

如上所述，動態存儲區重新分片是RHCS中的默認功能，當存儲區中存儲的對象數量超過某個閾值時，該功能會啟動。圖1顯示了性能變化，同時不斷向桶中填充物體。第一輪測試交付了約5.4K Ops，同時在被測試的存儲桶中存儲了約80萬個對象。

隨著測試輪的進行，我們不斷在桶中裝滿物品。第44輪測試交付了約3.9K Ops，而存儲桶中的對象數量達到了約3000萬。隨著對象計數的增加，存儲區分片計數也從第1輪的16(默認)增加到第44輪的512。如圖1所示，吞吐量Ops的突然下降很可能歸因于存儲桶上的RGW動態重新分片活動。

圖1：RGW動態存儲桶重新分片

預共享存儲桶：性能洞察

帶有一個過度填充的bucket的非確定性性能(圖1)引導我們進入下一個測試類型，在將任何對象存儲在bucket中之前，我們預先對其進行了分片。這一次，我們在這個預切分的bucket中存儲了超過1.9億個對象，我們測量了性能，如圖2所示。因此，我們觀察到預切分的桶性能穩定，但是，在測試的第14和28小時，性能突然下降了兩次，這是由于RGW動態桶切分。

圖2：預共享桶

圖3顯示了預分片存儲桶和動態分片存儲桶的性能對比。根據測試后存儲區統計數據，我們認為這兩個類別的性能突然下降是由動態重新分片事件引起的。

因此，預分片存儲有助于實現確定性性能，因此從架構的角度來看，以下是一些指導：

如果知道應用程序的對象存儲消耗模式，特別是每個存儲桶的預期對象數(數量)，在這種情況下，對存儲桶進行預分片通常會有所幫助。

如果每個存儲桶中要存儲的對象數未知，則動態存儲桶重新分片功能將自動完成該工作。但是，在重新分片時會消耗少量的性能。

我們的測試方法夸大了這些事件在集群級別的影響。在測試期間，每個客戶端都向不同的存儲區寫入數據，并且每個客戶端都傾向于以相似的速率寫入對象。其結果是，客戶端正在寫入的存儲桶以相似的時序超過了動態分片閾值。在現實環境中，動態分片事件更有可能在時間上得到更好的分布。

圖表3：動態存儲桶重新分片和預分片存儲桶性能比較：100%寫入

發現動態重新分片的存儲桶的讀取性能比預共享的存儲桶略高，但是預分片的存儲桶具有確定的性能，如圖4所示。

圖表4：動態存儲桶重新分片和預分片存儲桶性能比較：100%讀取

總結

如果我們知道應用程序將在一個存儲桶中存儲多少個對象，則對存儲桶進行預分片通常有助于提高整體性能。另一方面，如果事先不知道對象數，則Ceph RGW的動態存儲桶重新分片功能確實有助于避免與過載存儲桶相關的性能下降。

5、Ceph Bluestore的壓縮機制及性能影響

通過BlueStore OSD后端，Red Hat Ceph Storage獲得了一項稱為“實時數據壓縮”的新功能，該功能有助于節省磁盤空間?？梢栽贐lueStore OSD上創建的每個Ceph池上啟用或禁用壓縮。除此之外，無論池中是否包含數據，均可使用Ceph CLI隨時更改壓縮算法和模式。在此博客中，我們將深入研究BlueStore的壓縮機制，并了解其對性能的影響。

BlueStore中的數據是否被壓縮取決于壓縮模式和與寫操作相關的任何提示的組合。BlueStore提供的不同壓縮模式是：

• none：從不壓縮數據。
• passive：除非寫操作具有可壓縮的提示集，否則不要壓縮數據。
• aggressive：壓縮數據，除非寫操作具有不可壓縮的提示集。
• force：無論如何都嘗試壓縮數據。即使客戶端暗示數據不可壓縮，在所有情況下都使用壓縮。

可以通過每個池屬性或全局配置選項來設置compression_mode，compression_algorithm，compression_required_ratio，compression_min-blob_size和compresion_max_blob_size參數?？梢酝ㄟ^以下方式設置“pool”屬性：

ceph osd pool set <pool-name> compression_algorithm <algorithm> 
ceph osd pool set <pool-name> compression_mode <mode> 
ceph osd pool set <pool-name> compression_required_ratio <ratio> 
ceph osd poll set <pool-name> compression_min_blob_size <size> 
ceph osd pool set <pool-name> compression_max_blob_size <size> 

Bluestore壓縮內部構件

Bluestore不會壓縮任何等于或小于min_alloc_size配置的寫入。在具有默認值的部署中，SSD的min_alloc_size為16KiB，而HDD為64 KiB。在我們的案例中，我們使用的是全閃存(SSD)介質，IO大小小于32KiB的Ceph不會進行任何壓縮嘗試。

為了能夠在較小的塊大小下測試壓縮性能，我們以4KiB的min_alloc_size重新部署了Ceph集群，通過對Ceph配置的修改，我們能夠以8KiB塊大小實現壓縮。

請注意，從Ceph集群中的默認配置修改min_alloc_size會對性能產生影響。在我們將大小從16 KiB減小到4KiB的情況下，我們正在修改8KiB和16KiB塊大小IO的數據路徑，它們將不再是延遲寫入并首先進入WAL設備，任何大于4KiB的塊將直接寫入OSD配置的塊設備中。

Bluestore Compression配置和測試方法

為了了解BlueStore壓縮的性能方面，我們進行了如下測試：

1.在Red Hat Openstack Platform 10上運行40個實例，每個實例附加一個Cinder卷(40xRBD卷)。然后，我們使用隨附的Cinder卷創建并安裝了XFS文件系統。

2.使用FIO libRBD IOengine進行84xRBD卷。

Pbench-Fio用作首選的基準測試工具，具有3個新的FIO參數(如下所示)，以確保FIO在測試期間將生成可壓縮的數據集。

refill_buffers 
buffer_compress_percentage=80 
buffer_pattern=0xdeadface 

我們使用aggressive的壓縮模式運行測試，以便我們壓縮所有對象，除非客戶端提示它們不可壓縮。測試期間使用了以下Ceph bluestore壓縮全局選項

bluestore_compression_algorithm：snappy 
bluestore_compression_mode：aggressive 
bluestore_compression_required_ratio：.875 

bluestore_compression_required_ratio是此處的關鍵可調參數，其計算公式為

bluestore_compression_required_ratio = size_compressed/siz_original 

默認值為0.875，這意味著如果壓縮未將大小減小至少12.5%，則將不壓縮對象。由于凈增益低，高于此比率的對象將不會壓縮存儲。

要知道我們在FIO綜合數據集測試期間實現的壓縮量，我們使用了四個Ceph性能指標：

• Bluestore_compressed_original。被壓縮的原始字節的總和。
• Bluestore_compressed_allocated。分配給壓縮數據的字節總數。
• Compress_success_count。有益壓縮操作的總和。
• Compress_rejected_count。壓縮操作的總和因空間凈增益低而被拒絕。

要查詢上述性能指標的當前值，我們可以對正在運行的一個osd使用Ceph perf dump命令：

ceph daemon osd.X perf dumo | grep -E'（compress _.* _ count | bluestore_compressed_）' 

在壓縮基準測試期間從客戶端測量的關鍵指標：

• IOPS。每秒完成的IO操作總數
• Average lantency。客戶端完成IO操作所需的平均時間。
• P95%。延遲的95%。
• P99%。延遲的99%。

測試實驗室配置

該測試實驗室由5個RHCS全閃存(NVMe)服務器和7個客戶端節點組成，詳細的硬件和軟件配置分別如表1和2所示。請參閱此博客文章，以獲取有關實驗室設置的更多詳細信息。

 

小塊：FIO綜合基準測試

重要的是要考慮到，使用Bluestore壓縮可以節省的空間完全取決于應用程序工作負載的可壓縮性以及所使用的壓縮模式。因此，對于8KB的塊大小和40個帶有主動壓縮的RBD卷，我們已經實現了以下 compress_success_count和compress_rejected_count。

“ compress_success_count”：48190908， 
  “ compress_rejected_count”：26669868， 

在我們的數據集執行的74860776個寫請求總數(8KB)中，我們能夠成功壓縮48190908個寫請求，因此在我們的綜合數據集中成功壓縮的寫請求百分比為64%。

查看 bluestore_compressed_allocated和bluestore_comprperformance計數器，我們可以看到通過Bluestore壓縮，成功壓縮的64%的寫操作已轉換為每個OSD節省60Gb的空間。

“ bluestore_compressed_allocated”：60988112896 
“ bluestore_compressed_original”：121976225792 

如圖1 /表1所示，在比較“積極壓縮”與“不壓縮”時，我們觀察到IOPS百分比下降，這不是很明顯。同時，發現平均和尾部潛伏期略高。造成這種性能負擔的原因之一是，Ceph BlueStore壓縮每個對象blob以匹配compression_required_ratio，然后將確認發送回客戶端。結果，當壓縮設置為激進時，我們看到IOPS略有降低，平均和尾部延遲增加。

圖表1：FIO 100%寫測試-40個RBD卷

如圖2所示，我們嘗試通過對主動壓縮池和非壓縮池中的84個RBD卷運行FIO來增加群集上的負載。我們觀察到了類似的性能差異，如圖1所示。與沒有壓縮相比，BlueStore壓縮消耗了少許性能。實際上，任何聲稱提供動態壓縮功能的存儲系統都可以期望這一點。

圖表2：FIO 100%隨機讀取/隨機寫入測試-84 RBD卷

壓縮還具有與之相關的計算成本。數據壓縮是通過諸如snappy和zstd之類的算法完成的，它們需要CPU周期來壓縮原始blob并將其存儲。如圖3所示，塊大小較小(8K)時，主動壓縮和無壓縮之間的CPU利用率增量較低。隨著將塊大小增加到16K / 32K / 1M，此增量也會增加。原因之一可能是，對于更大的塊大小，壓縮算法需要做更多的工作才能壓縮blob和存儲，從而導致更高的CPU消耗。

圖表3：FIO 100%隨機寫入測試-84個RBD卷(IOPS與CPU%利用率)

大塊(1MB)：FIO綜合基準測試

與小塊大小相似，我們還測試了具有不同壓縮模式的大塊大小工作負載。因此，我們已經測試了侵略性(aggressive)，強制性和非壓縮性模式。如圖4所示，攻擊模式和強制模式的總吞吐量非常相似，我們沒有觀察到明顯的性能差異。除了隨機讀取工作負載以外，在隨機讀寫和隨機寫入模式下，壓縮(積極/強制)與非壓縮模式之間的性能差異很大。

圖表4：FIO 1MB-40 RBD卷

為了確定系統上的更多負載，我們使用了libRBD FIO IO引擎并生成了84個RBD卷。該測試的性能如圖5所示

圖表5：FIO 1MB-84 RBD卷

MySQL數據庫池上的Bluestore壓縮

到目前為止，我們已經討論了由PBench-Fio自動化的基于FIO的綜合性能測試。為了了解BlueStore壓縮在接近實際的生產工作負載中的性能含義，我們在壓縮和未壓縮的存儲池上測試了多個MySQL數據庫實例的性能。

MySQL測試方法

Bluestore的配置與之前的測試相同，使用的是快速算法和主動壓縮模式。我們在OpenStack上部署了20個VM實例，這些實例托管在5個計算節點上。在這20個VM實例中，有10個VM用作MySQL數據庫實例，而其余10個實例是MySQL數據庫客戶端，因此在數據庫實例和DB客戶端之間創建了1：1關系。

通過Cinder為10xMariadb服務器配置了1x100GB RBD卷，并將其安裝在上/var/lib/mysql。dd在創建文件系統并將其安裝之前，通過使用該工具寫入完整的塊設備來對該卷進行預處理 。

/dev/mapper/APLIvg00-lv_mariadb_data 99G 8.6G 91G 9% /var/lib/mysql 

測試過程中使用的MariaDB配置文件在本要點中可用。數據集是使用以下sysbench命令在每個數據庫上創建的。

sysbench oltp_write_only --threads=64 --table_size=50000000 --mysql-host=$i --mysql-db=sysbench --mysql-user=sysbench --mysql-password=secret --db-driver=mysql --mysql_storage_engine=innodb prepare 

創建數據集后，運行以下三種類型的測試：

• 讀
• 寫
• 讀_寫

在每次測試之前，必須重新啟動mariadb實例以清除innodb緩存，每個測試均在900秒內運行并重復2次，捕獲的結果是兩次運行的平均值。

MySQL測試結果

Bluestore壓縮所能節省的空間完全取決于應用程序工作負載的可壓縮性以及所使用的壓縮模式。

通過Mysql壓縮測試，結合了Sysbench生成的數據集和經過積極壓縮的bluestore默認compression_required_ratio(0.875)，我們獲得了以下計數。

compress_success_count：594148， 
compress_rejected_count：1991191， 

在我們的數據集中運行的2585339個寫入請求總數中，我們能夠成功壓縮594148個寫入請求，因此在Mysql Sysbench數據集中成功壓縮的寫入請求百分比為22%。

查看 bluestore_compressed_allocated和bluestore_compressed_original性能計數器，我們可以看到成功壓縮的22%的寫操作通過壓縮轉換為每個OSD節省了20Gb的空間。

bluestore_compressed_allocated：200351744， 
bluestore_compressed_original：400703488， 

借助Ceph-metrics，我們在MySQL測試期間監視了OSD節點上的系統資源。發現OSD節點的平均cpu使用率低于14%，磁盤利用率低于9%范圍，發現磁盤延遲平均低于2 ms，且峰值保持在個位數。

如圖6所示，BlueStore壓縮未嚴重影響每秒MySQL事務(TPS)。與不壓縮TPS和事務延遲相比，BlueStore主動壓縮確實表現出較小的性能負擔。

圖6：MySQL數據庫池上的BlueStore壓縮

重要要點

• 與非壓縮池相比，啟用了BlueStore壓縮功能的池與基于FIO的綜合工作負載相比，性能僅降低10%，而對MySQL數據庫工作負載僅降低7%。這種減少歸因于執行數據壓縮的基礎算法。
• 使用較小的塊大小(8K)，發現主動壓縮和無壓縮模式之間的CPU利用率增量較低。隨著我們增加塊大小(16K / 32K / 1M)，此增量也會增加
• 低管理開銷，同時在Ceph池上啟用壓縮。Ceph CLI開箱即用，提供了啟用壓縮所需的所有功能。

6、Ceph 3.3與2.2前后端對比

這篇文章是我們兩年前基于Red Hat Ceph Storage 2.0 FileStore OSD后端和Civetweb RGW前端進行的對象存儲性能測試的續篇。在本文中，我們將比較(撰寫本文時)最新可用的 Ceph Storage的性能，即3.3版(BlueStore OSD后端和Beast RGW前端)與Ceph Storage 2.0版(2017年中)(FileStore OSD后端和Civetweb RGW前端)。

我們意識到，這兩個性能研究的結果在科學上都不具有可比性。但是，我們認為，將兩者進行比較應該可以為您提供重要的性能見解，并使您能夠在架構Ceph存儲群集時做出明智的決定。

正如預期的那樣，在我們測試的所有工作負載中，Ceph Storage 3.3的性能均優于Ceph Storage 2.0。我們認為Ceph Storage 3.3的性能改進歸因于幾件事的結合。BlueStore OSD后端，RGW的Beast Web前端，BlueStore WAL使用的Intel Optane SSD，block.db和最新一代的Intel Cascade Lake處理器。

讓我們仔細看一下兩個Ceph Storage版本的性能比較。

測試實驗室配置

這是我們實驗室環境的簡要介紹。測試是在Dell EMC實驗室中使用其硬件以及英特爾提供的硬件進行的。

Ceph Storage 3.3環境

表1：Ceph Storage 3.3測試實驗室配置

Ceph Storage 2.0環境

表2：Ceph Storage 2.0測試實驗室配置

小對象性能

在本節中，我們將研究小型對象的性能。

小對象100%的寫入工作量

圖表1比較了Ceph Storage 3.3和Ceph Storage 2.0版本的小對象100%寫入工作負載的性能。如圖所示，與Ceph Storage 2.0相比，Ceph Storage 3.3始終提供更高的數量級每秒操作(Ops)性能。因此，我們發現Ceph Storage 3.3的操作數提高了500%以上。

您可能想知道，Ceph Storage 3.3性能線出現2倍性能急劇下降的原因是什么?據稱是因為由RGW動態桶重新分片事件導致的(參考上文內容)。

圖表1：小對象大小100%寫性能

小對象100%讀取工作負載

與Ceph Storage 2.0相比，Ceph Storage 3.3的100%讀取工作負載顯示出近乎完美的性能，而Ceph Storage 2.0的性能在大約第18小時的測試中直線下降。對于Ceph Storage 2.0，讀取OPS的下降是由于隨著群集對象數量的增加，文件系統元數據查找所花費的時間增加所致。

當群集中包含較少的對象時，內核會在內存中緩存更大比例的文件系統元數據。但是，當群集增長到數百萬個對象時，緩存了較小百分比的元數據。然后，磁盤被迫執行專門用于元數據查找的I / O操作，從而增加了額外的磁盤搜索，并導致讀取的OPS降低。

Ceph Storage 3.3及更高版本的Bluestore OSD后端在讀取操作期間不依賴Linux頁面緩存。這樣，Bluestore OSD會執行自己的內存管理，因此有助于實現讀取工作負載的確定性性能，如圖2所示。

圖表2：小型物件100%的讀取效能

大對象性能

接下來，我們將注意力轉向大型對象性能基準測試。

大對象100%的寫入工作量

對于大對象100%寫入測試，Ceph Storage 3.3提供了次線性性能改進，而Ceph Storage 2.0顯示了逆向性能，如圖3所示。在Ceph Storage 2.0測試期間，我們缺少附加的RGW節點，而Containerized Storage Daemon也沒有一個選項。因此，對于Ceph Storage 2.0測試，我們無法測試超過4個RGW。

除非子系統資源飽和，否則Ceph Storage 3.3的寫入帶寬約為5.5 GBps。另一方面，Ceph Storage 2.0的性能卻下降了。

圖表3：大對象大小100%的寫入性能

大對象100%讀取工作負載

大對象100%的讀取工作負載顯示了Ceph Storage 2.0和3.3測試的次線性性能。如上一節所述，在Ceph Storage 2.0測試時，我們沒有用于RGW的其他物理節點，因此我們被限制為4個，無法進一步擴展RGW。

Ceph Storage 3.3顯示5.5 GBps 100%的讀取帶寬，在7個RGW的情況下未發現瓶頸。我們的假設是，如果我們添加更多的RGW，Ceph Storage 3.3可能會提供更多的帶寬。圖表4比較了100%大對象工作負載下Ceph Storage 3.3和Ceph Storage 2.2的性能。

圖4：大對象大小100%的讀取性能

總結

我們承認，上面顯示的性能比較并不完全相似的對比。我們相信這項研究應該為您提供不同Ceph Storage版本的關鍵性能見解，并幫助您做出明智的決定。

我們盡力在這兩項研究中選擇共同點。有趣的是，只有一半的磁盤軸(110 Ceph Storage 3.3 test vs 210 Ceph Storage 2.0 test)帶有BlueStore OSD后端和Beast RGW前端web服務器的Ceph Storage 3.3為小對象提供了5倍高的操作，為大對象提供了2倍高的帶寬100%的寫入工作負載。在下一篇文章中，我們將揭示在Ceph集群中存儲10億多個對象的性能。

7、Ceph擴展到超過十億個對象

這是Red Hat Ceph對象存儲性能系列中的第六篇。在這篇文章中，我們將進行深入研究，學習如何將經過測試的Ceph擴展到超過十億個對象，并分享在此過程中發現的性能秘密。為了更好地理解本文中顯示的性能結果，建議閱文章的第一部分內容，其中詳細介紹了實驗室環境，性能工具包和所用方法。

執行摘要

• 讀?。河^察到一致的聚合吞吐量(Ops)和讀取延遲。
• 寫入：觀察到一致的寫入延遲，直到群集達到大約容量的90%。
• 在整個測試周期中，我們沒有觀察到CPU、內存、HDD、NVMe和網絡上的任何瓶頸。我們也沒有觀察到Ceph守護進程的任何問題，這些問題表明集群在存儲對象的數量上有困難。
• 此測試是在相對較小的集群上執行的。元數據溢出到較慢的設備上的組合效應以及集群容量的大量使用影響了整體性能?？梢酝ㄟ^正確調整Bluestore元數據設備的大小并在集群中保持足夠的可用容量來緩解這種情況。

表現摘要

• 成功攝取了超過十億個對象(準確地說是1,014,912,090個對象)，這些對象通過S3對象接口跨10K存儲桶分布到Ceph集群中，而操作或數據一致性挑戰為零。這證明了Ceph集群的可擴展性和健壯性。
• 當集群中的對象總數接近8.5億時，我們的存儲容量不足。當群集填充率達到約90%時，我們需要為更多的對象騰出空間，因此我們從以前的測試中刪除了較大的對象，并激活了均衡器模塊。他們共同創造了額外的負載，我們認為這會降低客戶端吞吐量并增加延遲。
• 有害的寫入性能反映了Bluestore元數據從閃存溢出到低速設備的情況。對于涉及存儲數十億個對象的用例，建議為Bluestore元數據(block.db)適當調整SSD的大小，以避免rocksDB級別溢出到速度較慢的設備上。
• 使用 bluestore_min_alloc_size = 64KB會導致小型擦除編碼對象的空間顯著放大。
• 減少 bluestore_min_alloc_size消除了空間放大問題，但是由于18KB未對齊4KB，導致對象創建速率降低。
• SSD 的默認 bluestore_min_alloc_size 在RHCS 4.1中將更改為4KB，并且使4KB也適合HDD的工作。
• 對于批量刪除操作，發現S3對象刪除API與Ceph Rados API相比要慢得多。因此，我們建議您使用“對象到期存儲桶生命周期”，或使用radosgw-admin工具進行批量刪除操作。

測試方法

要將十億個對象存儲到Ceph集群中，我們使用了COSBench并執行了數百次測試回合，其中每一回合包括

• 創建14個新的存儲桶。
• 每個存儲區可攝取(即寫入)100,000個64KB有效負載大小的對象。
• 在300秒的時間內讀取盡可能多的書面對象。

績效結果

Ceph被設計為一個固有的可擴展系統。我們在此項目中進行的十億個對象提取測試強調了Ceph可擴展性且非常重要的維度。在本節中，我們將分享在將10億個對象存儲到Ceph集群時捕獲的相關發現。

讀取表現

圖1表示以聚合吞吐量(ops)指標衡量的讀取性能。圖2顯示了平均讀取延遲，以毫秒為單位(藍線)。這兩個圖表均顯示了從Ceph群集獲得的強大且一致的讀取性能，而測試套件吸收了超過十億個對象。在整個測試過程中，讀取吞吐量保持在15K Ops-10K Ops的范圍內。這種性能差異可能與高存儲容量消耗(約90%)以及在后臺發生的舊的大對象刪除和重新平衡操作有關。

圖表1：對象計數與匯總讀取吞吐量操作

圖2比較了在讀取對象時讀寫測試的平均延遲(以毫秒為單位)(從客戶端測量)。在此測試規模的前提下，讀取和寫入延遲都保持非常一致，直到我們用盡存儲容量并將大量Bluestore元數據溢出到速度較慢的設備上為止。

測試的前半部分顯示，與讀取相比，寫入延遲保持較低。這可能是Bluestore效應。我們過去所做的性能測試顯示了類似的行為，其中發現Bluestore寫延遲比Bluestore讀延遲略低，這可能是因為Bluestore不依賴Linux頁面緩存進行預讀和OS級緩存。

在測試的后半部分，讀取延遲比寫入延遲低，這可能與Bluestore元數據從閃存溢出到慢速HDD有關(在下一節中說明)。

圖表2：讀寫延遲比較

寫性能

圖3表示通過其S3接口將十億個64K對象提取(寫入操作)到我們的Ceph集群。該測試從已經存儲在Ceph集群中的大約2.9億個對象開始。

該數據是由之前的測試運行創建的，我們選擇不刪除該數據，并從此時開始填充集群，直到達到10億個對象為止。我們執行了600多次獨特的測試，并在集群中填充了10億個對象。在課程中，我們測量了指標，例如總對象數，讀寫吞吐量(Ops)，讀寫平均延遲(ms)等。

在大約5億個對象的情況下，群集達到了其可用容量的50%，我們觀察到聚合寫入吞吐量性能下降的趨勢。經過數百次測試后，聚合的寫吞吐量繼續下降，而群集使用的容量達到了驚人的90%。

從這一點出發，為了達到我們的目標，即存儲十億個對象，我們需要更多的可用容量，因此我們刪除/重新平衡了大于64KB的舊對象。

眾所周知，通常隨著總體消耗的增加，存儲系統的性能會逐漸下降。我們觀察到與Ceph類似的行為，在大約90%的已用容量下，總吞吐量與我們最初開始時相比有所下降。因此，我們認為如果添加更多存儲節點以保持較低的利用率，則性能可能不會像我們觀察到的那樣遭受損失。

另一個有趣的發現，我們發現Bluestore元數據頻繁從NVMe到HDD溢出導致聚合性能下降。我們攝取了大約十億個新對象，生成了許多Bluestore元數據。根據設計，Bluestore元數據存儲在rocksDB中，建議將此分區存儲在Flash介質上，在本例中，我們為每個OSD使用80GB NVMe分區，該分區共享在Bluestore rocksDB和WAL之間。

rocksDB在內部使用級別樣式壓縮，其中rocksDB中的文件被組織為多個級別。例如，Level-0(L0)，Level-1(L1)等。級別0是特殊的，其將內存中的寫緩沖區(內存表)刷新到文件，并且其中包含最新數據。較高的級別包含較舊的數據。

當L0文件達到特定閾值(可使用 level0_file_num_compaction_trigger進行配置)時，它們將合并到L1中。所有非0級都有目標大小。rocksDB的壓縮目標是將每個級別的數據大小限制在目標范圍內。將目標大小計算為級別基礎大小x 10作為下一個級別乘數。因此，L0目標大小為(250MB)，L1(250MB)，L2(2,500MB)，L3(25,000MB)等。

所有級別的目標大小的總和就是您需要的rocksDB存儲總量。根據Bluestore配置的建議，rocksDB存儲應使用閃存介質。如果我們沒有為rocksDB提供足夠的閃存容量來存儲其Levels，rocksDB會將Levels數據溢出到速度較慢的設備(例如HDD)上。畢竟，數據必須存儲在某個地方。

rocksDB元數據從閃存設備到HDD的這種溢出大大降低了性能。如圖4所示，當我們將對象存儲到系統中時，每個OSD溢出的元數據達到80GB以上。

因此，我們的假設是，Bluestore元數據從閃存介質到慢速介質的這種頻繁溢出是我們案例中聚合性能下降的原因。

這樣，如果您知道用例將涉及在Ceph集群上存儲數十億個對象，則可以通過對每個Ceph OSD使用適用于BlueStore(rocksDB)元數據的Ceph OSD使用較大的閃存分區來緩解性能影響，從而可以將其存儲在閃存上訪問rocksDB的L4文件。

圖表3：對象計數與匯總寫入吞吐量操作

圖表4：Bluestore元數據溢出到慢速(HDD)設備上

其它發現

在本節中，我們希望涵蓋我們的一些其他發現。

大規模刪除對象

當集群的存儲容量用盡時，除了刪除存儲在存儲桶中的舊的大對象外，我們別無選擇，并且有數百萬個這樣的對象。我們最初是從S3 API的DELETE方法開始的，但很快我們意識到它不適用于存儲桶刪除，因為必須刪除存儲桶中的所有對象，然后才能刪除存儲桶本身。

我們遇到的另一個S3 API限制是，每個API請求只能刪除1K個對象。我們有數百個存儲桶，每個存儲桶都有100K個對象，因此使用S3 API DELETE方法刪除數百萬個對象對我們來說是不切實際的。

幸運的是，使用radosgw-admin CLI工具公開的本機RADOS網關API支持刪除加載了對象的存儲桶。通過使用本機RADOS網關API，我們花了幾秒鐘刪除了數百萬個對象。因此，對于任何規模的刪除對象，Ceph的本地API都可以挽救。

修改 bluestore_min_alloc_size_hdd參數

該測試是在具有4 + 2配置的擦除編碼池上完成的。因此，根據設計，每個64K有效負載都必須分成4個16KB的塊。Bluestore使用的 bluestore_min_alloc_size_hdd參數表示為存儲在Ceph Bluestore對象存儲中的對象創建的Blob的最小大小，其默認值為64KB。因此在這種情況下，將為每個16KB EC塊分配64KB空間，這將導致48KB的未使用空間開銷，無法進一步利用。

因此，在進行10億個對象攝取測試之后，我們決定將 bluestore_min_alloc_size_hdd 降低到18KB并重新測試。如圖5所示，在將bluestore_min_alloc_size_hdd參數從64KB(默認值)降低到18KB之后，發現對象創建速率顯著降低。因此，對于大于bluestore_min_alloc_size_hdd的對象，默認值似乎是最佳值，如果打算減少bluestore_min_alloc_size_hdd參數，則較小的對象還需要更多篩選。請注意，不能將bluestore_min_alloc_size_hdd設置為低于bdev_block_size(默認值為4096-4kB)。

圖5：每分鐘的物體攝取率

總結

在本文中，我們通過將十億多個對象存儲到Ceph集群中，展示了Ceph集群的健壯性和可伸縮性。我們了解了與群集相關聯的各種性能特征，其中包括最大容量的群集，以及將bluestore元數據溢出到速度較慢的設備上如何提高性能，以及在設計大規模規模的Ceph群集時可以選擇的緩解措施。

參考鏈接：

https://www.redhat.com/en/blog/red-hat-ceph-object-store-dell-emc-servers-part-1

https://www.redhat.com/en/blog/red-hat-ceph-storage-rgw-deployment-strategies-and-sizing-guidance?source=blogchannel&channel=blog/channel/red-hat-storage&page=1

https://www.redhat.com/en/blog/achieving-maximum-performance-fixed-size-ceph-object-storage-cluster?source=blogchannel&channel=blog/channel/red-hat-storage&page=1

https://www.redhat.com/en/blog/ceph-rgw-dynamic-bucket-sharding-performance-investigation-and-guidance?source=blogchannel&channel=blog/channel/red-hat-storage&page=1

https://www.redhat.com/en/blog/red-hat-ceph-storage-33-bluestore-compression-performance?source=blogchannel&channel=blog/channel/red-hat-storage&page=1

https://www.redhat.com/en/blog/comparing-red-hat-ceph-storage-33-bluestorebeast-performance-red-hat-ceph-storage-20-filestorecivetweb?source=blogchannel&channel=blog/channel/red-hat-storage&page=1

https://www.redhat.com/en/blog/scaling-ceph-billion-objects-and-beyond?source=author&term=43551