?介紹
最近，很多人都會問：如何設置 QEMU/KVM 以獲取最高的性能？
雖然，過去很多人都在測試或者使用 Ceph 過程中進行調優(yōu)設置以獲取最佳性能，但到目前而言，還沒有一個最優(yōu)的最新數(shù)據(jù)。通常，我們在使用 Ceph 的時候，有經(jīng)驗的工程師往往會通過消除系統(tǒng)高級別的性能瓶頸來優(yōu)化。
這可能意味著可能會通過 librbd 與同步 IO 隔離測試單個OSD的延遲，或者使用大量有高 IO 深度的客戶端在裸機上的 OSD 集群上產(chǎn)生大量IO。在這種情況下，請求是用大量并發(fā) IO 驅動由 librbd 支持的單個 QEMU/KVM，并查看其速度。
下文，我們將了解 QEMU/KVM 在使用 Ceph 的 librbd 驅動程序時的執(zhí)行速度。
集群設置
所有節(jié)點都位于同一個 Juniper QFX5200 交換機上，并通過單個 100GbE QSFP28 鏈路連接。雖然集群有 10 個節(jié)點，但在決定最終設置之前我們也評估了各種配置。最終使用 5 個節(jié)點作為 OSD 主機，總共有 30 個 NVMe 支持的 OSD。
此設置的預期總體性能約為 1M 隨機讀取 IOPS 和至少 250K 隨機寫入 IOPS（在 3 副本的場景下），這足以測試單個 VM 的 QEMU/KVM 性能。集群中剩余的一個節(jié)點用作 VM 客戶端主機。不過，在配置 VM 之前，使用 CBT (https://github.com/ceph/cbt/) 構建了幾個測試集群，并使用 fio 的 librbd 引擎運行測試工作負載以獲得基線結果。
基線測試
CBT 的配置為匹配 Ceph 環(huán)境修改了一些，而不是使用默認的配置。首先，禁用了 rbd 緩存 (1)，每個 OSD 被分配了一個 8GB 的 OSD 內存 traget，并且在初始測試中禁用了 cephx ，并且使用 msgr V1（但在以后的測試中使用安全模式下的 msgr V2 啟用了 cephx）。創(chuàng)建集群后，CBT 配置為使用帶有 librbd 引擎的 fio 創(chuàng)建一個 6TB RBD 卷，然后通過 iodepth=128 的 fio 執(zhí)行 16KB 隨機讀取 5 分鐘。由于使用 CBT 重新創(chuàng)建集群和運行多個基線測試非常簡單，因此，下面測試了幾種不同的集群大小以獲得 librbd 引擎和基于 kernel-rbd 的 libaio 引擎的基線結果。
在集群級別禁用 RBD 緩存將對使用 librbd 引擎的 fio 有效，但不會對 QEMU/KVM 的 librbd 驅動程序有效。相反，cache=none 必須通過 qemu-kvm 的驅動部分顯式傳遞。
Kernel-RBD 在從單個 OSD 讀取時表現(xiàn)非常出色，但 Librbd 在完整的 30 個 OSD Ceph 集群中以略高于 122K IOPS 的速度實現(xiàn)了最高性能。librbd 和 kernel-rbd 在 5 OSD Ceph 集群上的表現(xiàn)幾乎一樣。
盡管如此，在 5 個節(jié)點、30 個 OSD Ceph 集群上我們執(zhí)行了進一步的測試。此場景更好地模仿了用戶在小規(guī)模但更貼近真實環(huán)境并且配置 NVMe 的 Ceph 集群上可能看到的結果。
虛擬機部署
使用 RBD 部署和引導 QEMU 虛擬機鏡像相當簡單了。
1. 下載鏡像
使用了 CentOS8 Stream qcow2 映像，并注入了 root 密碼和公鑰以便于訪問：
wget https://cloud.centos.org/centos/8-stream/x86_64/images/CentOS-Stream-GenericCloud-8-20220913.0.x86_64.qcow2
virt-sysprep -a ~/CentOS-Stream-GenericCloud-8-20220913.0.x86_64.qcow2 --root-password password:123456 --ssh-inject root:file:/home/nhm/.ssh/id_rsa.pub
2. RBD 鏡像池創(chuàng)建、初始化和設置 LibVirt 身份驗證
這用于存儲 RBD 鏡像。
sudo /usr/local/bin/ceph osd pool create libvirt-pool
sudo /usr/local/bin/rbd pool init libvirt-pool
sudo /usr/local/bin/ceph auth get-or-create client.libvirt mon 'profile rbd' osd 'profile rbd pool=libvirt-pool'
3. 將 qcow2 鏡像轉換為 Ceph RBD 鏡像并調整大小
調整它的大小，以便為基準測試留出一些空間！
qemu-img convert -f qcow2 -O raw ./CentOS-Stream-GenericCloud-8-20220913.0.x86_64.qcow2 rbd:libvirt-pool/CentOS8
qemu-img resize rbd:libvirt-pool/CentOS8 6000G
4. 完成設置虛擬機并預填充基準數(shù)據(jù)
最后，從 RBD 啟動 VM，登錄，設置分區(qū)，并預填充 FIO 文件以進行測試。在這種情況下，僅使用了 20GB 的鏡像部分，但不要擔心。稍后將在真正的 XFS 文件系統(tǒng)上生成更大 (2TB) 文件的結果。
/usr/libexec/qemu-kvm -m 16384 -smp 16,sockets=1,cores=16,threads=1 -drive format=raw,file=rbd:libvirt-pool/CentOS8 -net nic -net user,hostfwd=tcp::2222-:22
ssh -p 2222 root@localhost
sudo yum install fio
cfdisk /dev/sda # Create a 2TB partition here (maximum size due to the partition type for image, oh well)
fio --ioengine=libaio --rw=write --numjobs=1 --bs=4M --iodepth=128 --size=20G --name=/dev/sda2
對 VM 進行基準測試
1. 默認情況
眾所周知，在 ide 和 virtio-blk 等 qemu 設備之間存在相當顯著的性能差異。QEMU/KVM 配置為使用其默認值的性能如何？
/usr/libexec/qemu-kvm -m 16384 -smp 16,sockets=1,cores=16,threads=1 -drive format=raw,file=rbd:libvirt-pool/CentOS8 -net nic -net user,hostfwd=tcp::2222-:22
fio --ioengine=libaio --direct=1 --bs=16384 --iodepth=128 --rw=randread --norandommap --size=20G --numjobs=1 --runtime=300 --time_based --name=/dev/sda2
read: IOPS=2484, BW=38.8MiB/s (40.7MB/s)(11.4GiB/300001msec)
結果慘不忍睹！那virtio-blk 又是怎么樣的了？
2. 使用 virtio-blk-pci
/usr/libexec/qemu-kvm -m 16384 -smp 16,sockets=1,cores=16,threads=1 -drive format=raw,id=rbd0,if=none,file=rbd:libvirt-pool/CentOS8 -device virtio-blk-pci,drive=rbd0,id=virtioblk0 -net nic -net user,hostfwd=tcp::2222-:22
fio --ioengine=libaio --direct=1 --bs=16384 --iodepth=128 --rw=randread --norandommap --size=20G --numjobs=1 --runtime=300 --time_based --name=/dev/vda2
read: IOPS=24.9k, BW=390MiB/s (409MB/s)(114GiB/300005msec)
結果有很大的進步?，F(xiàn)在是時候添加一個單獨的 iothread。
3. 添加單獨的 IO 線程
?/usr/libexec/qemu-kvm -m 16384 -smp 16,sockets=1,cores=16,threads=1 -drive format=raw,id=rbd0,if=none,file=rbd:libvirt-pool/CentOS8 -object iothread,id=iothread0 -device virtio-blk-pci,iothread=iothread0,drive=rbd0,id=virtioblk0 -net nic -net user,hostfwd=tcp::2222-:22
fio --ioengine=libaio --direct=1 --bs=16384 --iodepth=128 --rw=randread --norandommap --size=20G --numjobs=1 --runtime=300 --time_based --name=/dev/vda2
read: IOPS=26.0k, BW=407MiB/s (426MB/s)(119GiB/300005msec)
結果更好，但其實仍然很慢。此時，我使用 ( uwpmp (https://github.com/markhpc/uwpmp/) ) 分析了 QEMU/KVM。有各種各樣的問題，包括不匹配的 debug symbols 和其他煩人的問題。為了防止結果不標準，我們進行了數(shù)十次測試。最終推動測試繼續(xù)的是對 QEMU 調用 librbd 緩存層的 wallclock 配置文件調整。QEMU 中的 librbd 驅動程序會覆蓋 Ceph 全局配置中設置的內容。要在 QEMU/KVM 中禁用 RBD 緩存（這在告訴集群上很重要），必須在 qemu-kvm 的驅動器配置中明確設置 cache=none。
4. 禁用 LibRBD 驅動器緩存
/usr/libexec/qemu-kvm -m 16384 -smp 16,sockets=1,cores=16,threads=1 -drive format=raw,id=rbd0,if=none,cache=none,file=rbd:libvirt-pool/CentOS8 -object iothread,id=iothread0 -device virtio-blk-pci,iothread=iothread0,drive=rbd0,id=virtioblk0 -net nic -net user,hostfwd=tcp::2222-:22
fio --ioengine=libaio --direct=1 --bs=16384 --iodepth=128 --rw=randread --norandommap --size=20G --numjobs=1 --runtime=300 --time_based --name=/dev/vda2
read: IOPS=53.5k, BW=836MiB/s (876MB/s)(245GiB/300003msec)
禁用 LibRBD 緩存帶來了相當大的性能改進，但幸運的是這還沒有結束。在運行 wallclock profiler 時，我們注意到不僅有大量時間花在 rbd 緩存上，還有 libc 內存分配例程。Ceph 的內存模型通常涉及創(chuàng)建許多小的臨時對象，這些對象會分割內存并且對內存分配器來說非常困難。TCMalloc（和 JEMalloc）傾向于比 libc malloc 更好地處理 Ceph 的行為。幸運的是，可以通過 LD_PRELOAD 指令注入 TCMalloc。
5. 將內存分配器切換到 TCMalloc
LD_PRELOAD="/usr/lib64/libtcmalloc.so" /usr/libexec/qemu-kvm -m 16384 -smp 16,sockets=1,cores=16,threads=1 -drive format=raw,id=rbd0,if=none,cache=none,file=rbd:libvirt-pool/CentOS8 -device virtio-blk-pci,drive=rbd0,id=virtioblk0 -net nic -net user,hostfwd=tcp::2222-:22
fio --ioengine=libaio --direct=1 --bs=16384 --iodepth=128 --rw=randread --norandommap --size=20G --numjobs=1 --runtime=300 --time_based --name=/dev/vda2
read: IOPS=80.0k, BW=1250MiB/s (1311MB/s)(366GiB/300003msec)
結果變得更好了，但它可以更快嗎？
6. 使用新版本的 LibRBD
目前本次測試使用的是CentOS Stream8自帶的系統(tǒng)版本librbd。它已經(jīng)很老了，后面的版本有顯著的改進。這些主要與由 Adam Emerson 編寫并由 Jason Dillaman 在 RBD 中實現(xiàn)的 boost::asio IO 路徑返工有關?？梢栽O置 LD_LIBRARY_PATH 來告訴 qemu-kvm 使用編譯 Ceph (v16.2.9) 時安裝在 /usr/local 中的新版本 librbd。
LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64
LD_PRELOAD="/usr/lib64/libtcmalloc.so" /usr/libexec/qemu-kvm -m 16384 -smp 16,sockets=1,cores=16,threads=1 -drive format=raw,id=rbd0,if=none,cache=none,aio=native,file=rbd:libvirt-pool/CentOS8 -object iothread,id=iothread0 -device virtio-blk-pci,iothread=iothread0,drive=rbd0,id=virtioblk0 -net nic -net user,hostfwd=tcp::2222-:22
fio --ioengine=libaio --direct=1 --bs=16384 --iodepth=128 --rw=randread --norandommap --size=20G --numjobs=1 --runtime=300 --time_based --name=/dev/vda2
read: IOPS=126k, BW=1964MiB/s (2060MB/s)(575GiB/300002msec)
新版本的 librbd 顯著提高了性能，現(xiàn)在的結果比直接使用 librbd 的基線 fio 測試要快一些！
更大鏡像的測試
到目前為止，只有一個直接位于 RBD 塊設備上的小型 (20G) 數(shù)據(jù)集用于測試。為了使這些測試更真實，更接近我們的基線測試，可以安裝一個 XFS 文件系統(tǒng)并預填充 2TB 的數(shù)據(jù)（遺憾的是受到前面提到的分區(qū)大小限制）。
mkfs.xfs /dev/vda2
mount /dev/vda2 /mnt
fio --ioengine=libaio --direct=1 --rw=write --numjobs=1 --bs=4M --iodepth=16 --size=2000G --name=/mnt/foo
write: IOPS=607, BW=2429MiB/s (2547MB/s)(2000GiB/843305msec); 0 zone resets
不錯。即使 iodepth=16 相當適中，fio 也能夠以大致 NVMe 的速度填充 RBD 卷。16K randread 工作量怎么樣？
16K 隨機讀取
fio --ioengine=libaio --direct=1 --bs=16384 --iodepth=128 --rw=randread --norandommap --size=2000G --numjobs=1 --runtime=300 --time_based --name=/mnt/foo
read: IOPS=123k, BW=1916MiB/s (2009MB/s)(561GiB/300002msec)
16K 隨機寫入怎么樣？
16K 隨機寫入
fio --ioengine=libaio --direct=1 --bs=16384 --iodepth=128 --rw=randwrite --norandommap --size=2000G --numjobs=1 --runtime=300 --time_based --name=/mnt/foo
write: IOPS=64.1k, BW=1001MiB/s (1050MB/s)(293GiB/300003msec); 0 zone resets
不如本地 NVMe 驅動器快，但對于單個 VM 來說還不錯。值得注意的是，在隨機讀取測試期間，Ceph 的所有三個異步 msgr 線程都以 100% 的 CPU 運行。在測試運行時使用 ( uwpmp (https://github.com/markhpc/uwpmp/) )查看 qemu-kvm 進程，發(fā)現(xiàn)正在進行相當多的工作，但在 librbd 端沒有明顯的快速優(yōu)化區(qū)域。然而，將 boost::asio 帶入堆棧更深可能會提供額外的改進。
進一步的 QEMU 優(yōu)化？
完成上述測試后，我聯(lián)系了 QEMU 維護者 Stefan Hajnoczi 以獲得他對結果的看法。他提供了幾個額外的選擇來嘗試：
- 較新的 --blockdev rbd,node-name=rbd0,cache.direct=on,pool=libvirt-pool,image=CentOS8 參數(shù)省略了 “raw'” 驅動程序以實現(xiàn)微小的加速...I / O請求直接進行使用這種新參數(shù)從模擬的 virtio-blk 設備到 rbd 驅動程序。
- 使用 -M q35 獲得現(xiàn)代機器類型。
事實證明，測試這很容易，我們可以使用新參數(shù)重新啟動 qemu-kvm：
LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64
LD_PRELOAD="/usr/lib64/libtcmalloc.so" /usr/libexec/qemu-kvm -m 16384 -smp 16,sockets=1,cores=16,threads=1 --blockdev rbd,node-name=rbd0,cache.direct=on,pool=libvirt-pool,image=CentOS8 -M q35 -object iothread,id=iothread0 -device virtio-blk-pci,iothread=iothread0,drive=rbd0,id=virtioblk0 -net nic -net user,hostfwd=tcp::2222-:22
最終，性能非常接近，使用新命令的讀取速度可能稍慢，寫入速度稍快，但需要進一步測試以了解結果是否具有統(tǒng)計相關性。
Msgr V2 和 AES 加密
到目前為止，這些測試都使用了完全禁用 CephX 的 Msgr V1。這不是運行真實集群的一種非?，F(xiàn)實的方式。唯一應該像這樣配置集群的情況是，網(wǎng)絡以及 Ceph 客戶端是完全可靠信任的。Ceph 的默認身份驗證模式允許身份驗證和防止中間人攻擊。Ceph 還可以在“安全”模式下運行，該模式還提供 AES-128-GCM 在線加密。這可以通過將幾個 Ceph 配置選項設置為“安全”來啟用：
ms_client_mode = secure
ms_cluster_mode = secure
ms_service_mode = secure
ms_mon_client_mode = secure
ms_mon_cluster_mode = secure
ms_mon_service_mode = secure
這些設置對基線測試中的客戶端性能有多大影響？
這里的下降似乎并不算太糟糕，但是從上面的“更大鏡像的測試”部分重復 QEMU/KVM 隨機讀取測試導致得分約為 87K IOPS，而沒有加密時為 123K IOPS。在 qemu-kvm 進程中，異步 msgr 線程仍然固定在 100%，但是這次（反向）wallclock 配置文件看起來有點不同：
+ 14.00% _aesni_ctr32_ghash_6x
|+ 14.00% aesni_gcm_decrypt
| + 14.00% aes_gcm_cipher
| + 14.00% EVP_DecryptUpdate
| + 14.00% ceph::crypto::onwire::AES128GCM_OnWireRxHandler::authenticated_decrypt_update(ceph::buffer::v15_2_0::list&)
| + 14.00% ceph::msgr::v2::FrameAssembler::disasm_remaining_secure_rev1(ceph::buffer::v15_2_0::list*, ceph::buffer::v15_2_0::list&) const
作為框架組裝工作的一部分，每個異步 msgr 線程至少花費 14% 的時間在 libssl 的 EVP_DecryptUpdate 函數(shù)中。值得注意的是，即使在這個 AMD Rome 處理器上，libssl 似乎也能正確使用 AES-NI 指令。仔細查看代碼，似乎對于每一幀，Ceph 都會遍歷每個段并依次解密各個緩沖區(qū)（每個段可能有多個?。?。IE 的偽代碼看起來像這樣：
Disassemble first segment
Disassemble remaining segments
For each Segment in Segments:
For each buffer in Segment:
convert buffer to c string
call EVP_DecryptUpdate on c string
也許如果可以一次解密更大的數(shù)據(jù)塊，那么這里的 AES-NI 開銷就可以減少。但是什么大小真的很重要？Openssl 提供了一個速度測試，可以幫助縮小范圍：
openssl speed -evp aes-128-gcm -decrypt
看來，在這個處理器上，當我們只處理 16K 塊并利用一個完整的核心來進行 AES 解密時，我們應該能夠達到接近 4GB/s（256K 塊/秒）的速度。即使是 1-8K 的塊處理速度也很快，但非常小的塊對解密性能有重大影響。
這可能有助于解釋啟用安全模式時的性能損失。如果 3 個 IO 線程中的每一個都在 libssl 函數(shù)中花費 14-20% 的時間（并非所有都顯示在上面的配置文件片段中），那么根據(jù) openssl 速度測試，預期應該可以實現(xiàn) 120-130K IOPS。如果可以減少 msgr 線程之間的爭用，那么額外的 msgr 線程可能能夠以增加 CPU 使用率為代價來提高性能。
結論
這篇文章介紹了如何為 VM 存儲調整以及優(yōu)化 QEMU/KVM 和 librbd 的性能。
對于 16K 的 IO，qemu+librbd 經(jīng)過仔細調優(yōu)后，可以從單個 VM 實現(xiàn) 64-67K 的隨機寫入 IOPS 和 123K 的隨機讀取 IOPS。即使在使用 libssl 的 AES-NI 支持時，在 Ceph 中啟用 128 位在線 AES 加密也會對性能產(chǎn)生顯著影響（30% 以上）。
在加密和未加密的情況下，性能似乎主要受到飽和 msgr 線程的限制。有一些跡象表明，線程之間的爭用可能在限制單客戶端性能方面發(fā)揮了作用。在啟用AES加密的情況下，幀段的分解和解密順序可能會影響性能。似乎沒有證據(jù)表明 virtio-blk-pci 達到了極限。
*原文鏈接：https://ceph.io/en/news/blog/2022/qemu-kvm-tuning/
