建站
咨詢
售后
建站咨詢
新聞中心
介紹
通常情況下，Ceph 的整體性能還是不錯(cuò)的，大量的場(chǎng)景優(yōu)化為 Ceph 集群提供了可靠的性能保障。但是，很少有人知道 Ceph 當(dāng)前并沒有充分發(fā)揮出硬件的性能，也就說集群的性能與硬件的性能并不是呈線性增長(zhǎng)的。
專注于為中小企業(yè)提供成都做網(wǎng)站、網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)天津免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動(dòng)了近1000家企業(yè)的穩(wěn)健成長(zhǎng)，幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
目前，我們正在進(jìn)行多種方法來優(yōu)化 Ceph 的數(shù)據(jù)路徑，但現(xiàn)實(shí)情況是 Ceph 一直都是需要相當(dāng)多的 CPU 才能充分發(fā)揮出比如像 NVMe 這樣高速存儲(chǔ)設(shè)備的性能。
之前，一位用戶向我們提出了對(duì)低 CPU Core 下性能的擔(dān)憂。我們給出的建議是，在使用 NVMe 磁盤時(shí)，可以為每個(gè) OSD 分配 2 個(gè) CPU Core 。我們并沒有去解釋原因。最終，用戶購買了相應(yīng)的硬件服務(wù)器，且服務(wù)器只插了一半的 NVMe 磁盤（即每個(gè) OSD 有 4 個(gè)CPU Core 可用）。正常情況下，該配置的性能是可以接受的。但用戶依然比較關(guān)心當(dāng)服務(wù)器插滿所有的 NVMe 磁盤時(shí)候，性能是否有影響。
遺憾的是，我們不得不告訴他們，添加更多磁盤后，他們很可能只會(huì)看到容量增加，而不是性能增加。但我們的建議并非完全沒有價(jià)值。如果用戶不關(guān)心小型隨機(jī) IO 的性能，則每個(gè) OSD 2 個(gè) CPU Core 可能是一個(gè)很好的推薦。除了提高小型隨機(jī) IO 性能之外，在 NVMe 磁盤運(yùn)行 Ceph 還有很多好處。然而，對(duì)于該用戶來說，小型隨機(jī) IO 是必須要關(guān)注的，而這恰恰是 CPU 資源最重要的情況。
所以不得不告訴他們，在增加磁盤后，他們很可能只會(huì)看到容量增加，而不是性能的增加。
遺憾的是，這不是第一次出現(xiàn)這個(gè)問題，并且該問題依然有很多困擾點(diǎn)。2 年前，我們更新了上游 Ceph 文檔，試圖在 PR (https://github.com/ceph/ceph/pull/32093 ) 中提供更好的案例。當(dāng)時(shí)，我們的推薦場(chǎng)景要求如下：
- 1 core per 200-500 MB/s
- 1 core per 1000-3000 IOPS
不過這里最重要的方面是 IOPS 性能。本文將重點(diǎn)介紹 Ceph 小型隨機(jī) IOPS 性能如何隨著 CPU 資源的增加而擴(kuò)展。
集群配置
|
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 |
Pacific V16.2.9 (built from source) |
所有節(jié)點(diǎn)通過 100GbE QSFP28 連接到同一臺(tái) Juniper QFX5200 交換機(jī)上。安裝集群并使用 CBT (https://github.com/ceph/cbt/) 執(zhí)行 fio 測(cè)試。除非單獨(dú)說明，否則每個(gè)節(jié)點(diǎn)都配置為最多 6 個(gè) OSD，并使用 4 個(gè) fio 進(jìn)程使用 librbd 進(jìn)行測(cè)試。
英特爾系統(tǒng)上一個(gè)重要的操作系統(tǒng)級(jí)優(yōu)化是將調(diào)整后的配置文件設(shè)置為 “l(fā)atency-performance” 或 “network-latency”。這主要有助于避免與 CPU C/P 狀態(tài)轉(zhuǎn)換相關(guān)的延遲峰值?；?AMD Rome 的系統(tǒng)在這方面似乎不那么敏感，但是為這些測(cè)試調(diào)整的配置文件仍然設(shè)置為 “network-latency”。
測(cè)試配置
基于 CBT 測(cè)試的 Ceph 集群有幾個(gè)配置需要修改。首先，禁用 rbd 緩存，為每個(gè) OSD 分配 8GB 內(nèi)存，并在禁用 cephx 的情況下使用 msgr V1。在最近的測(cè)試中，我們發(fā)現(xiàn)使用默認(rèn) cephx 身份驗(yàn)證的 Msgr V2 似乎結(jié)果與使用 Msgr V1 一樣，盡管啟用加密可能會(huì)導(dǎo)致高達(dá) 30-40% 的性能損失，并且兩臺(tái)服務(wù)器和客戶端上的 CPU 使用率相近甚至更高。
首先通過 Fio 預(yù)寫入填充 RBD 卷，然后是循環(huán) 3 次 4K 隨機(jī)讀取，接下來是 iodepth=128 的 4K 隨機(jī)寫入，每次持續(xù) 5 分鐘。CBT 允許 OSD 與其他工具或環(huán)境變量一起工作，numactl 用于控制 OSD 可以在系統(tǒng)上使用多少 CPU Core。初始測(cè)試使用單個(gè) OSD 和 1 副本進(jìn)行。多 OSD 測(cè)試是使用多個(gè) OSD 和 3 副本進(jìn)行的。
單個(gè) OSD 測(cè)試
在多集群上，ceph 以偽隨機(jī)算法實(shí)現(xiàn)數(shù)據(jù)分布存儲(chǔ)。不同的 OSD 承載的熱點(diǎn)數(shù)據(jù)是不同的。有些 OSD 可能比其他 OSD 承受更多的壓力，因此總體性能可能也會(huì)受到影響。最終，我們可以看到 Ceph 集群的性能是受到集群中最慢 OSD 性能的限制（木桶原理——最短的木片決定木桶的容量）。
針對(duì)單個(gè) OSD 的測(cè)試可以避免這種問題，同時(shí)也進(jìn)一步消除了額外的復(fù)制延遲和開銷，確保 OSD 以最高效率工作。測(cè)試單個(gè) OSD 并不能代表整個(gè)集群的性能，但它確實(shí)展示了對(duì)應(yīng)的 OSD 在最佳條件下的性能。
這里首先要注意的是，CPU 在 2 到 4 Core 之間，性能大約提高了 100%。這幾乎是線性增加。但是在 4 個(gè) CPU Core 之后，增加開始放緩。從 4 個(gè) CPU Core 增加到 16 個(gè) CPU Core 僅產(chǎn)生 100% 的性能增長(zhǎng)，在 10 個(gè) CPU Core 時(shí)增長(zhǎng)幾乎完全趨于平穩(wěn)。不過，寫入性能會(huì)更高，在 14-16 個(gè) CPU Core 時(shí)最高可達(dá) 350% 左右。但是在測(cè)試中 Ceph OSD 是否真的使用了所有這些被分配的 CPU Core 嗎？
事實(shí)證明，為 OSD 分配更多 CPU Core 可以持續(xù)提高性能，最多可達(dá) 14-16 Core，但在 CPU 高 Core 數(shù)時(shí)，OSD 不會(huì)使用所有 Core。對(duì)于讀取尤其如此。更多的 CPU Core 意味著更高的性能，但效率會(huì)隨著您的提升而降低。然而，使用的每個(gè) CPU Core 的 IOPS 仍然相對(duì)平穩(wěn)。
為什么會(huì)這樣，限制是什么？默認(rèn)情況下，Ceph OSD 每個(gè) OSD 有 80 多個(gè)線程，但從資源消耗的角度來看，最重要的是：
- 16 個(gè) OSD 工作線程（8 個(gè)分片，每個(gè)分片有 2 個(gè)線程）
- 3 個(gè)異步消息線程
- 1 個(gè) bluestore key/value 線程
- 1 個(gè) bluestore “finisher” 線程
- RocksDB flush（高優(yōu)先級(jí)）和compaction（低優(yōu)先級(jí)）后臺(tái)線程
此處無需深入了解細(xì)節(jié)（我們將在稍后的文章中討論），常用 OSD 的實(shí)際最大 CPU Core 使用率可能約為 23 個(gè) Core。我們?cè)趯?shí)驗(yàn)中， 5 分鐘內(nèi)測(cè)試下來的最高使用率是 4K 隨機(jī)寫入大約 占用18-19 Core，對(duì) OSD 沒有限制并且禁用了 RocksDB 的預(yù)寫日志。那么為什么我們?cè)谶@些測(cè)試中看不到呢？可能的答案是 ceph 根本無法讓所有 16 個(gè)工作線程一直處于忙碌狀態(tài)。工作線的等待時(shí)間是很短的。雖然一個(gè) OSD 平均可能使用 6 或 8 Core，但當(dāng)它可以在短時(shí)間內(nèi)爆發(fā)到 16 個(gè)以上的 Core 數(shù)時(shí)，它可能表現(xiàn)最佳，而其他時(shí)候它可能只需要 3-4 個(gè) CPU Core。
60 個(gè) OSD 集群測(cè)試
在部署完整集群時(shí)是否會(huì)出現(xiàn)在單個(gè) OSD 測(cè)試中觀察到的趨勢(shì)？
在查看 60 OSD 集群測(cè)試結(jié)果時(shí)，有幾個(gè)結(jié)果是很明顯的。雖然曲線看起來類似于單個(gè) OSD 測(cè)試，但性能最高時(shí)每個(gè) OSD 大約 8-10 Core 用于讀取，每個(gè) OSD 大約 12 Core 用于寫入。在單個(gè) OSD 測(cè)試中，讀取和寫入增益分別達(dá)到約 200% 和 350%。在完整集群配置中，增益達(dá)到 100% 和 250%。
簡(jiǎn)單地看一下 OSD.0，看起來更大規(guī)模集群中的 OSD 在隨機(jī)讀取測(cè)試中使用的 Core 更少。同時(shí)，分配的每個(gè) Core 的 IOPS 和使用的每個(gè) Core 的 IOPS 數(shù)量也低得多。在寫入端，現(xiàn)在使用 3 副本。為了能夠與單個(gè) OSD 測(cè)試進(jìn)行比較，我們必須確認(rèn) OSD 的 IOPS 并考慮復(fù)制因素。即使這樣做，每個(gè) Core 的寫入性能也比單個(gè) OSD 測(cè)試低很多。
在讀取方面，Ceph 為每 Core 提供大約 7500 IOPS，并且根據(jù)分配給 OSD 的 Core 數(shù)量，每個(gè) Core 分配的 IOPS 從 2400 到 8500 不等。在寫入端，Ceph 為每個(gè)使用的 Core 提供大約 3500 IOPS，每個(gè)分配的 Core 提供 1600 到 3900 IOPS 。這些結(jié)果比我們 2 年前結(jié)果要好一些，我們?cè)谧罱?Quincy 版本中進(jìn)行了進(jìn)一步的改進(jìn)。
單 OSD 與多 OSD NVMe 性能對(duì)比
另一個(gè)經(jīng)常出現(xiàn)的問題是 Ceph 如何很好地利用 NVMe 磁盤。通常的測(cè)試方式是直接從本地連接的驅(qū)磁盤寫入或讀取數(shù)據(jù)。
用戶想知道為什么 Ceph 在有大量磁盤的情況下，速度依然慢。簡(jiǎn)單點(diǎn)說，Ceph 確實(shí)比直接寫入磁盤是要慢的，原因有很多。主要的原因如下：
- 計(jì)算 crush placement、校驗(yàn)和、加密、糾刪碼、網(wǎng)絡(luò)開銷等帶來的延遲。
- 處理數(shù)據(jù)（編碼/解碼/等）并在線程甚至 RocksDB 之間分配/復(fù)制/移動(dòng)內(nèi)存中的數(shù)據(jù)。
- Ceph 不只是寫入數(shù)據(jù)，還會(huì)寫出關(guān)于該數(shù)據(jù)的元數(shù)據(jù)。這在執(zhí)行小型寫入時(shí)是很重要的。
- 允許線程在沒有任務(wù)時(shí)進(jìn)入休眠狀態(tài)，并在任務(wù)到來時(shí)喚醒它們。這樣做是為了減少低負(fù)載期間的 CPU 開銷，但是當(dāng)線程進(jìn)入休眠和喚醒太快時(shí)它會(huì)對(duì)性能產(chǎn)生重大影響。
如果不做任何調(diào)整與優(yōu)化，其中一些問題是很難改進(jìn)的。Ceph 很容易受到網(wǎng)絡(luò)的性能影響（盡管 dpdk 之類的優(yōu)化可以提供些幫助）。Crush 確定數(shù)據(jù)的分布時(shí)也會(huì)帶來一些延遲，并且總會(huì)有一些由 crc32、編碼/解碼等引起的額外延遲。話雖如此，單 OSD 和多 OSD 之間存在非常大的性能差異—— OSD 測(cè)試。
上述的圖表可能有些粗糙。盡管 60 個(gè) OSD 的集群提供了大約 200 萬次隨機(jī)讀取 IOPS，但單獨(dú)的 OSD 能夠以更高的效率提供近 4 倍于每個(gè) NVMe 的性能。在寫入方面，情況更接近一些，但單個(gè) OSD 仍然比每個(gè) NVMe 快大約 2 倍。在 Ceph Quincy 中，我們努力提高寫路徑性能。在 Ceph Quincy 版本的改進(jìn)和選擇性 RocksDB 調(diào)整之間，我們?cè)谕暾?60 個(gè) OSD 集群上實(shí)現(xiàn)了超過 40% 的 4K 隨機(jī)寫入 IOPS 改進(jìn)。
要了解我們是如何獲得這些結(jié)果的，請(qǐng)?jiān)诖颂幉榭?RocksDB 調(diào)優(yōu)深入研究文章 (https://ceph.io/en/news/blog/2022/rocksdb-tuning-deep-dive/)。
結(jié)論
最終，我們可以看到，在集群級(jí)別和 OSD 內(nèi)部實(shí)現(xiàn)更高性能還是有很大空間的。
在以后的博文中，我們將深入探討一些在低 CPU Core 數(shù)和高 CPU Core 數(shù)下限制性能的問題，以及一些如何進(jìn)一步改進(jìn) Ceph 性能的想法。在此之前，每個(gè) OSD 分配多少個(gè) CPU Core 是需要權(quán)衡取舍的。為每個(gè) OSD 分配 2-4 個(gè)CPU Core，Ceph 可以在小型讀取和小型寫入期間可充分使用所有 CPU Core。當(dāng)分配更多的的CPU Core 數(shù)（甚至每個(gè) OSD 最多 16+）時(shí)，是可以提高性能，但每添加一個(gè) CPU Core 的增益就會(huì)降低。
正常情況下，OSD 能夠正常穩(wěn)定使用 CPU Core，但是當(dāng) OSD 分配了更高的CPU Core數(shù)量時(shí)，OSD 則無法充分使用每個(gè) CPU Core。也就是說支出并不能帶來同等的收益。因此需要綜合考量 Ceph 硬件架構(gòu)設(shè)計(jì)以及軟件資源上的架構(gòu)設(shè)計(jì)的支出與收益。
最后，這篇文章是基于 Ceph Pacific 版本的，通過調(diào)優(yōu)后， Ceph 的性能有所提高。另外，我們需要注意，如果是使用Ceph Quincy 版本的話，結(jié)果可能有些差異。當(dāng)前測(cè)試也是在一個(gè)新集群上進(jìn)行的，如果是在一個(gè)運(yùn)行時(shí)間比較長(zhǎng)的舊的集群可能結(jié)果也是不一樣的。不過，本文至少為 CPU 是如何影響基于 NVMe OSD 性能提供一個(gè)思路。
*原文鏈接：Ceph.io — Ceph OSD CPU Scaling - Part (https://ceph.io/en/news/blog/2022/ceph-osd-cpu-scaling/) 推薦閱讀
當(dāng)前標(biāo)題：CephOSDCPU性能優(yōu)化之一
標(biāo)題路徑：http://www.5511xx.com/article/dhohieo.html
