测试Reef：RGW工作负载中的吞吐量和恢复

2023年10月27日 Laura Flores

简介 ¶

我们邀请您阅读名为“测试Reef”的博客系列文章的第一期——在这个系列中，我们将解释我们如何在各种场景下测试上游Reef，以衡量其功能和性能与Quincy基准线的对比。

本文中的所有结果均由Storage Workload DFG团队提供。请继续阅读，了解我们如何通过填充RGW集群、老化集群、诱发节点故障并启动恢复来收集最新的吞吐量和恢复结果，从而测试Reef。

测试计划 ¶

以下测试旨在验证RADOS和RGW功能，并衡量大规模下的基准性能。所有测试均在上游版本的Reef（18.1.2）上执行，并在上游版本的Quincy（17.2.6）上重复执行，以进行比较。使用了两种对象大小集合：较小的对象大小工作负载使用五个Warp驱动程序，范围为固定大小（1KB、4KB、8KB、64KB、256KB），每个存储桶一个大小，而更通用的对象大小（1MB、4MB、8MB、64MB、256MB）则相反。

测试周期 1：RGWtest 工作负载 ¶

此测试周期填充 RGW 集群，并测量集群为新集群时的性能，以及集群老化几个小时后的性能。此测试周期在小对象和通用对象大小上执行。以下几点描述了测试周期的每个步骤

集群填充 - @4小时
1小时混合工作负载测量新集群（45% 读取，35% 写入，15% 统计，5% 删除）
混合老化工作负载
1. 相同的操作比例
2. 较小对象 24小时，通用对象 12小时
1小时混合工作负载测量老化集群

测试周期 2：OSDfailure 工作负载 ¶

此测试周期填充 RGW 集群，并测量在各种节点故障场景下的性能和恢复时间。此测试周期在小对象和通用对象大小上执行。以下几点描述了测试周期的每个步骤

集群填充 - @4小时
2小时混合工作负载 - 无故障
2小时混合工作负载 - 停止一个OSD节点（24个OSD）
2小时混合工作负载 - 停止另一个OSD节点（24个OSD）
2小时混合工作负载 - 启动缺失的OSD
监控恢复，直到所有PG处于active+clean状态

测试环境 ¶

以下几点显示了我们的测试场景中使用的硬件、软件和工具。测试在两个集群上运行，每个集群有 8 个 OSD 和 4096 个 PG。我们在最新的上游Quincy版本（17.2.6）上运行每个测试场景以收集基准，然后在Reef上游（18.2.1）上运行以收集比较结果。使用 minio warp 工具生成和收集结果。

硬件 ¶

3x MON / MGR 节点
- Dell R630
- 2x E5-2683 v3（总共 28 个内核，56 个线程）
- 128 GB RAM
8x OSD / RGW 节点
- Supermicro 6048R
- 2x Intel E5-2660 v4（总共 28 个内核，56 个线程）
- 256 GB RAM
192x OSD（bluestore）：每个节点 24 个 2TB HDD 和 2 个 800G NVMe 用于 WAL/DB
池：site{1,2}.rgw.buckets.data = EC 4+2, pgcnt=4096
五个warp驱动节点，每个节点运行多个客户端

软件 ¶

RHEL 9.2 (5.14.0-284.11.1.el9_2.x86_64)
Quincy 上游 (17.2.6) 与 Reef 上游 (18.1.2) 进行比较
非默认设置
- log_to_file true
- mon_cluster_log_to_file true
- rgw_thread_pool_size 2048
- rgw_max_concurrent_requests 2048
- osd_memory_target 7877291758
- osd_memory_target_autotune false
- ceph balancer off
- PG autoscaler pg_num_min
  - 4096 data
  - 256 index
  - 128 log/control/meta