40GiB/s S3 吞吐量与 22TB 旋转硬盘 - 第一部分

2024年5月15日 Paul Cuzner (IBM),Gregory Orange (Pawsey Supercomputing Research Centre)

时不时地，我们在澳大利亚的 Pawsey Supercomputing Research Centre 的朋友们会给我们提供机会，在开发者通常无法访问的硬件上测试 Ceph。

Pawsey Supercomputing Research Centre 为澳大利亚和国际研究人员提供跨众多科学领域的集成研究解决方案、专业知识和计算基础设施。Pawsey 主要使用 Ceph 进行对象存储，他们的 Acacia 服务提供数十 PB 的 Ceph 对象存储。Acacia 由两个生产 Ceph 集群组成：一个支持通用研究的 11PB 集群，以及一个专门用于射电天文学的 27PB 集群。

这一次，其中一个目标是评估 OSD 主机的不同部署架构：单插槽 1U 服务器，连接到 60 驱动的外部 SAS 存储盒。

我们首先定义了一些初始问题，以帮助指导我们的测试工作。

  • OSD drivespec 在定义密集节点和相对较小的 NVME 所需的定制配置时表现如何？
  • 仪表板功能（如 LED 控制）是否适用于外部存储盒？
  • 使用虚拟机作为 RGW 实例时有哪些注意事项？
  • 对于不同的 EC 配置和简单的 GET/PUT 工作负载，性能如何？
  • 密集节点在部署和管理方面是否存在任何问题？
  • Ceph 仪表板处理密集 OSD 节点的能力如何？*

正如您所见，这些问题涵盖了广泛的主题，为了避免读者疲劳，我们的观察结果将分为 3 篇博客文章，涵盖

  1. 安装、管理和架构验证
  2. 性能深度分析
  3. 扩展 RGW 实例

概述

时间紧迫？这里有一些环境和关键性能结果的预告。

我们学到了什么？

部署

请注意，在 18.2.1 之前，ceph-volume 无法使用外部存储盒提供的多路径设备。检查您的 Ceph 版本以及 device-mapper-multipath 的使用情况，如果您遇到问题！

我们的第一个挑战是 OSD 配置。块数据库的默认分配基于 OSD 的容量 - 在我们的例子中是 22TB。但是，每个 OSD 节点只有 4 个 1.6TB NVMe 驱动器 - 因此无法使用默认值。相反，我们使用了一个明确定义了块数据库空间和 OSD 与 NVMe 驱动器比例的规范文件。

service_type: osd
service_id: aio-hdds
placement:
  host_pattern: storage-13-09012
spec:
  block_db_size: 60G
  db_slots: 15
  data_devices:
    rotational: 1
  db_devices:
    rotational: 0

问题解决了，但随后我们遇到了第一个小插曲。我们发现将 OSD 部署到密集节点可能会在 cephadm 中遇到超时。在我们的例子中，它只发生了两次，但可能会令人恼火！Reef 中有一个修复程序，可以启用 mgr/cephadm/default_cephadm_command_timeout 设置，使其可由用户定义，但这尚未计划在 18.2.3 中“发布”。如果您计划使用密集存储盒，请记住这一点。

管理

集群部署完成后，我们的重点转向使用 CLI 和 GUI 管理集群。这些是我们的关注点

  1. 大量的 OSD 和每个节点的守护进程如何在 UI 中呈现？
  2. 在超过 1,500 个 OSD 的情况下，UI 的响应速度如何？
  3. 鉴于部署基于多路径设备，磁盘将如何呈现？
  4. 像 IDENTIFY（LED 控制）这样的工作流程是否适用于外部 HDD 存储盒？
  5. 外壳会如何影响正常的运维，例如维护和电源循环？

好消息是，一般来说，UI 可以很好地处理这么多主机和 OSD，LED 控制也工作正常！但是，还是遇到了一些障碍。

  • OSD 部署完成后，仪表板中的设备列表不再显示 HDD。这个问题归因于 ceph-volume 本身，它为 GUI 提供数据，以及 ceph orch device CLI 命令。该问题的跟踪器是 63862
  • 在 OSD 视图中切换页面速度很慢（3-4 秒）。您可以在 56511 中跟踪解决此问题的进度

还提出了一些 UX 增强建议

跟踪器组件描述状态
64171UI包括 crush 地图视图中的展开/折叠backlog
63864CLI显示每个节点的设备摘要Merged
63865UICPU 线程数报告不正确Merged

如前所述，此硬件基于通过 SAS 连接到 60 驱动器存储盒的 1U 服务器。虽然 Linux 中的 SAS 连接不是问题，但我们发现了一些值得注意的相关问题。

  • 在启动时，如果主机在存储盒之前达到“ready”状态，LVM 无法激活用于 OSD 的逻辑卷。结果是大量的 OSD 处于 down 状态。
  • Ceph 完全不知道外壳硬件的健康状况。在我们的电源循环测试期间，两个存储盒出现了故障。对于 Ceph 而言，这表现为 OSD 离线，但根本原因直到检查外壳上的状态指示灯才显现出来！

最后，在我们的数据分析过程中，我们遇到了一个问题，我们的监控报告的 put ops 远高于 warp 工具报告的数量，这使得协调 Ceph 数据与 warp 结果变得困难。提出了一个跟踪器 65131 来探讨发生了什么，罪魁祸首被确定：multipart 上传。对于大对象，warp 客户端使用 multipart 进行并行处理，正如您所期望的那样，Ceph 正在将每个“部分上传”报告为单独的 put op，从技术上讲确实如此。问题在于，RGW 没有一个相应的计数器来表示 put op 的整体完成情况 - 因此，您无法轻松协调客户端和 RGW 视图。

架构验证

由于 OSD 节点是单插槽机器，我们的起始策略是使用虚拟机来托管 RGW 守护进程，从而尽可能多地将 CPU 用于 60 个 OSD 守护进程。验证此设计决策是我们的下一个“站点”。

鉴于 PUT 工作负载通常更具挑战性，我们使用一个简单的 4MB 对象工作负载作为试金石。下图显示了我们最初令人失望的结果。甚至无法提供 2GiB 的吞吐量表明设计中存在重大瓶颈！

Ceph 性能统计信息没有显示任何问题，这并不奇怪，因为硬件本身没有问题。罪魁祸首不是 Ceph，而是托管 RGW 守护进程的超visor 上的 CPU 和网络限制！

查看 OSD CPU 使用率，我们发现即使每个主机有 60 个守护进程，OSD 主机也没有受到任何 CPU 压力。接下来 - 迅速切换到 RGW 协同定位策略，将 RGW 守护进程重新定位到 OSD 主机。我们还借此机会将工作负载生成器协同定位到 Ceph Index 节点。现在，相同的测试提供了更合适的起点。

正如您所见，采用协同定位策略可将 PUT 吞吐量提高 7 倍！

这是我们取得的第一个胜利，将影响 Pawsey 的生产部署策略。

在下一篇文章中，我们可能会为 Ceph 博客图表数量创造新的记录，因为我们将深入研究集群在各种对象大小和 Erasure Code (EC) 配置下的性能。