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

HPC 和 AI 创新实验室的 Mario Gallegos 于 2019 年 10 月撰写的文章

目录

1. 简介
   1. 解决方案体系结构
   2. 解决方案组件
2. 性能特征分析
   1. 连续 IOzone 性能多客户端对多文件
   2. 顺序 IOR 性能多客户端对一个文件
   3. 随机小数据块 IOzone 性能多客户端对多文件
   4. 使用 MDtest 和空文件测试元数据性能
   5. 使用 MDtest 和 4 KiB 文件测试元数据性能
   6. 使用 MDtest 处理 3K 文件的元数据性能
3. 高级分析
4. 结论和未来的工作

简介

解决方案体系结构

解决方案组件

性能特征分析

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

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

   

  ---

  连续 IOzone 性能多客户端对多文件

  顺序多客户端对多文件的性能是使用 IOzone 版本 3.487 测量的。执行的测试从单个线程到 1024 个线程不等。
  通过将可调节的 GPFS 页面池设置为 16GiB 并使用大小超过该值两倍的文件，最大限度地减少了缓存的影响。需要注意的是，对于 GPFS，该可调参数设置用于缓存数据的最大内存量，而与已安装和可用的 RAM 量无关。此外，需要注意的重要一点是，在以前的 Dell EMC HPC 解决方案中，大型顺序传输的数据块大小为 1 MiB，而 GPFS 格式化为 8 MiB 数据块，因此在基准测试中使用该值以获得最佳性能。这可能看起来太大并且明显会浪费太多空间，但 GPFS 使用子数据块分配来防止这种情况。在当前配置中，每个数据块细分为 256 个子数据块，每个子数据块 32 KiB。
  以下命令用于执行写入和读取基准测试，其中 Threads 是具有所用线程数量的变量（1 到 1024 的幂为 2），threadlist 是在不同节点上分配每个线程的文件，使用轮循在 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 个并发客户端，大文件顺序性能也是稳定的。请注意，在 32 个线程时，最大读取性能为 23 GB/s，瓶颈很可能是 InfiniBand EDR 接口，而 ME4 阵列仍有一些额外的性能可用。同样地，请注意，16.7 的最大写入性能是在 16 线程时略早达到的，与 ME4 阵列规格相比，它显然较低。
  在这里，重要的是要记住，GPFS 首选操作模式是分散的，并且解决方案被格式化为使用它。在此模式下，块从一开始就以伪随机方式分配，将数据分散在每个 HDD 的整个表面上。明显的缺点是初始最大性能较小，但无论文件系统上使用了多少空间，性能都会保持稳定。与其他并行文件系统相比，它一开始使用磁盘旋转一周可保存更多数据（扇区）的外部磁道，因此具有 HDD 可提供的最高性能，但随着系统使用更多空间，开始使用旋转一周可保存更少数据的内部磁道，性能也随之下降。 
  
   

  ---

  顺序 IOR 性能多客户端对一个文件

  顺序多客户端对单个共享文件性能是使用 IOR 版本 3.3.0 测量的，在 OpenMPI v4.0.1 的协助下在 16 个计算节点上运行基准测试。执行的测试从单线程到 1024 线程不等。
  通过将可调节的 GPFS 页面池设置为 16GiB 并使用大小超过该值两倍的文件，最大限度地减少了缓存的影响。此基准测试使用了 8 MiB 数据块来获得最佳性能。前面的性能测试部分对这些问题有更完整的解释。
  以下命令用于执行写入和读取基准测试，其中 Threads 是具有所用线程数的变量（1 到 1024 的幂为 2），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 的顺序性能
  
  从结果中，我们可以观察到，性能随着使用的客户端数量的增加而再次快速上升，然后达到读取半稳定、写入非常稳定的平台期，一直到此测试中使用的最大线程数。因此，即使对于 1024 个并发客户端，大型单个共享文件顺序性能也是稳定的。请注意，在 16 个线程时，最大读取性能为 23.7 GB/s，瓶颈很可能是 InfiniBand EDR 接口，而 ME4 阵列仍有一些额外的性能可用。此外，读取性能从该值下降，直到达到大约 20.5 GB/s 的平台，在 128 个线程下短暂下降到 18.5 GB/s。同样，请注意，在 16 个线程时达到了 16.5 的最大写入性能，与 ME4 阵列规格相比，它显然较低。
   

  ---

  随机小数据块 IOzone 性能多客户端对多文件

  使用 IOzone 版本 3.487 测量随机 N 个客户端到 N 个文件的性能。执行的测试从单线程到 1024 线程不等。此基准测试使用 4 KiB 数据块来模拟小数据块流量。
  通过将 GPFS 页面池可调参数设置为 16GiB 并使用两倍于该大小的文件，将缓存效果降至最低。第一个性能测试部分更全面地解释了为什么它在 GPFS 上有效。
  以下命令用于在随机 IO 模式下执行写入和读取基准测试，其中 Threads 是具有所用线程数量的变量（1 到 1024 的幂为 2），threadlist 是在不同节点上分配每个线程的文件，使用循环在 16 个计算节点之间均匀分布它们。

  ./iozone -i2 -c -O -w -r 4K -s 32G -t $Threads -+n -+m ./threadlist

  
  图 4：  N 到 N 随机性能
  
  从结果中，我们可以观察到，写入性能从接近 8.2K IOPS 的高值开始，然后稳步上升到 128 个线程，达到一个平台期，并保持接近最大值 16.2K IOPS。另一方面，读取性能在超过 200 IOPS 时起步非常小，并且随着使用的客户端数量几乎呈线性增长（请记住，每个数据点的线程数翻倍），并在 512 个线程时达到 20.4K IOPS 的最大性能，并且没有达到最大值的迹象。但是，在当前 16 个计算节点上使用更多线程，每个节点有两个 CPU，并且每个 CPU 有 18 个内核，其限制是没有足够的内核来运行最大数量的 IOzone 线程 （1024），而不会产生上下文切换（16 x 2 x 18 = 576 个内核），这会极大地限制性能。将来使用更多计算节点的测试可以检查使用 IOzone 的 1024 个线程可以实现的随机读取性能，或者可以使用 IOR 来调查超过 1024 个线程的行为。
  
   

  ---

  使用 MDtest 和空文件测试元数据性能

  元数据性能是使用 MDtest 版本 3.3.0 测量的，在 OpenMPI v4.0.1 的协助下在 16 个计算节点上运行基准测试。执行的测试从单线程到最多 512 个线程。该基准测试仅用于文件（无目录元数据），获取解决方案可以处理的创建、统计、读取和删除数量。
  为了正确评估该解决方案与其他 Dell EMC HPC 存储解决方案的比较情况，使用了可选的高需求元数据模块，但对于单个 ME4024 阵列，即使本工作中测试的大型配置也被指定为具有两个 ME4024。
  此高需求元数据模块最多可支持四个 ME4024 阵列，建议在添加另一个元数据模块之前将 ME4024 阵列的数量增加到 4 个。预计每增加一个阵列，额外的 ME4024 阵列都会线性提高元数据性能，但统计操作（和空文件的读取除外），因为这些数字非常高，在某些时候 CPU 将成为瓶颈，并且性能不会继续线性提高。
  使用了以下命令来执行基准测试，其中 Threads 是使用的线程数的变量（从 1 到 512，以 2 的幂次方递增），my_hosts.$Threadst 是将每个线程分配到不同节点上的对应文件，使用轮询在 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 个线程处以 11.2M op/s 和 4.8M op/s 达到峰值。删除操作在 16 个线程下达到最大值 169.4K op/s，而创建操作在 512 线程处达到峰值，操作速度为 194.2K op/s。统计和读取操作具有更多的可变性，但达到峰值以后，统计操作性能不会低于 3M op/s，和读取操作性能不会低于 2M op/s。“创建”和“删除”在达到平台后会更加稳定，并且“删除”会保持在 140K op/s 以上，创建操作会保持在 120K op/s 以上。
   

  ---

  使用 MDtest 和 4 KiB 文件测试元数据性能

  此测试与上一个测试几乎完全相同，只是使用了 4KiB 的小文件，而不是空文件。
  使用了以下命令来执行基准测试，其中 Threads 是使用的线程数的变量（从 1 到 512，以 2 的幂次方递增），my_hosts.$Threadst 是将每个线程分配到不同节点上的对应文件，使用轮询在 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）
  
  系统在 Stat 和 Removal 操作方面获得了非常好的结果，分别在 128 个线程、7.7M op/s 和 1M op/s 时达到峰值。删除操作达到最大值 37.3K op/s，创建操作达到峰值（55.5K op/s），两者均为 512 个线程。统计信息和删除操作具有更大的可变性，但是一旦达到峰值，统计信息的性能不会低于 400 万次操作/秒，删除操作的性能也不会低于 200K 操作/秒。创建和读取的可变性较低，并随着线程数量的增加而不断提供。
  由于这些数字适用于具有单个 ME4024 的元数据模块，因此每增加一个 ME4024 阵列，性能就会提高，但我们不能只假设每次操作都会呈线性增长。除非整个文件可以放到此类文件的索引节点内，否则 ME4084 上的数据目标将用于存储 4K 文件，从而在一定程度上限制性能。由于索引节点大小为 4KiB，并且仍然需要存储元数据，因此只有大约 3 KiB 的文件能够保存在其中，任何大于该大小的文件都将使用数据目标。
   

  ---

  使用 MDtest 处理 3K 文件的元数据性能

  此测试与之前的测试几乎完全相同，只是使用了 3KiB 的小文件。主要区别在于这些文件完全适合信息节点。因此，不使用存储节点及其 ME4084，通过仅使用 SSD 介质进行存储并减少网络访问来提高整体速度。
  使用了以下命令来执行基准测试，其中 Threads 是使用的线程数的变量（从 1 到 512，以 2 的幂次方递增），my_hosts.$Threadst 是将每个线程分配到不同节点上的对应文件，使用轮询在 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 3K -e 3K

   

  
  图 7：元数据性能 — 小型文件 （3K）
  
  系统在 256 个线程处分别以 8.29M op/s 和 5.06M op/s 达到峰值，获得了非常好的 Stat 和 Read 操作结果。删除操作在 128 个线程下达到最大值 609K op/s，在 512 个线程下创建操作达到峰值，达到 78K op/s。与“创建”和“删除”相比，“统计”和“读取”操作具有更大的可变性。对于两个较高的线程点，删除操作会使性能略有下降，这表明 128 个线程后的持续性能将略高于 400K op/s。创建线程不断增加到 512 个，但看起来达到了一个平台期，因此最大性能可能仍低于 100K op/s。
  由于此类小文件完全存储在基于 SSD 的元数据模块上，因此需要卓越小文件性能的应用程序可以使用一个或多个可选的高要求元数据模块来提高小文件性能。但是，按照当前标准，适合信息节点的文件非常小。此外，由于元数据目标使用 SSD 相对较小（最大大小为 19.2 TB）的 RAID 1，因此与存储节点相比，容量将受到限制。因此，必须小心避免填满元数据目标，这可能会导致不必要的故障和其他问题。
   

  ---

  高级分析

  在 PixStor 功能中，通过高级分析监视文件系统对于大幅简化管理至关重要，有助于主动或被动地发现问题或潜在问题。接下来，我们将简要介绍其中的一些功能。
  图 8 显示了基于文件系统容量的有用信息。左侧是文件系统已用空间总量，以及基于已用文件系统容量的前十个用户。右侧是历史视图，其中包含多年来的已用容量，然后是使用容量最多的 10 种文件类型和使用的 10 大文件集，均基于已用容量，采用类似于帕累托图的格式（不包括行表示累计总计）。利用这些信息，可以轻松找到用户获得的文件系统超出其公平份额的容量、容量使用趋势以帮助确定未来的容量增长、哪些文件占用了大部分空间或者哪些项目占用了大部分容量。
  
  
  图 8：  PixStor Analytics - 容量视图
  
  图 9 提供了一个文件计数视图，其中包含两种非常有用的查找问题的方法。屏幕的前半部分以饼图的形式显示前十名用户，以及采用类似于帕累托图的格式的前十名文件类型和前十名文件集（想想项目），所有这些都基于文件数量。此信息可用于回答一些重要问题。例如，哪些用户通过创建过多文件来独占文件系统，哪种类型的文件正在制造元数据噩梦，或者哪些项目占用了大部分资源。
  下半部分有一个直方图，其中包含针对不同文件大小使用 5 个类别的文件大小的文件数量（频率）。这可用于了解整个文件系统中使用的文件大小，与文件类型协调可用于确定压缩是否有用。
  
  
  图 9：  PixStor Analytics - 文件计数视图

  
  
   

  ---

  结论和未来的工作

  如 表 4 所示，当前的解决方案能够提供相当好的性能，无论使用的空间如何（因为系统是在分散模式下格式化），预计性能将是稳定的。此外，随着添加更多存储节点模块，该解决方案的容量和性能会线性提升，可选的高需求元数据模块也可以实现类似的性能提升。此解决方案为 HPC 客户提供了一个非常可靠的并行文件系统，它被许多排名前 500 的 HPC 群集使用。此外，它还提供卓越的搜索功能、高级监控和管理，并且添加可选网关允许通过无处不在的标准协议（如 NFS、SMB 等）将文件共享给尽可能多的客户端。
  
  表4  巅峰和持续的性能
  
   

  	峰值性能		持续性能
  	写入	读取	写入	读取
  大型顺序多客户端对多文件	16.7 千兆字节/s	23 千兆字节/s	16.5 千兆字节/s	20.5 千兆字节/s
  大型顺序多客户端对单个共享文件	16.5 千兆字节/s	23.8 GB/s	16.2 千兆字节/s	20.5 千兆字节/s
  随机小数块多客户端对多文件	15.8KIOps	20.4KIOps	15.7KIOps	20.4KIOps
  元数据创建空文件	169.4K IOps		127.2K IOps
  元数据统计空文件	1120 万 IOps		3.3M IOps
  元数据读取空文件	480 万 IOps		2.4M IOps
  元数据删除空文件	194.2K IOps		144.8K IOps
  元数据创建 4KiB 文件	55.4K IOps		55.4K IOps
  元数据统计 4KiB 文件	6.4M IOps		4M IOps
  元数据读取 4KiB 文件	37.3K IOps		37.3K IOps
  元数据删除 4KiB 文件	1M IOps		219.5K IOps

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

  ---