View a markdown version of this page

管理吞吐能力 - FSx for ONTAP
何时修改吞吐能力如何处理并发请求

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

管理吞吐能力

FSx for ONTAP 会在您创建文件系统时配置吞吐能力。您可以随时修改文件系统的吞吐能力。请记住，文件系统需要通过特定配置来实现最大吞吐能力。例如，若要为第一代文件系统预置 4 GBps 的吞吐能力，文件系统至少需要配置 5,120 GiB 的 SSD 存储和 160,000 的 SSD IOPS。有关更多信息，请参阅 吞吐能力对性能的影响。

吞吐能力是决定负责托管文件系统的文件服务器在为文件数据提供服务时的速度的因素之一。更高的吞吐容量随之而来的是更高的网络级别、每秒磁盘读取 I/O操作数 (IOPS) 和文件服务器上的数据缓存容量。有关更多信息，请参阅 适用于 ONTAP 性能的 Amazon FS NetApp x。

当您修改文件系统的吞吐能力时，Amazon FSx 会关闭为文件系统提供支持的文件服务器。在此过程中，两 Single-AZ 者和 Multi-AZ 文件系统都会自动进行故障转移和故障恢复，这通常需要几分钟才能完成。故障转移和故障恢复过程对于 NFS（网络文件共享）、SMB（服务器消息块）、iSCSI（互联网小型计算机系统接口）和 NVMe/TCP （基于 TCP 的 M Non-Volatile emory Express）客户端是透明的，允许您的工作负载在没有中断或手动干预的情况下继续运行。您的文件系统可以使用新的吞吐能力量后，就会向您收取费用。

注意

故障转移透明度的实现方式因协议而异。对于 NFS 和 SMB 客户端，故障转移是透明的，因为客户端用于访问您的数据的端点 IP 地址保持不变。对于 iSCSI 和 NVMe/TCP 块存储协议，故障转移透明度取决于客户端多路径，您必须在客户端上安装和配置多路径，这样它才能自动在文件服务器之间进行故障切换。有关更多信息，请参阅为 Linux 配置 iSCSI和Linux NVMe/TCP 资源调配。

注意

为了确保维护活动期间的数据完整性，FSx for ONTAP 会在维护开始之前关闭所有机会性锁定，并完成对托管文件系统的底层存储卷的所有待处理写入操作。在文件系统的计划维护时段中，系统修改（例如对吞吐能力的修改）可能会出现延迟。系统维护会导致这些更改排队等待处理。有关更多信息，请参阅 使用 Amazon FSx 维护时段进行性能优化。

主题

何时修改吞吐能力

Amazon FSx 与亚马逊集成 CloudWatch，可帮助您监控文件系统的持续吞吐量使用水平。除了文件系统的吞吐能力外，您可以通过文件系统驱动的吞吐量和 IOPS 性能还取决于特定工作负载的特征。通常，您应预置足够的吞吐能力来支持工作负载的读取吞吐量以及两倍的工作负载写入吞吐量。您可以使用 CloudWatch 指标来确定要更改哪些维度以提高性能。有关更多信息，请参阅 在 Amazon FSx 控制台中进行监控。

如何处理并发请求

对于第一代文件系统，您可以在 SSD 存储容量和预调配 IOPS 更新工作流程开始之前或进行中请求吞吐能力更新。Amazon FSx 会按照如下顺序处理上述两项请求：

  • 如果您同时提交 SSD/IOPS 更新和吞吐量容量更新，则这两个请求都将被接受。在吞吐量容量 SSD/IOPS 更新之前，对更新进行优先级排序。

  • 如果您在更新过程中提交吞吐量容量 SSD/IOPS 更新，则吞吐量容量更新请求将被接受并排队等候 SSD/IOPS更新后执行。吞吐量容量更新在更新后 SSD/IOPS （有新值可用）和优化步骤期间开始。这通常会在 10 分钟内完成。

  • 如果您在吞吐量容量 SSD/IOPS 更新过程中提交更新，则 SSD/IOPS 存储更新请求将被接受并排队等候在吞吐量容量更新完成（新的吞吐容量可用）后开始。这通常需要 20 分钟。

请求更新第二代文件系统的吞吐能力时，应考虑以下几点：

  • 在更新第二代文件系统的吞吐能力之前，至少须等待六个小时。

  • 吞吐容量的冷却时间与 SSD/IOPS 扩展共享。

  • 吞吐量容量的 SSD/IOPS 扩展和扩展不能同时完成，也不能在两者进行时排队。

  • 在吞吐量容量扩展或扩展过程中，或在吞吐量容量扩展或 SSD/IOPS 扩展进行期间，您不能添加高可用性 (HA) 对。但是，添加 HA 对不会与 SSD/IOPS 扩展和吞吐量容量扩展共享冷却时间。有关更多信息，请参阅 添加高可用性（HA）对。

有关 SSD 存储和预调配 IOPS 更新的更多信息，请参阅管理存储容量。