告别 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 持续吞吐
• 现实困境：应用栈复杂，内核升级风险高

企业面临的多重挑战

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

传统解决方案的局限性

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

方案一：强制升级内核到 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 两代架构的根本差异：

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 性能聚合：

1. 跨 Aggregate 分布

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

2. pNFS 并行访问

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

3. 性能线性扩展

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

4. 文件级负载均衡

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

关键对比

重要：在 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 协议实现高性能并行访问。

1. SVM NFS 端点访问：客户端通过 [SVM 的 NFS 端点] 连接文件系统
2. NFS v4.1 协议支持：利用1 协议的 pNFS 功能实现并行访问
3. Scale-Out 架构利用：充分利用 Gen2 的多 HA Pairs 架构实现性能扩展
4. 并行性能提升：通过 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 方案的性能对比。

测试环境

客户端配置

文件系统配置

对照组设置

测试工具

本次测试，我们使用 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 文件系统进行相同的传输大小优化：

# 对 Gen1 文件系统 (fs-0701af355a95a70c5) 进行优化
ssh fsxadmin@management.fs-0701af355a95a70c5.fsx.us-east-1.amazonaws.com
FsxId0701af355a95a70c5::> vserver nfs modify -vserver svm1 -tcp-max-xfer-size 1048576
FsxId0701af355a95a70c5::> vserver nfs modify -vserver svm1 -udp-max-xfer-size 1048576
# 对 Gen2 文件系统 (fs-09e246d33a1cd3cd5) 进行优化
ssh fsxadmin@management.fs-09e246d33a1cd3cd5.fsx.us-east-1.amazonaws.com
FsxId09e246d33a1cd3cd5::> vserver nfs modify -vserver svm1 -tcp-max-xfer-size 1048576
FsxId09e246d33a1cd3cd5::> vserver nfs modify -vserver svm1 -udp-max-xfer-size 1048576

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

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

验证内核版本

[ec2-user@sascomp-d ~]$ uname -a
Linux sascomp-d 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue May 14 11:55:25 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux

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

挂载文件系统

[ec2-user@sascomp-d ~]#sudo mount -t nfs4 \
-o vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2 \
svm-049fe4b5763eb828f.fs-0701af355a95a70c5.fsx.us-east-1.amazonaws.com:/vol0 /mnt/netapp/test200

关键参数说明：
– vers=4.1：使用 NFSv4.1 协议
– 无 nconnect 参数：旧内核不支持，仅使用单 TCP 连接
– rsize=1048576,wsize=1048576：1MB 读写缓冲区
– hard,proto=tcp：可靠传输配置

执行 RHEL IOTest 性能测试

[root@sascomp-d toolset]# ./rhel_iotest.sh -t /mnt/netapp/test200
RESULTS
-------
INVOCATION:  rhel_iotest.sh -t /mnt/netapp/test200
TARGET DETAILS
  target dir:   /mnt/netapp/test200
  df -kT:       svm-049fe4b5763eb828f.fs-0701af355a95a70c5.fsx.us-east-1.amazonaws.com:/vol1 5100273664 759240320 4341033344  15% /mnt/netapp/test200
  mount point:  svm-049fe4b5763eb828f.fs-0701af355a95a70c5.fsx.us-east-1.amazonaws.com:/vol1 on /mnt/netapp/test200 type nfs4 (rw,noatime,nodiratime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,acregmin=120,acregmax=120,acdirmin=120,acdirmax=120,hard,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.102.60,local_lock=none,addr=192.168.255.201)
  iterations:   12
  filesize:     186.19 gigabytes
 
STATISTICS
  read throughput rate:   49.22 megabytes/second per physical core
  write throughput rate:  48.80 megabytes/second per physical core

关键信息确认：

• 协议一致性：使用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 的版本

内核升级过程

# 1. 安装 ELRepo 仓库（参考：https://elrepo.org/tiki/tiki-index.php）
sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
sudo yum install -y https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
# 2. 查看可用内核版本（参考：https://elrepo.org/tiki/kernel-ml）
sudo yum --disablerepo="*" --enablerepo="elrepo-kernel" list available
# 3. 安装主线内核（ML - MainLine）
sudo yum --enablerepo=elrepo-kernel install -y kernel-ml kernel-ml-devel
# 4. 设置默认启动内核（参考：RHEL 官方文档）
sudo grub2-set-default 0
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
# 5. 重启系统
sudo reboot

企业级部署注意事项：

• 测试验证：在非生产环境充分测试应用兼容性
• 回滚准备：保留原内核作为备用启动选项
• 变更管理：遵循企业变更审批流程
• 业务中断：计划维护窗口，最小化业务影响
• 合规要求：某些行业需重新进行系统认证

为什么选择 ELRepo（参考 ELRepo 项目介绍）：

• 社区驱动：开源社区维护，跟进上游内核更新
• 企业友好：专为 RHEL/CentOS 设计，保持兼容性
• 长期支持：提供稳定的内核更新路径

验证内核版本

[ec2-user@sascomp-d ~]$ uname -a
Linux sascomp-d 5.4.226-1.el7.elrepo.x86_64 #1 SMP Tue Dec 6 16:05:31 EST 2022 x86_64 x86_64 x86_64 GNU/Linux

关键确认：

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

使用 nconnect 参数挂载文件系统

执行 nconnect 挂载

[root@sascomp-d sas_io_test]#sudo mount -t nfs4 \
-o vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,nconnect=16,timeo=600,retrans=2 \
svm-049fe4b5763eb828f.fs-0701af355a95a70c5.fsx.us-east-1.amazonaws.com:/vol0 /mnt/netapp/test200

执行 RHEL IOTest 性能测试

运行rhel_iotest测试（rhel_iotest.sh：I/O 性能测试工具命令行， -t /mnt/netapp/test200：指定测试目标挂载点），并等待结果输出：

[root@sascomp-d sas_io_test]# ./rhel_iotest.sh -t /mnt/netapp/test200
RESULTS
INVOCATION:  rhel_iotest.sh -t /mnt/netapp/test200
TARGET DETAILS
  target dir:   /mnt/netapp/test200
  df -kT:       svm-049fe4b5763eb828f.fs-0701af355a95a70c5.fsx.us-east-1.amazonaws.com:/vol0 5100273664 938950656 4161323008  19% /mnt/netapp/test200
  mount point:  svm-049fe4b5763eb828f.fs-0701af355a95a70c5.fsx.us-east-1.amazonaws.com:/vol0 on /mnt/netapp/test200 type nfs4 (rw,noatime,nodiratime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,acregmin=120,acregmax=120,acdirmin=120,acdirmax=120,hard,noresvport,proto=tcp,nconnect=16,timeo=600,retrans=2,sec=sys,clientaddr=192.168.12.189,local_lock=none,addr=192.168.255.244)
  iterations:   12
  filesize:     186.63 gigabytes
STATISTICS
  read throughput rate:   182.12 megabytes/second per physical core
  write throughput rate:  81.20 megabytes/second per physical core

关键信息确认：

• 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”

配置文件系统设置如下

文件系统名称: fsx_3pairs
部署类型: Single-AZ 2
预配置吞吐: 4608 MBps
HA 对数量: 3
VPC: 选择目标 VPC
子网: 选择与 EC2 实例相同的子网
安全组: 确保允许 NFS 流量（端口 2049）

注意：必须选择 Single-AZ 部署类型，因为目前 Multi-AZ 不支持多个 HA Pairs 的文件系统配置。

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

启用FSxN文件系统的pNFS 设置

1. 连接到 ONTAP CLI

# 通过 SSH 连接到 FSx 管理端点
ssh fsxadmin@management.fs-09e246d33a1cd3cd5.fsx.us-east-1.amazonaws.com

2. 启用1 和 pNFS 功能

# 启用 NFSv4.1 协议和 pNFS 功能
FsxId09e246d33a1cd3cd5::> vserver nfs modify -vserver svm1 -v4.1 enabled -v4.1-pnfs enabled

说明：该命令同时启用了 NFSv4.1 协议和 pNFS 功能，pNFS 是实现多 HA Pairs 并行访问的关键技术。

验证 pNFS 配置

# 检查 NFSv4.1 和 pNFS 是否正确启用
FsxId09e246d33a1cd3cd5::> vserver nfs show -vserver svm1 -fields v4.1,v4.1-pnfs
vserver v4.1    v4.1-pnfs
------- ------- ---------
svm1    enabled enabled

说明：确认两个关键功能都显示为 “enabled” 状态，表示 pNFS 功能已正确启用。

3. 运行rhel_iotest 测试

执行 pNFS 挂载命令

[ec2-user@uw2c-sascomp-d ~]$ sudo mount -t nfs \
-o vers=4.1,proto=tcp,rsize=1048576,wsize=1048576,hard,intr,timeo=600,retrans=2 \
svm-08104a9feb2f38dd5.fs-09e246d33a1cd3cd5.fsx.us-east-1.amazonaws.com:/vol1 /mnt/pnfs

关键参数说明：

• vers=4.1：指定使用1 协议，这是 pNFS 功能的前提条件
• proto=tcp：使用 TCP 协议，确保可靠的数据传输
• rsize=1048576,wsize=1048576：设置读写缓冲区为 1MB，与服务端配置匹配
• hard,intr：硬挂载模式，确保 I/O 操作的可靠性
• timeo=600,retrans=2：超时和重试参数，适合高延迟网络环境

运行rhel_iotest测试（rhel_iotest.sh：I/O 性能测试工具命令行， -t /mnt/pnfs：指定测试目标为 pNFS 挂载点），并等待结果输出：

[ec2-user@sascomp-d ~]# ./rhel_iotest.sh -t /mnt/pnfs
 
INVOCATION: rhel_iotest.sh -t /mnt/pnfs
 
TARGET DETAILS
 target dir: /mnt/pnfs
 df -kT:  svm-08104a9feb2f38dd5.fs-09e246d33a1cd3cd5.fsx.us-east-1.amazonaws.com:/vol1 5100274688 1495447552 3604827136 30% /mnt/pnfs
 mount point:  svm-08104a9feb2f38dd5.fs-09e246d33a1cd3cd5.fsx.us-east-1.amazonaws.com:/vol1 on /mnt/pnfs type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.17.96,local_lock=none,addr=192.168.17.251)
 iterations: 12
 filesize: 186.65 gigabytes
 
STATISTICS
 read time: 1,297.18 seconds per physical core average
 read throughput rate: 147.34 megabytes/second per physical core
 write time: 1,506.45 seconds per physical core average
 write throughput rate: 126.87 megabytes/second per physical core

 
<<STATUS>> processing complete.
<<STATUS>> compressing files and cleaning up.
<<STATUS>> end time: Thu Aug 21 09:30:02 PDT 2025.
 
Start time: Thu Aug 21 08:41:22 PDT 2025.
End time: Thu Aug 21 09:30:02 PDT 2025.

性能结果分析：

• 单核读性能：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 工具，我们对三种不同架构进行了全面的性能测试。以下是完整的测试结果对比：

性能表现：

• 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 提供更好的扩展性和可用性

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

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

对于运行在旧内核环境、需要高性能存储的企业客户，这是一个生产就绪、经过验证的解决方案。

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

本篇作者