PowerEdge：适用于 HPC BeeGFS 高性能存储的戴尔就绪型解决方案

戴尔 HPC 和 AI 创新实验室的 Nirmala Sundararajan 于 2019 年 11 月撰写的文章

目录

1. 简介
2. 解决方案参考体系结构
3. 硬件和软件配置
4. 解决方案配置详细信息
   • 管理服务
   • 元数据服务
   • 存储服务
   • 客户端服务
5. R740xd，24 个 NVMe 驱动器，CPU 映射的详细信息
6. 性能特征分析
   • 顺序读取和写入 N-N
   • 随机读取和写入 N-N
7. 结论和未来的工作
    

简介

戴尔 HPC 团队自豪地宣布发布“适用于 HPC BeeGFS 存储的 Dell EMC 就绪型解决方案”，这是 HPC 存储产品组合的最新成员。此解决方案使用 R740xd 服务器，每台服务器配备 24 个 Intel P4600 1.6 TB NVMe、混合使用 Express Flash 驱动器和两个 Mellanox ConnectX-5 InfiniBand EDR 适配器。在此 24 个 NVMe 驱动器配置中，12 个 NVMe SSD 连接到 PCIe 交换机，每个交换机使用 x16 PCIe 扩展卡连接到一个 CPU。此外，每个 IB 接口都连接到一个 CPU。这种平衡配置使每个 CPU 连接到一个 InfiniBand 适配器并处理 12 个 NVMe SSD，通过确保处理器在处理传入和传出 NVMe 驱动器的 I/O 请求时均占用相同的时间来提供出色性能。

该解决方案的重点是高性能 I/O，并且被设计为高速暂存解决方案。该解决方案的核心是使用高速 NVMe SSD，通过消除数据块层 中的调度程序和排队瓶颈 ，提供高带宽和低延迟。BeeGFS 文件系统还支持高聚合 I/O 吞吐量。

解决方案参考体系结构

图 1 显示了该解决方案的参考体系结构。管理服务器仅使用以太网连接到元数据和存储服务器。每个元数据和存储服务器都有两个 InfiniBand 链路，并通过以太网连接到专用网络。客户端有一个 InfiniBand 链路，并通过以太网连接到专用接口。

图 1：  适用于 HPC BeeGFS 存储的戴尔就绪型解决方案 — 参考体系结构

硬件和软件配置

表 1 和表 2 分别描述了管理服务器和元数据/存储服务器的硬件规格。表 3 介绍了用于解决方案的软件版本。

解决方案配置详细信息

BeeGFS 体系结构包括四个主要服务：

• 管理服务
• 元数据服务
• 存储服务
• 客户端服务

除客户端服务作为内核模块外，管理、元数据和存储服务均为用户空间进程。图 2 展示了适用于 HPC BeeGFS 存储的 Dell EMC Ready Solutions 参考体系结构如何映射到 BeeGFS 文件系统的一般体系结构。

图 2：  具有 NVMe SSD 的 PowerEdge R740xd 上的 BeeGFS 文件系统

管理服务

每个 BeeGFS 文件系统或命名空间只有一项管理服务。管理服务是必须设置的第一个服务，因为当我们配置所有其他服务时，它们必须向管理服务注册。PowerEdge R640 用作管理服务器。除了托管管理服务 (beegfs-mgmtd.service) 之外，它还托管监视服务 (beegfs-mon.service)，该服务使用时间序列数据库 InfluxDB 从系统收集统计信息并将其提供给用户。对于数据的可视化，beegfs-mon 提供了可开箱即用的预定义 Grafana 窗格。管理服务器在 RAID 10 中为操作系统和 InfluxDB 配置了 6 个 300 GB HDD。

元数据服务

元数据服务是一种横向扩展服务，这意味着 BeeGFS 文件系统中可能有许多元数据服务。但是，每个元数据服务都有且仅有一个用于存储元数据的元数据目标。在元数据目标上，BeeGFS会为每个用户创建的文件创建一个元数据文件。BeeGFS 元数据按目录分布。元数据服务向客户端提供数据条带化信息，并且不参与打开/关闭文件之间的数据访问。

PowerEdge R740xd 配备 24 个英特尔 P4600 1.6 TB NVMe 驱动器，用于元数据存储。由于 BeeGFS 元数据的存储容量要求非常小，因此没有使用专用元数据服务器，而是仅使用 NUMA 区域 0 上的 12 个驱动器托管元数据数据库（ MDT ），而 NUMA 分区上的其余 12 个驱动器托管存储数据库（ ST ）。

图 3 显示了元数据服务器。黄色矩形中包含的 12 个驱动器是 NUMA 区域 0 中的 MDT，而绿色矩形中的 12 个驱动器是 NUMA 区域 1 中的 ST。此配置不仅可以避免 NUMA 问题，而且还提供足够的元数据存储以根据需要扩展容量和性能。

图 3： 元数据服务器

图 4 显示元数据服务器的 RAID 配置。它突出显示了在元数据服务器中，NUMA 区域 0 中的驱动器托管 MDT，NUMA 区域 1 中的驱动器托管存储数据，而存储服务器在两个 NUMA 区域中托管 ST。

图 4：  在元数据服务器

中配置驱动器 用于元数据的 12 个驱动器配置为由两个驱动器组成的 6x RAID 1 磁盘组，每个驱动器用作一个 MDT。有六个元数据服务在运行，每个服务处理一个 MDT。其余 12 个存储驱动器在 3x RAID 0 磁盘组中进行配置，每个磁盘组包含四个驱动器。NUMA 1 区域上运行三个存储服务，每个 ST 有一个服务。因此，联合托管元数据和存储目标的服务器有 6 个 MDT 和 3 个 ST。它还运行六项元数据服务和三项存储服务。每个 MDT 都是一个基于 RAID 1 配置的 ext4 文件系统。ST 基于 RAID 0 中配置的 XFS 文件系统。
 

存储服务

与元数据服务一样，存储服务也是横向扩展服务。BeeGFS 文件系统中可能有许多个存储服务。但是，与元数据服务不同，每个存储服务可能有多个存储目标。存储服务存储条带化用户文件内容，也称为数据块文件。

图 5 显示了用作存储服务器的 5 台 PowerEdge R740xd 服务器。

图 5：  专用存储服务器每个

存储服务器配置有 6 个 RAID 0 组，每个组有 4 个驱动器，因此每个服务器托管 6 个 ST（每个 NUMA 分区 3 个），如下图 6 所示：

图 6：  配置存储服务器

中的驱动器 基本参考体系结构配置总共托管 6 个 MDT 和 33 个 ST。五个专用存储服务器提供了 211 TB 的原始容量和 190 TiB 的可用容量。预估可用容量（以 TiB 为单位）= 驱动器数量 x 每个驱动器的容量（以 TB 为单位）x 0.99（文件系统开销）x (10^12/2^40)。这将是理想的中端暂存解决方案，它具有足够的元数据存储，可随着容量需求的增加而增加更多存储服务器。

鉴于以下因素，为存储目标选择了 RAID 0 配置，而不是 RAID 10 配置。

1. 使用 dd 命令通过创建数据块大小为 1MB 的 10GB 文件和直接数据的 I/O 来测量写入性能，对于 RAID 0 设备，每个设备的平均值约为 5.1 GB/s，而对于 RAID 10 设备，每个设备的平均值为 3.4 GB/s。
2. StorageBench 基准测试表明，RAID 0 配置的最大吞吐量为 5.5 GB/s，而 RAID 10 配置为 3.4 GB/s。这些结果与使用 dd 命令获得的结果类似。
3. RAID 10 提供 50% 的磁盘容量利用率，并使写入性能降低 50%。使用 RAID 10 获取存储冗余是一种成本很高的方法。
4. NVMe 驱动器价格昂贵，并且提供加速，最适合在 RAID 0 配置中使用

客户端服务

BeeGFS客户端模块必须加载到必须访问BeeGFS文件系统的所有主机上。加载 beegfs-client 时，它会挂载/etc/beegfs/beegfs-mounts.conf 文件中定义的文件系统，而不是基于 /etc/fstab 的常用方法。采用此方法可通过服务启动脚本启动 beegfs-client，就像任何其他 Linux 服务一样。它还支持在系统更新后自动重新编译 BeeGFS 客户端模块。

加载客户端模块时，它会挂载 beegfs-mounts.conf 中定义的文件系统。可以在同一客户端上装载多个 beegfs 实例，如下所示：

$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf

上面的示例显示了装载在同一客户端上的两个不同的文件系统。出于此测试的目的，将 32 个 C6420 节点用作客户端。

R740xd，24 个 NVMe 驱动器，CPU 映射的详细信息

在 PowerEdge R740xd 服务器的 24xNVMe 配置中，有两个 x16 NVMe 桥接卡为背板上的 PCIe 交换机提供馈入，该交换机扇出并为前面的驱动器（驱动器为 x4）提供馈入，如下面的图 7 所示：


图 7：  R740xd，24 个 NVMe，CPU 映射的详细信息

在非统一内存访问 (NUMA) 中，系统内存被划分为不同的区域（称为节点），这些节点会分配给 CPU 或插槽。与系统上连接到远程 CPU 的内存相比，CPU 的本地内存访问速度更快。线程应用程序通常在线程访问同一 NUMA 节点上的内存时表现最佳。NUMA 未命中对性能的影响非常显著，通常从 10% 或更高的性能命中率开始。为了提高性能，服务配置为使用特定的 NUMA 区域，以避免不必要地使用 UPI 跨插槽链路，从而减少延迟。每个 NUMA 区域处理 12 个驱动器，并使用服务器上的两个 InfiniBand EDR 接口之一。此 NUMA 分离通过手动配置 NUMA 平衡来实现，具体方法是创建自定义 systemd 单元文件和配置多宿主。因此，自动 NUMA 平衡处于禁用状态，如下所示：

# cat /proc/sys/kernel/numa_balancing
0

图 8 显示了测试平台，其中突出显示了与 NUMA 区域的 InfiniBand 连接。每个服务器都有两个 IP 链路，通过 NUMA 0 分区的流量由接口 IB0 传递，而通过 NUMA 1 分区的流量由接口 IB1 处理。

图 8：  试验台配置
 

性能特征分析

本部分提供的性能评估有助于表征适用于 HPC BeeGFS 高性能存储解决方案的 Dell EMC 就绪型解决方案的特征。有关更多详细信息和更新，请查看稍后发布的白皮书。系统性能是使用 IOzone 基准测试评估的。针对顺序读取和写入吞吐量以及随机读取和写入 IOPS 对该解决方案进行了测试。表4介绍了C6420服务器的配置，这些服务器用作本博客中性能研究的BeeGFS客户端。
 

顺序写入和读取 N-N

为了评估顺序读取和写入，在顺序读取和写入模式下使用了 IOzone 基准。这些测试是在多个线程数上进行的，从一个线程开始，以 2 的幂递增，最多 1024 个线程。在每次线程计数时，都生成同等数量的文件，因为此测试的工作方式是每线程一个文件或多客户端对多文件 (N-N) 的情况。这些进程以轮询或循环方式分布在 32 个物理客户端节点上，以使请求均匀分布并进行负载均衡。选择了 8TB 的累计文件大小，在任何给定的测试中按线程数均分。选择的聚合文件大小要足够大，以便更大限度地减少来自服务器和BeeGFS客户端的高速缓存的影响。IOzone 以写入然后读取 (-i 0, -i 1) 的组合模式运行，以便协调操作之间的边界。对于此测试和结果，我们为每次运行使用了 1MB 的记录大小。用于顺序 N-N 测试的命令如下所示：

顺序写入和读取： iozone -i 0 -i 1 -c -e -w -r 1m -I -s $Size -t $Thread -+n -+m /path/to/threadlist

通过运行以下命令，还会在迭代之间以及写入和读取测试之间删除或清理客户端节点上的作系统缓存：

# sync && echo 3 > /proc/sys/vm/drop_caches

Beegfs 的默认条带数量为 4。但是，可以按目录配置区块大小和每个文件的目标数。对于所有这些测试、BeeGFS条带大小选择为2 MB，条带计数选择为3，因为每个NUMA区域有三个目标，如下所示：

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe pattern details:
+ Type: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 7/5E/0-5D9BA1BC-1

透明的大页面被禁用，元数据和存储服务器上设置了以下调整选项：

vm.dirty_background_ratio = 5 
vm.dirty_ratio = 20 
vm.min_free_kbytes = 262144 
vm.vfs_cache_pressure = 50
vm.zone_reclaim_mode = 2 
kernel.numa_balancing = 0

除上述设置外，还使用了以下 BeeGFS 调整选项： 

• tuneTargetChooser 参数在元数据配置文件中设置为“循环” 
• tuneNumWorkers 元数据参数设置为 24，存储参数设置为 32 
• connMaxInternodeNum 元数据参数设置为 32，存储设置为 12，客户端参数设置为 24

图 9：  顺序 IOzone 8 TB 总文件大小。

在 图 9 中，我们看到峰值读取性能为 132 GB/秒（1024 个线程），峰值写入性能为 121 GB/秒（256 个线程）。每个驱动器可提供 3.2 GB/s 的峰值读取性能和 1.3 GB/s 的峰值写入性能，这使得读取的理论峰值为 422 GB/s，写入的峰值为 172 GB/s。但是，网络是限制因素。对于设置中的存储服务器，我们总共有 11 个 InfiniBand EDR 链路。每个链路可提供 12.4 GB/秒的理论峰值性能，因此理论峰值性能为 136.4 GB/秒。实际达到的峰值读取和写入性能分别为理论峰值性能的 97% 和 89%。

观察到的单线程写入性能约为 3 GB/秒，读取性能约为 3 GB/秒。我们观察到，写入性能呈线性扩展，峰值为 256 个线程，然后开始下降。在较低的线程数量下，读取和写入性能相同。因为在有 8 个线程之前，我们有 8 个客户端跨 24 个目标写入 8 个文件，这意味着并非所有存储目标都得到了充分利用。系统中有 33 个存储目标，因此至少需要 11 个线程才能充分利用所有服务器。随着并发线程数量的增加，读取性能呈稳定的线性增长，我们观察到性能在 512 和 1024 线程时几乎相似。

我们还观察到，当线程数为 16 到 128 时，读取性能低于写入性能，在这之后读取性能开始提高。这是因为，虽然 PCIe 读取操作是非发布操作，需要请求和完成，但 PCIe 写入操作是一种即发即弃的操作。将事务层数据包移交给数据链路层后，操作便完成。写入操作是“发布”操作，仅包括请求。

读取吞吐量通常低于写入吞吐量，因为读取需要两个事务，而对于相同的数据量只需要单次写入。PCI Express 使用拆分事务模型进行读取。读取事务包括以下步骤：

• 请求者发送内存读取请求 (MRR)。
• 完成者向 MRR 发送确认。
• 完成者返回完成和数据。

读取吞吐量取决于发出读取请求的时间与完成程序返回数据所需的时间之间的延迟。但是，当应用程序发出的读取请求足够多，可以覆盖此延迟时，吞吐量将最大化。这就是为什么在 16 个线程到 128 个线程时读取性能低于写入性能，而我们在请求数量增加时测量到更高的吞吐量。如果请求者等待完成后再发出后续请求时，将测量到较低的吞吐量。如果在第一个数据返回后发出多个请求以对延迟进行分摊，将测量到较高的吞吐量。

随机写入和读取 N-N

为了评估随机 IO 性能，在随机模式下使用了 IOzone。对从 4 个线程到最多 1024 个线程的情况进行了测试。使用了直接 IO 选项 (-I) 来运行 IOzone，以使所有操作都绕过缓冲区缓存并直接进入磁盘。使用的 BeeGFS 条带数量为 3，区块大小为 2 MB。IOzone 上使用的请求大小为 4 KiB。性能的测量单位是每秒 I/O 操作数 (IOPS)。在BeeGFS服务器和BeeGFS客户端上的运行之间丢弃了作系统高速缓存。用于执行随机写入和读取的命令如下所示：

随机读取和写入： iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

图 10：  使用具有 8TB 总文件大小的 IOzone 的随机读写性能。

随机写入峰值为 ~360 万 IOPS（在 512 个线程时），随机读取峰值为 ~350 万 IOPS（1024 个线程），如图 10 所示。当 IO 请求数量增多时，写入和读取性能都会变高。这是因为 NVMe 标准支持最多 64,000 个 I/O 队列，每个队列最多 64,000 条命令。这一大型 NVMe 队列池提供了更高级别的 I/O 并行度，因此我们观察到 IOPS 超过 300 万。

结论和未来的工作

此博客宣布发布 Dell EMC 高性能 BeeGFS 存储解决方案，并重点介绍其性能特征。该解决方案的峰值顺序读取和写入性能分别约为 132 GB/秒和约 121 GB/秒，随机写入峰值约为 360 万 IOPS，随机读取峰值约为 350 万 IOPS。

此博客是“BeeGFS 存储解决方案”的第一部分，该解决方案旨在打造高性能的暂存空间。敬请关注此博客系列的第二部分，其中将介绍如何通过增加服务器数量来扩展解决方案，以提高性能和容量。博客系列的第3部分将讨论BeeGFS的其他功能，并重点介绍如何使用BeeGFS的内置存储目标基准“StorageBench”。

作为后续步骤的一部分，我们将稍后发布一份白皮书，介绍元数据性能和 N 线程到一个文件 IOR 的性能，以及有关设计注意事项、调整和配置的其他详细信息。

参考材料

[1] BeeGFS文档： 
https://www.beegfs.io/wiki/[2] 如何连接同一子网上的两个端口：  https://access.redhat.com/solutions/30564