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

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

1、構(gòu)建健壯的對象存儲基礎(chǔ)架構(gòu)

本部分主要介紹如何結(jié)合使用Red Hat Ceph Storage，Dell EMC存儲服務(wù)器和網(wǎng)絡(luò)來構(gòu)建健壯的對象存儲基礎(chǔ)架構(gòu)。

環(huán)境搭建

本環(huán)境是Dell EMC實驗室中使用其硬件以及英特爾提供的硬件進(jìn)行的

硬件配置

 

表1：硬件配置

 

表2：軟件配置

 

表3：資源限制

機架設(shè)計

 

 

圖1：實驗室機架設(shè)計

 

 

圖2：測試實驗室邏輯設(shè)計

有效負(fù)載選擇

對象存儲的有效負(fù)載差異很大，有效負(fù)載大小是設(shè)計基準(zhǔn)測試用例時的關(guān)鍵考慮因素。在理想的基準(zhǔn)測試用例中，有效負(fù)載大小應(yīng)代表實際的應(yīng)用程序工作負(fù)載。與通常只讀取或?qū)懭霂浊ё止?jié)的塊存儲工作負(fù)載測試不同，其中對象存儲工作負(fù)載進(jìn)行測試需要涵蓋各種有效負(fù)載大小。以下是本次實驗對象有效負(fù)載的大小。

 

 

表4：經(jīng)過測試的有效負(fù)載

數(shù)據(jù)處理應(yīng)用程序傾向于在較大的文件上運行，根據(jù)我們的測試，我們發(fā)現(xiàn)32MB是COSBench在我們的測試范圍內(nèi)可以可靠處理的最大對象大小。

執(zhí)行摘要

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

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

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

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

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

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

隨著存儲桶中對象總數(shù)的增長，需要管理的索引元數(shù)據(jù)的數(shù)量也相應(yīng)增加。索引元數(shù)據(jù)分布在許多分片上，以確?？梢杂行У卦L問它。當(dāng)存儲桶中的對象數(shù)量大于使用當(dāng)前分片數(shù)量可以有效管理的數(shù)量時，Red Hat Ceph Storage將動態(tài)增加分片數(shù)量。在我們的測試過程中，我們發(fā)現(xiàn)動態(tài)分片事件對目的地為動態(tài)分片的存儲桶的請求的吞吐量具有短暫有害的影響。如果開發(fā)人員具有將存儲桶增長到給定數(shù)量的經(jīng)驗知識，則可以創(chuàng)建該存儲桶或?qū)⑵涫謩痈聻槟軌蛴行菁{元數(shù)據(jù)量的多個分片。

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

體系結(jié)構(gòu)

 

表5：體系結(jié)構(gòu)摘要

Ceph基準(zhǔn)性能測試

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

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

使用了以下CBT配置：

• 工作量：順序?qū)憸y試，然后順序讀測試
• 塊大小：4MB
• 片長：300秒
• 每個客戶端的并發(fā)線程數(shù)：128
• 每個客戶端的RADOS基準(zhǔn)實例：1
• 池數(shù)據(jù)保護(hù)：Ec 4 + 2刪除或3x復(fù)制
• 客戶總數(shù)：7

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

 

圖1：Radosbench 100%寫入測試

 

圖2：Radosbench 100%讀取測試

總結(jié)

在本文中，我們詳細(xì)介紹了實驗室體系結(jié)構(gòu)，包括硬件和軟件配置，分享了來自基礎(chǔ)集群基準(zhǔn)測試的一些結(jié)果，并提供了高級執(zhí)行和體系結(jié)構(gòu)的相關(guān)摘要。

2、Ceph RGW 部署策略和大小調(diào)整

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

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

并置的RGW

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

 

 

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

多主機RGW

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

 

 

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

獨立RGW

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

 

 

圖3：獨立的RGW部署策略

表現(xiàn)摘要

(一)RGW部署和規(guī)模調(diào)整指南

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

100%寫入工作量

如圖1和圖2所示

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

 

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

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

100%讀取工作負(fù)載性能

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

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

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

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

 

 

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

 

 

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

(二)RGW線程池大小調(diào)整準(zhǔn)則

在決定將CPU內(nèi)核分配給RGW實例時，非常相關(guān)的RGW調(diào)整參數(shù)之一rgw_thread_pool_size是負(fù)責(zé)由Beast生成的與HTTP請求相對應(yīng)的線程數(shù)。這有效地限制了Beast前端可以服務(wù)的并發(fā)連接數(shù)。

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

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

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

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

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

總結(jié)

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

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

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

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

大對象工作量

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

如圖1所示，當(dāng)增加RGW主機的數(shù)量時，大對象100%HTTP GET和HTTP PUT工作負(fù)載表現(xiàn)出亞線性可伸縮性。因此，我們?yōu)镠TTP GET和HTTP PUT工作負(fù)載測量了約5.5 GBps的聚合帶寬，有趣的是，我們沒有注意到Ceph集群節(jié)點中的資源飽和。

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

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

圖1：大對象測試

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

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

小對象工作量

如圖3所示，當(dāng)增加RGW主機的數(shù)量時，小型對象100%HTTP GET和HTTP PUT工作負(fù)載表現(xiàn)出次線性可伸縮性。因此，我們測量了9ms應(yīng)用程序?qū)懭胙舆t時HTTP PUT的6.2K Ops吞吐量，以及具有7個RGW實例的HTTP GET工作負(fù)載的3.2K Ops吞吐量。

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

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

 

圖3：小對象測試

總結(jié)

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

結(jié)果還表明，BlueStore OSD與Intel Optane NVMe的結(jié)合使用實現(xiàn)了平均應(yīng)用程序延遲個位數(shù)的好成績，這對于對象存儲系統(tǒng)而言是非常重要的。

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

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

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

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

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

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

動態(tài)存儲分區(qū)重新分片的意義

RHCS 3.0引入了動態(tài)存儲區(qū)重新分片功能。利用此功能，存儲桶索引現(xiàn)在將隨著存儲桶中對象數(shù)的增加而自動重新分片。重新分片發(fā)生時，您無需停止在存儲桶中讀取或?qū)懭雽ο?。動態(tài)重新分片是RGW的本機功能，如果該存儲桶中的對象數(shù)量超過100K，則RGW會自動識別需要重新分片的存儲桶，RGW通過產(chǎn)生一個負(fù)責(zé)處理已調(diào)度的特殊線程來為該存儲桶調(diào)度重新分片操作。動態(tài)重新分片現(xiàn)在是默認(rèn)功能，管理員無需采取任何措施即可激活它。

在本文中，我們將深入探討與動態(tài)重新分片功能相關(guān)的性能，并了解如何使用預(yù)分片的存儲區(qū)將其中的某些內(nèi)容最小化。

測試方法

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

1. 動態(tài)存儲桶重新分片測試，單個存儲桶最多可存儲3000萬個對象
2. 預(yù)先進(jìn)行存儲桶測試，其中存儲了大約2億個對象

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

動態(tài)存儲桶重新分片：性能洞察

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

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

圖1：RGW動態(tài)存儲桶重新分片

預(yù)共享存儲桶：性能洞察

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

圖2：預(yù)共享桶

圖3顯示了預(yù)分片存儲桶和動態(tài)分片存儲桶的性能對比。根據(jù)測試后存儲區(qū)統(tǒng)計數(shù)據(jù)，我們認(rèn)為這兩個類別的性能突然下降是由動態(tài)重新分片事件引起的。

因此，預(yù)分片存儲有助于實現(xiàn)確定性性能，因此從架構(gòu)的角度來看，以下是一些指導(dǎo)：

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

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

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

圖表3：動態(tài)存儲桶重新分片和預(yù)分片存儲桶性能比較：100%寫入

發(fā)現(xiàn)動態(tài)重新分片的存儲桶的讀取性能比預(yù)共享的存儲桶略高，但是預(yù)分片的存儲桶具有確定的性能，如圖4所示。

圖表4：動態(tài)存儲桶重新分片和預(yù)分片存儲桶性能比較：100%讀取

總結(jié)

如果我們知道應(yīng)用程序?qū)⒃谝粋€存儲桶中存儲多少個對象，則對存儲桶進(jìn)行預(yù)分片通常有助于提高整體性能。另一方面，如果事先不知道對象數(shù)，則Ceph RGW的動態(tài)存儲桶重新分片功能確實有助于避免與過載存儲桶相關(guān)的性能下降。

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

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

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

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

可以通過每個池屬性或全局配置選項來設(shè)置compression_mode，compression_algorithm，compression_required_ratio，compression_min-blob_size和compresion_max_blob_size參數(shù)。可以通過以下方式設(shè)置“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壓縮內(nèi)部構(gòu)件

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

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

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

Bluestore Compression配置和測試方法

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

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

2.使用FIO libRBD IOengine進(jìn)行84xRBD卷。

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

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是此處的關(guān)鍵可調(diào)參數(shù)，其計算公式為

bluestore_compression_required_ratio = size_compressed/siz_original 

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

要知道我們在FIO綜合數(shù)據(jù)集測試期間實現(xiàn)的壓縮量，我們使用了四個Ceph性能指標(biāo)：

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

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

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

在壓縮基準(zhǔn)測試期間從客戶端測量的關(guān)鍵指標(biāo)：

• IOPS。每秒完成的IO操作總數(shù)
• Average lantency?？蛻舳送瓿蒊O操作所需的平均時間。
• P95%。延遲的95%。
• P99%。延遲的99%。

測試實驗室配置

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

 

小塊：FIO綜合基準(zhǔn)測試

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

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

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

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

“ bluestore_compressed_allocated”：60988112896 
“ bluestore_compressed_original”：121976225792 

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

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

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

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

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

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

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

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

圖表4：FIO 1MB-40 RBD卷

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

圖表5：FIO 1MB-84 RBD卷

MySQL數(shù)據(jù)庫池上的Bluestore壓縮

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

MySQL測試方法

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

通過Cinder為10xMariadb服務(wù)器配置了1x100GB RBD卷，并將其安裝在上/var/lib/mysql。dd在創(chuàng)建文件系統(tǒng)并將其安裝之前，通過使用該工具寫入完整的塊設(shè)備來對該卷進(jìn)行預(yù)處理 。

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

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

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 

創(chuàng)建數(shù)據(jù)集后，運行以下三種類型的測試：

• 讀
• 寫
• 讀_寫

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

MySQL測試結(jié)果

Bluestore壓縮所能節(jié)省的空間完全取決于應(yīng)用程序工作負(fù)載的可壓縮性以及所使用的壓縮模式。

通過Mysql壓縮測試，結(jié)合了Sysbench生成的數(shù)據(jù)集和經(jīng)過積極壓縮的bluestore默認(rèn)compression_required_ratio(0.875)，我們獲得了以下計數(shù)。

compress_success_count：594148， 
compress_rejected_count：1991191， 

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

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

bluestore_compressed_allocated：200351744， 
bluestore_compressed_original：400703488， 

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

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

圖6：MySQL數(shù)據(jù)庫池上的BlueStore壓縮

重要要點

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

6、Ceph 3.3與2.2前后端對比

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

我們意識到，這兩個性能研究的結(jié)果在科學(xué)上都不具有可比性。但是，我們認(rèn)為，將兩者進(jìn)行比較應(yīng)該可以為您提供重要的性能見解，并使您能夠在架構(gòu)Ceph存儲群集時做出明智的決定。

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

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

測試實驗室配置

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

Ceph Storage 3.3環(huán)境

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

Ceph Storage 2.0環(huán)境

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

小對象性能

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

小對象100%的寫入工作量

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

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

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

小對象100%讀取工作負(fù)載

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

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

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

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

大對象性能

接下來，我們將注意力轉(zhuǎn)向大型對象性能基準(zhǔn)測試。

大對象100%的寫入工作量

對于大對象100%寫入測試，Ceph Storage 3.3提供了次線性性能改進(jìn)，而Ceph Storage 2.0顯示了逆向性能，如圖3所示。在Ceph Storage 2.0測試期間，我們?nèi)鄙俑郊拥腞GW節(jié)點，而Containerized Storage Daemon也沒有一個選項。因此，對于Ceph Storage 2.0測試，我們無法測試超過4個RGW。

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

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

大對象100%讀取工作負(fù)載

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

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

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

總結(jié)

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

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

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

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

執(zhí)行摘要

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

表現(xiàn)摘要

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

測試方法

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

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

績效結(jié)果

Ceph被設(shè)計為一個固有的可擴展系統(tǒng)。我們在此項目中進(jìn)行的十億個對象提取測試強調(diào)了Ceph可擴展性且非常重要的維度。在本節(jié)中，我們將分享在將10億個對象存儲到Ceph集群時捕獲的相關(guān)發(fā)現(xiàn)。

讀取表現(xiàn)

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

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

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

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

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

圖表2：讀寫延遲比較

寫性能

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

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

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

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

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

另一個有趣的發(fā)現(xiàn)，我們發(fā)現(xiàn)Bluestore元數(shù)據(jù)頻繁從NVMe到HDD溢出導(dǎo)致聚合性能下降。我們攝取了大約十億個新對象，生成了許多Bluestore元數(shù)據(jù)。根據(jù)設(shè)計，Bluestore元數(shù)據(jù)存儲在rocksDB中，建議將此分區(qū)存儲在Flash介質(zhì)上，在本例中，我們?yōu)槊總€OSD使用80GB NVMe分區(qū)，該分區(qū)共享在Bluestore rocksDB和WAL之間。

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

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

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

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

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

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

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

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

其它發(fā)現(xiàn)

在本節(jié)中，我們希望涵蓋我們的一些其他發(fā)現(xiàn)。

大規(guī)模刪除對象

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

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

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

修改 bluestore_min_alloc_size_hdd參數(shù)

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

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

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

總結(jié)

在本文中，我們通過將十億多個對象存儲到Ceph集群中，展示了Ceph集群的健壯性和可伸縮性。我們了解了與群集相關(guān)聯(lián)的各種性能特征，其中包括最大容量的群集，以及將bluestore元數(shù)據(jù)溢出到速度較慢的設(shè)備上如何提高性能，以及在設(shè)計大規(guī)模規(guī)模的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