其中 5 个节点被配置为 OSD 主机，5 个节点被配置为客户端节点。所有节点都位于同⼀个 JuniperQFX5200 交换机上，并通过⼀条 100GbE QSFP28 链路连接。部署了 Ceph 集群，并使用 CBT 启动了 FIO 测试。在英特尔操作系统上有⼀个重要的操作系统级优化是将 TuneD 配置文件设置为 "延迟-性能 "或 "网络-延迟"。这主要有助于避免与 CPU C/P 状态转换相关的延迟峰值。基于 AMD Rome 的系统在这方面似乎没有太大的调整需要，而且也没有证实 TuneD 是否真的限制了 AMD 处理器上的 C/P 状态转 换。不过，在这些测试中，TuneD 配置文件被设置为 "网络延迟"。

CBT 主要做这么几块配置⼯作：

1. 部署 Ceph，并对设置进行了若干修改。

2. 为 OSD 分配了16GB osd_memory_target以确保⾼节点命中率并消除对性能的影响。

3. 禁用了 RBD 缓存，因为对于由快速 NVMe 驱动器支持的 OSD 来说，RBD 缓存对性能有百害而无⼀利。

4. 使用以下配置选项为相关测试启用了 msgr V2 的安全模式：

ms_client_mode = securems_cluster_mode = securems_service_mode = securems_mon_client_mode = securems_mon_cluster_mode = securems_mon_service_mode = secure

如下执行三组测试，并在每组测试之间重建集群：

OSD 将会使用节点上的所有 CPU 内核资源。FIO 被配置为首先用大量写入预填充 RBD 卷，然后进行4MB 和 4KB IO 测试，每个测试持续 300 秒。同时会禁用了 Ceph 的⼀些后台进程，如刷新、深度刷 新、PG 自动扩展和 PG 平衡。最后，使用了⼀个 16384 个 PG（高于通常推荐值）和 3 副本的 RBD 存 储池。

Ceph利用名为LUKS的工具对BlueStore写入数据的块设备进行加密。有几个可用的调整选项可以帮助 提高性能。在深入了解整个测试之前，我们先来看看其中的几个选项。

遗憾的是，Centos Stream 8 中的内核不支持禁用读写工作队列。因此，我们无法测试这些选项。不过，我们还是测试了其他选项，并将最初的重点放在了多客户端测试配置上。

刚开始，我们发现在 LUKS 上部署 OSD 对 4MB 读取性能影响很小，但对写入性能影响很大。这可能会 有点误导，因为我们在每个节点的读取测试中受到网络限制，约为 11GB/s。然而，对于写入测试，性能影响很大。但是，我们可以使用 --perf_submit_from_crypt_cpus 选项来减轻⼀些性能损失。虽然我们无法在这些测试中测试与工作队列相关的性能选项，但 Ceph 中已经有⼀个 PR 可以启⽤ Josh Baergen 测试过的这些选项：

工作队列选项可能有助于提高 CPU 使用率。虽然我们没有这些数据，但让我们来看看我们能够运行的测试中的 CPU 使用率。

在读取过程中，如果使用 LUKS，系统的 CPU 占用率会急剧上升（CPU 占用率最高可达 2 倍）。在写入测试中，CPU 的总体消耗量似乎差不多，甚至更低，但如果考虑到性能，情况就不⼀样了。实际上，每 次 IO 的 CPU 占用率总体更高。在读取和写⼊测试中，使用 4K 扇区大小的 LUKS 似乎会导致 CPU 占用 率略有下降。

4KB 随机 IO 对性能的影响低于 4MB IO。4KB 读取的命中率大约为 11-12%，而写入命中率接近 20%。

总体 CPU 使用率非常接近，但是，系统使用率略高，而用户使用率较低（与启用LUKS 时性能较低相关）。

这些测试的⼀般结论是 --perf-submit_from_crypt_cpus选项可以提高LUKS 大写入吞吐量，并且可 能值得使用，我们将在本文的其余测试中使用它。对于本身支持 4K 扇区的设备来说，4K 扇区也可能值 得启用，并且在某些情况下可能有助于稍微提高 CPU 使用率。从这些测试中得出的总体结论是， --perf-submit_from_crypt_cpus 选项可以提高 LUKS 的大容量写入吞吐量，这非常推荐我们去使用它，我们将在本文剩余的测试中使用该选项。对于原生支持 4K 扇区的 设备来说，启用该选项也是值得的，在某些情况下可能有助于略微提高 CPU 使用率。

既然我们已经对 LUKS 进行了⼀些基础测试，那么让我们看看 msgr V2 安全模式在相同的高并发工作量下有何效果。

启用 msgr v2 安全模式会产生额外的开销，但是，这些测试中更大的影响来自 LUKS。

LUKS 再次导致大量 CPU 占用。有趣的是，启用 msgr v2 后，在使用未加密的块卷（IE no LUKS）时， 系统 CPU 消耗似乎有所减少。目前还不完全清楚为什么会出现这种情况，可能是块层的 IO 工作量略有 减少。

最大的影响再次来自LUKS。

对 CPU 占用率影响最大的也是 LUKS，系统 CPU 占用率略高，用户 CPU 占用率略低（与性能降低有关）。

集群消耗大量 IO 的影响之⼀是，我们会看到高延迟事件。在这种情况下，我们实际上在读取方面做了⼀ 些优化，但还是看到延迟高达 ~900ms。但是，在这种饱和工作负载中，LUKS 和安全模式都不会对尾部 延迟产生显著影响。单客户端测试 - 4MB IO

去年，我们使用 Msgr V2 AES 加密研究了 QEMU/KVM 性能，发现加密确实对单客户端性能产生了显着 影响。我们在这里运行了几个单客户端测试，以验证 Reef 中是否仍然存在这种情况。

在早些时候的多客户机测试中，我们观察到 LUKS 通常影响最大。它大大增加了大型 IO 的 CPU 消耗， 降低了大型写入和小型随机 IO 的性能。在这些单客户端大型 IO 工作负载中，LUKS 的影响很小。不过， 启用信使加密对单客户端性能的影响很大，而在多客户端测试中，它对整个集群性能的影响要小得多。

不过，LUKS 和 messenger-level 加密对单客户端小型 IO 的影响很小，通常只有百分之几。延迟如何？

之前的多客户端测试显示出明显的延迟峰值，这是因为我们对 OSD 的加大负载的力度很大。在这些单客户端测试中，延迟要均匀得多。读取的典型延迟徘徊在 0.9 毫秒左右，峰值不超过 1.15 毫秒。写入情况 更为有趣。延迟仍然明显较低，通常在 1.5 毫秒左右。峰值通常低于 2.5 毫秒，但在同时使用磁盘和信使 级加密的情况下，峰值接近 3.5 毫秒。不过，峰值的性质似乎随着时间的推移呈周期性变化，而且这种 模式会在完全重建的集群上进行的多次测试中重复出现。这种效应值得进⼀步研究。

在之前的单客户端测试中，我们仍然使用了较高的 io_depth，以允许大量 IO 保持运行状态。这允许多个 OSD 同时为 IO 提供服务，从而提高性能。但有些应用程序要求按顺序处理 IO。在写入或读取下⼀个 IO 之前，必须先完成⼀个 IO。etcd 日志就是这类工作负载的⼀个很好的例子，因而，通常会完全受延迟限制。每个 IO 必须完成至少⼀次往返网络传输，以及从磁盘提供服务所需的其他开销。

在这种情况下，最大的影响来自 LUKS。4KB 同步读取的速度稍慢，而 4KB 同步写入的速度下降幅度较大。

延迟也遵循类似的模式，未加密结果显示响应时间比加密结果稍快。读取延迟徘徊在 0.13 毫秒左右，而写⼊延迟徘徊在 0.4 毫秒左右，偶尔也会达到 0.5 毫秒左右。

在本文中，我们研究了在各种不同的 RBD 测试场景中使⽤磁盘上加密和在线加密的 Ceph 性能。这些测 试结果显示了几个细微的结论。

⼀般来说，我们预计用户在使⽤磁盘加密时会看到 CPU 消耗增加。预计影响最大的是大型 IO。值得庆幸 的是，Ceph 在小 IO 工作负载期间通常会使用更多的 CPU。围绕 IOPS 需求设计 OSD CPU 规格的客户不会因为 CPU 不足而受到严重的性能影响。磁盘加密确实会对大型写入产生显着的性能影响，但是，这 种影响可以部分缓解，并且正在推进的优化工作可能会进⼀步缓解这种影响。磁盘加密对小型同步写入性能也有⼀定影响。在线加密对性能的最大影响在于最大单客户端吞吐量。在其他情况下，它确实也会 对性能产生很小的影响，尽管影响通常很小。⼀如既往，我们鼓励用户亲自测试⼀下，看看用户的测试 结果是否与我们在这里测试的相符。

    推荐阅读   

    推荐视频