Confluent Platform 与 MinIO 分层对象存储吞吐量基准测试

Confluent、Intel 和 MinIO 对 MinIO 分层对象存储进行了基准测试和认证测试，用于 Kafka 存储。这篇博文描述了测试 MinIO 对象存储作为 Confluent Platform 7.1.0 的分层存储功能的后端在配备第三代英特尔至强可扩展处理器的服务器上的观察结果和测试结果。这些测试的范围是观察 MinIO 对象存储在来自与分层存储相关的 Kafka 代理的大量工作负载下的读、写和删除性能。

Confluent Platform 是一个全面的数据流平台，使您可以轻松地访问、存储和管理数据作为连续的实时流。Confluent 完全支持 MinIO 对象存储作为分层存储层。分层存储通过减少运营负担和成本，使在 Kafka 中存储海量数据变得可管理。其理念是从数据处理中分离数据存储，允许两者独立扩展。使用 Confluent 分层存储，您可以将温数据发送到经济高效的 MinIO 对象存储，并分别扩展 Kafka 代理和存储以提高效率。这种组合使单个 Kafka 集群在最佳硬件上部署时能够扩展到 PB 级的数据。

使用 MinIO 对象存储的 Confluent 分层存储提高了 Kafka 的可扩展性、弹性和性能。使用分层存储，温层处理长期存储的弹性和吞吐量，而热层则依赖于快速的本地短期存储。以前，复制和重新复制会影响所有代理，从而降低性能。现在，由于计算和存储分离，代理现在仅复制热数据，而 MinIO 的擦除编码保护温数据。软件定义的 MinIO 为 Confluent Platform 提供无限存储。

我们的结果运行在 5 个 Kafka 代理和一个 8 节点 MinIO 集群之间的吞吐量测试，该集群在 40 Gbps 网络上具有 64 个 NVMe 驱动器，总结如下

基准测试环境

测试使用英特尔硬件进行。MinIO 服务器节点配置了 40GbE 网络和 NVMe 驱动器。

Kafka 管理节点由 3 台 Zookeeper 机器和 5 台测试工具机器组成。一台 Kafka 代理机器专门用于 Grafana 和 Prometheus。

对于测试的软件组件，我们使用了

分层获取基准测试

我们执行了Confluent 分层对象存储兼容性检查器 (TOCC) 过程中第 3 节“分层获取基准测试”部分列出的步骤。TOCC 框架用于评估对象存储与分层存储的兼容性。

进行的性能测试的范围是观察 MinIO 对象存储在以下来自与分层存储相关的 Kafka 代理的大量工作负载下的读、写和删除性能

1. 后台写入工作负载，用于将流数据从代理的本地磁盘（或页面缓存）归档到 MinIO 对象存储。
2. 流读取（获取）工作负载，用于为消费者的历史获取请求提供服务。
3. 后台删除工作负载，在数据保留期到期时删除 MinIO 对象存储中的流数据。

为服务读取的对象存储 API 性能的一个重要部分是它在重负载下服务范围获取读取请求的能力。此基准测试用于衡量对象存储在为基准测试生成的段提供范围获取请求时的性能。在此基准测试中，读取/写入对象存储的客户端不是 Kafka 代理，而是使用 Confluent 内部直接用于服务分层获取请求的一些核心库开发的自定义客户端。

对于从列表中选择的每个record_size_bytes：[500、50000、500000、1000000、2000000]，基准测试执行 60 次迭代，每次迭代都包含以下所有步骤集。然后，它测量在所有 60 次迭代中完成整个范围获取请求所花费的平均/最小/最大时间。

以下是基准测试每次迭代执行的步骤

1. 创建段并使用每个具有指定record_size_bytes的记录填充它，直到段大小达到 100MB。
2. 将生成的段上传到对象存储。
3. 分块获取段中 10MB 的范围。测量完成整个范围获取请求所花费的时间。
4. 将基准测试输出打印到标准错误。

MinIO 配置

MinIO 二进制文件已下载到每个服务器节点上，并按如下方式配置

# Remote volumes to be used for MinIO server.
MINIO_VOLUMES=http://data{1...8}/mnt/drive{1...8}/minio
# Use if you want to run MinIO on a custom port.
MINIO_OPTS="--console-address :9199"
# Root user for the server.
MINIO_ROOT_USER=minio
MINIO_STORAGE_CLASS_STANDARD=EC:4
# Root secret for the server.
MINIO_ROOT_PASSWORD=minio123
MINIO_PROMETHEUS_AUTH_TYPE="public"
MINIO_PROMETHEUS_URL=http://data1:9090
MINIO_PROMETHEUS_AUTH_TYPE="public"

网络性能

在几乎所有使用 MinIO 的情况下，网络都是瓶颈。MinIO 充分利用了可用的底层服务器硬件。在此测试中，单个 40 Gbps 网络连接了 Kafka 代理、Kafka 管理工具和 MinIO 服务器。

因此，可以从这些节点中的每一个获得的最大吞吐量为 5 Gbytes/秒。

有 8 个节点，因此理论上的最大 GET 吞吐量为 40 GB/秒，PUT 吞吐量为 20 GB/秒。我们的结果落在这些参数范围内。

运行 Confluent TOCC 性能测试

我们使用此处提供的说明部署并启动了 Confluent Platform。特别是，需要启动的组件是 Kafka 代理、ZooKeeper 和控制中心。

我们使用此处提供的说明在测试集群上启用分层存储。

我们部署了 Kafka 代理，以便它们在特定端口导出 JMX 指标。TOCC JAR 从此端口收集 JMX 指标，以便在分层存储正确性测试期间使用。

我们部署了Trogdor 以并行化测试和工作负载，以便在部署在多台机器（Kafka 管理节点类型）上的 Trogdor 代理上运行。对于并行生产-消费和保留工作负载，测试脚本利用 Trogdor 代理内置的ProduceBenchSpec 和ConsumeBenchSpec 来生成负载。对于并行分层获取基准测试和正确性测试，脚本利用上面描述的 TOCC JAR，使用代理内置的ExternalCommandSpec。

然后，我们使用以下工作负载运行分层获取基准测试

• 生产-消费工作负载
• 带有对象存储故障注入的生产-消费工作负载
• 保留工作负载

结果解读

第一次测试运行使用五个 Kafka 代理，每个代理配备一个 NVMe 驱动器，发现总吞吐量受 I/O 限制。

第二次测试运行为每个 Kafka 代理添加了 4 个 NVMe 驱动器以提高 I/O 吞吐量。在此测试运行期间，所有 Kafka 代理的 CPU 利用率为 30%-35%，I/O 利用率接近 100%。网络利用率非常接近 40Gbps 网络链路的 100%。同时，MinIO 节点的 CPU 利用率为 10%-15%，I/O 利用率为 40%。MinIO 的性能受到网络吞吐量的限制。

为了测试这个理论，我们添加了另一个 Kafka 代理，并在每个 Kafka 代理中添加了 3 个 NVMe 驱动器，从而产生了 6 个 Kafka 代理，每个代理有 8 个 NVMe 驱动器。MinIO 配置没有更改。网络利用率再次接近 100%。添加额外的 Kafka 代理并在每个 Kafka 代理中添加驱动器并没有提高整体吞吐量——事实上 Kafka 吞吐量下降了。

在这种情况下，40 Gbps 网络再次成为瓶颈，因为 MinIO 在读写方面都接近硬件性能。

结论

根据以上结果，我们发现 MinIO 完全能够提供 Kafka 数据的高性能无错误分层。配备 NVMe 驱动器的 8 个英特尔至强节点运行 MinIO，超过了每次测试中 Kafka 代理的吞吐量需求。我们发现 MinIO 比 Kafka 代理更有效地扩展。

最后，网络带宽的重要性怎么强调都不为过。虽然 MinIO 的性能会随着服务器数量的增加而近乎线性增长，但带宽通常会成为瓶颈，架构师应该牢记这些限制并据此进行构建。  

您可以下载基准测试的 PDF 文件 以进行进一步分析。下载 MinIO，如有任何疑问，请发送邮件至 hello@min.io 或加入我们的 Slack 社区。