适用于 HPC PixStor 存储的 Dell EMC Ready 解决方案 — 扩容

无

目录

1. 简介
   1. 解决方案体系结构
   2. 解决方案组件
2. 性能特征
   1. 连续 IOzone 性能 N 客户端到 N 文件
   2. 顺序 IOR 性能 N 客户端到 1 个文件
   3. 随机小数据块 IOzone 性能 N 客户端到 N 文件
   4. 使用空文件的 MDtest 的元数据性能
   5. 使用 4 个 KiB 文件的 MDtest 的元数据性能
3. 结论和未来的工作

 

---

简介

当今的 HPC 环境对高速存储的需求日益增加，而高速存储也经常需要通过 NFS、SMB 等多种标准协议进行高容量和分布式访问。这些高要求的 HPC 要求通常由并行文件系统覆盖，这些文件系统提供对单个文件或多个节点的一组文件的并发访问，非常高效且安全地将数据分发到多个服务器上的多个 LUN。

 

---

解决方案体系结构

此博客是适用于 HPC 环境的连续并行文件系统 （PFS） 解决方案，即 适用于 HPC PixStor 存储的 DellEMC 就绪型解决方案， 其中 PowerVault ME484 EBOD 阵列用于增加解决方案的容量。图 1 提供了描述现有 PowerVault ME4084 存储阵列的容量扩展 SAS 添加的参考体系结构。
除了许多其他 Arcastream 软件组件（如高级分析、简化的管理和监视、高效的文件搜索、高级网关功能等）之外，PixStor 解决方案还包括广泛的通用并行文件系统（也称为 Spectrum Scale 作为 PFS 组件）。


图 1：参考体系结构。

 

---

解决方案组件

此解决方案计划随最新的英特尔至强第二代可扩展至强 CPU（又称 Cascade Lake CPU）一起发布。Cascade Lake CPU 和部分服务器将使用可用的最快 RAM （2933 MT/s）。但是，由于当前硬件可用于处理解决方案的原型以描述性能，因此采用英特尔至强第 1 代可扩展至强 CPU 的服务器又称为Skylake 处理器和某些情况下较慢的 RAM 用于描述此系统的特征。由于解决方案的瓶颈位于 DellEMC PowerVault ME40x4 阵列的 SAS 控制器处，因此一旦 Skylake CPU 和 RAM 替换为设想的 Cascade Lake CPU 和更快的 RAM，预计不会出现显著的性能差异。此外，该解决方案已更新为支持 RHEL 7.7 和 OFED 4.7 的最新 PixStor （5.1.1.4） 版本，以对系统进行特征化。

由于之前描述的情况，表 1 包含解决方案的主要组件列表，但在引入差异时，第一个描述列具有发布时使用的组件，因此可供客户使用，最后一列是实际用于描述解决方案性能的组件。为数据 （12 TB NLS） 和元数据 （960Gb SSD） 列出的驱动器是用于性能特征的驱动器，更快的驱动器可以提供更好的随机 IOPS，并可改进创建/删除元数据操作。

最后，为了实现完整性，包括可能的数据 HDD 和元数据 SSD 列表，该列表基于在线提供的 DellEMC PowerVault ME4 支持列表中枚举的受支持的驱动器。

表 1 在发布时使用的组件和测试台中使用的组件

解决方案组件		发布时	测试台
内部连接		Dell Networking S3048-ON 千兆位以太网
数据存储子系统		1 到 4 个 Dell EMC PowerVault ME4084 1 到 4 个 Dell EMC PowerVault ME484（每个 ME4084 一个） 80 个 12 TB 3.5 英寸 NL SAS3 HDD 驱动器 选项 900 GB @15K， 1.2 TB @10K、1.8 TB @10K、2.4 TB @10K、 4 TB NLS、8 TB NLS、10 TB NLS、12 TB NLS。     8 个 LUN，线性 8+2 RAID 6，区块大小 512KiB。 4 个 1.92 TB SAS3 SSD 用于元数据 — 2 个 RAID 1（或 4 个全局 HDD 备盘，如果使用可选的高要求元数据模块）
可选的高要求元数据存储子系统		1 到 2 个 Dell EMC PowerVault ME4024（4 个 ME4024（如果需要，仅限大型配置） 24 个 960 GB 2.5 英寸 SSD SAS3 驱动器（选项 480 GB、960 GB、1.92 TB） 12 个 LUN，线性 RAID 1。
RAID 存储控制器		12 Gbps SAS
已配置的容量		原始：8064 TB（7334 TiB 或 7.16 PiB）格式化 ~ 6144 GB（5588 TiB 或 5.46 PiB）
处理器	Gateway	2 个英特尔至强 Gold 6230 2.1G、20C/40T、10.4 GT/s、275M 高速缓存、睿频、HT （125 W） DDR4-2933	N/A
	高需求元数据		2 个英特尔至强 Gold 6136 ，3.0 GHz，12 个核心
	存储节点		2 个英特尔至强 Gold 6136 ，3.0 GHz，12 个核心
	管理节点	2 个英特尔至强 Gold 5220 2.2 G、18C/36T、10.4 GT/s、24.75M 高速缓存、睿频、HT （125 W） DDR4-2666	2 个英特尔至强 Gold 5118 ，2.30 GHz，12 个核心
内存	Gateway	12 个 16 GiB 2933 MT/s RDIMM （192 GiB）	N/A
	高需求元数据		24 个 16 GiB 2666 MT/s RDIMM （384 GiB）
	存储节点		24 个 16 GiB 2666 MT/s RDIMM （384 GiB）
	管理节点	12 个 16 GB DIMM，2666 MT/s （192 GiB）	12 个 8 GiB 2666 MT/s RDIMM （96 GiB）
操作系统		Red Hat Enterprise Linux 7.6	Red Hat Enterprise Linux 7.7
内核版本		3.10.0-957.12.2.el7.x86_64	3.10.0-1062.9.1.el7.x86_64
PixStor 软件		5.1.0.0	5.1.1.4
频谱扩展 （GPFS）		5.0.3	5.0.4-2
高性能网络连接		Mellanox ConnectX-5 双端口 InfiniBand EDR/100 GbE 和 10 GbE	Mellanox ConnectX-5 InfiniBand EDR
高性能交换机		2 个 Mellanox SB7800（高可用性 — 冗余）	1 个 Mellanox SB7700
OFED 版本		Mellanox OFED-4.6-1.0.1.0	Mellanox OFED-4.7-3.2.9
本地磁盘（操作系统和分析/监视）		除管理节点以外的所有服务器 3 个 480 GB SSD SAS3 （RAID1 + HS），用于操作系统 PERC H730P RAID 控制器 管理节点 3 个 480 GB SSD SAS3 （RAID1 + HS），用于操作系统 PERC H740P RAID 控制器	除管理节点以外的所有服务器 2 个 300 GB 15K SAS3 （RAID 1），用于操作系统 PERC H330 RAID 控制器 管理节点 5 个 300 GB 15K SAS3 （RAID 5），用于操作系统和 分析/监视 PERC H740P RAID 控制器
系统管理		iDRAC 9 Enterprise + DellEMC OpenManage	iDRAC 9 Enterprise + DellEMC OpenManage

 

---

性能特征

为了描述这个新的就绪型解决方案，我们使用了表 1 的最后一列中指定的硬件，包括可选的高要求元数据模块。为了评估解决方案性能，使用了以下基准测试：

• IOzone N 到 N 顺序
• IOR N 至 1 顺序
• IOzone 随机
• MDtest

 对于上面列出的所有基准测试，测试台具有下表 2 中所述的客户端。由于可用于测试的计算节点数仅为 16 个， 当需要更多线程时，这些线程在计算节点上均匀分布（即每个节点 32 个线程 = 2 个线程，64 个线程 = 每个节点 4 个线程，每个节点 128 个线程 = 8 个线程，每个节点 256 个线程 = 16 个线程，每个节点 512 个线程 = 32 个线程， 1024 个线程 = 每个节点 64 个线程）。目的是模拟具有有限数量计算节点的更多并发客户端。由于基准测试支持大量线程，因此使用的最大值高达 1024（为每个测试指定），同时避免影响性能结果的过多上下文切换和其他相关副作用。

表 2 客户端测试台

客户端节点数	16
客户端节点	C6320
每个客户端节点的处理器数	2 个英特尔至强（R） 黄金级 E5-2697v4 18 核，2.30 GHz
每个客户端节点的内存	12 个 16GiB 2400 MT/s RDIMM
(BIOS)	2.8.0
操作系统内核	3.10.0-957.10.1
GPFS 版本	5.0.3

 

---

连续 IOzone 性能 N 客户端到 N 文件

按顺序 N 客户端到 N 文件的性能是使用 IOzone 版本 3.487 测量的。执行的测试从单线程到多达 1024 个线程不等，容量扩展解决方案的结果（4 个 ME4084s + 4 个 ME484）与大尺寸解决方案（4 个 ME4084s）对比。通过将 GPFS 页面池可调整为 16GiB 并使用大小超过该大小两倍的文件，可以最大程度地减少缓存效果。请务必注意，对于 GPFS，可调设置用于缓存数据的最大内存量，而不考虑安装和释放的 RAM 量。此外，需要注意的是，在以前的 DellEMC HPC 解决方案中，大型顺序传输的数据块大小为 1 MiB，GPFS 采用 8 个 MiB 数据块格式，因此该值用于基准测试以实现最佳性能。这可能看起来太大，显然会浪费太多空间，但 GPFS 使用子块分配来防止这种情况发生。在当前配置中，每个数据块细分为 256 个子块，每个子块 32 KiB。

使用以下命令来执行写入和读取基准，其中 Threads 是使用线程数的变量（以 2 为单位递增 1 到 1024），而线程列表是将每个线程分配到不同节点上的文件，使用循环调度在 16 个计算节点上以同构方式分布它们。

./iozone -i0 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist
./iozone -i1 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist

图 2：  N 到 N 顺序性能


从结果中，我们可以观察到，性能随着所用客户端数量的增加而快速提升，然后达到稳定状态，直至达到 IOzone 允许的最大线程数，因此即使对于 1024 个并发客户端，大型文件顺序性能也保持稳定。请注意，读取和写入性能都得益于驱动器数量翻倍。从 8 个线程开始，存储节点上使用的两个 IB EDR 链路的带宽限制了最大读取性能，ME4 阵列可能具有一些额外的可用性能。同样请注意，最大写入性能在 64 线程和 128 线程时从最大 16.7 GB/s 增加到 20.4 GB/s，并且更接近 ME4 阵列的最大规格 （22 GB/s）。

在这里，请务必记住，GPFS 首选的操作模式分散，并且解决方案格式化为使用此类模式。在此模式下，数据块从操作开始以伪随机方式分配，将数据分布到每个 HDD 的整个表面。虽然明显的缺点是初始最大性能较小，但无论文件系统上使用了多少空间，性能都会保持相当恒定。与其他并行文件系统相比，这些文件系统最初使用外部磁道，这些磁道可在磁盘革命中容纳更多数据（扇区），因此 HDD 可以提供尽可能高的性能，但随着系统使用更多空间，每个革命使用的数据较少的内部磁道，性能也会随之降低。

 

---

顺序 IOR 性能 N 客户端到 1 个文件

在 OpenMPI v4.0.1 的协助下，通过 IOR 版本 3.3.0 测量到单个共享文件性能的顺序 N 客户端，以在 16 个计算节点上运行基准测试。执行的测试从一个线程到多达 512 个线程（因为没有足够的内核用于 1024 个线程），结果与解决方案相比没有容量扩展。
通过将 GPFS 页面池可调整为 16GiB 并使用大小超过该大小两倍的文件，可以最大程度地减少缓存效果。此基准测试使用了 8 个 MiB 数据块来获得最佳性能。之前的性能测试部分对这些问题有更全面的解释。

使用以下命令来执行写入和读取基准，其中 Threads 是使用线程数的变量（以 2 为单位递增 1 到 1024），而 my_hosts.$Threads 是分配在不同节点上的每个线程的对应文件，使用循环调度在 16 个计算节点上以同构方式分布它们。

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b 128G 

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b 128G

图 3：N 到 1 顺序性能

从结果中，我们可以再次观察到，额外的驱动器有利于读取和写入性能。使用的客户端数量再次快速提升性能，然后达到相当稳定的水平，读取和写入一直到此测试中使用的最大线程数。请注意，在 16 个线程中，最大读取性能为 24.8 GB/s，瓶颈是 InfiniBand EDR 接口，ME4 阵列仍有一些额外的可用性能。从这一点开始，读取性能从该值降低到达到约 23.8 GB/s 的水平。同样，请注意，在 8 个线程上达到 19.3 的最大写入性能，并达到一个稳定状态。
 

---

随机小数据块 IOzone 性能 N 客户端到 N 文件

随机 N 客户端到 N 文件的性能是使用 FIO 版本 3.7 而不是传统的 Iozone 来衡量的。如上一篇博客中所列，其目的是利用更大的队列深度来调查 ME4084 阵列可以提供的最大性能（以前针对不同 ME4 解决方案的测试表明 ME4084 阵列需要更多的 IO 压力，以便 Iozone 能够提供更大的 IO 压力来达到其随机 IO 限制）。

执行的测试从单线程到多达 512 个线程不等，因为没有足够的客户端核心用于 1024 个线程。每个线程都使用不同的文件，并且在客户端节点上分配了线程轮循。此基准测试使用 4 个 KiB 数据块来模拟小数据块流量，并使用 16 的队列深度。比较了大尺寸解决方案和容量扩展的结果。

通过将 GPFS 页面池可调到 16GiB 并使用大小两倍的文件，缓存效果再次降至最低。第一个性能测试部分更全面地解释了为什么它在 GPFS 上有效。


图 4：  N 到 N 随机性能

从结果中可以看出，写入性能从 29.1K IOps 的高值开始，并稳定地上升至 64 个线程，其中它似乎达到 40K IOps 左右的稳定状态。另一方面，读取性能从 1.4K IOps 开始，随着所用客户端数量的增加，性能几乎呈线性提高（请记住，每个数据点的线程数翻倍），并在 64 个线程中达到 25.6K IOPS 的最大性能，在 64 个线程中似乎接近达到一个稳定状态。使用更多的线程将需要超过 16 个计算节点，以避免资源不足和更低的明显性能，而阵列实际上可以保持性能。

 

---

使用空文件的 MDtest 的元数据性能

元数据性能通过 MDtest 版本 3.3.0 进行测量，在 OpenMPI v4.0.1 的帮助下，在 16 个计算节点上运行基准测试。执行的测试从单线程到多达 512 个线程不等。基准测试仅用于文件（无目录元数据），获取解决方案可以处理的创建、统计信息、读取和删除数量，结果与大尺寸解决方案形成对比。

为了与其他 DellEMC HPC 存储解决方案和之前的博客结果进行比较，正确评估解决方案，使用了可选的高要求元数据模块，但在单个 ME4024 阵列中，即使此工作中经过测试的大型配置也指定了两个 ME4024。此高要求元数据模块最多可支持四个 ME4024 阵列，建议在添加另一个元数据模块之前将 ME4024 阵列的数量增加到 4 个。其他 ME4024 阵列预计会随着每个附加阵列线性提高元数据性能，但 Stat 操作（和空文件的读取）除外，因为这些数字非常高，因此 CPU 在某些时候将成为瓶颈，性能不会继续线性提高。

使用以下命令执行基准测试，其中 Threads 是使用线程数的变量（1 到 512 以 2 为单位递增），而 my_hosts.$Threads 是分配在不同节点上的每个线程的对应文件，使用循环调度在 16 个计算节点上以同构方式分布它们。与随机 IO 基准测试类似，最大线程数限制为 512，因为没有足够的内核用于 1024 线程，上下文切换会影响结果，报告的数字低于解决方案的实际性能。

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1 /perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F

由于性能结果可能会受到 IOPS 总数、每个目录的文件数和线程数的影响，因此决定将文件总数固定为 2 个 MiB 文件（2^21 = 2097152）、每个目录固定的文件数（1024），并且目录数量因表 3 中所示的线程数而异。

表 3： 目录上的文件的 MDtest 分发

线程数	每个线程的目录数	文件总数
1	2048	2,097,152
2	1024	2,097,152
4	512	2,097,152
8	256	2,097,152
16	128	2,097,152
32	64	2,097,152
64	32	2,097,152
128	16	2,097,152
256	8	2,097,152
512	4	2,097,152
1024	2	2,097,152

图 5：元数据性能 — 空文件

首先，请注意，选择的规模与基数 10 是对数，以允许比较具有多个数量级顺序差异的操作;否则，某些操作在正常图形上看起来就像是接近 0 的平线。具有基数 2 的日志图形可能更合适，因为线程数量以 2 为功率增加，但图形看起来非常相似，人们往往会根据 10 的功率处理和记住更好的数字。
当统计和读取操作分别达到 64 个线程的峰值时，系统将获得非常好的结果，分别为近 11M op/s 和 470 万 op/s。删除操作在 16 个线程中达到最大 170.6K op/s，并以 222.1K op/s 的 32 个线程创建达到峰值的操作。统计和读取操作具有更多的可变性，但一旦达到峰值，统计和读取的性能不会低于 3M op/s 和 2M op/s。一旦到达稳定状态，创建和删除将更加稳定，并且保持在 140K op/s 以上（用于删除）和 120K op/s（用于创建）。请注意，额外的驱动器不会按预期影响空文件上的大多数元数据操作。
 

---

使用 4 个 KiB 文件的 MDtest 的元数据性能

此测试与上一个测试几乎完全相同，只是使用了 4KiB 的小文件，而不是空文件。
使用以下命令执行基准测试，其中 Threads 是使用线程数的变量（1 到 512 以 2 为单位递增），而 my_hosts.$Threads 是分配在不同节点上的每个线程的对应文件，使用循环调度在 16 个计算节点上以同构方式分布它们。

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

图 6：  元数据性能 — 小文件 （4K）

对于统计和删除操作，系统将获得非常好的结果，分别达到 256 个线程的峰值，分别为 8.2M op/s 和 400K op/s。读取操作达到最大 44.8K op/s，创建操作以 68.1K op/s 达到峰值，两者均为 512 线程。统计和删除操作具有更多的可变性，但一旦达到峰值，Stats 和 280K op/s 的性能不会低于统计信息的 3M op/s。创建和读取的可变性较低，并且随着线程数量的增加而不断增加。可以观察到，容量扩展的额外驱动器仅提供元数据性能的欠佳更改。
由于这些数字适用于具有单个 ME4024 的元数据模块，因此每个附加 ME4024 阵列的性能将会提高，但是我们不能只假设每个操作的线性增加。除非整个文件适合此类文件的索引节点内，否则 ME4084s 上的数据目标将用于存储 4K 文件，从而在一定程度上限制性能。由于信息节点大小为 4KiB，并且仍然需要存储元数据，因此只有大约 3 KiB 的文件适合在内部，任何大于该文件的文件都将使用数据目标。
 

---

结论和未来的工作

具有扩展容量的解决方案不仅能够提高性能，不仅适用于随机访问，甚至还能提高顺序性能。这是预期的，因为分散模式的行为是随机访问，并且拥有更多磁盘可以改进。该性能可在表 4 上概述，从空文件系统到几乎已满，预计性能将保持稳定。此外，随着添加更多存储节点模块，该解决方案的容量和性能也会线性扩展，并且可选的高需求元数据模块可以实现类似的性能提升。此解决方案为 HPC 客户提供了一个非常可靠的并行文件系统，由许多排名前 500 的 HPC 群集使用。此外，它还提供卓越的搜索功能、高级监视和管理，以及添加可选网关，允许通过无处不在的标准协议（如 NFS、SMB 等）向尽可能多的客户端共享文件。

表 4  峰值和持续性能

	峰值性能		持续性能
	写	读取	写	读取
大型顺序 N 客户端到 N 文件	20.4 GB/s	24.2 GB/s	20.3 GB/s	24 GB/s
大型顺序 N 客户端到单个共享文件	19.3 GB/s	24.8 GB/s	19.3 GB/s	23.8 GB/s
随机小块 N 客户端到 N 文件	40KIOps	25.6KIOps	40.0KIOps	19.3KIOps
元数据 创建空文件	169.4K IOps		123.5K IOps
元数据统计信息空文件	1100 万 IOps		320 万 IOps
元数据读取空文件	470 万 IOps		240 万 IOps
元数据 删除空文件	170.6K IOps		156.5K IOps
元数据创建 4KiB 文件	68.1K IOps		68.1K IOps
元数据统计信息 4KiB 文件	820 万 IOps		300 万 IOps
元数据读取 4KiB 文件	44.8K IOps		44.8K IOps
元数据删除 4KiB 文件	40 万 IOps		280K IOps

由于该解决方案旨在随 Cascade Lake CPU 和更快的 RAM 一起发布，因此一旦系统具有最终配置，将执行一些性能点检查。测试具有至少 2 个 ME4024s 和 4KiB 文件的可选高要求元数据模块，以便更好地记录涉及数据目标时元数据性能如何扩展。此外，网关节点的性能将与新博客或白皮书中的即时检查相关结果一起衡量和报告。最后，计划测试和发布更多解决方案组件，以提供更多功能。