最近，ceph subreddit上的一位用戶提了一個(gè)問題：在一個(gè)由 6 個(gè)節(jié)點(diǎn)組成，每個(gè)節(jié)點(diǎn)有 2 個(gè) 4GB FireCuda NVMe 磁盤的集群中，Ceph是否可以為單個(gè)客戶端提供10K IOPs的組合隨機(jī)讀/寫能力。該用戶也想知道是否有人對(duì)類似的場景進(jìn)行過測試并希望能夠共享一下測試結(jié)果。在 Clyso 項(xiàng)目組中，我們一直在積極努力改進(jìn) Ceph 代碼以實(shí)現(xiàn)更高的性能。我們有自己的測試和配置來評(píng)估我們對(duì)代碼的更改。正好，我們當(dāng)前有可以匹配該用戶測試場景的硬件環(huán)境。因此，我們決定花些時(shí)間來進(jìn)行測試以及驗(yàn)證。

用戶環(huán)境配置

用戶的環(huán)境包含6個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都有2個(gè)4TB希捷FireCuda NVMe驅(qū)動(dòng)器和64GB內(nèi)存。關(guān)于CPU或網(wǎng)絡(luò)，當(dāng)前沒有明確的信息。但兩者都對(duì)這次測試可能很重要。因此，我們使用如下的 fio 命令來實(shí)現(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

雖然我們的實(shí)驗(yàn)室中沒有FireCuda驅(qū)動(dòng)器，但我們確實(shí)有節(jié)點(diǎn)具有多個(gè)4TB三星PM983驅(qū)動(dòng)器和每個(gè)128GB內(nèi)存。

群集配置

為了盡可能匹配用戶的環(huán)境，我們只使用了集群中的 6 個(gè)節(jié)點(diǎn)，其中 2 個(gè) OSD 在單個(gè) NVMe 驅(qū)動(dòng)器上運(yùn)行，每個(gè) OSD 用于 Ceph。其余節(jié)點(diǎn)用作客戶端節(jié)點(diǎn)。所有節(jié)點(diǎn)都位于同一Juniper QFX5200 交換機(jī)上，并通過單個(gè) 100GbE QSFP28 連接。

下面將先部署好 Ceph，并使用 CBT 啟動(dòng) FIO 測試。基于Intel的系統(tǒng)上一項(xiàng)重要的操作系統(tǒng)級(jí)別優(yōu)化是將 TuneD 配置文件設(shè)置為“延遲性能”或“網(wǎng)絡(luò)延遲”。這主要有助于避免與 CPU C/P 狀態(tài)轉(zhuǎn)換相關(guān)的延遲峰值。基于AMD的系統(tǒng)在這方面并沒有太大效果，目前還沒有確認(rèn)調(diào)優(yōu)是否限制了C/P狀態(tài)轉(zhuǎn)換，但是對(duì)于這些測試，調(diào)優(yōu)后的配置文件仍然設(shè)置為“網(wǎng)絡(luò)延遲”。

測試設(shè)置

用戶的環(huán)境包含6個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都有2個(gè)4TB希捷

CBT 需要修改幾個(gè)配置，而不使用是默認(rèn)的配置來部署 Ceph。每個(gè) OSD 分配 8GB 內(nèi)存（這是合理的，因?yàn)橛脩舻墓?jié)點(diǎn)有 64GB 內(nèi)存用于 2 個(gè) OSD）。RBD 卷與 Msgr V1 配合一起使用，并且 cephx 被禁用。

FIO 會(huì)先用大寫入預(yù)填充 RBD 卷，然后進(jìn)行用戶的隨機(jī)讀/寫測試。某些后臺(tái)進(jìn)程（如scrub, deep scrub, pg autoscaling, 以及 pg balancing）已禁用。PG 以及 PGP 設(shè)置為4096 （高于通常推薦的）和 3 副本的 RBD 池。用戶僅請(qǐng)求單個(gè) FIO 卷和使用單個(gè) 150GB 文件的測試。我們按照要求對(duì)此進(jìn)行了測試，但為了讓集群處于負(fù)載狀態(tài)，還運(yùn)行了 16 個(gè)獨(dú)立的 FIO 進(jìn)程的測試，這些進(jìn)程寫入分布在 4 個(gè)客戶端節(jié)點(diǎn)上的專用 RBD 卷，每個(gè)卷都有一個(gè) 16GB 的文件。 為了保證與用戶的FIO設(shè)置一致，必須將 gtod_reduce 選項(xiàng)的支持添加到cbt的FIO基準(zhǔn)測試工具中。 gtod_reduce 可以通過顯著減少 FIO 必須進(jìn)行的 getTimeOfDay（2） 調(diào)用次數(shù)來提高性能， 但它也禁用了某些功能， 例如在測試期間收集操作延遲信息。為了評(píng)估影響，我們?cè)趩⒂煤徒玫那闆r下 gtod_reduce運(yùn)行了測試：

根據(jù)結(jié)果，我們決定保持 gtod_reduce 禁用狀態(tài)，以便我們也可以觀察延遲數(shù)據(jù)。請(qǐng)注意，啟用此 FIO 選項(xiàng)可以提高大約 3-4%性能。除此之外，所有其他選項(xiàng)要么在CBT中可用，要么在FIO中已經(jīng)默認(rèn)。CBT YAML 文件的基準(zhǔn)測試部分包含單客戶端測試的配置內(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'

最終，我們實(shí)現(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 不僅能夠在這種混合工作負(fù)載中實(shí)現(xiàn) 10K IOPS，而且在單個(gè)客戶端測試中速度提高了一個(gè)數(shù)量級(jí)。針對(duì)這個(gè)小型 12 OSD 集群，我們從單個(gè)客戶端實(shí)現(xiàn)了大約 92K 的隨機(jī)讀取和 31K 的隨機(jī)寫入 IOPS。

另外，我們也運(yùn)行多客戶端測試的原因是為了展示這個(gè)小集群在為其他客戶端提供服務(wù)時(shí)有多少空間。在相同的混合工作負(fù)載和 16 個(gè)客戶端下，我們僅用 12 個(gè)支持 NVMe 的 OSD 就實(shí)現(xiàn)了超過 500K 的隨機(jī)讀取和大約 170K 的隨機(jī)寫入 IOPS。在多客戶端測試中，Qunicy 和 Reef 的性能優(yōu)勢分別比 Pacific 高出大約 6% 和 9%。啟用gtod_reduce可將 性能再提高 3-4%。

單客戶端和多客戶端CPU使用率

根據(jù)以往的測試，我們可以發(fā)現(xiàn)一個(gè)明顯的問題：CPU不足導(dǎo)致NVME的性能無法充分發(fā)揮。為了滿足單個(gè)客戶端工作負(fù)載，每個(gè) OSD 大約消耗 3-4 個(gè) AMD EPYC 內(nèi)核。為了滿足多客戶端工作負(fù)載的需求，每個(gè) OSD 消耗大量 11-12 個(gè)內(nèi)核！IE 即使每個(gè)節(jié)點(diǎn)只有 2 個(gè) OSD，每個(gè)節(jié)點(diǎn)也需要一個(gè) 24 核 EPYC 處理器才能實(shí)現(xiàn)這些驅(qū)動(dòng)器的最大性能。更快的驅(qū)動(dòng)器可能需要更大/更快的處理器。什么進(jìn)程使用了所有這些 CPU？ 在以前的文章中，我們得出過如下的結(jié)論：

在某些情況下，RocksDB 壓縮線程也會(huì)定期使用 CPU 資源。BlueStore KV Sync 線程很容易成為小型隨機(jī)寫入的瓶頸，尤其是在使用較低性能的 CPU 時(shí)。但是，總體 CPU 消耗主要是在 OSD 工作線程和異步信使線程中完成的工作的結(jié)果。這是 crc 檢查、編碼/解碼、內(nèi)存分配等的組合。

單客戶端和多客戶端cycles/OP

由于cycles/OP 解析代碼中的錯(cuò)誤，先前的cycles/OP 計(jì)數(shù)顯著增加。這使得 OSD 的效率似乎比實(shí)際要低得多。因此，我們計(jì)算性能指標(biāo)的時(shí)候，需要使用聚合平均 CPU 消耗和 IOPS 而不是聚合周期和 OPS ，校正后的數(shù)值已被驗(yàn)證在預(yù)期的 ~14-17% 以內(nèi)。我們認(rèn)為，剩余的差異主要是由于cpu速度隨時(shí)間的變化，以及 collectl 報(bào)告的 CPU 消耗方式。

在單客戶端和多客戶端測試中，性能似乎略有提高。另外，在多客戶端測試中，我們發(fā)現(xiàn)在高負(fù)載下處理數(shù)據(jù)的效率要高得多，而在單客戶端測試中，我們?cè)诘拓?fù)載下處理數(shù)據(jù)的效率要高得多。

為什么會(huì)這樣呢？在上一節(jié)中，我們討論了 OSD 中的大部分工作如何由 OSD 工作線程和異步信使線程完成。當(dāng) OSD 收到新 IO 時(shí)，首先由與相應(yīng)網(wǎng)絡(luò)連接關(guān)聯(lián)的異步信使線程處理并移動(dòng)到用戶空間中。然后將其放入給定 OSD 分片的計(jì)劃程序工作隊(duì)列中。如果隊(duì)列之前為空，則與該分片關(guān)聯(lián)的所有線程都會(huì)喚醒，并且在分片的工作隊(duì)列為空之前不會(huì)返回睡眠狀態(tài)。當(dāng)只有 1 個(gè)客戶端執(zhí)行 IO 時(shí)，集群上的負(fù)載會(huì)明顯減少，并且每個(gè)分片的隊(duì)列通常會(huì)在短時(shí)間內(nèi)為空。線程會(huì)不斷喚醒并重新進(jìn)入睡眠狀態(tài)。當(dāng)群集負(fù)載較重時(shí)，隊(duì)列更有可能有工作要做，因此線程花費(fèi)更少的睡眠和喚醒時(shí)間。相反，他們花更多的時(shí)間做實(shí)際工作。

單客戶端和多客戶端平均延遲

在單客戶端測試中，Ceph 能夠保持亞毫秒級(jí)的平均讀取和寫入延遲。在多客戶端測試中，我們看到了Pacific，Quincy和Reef之間的不同行為。Pacific的讀取延遲最低，寫入延遲最高，而Reef的讀取延遲略有增加，但寫入延遲顯著降低。Quincy的介于兩者之間，但更接近Reef而不是Pacific。

單客戶端和多客戶端99.9%延遲

正如預(yù)期的那樣，99.9% 的延遲略高。我們可以實(shí)現(xiàn)不到 1.3 毫秒的讀取和大約 2.1-2.3 毫秒的寫入，具體取決于版本。多客戶端測試中的尾部延遲明顯更高，但是在此測試中，Quincy 尤其是 Reef 的寫入尾部延遲明顯低于 Pacific。

結(jié)論

那么我們最后是怎么做的呢？目標(biāo)是在這個(gè)混合讀/寫 FIO 工作負(fù)載中達(dá)到 10K IOPS，讀取率為 75%，寫入率為 25%。我假設(shè)這意味著目標(biāo)是 7500 個(gè)讀取 IOPS 和 2500 個(gè)寫入 IOPS。讓我們比較一下我們是如何做到的：

Single-Client IOPS: 單客戶端 IOPS：

多客戶端 IOPS：

目前，我們完成了所有的測試，同時(shí)也滿足了要求！另外，如果使用更快的 NVMe 驅(qū)動(dòng)器，結(jié)果應(yīng)該可以進(jìn)一步改善。