Ceph Tentacle 快速纠删码的性能改进|存储池|数据块|算法|纠删码|负载|驱动器

新钛云服已累计为您分享893篇技术干货

深入探讨 Ceph 最新 Tentacle 版本中 FastEC 改进的优势。本文详细讨论了我们如何改进纠删码，使其成为复制的可靠替代方案，并降低 Ceph 集群的总拥有成本 (TCO)。

引言

Ceph 社区的用户对 Tentacle 版本中 Fast EC 功能的发布感到非常满意。本文讨论了在 Tentacle 中启用 Fast EC 相对于 Squid 的性能优势。

这些优化主要旨在使块和文件工作负载受益；对于小对象或随机访问读取的 S3 对象工作负载也可能受益。

在 Tentacle 中启用 Fast EC 是基于每个存储池进行的，使用命令：

ceph osd pool   set allow_ec_optimizations  on

需要注意的是，一旦 allow_ec_optimizations 被启用，就无法禁用。

快速纠删码改进总结如下：

读取优化 - 部分读取
空间效率提升 - 小对象填充
写入优化 - 部分写入，奇偶校验增量写入
建议用户将 stripe_unit 大小增加到 16k，用于启用 allow_ec_optimizations 的存储池。

纠删码基础

在深入讨论优化之前，让我们简要介绍一下纠删码和 RAID 的基础知识。

Ceph 纠删码通过将对象分成K个数据块和M个奇偶校验编码块来工作，这些块然后存储在不同的对象存储守护程序 (OSD) 上。如果一个或多个 OSD 发生故障，可以使用剩余的数据块和奇偶校验编码块重建丢失的数据。与传统复制相比，这种方法更具存储效率，因为它不存储数据的完整副本。

工作原理

数据分割：一个对象被分成K个数据块。
奇偶校验生成：纠删码算法，例如 Reed-Solomon ( https://en.wikipedia.org/wiki/Reed–Solomon_error_correction )，根据数据块计算M个奇偶校验编码块。奇偶校验块的数量M决定了在不丢失数据的情况下可以有多少个 OSD 发生故障。用户可以使用不同的可用插件配置纠删码算法。插件的选择不在本文讨论范围之内。
块分布：K个数据块和M个奇偶校验块根据 CRUSH 规则分发并存储在单独的 OSD 上。
用户决定块的大小，这称为 `tripe_unit，可以在创建 erasure-code-profile` 时指定。后面会有一个部分讨论 stripe_unit 的选择。
stripe_unit 大小是写入数据块的数据量，然后对象的下一部分写入下一个 OSD 上的下一个块。条带是条带中条的集合，这些条也构成了在 OSD 丢失事件中保护数据的编码奇偶校验。

在社区中，stripe_unit 通常被称为chunk。在本文中，stripe_unit 与 chunk 大小同义。

选择纠删码配置文件

用户主要使用副本数为 3 的存储池进行块和文件工作负载。副本数为 3 的存储池在不同的 OSD 上存储 3 份数据副本，因此可以在两个 OSD 故障而不丢失数据的情况下继续运行。最常见的双重故障是驱动器故障加上另一个驱动器上的介质错误。副本数为 3 的存储池具有 300% 的存储开销——每 3GB 原始容量只能存储 1GB 应用程序数据。

使用纠删码存储池时，您可以创建一个纠删码配置文件，选择K+M的值。纠删码存储池所需的最小 OSD 数量是K+M，与副本数为 3 的存储池一样，建议这些 OSD 位于不同的服务器上以实现容错。M的选择定义了您的冗余程度，M = 2意味着您可以承受两次 OSD 故障——与副本数为 3 的存储池相同。纠删码存储池的存储开销是(K+M / K)，因此 4+2 存储池的存储开销是 150%。

本文重点介绍M = 2的纠删码性能，因为它提供与副本数为 3 的存储池相同级别的保护。

读取优化（部分读取）

在 Squid 中，对条带中单个条带的读取会读取整个条带，从条带数据中提取客户端请求所需的必要数据，然后丢弃其余数据。对于小读取，纠删码配置文件中K值（数据条带）越大，浪费到 OSD 的 IO 就越多。

在 Tentacle 中，部分读取是一项改进，只读取最少的数据以满足客户端请求。这项改进有两个好处，首先，性能读取不受K增加的影响，并且您的驱动器介质将通过减少浪费的 IO 获得更好的利用率；其次，通过更大的 stripe_unit，客户端读取只需读取条带的一部分，并且来自其他 OSD 的带宽浪费会更少。

这意味着在 Tentacle 中，通过快速 EC，您现在可以选择使用更高的K值，从而获得更好的容量利用率，而不会出现 Squid 中遇到的性能损失。

空间效率提升 - 小对象填充

在 Squid 中，小对象会被填充到整个条带，这导致了空间浪费以及由于不必要的写入多个 OSD 而导致的写入性能损失。Fast EC 不会将小对象填充到整个条带，而是将对象写入其所需的条带，从而提高了性能并节省了容量。

将 stripe_unit 大小增加到 16k

stripe_unit 小会增加客户端 I/O 被拆分成多个请求发送到不同 OSD 的可能性。对于大 I/O（例如 1MB 读取），将 I/O 拆分成更小的请求并行处理到不同的 OSD 具有性能优势。对于小 I/O，拆分 I/O 只会增加驱动器、CPU 和网络的负担，并降低性能。

增加 stripe_unit 可以减少处理小 I/O 的开销，同时仍然可以拆分大 I/O 并获得性能优势。

在 Squid 及更早版本中，stripe_unit之所以小，有两个原因：

1. 缺乏部分读取支持，这实际上阻碍了 stripe_unit 大小的增加，因为更大的K值和更大的 stripe_unit 意味着 4-16k 的读取会导致 OSD 的 IO 浪费更大。

2. EC 曾经将所有对象填充为条带大小的倍数。更大的 stripe_unit 意味着更多的填充，从而浪费存储容量。

性能和容量使用之间仍然存在权衡。将 stripe_unit 增加到 16K 以上，甚至可能高达 256K，会进一步提高性能，但对于小文件或对象仍会浪费存储容量。选择 16K 作为 stripe_unit 是一个很好的折衷方案——它提供了与旧 EC 非常相似的容量利用率，但性能更好。

Tentacle 中默认的 stripe_unit 仍然是 4K，但我们建议您在为新的快速 EC 存储池创建时指定 16K 的 stripe_unit，以获得更大的性能提升。

对于现有存储池，无法更改 stripe_unit，这些存储池仍然可以启用快速 EC，但性能提升会略小。

写入优化

部分写入

在 Squid 中，所有子条带写入都通过读取整个条带，合并来自客户端的新数据，编码新的奇偶校验并写回条带（数据和编码奇偶校验）来处理。

这意味着 EC 更适用于大块和大对象工作负载，但对于小对象或小写入工作负载（例如 CephFS 或事务性工作负载）则不是最优的，因为对于小写入，更大的K值意味着 I/O 操作会被放大。

部分写入只读取未被写入的数据条带，编码新的奇偶校验，并只写回修改过的数据和奇偶校验条带。

这项优化意味着对于小写入和大的K值，Fast EC 节省了读取和写入条带中未更改数据的驱动器操作。

奇偶校验增量写入

奇偶校验增量写入 (PDW) 基于 Fast EC 中的部分写入改进。

块存储控制器（实现 RAID-5 和 RAID-6）常用的一种技术是实现奇偶校验增量写入。当条带的一小部分被覆盖时，可以通过读取旧数据，将其与新数据进行 XOR 运算以创建增量，然后读取每个编码奇偶校验，应用增量并写入新奇偶校验来执行更新。这种技术的优势在于它可以涉及更少的 I/O，特别是对于具有较大K值的K+M编码。该技术不特定于M = 1和M = 2，它可以应用于任意数量的编码奇偶校验。对于M = 2，此技术涉及对客户端请求中的每个条带执行 3 次读取和 3 次写入，然后通过缓存合并对奇偶校验的更新，以最大程度地减少条带内奇偶校验更新的数量。（对于M = 1，每次写入需要 2 次读取和 2 次写入）。

在某些情况下，根据K的值和写入操作的大小，不使用 PDW 可能更有利。

Fast EC 中 PDW 的实现会为每个 I/O 动态调整写入技术，以实现最佳写入性能。

这是一个配置文件与写入大小的示例表，仅供说明：

纠删码stripe_unit写入大小PDW 写入PDW 关闭 (部分写入)2+2 16k 4 到 16k 3 读+3 写1 读+3 写4+2 16k 4 到 16k3 读+3 写3 读+3 写 6+2 16k 4 到 16k3 读+3 写5 读+3 写 6+2 16k 32k4 读+4 写4 读+4 写 8+2 16k 4 到 16k3 读+3 写7 读+3 写 8+2 16k 32k4 读+4 写6 读+4 写

图 1：解释使用 PDW 和部分写入技术的写入开销表

突出显示的文本表示该场景下更有效的方法。

在 PDW 开启和关闭（即使用部分写入方法）时，I/O 操作总数相同的情况下，FastEC 会倾向于使用 PDW，因为读写同一个 OSD 比读写不同 OSD 更高效，因为 bluestore 会缓存元数据。

性能结果

为了本文的目的，我们使用单个节点运行了性能测试。在单个节点上运行意味着没有网络瓶颈，我们可以专注于 CPU 和驱动器瓶颈。绝对性能测量不会很出色，但我们仍然可以比较相对性能，因为优化将证明我们在受 CPU 或驱动器限制的工作负载中提取了更多性能。

系统配置如下：

单节点 – 8 个 OSD - NVME 闪存
2 x Intel(R) Xeon(R) Platinum 8276M CPU @ 2.20GHz – 每个插槽 28 个核心
LibRBD FIO 客户端 – 16 个卷 – 每个 RBD 卷一个客户端
ISAL 插件

如何理解响应曲线

对于接下来的部分，我需要解释一下响应曲线（也称为曲棍球棒曲线）。

响应曲线绘制了每秒 I/O 操作数 (IOPs) 与延迟之间的关系。从图表的左下角开始，预期是随着存储系统队列深度的增加，IOPs 也会增加。在曲线的某个点，也称为“膝部”，这是饱和点，此时吞吐量不再增加，并且向存储系统队列添加额外的工作只会增加延迟。这就是产生“曲棍球棒”形状曲线的原因。

对于曲线的每个点，I/O 工作负载以指定的队列深度运行几分钟，然后计算平均 IOPs 和延迟。通常为 3 到 5 分钟（带有预热期）。

饱和点是系统特定的，并且根据工作负载，导致达到此限制的原因可能有很多，例如 CPU、CPU 核心、驱动器、网络接口或软件中的某些软件资源限制等等。

通常，响应曲线用于客户端系统大小估算，以了解所售系统的限制并评估系统还剩下多少 headroom。通常，客户端不会超过最大吞吐量的 70% 左右，以留出足够的扩展 headroom。曲线开始到“膝部”的平线表明延迟与吞吐量和延迟的低方差一致。

在比较响应曲线时，不可避免地会存在一些差异，通常在 5% 到 10% 左右。

现在，让我们继续讨论 Tentacle 中 Fast EC 改进的性能，以便解释下一节和本文中所有其他图表的图例，例如：

squid-ec-6+2-4K表示我们正在运行 Squid 构建，使用 6+2 配置文件和 4K stripe_unit 的纠删码。因此，这些图表正在比较具有 4K stripe_unit 6+2 纠删码的 Squid 构建与启用 FastEC 并具有 16K stripe_unit 和 6+2 配置文件的 Tentacle 构建。还有其他图表使用不同的纠删码配置文件。

写入结果 - 小写入

图 3：小写入 - Squid 4k 6+2 EC 与 Tentacle 16k Fast EC 6+2 对比小写入常见于 Ceph FS、RBD 和小对象工作负载。

在图 3 中，我们首先比较了 Squid 4k stripe_unit 6+2 纠删码与启用 FastEC 的 Tentacle 16k stripe_unit 6+2 配置。这是一个小型系统，单个节点有 8 个 OSD。无论如何，20K IOPS 对于存储系统来说并不是一个特别大的吞吐量，但我们在这里感兴趣的不是绝对数值。我们感兴趣的是两种软件的相对性能，这突出表明我们可以在相同的延迟下将驱动器的吞吐量至少提高一倍，或者在某些情况下提高延迟。如果您想要更高的性能，可以向配置中添加更多的驱动器和节点。

6+2 配置中 Squid 4K 和 Tentacle 16k 之间的性能提升主要归因于 FastEC 的奇偶校验增量写入功能，如表 1 所述，该表比较了读/写操作的数量，具体取决于K的值和写入 I/O 请求的大小。

您选择的K会影响系统获得的性能。以下是一组图表，它们执行相同的 4/8/16k 随机写入测试，比较 2+2、4+2 和 6+2 EC 配置：

图 4：小写入 - Squid – EC 2+2、4+2 和 6+2 – 4k 与 Tentacle – FastEC 在 2+2、4+2、6+2 配置文件中的对比

此前在 Squid 中，写入性能随着K的增加而降低，原因是整个条带总是被读取和写入，这意味着对于更宽的纠删码（例如 4+2 和 6+2），开销会更高，性能会降低。将K增加到 6 以上会导致性能进一步下降。

对于启用 Fast EC 的 Tentacle，奇偶校验增量写入优化意味着更宽的纠删码性能随着K的增加而提高。性能预计不会超过 6+2。

我们将在本文后面讨论我们如何建议选择更大的K值，因为这可以提高存储效率并减少容量开销。

写入结果 - 大写入

图 5：大写入 - Squid 4k、Tentacle 16k 与 3 路副本对比

对于大写入和大型 S3 对象，与 Squid 相比，吞吐量略有增加，延迟更低。您可以预期，对于更大的 1Mbyte 对象，启用 FastEC 后将获得相同的性能，性能接近 3 路副本。

读取结果 - 小读取

图 6：小读取对比 4kstripe_unitSquid 6+2 EC 与 16k Tentacle 6+2 EC

小读取由于 Fast EC 中添加的部分读取功能而实现了 2-3 倍的改进。这对于 RBD、Ceph FS 和小对象工作负载非常有利。

图 7：小读取 - Squid 2+2、4+2、6+2 与 Tentacle 与 3 路副本对比

比较 Squid 和 Tentacle 之间不同的纠删码配置文件。

这些结果突出了以下观察：

对于 Squid，随着K从 2+2 -> 4+2 -> 6+2 增加。最大吞吐量下降，原因如本文前面所述，Squid 没有部分读取功能。随着K的增加，更多的数据在小读取操作中被丢弃，从而增加了 OSD 和 CPU 的利用率。
对于 Tentacle，随着K的增加，最大吞吐量会线性扩展，直到我们能够达到与 3 路副本几乎相同的读取性能。
Tentacle 和 3 路副本之间到非主 OSD 的读取延迟差异正在被重定向到主 OSD。

直接读取是 Ceph 未来版本中将推出的一项功能，它将消除到主 OSD 的跳转，从而使延迟与 3 路副本性能相当。

目前目标是 Umbrella 发布时间，关于此功能的博客将在未来发布。

读取结果 - 大读取

图 8：大读取 - 6+2 Squid 4K 与 Tentacle 6+2 16k 与 3 路副本对比

对于大读取、备份、大型 S3 对象和流式工作负载，使用 Fast EC 比 Squid 延迟略低，吞吐量大约增加 1.2 倍。

直接读取预计将显著进一步提高 EC 吞吐量，使其更接近 3 路副本，同时由于将大请求分解成块并并行向条带中的所有 OSD 发出 I/O，从而降低延迟。

写入追加结果

写入追加是指将新数据追加到现有对象的末尾。这通常在顺序写入、备份、AI 或 RGW PUT 工作负载中很常见。

图 9：写入追加 - Squid 4k 到 Tentacle 16kstripe_unit

这些结果突出了以下优势：

所有高达 512k 的写入延迟显著降低，1Mbyte 写入延迟适度改善。
对于高达 16k 的小块写入，IOPs 吞吐量显著增加。
对于 16k 到 64k 的写入，吞吐量也有适度增加。
512k 和 1Mbyte 写入性能没有下降，同时显著改善了延迟。

值得注意的是，增加K（例如，从 2+2 到 4+2/6+2）会增加延迟。原因在于，在 2+2 配置中，50% 的 I/O 是写入 PG 的主 OSD，而在 4+2 配置中，25% 的 I/O 是写入 PG 的主 OSD。写入非主 OSD 需要将请求转发到主 OSD，从而导致额外的消息传递跳跃操作。

混合读/写工作负载

图 10：混合 16k 70/30 - Squid 4k 与 Tentacle 16k 与 3 路副本对比

事务性和文件工作负载包含读写混合，通常是小块，70% 读取和 30% 写入，大小约为 16k。此图表包含典型的 70/30 16k 混合工作负载。

与 Squid 相比，FastEC 的吞吐量至少翻了一番。三路副本仍然更快，但是与使用 Fast EC 的 6+2 16k stripe_unit 纠删池相比，它的性能约为 50%，但是您需要考虑到 6+2 纠删码只有 33% 的开销，而三路配置需要 3 倍的物理容量。三路副本是比使用 EC 昂贵得多的选项。因此，6+2 形式的 EC 具有比三路副本更好的成本效益比。

在相同的存储系统上，以写入为主的 EC 工作负载（由于 3 次读取/3 次写入）的性能永远不会像副本那样好，纯粹是因为物理定律和 EC 算法需要比副本执行更多的 I/O。但是，您可以通过减少物理容量来抵消此成本，并相应地重组存储。

重要的是要注意，传统的存储控制器通常提供 RAID-1（镜像）和 RAID-6（纠删码 K+2）之间的选择，并且它们也具有相似的成本性能权衡。

使用更广泛的纠删码（例如 6+2）需要 9 个节点，因此您可能需要向 Ceph 集群添加更多节点。然而，存储解决方案的成本通常主要由您安装用于存储数据的驱动器成本决定，特别是如果您使用闪存。使用纠删码，您可以以不到一半的成本获得一半的性能，从而有机会进行横向扩展，以构建与副本相同级别的性能。

总结

EC 性能增强的目标是使性能足够好，使其能够用于块和文件存储，特别是考虑到使用 EC 替代 3 路副本的成本效益比优势。

在大多数情况下，用户在选择K的值时不应考虑性能。用户应使用更高的K值（例如 6+2）以获得更好的存储效率，同时保持与副本相同的冗余度。

在 6+2 配置中使用 Fast EC，您可以利用这些节省来增加节点数量，在节点之间重新分配驱动器，并实现与三路副本相同的性能，同时仍然节省资金。

Tentacle 中的 Fast EC 功能通过允许您使用纠删码作为一种替代且更节省空间的方法来存储数据，与副本池相比，具有显著更好的成本性能比，从而降低了 Ceph 集群的总拥有成本。

我希望这篇博客能帮助您了解 Fast EC 的性能优势。团队正在努力进行更多改进：