建站
咨詢
售后
建站咨詢
新聞中心
多年來我們遇到的最常見問題之一是用戶是否應(yīng)該在每個閃存驅(qū)動器上部署多個 OSD。這個問題比較復(fù)雜，因為隨著Ceph的發(fā)展，這個問題的答案也在不停的變化。早在 Ceph Nautilus 時代，我們通常建議每個閃存驅(qū)動器部署2 個甚至 4 個 OSD。當(dāng)時在每個閃存設(shè)備部署多個 OSD 時，特別是在使用 NVMe 驅(qū)動器時，會具有很明顯的性能優(yōu)勢。
但在 Octopus 和 Pacific 的發(fā)布周期中，這一問題的答案也開始發(fā)生變化。社區(qū)在 OSD 和 BlueStore 代碼中引入了多項性能改進，極大地提高了每個 OSD 的性能。隨著Pacific 版本的發(fā)布，我們也進行了各種測試，以確定我們的建議是否應(yīng)該改變。
圖片
正如預(yù)期的那樣，Octopus 和 Pacific 的速度明顯快于 Nautilus，但與每個 NVMe 2 個 OSD 與 1 個 OSD 相比，也不再表現(xiàn)出一致的性能增益。一些測試仍然顯示出一些增益，但其他測試則顯示出輕微的損失。然而，這些測試的范圍相當(dāng)有限。 CPU 資源的可用性是否會改變結(jié)果？在性能或資源消耗方面還有其他優(yōu)點或缺點嗎？最后，自 Pacific 以來，我們不斷改進 OSD 和 bluestore 代碼。下面我們將進行詳細驗證下。
集群設(shè)置
|
Nodes |
10 x Dell PowerEdge R6515 |
|
CPU |
1 x AMD EPYC 7742 64C/128T |
|
Memory |
128GiB DDR4 |
|
Network |
1 x 100GbE Mellanox ConnectX-6 |
|
NVMe |
6 x 4TB Samsung PM983 |
|
OS Version |
CentOS Stream release 8 |
|
Ceph Version |
Reef v18.2.0 (built from source) |
其中 5 個節(jié)點被配置為托管 OSD，其中 5 個節(jié)點被配置為客戶端節(jié)點。所有節(jié)點都位于同一臺 Juniper QFX5200 交換機上，并通過單個 100GbE QSFP28 鏈路進行連接。使用 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)在這方面似乎并不那么敏感，而且我還沒有確認 TuneD 實際上限制了 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 最多可以擴展至 20 個 CPU 線程。為了保持正確的內(nèi)存比率， osd_memory_target 在 1 OSD/NVMe 情況下設(shè)置為 16GB，在 2 OSD/NVMe 情況下設(shè)置為 8GB。 Numactl 用于控制每個 OSD 的 CPU 線程數(shù)。 OSD 被分配給兩個“處理器”池，試圖同時擴展物理核心和 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 線程進行測試。 FIO 配置為首先使用大量寫入預(yù)填充 RBD 卷，然后分別進行 60 秒的 4MB 和 4KB IO 測試。某些后臺進程（例如清理、深度清理、PG 自動縮放和 PG 平衡）被禁用。使用具有靜態(tài) 16384 PG（高于通常建議的值）和 3 倍復(fù)制的 RBD 池。
4MB吞吐量
圖片
圖片
當(dāng)開始此測試時，我們并沒有預(yù)料到每個 NVMe 設(shè)備有多個 OSD 對于大型 IO 工作負載會產(chǎn)生顯著的性能差異。對于讀取，差異相當(dāng)小，盡管 2 個 OSD 配置顯示出相當(dāng)一致的小優(yōu)勢。然而，對于寫入，我們驚訝地發(fā)現(xiàn)與單個 OSD 配置相比，吞吐量出現(xiàn)適度下降，峰值為每個 NVMe 12 個 CPU 線程。
圖片
這些是短期運行的測試，但在每個 CPU 計數(shù)樣本點重新創(chuàng)建集群，我們看到多個樣本的明顯趨勢。該效果可能是真實的，并且似乎與我們在 Octopus 和 Pacific 中看到的行為相匹配，其中 2 OSD/NVMe 配置中的 4MB 寫入吞吐量實際上較低。
4KB隨機IOPS
圖片
圖片
圖片
借助 Nautilus，我們在 4KB 隨機讀取和隨機寫入測試中看到了 2 個 OSD/NVMe 的顯著優(yōu)勢。在相同的硬件、相同的操作系統(tǒng)、相同的內(nèi)核版本并運行完全相同的測試時，我們看到了 Octopus 和 Pacific 的不同行為。我們不再擁有可用于這些 Reef 測試的相同硬件或操作系統(tǒng)，但我們看到的行為看起來更接近我們在之前的測試平臺上在 Pacific 中看到的情況。在每個 NVMe 驅(qū)動器上部署 2 個 OSD 并沒有特別的 IOPS 優(yōu)勢，除非每個 NVMe 驅(qū)動器有 16 個或更多 CPU 線程。事實上，對于每個 NVMe 有 2-4 個 CPU 線程的部署，IOPS 會受到輕微影響。這次測試有幾個直接的結(jié)論：
- 使用默認調(diào)整時，OSD 的擴展范圍不會超過每個 14-16 個 CPU 線程。
- 在高 CPU 線程數(shù)下，隨機讀取比隨機寫入更能從多個 OSD 中受益。
- 在 CPU 線程數(shù)較低的情況下，每個 NVMe 運行多個 OSD 會增加一定量的額外開銷。
但 IOPS 并不是唯一需要考慮的因素。延遲怎么樣？那么資源消耗呢？
4KB隨機延遲
圖片
圖片
圖片
在這些測試中，我們有 50 個 fio 客戶端進程運行，每個進程的 io_深度為 128。 Ceph 可以實現(xiàn)顯著較低的平均延遲，但在這種情況下，我們使 OSD 飽和到完全受 CPU 限制的程度。在這種情況下，延遲與 IOPS 成正比。
圖片
平均延遲減少遵循與我們在 IOPS 中看到的類似模式。在每個 NVMe 有 2 個 OSD 的低 CPU 線程數(shù)下，平均延遲稍差（較高），但在 CPU 線程數(shù)非常高時，平均延遲明顯更好（較低）。
4KB隨機99%尾部延遲
圖片
圖片
到目前為止，我們還沒有看到強有力的證據(jù)表明，除非 CPU 線程比率非常高，否則每個 NVMe 部署多個 OSD 具有顯著優(yōu)勢。但在一種情況下，我們?nèi)匀豢吹搅孙@著的優(yōu)勢。在幾乎所有情況下，每個 NVMe 運行多個 OSD 都能一致地減少尾部延遲。
99% Tail 延遲的改善非常顯著，在某些情況下，每個 NVMe 運行 2 個 OSD 可將 99% 延遲減少一半。雖然此處未顯示，但 99.9% 延遲的改進甚至更好。雖然對于每個 NVMe 運行多個 OSD 的大多數(shù) Reef 部署可能不會表現(xiàn)出顯著的性能優(yōu)勢，但它可能會表現(xiàn)出顯著的尾部延遲優(yōu)勢。但是……有代價嗎？
圖片
4KB隨機CPU使用率
圖片
圖片
圖片
盡管通過 numactl 將 OSD 限制為僅使用一定數(shù)量的 CPU 線程，但每個 NVMe 配置 2 個 OSD 始終比每個 NVMe 1 個 OSD 的情況使用更多的 CPU。讓我們進一步看看這如何轉(zhuǎn)化為 CPU 效率。
圖片
圖片
圖片
我們之前看到，兩種 OSD 配置在最多 16 個 CPU 線程時表現(xiàn)相似。此后，每個 NVMe 配置的 2 個 OSD 繼續(xù)擴展，而單個 OSD 配置則達到頂峰。我們還發(fā)現(xiàn)，每個 NVMe 配置 2 個 OSD 的尾部延遲顯著降低。在這里，我們看到每個 CPU 線程在每個 NVMe 配置的 2 個 OSD 中更加努力地工作，以實現(xiàn)相同的 IOPS，盡管還有其他優(yōu)勢。這可能會導(dǎo)致更高的功耗和更多的熱量產(chǎn)生。需要注意的是：此處報告的隨機寫入結(jié)果將復(fù)制因素納入其中，以與我們?nèi)ツ昵锾煸谶@里發(fā)布的太平洋地區(qū)結(jié)果相匹配。雖然測試配置與去年秋天并不完全相同，但看來我們在這些 Reef 測試中實現(xiàn)了適度的效率改進。
4KB隨機內(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ā)布，我們進行了更廣泛的分析，并注意到我們的測試系統(tǒng)的一些細微的優(yōu)點和缺點：
|
1 OSD per NVMe Pros |
2 OSDs per NVMe Pros |
|
+ Simpler Configuration |
+ Slightly Better Large Read Throughput |
|
+ Better Large Write Throughput |
+ Better IOPS when Very CPU Dense |
|
+ Slightly Better IOPS when CPU Starved |
+ Better Latency when Very CPU Dense |
|
+ Better CPU Efficiency |
+ Significantly Better Tail Latency |
|
+ Slightly Better Memory Usage |
其他硬件配置可能會根據(jù) CPU、閃存或其他性能特征顯示不同的縮放行為。不過，我相信這些結(jié)果應(yīng)該可以概括地說明在現(xiàn)代 Ceph 版本中每個 NVMe 配置運行 2 個 OSD 的潛在優(yōu)點和缺點。與往常一樣，最好的了解方法是測試一下自己，看看您的發(fā)現(xiàn)是否與我們在這里看到的相符。感謝您的閱讀，如果您有任何疑問或想更多地討論 Ceph 性能，請隨時與我們聯(lián)系。
原文： https://ceph.io/en/news/blog/2023/reef-osds-per-nvme/
當(dāng)前題目：Ceph-每個NVMe推薦安裝1個還是2個OSD？
網(wǎng)站URL：http://www.dlmjj.cn/article/ccdjepe.html
