深入研究
在我们的 第一篇帖子 中，我们介绍了 Penguin Computing、Seagate 和 Red Hat 共同开发的项目，最终形成了 Penguin Computing DeepData 解决方案。 在本帖中，我们将从第一性原理出发，然后讨论驱动我们配置更改的一些硬件和软件技术细节。 特别是，我们将演示如何针对使用纠删码数据池的读取吞吐量进行优化。
第一性原理 ¶
存储机箱可最大化部署灵活性，使您可以调整存储服务器与存储机箱的比例。 这就能够微调每个驱动器可用的 CPU、内存和网络。 对于我们的测试，我们选择了能够放入标准深度机架中的最大 Seagate 存储机箱 - Seagate Exos 5U84。 每个机箱都装有 84 个 Seagate Exos X16 16TB SAS 驱动器，并与来自 Penguin Computing 的单个 Altus XE2214GT 机架服务器 配对。
在吞吐量和成本之间取得有效平衡可能具有挑战性。 我们知道我们希望尽可能地将存储介质推向其物理极限。 如果我们稍后确定需要相对于容量增加吞吐量，我们可以选择更改每个存储机箱的主机数量或选择较低容量的存储设备。 为了建立每个设备和每个系统的性能基准，并确保 SAS 拓扑中没有系统级别的瓶颈，我们使用 100% 随机读取 fio 工作负载，并使用各种 IO 大小和队列深度同时基准测试所有 84 个驱动器。 结果详见下表
我们从 之前的测试 中了解到，Ceph 即使使用相对较旧的 4TB 驱动器，也能够实现接近这些低级别结果的每驱动器性能指标。 我们之前实现的每驱动器性能归一化
- 使用 4+2 EC（纠删码）的每个 OSD 75.83 MB/s
- 使用 3 倍复制的每个 OSD 88 MB/s
当然，这个吞吐量是通过直接从 RADOS 读取实现的，而不是通过 Ceph 对象网关 (RGW) 读取，但我们推测，通过当前一代驱动器和周到的性能调整，可能在 100 MB/s 左右。
纠删码 ¶
Ceph 对象存储经常部署为使用纠删码数据池，该功能已在关键任务环境中使用了超过半个世纪。 相对于复制，纠删码更具成本效益，通常消耗一半的磁盘空间。 此外，它可以通过调整数据和奇偶校验块的数量以及它们在集群中的分布来提供增强的可用性和持久性。
但是，在读取时，纠删码池通常会生成更多的磁盘寻道。 我们知道之前测试中发布的 EC 和复制数字之间的差异至少可以部分归因于此。 例如，我们可以查看针对 4 MB 对象（RGW、RBD 和 CephFS 条带的默认对象大小）的单个 RADOS 读取操作产生的磁盘 IO 数量
- 从复制池读取 4MB = 1 个 HDD 的 1 个 4MiB IO
- 从 4+2 EC 池读取 4MB = 4 个 HDD 的 4 个 1MiB IO
对于整个对象读取，生成的 IO 数量等于用于数据池的纠删码配置的数据块 (K) 数量。 这就是为什么使用可被 4 整除的数据块数量在默认设置下是有利的——它确保数据块正确对齐。 例如，参与 6+3 纠删码数据池的 OSD 的数据设备将看到大小为 682.6 KB 的操作，而 RADOS 对象为 4MB。 最好让 RGW 创建 6 或 24MB 对象，以便命中数据设备的运算大小为 1 或 4MB。
在分析了 fio 结果表后，我们预计如果可以将 4MB IO 一直推送到磁盘而不是 1MB IO，则吞吐量将大幅增加。 我们知道调整我们的条带配置可以产生 4MB 数据块。 预期的结果将类似于具有默认设置的复制池的读取吞吐量。 使用纠删码池的写入吞吐量会更高，因为需要写入磁盘的位数会减少一半。
在寻找进一步优化更大 IO 的线索时，我们决定配置纠删码配置文件以针对每个 RADOS 对象创建一个大型 EC 条带。 我们通过将条带宽度（条带单元 * K）设置为预期的 RADOS 对象大小来实现这一点。 这种配置的缺点是，小于条带宽度的 RADOS 对象在编码之前将被零填充。 对于应用程序对持久存储在对象存储中的对象的大小具有高度控制权的工作负载，我们认为这是可以接受的。
回顾一下，调整 EC 条带可能不是实现我们观察到的吞吐量水平所必需的。 也就是说，我们可以通过引入诸如 EC 高效稀疏对象 和 EC 部分条带读取 等功能来提高大型 EC 条带的效率。 在未来的测试中，也可能尝试使用 Bluestore 压缩来消除在写入磁盘之前进行的填充，也许是通过应用于部分或空数据块的提示。
下周 ¶
从我们之前博客帖子中预览的结果可以看出，从第一性原理出发可以证明是非常有效的。 本帖的细节旨在帮助其他有兴趣从纠删码池中提取最大读取性能，甚至鼓励进一步开发和实验的人员。 在我们的下一篇帖子中，我们将详细介绍如何配置 Ceph 对象网关以实现最大读取吞吐量。