用于大规模 Red Hat Ceph Storage 性能测试的工具
作者 Chris Blum
一个 博客系列 去年发布，记录了 Red Hat 在 Dell EMC 服务器上对 Red Hat Ceph Storage 性能进行的大量测试。这项工作，也描述在 性能和容量规划指南 中，并得到了 Dell Technologies 和 Intel Corporation 的贡献，评估了许多影响 Red Hat Ceph Storage 性能的因素，包括
- 确定固定大小集群的最大性能
- 将集群扩展到超过 10 亿个对象
- 调整 Dell EMC 测试集群以实现最大的 Red Hat Ceph Storage 性能
在其他参数中，Red Hat 工程师研究了 Ceph RADOS Gateway (RGW) 大小、动态存储桶分片、Beast 与 Civetweb 前端以及擦除编码的fast_read 与标准读取对大型和小型工作负载的影响。
这项测试和评估需要一套高级工具。开发了许多脚本和工具来简化测试过程并提供对关键性能指标的可视性。本帖的目的是分享这些工具，以防它们有助于表征 Ceph 在其他研究中的性能。以下部分中描述的这些工具，旨在增强现有的性能表征框架，包括
Grafana 导向的工具 ¶
本节中的工具要么将新数据传递到 Grafana，要么提供查看数据的新方式。
RGW textfile 收集器 ¶
与 Ceph Manager Daemon 捆绑在一起的通用 Ceph 导出器不包含我们想要查看的所有信息。一开始，我们只有 Ceph RADOS 对象数量的信息。相反，我们希望深入了解 Ceph RGW 存储桶中的对象总数。我们还想了解每个存储桶的分片数量。这些数据对于 10 亿对象测试尤其有趣，我们发现了一些会暂时降低集群性能的重新分片事件。
为了获得这种可见性，我们开发了一个名为 RGW textfile 收集器的工具。它用 Python 3 编写，只有 50 行代码。该工具有意保持较小，以便于扩展。为了收集信息，我们使用 RadosGW Admin API 通过 Python 库 RGWAdmin。然后，使用官方 Python prometheus_client 库 呈现这些信息。该库支持多种方式来使信息可供 Prometheus 使用。为了简化此过程，我们决定将信息写入 textfile，以便使用现有的 node_exporter 进行解析和导出。这种方法的好处是，无需更改 Prometheus TSDB 抓取配置即可使用该信息进行解析。
通过 textfile 导出的示例指标包括
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 textfile 收集器的源代码可以在 此处 找到。
COSBench 注释 ¶
大规模测试可能很复杂，尤其是在要测试的配置位于不同的大陆上和/或由其他人安装时。当测试团队试图了解当前限制 COSBench 测试的组件时，我们必须将 COSBench 开始时间（如通过控制器网站呈现）与 Grafana 仪表板进行比较。
不幸的是，COSBench 不理解时区。它始终假定主机上的本地时间是正确的时间，而 Grafana 默认使用浏览器时区查看仪表板。这种差异导致在试图了解某些性能峰值是由测试引起的还是 Ceph 正在执行常规维护时出现明显的问题。
为了解决这个问题，我们开发了一个 COSBench 注释工具，采用小型 Python 脚本的形式，该脚本解析 COSBench 控制器的run-history.csv 文件，并使用 Grafana API 在测试开始和停止时设置注释。该脚本编写为与 Python 2 和 3 兼容，以提高其可移植性。该工具使用“bench”标签进行注释。一旦显示在仪表板上，输出类似于图 1。
图 1. Grafana 仪表板中的 COSBench 注释
如图 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 对象计数。该工具的输出是 CSV 表示形式的 COSBench 工作负载 ID、描述以及使用分号作为分隔符的运行前后的对象总数。
该工具的源代码可以在 此处 找到。
GOSBench 分布式简单存储服务 (S3) 性能测量工具 ¶
COSBench 非常适合测试分布式对象存储。同时，它具有一些非最优特性，迫使测试团队花费更多的时间来完成计划的测试。这些问题从安装开始，并在编写测试配置时持续存在。
为了解决这些问题，团队开始编写一个新工具，旨在取代 COSBench，同时让测试人员的生活更轻松。我们给这个新工具命名为 GOSBench，因为它是用 Golang 编写的。与 COSBench 的一些主要区别包括
- GOSBench 用 Golang 编写，因此作为静态二进制文件提供。
- 测试配置是隐式的而不是显式的。
- 测试配置以 YAML 格式编写。
- 性能指标作为 Prometheus 导出器端点提供。
- 性能指标自动排除准备步骤。
- 负载生成节点消耗的系统资源更少。
- GOSBench 可以比 COSBench 更有效地对集群进行压力测试。
虽然该工具达到了我们可以用它来执行所有 COSBench 测试的成熟度水平，但团队决定继续使用 COSBench 进行这组测试，以便与早期工作保持一致且可比较的测试结果。此外，团队运行了可比较的 COSBench 和 GOSBench 测试，以查看性能数字是否匹配。
测试团队希望社区可以添加一些较小的可选功能，这些功能列在 TODO.md 文档中。在一些早期的 Red Hat 内部反馈的帮助下，测试团队能够识别出一些 COSBench 用例，这些用例不容易或明显地用 GOSBench 解决。为了收集集成到 GOSBench 的候选对象，团队在 GitHub 存储库中创建了一个 问题列表。
图 2 和图 3 显示了 GOSBench 测试运行的屏幕截图。图 2 是 GOSBench 服务器的输出，图 3 显示了 Red Hat 测试中使用的七个 GOSBench 工作节点之一的输出。从这个输出可以看出，每个工作节点都经过几个阶段，特别是
- 最初连接到服务器（工作节点接收 S3 连接详细信息及其工作负载）
- 使用连接详细信息准备工作负载
- 处理工作负载
- 重新连接到服务器以接收新的工作负载
服务器将确保所有工作节点（即使它们不在同一主机上）的准备和性能测试阶段同步，并在所有工作节点完成当前工作负载后才开始更多测试。
GOSBench 的源代码可在 此处 找到。
图 2. GOSBench 服务器输出
图 3. GOSBench 工作节点输出
GOSBench 仪表板 ¶
与许多其他工具不同，GOSBench 不会将指标输出到命令行。相反，它提供了一个 Prometheus 导出器端点，以便可以对其进行抓取。此导出功能由 OpenCensus 库 提供，该库充当 AWS SDK 的 HTTP 客户端。
为了理解这些指标并收集类似的数据，我们创建了一个 Grafana 仪表板。当 Grafana 时间窗口设置为测试的执行时间时，它会显示为 COSBench 处理的相同指标。最终，GOSBench 将设置 Grafana 注释，以便更容易地获得正确的时间窗口。目前，正确的时间窗口设置会打印到 GOSBench 服务器的 stdout。这些 POST 变量可以附加到 Grafana URL。图 4 显示了一个仪表板摘录示例。
图 4. GOSBench Grafana 仪表板
GOSBench Grafana 仪表板的源代码可以在 这里 找到。
COSBench 和 GOSBench 基准测试比较 ¶
当提出一种新工具时，为了确保准确性，将其与现有工具进行比较至关重要。因此，团队运行了 COSBench 和 GOSBench 之间的一个简单比较。这两个工具都被要求对 64KB、1MB 和 32MB 对象执行 100% 读取测试和 100% 写入测试，每个测试持续 300 秒。测试工具被设置为并行运行测试配置中的所有七个 RGW。图 5 和图 6 分别显示了写入和读取。
图 5. COSBench 与 GOSBench 在七个 RGW 上的写入
图 6. COSBench 与 GOSBench 从七个 RGW 上的读取
从这些图表中可以看出，对于两个工具而言，64KB 和 1MB 对象的性能指标相似。对于 32MB 对象，COSBench 报告的性能指标明显高于 GOSBench。一种可能的解释是 GOSBench 正在使用多分块上传和下载。此功能对于小于 5MB 的对象无效，因此仅在 32MB 对象上可见。截至撰写本文时，我们仍在调查此问题。
结论 ¶
作为 Red Hat 测试的一部分开发的工具为测试人员提供了对复杂的大规模测试细节的更多可见性。测试人员能够使用 Grafana 和 COSBench 工具快速可视化性能问题的影响，例如磁盘容量过载，并更轻松地协调被测远程系统之间的时序。虽然工作仍在进行中，但 GOSBench 有望减少设置测试安装和编写测试配置所需的时间。