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

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

圖片

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

集群設(shè)置

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

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

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

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

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

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

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

4MB吞吐量

圖片

圖片

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

圖片

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

4KB隨機(jī)IOPS

圖片

圖片

圖片

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

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

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

4KB隨機(jī)延遲

圖片

圖片

圖片

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

圖片

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

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

圖片

圖片

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

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

圖片

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

圖片

圖片

圖片

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

圖片

圖片

圖片

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

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

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

圖片

圖片

圖片

結(jié)論

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

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

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