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/)。
本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 为 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)