背景

Ceph 社區(qū)最近凍結(jié)了即將發(fā)布的 Ceph Reef 版本，今天我們研究一下 Ceph Reef 版本在 10 個(gè)節(jié)點(diǎn)、60 個(gè) NVMe 磁盤的集群上的 RBD 性能。

在確保硬件沒有問題（NVMe 固件更新）后，Reef 能夠保證約71GB/s的性能讀取和25GB/s的性能寫入（75GB/s 復(fù)制速度）。

對(duì)于小型隨機(jī) IO，Reef 提供了大約4.4M 隨機(jī)讀取 IOPS和800K 隨機(jī)寫入 IOPS（2.4M 復(fù)制速度）。

對(duì)于小型 4K 順序同步寫入，Reef 實(shí)現(xiàn)了低于 0.5 毫秒的平均延遲、低于 0.5 毫秒的 99% 延遲和低于 0.8 毫秒的 99.9% 延遲。

即使在商業(yè)硬件設(shè)備上執(zhí)行 3 倍的同步復(fù)制，它也實(shí)現(xiàn)了低于 8 毫秒的最大延遲。

雖然 Reef 要比 Quincy 性能更佳，但我們也發(fā)現(xiàn)了一些小問題。

在 Reef 凍結(jié)期間，我們將研究這些問題，以幫助 Reef 成為迄今為止最好的 Ceph 版本。

介紹

在過去的幾個(gè) Ceph 版本中，Ceph 社區(qū)和 Red Hat 的 perf and scale 團(tuán)隊(duì)都進(jìn)行了各種性能測(cè)試，以將以前的版本與我們新的預(yù)發(fā)布代碼進(jìn)行比較。

我們希望看到我們?cè)谛阅芨倪M(jìn)的過程中沒有再引入新的其他問題。

Pacific 和 Quincy 的發(fā)布對(duì)我們來說是一個(gè)比較完美的節(jié)點(diǎn)。因?yàn)槲覀兺ㄟ^版本的回歸，并最終在發(fā)布之前確認(rèn)了一些可能會(huì)有影響的問題。

捕獲細(xì)微的性能問題是非常復(fù)雜的，并且當(dāng)我們嘗試將過去測(cè)試的結(jié)果與新結(jié)果進(jìn)行比較時(shí)會(huì)變得更加困難。

在這過程中，發(fā)生了什么變化？是由于代碼更改、硬件/軟件架構(gòu)更改還是其他原因造成的？

Performance-CI 在這里可用于嘗試在問題發(fā)生時(shí)捕獲問題，但它非常耗費(fèi)資源，并且除非我們非常小心，否則很容易出現(xiàn)差錯(cuò)。

今天，我們將對(duì) Quincy 和 Reef 進(jìn)行簡(jiǎn)單的對(duì)比測(cè)試，我們將嘗試以完全相同的方式在完全相同的硬件上進(jìn)行測(cè)試，以使差異盡可能小。

集群設(shè)置

所有節(jié)點(diǎn)都連接到同一臺(tái) Juniper QFX5200 交換機(jī)上，并通過單個(gè) 100GbE QSFP28 連接。同時(shí)我們部署了 Ceph 并使用 CBT (https://github.com/ceph/cbt/)啟動(dòng)了 fio 測(cè)試。

除非特別說明，否則每個(gè)節(jié)點(diǎn)都安裝 6 個(gè) OSD，同時(shí) fio 運(yùn)行 6 個(gè) librbd 類型的進(jìn)程。

基于英特爾的系統(tǒng)可以配置 "latency-performance" 以及 "network-latency" 來對(duì)系統(tǒng)進(jìn)行調(diào)優(yōu)。

這避免與 CPU C/P 狀態(tài)轉(zhuǎn)換帶來延遲?；?AMD Rome 的系統(tǒng)在這方面的調(diào)優(yōu)并沒有太大的改變，而且我們還沒有確認(rèn) tuned 實(shí)際上限制了 C/P 狀態(tài)轉(zhuǎn)換，但是對(duì)于這些測(cè)試，tuned 配置文件仍然設(shè)置為 “network-latency”。

測(cè)試設(shè)置

CBT 需要針對(duì)所部署的 Ceph 集群調(diào)整幾個(gè)參數(shù)。

首先，禁用 rbd 緩存，為每個(gè) OSD 分配 8GB 內(nèi)存，并在禁用 cephx 的情況下使用 msgr V2。

Fio 配置為首先使用大量寫入預(yù)填充 RBD 卷，然后在 iodepth=128 下進(jìn)行 3 次迭代測(cè)試（如下表所示），每次迭代 5 分鐘。每個(gè)節(jié)點(diǎn)使用 6 個(gè) fio 進(jìn)程，總共使用 60 個(gè) fio 進(jìn)程，聚合 iodepth 為 7680。

一些后臺(tái)進(jìn)程，比如 scrub、deep scrub、pg autoscaling 和 pg balancing 會(huì)被禁用。

配置靜態(tài) 16384 PG（高于通常推薦的數(shù)量）和 3x 副本的 RBD 池與每個(gè) fio 進(jìn)程 1 個(gè) RBD 鏡像一起使用。

最初的誤導(dǎo)性結(jié)果

只要是多余單個(gè) OSD 的集群，Ceph 會(huì)使用 crush 以偽隨機(jī)方式存儲(chǔ)數(shù)據(jù)。

雖然比較多的 PG 數(shù)量以及 PG 均衡可以幫助改善這一點(diǎn)，但總會(huì)有差異，一些 OSD 不可避免地需要比其他 OSD 花費(fèi)更長(zhǎng)的時(shí)間來完成他們的工作。

因此，在任何給定的時(shí)間內(nèi)，集群性能通常會(huì)受到最慢或使用率最高的 OSD 的限制。這是每個(gè) Ceph 運(yùn)維人員都應(yīng)該知道的事情。

我們?yōu)槭裁船F(xiàn)在提出這個(gè)？在 Reef 凍結(jié)之后，我們恢復(fù)了用于 Quincy 測(cè)試的 CBT 配置，并開始運(yùn)行一組新的測(cè)試。初步結(jié)果看起來相當(dāng)不錯(cuò)。Quincy 的表現(xiàn)略低于預(yù)期，但與我們之前看到的相差不遠(yuǎn) (https://ceph.io/en/news/blog/2022/rocksdb-tuning-deep-dive).。

然而，一旦我到達(dá)瓶頸，結(jié)果開始看起來有點(diǎn)意外。

Reef 正在使用新的 RocksDB 調(diào)優(yōu)配置(https://ceph.io/en/news/blog/2022/rocksdb-tuning-deep-dive)，并進(jìn)行了深度測(cè)試。

當(dāng)這些調(diào)優(yōu)用在 Quincy 版本時(shí)，我們獲得了很明顯的性能改進(jìn)，我們預(yù)計(jì) Reef 版本也會(huì)有類似的改進(jìn)。

在這些測(cè)試中，Reef 的表現(xiàn)并不比 Quincy 好，實(shí)際上也不比 Pacific 好多少。

我們運(yùn)行了很多次對(duì)比測(cè)試，并試圖梳理出可能解釋差異的因素。

后來，我們意識(shí)到我們可能應(yīng)該關(guān)注一下系統(tǒng)的指標(biāo)。CBT 為每個(gè)測(cè)試運(yùn)行一個(gè) collectl 副本，并記錄大量系統(tǒng)指標(biāo)數(shù)據(jù)。

事實(shí)上，在運(yùn)行的 RBD 和 RGW 測(cè)試之間，CBT 在長(zhǎng)時(shí)間的測(cè)試過程中記錄了超過 20GB 的指標(biāo)數(shù)據(jù)。

我們查看了系統(tǒng)中每個(gè) NVMe 設(shè)備的性能指標(biāo)。我們注意到，當(dāng)?shù)?10 個(gè)集群節(jié)點(diǎn)中的 nvme4 在大量寫入測(cè)試中顯示出較高的設(shè)備隊(duì)列等待時(shí)間，但在讀取測(cè)試中卻沒有。尤其是當(dāng)在4KB 隨機(jī)寫入的時(shí)候，效果就更明顯了：

這些是 nvme4 上非常明顯的延遲峰值，我們可以肯定這些與低于預(yù)期的性能有關(guān)。

這個(gè) NVME 是目前發(fā)現(xiàn)的延遲最嚴(yán)重的一個(gè)，但其他節(jié)點(diǎn)中的一些 NVME 也顯示出高于預(yù)期的延遲。

為了排除碎片的問題，我們對(duì)每個(gè) NVME 進(jìn)行完全安全擦除。

另外，在 Quincy 發(fā)布期間，我們從三星那里獲得到了一個(gè)新的 NVME。

當(dāng)我們將其安裝替換到我們的集群上時(shí)，結(jié)果很明顯。

固件升級(jí)后，設(shè)備隊(duì)列永遠(yuǎn)不會(huì)有超過一個(gè) IO 等待，隊(duì)列等待時(shí)間永遠(yuǎn)不會(huì)超過 0ms。

看起來固件更新解決了當(dāng)前的問題，但它能夠永久修復(fù)該問題嗎？隨著時(shí)間的推移，我們需要觀察硬件的狀態(tài)以確保是否永久修復(fù)了該問題。

出于本次測(cè)試的目的，我們恢復(fù)了集群到正常的性能。

另外，性能提升了多少？固件更新主要有助于 4KB 和 128KB 隨機(jī)寫入測(cè)試。

性能現(xiàn)在大致恢復(fù)到去年秋天在 RocksDB 調(diào)優(yōu)測(cè)試中觀察到的水平。

更重要的是，小型隨機(jī) IO 測(cè)試顯示出非常一致的 NVMe 驅(qū)動(dòng)器行為。

接下來我們將重新運(yùn)行測(cè)試并進(jìn)行一些對(duì)比。

4MB 連續(xù)吞吐量

在大吞吐量測(cè)試中，Quincy 和 Reef 達(dá)到了大致相同的性能水平。

Reef 對(duì)于大量寫入可能會(huì)快一點(diǎn)，而對(duì)于大量讀取可能會(huì)慢一點(diǎn)。

在這兩種情況下，底層集群都能夠以大約 70-75GB/s 的速度執(zhí)行，盡管因?yàn)槲覀冋谶M(jìn)行 3X 復(fù)制，客戶端可見寫入吞吐量實(shí)際上約為 25GB/s。

在這些測(cè)試中，每個(gè) OSD 的平均 CPU 消耗為 1-1.5 個(gè)核心用于讀取和 3-4 個(gè)核心用于寫入。

這種差異非常典型，因?yàn)?Ceph 的寫入路徑比讀取路徑更長(zhǎng)。

4KB 隨機(jī) IOPS

每個(gè)版本對(duì)我們來說最重要的測(cè)試是小型隨機(jī) IO 測(cè)試。

這些測(cè)試通過對(duì) OSD 增加壓力，從而確認(rèn) IO 的效率。

在這種情況下，我們總體上得到了相對(duì)較好的結(jié)果，但有幾點(diǎn)需要注意。

在 4K 隨機(jī)讀取方面，Reef 僅比 Quincy 慢一點(diǎn)點(diǎn)，但非常接近。

另一方面，我們看到 4K 隨機(jī)寫入測(cè)試有了一定的改進(jìn)，這主要是由于引入了新的 RocksDB 調(diào)優(yōu)。

不過，根據(jù)去年秋天的結(jié)果，我們并沒有看到像預(yù)期那樣大的性能提升。在隨機(jī)讀取測(cè)試中，每個(gè) OSD 的 CPU 使用率略高于 7 個(gè)內(nèi)核，而在隨機(jī)寫入測(cè)試中，Reef 的每個(gè) OSD 將近 11 個(gè)內(nèi)核。這似乎與 Quincy 的更高性能成正比。

在測(cè)試 Ceph 的小的隨機(jī)寫入性能的時(shí)，加入擁有無限 CPU 資源，那么 kv_sync_thread 則會(huì)成為瓶頸，但 CPU 的消耗主要發(fā)生在 OSD 工作線程和信使線程中，因 CPU 造成的性能瓶頸場(chǎng)景還是比較少的。

因此，最大化寫入性能是 OSD 數(shù)量、NVMe 速度、核心數(shù)量和核心速度之間的微妙平衡。

Reef 中的隨機(jī)寫入性能高于 Quincy，但沒有我們希望的那么高。這是為什么？

還有兩個(gè)額外的測(cè)試可能會(huì)提供一下原因。

就在我們凍結(jié) Reef 之前，我們升級(jí)到最新版本的 RocksDB，因?yàn)榕c我們?cè)?Quincy 中使用的舊版本相比有幾個(gè)重大錯(cuò)誤修復(fù)和改進(jìn)。

我們可以簡(jiǎn)單地還原該更改，然后看看 Reef 的表現(xiàn)如何。

我們還可以使用我們現(xiàn)在在 Reef 中作為標(biāo)準(zhǔn)使用的 RocksDB 調(diào)優(yōu)來運(yùn)行 Quincy，看看它能在多大程度上提高 Quincy 性能。

使用 Reef 調(diào)整在 v17.2.5 上運(yùn)行特別慢之外，但非常接近。

當(dāng)使用舊的 Quincy 版本的 RocksDB 編譯 Reef 時(shí)，似乎確實(shí)有一致的性能提升，盡管很?。▇2%）。

使用相同版本的 RocksDB 編譯的 Quincy 和 Reef 則保持一致。

在隨機(jī)寫入場(chǎng)景中，我們看到兩個(gè)非常有趣的結(jié)果。

一：當(dāng) Quincy 使用新的 RocksDB 調(diào)整默認(rèn)值編譯時(shí)，無論它使用哪個(gè)版本的 RocksDB，它實(shí)際上都比 Reef 快。

二：恢復(fù)到舊版本的 RocksDB 確實(shí)會(huì)帶來性能提升，但同樣非常?。▇1-2%）。它不能完全解釋當(dāng) Quincy 和 Reef 都使用新的 RocksDB 調(diào)優(yōu)時(shí)出現(xiàn)的回歸。

最終結(jié)果是 Reef 中很可能會(huì)出現(xiàn)小的回歸，從而影響小的隨機(jī)寫入。

4KB 順序同步寫入延遲

在過去的一年里，我們收到了很多關(guān)于 Ceph 寫入延遲的問題。

Ceph 可以進(jìn)行 sub-millisecond 寫入嗎？我們看到什么樣的尾延遲？

雖然我們過去對(duì)此進(jìn)行過測(cè)試，但我們現(xiàn)在決定也進(jìn)行一組快速的 4K 同步順序?qū)懭霚y(cè)試。需要注意的是，這是在一個(gè)有大量可用空間和幾乎零碎片的新集群上。

只有 1 個(gè)客戶端在 io_depth 為 1 的情況下進(jìn)行寫入。

這幾乎是展示 Ceph低延遲的理想場(chǎng)景。它不一定反映在有業(yè)務(wù)流量以及數(shù)據(jù)碎片的集群上的真實(shí)尾部延遲。

在這兩種情況下，Quincy 和 Reef 都能夠以低于 0.5 毫秒的延遲寫入絕大多數(shù) IO。

CBT 會(huì)為每次運(yùn)行保存 fio 延遲圖，因此我們也可以查看這些圖：

總體而言，結(jié)果非常一致，只有幾個(gè)異常值。

這里需要注意的是，在 fio 中測(cè)試 librbd 時(shí)，使用 O_SYNC 和 O_DSYNC 標(biāo)志可能沒有太大區(qū)別。

我們聯(lián)系了 Ilya Dryomov（Ceph 的 RBD 負(fù)責(zé)人）。他表示 librbd 或內(nèi)核 RBD 都不需要關(guān)心，因?yàn)檫@些是在 VFS 層處理的。我們應(yīng)該只在這些寫入在所有參與的 OSD 上完全持久化后才尋求 OSD 的確認(rèn)。無論如何，所有運(yùn)行的性能似乎都相當(dāng)。

在進(jìn)行這些單客戶端、io_depth=1 測(cè)試時(shí)，同時(shí)也需要關(guān)注一下網(wǎng)絡(luò)的延遲。我們?cè)诩褐械牟煌?jié)點(diǎn)之間進(jìn)行了一些 ping 測(cè)試。

注意：ping 是 ICMP 而不是 TCP，而且 ping 也是往返的。

從 mako01 ping mako10（100GbE 接口）：

在讀取的情況下，使用復(fù)制和使用 RBD 進(jìn)行測(cè)試時(shí)，Ceph 僅有從客戶端到主 OSD 的往返。

在寫入情況下，Ceph 必須進(jìn)行多次往返。1 個(gè)在客戶端和主節(jié)點(diǎn)之間，1 個(gè)在主節(jié)點(diǎn)和并行的每個(gè)輔助節(jié)點(diǎn)之間。

在寫測(cè)試中，我們應(yīng)該可以看到有負(fù)載的節(jié)點(diǎn)的 2 次往返的平均網(wǎng)絡(luò)延遲要更差。

因此，網(wǎng)絡(luò)延遲很可能在這些小型同步寫入測(cè)試中發(fā)揮重要作用（可能不是主導(dǎo)作用）。

Ceph 本身仍有改進(jìn)同步寫入延遲的空間，但是網(wǎng)絡(luò)延遲在這一點(diǎn)上是一個(gè)有效的問題，并且隨著 Ceph 本身的改進(jìn)將成為一個(gè)更大的因素。

結(jié)論

這篇文章也是非常關(guān)注底層硬件性能和固件更新對(duì) Reef 的影響。在進(jìn)行基準(zhǔn)測(cè)試時(shí)，了解底層硬件至關(guān)重要，如果我們沒有升級(jí)所有 SSD 驅(qū)動(dòng)器上的固件，我們會(huì)忽略掉很多東西（更高的寫入 IOPS?。?。

確保我們使用的固件是最新的，并且我們的硬件運(yùn)行狀態(tài)良好，然后再花一天時(shí)間運(yùn)行測(cè)試。

一旦硬件處于良好的狀態(tài)，Quincy 和 Reef 就會(huì)表現(xiàn)出差不多的性能。

兩者都實(shí)現(xiàn)了大約 71GB/s 的大型讀取和 25GB/s 的大型寫入以及 3X 復(fù)制。兩者還以大約 4.4-4.5M IOPS 實(shí)現(xiàn)了類似的 4KB 隨機(jī)讀取性能。

Reef 在小型隨機(jī)寫入方面比 Quincy 快 6-7%，這主要是由于新的 RocksDB 調(diào)整，但我們預(yù)計(jì)它會(huì)更快一些。

同時(shí)，可能還存在限制 Reef 實(shí)現(xiàn)更高性能的因素，我們后續(xù)將研究 Reef 凍結(jié)期間的潛在回歸，并繼續(xù)努力使 Reef 成為迄今為止最好的 Ceph 版本！