建站
咨詢
售后
建站咨詢
新聞中心
最近，ceph subreddit上的一位用戶提了一個問題：在一個由 6 個節(jié)點組成，每個節(jié)點有 2 個 4GB FireCuda NVMe 磁盤的集群中，Ceph是否可以為單個客戶端提供10K IOPs的組合隨機讀/寫能力。該用戶也想知道是否有人對類似的場景進行過測試并希望能夠共享一下測試結(jié)果。在 Clyso 項目組中，我們一直在積極努力改進 Ceph 代碼以實現(xiàn)更高的性能。我們有自己的測試和配置來評估我們對代碼的更改。正好，我們當(dāng)前有可以匹配該用戶測試場景的硬件環(huán)境。因此，我們決定花些時間來進行測試以及驗證。
用戶環(huán)境配置
用戶的環(huán)境包含6個節(jié)點，每個節(jié)點都有2個4TB希捷FireCuda NVMe驅(qū)動器和64GB內(nèi)存。關(guān)于CPU或網(wǎng)絡(luò)，當(dāng)前沒有明確的信息。但兩者都對這次測試可能很重要。因此，我們使用如下的 fio 命令來實現(xiàn)這一需求：
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=150G --readwrite=randrw --rwmixread=75雖然我們的實驗室中沒有FireCuda驅(qū)動器，但我們確實有節(jié)點具有多個4TB三星PM983驅(qū)動器和每個128GB內(nèi)存。
群集配置
|
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 1 |
Pacific v16.2.13 (built from source) |
|
Ceph Version 2 |
Quincy v17.2.6 (built from source) |
|
Ceph Version 3 |
Reef v18.1.0 (built from source) |
為了盡可能匹配用戶的環(huán)境，我們只使用了集群中的 6 個節(jié)點，其中 2 個 OSD 在單個 NVMe 驅(qū)動器上運行，每個 OSD 用于 Ceph。其余節(jié)點用作客戶端節(jié)點。所有節(jié)點都位于同一Juniper QFX5200 交換機上，并通過單個 100GbE QSFP28 連接。
下面將先部署好 Ceph，并使用 CBT 啟動 FIO 測試。基于Intel的系統(tǒng)上一項重要的操作系統(tǒng)級別優(yōu)化是將 TuneD 配置文件設(shè)置為“延遲性能”或“網(wǎng)絡(luò)延遲”。這主要有助于避免與 CPU C/P 狀態(tài)轉(zhuǎn)換相關(guān)的延遲峰值?；贏MD的系統(tǒng)在這方面并沒有太大效果，目前還沒有確認調(diào)優(yōu)是否限制了C/P狀態(tài)轉(zhuǎn)換，但是對于這些測試，調(diào)優(yōu)后的配置文件仍然設(shè)置為“網(wǎng)絡(luò)延遲”。
測試設(shè)置
用戶的環(huán)境包含6個節(jié)點，每個節(jié)點都有2個4TB希捷
CBT 需要修改幾個配置，而不使用是默認的配置來部署 Ceph。每個 OSD 分配 8GB 內(nèi)存（這是合理的，因為用戶的節(jié)點有 64GB 內(nèi)存用于 2 個 OSD）。RBD 卷與 Msgr V1 配合一起使用，并且 cephx 被禁用。
FIO 會先用大寫入預(yù)填充 RBD 卷，然后進行用戶的隨機讀/寫測試。某些后臺進程（如scrub, deep scrub, pg autoscaling, 以及 pg balancing）已禁用。PG 以及 PGP 設(shè)置為4096 （高于通常推薦的）和 3 副本的 RBD 池。用戶僅請求單個 FIO 卷和使用單個 150GB 文件的測試。我們按照要求對此進行了測試，但為了讓集群處于負載狀態(tài)，還運行了 16 個獨立的 FIO 進程的測試，這些進程寫入分布在 4 個客戶端節(jié)點上的專用 RBD 卷，每個卷都有一個 16GB 的文件。 為了保證與用戶的FIO設(shè)置一致，必須將 gtod_reduce 選項的支持添加到cbt的FIO基準測試工具中。 gtod_reduce 可以通過顯著減少 FIO 必須進行的 getTimeOfDay（2） 調(diào)用次數(shù)來提高性能， 但它也禁用了某些功能， 例如在測試期間收集操作延遲信息。為了評估影響，我們在啟用和禁用的情況下 gtod_reduce運行了測試：
根據(jù)結(jié)果，我們決定保持 gtod_reduce 禁用狀態(tài)，以便我們也可以觀察延遲數(shù)據(jù)。請注意，啟用此 FIO 選項可以提高大約 3-4%性能。除此之外，所有其他選項要么在CBT中可用，要么在FIO中已經(jīng)默認。CBT YAML 文件的基準測試部分包含單客戶端測試的配置內(nèi)容如下：
benchmarks:
fio:
client_endpoints: 'fiotest'
op_size: [4096]
iodepth: [64]
size: 153600 # data set size per fio instance in KB
mode: ['randrw']
rwmixread: 75
procs_per_endpoint: [1]
osd_ra: [4096]
log_avg_msec: 100
cmd_path: '/usr/local/bin/fio'最終，我們實現(xiàn)了與用戶類似的FIO測試案例，但還有一些差異，主要與在測試過程中記錄iops/延遲數(shù)據(jù)有關(guān)：
fio --ioengine=libaio --direct=1 --bs=4096 --iodepth=64 --rw=randrw --rwmixread=75 --rwmixwrite=25 --size=153600M --numjobs=1 --name=/tmp/cbt/mnt/cbt-rbd-kernel/0/`hostname -f`-0-0 --write_iops_log=/tmp/cbt/00000000/Fio/output.0 --write_bw_log=/tmp/cbt/00000000/Fio/output.0 --write_lat_log=/tmp/cbt/00000000/Fio/output.0 --log_avg_msec=100 --output-format=json,normal > /tmp/cbt/00000000/Fio/output.0單客戶端和多客戶端IOPS
Ceph 不僅能夠在這種混合工作負載中實現(xiàn) 10K IOPS，而且在單個客戶端測試中速度提高了一個數(shù)量級。針對這個小型 12 OSD 集群，我們從單個客戶端實現(xiàn)了大約 92K 的隨機讀取和 31K 的隨機寫入 IOPS。
另外，我們也運行多客戶端測試的原因是為了展示這個小集群在為其他客戶端提供服務(wù)時有多少空間。在相同的混合工作負載和 16 個客戶端下，我們僅用 12 個支持 NVMe 的 OSD 就實現(xiàn)了超過 500K 的隨機讀取和大約 170K 的隨機寫入 IOPS。在多客戶端測試中，Qunicy 和 Reef 的性能優(yōu)勢分別比 Pacific 高出大約 6% 和 9%。啟用gtod_reduce可將 性能再提高 3-4%。
單客戶端和多客戶端CPU使用率
根據(jù)以往的測試，我們可以發(fā)現(xiàn)一個明顯的問題：CPU不足導(dǎo)致NVME的性能無法充分發(fā)揮。為了滿足單個客戶端工作負載，每個 OSD 大約消耗 3-4 個 AMD EPYC 內(nèi)核。為了滿足多客戶端工作負載的需求，每個 OSD 消耗大量 11-12 個內(nèi)核！IE 即使每個節(jié)點只有 2 個 OSD，每個節(jié)點也需要一個 24 核 EPYC 處理器才能實現(xiàn)這些驅(qū)動器的最大性能。更快的驅(qū)動器可能需要更大/更快的處理器。什么進程使用了所有這些 CPU？ 在以前的文章中，我們得出過如下的結(jié)論：
|
Name |
Count |
|
OSD Worker Threads |
16 |
|
Async Messenger Threads |
3 |
|
Bluestore KV Sync Thread |
1 |
|
Bluster "Finisher" Thread |
1 |
在某些情況下，RocksDB 壓縮線程也會定期使用 CPU 資源。BlueStore KV Sync 線程很容易成為小型隨機寫入的瓶頸，尤其是在使用較低性能的 CPU 時。但是，總體 CPU 消耗主要是在 OSD 工作線程和異步信使線程中完成的工作的結(jié)果。這是 crc 檢查、編碼/解碼、內(nèi)存分配等的組合。
單客戶端和多客戶端cycles/OP
由于cycles/OP 解析代碼中的錯誤，先前的cycles/OP 計數(shù)顯著增加。這使得 OSD 的效率似乎比實際要低得多。因此，我們計算性能指標(biāo)的時候，需要使用聚合平均 CPU 消耗和 IOPS 而不是聚合周期和 OPS ，校正后的數(shù)值已被驗證在預(yù)期的 ~14-17% 以內(nèi)。我們認為，剩余的差異主要是由于cpu速度隨時間的變化，以及 collectl 報告的 CPU 消耗方式。
在單客戶端和多客戶端測試中，性能似乎略有提高。另外，在多客戶端測試中，我們發(fā)現(xiàn)在高負載下處理數(shù)據(jù)的效率要高得多，而在單客戶端測試中，我們在低負載下處理數(shù)據(jù)的效率要高得多。
為什么會這樣呢？在上一節(jié)中，我們討論了 OSD 中的大部分工作如何由 OSD 工作線程和異步信使線程完成。當(dāng) OSD 收到新 IO 時，首先由與相應(yīng)網(wǎng)絡(luò)連接關(guān)聯(lián)的異步信使線程處理并移動到用戶空間中。然后將其放入給定 OSD 分片的計劃程序工作隊列中。如果隊列之前為空，則與該分片關(guān)聯(lián)的所有線程都會喚醒，并且在分片的工作隊列為空之前不會返回睡眠狀態(tài)。當(dāng)只有 1 個客戶端執(zhí)行 IO 時，集群上的負載會明顯減少，并且每個分片的隊列通常會在短時間內(nèi)為空。線程會不斷喚醒并重新進入睡眠狀態(tài)。當(dāng)群集負載較重時，隊列更有可能有工作要做，因此線程花費更少的睡眠和喚醒時間。相反，他們花更多的時間做實際工作。
單客戶端和多客戶端平均延遲
在單客戶端測試中，Ceph 能夠保持亞毫秒級的平均讀取和寫入延遲。在多客戶端測試中，我們看到了Pacific，Quincy和Reef之間的不同行為。Pacific的讀取延遲最低，寫入延遲最高，而Reef的讀取延遲略有增加，但寫入延遲顯著降低。Quincy的介于兩者之間，但更接近Reef而不是Pacific。
單客戶端和多客戶端99.9%延遲
正如預(yù)期的那樣，99.9% 的延遲略高。我們可以實現(xiàn)不到 1.3 毫秒的讀取和大約 2.1-2.3 毫秒的寫入，具體取決于版本。多客戶端測試中的尾部延遲明顯更高，但是在此測試中，Quincy 尤其是 Reef 的寫入尾部延遲明顯低于 Pacific。
結(jié)論
那么我們最后是怎么做的呢？目標(biāo)是在這個混合讀/寫 FIO 工作負載中達到 10K IOPS，讀取率為 75%，寫入率為 25%。我假設(shè)這意味著目標(biāo)是 7500 個讀取 IOPS 和 2500 個寫入 IOPS。讓我們比較一下我們是如何做到的：
Single-Client IOPS: 單客戶端 IOPS：
|
Release |
Read Goal |
Read IOPS |
Improvement |
Write Goal |
Write IOPS |
Improvement |
|
v16.2.13 |
7500 |
88540 |
11.8X |
2500 |
30509 |
12.2X |
|
v17.2.6 |
7500 |
89032 |
11.9X |
2500 |
30644 |
12.3X |
|
v18.1.0 |
7500 |
89669 |
12.0X |
2500 |
30940 |
12.4X |
多客戶端 IOPS：
|
Release |
Read Goal |
Read IOPS |
Improvement |
Write Goal |
Write IOPS |
Improvement |
|
v16.2.13 |
7500 |
490773 |
65.4X |
2500 |
163649 |
65.5X |
|
v17.2.6 |
7500 |
521475 |
69.5X |
2500 |
173887 |
69.6X |
|
v18.1.0 |
7500 |
535611 |
71.4X |
2500 |
178601 |
71.4X |
目前，我們完成了所有的測試，同時也滿足了要求！另外，如果使用更快的 NVMe 驅(qū)動器，結(jié)果應(yīng)該可以進一步改善。
當(dāng)前標(biāo)題：Ceph使用NVME是否可以實現(xiàn)10k混合IOPS？
標(biāo)題路徑：http://m.fisionsoft.com.cn/article/djigdjh.html
