增加并行文件系统功能是怎么实现的？（2篇）
在Dell Technologies World 2024上，Dell的ISG营销高级副总裁Varun Chhabra向观众揭晓：“我们很高兴推出‘Project Lightning’项目，该项目将在PowerScale中引入专为非结构化数据设计的并行文件系统。‘Project Lightning’将带来极高的性能和无与伦比的效率，接近线路速率的传输效率——网络利用率高达97%，并能够支持数千个数据密集型GPU。”
PowerScale硬件由最多256个集群节点组成，运行OneFS顺序文件系统软件。在读写文件时，这些操作在存储文件的节点上进行。通过并行文件系统，大文件或一组小文件需要跨节点条带化，每个节点与其它节点并行响应读取或写入请求，以加快I/O操作。
为OneFS定制并行文件系统功能； 从零开始开发一个并行文件系统； 采用开源的并行文件系统——如Lustre、BeeGFS或DAOS； 购买并行文件系统产品或供应商； 转售或OEM其它供应商的文件系统产品。
我们与业内消息人士和专家进行了私下交流，以探究Dell的决策。其主要考虑因素是在OneFS中增加并行文件系统功能，并与数千个OneFS PowerScale/Isilon系统的已有的安装保持兼容，还是构建一个全新的基于并行文件系统的操作系统。虽然后者看似更为简洁，但同样伴随着不少难题。
如果Dell选择转售现有供应商的并行文件系统，如与VDURA（即Panasas）合作销售PanFS或与IBM合作销售Storage Scale，这将会给其现有用户基数带来迁移问题，并存在将客户控制权转移给并行文件系统供应商的风险。OneFS客户可能需要购买新的PowerScale设备并将文件迁移至新设备，这无疑会增加他们需要管理和维护的新孤岛。这种方案似乎较为繁琐。
如果Dell选择购买一个并行文件系统或供应商，同样会面临类似的问题，并且需要投入大量资金。
如果Dell采用开源并行文件系统软件，虽然无需额外投入资金，但需要组建内部支持和开发团队。此外，这也将把控制权交给客户，客户可能会选择其它供应商或自行管理，从而为其数据中心增加另一个孤岛，失去与OneFS的兼容性。
为Dell量身打造自己的并行文件系统软件将是一个庞大且耗时的工程。但这样做可以保持对客户账户的掌控和软件的清洁环境。据一位消息人士透露，这可能需要长达5年的时间才能生产出一个稳定、可靠且高性能的系统。
即便拥有了自己的并行文件系统软件，Dell仍然会给客户的存储环境增加一个孤岛，并失去与OneFS的兼容性，给客户带来迁移和管理上的难题，同时也增加了客户不愿采用全新且未经验证的软件的风险。
考虑到上述所有问题，我们更倾向于列表中的第一个选项，即为OneFS增加并行文件系统功能。
开发人员可以着手修改OneFS的文件组织和访问软件的核心部分，进行替换，或者在现有代码上增加并行访问功能。前者就像是对人脑进行移植手术，如此复杂的操作，或许从头开始编写一个全新的操作系统更为简单直接。
幸运的是，OneFS支持NFS 4.1及其会话功能，该功能于2021年10月加入。OneFS v9.3及更高版本也支持NFS v4.2。
NFS v4.2客户端支持使用Flex Files特性的并行NFS（pNFS）。pNFS功能依赖于NFS 4.1中引入的会话支持。根据SNIA的演示文稿，Flex Files pNFS布局提供了“灵活的、每个文件的条带化模式和适用于将独立的NFS服务器聚合到集中管理的pNFS集群中的简单设备信息。”
实际上，现有的OneFS集群节点作为独立服务器读取和写入NFS文件。在pNFS的架构中，集群节点增加了一个元数据服务器。访问客户端使用特定的pNFS协议与该服务器通信。它使用控制协议与集群节点（称为数据节点）通信，而客户端和数据节点之间仍然使用存储访问协议进行数据传输。
元数据服务器负责向客户端提供文件布局或条带映射，这样客户端就能并行地读取和写入数据服务器（即集群节点）。SNIA演示文稿的后续幻灯片强调了pNFS元数据服务器的一个关键特性：
它不必是独立的物理或虚拟服务器，实际上可以作为数据服务器中的独立代码来运行。
这意味着，如果OneFS进行了pNFS改造，那么现有集群节点之一就可以运行元数据服务器功能，从而实现OneFS集群的就地升级。
值得关注的是，Hammerspace在其数据编排软件中采取了类似的方法。Hammerspace基于pNFS并使用Anvil作为元数据服务节点。
此外，正如我们在2023年11月所述：“Hammerspace的并行文件系统客户端是一个内置于Linux的NFS 4.2客户端，它利用了Hammerspace的FlexFiles（灵活文件布局）软件。”
激活OneFS中已经原则上支持的pNFS功能，将使Dell能够将OneFS业务拓展到AI训练所需的高性能并行访问领域。虽然它并非一个全新的并行文件系统，但会显著提升OneFS的文件传输带宽。现有的PowerScale集群将转变为支持并行访问的集群。
这种性能提升将使PowerScale在竞争对手Pure Storage（FlashBlade）和Qumulo中脱颖而出，与NetApp形成有力竞争，为Dell提供对抗Hammerspace的武器，并抵御VAST Data和HPE OEM的VAST Data以及IBM的StorageScale对客户的吸引力。这种方法的优势不言而喻。
值得注意的是，任何支持NFS标准的供应商都可以采取类似的方法，特别是NetApp，它已经这样做了，还有Qumulo。后者的CTO Kiran Bhageshpur表示：“Qumulo专注于一个基于标准的系统，从端到端，实现平台商品化；在本地、边缘和公有云中；不使用特殊硬件，仅基于标准的互连技术（以太网和TCP/IP）和基于标准的访问协议（NFS、SMB、FTP、S3等）。”
“我们清楚，Qumulo能够在标准化环境中，无需专用硬件、专用互连技术（如Infiniband）或专用客户端（如‘并行文件系统’），在实际工作负载下超越任何竞争对手，并为客户提供更低的TCO。”
Qumulo的Core软件在2021年底增加了对NFS 4.1的支持，但尚未支持4.2。而NetApp的ONTAP同时支持NFS 4.1和4.2。Qumulo可以通过增加对NFS 4.2的支持并使用pNFS来实现并行访问，而NetApp已经实现了这一点。
NetApp的首席工程师Srikanth Kaligotla在博客中讨论了pNFS和AI/ML工作负载：“在NetApp ONTAP中，扩展型NAS、FlexGroup、RDMA上的NFS、pNFS和会话分支等技术可以成为支持AI/ML工作负载的基石。”
ONTAP用户现在可以启用pNFS功能。可以说，NetApp为OneFS的并行化提供了一条明确的路径。
综上所述，我们的推测是，Dell正在为OneFS添加pNFS功能，将其打造成我们所说的“pOneFS”系统。
为什么并行NFS是AI/ML工作负载的理想选择
AI工作负载的性能需求往往围绕着操作规模和完成速度这两个方面。为了满足这些苛刻的要求，一些久经考验的数据中心存储环境常常被忽视，取而代之的是用户会构建定制化、复杂的解决方案，这些方案往往独立成“孤岛”，难以维护。更令人担忧的是，尽管NFS是目前最普遍使用的文件系统环境，但将其用于AI/ML领域却存在负面评价。
关于在AI/M环境中使用NFS的误解和反对意见，往往源于配置效率低下以及拒绝使用NFS的最新功能。在本文中，我的目标是强调NFS的改进之处，并展示其在无缝启动AI环境方面的前景，同时满足所有相关需求。作为佐证，本文将重点介绍NetApp® ONTAP®软件的能力，它可以在不改变主机环境的情况下为AI/ML工作负载提供服务，同时满足甚至超越既定需求。
AI/ML工作负载的挑战
随着AI应用场景的增多，数据访问、数据计算和数据存储的压力不断增加。为了充分发挥GPU的性能，需要确保数据能够随时访问。像GPUDirect Storage这样的技术通过高速带宽连接，极大地促进了对大量存储的访问。为实现这种访问，GPU和存储阵列之间建立了多条并行通道。选择合适的传输方式对于确保网络通道的饱和也至关重要。实际上，NFSv3服务器无法处理这种负载，因为它的设计基于单服务器多客户端模型。
为了充分利用数据中心内的连接带宽并保持GPU高效运转，需要一个能够驱动存储和计算节点之间并发I/O的多I/O路径架构。并行文件系统通过将数据分成多个部分并存储在多个服务器上，提供了并发访问的能力。这样的文件系统通过独特的索引方式，使数据的各个区域能够同时被访问。这种对多个I/O路径的协调使用显著提高了I/O性能。
此外，由于NFSv3无法分离流量，元数据性能成为推动用户选择并行文件系统的另一个关键因素。然而，设置并行文件系统成本较高，且需要仔细考虑其维护问题。不仅如此，还要面对供应商锁定、专有客户端以及数据孤岛等问题。
变革者：NFSv4.1
NFS的4.1版本解决了在建立高速访问NFS时的多种变通方法和限制，这是对该协议的一次重大改进，主要侧重于性能提升。
并行NFS
在NFS 4.1版本中，并行NFS（pNFS）真正实现了横向扩展，允许数据分布在多个服务器上，并可通过多路径直接被客户端访问。pNFS的另一大亮点是支持客户端使用文件布局驱动程序与服务器通信。这一设计使得流量可以分离，元数据（描述文件属性的文件系统调用）和数据（读写流量）能够由集群中的不同服务器独立处理。
图中展示了在挂载操作（如打开、关闭、状态查询、查找和读取目录）期间，元数据服务器（MDS）的多个连接。存储在任何高速节点上的用户数据都可以通过数据服务器（DS）直接访问。这些连接是基于文件布局的响应动态建立的。
AI/ML工作负载套件中的许多任务在能够分离数据与元数据时表现优异。并且，这种架构为不同类型的操作和文件范围提供了独立的连接，非常适合运行AI/ML工作负载。
会话捆绑
仅分离NFS流量并提供I/O访问的直接路径并不足以充分利用所有可用带宽。在客户端和服务器之间创建多个连接是饱和网络连接的有效方法。NFSv4.1引入的会话捆绑功能就实现了这一点。通过聚合到数据服务器的所有可用接口的吞吐量，会话捆绑有助于最大化网络带宽。这种聚合是通过在同一会话中关联多个连接（每个连接可能具有不同的源和目标网络地址）来实现的。
如图所示，现在NFS操作可以在客户端和服务器之间通过所有可用接口的组合吞吐量进行。这种网络带宽的多路复用为NFS远程过程调用（RPC）的传输创建了高速通道。
pNFS捆绑
通过将多路径能力与pNFS结合，我们现在有了集中的通道来传输文件系统的元数据或读/写流量，或两者兼而有之。这种架构与其它并行文件系统非常相似，但无需高昂的设置和维护成本。以下图示展示了并行文件系统Lustre与pNFS在架构上的相似性。
采用标准化的NFS语义，我们现在可以在久经考验的环境中实现高速磁盘、高速网络和强大计算能力的协同工作。
ONTAP的更新
正如前面的技术讨论所述，AI/ML是一场关于吞吐量的竞赛。工作负载主要包括数据处理、模型训练和推理。从存储的角度来看，这意味着在最终生成模型之前，需要导入和导出大型数据集，并进行周期性检查点。在NetApp ONTAP中，横向扩展NAS、FlexGroup、基于NFS over RDMA、pNFS和会话捆绑等技术——以及其它众多技术——可以成为支持AI/ML工作负载的坚实基础。
数据布局
随着AI/ML数据集规模的不断增长，它们必须作为一个整体进行处理。FlexGroup是处理这类数据的理想选择，因为它提供了在集群内均匀分布数据的自由和灵活性。从集群中的任何节点均匀访问数据的能力使解决方案真正实现了横向扩展，没有热点，能够充分利用整个集群的聚合带宽。想象一个8节点的ONTAP集群，每个节点配有双100Gbps RoCE端口，那么系统现在就拥有了高达800Gbps的总带宽，这对于完成AI/ML的单个任务已经足够了！
数据传输
支持NFS over RDMA传输规格，消除了内存复制的低效。数据可以直接从主机的系统内存复制到服务器，反之亦然，从而消除了CPU开销。这一功能在通过NFS实现高速数据传输方面是一个重大改进。
此外，该技术还与GPUDirect Storage兼容。像CUDA这样的新编程模型（由NVIDIA为并行计算开发）可以本地使用NFS over RDMA。如果数据科学家正在使用启用CUDA的程序，他们可能不会关心数据存储在哪里；数据通过NFS over RDMA语义直接从存储被导入GPU内存。成熟的ONTAP NFS堆栈一直是NFS over RDMA的早期应用者，并在GPUDirect Storage的所有方面进行了优化。
数据加速
最后，充分利用可用带宽的关键是运行多个NFS流的能力。ONTAP对于RDMA挂载的pNFS和会话捆绑的实现避免了非一致性内存访问（NUMA），并聚合了每个节点上所有可用接口卡的带宽。随着集群的扩展，动态创建和扩展I/O连接的能力有助于您的AI/ML工作负载在添加更多应用场景时保持同步。
结果
ONTAP通过FlexGroup卷在整个集群中均匀分布数据，并通过优化传输消除了数据传输中的低效，从而实现了接近在线速率的数据吞吐量。为了验证这一点，我们进行了一系列测试。启用了GPUDirect Storage的NVIDIA DGX A100系统连接至一个由4对HA配对的NetApp AFF A800集群构成的系统。配置过程无需对主机环境进行任何更新。关键在于其设置的简便性，使得AI/ML工作负载能够以无与伦比的速度运行。
图中展示了NVIDIA DGX A100系统的示意图，每个ONTAP节点仅配备两个RoCE接口。实现的吞吐量接近线路速率的86%，事后工程分析显示每个节点仍有进一步的扩展空间。
使用pNFS和ONTAP优化AI/ML工作负载！
对于AI/ML工作负载而言，一个能够跟上数据规模且不影响数据访问的文件系统是最基本的要求。然而，在满足这一基本要求之后，设置的简便性和功能的丰富性则成为定义AI/ML环境的关键因素。虽然使用特定供应商的专有文件系统可以实现高速，但这些存储系统中的数据将被永久隔离。需要构建一个通用的文件系统，不仅满足或超过AI/ML的要求，同时不牺牲其被非专有系统访问的能力。
ONTAP的这些新功能也有助于反驳关于NFS在AI/ML工作负载中表现不佳的负面说法。NFS具有多种类型，特别是通过pNFS捆绑处理大规模数据存储和访问的能力，可以确保AI/ML引擎的稳定运行。
Source:Srikanth Kaligotla; Why Parallel NFS is the right choice for AI/ML Workloads; February 28, 2024
--【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/单位/关注领域）