多年來我們遇到的最常見問題之一是用戶是否應(yīng)該在每個閃存驅(qū)動器上部署多個 OSD。這個問題比較復(fù)雜，因?yàn)殡S著Ceph的發(fā)展，這個問題的答案也在不停的變化。早在 Ceph Nautilus 時代，我們通常建議每個閃存驅(qū)動器部署2 個甚至 4 個 OSD。當(dāng)時在每個閃存設(shè)備部署多個 OSD 時，特別是在使用 NVMe 驅(qū)動器時，會具有很明顯的性能優(yōu)勢。

但在 Octopus 和 Pacific 的發(fā)布周期中，這一問題的答案也開始發(fā)生變化。社區(qū)在 OSD 和 BlueStore 代碼中引入了多項(xiàng)性能改進(jìn)，極大地提高了每個 OSD 的性能。隨著Pacific 版本的發(fā)布，我們也進(jìn)行了各種測試，以確定我們的建議是否應(yīng)該改變。

圖片

正如預(yù)期的那樣，Octopus 和 Pacific 的速度明顯快于 Nautilus，但與每個 NVMe 2 個 OSD 與 1 個 OSD 相比，也不再表現(xiàn)出一致的性能增益。一些測試仍然顯示出一些增益，但其他測試則顯示出輕微的損失。然而，這些測試的范圍相當(dāng)有限。 CPU 資源的可用性是否會改變結(jié)果？在性能或資源消耗方面還有其他優(yōu)點(diǎn)或缺點(diǎn)嗎？最后，自 Pacific 以來，我們不斷改進(jìn) OSD 和 bluestore 代碼。下面我們將進(jìn)行詳細(xì)驗(yàn)證下。

集群設(shè)置

其中 5 個節(jié)點(diǎn)被配置為托管 OSD，其中 5 個節(jié)點(diǎn)被配置為客戶端節(jié)點(diǎn)。所有節(jié)點(diǎn)都位于同一臺 Juniper QFX5200 交換機(jī)上，并通過單個 100GbE QSFP28 鏈路進(jìn)行連接。使用 CBT 部署了 Ceph 并啟動了 FIO 測試。英特爾系統(tǒng)上一個重要的操作系統(tǒng)級別優(yōu)化是將 TuneD 配置文件設(shè)置為“延遲性能”或“網(wǎng)絡(luò)延遲”。這主要有助于避免與 CPU C/P 狀態(tài)轉(zhuǎn)換相關(guān)的延遲峰值。基于 AMD Rome 的系統(tǒng)在這方面似乎并不那么敏感，而且我還沒有確認(rèn) TuneD 實(shí)際上限制了 AMD 處理器上的 C/P 狀態(tài)轉(zhuǎn)換。盡管如此，對于這些測試，TuneD 配置文件仍設(shè)置為“網(wǎng)絡(luò)延遲”。

測試設(shè)置

安裝 Ceph 并配置CBT。通常，在測試 Ceph 時，通常會考慮內(nèi)核數(shù)量和分配給每個 OSD 的內(nèi)存。然而，在此測試中，最好考慮每個 NVMe 驅(qū)動器有多少 CPU 和內(nèi)存可用。這些系統(tǒng)中的每一個都可以輕松支持每個 NVMe 驅(qū)動器 16GB 內(nèi)存，并且每個 NVMe 最多可以擴(kuò)展至 20 個 CPU 線程。為了保持正確的內(nèi)存比率， osd_memory_target 在 1 OSD/NVMe 情況下設(shè)置為 16GB，在 2 OSD/NVMe 情況下設(shè)置為 8GB。 Numactl 用于控制每個 OSD 的 CPU 線程數(shù)。 OSD 被分配給兩個“處理器”池，試圖同時擴(kuò)展物理核心和 HT 核心。為此，使用以下 bash 單行代碼生成處理器到物理核心的映射：

paste <(cat /proc/cpuinfo | grep "core id") <(cat /proc/cpuinfo | grep "processor") | sed 's/[[:blank:]]/ /g'

這表明處理器 0-63 對應(yīng)于物理核心，處理器 64-127 對應(yīng)于 HT 核心。接下來，調(diào)用 numactl 來利用相同數(shù)量的物理處理器和 HT 處理器（在本文中，我們通常將其稱為 CPU 線程）。例如，要將 OSD 分配給由 12 個物理核心和 12 個 HT 核心組成的池（總共 24 個 cpu 線程，或每個 NVMe 4 個線程），則調(diào)用 OSD：

...numactl --physcpubind=0-12,64-76 /usr/local/bin/ceph-osd

每個 NVMe 驅(qū)動器使用 2 到 20 個 CPU 線程進(jìn)行測試。 FIO 配置為首先使用大量寫入預(yù)填充 RBD 卷，然后分別進(jìn)行 60 秒的 4MB 和 4KB IO 測試。某些后臺進(jìn)程（例如清理、深度清理、PG 自動縮放和 PG 平衡）被禁用。使用具有靜態(tài) 16384 PG（高于通常建議的值）和 3 倍復(fù)制的 RBD 池。

4MB吞吐量

圖片

圖片

當(dāng)開始此測試時，我們并沒有預(yù)料到每個 NVMe 設(shè)備有多個 OSD 對于大型 IO 工作負(fù)載會產(chǎn)生顯著的性能差異。對于讀取，差異相當(dāng)小，盡管 2 個 OSD 配置顯示出相當(dāng)一致的小優(yōu)勢。然而，對于寫入，我們驚訝地發(fā)現(xiàn)與單個 OSD 配置相比，吞吐量出現(xiàn)適度下降，峰值為每個 NVMe 12 個 CPU 線程。

圖片

這些是短期運(yùn)行的測試，但在每個 CPU 計(jì)數(shù)樣本點(diǎn)重新創(chuàng)建集群，我們看到多個樣本的明顯趨勢。該效果可能是真實(shí)的，并且似乎與我們在 Octopus 和 Pacific 中看到的行為相匹配，其中 2 OSD/NVMe 配置中的 4MB 寫入吞吐量實(shí)際上較低。

4KB隨機(jī)IOPS

圖片

圖片

圖片

借助 Nautilus，我們在 4KB 隨機(jī)讀取和隨機(jī)寫入測試中看到了 2 個 OSD/NVMe 的顯著優(yōu)勢。在相同的硬件、相同的操作系統(tǒng)、相同的內(nèi)核版本并運(yùn)行完全相同的測試時，我們看到了 Octopus 和 Pacific 的不同行為。我們不再擁有可用于這些 Reef 測試的相同硬件或操作系統(tǒng)，但我們看到的行為看起來更接近我們在之前的測試平臺上在 Pacific 中看到的情況。在每個 NVMe 驅(qū)動器上部署 2 個 OSD 并沒有特別的 IOPS 優(yōu)勢，除非每個 NVMe 驅(qū)動器有 16 個或更多 CPU 線程。事實(shí)上，對于每個 NVMe 有 2-4 個 CPU 線程的部署，IOPS 會受到輕微影響。這次測試有幾個直接的結(jié)論：

• 使用默認(rèn)調(diào)整時，OSD 的擴(kuò)展范圍不會超過每個 14-16 個 CPU 線程。
• 在高 CPU 線程數(shù)下，隨機(jī)讀取比隨機(jī)寫入更能從多個 OSD 中受益。
• 在 CPU 線程數(shù)較低的情況下，每個 NVMe 運(yùn)行多個 OSD 會增加一定量的額外開銷。

但 IOPS 并不是唯一需要考慮的因素。延遲怎么樣？那么資源消耗呢？

4KB隨機(jī)延遲

圖片

圖片

圖片

在這些測試中，我們有 50 個 fio 客戶端進(jìn)程運(yùn)行，每個進(jìn)程的 io_深度為 128。 Ceph 可以實(shí)現(xiàn)顯著較低的平均延遲，但在這種情況下，我們使 OSD 飽和到完全受 CPU 限制的程度。在這種情況下，延遲與 IOPS 成正比。

圖片

平均延遲減少遵循與我們在 IOPS 中看到的類似模式。在每個 NVMe 有 2 個 OSD 的低 CPU 線程數(shù)下，平均延遲稍差（較高），但在 CPU 線程數(shù)非常高時，平均延遲明顯更好（較低）。

4KB隨機(jī)99%尾部延遲

圖片

圖片

到目前為止，我們還沒有看到強(qiáng)有力的證據(jù)表明，除非 CPU 線程比率非常高，否則每個 NVMe 部署多個 OSD 具有顯著優(yōu)勢。但在一種情況下，我們?nèi)匀豢吹搅孙@著的優(yōu)勢。在幾乎所有情況下，每個 NVMe 運(yùn)行多個 OSD 都能一致地減少尾部延遲。

99% Tail 延遲的改善非常顯著，在某些情況下，每個 NVMe 運(yùn)行 2 個 OSD 可將 99% 延遲減少一半。雖然此處未顯示，但 99.9% 延遲的改進(jìn)甚至更好。雖然對于每個 NVMe 運(yùn)行多個 OSD 的大多數(shù) Reef 部署可能不會表現(xiàn)出顯著的性能優(yōu)勢，但它可能會表現(xiàn)出顯著的尾部延遲優(yōu)勢。但是……有代價(jià)嗎？

圖片

4KB隨機(jī)CPU使用率

圖片

圖片

圖片

盡管通過 numactl 將 OSD 限制為僅使用一定數(shù)量的 CPU 線程，但每個 NVMe 配置 2 個 OSD 始終比每個 NVMe 1 個 OSD 的情況使用更多的 CPU。讓我們進(jìn)一步看看這如何轉(zhuǎn)化為 CPU 效率。

圖片

圖片

圖片

我們之前看到，兩種 OSD 配置在最多 16 個 CPU 線程時表現(xiàn)相似。此后，每個 NVMe 配置的 2 個 OSD 繼續(xù)擴(kuò)展，而單個 OSD 配置則達(dá)到頂峰。我們還發(fā)現(xiàn)，每個 NVMe 配置 2 個 OSD 的尾部延遲顯著降低。在這里，我們看到每個 CPU 線程在每個 NVMe 配置的 2 個 OSD 中更加努力地工作，以實(shí)現(xiàn)相同的 IOPS，盡管還有其他優(yōu)勢。這可能會導(dǎo)致更高的功耗和更多的熱量產(chǎn)生。需要注意的是：此處報(bào)告的隨機(jī)寫入結(jié)果將復(fù)制因素納入其中，以與我們?nèi)ツ昵锾煸谶@里發(fā)布的太平洋地區(qū)結(jié)果相匹配。雖然測試配置與去年秋天并不完全相同，但看來我們在這些 Reef 測試中實(shí)現(xiàn)了適度的效率改進(jìn)。

4KB隨機(jī)內(nèi)存使用

雖然每個 NVMe 案例的 2 個 OSD 中的 CPU 使用率顯著增加，但內(nèi)存使用率的增加相對較小。通常，與每個 NVMe 使用 1 個 OSD 相比，會有大約 3-6% 的損失。兩種配置均未使用此數(shù)據(jù)集大小的 OSD 可用的全部內(nèi)存量。

圖片

圖片

圖片

結(jié)論

之前我們看到，在 Ceph 的 Nautilus 版本和 Pacific 版本之間，每個 NVMe 使用多個 OSD 的性能優(yōu)勢發(fā)生了顯著變化。現(xiàn)在 Reef 已經(jīng)發(fā)布，我們進(jìn)行了更廣泛的分析，并注意到我們的測試系統(tǒng)的一些細(xì)微的優(yōu)點(diǎn)和缺點(diǎn)：

其他硬件配置可能會根據(jù) CPU、閃存或其他性能特征顯示不同的縮放行為。不過，我相信這些結(jié)果應(yīng)該可以概括地說明在現(xiàn)代 Ceph 版本中每個 NVMe 配置運(yùn)行 2 個 OSD 的潛在優(yōu)點(diǎn)和缺點(diǎn)。與往常一樣，最好的了解方法是測試一下自己，看看您的發(fā)現(xiàn)是否與我們在這里看到的相符。感謝您的閱讀，如果您有任何疑問或想更多地討論 Ceph 性能，請隨時與我們聯(lián)系。

原文： https://ceph.io/en/news/blog/2023/reef-osds-per-nvme/