Amazon FSx 文件网关不再向新客户开放。 FSx File Gateway 的现有客户可以继续正常使用该服务。有关与 FSx 文件网关类似的功能，请访问[此博客文章](https://aws.amazon.com/blogs/storage/switch-your-file-share-access-from-amazon-fsx-file-gateway-to-amazon-fsx-for-windows-file-server/)。
本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 性能和优化
本节介绍优化文件网关性能的指导和最佳实践。
**Topics**
+ [的基本性能指南](#performance-fgw)
+ [优化网关性能](#Optimizing-common)
+ [更大限度地提高 S3 文件网关吞吐量](Performance-Throughput.md)
+ [为 SQL Server 数据库备份优化 S3 文件网关](SQL-Backup-Best-Practices.md)
## 的基本性能指南
在本节中，您可以找到有关为 FSx 文件网关虚拟机配置硬件的指南。表中列出的实例配置是示例，仅供参考。
为获得最佳性能，必须将缓存磁盘大小调整为活动工作集的大小。使用多个本地磁盘进行缓存时，可以通过并行访问数据来提高写入性能，从而提高 IOPS。
**注意**
我们建议您不要使用短暂存储。有关使用短暂存储的更多信息，请参阅[将临时存储与 EC2 网关结合使用](ephemeral-disk-cache.md)。
连接到文件网关的文件系统中各个目录的建议大小限制为每个目录 1 万个文件。您可以将文件网关用于包含超过 1 万个文件的目录，但性能可能会受到影响。
在下表中，*缓存命中*读取操作从缓存提供的文件数据中读取。*缓存未*读操作是从 Amazon for Windows 文件服务器提供的文件数据中读 FSx 取的。
下表显示了 FSx 文件网关配置示例。
### FSx Windows 客户端上的文件网关性能
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/filegateway/latest/filefsxw/Performance.html)
**注意**
您的性能可能因主机平台配置和网络带宽而异。写入吞吐量性能会随着文件大小增大而降低，小文件（小于 32MiB）可实现的最高吞吐量为每秒 16 个文件。
## 优化网关性能
您可以在下面找到有关如何优化网关性能的信息。向网关添加资源以及向应用程序服务器添加资源是这些指导的基础。
### 在网关中添加资源
您可以使用以下一种或多种方法在网关中添加资源以优化网关性能。
**使用更高性能的磁盘**
要优化网关性能，您可以添加高性能磁盘，例如固态硬盘 (SSDs) 和控制器。 NVMe 您还可以直接从存储区域网络 (SAN) 而不是 Microsoft Hyper-V NTFS 将虚拟磁盘连接到 VM。磁盘性能的提高通常会带来更好的吞吐量和更多的每秒 input/output 操作次数 (IOPS)。有关添加磁盘的信息，请参阅[配置额外的缓存存储](ConfiguringLocalDiskStorage.md)。
要测量吞吐量，请将 `ReadBytes` 和 `WriteBytes` 指标与 `Samples` Amazon CloudWatch 统计数据结合使用。例如，5 分钟的采样周期内的 `Samples` 指标的 `ReadBytes` 统计数据除以 300 秒可以得出 IOPS。一般来说，查看网关的这些指标时，应注意低吞吐量和低 IOPS 趋势，以便显示与磁盘相关的瓶颈。
CloudWatch 并非所有网关都提供指标。有关网关指标的信息，请参阅[监控您的 文件网关](monitoring-file-gateway.md)。
**添加 CPU 资源到您的网关主机**
网关主机服务器的最低要求是四个虚拟服务器。要优化网关性能，请确认分配给网关 VM 的四个虚拟处理器由四个内核提供支持。此外，请确认您没有超额订阅主机 CPUs 服务器的。
CPUs 向网关主机服务器添加其他内容时，可以提高网关的处理能力。这样一来，您的网关就可以并行处理将应用程序中的数据存储到本地存储以及将这些数据上传到适用FSx 于 Windows 文件服务器的 文件服务器。其他 CPUs 功能还有助于确保您的网关在与其他主机共享主机时获得足够的 CPU 资源 VMs。提供足够的 CPU 资源通常能取得增加吞吐量的效果。
Storage Gateway 支持 CPUs 在网关主机服务器中使用 24。您可以使用 24 CPUs 来显著提高网关的性能。我们建议您对网关主机服务器使用以下网关配置：
+ 24 CPUs。
+ 16 GiB 预留 RAM 用于文件网关
+ 对于缓存大小不超过 16 TiB 的网关，预留 16 GiB 的 RAM
+ 对于缓存大小为 16 TiB 至 32 TiB 的网关，预留 32 GiB 的 RAM
+ 对于缓存大小为 32 TiB 至 64 TiB 的网关，预留 48 GiB 的 RAM
+ 磁盘 1 附加到半虚拟化控制器 1，将按如下方式用作网关缓存：
+ 使用 NVMe 控制器的固态硬盘。
+ 在虚拟机网络 1 上配置网络适配器 1：
+ 使用虚拟机网络 1 并添加 VMXnet3 (10 Gbps) 以用于摄取。
+ 在虚拟机网络 2 上配置网络适配器 2：
+ 使用虚拟机网络 2 并添加 VMXnet3 (10 Gbps) 以用于连接。 AWS
**使用独立物理磁盘支持网关虚拟磁盘**
在预置网关磁盘时，我们强烈建议您不要为使用相同底层物理存储磁盘的本地存储预置本地磁盘。例如，对于 VMware ESXi，底层物理存储资源表示为数据存储。部署网关 VM 时，您可选择用来存储 VM 文件的数据存储。在预置虚拟磁盘时（例如，作为上传缓冲区），您可以将虚拟磁盘存储在与 VM 相同的数据存储中，也可以将其存储在不同的数据存储中。
如果您有多个数据存储，则强烈建议为要创建的每个类型的本地存储选择一个数据存储。仅由一个底层物理磁盘支持的数据存储可能会导致性能下降。例如，在使用此类磁盘同时支持网关设置中的缓存存储和上传缓冲区时。同样，由性能不太高的 RAID 配置（如 RAID 1）支持的数据存储可能会导致性能下降。
### 向应用程序环境添加资源
**提高应用程序服务器和网关之间的带宽**
要优化网关性能，请确保应用程序和网关之间的网络带宽可满足您的应用程序需求。您可以使用网关的 `ReadBytes` 和 `WriteBytes` 指标来测量总数据吞吐量。
对于您的应用程序，请将测得的吞吐量与所需的吞吐量进行比较。如果测得吞吐量小于预期吞吐量，那么如果网络是瓶颈，提高应用程序和网关间的带宽可改善性能。同样地，您可以增加 VM 和本地磁盘之间的带宽 (如果它们不是直接连接的)。
**向应用程序环境添加 CPU 资源**
如果您的应用程序可以使用额外的 CPU 资源，那么添加更多 CPU 资源 CPUs 可以帮助您的应用程序扩展其 I/O 负载。
文件网关上的某些 FSx 文件操作（例如顶级文件夹重命名或权限更改）可能会导致多个文件操作，从而导致您 FSx 的 Windows 文件服务器文件系统 I/O 负载过高。如果您的文件系统没有足够的性能资源来处理您的工作负载，则文件系统可能会删除[卷影副本](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shadow-copies-fsxW.html)，因为它优先考虑持续的可用性 I/O 而不是历史卷影副本的保留。
在 Amazon FSx 控制台中，查看**监控和性能**页面，查看您的文件系统是否配置不足。如果是，您可以切换到 SSD 存储、增加吞吐能力或增加 SSD IOPS 来处理您的工作负载。
# 更大限度地提高 S3 文件网关吞吐量
以下各节说明了更大限度地提高 NFS 和 SMB 客户端、S3 文件网关和 Amazon S3 之间吞吐量的最佳实践。各节中提供的指导有助于逐步提高总体吞吐量。虽然这些建议都不是必需的，也不是相互依赖的，但它们是按照逻辑方式选择和排序的， 支持 用于测试和调整 S3 File Gateway 的实现。在实施和测试这些建议时，请记住，每个 S3 文件网关部署都是独特的，因此您的结果可能会有所不同。
S3 文件网关提供了一个文件接口，用于使用行业标准 NFS 或 SMB 文件协议存储和检索 Amazon S3 对象，文件和对象之间具有原生 1:1 映射。您可以将 S3 文件网关作为虚拟机部署在您 VMware的 Microsoft Hyper-V 或 Linux KVM 环境中，或者作为亚马逊 EC2 实例部署在 AWS 云中。S3 文件网关并不是设计用来完全替代企业级 NAS。S3 文件网关模拟文件系统，但它不是文件系统。使用 Amazon S3 作为持久后端存储会给每项 I/O 操作带来额外的开销，因此，与现有 NAS 或文件服务器相比，评估 S3 文件网关性能并不是等同的比较。
## 将网关部署在与客户端相同的位置
建议将 S3 文件网关虚拟设备部署在尽可能靠近 NFS 或 SMB 客户端的物理位置，从而尽可能缩短两者之间的网络延迟。在为网关选择位置时，请考虑以下事项：
+ 降低网关的网络延迟有助于提高 NFS 或 SMB 客户端的性能。
+ S3 文件网关设计为能够容忍网关与 Amazon S3 之间较高的网络延迟，但无法容忍网关与客户端之间的高延迟。
+ 对于部署在 Amazon EC2 中的 S3 文件网关实例，建议将网关和 NFS 或 SMB 客户端放在同一个置放群组中。有关更多信息，请参阅《Amazon Elastic Compute Cloud 用户指南》中的 [Amazon EC2 实例的置放群组](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)。
## 减少磁盘速度慢引起的瓶颈
我们建议您监控该`IoWaitPercent` CloudWatch 指标，以确定可能由于 S3 文件网关上存储磁盘缓慢而导致的性能瓶颈。尝试优化与磁盘相关的性能问题时，请考虑以下几点：
+ `IoWaitPercent` 报告 CPU 等待根磁盘或缓存磁盘返回响应所花费的时间占总时间的百分比。
+ 当 `IoWaitPercent` 大于 5-10% 时，这通常表示由于磁盘性能不佳而引起网关性能瓶颈。该指标应尽可能接近 0%（这意味着网关几乎从不需要等待磁盘响应），从而有助于优化 CPU 资源的使用。
+ 您可以`IoWaitPercent`在 Storage Gateway 控制台的 “**监控**” 选项卡上进行查看，或者将推荐的 CloudWatch 警报配置为在指标峰值超过特定阈值时自动通知您。有关更多信息，请参阅[为您的网关创建推荐的 CloudWatch 警报](https://docs.aws.amazon.com/filegateway/latest/files3/cloudwatch-alarms-create-recommended.html)。
+ 我们建议使用 NVMe 或 SSD 作为网关的根磁盘和缓存磁盘，以最大限度地减少网关的根磁盘和缓存磁盘`IoWaitPercent`。
## 调整 CPU、RAM 和缓存磁盘的虚拟机资源分配
尝试优化 S3 文件网关的吞吐量时，重要的是为网关 VM 分配足够的资源，包括 CPU、RAM 和缓存磁盘。4 CPUs、16GB RAM 和 150GB 缓存存储空间的最低虚拟资源要求通常仅适用于较小的工作负载。在为较大的工作负载分配虚拟资源时，建议执行以下操作：
+ 根据您的 S3 文件网关生成的典型 CPU 使用率，将分配的数量增加到 16 到 48 之间。 CPUs 您可以使用 `UserCpuPercent` 指标监控 CPU 使用率。有关更多信息，请参阅[了解网关指标](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics)。
+ 将分配的 RAM 增加到 32 GB 至 64 GB。
**注意**
S3 文件网关使用的 RAM 不能超过 64 GB。
+ 使用 NVMe 或 SSD 作为根磁盘和缓存磁盘，并调整缓存磁盘的大小，使其与计划写入网关的峰值工作数据集保持一致。有关更多信息，请参阅 [Amazon Web Services 官方 YouTube 频道上的 S3 文件网关缓存大小调整最佳实践](https://youtu.be/-ibL1eEcROI?si=dMAakj_dulZiG4Ln)。
+ 向网关添加至少 4 个虚拟缓存磁盘，而不是使用单个大磁盘。即使多个虚拟磁盘共享同一个底层物理磁盘，也可以提高性能，但是当虚拟磁盘位于不同的底层物理磁盘上时，性能提高通常会更大。
例如，如果要部署 12TB 的缓存，则可以使用以下配置之一：
+ 4 x 3 TB 缓存磁盘
+ 8 x 1.5 TB 缓存磁盘
+ 12 x 1 TB 缓存磁盘
通过这种方式，除了提高性能外，还可以随着时间的推移更有效地管理虚拟机。随着工作负载的变化，您可以逐步增加缓存磁盘的数量和总体缓存容量，同时让每个虚拟磁盘保持原始大小以确保网关的完整性。
有关更多信息，请参阅[确定本地磁盘存储量](https://docs.aws.amazon.com/filegateway/latest/files3/decide-local-disks-and-sizes.html)。
将 S3 文件网关部署为 Amazon EC2 实例时，请考虑以下事项：
+ 您选择的实例类型会显著影响网关性能。Amazon EC2 为调整 S3 文件网关实例的资源分配提供了广泛的灵活性。
+ 有关为 S3 文件网关推荐的 Amazon EC2 实例类型，请参阅[对 Amazon EC2 实例类型的要求](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#requirements-hardware-ec2)。
+ 您可以更改托管活动 S3 文件网关的 Amazon EC2 实例类型。这使您可以轻松调整 Amazon EC2 硬件生成和资源分配，以找到理想的 price-to-performance比率。要更改实例类型，请在 Amazon EC2 中执行以下步骤：
1. 停止 Amazon EC2 实例。
1. 更改 Amazon EC2 实例类型。
1. 启动 Amazon EC2 实例。
**注意**
停止托管 S3 文件网关的实例会暂时中断文件共享访问。如有必要，请务必提前安排维护时段。
+ Amazon EC2 实例的 price-to-performance比率是指以您支付的价格获得的计算能力。通常，新一代的 Amazon EC2 实例提供的 price-to-performance比率最高，与老一代实例相比，硬件更新，性能更高，成本相对较低。实例类型、区域和使用模式等因素也会影响该比率，因此，为特定工作负载选择合适的实例，对于实现成本效益的最优化非常重要。
## 调整 SMB 安全级别
该 SMBv3 协议允许 SMB 签名和 SMB 加密，这在性能和安全性方面有一些权衡。要优化吞吐量，您可以调整网关的 SMB 安全级别，指定在客户端连接时实施了哪些安全功能。有关更多信息，请参阅[为网关设置安全级别](https://docs.aws.amazon.com/filegateway/latest/files3/security-strategy.html)。
调整 SMB 安全级别时，需考虑以下事项：
+ S3 文件网关的默认安全级别为**强制加密**。此设置对与网关文件共享的 SMB 客户端连接强制执行加密和签名，这意味着从客户端到网关的所有流量都经过加密。此设置不影响从网关到的流量 AWS，该流量始终处于加密状态。
网关将每个加密的客户端连接限制为一个 vCPU。例如，如果您只有 1 个加密客户端，则即使为网关分配了 4 个或更多 v，该客户端CPUs 也只能使用 1 个 vCPU。因此，从单个客户端到 S3 文件网关的加密连接的吞吐量通常在 40-60 MB/s 之间会出现瓶颈。
+ 如果您的安全要求允许更宽松的情形，则可以将安全级别更改为**客户端协商**，这样会禁用 SMB 加密且仅实施 SMB 签名。使用此设置，客户端与网关的连接可以利用多个 vCPUs，这通常会提高吞吐量性能。
**注意**
更改 S3 文件网关的 SMB 安全级别后，必须在 Storage Gateway 控制台中等待文件共享状态从**正在更新**更改为**可用**，然后断开并重新连接 SMB 客户端，新设置才能生效。
## 使用多个线程和客户端来并行执行写入操作
通过一次仅使用一个 NFS 或 SMB 客户端来写入一个文件的 S3 文件网关很难实现最大吞吐量性能，因为从单个客户端按顺序写入是单线程操作。相反，建议从每个 NFS 或 SMB 客户端使用多个线程来并行写入多个文件，并同时使用多个 NFS 或 SMB 客户端写入到 S3 文件网关，从而更大限度地提高网关吞吐量。
使用多个线程可以显著提高性能。但是，使用更多线程需要更多系统资源，如果网关的大小不能满足增加的负载，这可能会对性能产生负面影响。在典型的部署中，随着添加更多线程和客户端，预期可以获得更好的吞吐量性能，直到达到网关的最大硬件和带宽限制。建议试用不同的线程数，以便针对您的特定硬件和网络配置，在速度和系统资源使用之间找到最佳平衡。
请参考以下关于常用工具的信息，这些工具可以帮助您测试线程和客户端配置：
+ 您可以使用诸如 robocopy 之类的工具将一组文件复制到网关上的文件共享，从而测试多线程写入性能。默认情况下，robocopy 在复制文件时使用 8 个线程，但您最多可以指定 128 个线程。
要在 robocopy 中使用多个线程，请在命令中添加 `/MT:n` 开关，其中 `n` 是要使用的线程数。例如：
`robocopy C:\source D:\destination /MT:64`
此命令将使用 64 个线程进行复制操作。
**注意**
在测试最大吞吐量时，我们不建议使用 Windows 资源管理器来拖放文件，因为此方法仅限于单个线程并会按顺序复制文件。
有关更多信息，请参阅 Microsoft Learn 网站上的 [robocopy](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy)。
+ 您也可以使用常见的存储基准测试工具（例如 DISKSPD 或 FIO）进行测试。这些工具提供了调整线程数、I/O 深度和其他参数的选项，可以满足您的特定工作负载要求。
DiskSpd 允许您使用`-t`参数控制线程数。例如：
`diskspd -c10G -d300 -r -w50 -t64 -o32 -b1M -h -L C:\testfile.dat`
此示例命令执行以下操作：
+ 创建一个 10 GB 的测试文件（`-c1G`）
+ 运行 300 秒（`-d300`）
+ 执行随机 I/O 测试，50% 读取 50% 写入 (`-r -w50`)
+ 使用 64 个线程（`-t64`）
+ 将每个线程的队列深度设置为 32（`-o32`）
+ 使用 1MB 的区块大小（`-b1M`）
+ 禁用硬件和软件缓存（`-h -L`）
有关更多信息，请参阅 Microsoft Learn 网站上的 [Use DISKSPD to test workload storage performance](https://learn.microsoft.com/en-us/azure/azure-local/manage/diskspd-overview?view=azloc-24113)。
+ FIO 使用 `numjobs` 参数来控制并行线程的数量。例如：
`fio --name=mixed_test --rw=randrw --rwmixread=70 --bs=1M -- iodepth=64 --size=10G --runtime=300 --numjobs=64 --ioengine=libaio --direct=1 --group_reporting`
此示例命令执行以下操作：
+ 执行随机 I/O 测试 (`--rw=randrw`)
+ 执行 70% 读取和 30% 写入（`--rwmixread=70`）
+ 使用 1MB 的区块大小（`--bs=1M`）
+ 将 I/O 深度设置为 64 (`--iodepth=64`)
+ 在 10 GB 文件上进行测试（`--size=10G`）
+ 运行 5 分钟（`--runtime=300`）
+ 创建 64 个并行作业（线程）（`--numjobs=64`）
+ 使用异步 I/O 引擎 (`--ioengine=libaio`)
+ 对结果进行分组以便于分析（`--group_reporting`）
有关更多信息，请参阅 [fio](https://linux.die.net/man/1/fio) Linux man 页面。
## 关闭自动缓存刷新
借助自动缓存刷新功能，您的 S3 文件网关可以自动刷新其元数据，从而有助于捕获用户或应用程序通过直接写入 Amazon S3 存储桶（而不是通过网关）对您的文件集所作的任何更改。有关更多信息，请参阅[刷新 Amazon S3 存储桶对象缓存](https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html)。
为了优化网关吞吐量，建议在对 Amazon S3 存储桶的所有读取和写入都通过 S3 文件网关来执行的部署中关闭此功能。
在配置自动缓存刷新时，请考虑以下事项：
+ 如果您因为部署中的用户或应用程序偶尔会直接写入 Amazon S3 而需要使用自动缓存刷新，那么建议在满足业务需求的前提下配置尽可能长的刷新时间间隔。较长的缓存刷新间隔有助于减少在浏览目录或修改文件时网关需要执行的元数据操作的数量。
例如：如果您的工作负载可以接受，将自动缓存刷新设置为 24 小时而不是 5 分钟。
+ 最短时间间隔为 5 分钟。最大间隔为 30 天。
+ 如果您选择设置非常短的缓存刷新间隔，建议您测试 NFS 和 SMB 客户端的目录浏览体验。刷新网关缓存所需的时间会大幅增加，具体取决于您的 Amazon S3 存储桶中文件和子目录的数量。
## 增加 Amazon S3 上传程序线程数
默认情况下，S3 文件网关为 Amazon S3 数据上传打开 8 个线程，这对大多数典型部署来说已经提供了足够的上传能力。但是，网关接收 NFS 和 SMB 客户端数据的速率可能高于以标准 8 线程能力上传到 Amazon S3 的速率，从而导致本地缓存达到其存储限制。
在特定情况下， 支持 可以将网关的 Amazon S3 上传线程池数量从 8 增加到 40，从而允许并行上传更多数据。根据您的部署特定的带宽和其他因素，这可以显著提高上传性能，并有助于减少支持您的工作负载所需的缓存存储。
我们建议使用该`CachePercentDirty` CloudWatch 指标来监控存储在本地网关缓存磁盘上但尚未上传到 Amazon S3 的数据量，并联系 支持 以帮助确定增加上传线程池数量是否会提高 S3 文件网关的吞吐量。有关更多信息，请参阅[了解网关指标](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics)。
**注意**
此设置会消耗额外的网关 CPU 资源。建议监控网关 CPU 使用率，并在必要时增加分配的 CPU 资源。
## 增大 SMB 超时设置
当 S3 文件网关将大文件复制到 SMB 文件共享时，SMB 客户端连接在长时间操作后可能会超时。
建议将 SMB 客户端的 SMB 会话超时设置延长到 20 分钟或更长时间，具体取决于文件大小和网关的写入速度。默认值为 300 秒，即 5 分钟。有关更多信息，请参阅[您的网关备份作业失败，或在对网关进行写入时出现错误](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails)。
## 为兼容的应用程序开启操作锁定
默认情况下，每个新的 S3 文件网关都会启用操作锁定（oplock）。在兼容的应用程序中使用操作锁定时，客户端会将多个较小的操作合并成更大的操作，这对客户端、网关和网络来说效率更高。如果您使用的是利用客户端本地缓存的应用程序（例如 Microsoft Office、Adobe Suite 等），建议开启操作锁定，这样可以显著提高性能。
如果您关闭操作锁定，则支持操作锁定的应用程序打开大文件（50 MB 或更大）的速度通常会慢得多。之所以出现这种延迟，是因为网关以 4 KB 的部分发送数据，这会导致吞吐量高 I/O 而低。
## 根据工作文件集的大小调整网关容量
网关容量参数指定网关在其本地缓存中可存储元数据的最大文件数量。默认情况下，网关容量设置为**小**，这意味着网关最多可存储 500 万个文件的元数据。因为在典型部署中，在任意时刻用户或应用通常只会访问一小部分文件，所以即使 Amazon S3 中有数亿甚至数十亿个对象，默认设置对大多数工作负载都能很好地运行。这组文件称为“工作集”。
如果您的工作负载经常访问大于 500 万个文件的工作集，则您的网关将需要频繁执行缓存移出操作，这些移出是存储在 RAM 中并保留在根磁盘上的小 I/O 操作。因为网关会从 Amazon S3 获取新数据，所以这样做会对网关性能产生负面影响。
您可以监控 `IndexEvictions` 指标以确定其元数据已从缓存中移出的文件数量，从而为新条目腾出空间。有关更多信息，请参阅[了解网关指标](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics)。
建议使用 `UpdateGatewayInformation` API 操作来增加网关容量，使其与典型工作集中的文件数量相对应。有关更多信息，请参阅 [UpdateGatewayInformation](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_UpdateGatewayInformation.html)。
**注意**
增加网关容量需要额外的 RAM 和根磁盘容量。
小（500 万个文件）容量至少需要 16 GB 的 RAM 和 80 GB 的根磁盘。
中（1000 万个文件）容量至少需要 32 GB 的 RAM 和 160 GB 的根磁盘。
大（2000 万个文件）容量需要 64 GB 的 RAM 和 240 GB 的根磁盘。
**重要**
网关容量无法减少。
## 为更大的工作负载部署多个网关
建议尽可能将工作负载分散到多个网关，而不是在单个大型网关上整合许多个文件共享。例如，您可以将一个使用非常频繁的文件共享单独部署在一个网关上，而将多个使用频率较低的文件共享集中部署在另一个网关上。
在规划具有多个网关和文件共享的部署时，请考虑以下几点：
+ 单个网关上文件共享的最大数量为 50，但是网关管理的文件共享数量会影响网关的性能。有关更多信息，请参阅[具有多个文件共享的网关的性能指导](https://docs.aws.amazon.com/filegateway/latest/files3/Performance.html#performance-multiple-file-shares)。
+ 每个 S3 文件网关上的资源由所有文件共享共同使用，不会进行划分。
+ 使用量大的单个文件共享会影响网关上其他文件共享的性能。
**注意**
我们不建议从多个网关创建映射到同一个 Amazon S3 位置的多个文件共享，除非其中至少有一个文件共享是只读的。
从多个网关同时向同一个文件执行写入操作属于多写入器场景，这可能会导致数据完整性问题。
# 为 SQL Server 数据库备份优化 S3 文件网关
数据库备份是 S3 文件网关的常见和推荐使用案例，该功能将数据库备份存储在 Amazon S3 中，从而提供经济实惠的短期和长期保留，并支持根据需要将备份自动转移到成本更低的存储层级。借助此解决方案，您可以使用 SQL Server Management Studio 和 Oracle RMAN 等内置工具减少对企业备份应用程序的需求。
以下各节介绍调优 S3 文件网关部署的最佳实践，以实现高性能，并经济高效地支持数百 TB 的 SQL 数据库备份。各节中提供的指导有助于逐步提高总体吞吐量。虽然这些建议都不是必需的，也不是相互依赖的，但它们是按照逻辑方式选择和排序的， 支持 用于测试和调整 S3 File Gateway 的实现。在实施和测试这些建议时，请记住，每个 S3 文件网关部署都是独特的，因此您的结果可能会有所不同。
S3 文件网关提供了一个文件接口，用于使用行业标准 NFS 或 SMB 文件协议存储和检索 Amazon S3 对象，文件和对象之间具有原生 1:1 映射。您可以将 S3 文件网关作为虚拟机部署在您 VMware的 Microsoft Hyper-V 或 Linux KVM 环境中，或者作为亚马逊 EC2 实例部署在 AWS 云中。S3 文件网关并不是设计用来完全替代企业级 NAS。S3 文件网关模拟文件系统，但它不是文件系统。使用 Amazon S3 作为持久后端存储会给每项 I/O 操作带来额外的开销，因此，与现有 NAS 或文件服务器相比，评估 S3 文件网关性能并不是等同的比较。
## 将网关部署在与 SQL Server 相同的位置
建议将 S3 文件网关虚拟设备部署在尽可能靠近 SQL Server 的物理位置，从而尽可能缩短两者之间的网络延迟。在为网关选择位置时，请考虑以下事项：
+ 降低网关的网络延迟有助于提高 SMB 客户端（例如，SQL Server）的性能。
+ S3 文件网关设计为能够容忍网关与 Amazon S3 之间较高的网络延迟，但无法容忍网关与客户端之间的高延迟。
+ 对于部署在 Amazon EC2 中的 S3 文件网关实例，建议将网关和 SQL Server 放在同一个置放群组中。有关更多信息，请参阅《Amazon Elastic Compute Cloud 用户指南》中的 [Amazon EC2 实例的置放群组](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)。
## 减少磁盘速度慢引起的瓶颈
我们建议您监控该`IoWaitPercent` CloudWatch 指标，以确定可能由于 S3 文件网关上存储磁盘缓慢而导致的性能瓶颈。尝试优化与磁盘相关的性能问题时，请考虑以下几点：
+ `IoWaitPercent` 报告 CPU 等待根磁盘或缓存磁盘返回响应所花费的时间占总时间的百分比。
+ 当 `IoWaitPercent` 大于 5-10% 时，这通常表示由于磁盘性能不佳而引起网关性能瓶颈。该指标应尽可能接近 0%（这意味着网关几乎从不需要等待磁盘响应），从而有助于优化 CPU 资源的使用。
+ 您可以`IoWaitPercent`在 Storage Gateway 控制台的 “**监控**” 选项卡上进行查看，或者将推荐的 CloudWatch 警报配置为在指标峰值超过特定阈值时自动通知您。有关更多信息，请参阅[为您的网关创建推荐的 CloudWatch 警报](https://docs.aws.amazon.com/filegateway/latest/files3/cloudwatch-alarms-create-recommended.html)。
+ 我们建议使用 NVMe 或 SSD 作为网关的根磁盘和缓存磁盘，以最大限度地减少网关的根磁盘和缓存磁盘`IoWaitPercent`。
## 调整 S3 文件网关虚拟机的 CPU、RAM 和缓存磁盘资源分配
尝试优化 S3 文件网关的吞吐量时，重要的是为网关 VM 分配足够的资源，包括 CPU、RAM 和缓存磁盘。4 CPUs、16GB RAM 和 150GB 缓存存储空间的最低虚拟资源要求通常仅适用于较小的工作负载。在为较大的工作负载分配虚拟资源时，建议执行以下操作：
+ 根据您的 S3 文件网关生成的典型 CPU 使用率，将分配的数量增加到 16 到 48 之间。 CPUs 您可以使用 `UserCpuPercent` 指标监控 CPU 使用率。有关更多信息，请参阅[了解网关指标](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics)。
+ 将分配的 RAM 增加到 32 GB 至 64 GB。
**注意**
S3 文件网关使用的 RAM 不能超过 64 GB。
+ 使用 NVMe 或 SSD 作为根磁盘和缓存磁盘，并调整缓存磁盘的大小，使其与计划写入网关的峰值工作数据集保持一致。有关更多信息，请参阅 [Amazon Web Services 官方 YouTube 频道上的 S3 文件网关缓存大小调整最佳实践](https://youtu.be/-ibL1eEcROI?si=dMAakj_dulZiG4Ln)。
+ 向网关添加至少 4 个虚拟缓存磁盘，而不是使用单个大磁盘。即使多个虚拟磁盘共享同一个底层物理磁盘，也可以提高性能，但是当虚拟磁盘位于不同的底层物理磁盘上时，性能提高通常会更大。
例如，如果要部署 12TB 的缓存，则可以使用以下配置之一：
+ 4 x 3 TB 缓存磁盘
+ 8 x 1.5 TB 缓存磁盘
+ 12 x 1 TB 缓存磁盘
通过这种方式，除了提高性能外，还可以随着时间的推移更有效地管理虚拟机。随着工作负载的变化，您可以逐步增加缓存磁盘的数量和总体缓存容量，同时让每个虚拟磁盘保持原始大小以确保网关的完整性。
有关更多信息，请参阅[确定本地磁盘存储量](https://docs.aws.amazon.com/filegateway/latest/files3/decide-local-disks-and-sizes.html)。
将 S3 文件网关部署为 Amazon EC2 实例时，请考虑以下事项：
+ 您选择的实例类型会显著影响网关性能。Amazon EC2 为调整 S3 文件网关实例的资源分配提供了广泛的灵活性。
+ 有关为 S3 文件网关推荐的 Amazon EC2 实例类型，请参阅[对 Amazon EC2 实例类型的要求](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#requirements-hardware-ec2)。
+ 您可以更改托管活动 S3 文件网关的 Amazon EC2 实例类型。这使您可以轻松调整 Amazon EC2 硬件生成和资源分配，以找到理想的 price-to-performance比率。要更改实例类型，请在 Amazon EC2 中执行以下步骤：
1. 停止 Amazon EC2 实例。
1. 更改 Amazon EC2 实例类型。
1. 启动 Amazon EC2 实例。
**注意**
停止托管 S3 文件网关的实例会暂时中断文件共享访问。如有必要，请务必提前安排维护时段。
+ Amazon EC2 实例的 price-to-performance比率是指以您支付的价格获得的计算能力。通常，新一代的 Amazon EC2 实例提供的 price-to-performance比率最高，与老一代实例相比，硬件更新，性能更高，成本相对较低。实例类型、区域和使用模式等因素也会影响该比率，因此，为特定工作负载选择合适的实例，对于实现成本效益的最优化非常重要。
## 通过调整 S3 文件网关的安全级别来提高 SMB 客户端吞吐量
该 SMBv3 协议允许 SMB 签名和 SMB 加密，这在性能和安全性方面有一些权衡。要优化吞吐量，您可以调整网关的 SMB 安全级别，指定在客户端连接时实施了哪些安全功能。有关更多信息，请参阅[为网关设置安全级别](https://docs.aws.amazon.com/filegateway/latest/files3/security-strategy.html)。
调整 SMB 安全级别时，需考虑以下事项：
+ S3 文件网关的默认安全级别为**强制加密**。此设置对与网关文件共享的 SMB 客户端连接强制执行加密和签名，这意味着从客户端到网关的所有流量都经过加密。此设置不影响从网关到的流量 AWS，该流量始终处于加密状态。
网关将每个加密的客户端连接限制为一个 vCPU。例如，如果您只有 1 个加密客户端，则即使为网关分配了 4 个或更多 v，该客户端CPUs 也只能使用 1 个 vCPU。因此，从单个客户端到 S3 文件网关的加密连接的吞吐量通常在 40-60 MB/s 之间会出现瓶颈。
+ 如果您的安全要求允许更宽松的情形，则可以将安全级别更改为**客户端协商**，这样会禁用 SMB 加密且仅实施 SMB 签名。使用此设置，客户端与网关的连接可以利用多个 vCPUs，这通常会提高吞吐量性能。
**注意**
更改 S3 文件网关的 SMB 安全级别后，必须在 Storage Gateway 控制台中等待文件共享状态从**正在更新**更改为**可用**，然后断开并重新连接 SMB 客户端，新设置才能生效。
## 通过将 SQL 备份拆分为多个文件来提高 SMB 客户端吞吐量
+ 通过一次仅使用一个 SQL Server 来写入一个文件的 S3 文件网关很难实现最大吞吐量性能，因为从单个 SQL Server 按顺序写入是单线程操作。相反，建议从每个 SQL Server 使用多个线程来并行写入多个文件，并同时使用多个 SQL Server 写入到 S3 文件网关，从而更大限度地提高网关吞吐量。对于 SQL 备份，将备份拆分为多个文件，让每个文件可以使用单独的线程，每个单独的线程可将多个文件同时写入 S3 文件网关文件共享。您拥有的线程越多，所能达到的吞吐量就越高，直到达到网关本身的性能上限。
+ SQL Server 支持在一次备份操作中同时写入多个文件。例如，您可以使用 T-SQL 命令或 SQL Server Management Studio（SSMS）指定多个文件目标。每个文件使用单独的线程将数据从 SQL Server 发送到网关文件共享。这种方法可以提高 I/O 吞吐量，从而显著提高备份速度和效率。
配置 SQL Server 备份时，需注意以下事项：
+ 通过将备份拆分为多个文件，SQL Server 管理员可以优化备份时间并更有效地管理大型数据库备份。
+ 使用的文件数量取决于服务器的存储配置和性能要求。对于大型数据库，建议将备份分成几个更小的文件，每个文件大小在 10 GB 到 20 GB 之间。
+ SQL Server 在执行备份时，对可以写入的文件数量没有硬性限制，但实际决策应基于存储架构和网络带宽等现实因素来考量。
有关更多信息，请参阅:
+ [通过写入多个文件，将 SQL Server 的备份速度提高了 43-67%](https://www.brentozar.com/archive/2020/08/back-up-sql-server-43-67-faster-by-writing-to-multiple-files/)
+ [使用文件网关轻松将 SQL Server 备份存储在 Amazon S3 中](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)
## 通过增大 SMB 超时设置来防止大文件复制失败
当 S3 文件网关将大型 SQL 备份文件复制到 SMB 文件共享时，SMB 客户端连接在长时间操作后可能会超时。建议将 SQL Server SMB 客户端的 SMB 会话超时设置延长到 20 分钟或更长时间，具体取决于文件大小和网关的写入速度。默认值为 300 秒，即 5 分钟。有关更多信息，请参阅[您的网关备份作业失败，或在对网关进行写入时出现错误](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails)。
## 增加 Amazon S3 上传程序线程数
默认情况下，S3 文件网关为 Amazon S3 数据上传打开 8 个线程，这对大多数典型部署来说已经提供了足够的上传能力。但是，网关接收 SQL Server 数据的速率可能高于以标准 8 线程能力上传到 Amazon S3 的速率，从而导致本地缓存达到其存储限制。
在特定情况下， 支持 可以将网关的 Amazon S3 上传线程池数量从 8 增加到 40，从而允许并行上传更多数据。根据您的部署特定的带宽和其他因素，这可以显著提高上传性能，并有助于减少支持您的工作负载所需的缓存存储。
我们建议使用该`CachePercentDirty` CloudWatch 指标来监控存储在本地网关缓存磁盘上但尚未上传到 Amazon S3 的数据量，并联系 支持 以帮助确定增加上传线程池数量是否会提高 S3 文件网关的吞吐量。有关更多信息，请参阅[了解网关指标](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics)。
**注意**
此设置会消耗额外的网关 CPU 资源。建议监控网关 CPU 使用率，并在必要时增加分配的 CPU 资源。
## 关闭自动缓存刷新
借助自动缓存刷新功能，您的 S3 文件网关可以自动刷新其元数据，从而有助于捕获用户或应用程序通过直接写入 Amazon S3 存储桶（而不是通过网关）对您的文件集所作的任何更改。有关更多信息，请参阅[刷新 Amazon S3 存储桶对象缓存](https://docs.aws.amazon.com/filegateway/latest/files3/refresh-cache.html)。
为了优化网关吞吐量，建议在对 Amazon S3 存储桶的所有读取和写入都通过 S3 文件网关来执行的部署中关闭此功能。
在配置自动缓存刷新时，请考虑以下事项：
+ 如果您因为部署中的用户或应用程序偶尔会直接写入 Amazon S3 而需要使用自动缓存刷新，那么建议在满足业务需求的前提下配置尽可能长的刷新时间间隔。较长的缓存刷新间隔有助于减少在浏览目录或修改文件时网关需要执行的元数据操作的数量。
例如：如果您的工作负载可以接受，将自动缓存刷新设置为 24 小时而不是 5 分钟。
+ 最短时间间隔为 5 分钟。最大间隔为 30 天。
+ 如果您选择设置非常短的缓存刷新间隔，建议您测试 SQL Server 的目录浏览体验。刷新网关缓存所需的时间会大幅增加，具体取决于您的 Amazon S3 存储桶中文件和子目录的数量。
## 部署多个网关以支持工作负载
通过将工作负载分配到多个网关，Storage Gateway 可以支持具有数百个 SQL 数据库、多个 SQL Server 和数百 TB 备份数据的大型环境的 SQL 备份。
在规划具有多个网关和 SQL Server 的部署时，请考虑以下几点：
+ 在有足够的硬件资源和带宽的情况下，单个网关通常每天最多可以上传 20 TB。您可以通过[增加 Amazon S3 上传程序线程数](https://docs.aws.amazon.com/filegateway/latest/files3/SQL-Backup-Best-Practices.html#SQL-Backup-Uploader-Threads)，将此限制提高到每天 40 TB。
+ 我们建议进行 proof-of-concept测试以衡量性能并考虑部署中的所有变量。确定 SQL 备份工作负载的峰值吞吐量后，您可以扩展网关数量以满足您的需求。
+ 因为数据库的数量和数据库的大小可能会随着时间的推移而增加，建议您在设计解决方案时考虑到增长。要继续扩展和支持不断增加的工作负载，您可以根据需要部署额外网关。
## 用于数据库备份工作负载的其他资源
+ [使用将 SQL Server 备份存储在 Amazon S3 中 AWS Storage Gateway](https://aws.amazon.com/blogs/database/storing-sql-server-backups-in-amazon-s3-using-aws-storage-gateway/)
+ [使用文件网关轻松将 SQL Server 备份存储在 Amazon S3 中](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)
+ [AWS Storage Gateway 用于在 Amazon S3 中存储 Oracle 数据库备份](https://aws.amazon.com/blogs/storage/using-aws-storage-gateway-to-store-oracle-database-backups-in-amazon-s3/)
+ [Backing up Oracle databases to Amazon S3 at scale](https://aws.amazon.com/blogs/storage/backing-up-oracle-databases-to-amazon-s3-at-scale/)
+ [使用将 SAP ASE 数据库集成到 Amazon S3 AWS Storage Gateway](https://aws.amazon.com/blogs/storage/integrate-an-sap-ase-database-to-amazon-s3-using-aws-storage-gateway/)
+ [一个 AWS 英雄如何使用云端 AWS Storage Gateway 备份](https://aws.amazon.com/blogs/storage/how-one-aws-hero-uses-aws-storage-gateway-for-in-cloud-backup/)
+ [S3 File Gateway cache sizing best practices](https://www.youtube.com/watch?v=-ibL1eEcROI)