用于大规模红帽 Ceph 存储性能测试的工具

去年推出的一个博客系列记录了红帽在 Dell EMC 服务器上对红帽 Ceph 存储性能进行的广泛测试。 这项工作也在性能和规模调整指南中进行了描述，并得到了戴尔科技公司和英特尔公司的支持，评估了影响红帽 Ceph 存储性能的许多因素，包括：

• 确定固定大小集群的最大性能
• 将集群扩展到超过 10 亿个对象
• 调整 Dell EMC 测试集群以获得最大红帽 Ceph 存储性能

在其他参数中，红帽工程师研究了 Ceph RADOS 网关 (RGW) 规模、动态存储桶分片、Beast 与 Civetweb 前端以及纠删码 fast_read 与标准读取对大和小对象工作负载的影响。

这种测试和评估需要一套先进的工具。 开发了许多脚本和工具来简化测试过程并提供对关键性能指标的可见性。 这篇文章的目的是分享这些工具，以防它们有助于表征其他研究中的 Ceph 性能。 在以下部分中描述，这些工具旨在增强现有的性能表征框架，包括：

• Grafana
• COSbench
• GOSbench

面向 Grafana 的工具

本节中的工具要么将新数据传送到 Grafana，要么提供查看数据的新方法。

RGW 文本文件收集器

与 Ceph Manager Daemon捆绑在一起的通用 Ceph exporter不包含我们想要查看的所有信息以进行测试。 一开始，我们只有关于 Ceph RADOS 对象数量的信息。 相反，我们想深入了解 Ceph RGW 桶中的对象总数。 我们还想了解每个桶的分片数量。 事实证明，这些数据对于 10 亿个对象的测试特别有趣，我们发现了几个暂时降低集群性能的重新分片事件。

为了获得这种可视化，我们开发了一个名为 RGW 文本文件收集器的新工具。 它是用 Python 3 编写的，只有 50 行长。该工具有意保持很小，以便于扩展。 为了收集信息，我们通过 Python 库 RGWAdmin 使用 RadosGW Admin API。 然后使用官方的 Python prometheus_client 库呈现信息。 该库支持多种方式向 Prometheus 提供信息。 为简化此过程，我们决定将信息写入文本文件，以便可以使用现有的 node_exporter 对其进行解析和导出。 这种方法的好处是信息可用于解析，而无需更改 Prometheus TSDB 抓取配置。

通过文本文件导出的示例指标包括：

radosgw_bucket_actual_size

{id="[…]",name="[…]"} 1.201144430592e+13

radosgw_bucket_number_of_objects

{id="[…]",name="[…]"} 1.83280095e+08

radosgw_bucket_number_of_shards

{id="[…]",name="[…]"} 2061

radosgw_bucket_shard_hash_type

{id="[…]",name="[…]"} 0

radosgw_bucket_size

{id="[…]",name="[…]"} 1.172992608e+13

radosgw_bucket_info

{id="[…]",index_type=“Normal”,name="[…]",owner=“s3user1”, placement_rule=“default-placement”} 1

RGW 文本文件收集器的源代码可以在这里找到。

COSBench 注释

大规模测试可能很复杂，尤其是当要测试的配置位于不同的地方和/或由其他人安装时。 当测试团队试图了解当前哪个组件限制了 COSBench 测试时，我们必须将 COSBench 开始时间（通过控制器网站提供给我们）与 Grafana 仪表板进行比较。

不幸的是，COSBench 不了解时区。 它始终假定主机上的本地时间是正确的时间，而 Grafana 在查看仪表板时默认使用浏览器的时区。 当试图了解某些性能峰值是由测试引起的还是 Ceph 进行日常维护时，这种二分法导致了明显的问题。

为了解决这个问题，我们开发了一个以 Python 小脚本形式出现的 COSBench 注释工具，它解析 COSBench 控制器的 run-history.csv 文件，并在测试开始和停止时使用 Grafana API 设置注释。 该脚本被编写为与 Python 2 和 3 兼容，以使其更具可移植性。 该工具使用标签“bench”作为注释。 在仪表板中可见后，输出类似于图 1 中的输出。

如图 1 所示，在 COSBench 测试内部和外部都出现了磁盘利用率的峰值。 这些峰值表明 Ceph 正在执行维护任务并暗示测试不会使磁盘性能负担过重。 需要注意的一件事是 Grafana 的内置注释在大规模时效果不佳。 缩小到更大的时间窗口仅显示部分注释。 如果更大的规模很重要，则可以使用外部注释源（例如，Prometheus 查询）。

可以在此处找到 COSBench 注释工具的源代码。

COSBench 运行概览

一旦 Grafana 注释就位，就很容易看到测试何时开始和停止。 但是，确定何时执行某个测试仍然很麻烦。 测试团队选择从控制器的网站对测试时间进行动画查询，将其转换为本地时区（或协调世界时，UTC），然后在 Grafana 中设置时间窗口。 我们开发了一个 17 行 Python 脚本，用于读取控制器的 run-history.csv 中 COSBench 工作负载的执行时间。 然后将这些日期/时间对象转换为 UNIX 时间（由 Grafana 内部使用），并生成一个 Grafana 链接，该链接在 COSBench 执行前后填充一分钟。

结果是一个 HTML 文档，其中每个 COSBench 测试都表示为指向 Grafana 仪表板概览的直接链接。 正确的时间窗口是预先设置好的。 虽然您可能并不总是想要访问概览，但您可以浏览到其他仪表板，同时在使用此链接时保持时间窗口锁定。

可以在此处找到 COSBench 运行概览工具的源代码。

面向 COSBench 的工具

在运行 10 亿个对象的测试时，测试团队必须将其 COSBench 测试的性能指标与 Prometheus 收集的信息结合起来。 因此，我们需要在每次 COSBench 运行前后收集 Prometheus 指标。 例如，Prometheus 在任何给定时间包含集群的确切总 RADOS 对象计数。

为了满足这一需求，该团队创建了一个小型 Python 3 工具，该工具将解析 COSBench 控制器的 run-history.csv 文件，将日期/时间信息转换为 UNIX 时间戳格式，最后对 Prometheus 执行查询以获取 RADOS 对象在那个精确时刻计数。 该工具的输出是使用分号作为分隔符的 COSBench 工作负载 ID、描述和工作负载前后总对象计数的 CSV 表示。

该工具的源代码可以在这里找到。

GOSBench分布式S3性能测量工具

COSBench 是测试分布式对象存储的理想选择。 同时，它有几个非最佳特性，迫使测试团队花费更多的时间来完成计划的测试。 这些问题从安装开始，并在编写测试配置时继续。

为了解决这些问题，该团队开始编写一个新工具，该工具旨在取代 COSBench，同时让测试人员的生活更轻松。 我们将这个新工具命名为 GOSBench，因为它是用 Golang 编写的。 与 COSBench 的一些主要区别包括：

• GOSBench 是用 Golang 编写的，因此作为静态二进制文件提供。
• 测试配置是隐式的而不是显式的。
• 测试配置是用 YAML 编写的。
• 性能指标可作为Prometheus exporter端点使用。
• 性能指标自动排除准备步骤。
• 在负载生成节点上消耗的系统资源更少。
• 与COSBench 相比，GOSBench 对集群的压力更大。

虽然该工具达到了我们可以将其用于任何 COSBench 测试的成熟度水平，但团队决定继续使用 COSBench 进行这组测试，以便获得与早期工作一致且可比较的测试结果。 此外，该团队还运行了可比较的 COSBench 和 GOSBench 测试，以查看性能数据是否匹配。

测试团队希望社区可以添加一些较小的可选功能，这些功能列在 TODO.md 文档中。 在一些早期红帽内部反馈的帮助下，测试团队能够识别出某些使用 GOSBench 无法轻松或明显无法实现的 COSBench 用例。 为了收集集成到 GOSBench 的候选者，该团队在 GitHub 存储库中创建了一个问题列表。

图 2 和图 3 显示了示例 GOSBench 测试运行的屏幕截图。 图 2 是 GOSBench 服务器的输出，图 3 显示了 Red Hat 测试中使用的七个 GOSBench worker节点之一的输出。 从这个输出中，很明显每个worker经历了几个阶段，特别是每个阶段：

• 最初连接到服务器（worker节点接收 S3 连接详细信息及其工作负载）
• 使用连接详细信息为工作负载做准备
• 处理工作负载
• 重新连接到服务器以接收新的工作负载

服务器将确保准备和性能测试阶段在所有worker之间同步（即使他们不在同一主机上），并会等到所有worker完成当前工作负载后再开始更多测试。

GOSBench 的源代码可在此处获得。

GOSBench仪表板

与许多其他工具不同，GOSBench 不会将指标输出到命令行。 相反，它提供了一个 Prometheus exporter端点，因此可以对其进行抓取。 此导出功能由 OpenCensus 库提供，该库充当 AWS SDK的 HTTP 客户端。

为了理解这些指标并收集类似的数据，我们创建了一个 Grafana 仪表板。 当 Grafana 时间窗口设置为测试的执行时间时，它会显示为 GOSBench 处理的相同指标。 最终，GOSBench 将设置 Grafana 注释，以便更容易地正确获取时间窗口。 目前，正确的时间窗口设置由 GOSBench 服务器打印到标准输出。 这些 POST 变量可以附加到 Grafana URL。

可以在此处找到 GOSBench Grafana 仪表板的源代码。

COSBench 和 GOSBench 基准比较

当出现新工具时，必须将其与现有工具进行比较以确保准确性。 为此，团队对 COSBench 和 GOSBench 进行了简单的比较。 这两个工具的任务是对 64KB、1MB 和 32MB 的对象进行 100% 读取测试和 100% 写入测试，每个测试时间为 300 秒。 测试工具设置为在测试配置中的所有七个 RGW 上并行运行。

从这些图表中可以明显看出，64KB 和 1MB 对象的性能指标对于这两种工具是相似的。 对于 32MB 的对象，COSBench 报告的性能指标明显高于 GOSBench。 这种差异的一种可能解释是 GOSBench 正在使用分段上传和下载。 此功能对小于 5MB 的对象无效，因此仅对 32MB 的对象可见。 在撰写本文时，我们仍在研究这个问题。

结论

作为红帽测试的一部分而开发的工具使测试人员能够更好地了解复杂的大规模测试的细节。 测试人员能够使用 Grafana 和 COSBench 工具快速可视化性能问题的影响，例如磁盘容量过载，并更轻松地调整被测远程系统之间的时间。 在工作正在进行的同时，GOSBench 承诺减少设置测试安装和编写测试配置所需的时间。