文章作者:Dell EMC HPC 和 AI 创新实验室的 Nirmala Sundararajan,撰写时间:2019 年 11 月
适用于 HPC BeeGFS 高性能存储的 Dell EMC Ready Solutions
表 1 和 2 分别介绍了管理服务器和元数据/存储服务器的硬件规格。表 3 介绍了用于解决方案的软件版本。
表 1 PowerEdge R640 配置(管理服务器) | |
---|---|
服务器 | Dell EMC PowerEdge R640 |
处理器 | 2 个英特尔至强 Gold 5218 2.3 GHz,16 个核心 |
内存 | 12 个 8 GB DDR4 2666 MT/s DIMM - 96 GB |
本地磁盘 | 6 个 300 GB 15K RPM SAS 2.5 英寸 HDD |
RAID 控制器 | PERC H740P 集成 RAID 控制器 |
带外管理 | 带有 Lifecycle Controller 的 iDRAC9 Enterprise |
电源设备 | 双 1100 W 电源装置 |
BIOS 版本 | 2.2.11 |
操作系统 | CentOS™ 7.6 |
内核版本 | 3.10.0-957.27.2.el7.x86_64 |
表 2 PowerEdge R740xd 配置(元数据和存储服务器) | |
---|---|
服务器 | Dell EMC PowerEdge R740xd |
处理器 | 2 个英特尔至强 Platinum 8268 CPU @ 2.90GHz,24 个核心 |
内存 | 12 个 32 GB DDR4 2933 MT/s DIMM - 384 GB |
BOSS 卡 | RAID 1 中的 2 个 240 GB M.2 SATA SSD,用于操作系统 |
本地驱动器 | 24 个 Dell Express Flash NVMe P4600 1.6TB 2.5 英寸 U.2 |
Mellanox EDR 卡 | 2 个 Mellanox ConnectX-5 EDR 卡(插槽 1 和 8) |
带外管理 | 带有 Lifecycle Controller 的 iDRAC9 Enterprise |
电源设备 | 双 2000W 电源装置 |
表 3 软件配置(元数据和存储服务器) | |
---|---|
BIOS | 2.2.11 |
CPLD | 1.1.3 |
操作系统 | CentOS™ 7.6 |
内核版本 | 3.10.0-957.el7.x86_64 |
iDRAC | 3.34.34.34 |
系统管理工具 | OpenManage Server Administrator 9.3.0-3407_A00 |
Mellanox OFED | 4.5-1.0.1.0 |
NVMe SSD | QDV1DP13 |
*英特尔 ® 数据中心工具 | 3.0.19 |
BeeGFS | 7.1.3 |
Grafana | 6.3.2 |
InfluxDB | 1.7.7 |
IOzone 基准测试 | 3.487 |
上面的示例显示了装载在同一客户端上的两个不同的文件系统。出于此测试的目的,将 32 个 C6420 节点用作客户端。$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf
图 8 显示了一个试验台,其中突出显示与 NUMA 区域的 InfiniBand 连接。 每个服务器都有两个 IP 链路,通过 NUMA 0 区域的流量由接口 IB0 处理,而通过 NUMA 1 区域的流量由接口 IB1 处理。# cat /proc/sys/kernel/numa_balancing
0
表 4 客户端配置 | |
---|---|
客户端 | 32x Dell EMC PowerEdge C6420 计算节点 |
BIOS | 2.2.9 |
处理器 | 2x Intel Xeon Gold 6148 CPU @ 2.40GHz,每个处理器 20 核 |
内存 | 12 个 16 GB DDR4 2666 MT/s DIMM - 192 GB |
BOSS 卡 | RAID 1 中的 2 个 120 GB M.2 启动驱动器,用于操作系统 |
操作系统 | Red Hat Enterprise Linux Server 发行版 7.6 |
内核版本 | 3.10.0-957.el7.x86_64 |
互连 | 1 个 Mellanox ConnectX-4 EDR 卡 |
OFED 版本 | 4.5-1.0.1.0 |
为了评估顺序读取和写入,在顺序读取和写入模式下使用了 IOzone 基准。这些测试是在多线程上进行的,从 1 个线程开始,以 2 为指数增加,最多达 1024 个线程。在每次线程计数时,都生成同等数量的文件,因为此测试的工作方式是每线程一个文件或多客户端对多文件 (N-N) 的情况。这些进程以轮询或循环方式分布在 32 个物理客户端节点上,以使请求均匀分布并进行负载均衡。选择了 8TB 的累计文件大小,在任何给定的测试中按线程数均分。选择的总文件大小足够大,以尽可能减少来自服务器和 BeeGFS 客户端的缓存的影响。IOzone 以写入然后读取 (-i 0, -i 1) 的组合模式运行,以便协调操作之间的边界。对于此测试和结果,我们为每次运行都使用了 1 MiB 的记录大小。用于顺序 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 调整选项:
在 图 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 使用拆分事务模型进行读取。读取事务包括以下步骤:
读取吞吐量取决于发出读取请求的时间与完成者返回数据所需的时间之间的延迟。但是,当应用程序发出的读取请求足够多,可以覆盖此延迟时,吞吐量将最大化。这就是为什么在 16 个线程到 128 个线程时读取性能低于写入性能,而我们在请求数量增加时测量到更高的吞吐量。 如果请求者等待完成后再发出后续请求时,将测量到较低的吞吐量。如果在第一个数据返回后发出多个请求以对延迟进行分摊,将测量到较高的吞吐量。
为了评估随机 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: 使用 IOzone 和 8 TB 总文件大小的随机读取和写入性能
随机写入峰值约为 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 存储解决方案”的第一部分,该解决方案旨在打造高性能的暂存空间。敬请关注此博客系列的第二部分,其中将介绍如何通过增加服务器数量来扩展解决方案,以提高性能和容量。此博客系列的第三部分将讨论 BeeGFS 的其他功能,并将重点介绍“StorageBench”的使用,这是 BeeGFS 的内置存储目标基准测试。
作为后续步骤的一部分,我们将在稍后发布一份白皮书,其中介绍元数据性能和 N 线程对 1 个文件的 IOR 性能,以及有关设计注意事项、调整和配置的其他详细信息。