SUSE 企业存储在 Arm 上提供最佳 CephFS 基准

自 2006 年推出以来，Ceph 主要用于性能不是最关键方面的容量密集型用例。 由于该技术具有许多吸引人的功能，因此一直希望将 Ceph 的使用扩展到高性能计算等领域。 HPC 环境中的 Ceph 部署通常作为一个活动存档（第 2 层存储），位于另一个充当主存储层的并行文件系统后面。

我们已经看到 Ceph 技术的许多重大改进。 SUSE 和其他人对开源项目的贡献带来了新功能，大大提高了效率，并使基于 Ceph 的软件定义存储解决方案能够为越来越多的工作负载提供完整的端到端存储平台。

传统上，HPC 数据存储非常专业，以实现所需的性能。 随着最近 Ceph 软件和硬件以及网络技术的改进，我们现在看到了将 Ceph 用于 1 层 HPC 存储的可行性。

IO500 10 节点基准测试是 SUSE 展示我们生产就绪的软件定义存储解决方案的机会。 与其他一些排名较高的系统相比，我们进行基准测试的这个基于 SUSE Enterprise Storage Ceph 的解决方案是生产就绪的，所有安全和数据保护机制都已到位。

这是 Arm、Ampere、Broadcom、NVIDIA、Micron 和 SUSE 的团队合作，旨在构建一个可用于部署的经济高效、高性能的系统。

基准

IO500 的 IO 性能基准结合了多个带宽密集型和元数据密集型工作负载的分数，以生成综合分数。 然后使用该分数对各种存储解决方案进行排名。 请注意，当前的 IO500 基准并未考虑成本或生产准备情况。

根据客户端节点的数量，IO500 有两个列表。 第一个列表用于无限配置，第二个列表用于所谓的“10 节点挑战”。 （更多 IO500 详细信息）我们选择“10 节点挑战”进行这次基准测试。

我们之前的基准测试也是针对 10 节点挑战的，它在我们称为“Tigershark”的集群上得分为 12.43。 今年我们创建了一个名为“Hammerhead”的新集群，继续以鲨鱼为主题。

解决方案

用于 2019 IO500 基准测试的软件堆栈没有重大更新。 操作系统是 SLES 15 Service Pack 1，带有 SUSE Enterprise Storage 版本 6，基于 Ceph 版本“Nautilus”。

我们的目标是超越去年的 12.43 分（[11/19 IO500 列表](https://www.vi4io.org/io500/list/19-11/10node?fields=information__system,information__institution, information__storage_vendor,information__filesystem_type,information__client_nodes,information__client_total_procs,io500__score,io500__bw,io500__md,information__data,information__list_id&equation=&sort_asc=false&sort_by=io500__score&radarmax=6&query=)) 使用完全不同的硬件平台并验证基于 Arm 的服务器的性能。 我们认为，我们进行基准测试的任何系统都应该模拟客户可能部署的生产系统，因此在基准测试期间启用了所有适当的 Ceph 安全和数据保护功能。

我们今年使用的硬件有很大不同，尽管看起来非常相似。我们使用了联想HR350A系统，基于安培计算eMAG处理器。eMAG是一款单插槽32核ARM v8架构处理器。

基准测试是在一个由10个节点组成的集群上执行的，作为数据和元数据服务器。每台服务器有128GB的RAM和四个Micron 7300PRO 3.84TB NVMe SSD。这些NVMe SSD设计用于要求高吞吐量和低延迟的工作负载，同时保持在资本和功耗预算内。Broadcom在每个存储节点中提供了HBA适配器。

该集群与 Mellanox 的 [以太网存储结构 (ENF)] (https://www.mellanox.com/ethernet-storage-fabric) 网络解决方案互连。 NVIDIA 技术提供了一种高性能网络解决方案，可消除与传输大量数据相关的数据通信瓶颈，并且专为轻松横向扩展部署而设计。 ENF 在通过 SN3700 Spectrum 100GbE 交换机连接的每个节点中包含一个 ConnectX-6 100GbE NIC 。

技术参考架构链接

集群配置

SLES 配置

每个节点都设置为禁用 CPU mitigations。

网络配置设置为使用 MTU 为 9000 的 JUMBO 帧。我们还增加了 NIC 上的设备缓冲区并更改了一些 sysctl 参数。

我们对所有系统都使用了 tuned “吞吐量性能”配置文件。

最后一项更改是更改每个 NVME 上的 IO 调度程序并将其设置为“none”。

ip link set eth0 mtu 9000 
setpci -s 0000:01:00.0 68.w=5950 
ethtool -G eth0 rx 8192 tx 8192 sysctl -w net.ipv4.tcp_timestamps=0 
sysctl -w net.ipv4.tcp_sack=0 
sysctl -w net.core.netdev_max_backlog=250000 
sysctl -w net.core.somaxconn=2048 
sysctl -w net.ipv4.tcp_low_latency=1 
sysctl -w net.ipv4.tcp_rmem="10240 87380 2147483647" 
sysctl -w net.ipv4.tcp_wmem="10240 87380 2147483647" 
sysctl -w net.core.rmem_max=2147483647 
sysctl -w net.core.wmem_max=2147483647 systemctl enable tuned 
systemctl start tuned 
tuned-adm profile throughput-performance echo "none" >/sys/block/nvme0n1/queue/scheduler

CEPH 配置

对于 SUSE Enterprise Storage (SES) 配置，我们为每个 NVME 设备部署了四个 OSD 进程。 这意味着每台服务器在四个物理设备上运行 16 个 OSD 进程。

我们在集群中的每个 Arm 节点上运行了一个元数据服务，这意味着我们有 12 个活动的元数据服务在运行。

我们将元数据和数据池的 PG 数量增加到 4096 个，以确保数据分布均匀。 这符合建议的每个 OSD 的 PG 数量在 50-100 之间。

我们还将池的数据保护设置为 2 倍，就像我们在上一组基准测试中所做的那样。 这是为了确保写入的任何数据都受到保护。

如前所述，我们还为集群打开了身份验证，以模拟我们在生产系统中看到的内容。

使用的 ceph.conf 配置：

[global] 
fsid = 4cdde39a-bbec-4ef2-bebb-00182a976f52 
mon_initial_members = amp-mon1, amp-mon2, amp-mon3 
mon_host = 172.16.227.62, 172.16.227.63, 172.16.227.61 
auth_cluster_required = cephx 
auth_service_required = cephx 
auth_client_required = cephx 
public_network = 172.16.227.0/24 
cluster_network = 172.16.220.0/24 
ms_bind_msgr2 = false # enable old ceph health format in the json output. This fixes the 
# ceph_exporter. This option will only stay until the prometheus plugin takes 
# over 
mon_health_preluminous_compat = true 
mon health preluminous compat warning = false rbd default features = 3 debug ms=0 
debug mds=0 
debug osd=0 
debug optracker=0 
debug auth=0 
debug asok=0 
debug bluestore=0 
debug bluefs=0 
debug bdev=0 
debug kstore=0 
debug rocksdb=0 
debug eventtrace=0 
debug default=0 
debug rados=0 
debug client=0 
debug perfcounter=0 
debug finisher=0 [osd] 
osd_op_num_threads_per_shard = 4 
prefer_deferred_size_ssd=0 [mds] 
mds_cache_memory_limit = 21474836480 
mds_log_max_segments = 256 
mds_bal_split_bite = 4

结果

该基准测试取得了 15.6 的分数。 这是迄今为止基于 Arm 的平台上最好的 CephFS IO500 基准测试。 这个分数比去年在“Hammerhead”平台上的结果提高了 25%。 该分数使该配置在 IO500 10 节点挑战赛中排名第 27 位，比我们之前的基准高出两个位置。

在基准测试期间，我们看到 Ceph 客户端性能指标很容易达到超过 16GBytes/s 的峰值，以实现大文件写入的写入性能。 因为我们使用 2X 数据保护策略的生产就绪设置，这意味着 Ceph 节点实现了 3GB/s 的 I/O 性能。

此测试期间最重要的发现之一是功耗，或者说没有功耗。 我们使用 ipmitool 来测量平均 30 秒的功耗。 最坏情况下 30 秒的平均功率仅为 152 瓦，远低于我们在去年的基准测试中看到的。

除了性能提升和节能外，我们相信这个集群的成本将比去年的配置低 40%。

结论

HPC 中使用的专用存储解决方案成本很高。 随着 HPC 和 AI/ML 工作负载的数据量呈指数增长，IT 部门面临着优化开支的巨大压力。 该基准测试表明，基于创新软件和硬件技术的存储解决方案可以为努力支持 HPC 环境所需数据量的公司提供更多选择。

与 Ampere、Arm、Broadcom、NVIDIA、Micron 和 SUSE 的合作产生了一个新的、高性能、高能效的平台——对于任何寻求具有成本效益的低功耗替代方案的企业或机构来说，这是一个出色的存储解决方案。

合作伙伴之声

Ampere Computing https://amperecomputing.com/ampere-claims-the-top-cephfs-storage-cluster-on-arm-in-io500s-10-node-challenge/

解决方案。

合作伙伴之声

Ampere Computing https://amperecomputing.com/ampere-claims-the-top-cephfs-storage-cluster-on-arm-in-io500s-10-node-challenge/

Arm https://community.arm.com/developer/tools-software/hpc/b/hpc-blog/posts/arm-demonstrates-leading-performance-on-ceph-storage-cluster