概述
NFS 英文即 Network File System，网络文件系统，是由 SUN 公司研制的 UNIX 表示层协定(presentation layer protocol)，它最大的性能就是能够通过网络，让不同的机器、不同的操作系统能够共享彼此的文件，能使使用者拜访网络上别处的文件就像在应用本人的计算机一样。
NFS 作为最罕用的网络文件系统可能提供简略易用、功能强大的存储解决方案。得益于其简略、成熟、易使用等个性，简直在 Linux 每一发行版本中都是规范组件。NFS 比拟适宜串行应用程序（串行读写文件）模式，而当零碎和数据集数量增多时或并行读写文件，NFS 可能就不是最佳的解决方案了。本文次要介绍 NFS 存储在 HPC 场景利用可能存在的性能、一致性、负载均衡性等问题，帮忙大家去了解为什么分布式并行存储系统更加适宜大型 HPC 环境。
HPC 超算环境 NFS 可能存在的问题
存储 IO 负载不平衡
NFS 是 C/S（客户端(Client)/ 服务器(Server)）架构的协定，由一个 NFS 客户端程序和 NFS 服务器程序组成。所以要求计算集群中每个计算节点都要挂载一个 NFS 服务器，而且挂载关系也是固定；在计算服务器开机的时候执行挂载动作，关机的时候再断开连接。
通常 HPC 超算集群中计算节点和存储节点的数量个别会是 6:1 或更高的比例，因而多台计算节点会挂载到同一台 NFS 存储服务器上。为取得最好性能，计算服务器与 NFS 服务器之间的对应关系要尽量放弃平衡，见下图：
如图所示，一个由 18 台计算节点，3 台 NFS 存储服务节点（以下简称：存储节点）组成的 HPC 集群环境。通过 DNS 域名挂载性能通常能使每台存储节点比拟平均地被 6 台计算节点挂载。假如一个计算工作占用 6 台计算节点，这 6 台计算服务器是由作业调度软件随机调配的。最坏的状况下，这 6 台计算节点挂载的都是同一台存储节点。那么 6 台计算节点上的 MPI 汇合 IO 操作都会压到这 1 台存储节点，即：NFS 存储服务器上。而另外 2 台存储节点则处于闲暇状态，这就造成了 2 /3 的存储资源的节约。
即使呈现这类极其不平衡情景的概率不大，但中等不平衡情况呈现的概率还是相当大的。比方，同样还是这个占用 6 台计算节点的计算工作，其中有 4 台计算节点挂载到存储节点 1，另外 2 台计算节点别离挂载到了存储节点 2 和存储节点 3，即存储节点的负载比例是 4:1:1。然而 MPI-IO 中的汇合 IO 完结时会有一个过程间同步，因而，聚合 IO 操作的速度取决于最慢过程的速度，即取决于负载最重的 NFS 服务器存储节点 1 的速度。
因为 NFS 的这种挂载机制，即：一旦挂载胜利，客户端中途不会主动扭转所挂载的 NFS 服务器，很容易呈现存储 IO 负载不平衡的状况。而分布式并行文件系统（例如：YRCloudFile）的数据 IO 形式是不同的，首先公有客户端通过与存储集群的 MDS（元数据服务）通信，并取得数据所在位置，之后客户端能够间接拜访任意的 OSS（存储数据服务）节点，因而不存在相似的负载不均问题。
数据直达提早高
NFS 客户端读写一个文件的时候只能向已挂载的 NFS 服务器发动申请，而文件数据被打散散布在多个 NFS 服务器上，所以 NFS 服务器上会有一个直达操作，见下图：
如上图所示，计算节点 1 须要向 NFS 存储节点 1 写入 3 个间断数据块 D0~D2，而数据块 D0~D2 别离搁置在 NFS 存储节点 1- 3 上。因而，NFS 存储节点 1 须要在缓冲区暂存数据 D0~D2，将 D0 写入本人的本地硬盘，通过网络将 D1 和 D2 别离发送给 NFS 存储节点 2 和 3。等 D0~D2 都正确地写入硬盘，存储服务器节点 1 才会向计算节点 1 返回写胜利的信号。
如果将计算服务器与 NFS 存储节点（存储服务器）之间的数据流量称为内部流量，而将 NFS 存储节点之间的数据流量（数据直达所产生的流量）称为外部流量。显然上图中的内部流量为 9（9 个数据块），外部流量为 6。由此能够推算出，当 NFS 存储节点的数量为 M 的时候，内部流量与外部流量的比例是 M:M-1。在存储节点数据较大（M 较大）时，例如：10 个存储节点，此时无效流量（内部流量）所占总流量的比例大概等于 50%，相当于将网络带宽下限升高于一半，重大影响文件系统性能。一个解决办法是独自配置网络设备（交换机、网卡）专为走外部流量应用，然而这样做无疑减少了老本。而且即便这样也依然无奈解决 IO 门路长的问题：文件数据从 NFS 客户端走到 NFS 服务器上的硬盘上，简直都要走一个直达过程，必然导致延时变长。
咱们来看一组比照，看看分布式并行存储（如：YRCloudFile）的 IO 门路，见下图，装置在计算节点上的 YRCloudFile 公有客户端先从元数据服务器（MDS）取得文件分布图(layout)，而后就晓得了每一个数据块都寄存在哪个 OSS 服务器的哪个地位，YRCloudFile 客户端间接从相应的 IO 服务器上读取数据块，没有直达，节俭外部流量而且打消了直达延时。
文件锁和一致性问题
在大规模并发数据拜访的场景，NFS 最重大的问题还是文件锁和一致性问题。首先咱们来讨论一下文件锁的问题：
NFS 协定是为串行拜访设计的，即每个客户端拜访不同的文件，不反对多个客户端同时拜访同一个文件。具体表现为，文件描述符（Open 函数返回的文件句柄）不能共享，即：如果 N 个客户端想同时读写同一个文件，那么 N 个客户端都必须调用一次 open 函数以便失去文件描述符。这个 N 客户端尽管关上同一个文件，但客户端之间并不互相协调，互相不晓得对方的动作，可能导致写抵触。
如下图，假如 NFS 客户端 C1 和 C2 同时写文件 f1.txt，C1 写的范畴是 [0-1023] 字节，而 C2 写的范畴是 [512-1515] 字节。依照 NFS 协定，C1 和 C2 之间是不互相协调的，那么就可能导致 C1 和 C2 同时写文件区间[512-1023]，文件中最终数据不可预知。
而为了防止数据抵触，须要应用文件锁函数 fcntl。在 C1 筹备写文件的 [0-1023] 字节时，先调用 fcntl 函数锁住这个文件区间，以便客户端 C1 独占操作。客户端 C2 写文件区间 [512-1023] 写数据时，文件系统发现区间[512-1023] 被客户端 C1 锁住了，于是让客户端 C2 期待。只有当客户端 C1 写操作实现之后 C2 能力开始写。
fcntl 保障并行 IO 操作的正确性，代价是升高了性能。依照 MPI-IO 剖析文章中的教训推断，汇合 IO 波及的 MPI 过程越多，锁竞争越强烈，性能降落越重大。
接下来再看看数据一致性的问题：
因为 NFS 设计时就没有思考多个过程同时读写同一个文件的状况，所以 NFS 客户端就能够采纳激进的缓存机制：岂但缓存文件数据还缓存文件属性信息。文件属性蕴含：读、写、执行权限、atime/mtime/*ctime 等。
这样一来，多个 MPI 过程聚合 IO 时就有文件同步的问题：如果开启了数据缓存机制，过程 A 通过 NFS 客户端 C1 写入文件区间[0-511]，操作返回时，文件数据可能曾经写到 NFS 服务器的硬盘上了，也可能还停留在 C1 客户端的缓存里。假如紧接着的 MPI 聚合 IO 操作要求过程 B 通过 NFS 客户端 2 读取文件区间[0-511]，这时就会呈现 3 种状况：
- 状况一：NFS 客户端 1 曾经将文件区间 [0-511] 写入 NFS 服务器，且 NFS 客户端 1 也没有缓存区间 [0-511] 的数据。此时过程 B 通过客户端 2 读文件区间 [0-511] 的申请使得客户端 2 向 NFS 服务器申请文件数据，从而过程 B 能失去正确数据。
- 状况二：NFS 客户端 1 还没有将文件区间 [0-511] 写入 NFS 服务器，依然保留在缓存中。此时 NFS 客户端 2 无论如何也读不到最新的数据，从而过程 B 能失去谬误的旧数据。
- 状况三：NFS 客户端 1 曾经将文件区间 [0-511] 写入 NFS 服务器，而 NFS 客户端 2 本地缓存了文件属性和文件区间 [0-511] 的数据。过程 B 向客户端 2 申请读文件区间 [0-511] 时，客户端 2 就会比照文件数据缓存的更新工夫和文件属性缓存中记录的文件最初批改工夫（mtime 等）。因为客户端 1 不能被动向客户端 2 推送文件曾经更新音讯，而客户端 2 缓存的刷新又有肯定的工夫距离，所以客户端 2 就可能得出谬误的论断：缓存中的文件数据就是最新的，不必从 NFS 服务器从新读取。最终导致过程 B 读到谬误的旧数据。
通过下面的剖析，要保障 IO 后果正确的必要条件是：一个过程的操作后果能被其它过程立刻看到，即：将写操作波及的文件数据立刻刷入 NFS 服务器，同时文件属性信息在过程间要放弃同步，就能防止上述那些谬误状况的产生。
要保障文件属性同步须要用 noac 选项关掉文件属性缓存，使得 NFS 客户端每次查看文件属性的时候都要向 NFS 服务器抓取。然而，关掉了缓存，就使得向 NFS 服务器写入、申请文件属性的次数大大增加，造成存储系统性能的降落。
性能比照：YRCloudFile 公有客户端 VS NFS 客户端
咱们能够通过对 YRCloudFile 分布式文件存储系统理论环境的测试，来直观比照 NFS 和公有客户端在 IO 方面性能体现的差异。
硬件环境
软件环境
网络拓扑图
如上图所示，共 3 台存储节点，其中存储网络应用单口 25Gbps 网络相连，管理网络应用单口千兆网络相连。4 台客户端服务器，每台应用单口 25Gbps 网络与存储服务器连贯。
测试性能比照如下
4K IOPS 性能测试
512K 带宽性能测试
从下面测试后果可能清晰的看出，公有客户端的性能显著高于通用的 NFS 客户端。
论断：YRCloudFile VS NFS
NFS 并不是一个高性能的协定，并不善于解决大规模并发的数据拜访。综上所示，在 HPC 等高并发场景中存在负载不平衡、数据直达 IO 门路长，以及为了保障一致性、防止数据写入抵触，而敞开了缓存和应用文件锁 fcntl 等所带来的诸多性能问题。HPC 环境会依据计算需要构建不同规模的分布式计算集群，并通过计算作业调度零碎将计算工作被散布到各个计算节点。因为超算集群的数据量很大，要解决计算节点所带来的 IO 流量瓶颈问题，往往须要应用分布式架构的文件存储系统。
焱融科技分布式并行文件系统 YRCloudFile 区别于 NFS 存储客户端零碎，能够间接拜访所有存储节点以进行数据传输，而不用通过协定服务器。YRCloudFile 将文件数据切分并搁置到多个存储设备中（各个被切分的数据如何搁置，由并行文件系统通过算法来管制，能够基于元数据服务或相似一致性哈希的形式实现），零碎应用全局名称空间来进行数据拜访。通过 YRCloudFile 的客户端能够同时应用多个 IO 门路将数据读 / 写到多个存储设备。可能提为大规模、高并发的 HPC 计算群集提供卓越的存储性能。同时，配合预读策略能够无效的缩小存储和应用程序的 I/O 等待时间，进一步晋升存储的 I/O 性能。
atime(access time, 最初 1 次访问工夫)；mtime(modification time，最初批改工夫)*ctime(change time，元数据的最初扭转工夫)