多年來我們遇到的最常見問題之一是用戶是否應該在每個閃存驅動器上部署多個 OSD。這個問題比較復雜，因為隨著Ceph的發展，這個問題的答案也在不停的變化。早在 Ceph Nautilus 時代，我們通常建議每個閃存驅動器部署2 個甚至 4 個 OSD。當時在每個閃存設備部署多個 OSD 時，特別是在使用 NVMe 驅動器時，會具有很明顯的性能優勢。

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

圖片

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

集群設置

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

測試設置

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

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

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

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

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

4MB吞吐量

圖片

圖片

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

圖片

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

4KB隨機IOPS

圖片

圖片

圖片

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

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

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

4KB隨機延遲

圖片

圖片

圖片

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

圖片

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

4KB隨機99%尾部延遲

圖片

圖片

到目前為止，我們還沒有看到強有力的證據表明，除非 CPU 線程比率非常高，否則每個 NVMe 部署多個 OSD 具有顯著優勢。但在一種情況下，我們仍然看到了顯著的優勢。在幾乎所有情況下，每個 NVMe 運行多個 OSD 都能一致地減少尾部延遲。

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

圖片

4KB隨機CPU使用率

圖片

圖片

圖片

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

圖片

圖片

圖片

我們之前看到，兩種 OSD 配置在最多 16 個 CPU 線程時表現相似。此后，每個 NVMe 配置的 2 個 OSD 繼續擴展，而單個 OSD 配置則達到頂峰。我們還發現，每個 NVMe 配置 2 個 OSD 的尾部延遲顯著降低。在這里，我們看到每個 CPU 線程在每個 NVMe 配置的 2 個 OSD 中更加努力地工作，以實現相同的 IOPS，盡管還有其他優勢。這可能會導致更高的功耗和更多的熱量產生。需要注意的是：此處報告的隨機寫入結果將復制因素納入其中，以與我們去年秋天在這里發布的太平洋地區結果相匹配。雖然測試配置與去年秋天并不完全相同，但看來我們在這些 Reef 測試中實現了適度的效率改進。

4KB隨機內存使用

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

圖片

圖片

圖片

結論

之前我們看到，在 Ceph 的 Nautilus 版本和 Pacific 版本之間，每個 NVMe 使用多個 OSD 的性能優勢發生了顯著變化?，F在 Reef 已經發布，我們進行了更廣泛的分析，并注意到我們的測試系統的一些細微的優點和缺點：

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

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