亚马逊AWS官方博客

告别 nconnect 限制：FSx for NetApp ONTAP pNFS + Multi HA Pairs 解锁企业级文件存储极致性能

背景

在企业级应用场景中，我们经常遇到这样的困境：客户的业务场景，如

AI/ML 训练、高性能计算、大数据分析等工作负载对文件存储的单机性能有明确的性能要求，如需要单机实现 3+ GB/s 的吞吐量。然而，企业在实现这一目标时面临两大核心挑战： 内核版本受限：生产环境运行在 Linux 5.3 或更早版本，由于应用兼容性、认证要求或企业政策限制，无法轻易升级内核 nconnect 参数限制：无论 NFSv3 还是 NFSv4，在旧内核下都无法使用 nconnect 参数（需要 Linux 5.3+ 才支持），导致单客户端吞吐受限于单个 TCP 连接

典型客户场景

场景一：制药企业统计分析系统

• 生产环境：RHEL 7.9 (Kernel 3.10)，通过 FDA 21 CFR Part 11 验证
• 业务需求：SAS 大数据集分析，单核需 100+ MB/s，多核并行单客户端需 3+ GB/s
• 现实困境：内核升级需 FDA 重新验证，周期 12-18 个月

场景二：生物科技公司基因组分析

• 生产环境：CentOS 7 (Kernel 3.10)，GxP 验证环境
• 业务需求：全基因组数据分析，单样本 30GB，批量处理需 10+ GB/s
• 现实困境：监管要求严格，系统变更需重新验证

场景三：制造业 HPC 仿真

• 生产环境：SUSE Linux Enterprise 12 (Kernel 4.4)
• 业务需求：CFD 仿真计算，需要 12+ GB/s 持续吞吐
• 现实困境：应用栈复杂，内核升级风险高

企业面临的多重挑战

|挑战维度

|具体问题

|业务影响

|1

|

技术瓶颈 |单 TCP 连接限制，无法使用 nconnect

|性能无法达到业务要求

|2

|

升级成本 |重新认证、测试、部署周期长

|项目延期 6-18 个月

|3

|

合规风险 |FDA、GxP 等监管要求

|变更审批复杂、成本高昂

|4

|

业务紧迫 |AI/ML、HPC 等工作负载增长

|竞争力下降、机会成本

这种场景下，客户陷入两难：升级内核风险高、周期长，但不升级又无法满足性能要求。

传统解决方案的局限性

面对这些挑战，企业通常考虑的传统解决方案包括：

方案一：强制升级内核到 5.3+

优点：可使用 nconnect 参数，提升 NFS 性能 缺点：需要重新认证、测试、部署，周期 6-18 个月 风险：业务中断、合规风险、成本高昂

方案二：在客户端增加多个 Mount 点

优点：可以实现多路并行访问，提升总吞吐 缺点：需要应用改造，手动管理数据分布和负载均衡 限制：应用复杂度增加，维护成本高，容错性差

方案三：应用层并行优化

优点：通过多线程/多进程实现并行 I/O 缺点：需要重写应用逻辑，开发成本高，测试复杂 风险：应用稳定性风险，单个 mount 点瓶颈依然存在 结论：传统方案都存在显著的局限性，企业迫切需要一个 零风险、高效率、低成本的解决方案。

突破性解决方案：pNFS + Multi-HA Pairs 架构

FSx for NetApp ONTAP Gen1 vs Gen2 核心差异

在深入了解解决方案之前，我们需要理解 FSx for NetApp ONTAP 两代架构的根本差异：

|对比维度

|Gen1 架构

|Gen2 架构

|关键优势

|1

|

架构模式 |Scale-Up（垂直扩展）

|Scale-Out（水平扩展）

|线性性能扩展

|2

|

HA Pairs 数量 |1 个 HA Pair

|1-12 个 HA Pairs

|12倍扩展能力

|3

|

最大吞吐 |4 GB/s

|72 GB/s

|18倍性能提升

|4

|

最大 IOPS |200,000

|2,400,000

|12倍IOPS提升

|5

|

pNFS 支持 |不支持

|原生支持

|多连接并行访问

|6

|

扩展方式 |增加单节点资源

|增加 HA Pairs

|更灵活的扩展

|7

|

适用场景 |通用工作负载

|高性能计算、AI/ML

|性能密集型应用

Gen2 架构的革命性突破： 突破单节点限制：从依赖单个高性能节点转向多节点协同工作 原生 pNFS 支持：客户端可同时与多个数据节点建立连接，实现真正的并行 I/O 线性性能扩展：每增加一个 HA Pair，性能近似线性提升 6 GB/s 企业级可用性：多个 HA Pairs 提供更高的可用性和容错能力

Amazon FSx for NetApp ONTAP

Gen2 架构提供了完美的解决方案，基于 pNFS + Multi-HA Pairs , 无需升级内核即可实现多连接并行访问。

FSx for NetApp ONTAP Gen1 单 HA Pair 架构

FSx for NetApp ONTAP Gen1 采用传统的

Scale-Up 架构，通过单个 HA Pair（高可用对）提供存储服务。在这种架构中，性能提升主要依赖于单个节点的硬件配置升级，如增加 CPU、内存或网络带宽。 限制：

• 单个 HA Pair，数据路径单一
• 客户端只能通过一个节点访问数据
• 在旧内核下，单 TCP 连接成为性能瓶颈

FSx for NetApp ONTAP Gen2 Multi HA Pairs 架构

FSx for NetApp ONTAP Gen2 引入了革命性的

Scale-Out 架构。Gen2 Single-AZ 文件系统支持最多 12 个 HA Pairs，可提供最大 72 GB/s 吞吐和 2,400,000 SSD IOPS（每个 HA Pair 提供 6 GB/s 吞吐和 200,000 SSD IOPS）。这种架构通过水平扩展多个 HA Pairs 来实现性能的线性提升。

Scale-Out 架构特点：

线性扩展：支持 1-12 个 HA Pairs，每个 HA Pair 提供 6 GB/s 吞吐和 200,000 IOPS 性能上限：最大可达 72 GB/s 吞吐和 2,400,000 IOPS pNFS 协议：客户端可同时与多个数据节点建立连接 动态扩展：可在线添加 HA Pairs，无需业务中断 单 AZ 部署：所有 HA Pairs 部署在同一可用区，最小化网络延迟 无需内核升级：pNFS 在 Linux 2.6.37+ 就已支持 关键问题：虽然 Gen2 架构提供了多个 HA Pairs，但并非所有 volume 类型都能利用这些 HA Pairs 的聚合性能。要充分发挥 Scale-Out 架构的优势，volume 的选择至关重要。

FlexVol vs FlexGroup：为什么需要 FlexGroup 才能利用多 HA Pairs 性能

在 Gen2 Multi-HA Pairs 架构下，volume 类型的选择直接决定能否充分利用多 HA Pairs 的性能。目前FSx for NetApp ONTAP支持两种不同的 volume 类型，分别为FlexVol 与 FlexGroup，其核心差异在于数据分布方式。

核心架构差异

FlexVol：

• 单个逻辑卷，只能存储在

单个 HA Pair 的 aggregate上 性能瓶颈：即使文件系统有 12 个 HA Pairs，FlexVol 也只能使用单个 HA Pair 的性能（最大 6 GB/s，200K IOPS） FlexGroup：

• 由多个

constituent volumes组成，每个 constituent 本质是一个 FlexVol 性能聚合：constituents 分布在所有 HA Pairs 的 aggregates 上，实现性能线性扩展 默认配置：每个 HA Pair 分配 8 个 constituents

FlexGroup 如何实现性能聚合

根据 AWS 官方文档，FlexGroup 通过以下机制实现多 HA Pairs 性能聚合：

跨 Aggregate** **分布

• 每个 HA Pair 有一个独立的 aggregate
• FlexGroup 的 constituents 均匀分布在所有 aggregates 上
• 示例：3 HA Pairs = 3 aggregates = 24 constituents (8 per aggregate)

pNFS** **并行访问

• 客户端通过 pNFS 协议同时访问多个 constituents
• 每个 constituent 的 I/O 由其所在 HA Pair 独立处理
• 实现真正的并行数据路径，无单点瓶颈

性能线性扩展

• 1 HA Pair：6 GB/s，200K IOPS
• 3 HA Pairs：18 GB/s，600K IOPS
• 12 HA Pairs：72 GB/s，4M IOPS

文件级负载均衡

• ONTAP 在文件级别自动分布数据到各个 constituents
• 多文件并发访问时自动实现负载均衡

关键对比

|对比项

|FlexVol

|FlexGroup

|1

|

Aggregate 使用 |单个 aggregate

|跨所有 aggregates

|2

|

HA Pairs 利用 |仅单个 HA Pair

|所有 HA Pairs

|3

|

性能上限 |6 GB/s, 200K IOPS

|72 GB/s, 2.4M IOPS

|4

|

Console 创建 |多 HA Pairs 需 CLI/API

|默认选项

*重要：在 AWS Console * *中，多 HA Pairs * *文件系统只能创建 FlexGroup volumes* *。要创建 FlexVol* *，需使用 AWS CLI* *、API * *或 NetApp * *管理工具，但无法利用多 HA Pairs * *性能。* *结论：多 HA Pairs * *环境下，必须使用 FlexGroup * *才能通过 pNFS * *充分利用所有 HA Pairs * *的聚合性能。*

pNFS 工作原理

pNFS (Parallel NFS) 是

NFSv4 协议的原生组成部分，在 RFC 5661 中定义，旨在解决传统 NFS 的性能瓶颈。FSx for NetApp ONTAP 利用 pNFS 协议实现高性能并行访问。 SVM NFS 端点访问：客户端通过 [SVM 的 NFS 端点] 连接文件系统 NFS v4.1 协议支持：利用1 协议的 pNFS 功能实现并行访问 Scale-Out 架构利用：充分利用 Gen2 的多 HA Pairs 架构实现性能扩展 并行性能提升：通过 pNFS 协议实现多路并行 I/O，突破单连接限制 关键优势： 协议原生支持：pNFS 是1 的标准组成部分，无需额外软件 向下兼容：支持 Linux 2.6.37+ 内核，覆盖绝大多数企业环境 透明切换：应用无需修改，仅需调整挂载参数

测试验证

为了全面验证 pNFS + Multi-HA Pairs 架构在旧内核环境下的性能优势，我们设计了三组对比测试：

基线组：使用 Gen1 架构 + RHEL 7.9 (Kernel 3.10) + NFSv4.1，作为基础方案的性能基线 对比组：使用 Gen1 架构 + RHEL 7.9 (Kernel 5.14.0) + NFSv4.1 + nconnect=16，展示内核升级后的性能提升 测试组：使用 Gen2 架构 + RHEL 7.9 (Kernel 3.10) + NFSv4.1 + pNFS，验证在旧内核下的性能突破

通过这三组测试，我们可以清晰地看到在相同的旧内核环境下，pNFS 方案相比传统 NFS 的性能优势，以及与 nconnect 方案的性能对比。

测试环境

客户端配置

|组件

|配置

|说明

|1

|

EC2 实例 |i3en.6xlarge

|24 vCPU, 192 GB RAM, 25 Gbps 网络

|2

|

操作系统 |RHEL 7.9

|模拟真实企业环境

|3

|

部署区域 |us-east-1

|与 FSx for NetApp ONTAP 文件系统同区域

文件系统配置

|测试组

|FSx 文件系统 ID

|SSD 容量

|架构

|吞吐配置

|IOPS

|HA Pairs

|1

|

基线组 |fs-0701af355a95a70c5

|4098GB

|Gen1

|4096 MB/s

|20000

|1

|2

|

对比组 |fs-0701af355a95a70c5

|4098GB

|Gen1

|4096 MB/s

|20000

|1

|3

|

测试组 |fs-09e246d33a1cd3cd5

|4098GB

|Gen2

|4608 MB/s

|20000

|3

对照组设置

|测试组

|Linux内核

|FSx 文件系统ID

|协议

|nconnect

|挂载命令

|1

|

基线组 |3.10.0

|fs-0701af355a95a70c5

|NFSv4.1

|1

|mount -t nfs -o vers=4.1,proto=tcp,rsize=[已去除电话],wsize=[已去除电话],hard,intr,timeo=600,retrans=2

|2

|

对比组 |5.14.0

|fs-0701af355a95a70c5

|NFSv4.1

|16

|mount -t nfs -o vers=4.1,proto=tcp,rsize=[已去除电话],wsize=[已去除电话],hard,intr,timeo=600,retrans=2,

nconnect=16

|3

|

测试组 |3.10.0

|fs-09e246d33a1cd3cd5

|NFSv4.1

|1

|mount -t nfs -o vers=4.1,proto=tcp,rsize=[已去除电话],wsize=[已去除电话],hard,intr,timeo=600,retrans=2

测试工具

本次测试，我们使用 SAS ** **官方推荐的 RHEL IOTest ** **脚本 (rhel-iotest.sh) ** **进行文件存储性能评估,** **该工具基于 fio ** **引擎开发，专门针对 SAS ** **应用的 I/O ** **特性进行了优化，并在 SAS ** **技术支持知识库中有详细的使用指导：

Tool to test I/O throughput for RHEL systems (the rhel_iotest.sh script)

*选择该工具的原因：为了验证在 SAS * *应用部署场景下的真实性能表现，该工具专门为 RHEL * *系统上的 SAS * *应用设计，能够准确模拟 SAS * *工作负载的 I/O * *模式，确保测试结果对 SAS * *用户具有直接的参考价值。*

测试前置：FSx 文件系统传输优化

为了确保所有测试组的公平性，需要对所有 FSx 文件系统进行相同的传输大小优化：

*说明：将所有文件系统的 TCP/UDP * *最大传输大小设置为 1MB* *，与客户端挂载参数 rsize=[已去除电话] * *和 wsize=[已去除电话] * *保持一致，确保所有测试组在相同的优化条件下进行比较。*

基线组：Gen1 架构 + RHEL 7.9 (Kernel 3.10)

验证内核版本

内核版本确认：10.0，RHEL 7.9默认内核 nconnect 支持：不支持（需要Linux 5.3+） 合规状态：经过认证的稳定版本，无变更风险

挂载文件系统

关键参数说明：

– vers=4.1：使用 NFSv4.1 协议

–

无 nconnect 参数：旧内核不支持，仅使用单 TCP 连接

– rsize=[已去除电话],wsize=[已去除电话]：1MB 读写缓冲区

– hard,proto=tcp：可靠传输配置

执行 RHEL IOTest 性能测试

关键信息确认： 协议一致性：使用1 测试规模：12 次迭代，每次19 GB 单核读性能：22 MB/s per core 单核写性能：80 MB/s per core 实际聚合性能：根据 CloudWatch 监控，峰值吞吐达 600MB/s *在测试中发现了单 TCP * *连接的性能瓶颈根源：在 CloudWatch * *监控中，单客户端吞吐始终在 600 MB/s * *左右触顶。这个现象的根本原因是 AWS * *网络架构的设计限制（参考 * *Amazon EC2* *实例网络带宽* *）：对于单流（5-tuple* *）流量，当实例不在同一集群放置组中时，单一TCP* *连接带宽被限制为 5 Gbps* *，考虑到 TCP * *协议开销和其他网络开销，实际可用带宽约为 500-600 MB/s* *，这与我们的 CloudWatch * *监控数据完全一致。这个限制导致了严重的资源浪费：i3en.6xlarge * *实例的 25 Gbps * *网络带宽利用率仅为 19%* *，同时 CPU * *空闲率高，无法通过增加核数来提升性能。*

对比组：Gen1 架构 + RHEL 7.9 (Kernel 5.14.0) + nconnect=16

升级内核至支持 nconnect 的版本

内核升级过程 企业级部署注意事项： 测试验证：在非生产环境充分测试应用兼容性 回滚准备：保留原内核作为备用启动选项 变更管理：遵循企业变更审批流程 业务中断：计划维护窗口，最小化业务影响 合规要求：某些行业需重新进行系统认证 为什么选择 ELRepo（参考 ELRepo 项目介绍）： 社区驱动：开源社区维护，跟进上游内核更新 企业友好：专为 RHEL/CentOS 设计，保持兼容性 长期支持：提供稳定的内核更新路径 验证内核版本 关键确认：

• 内核版本：4.226，支持 nconnect 参数
• 架构：x86_64，与生产环境一致
• 编译时间：2022年12月，相对稳定的内核版本，经过社区验证的稳定版本

使用 nconnect 参数挂载文件系统

执行 nconnect ** **挂载

执行 RHEL IOTest 性能测试

运行rhel_iotest测试（

rhel_iotest.sh：I/O 性能测试工具命令行，

-t /mnt/netapp/test200：指定测试目标挂载点），并等待结果输出：

关键信息确认： nconnect 验证：挂载参数中明确显示 nconnect=16 协议一致性：使用1 测试规模：12 次迭代，每次63 GB 单核读性能：12 MB/s per core 单核写性能：20 MB/s per core 实际聚合性能：根据 CloudWatch 监控，峰值吞吐达 3.0 GB/s

测试组：Gen2 架构(3 HA pairs) + pNFS+ RHEL 7.9 (Kernel 3.10)

创建Gen2/Single-AZ FSxN文件系统

登录 AWS 管理控制台并导航到 Amazon FSx 服务，选择目标区域（本测试中为 us-east-1），点击“创建文件系统” 并 选择“Amazon FSx for NetApp ONTAP” 配置文件系统设置如下 *注意：必须选择 Single-AZ * *部署类型，因为目前 Multi-AZ * *不支持多个 HA Pairs * *的文件系统配置。*

如下是创建完之后文件系统的设置 Gen2 Single-AZ File system (3 pairs):

启用FSxN文件系统的pNFS 设置

连接到 ONTAP CLI** **启用1** **和 pNFS** **功能** *说明：该命令同时启用了 NFSv4.1 * *协议和 pNFS * *功能，pNFS * *是实现多 HA Pairs * *并行访问的关键技术。* **验证 pNFS ** **配置** *说明：确认两个关键功能都显示为 “enabled” * *状态，表示 pNFS * *功能已正确启用。* **运行rhel_iotest** **测试

执行 pNFS 挂载命令

关键参数说明：

vers=4.1：指定使用1 协议，这是 pNFS 功能的前提条件

proto=tcp：使用 TCP 协议，确保可靠的数据传输

rsize=[已去除电话],wsize=[已去除电话]：设置读写缓冲区为 1MB，与服务端配置匹配

hard,intr：硬挂载模式，确保 I/O 操作的可靠性

timeo=600,retrans=2：超时和重试参数，适合高延迟网络环境

运行rhel_iotest测试（

rhel_iotest.sh：I/O 性能测试工具命令行，

-t /mnt/pnfs：指定测试目标为 pNFS 挂载点），并等待结果输出：

性能结果分析： 单核读性能：34 MB/s per core 单核写性能：87 MB/s per core 测试时长：48 分钟 40 秒 (08:41:22 – 09:30:02)

这一点也可以从

实际聚合性能：根据 CloudWatch 监控，峰值吞吐约 2.52 GB/s

测试小结

基于 SAS 官方推荐的 RHEL IOTest 工具，我们对三种不同架构进行了全面的性能测试。以下是完整的测试结果对比：

|测试组

|架构方案

|内核版本

|协议配置

|单核读性能

|单核写性能

|CloudWatch峰值

|1

|

基线组 |Gen1 单HA

|3.10.0

|NFSv4.1 (单连接)

|49.22 MB/s

|48.80 MB/s

|625 MB/s

|2

|

对比组 |Gen1 + nconnect

|5.4.226

|NFSv4.1 + nconnect=16

|182.12 MB/s

|81.20 MB/s

|3.0 GB/s

|3

|

测试组 |Gen2 pNFS

|3.10.0

|NFSv4.1 + pNFS

|147.34 MB/s

|126.87 MB/s

|2.5 GB/s

性能表现： nconnect 方案在纯性能上表现最优，峰值吞吐达到0 GB/s，但需要内核升级 pNFS 方案性能优异且均衡，峰值吞吐5 GB/s，写性能表现更佳 基线方案受AWS网络架构限制，单连接峰值仅625 MB/s 企业部署建议： 新项目部署：直接选择Gen2 pNFS，避免内核升级复杂性 现有环境升级：评估内核升级成本vs Gen2迁移成本 合规敏感行业：Gen2 pNFS是唯一零风险高性能方案 性能优先场景：如可承受内核升级风险，nconnect提供最高性能

总结

FSx for NetApp ONTAP Gen2 的

pNFS + Multi-HA Pairs 架构完美解决了企业在旧内核环境下的性能瓶颈：

✅

无需内核升级：pNFS 在 Linux 2.6.37+ 就已支持，兼容绝大多数企业生产环境

✅

性能提升显著：单客户端吞吐提升 5-6 倍（基于HA pair实现吞吐量线性增长）

✅

架构优势明显：多 HA Pairs 提供更好的扩展性和可用性

✅

应用透明：无需修改应用代码，仅需调整挂载参数

✅

成本效益优化：单位性能成本更低，加速业务交付

对于运行在旧内核环境、需要高性能存储的企业客户，这是一个

生产就绪、经过验证**的解决方案。 ***前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。