在过去?年左右的时间里，越来越多的用户开始使用 Ceph 的加密功能 ，但很多人并不知道这会对 Ceoh 集群产生什么样的性能影响。今天，我们将了解 Ceph 在几种不同工作负载下的磁盘加密和在线加密性能。下面是针对这些术语简单说明：

1. 磁盘加密：有时也称为静态加密。数据在写入持久存储时进行加密。在Ceph中，使用LUKS和dm-crypt对BlueStore用来存储数据的底层块设备进行完全加密。

这样就可以完全加密存储在 Ceph 中的所有数据，而不管它是块数据、对象数据还是文件数据。

2. 在线加密：数据在通过网络发送时会被加密。在 Ceph 中，这是通过选择性地为 Messenger 版本 2 客户端启用“安全”MS 模式来完成的。从 Ceph Reef v18.2.0 开始，ms 安全模式使用 128 位 AES 加 密。

还可以在更高级别执行加密。例如，RGW 可以在将对象发送到 OSD 之前对其本身进行加密。然而，就本文而言，我们将重点关注 RBD 块性能，并将利用上面列出的两个选项。

集群配置

其中 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 = secure
ms_cluster_mode = secure
ms_service_mode = secure
ms_mon_client_mode = secure
ms_mon_cluster_mode = secure
ms_mon_service_mode = secure

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

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

Ceph LUKS Tuning - 4MB IOs

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

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

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

• "在低负载情况下，延迟似乎不会受到这些变化的太大影响。任何差异都不会超出我们的误差范 围"。
• “在包括写入在内的高负载下，写入越大，此更改越有效。例如，对于 4m 顺序写入，OSD 节点 CPU 使用率下降了近?半，延迟显着改善（p90 读取速度快了两个数量级）”。
• “大块只读负载的延迟可能会稍差?些，但很难确定。”

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

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

Ceph LUKS Tuning - 4KB IOs

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 使用率。

多客户端测试一 - 4MB IO

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

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

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

多客户端测试二 - 4KB IO

最大的影响再次来自LUKS。

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

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

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

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

单客户端测试 - 4KB IO

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

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

单客户端测试 - 4KB SYNC IO

在之前的单客户端测试中，我们仍然使用了较高的 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 不足而受到严重的性能影响。磁盘加密确实会对大型写入产生显着的性能影响，但是，这 种影响可以部分缓解，并且正在推进的优化工作可能会进?步缓解这种影响。磁盘加密对小型同步写入性能也有?定影响。在线加密对性能的最大影响在于最大单客户端吞吐量。在其他情况下，它确实也会 对性能产生很小的影响，尽管影响通常很小。?如既往，我们鼓励用户亲自测试?下，看看用户的测试 结果是否与我们在这里测试的相符。

如有相关问题，请在文章后面给小编留言，小编安排作者第一时间和您联系，为您答疑解惑。

原文：https://ceph.io/en/news/blog/2023/ceph-encryption-performance/