Amazon FSx File Gateway 不再提供給新客戶。FSx File Gateway 的現有客戶可以繼續正常使用服務。如需類似 FSx File Gateway 的功能，請造訪[此部落格文章](https://aws.amazon.com/blogs/storage/switch-your-file-share-access-from-amazon-fsx-file-gateway-to-amazon-fsx-for-windows-file-server/)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 最大化 S3 檔案閘道輸送量
下列各節說明將 NFS 和 SMB 用戶端、S3 檔案閘道和 Amazon S3 之間的輸送量最大化的最佳實務。每個區段中提供的指引會逐步提升整體輸送量。雖然這些建議都不需要，而且不是相互依存的，但它們是以 支援 用來測試和調整 S3 File Gateway 實作的邏輯方式選取和排序。當您實作和測試這些建議時，請記住每個 S3 File Gateway 部署都是唯一的，因此您的結果可能會有所不同。
S3 File Gateway 提供檔案界面，使用業界標準的 NFS 或 SMB 檔案通訊協定來存放和擷取 Amazon S3 物件，並在檔案和物件之間進行原生的 1：1 映射。您可以將 S3 檔案閘道部署為 VMware、Microsoft Hyper-V 或 Linux KVM 環境中的內部部署虛擬機器，或將 AWS 雲端部署為 Amazon EC2 執行個體。S3 File Gateway 並非設計做為完整的企業 NAS 替換。S3 File Gateway 會模擬檔案系統，但不是檔案系統。使用 Amazon S3 作為耐用的後端儲存會為每個 I/O 操作產生額外的額外負荷，因此針對現有的 NAS 或檔案伺服器評估 S3 File Gateway 效能不是同等的比較。
## 在與用戶端相同的位置部署閘道
建議您將 S3 File Gateway 虛擬設備部署到實體位置，並在其與 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 資源。
+ 您可以檢查 Storage Gateway 主控台的`IoWaitPercent`**監控**索引標籤，或設定建議的 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 檔案閘道產生的典型 CPUs 使用量，將配置的 CPU 數量增加到 16 到 48 之間。您可以使用 `UserCpuPercent` 指標監控 CPU 用量。如需詳細資訊，請參閱[了解閘道指標](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#understanding-file-gateway-metrics)。
+ 將配置的 RAM 增加到 32 到 64 GB 之間。
**注意**
S3 檔案閘道無法使用超過 64 GB 的 RAM。
+ 針對根磁碟和快取磁碟使用 NVMe 或 SSD，並調整快取磁碟的大小，以符合您計劃寫入閘道的尖峰工作資料集。如需詳細資訊，請參閱官方 Amazon Web Services YouTube 頻道上的 [S3 File Gateway 快取大小調整最佳實務](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 File Gateway 執行個體資源配置的廣泛彈性。
+ 如需 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 File Gateway 的預設安全層級是**強制加密**。此設定會對閘道檔案共享的 SMB 用戶端連線強制執行加密和簽署，這表示從用戶端到閘道的所有流量都會加密。此設定不會影響從閘道到 的流量 AWS，其一律會加密。
閘道會將每個加密用戶端連線限制為單一 vCPU。例如，如果您只有 1 個加密用戶端，則該用戶端將限制為只有 1 個 vCPU，即使有 4 個以上的 vCPUs配置給閘道。因此，從單一用戶端到 S3 File Gateway 的加密連線輸送量通常會遇到 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 Explorer 在測試最大輸送量時拖放檔案，因為此方法僅限於單一執行緒並依序複製檔案。
如需詳細資訊，請參閱 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`
此範例命令會執行下列動作：
+ 建立 10GB 測試檔案 (`-c1G`)
+ 執行 300 秒 (`-d300`)
+ 使用 50% 讀取 50% 寫入執行隨機 I/O 測試 (`-r -w50`)
+ 使用 64 個執行緒 (`-t64`)
+ 將佇列深度設定為每個執行緒 32 個 (`-o32`)
+ 使用 1MB 區塊大小 (`-b1M`)
+ 停用硬體和軟體快取 (`-h -L`)
如需詳細資訊，請參閱 Microsoft Learn 網站上的[使用 DISKSPD 測試工作負載儲存效能](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 File Gateway 會為 Amazon S3 資料上傳開啟 8 個執行緒，這可為大多數典型部署提供足夠的上傳容量。不過，閘道可能會以高於標準 8 執行緒容量上傳至 Amazon S3 的速率從 NFS 和 SMB 用戶端接收資料，這可能會導致本機快取達到其儲存限制。
在特定情況下， 支援 可以將閘道的 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 File Gateway 將大型檔案複製到 SMB 檔案共享時，SMB 用戶端連線可能會在長時間後逾時。
我們建議您將 SMB 用戶端的 SMB 工作階段逾時設定延長至 20 分鐘或以上，具體取決於檔案大小和閘道的寫入速度。預設值為 300 秒或 5 分鐘。如需詳細資訊，請參閱[您的閘道備份任務失敗，或寫入閘道時發生錯誤](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#backup-job-fails)。
## 為相容應用程式開啟機會鎖定
預設會為每個新的 S3 檔案閘道啟用伺機鎖定或「oplocks」。搭配相容的應用程式使用 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 的根磁碟。
中型 (1，000 萬個檔案） 需要至少 32 GB 的 RAM 和 160 GB 的根磁碟。
大型 (2，000 萬個檔案） 需要 64 GB 的 RAM 和 240 GB 的根磁碟。
**重要**
無法減少閘道容量。
## 為更大的工作負載部署多個閘道
我們建議您盡可能將工作負載分割到多個閘道，而不是在單一大型閘道上合併多個檔案共用。例如，您可以在一個閘道上隔離一個重度使用的檔案共享，同時將較不常用的檔案共享分組到另一個閘道上。
規劃具有多個閘道和檔案共享的部署時，請考慮下列事項：
+ 單一閘道上的檔案共用數目上限為 50，但閘道管理的檔案共用數目可能會影響閘道的效能。如需詳細資訊，請參閱[具有多個檔案共享之閘道的效能指引](https://docs.aws.amazon.com/filegateway/latest/files3/Performance.html#performance-multiple-file-shares)。
+ 每個 S3 檔案閘道上的資源會跨所有檔案共用共用，無需分割。
+ 具有大量用量的單一檔案共享可能會影響閘道上其他檔案共享的效能。
**注意**
我們不建議從多個閘道建立多個映射至相同 Amazon S3 位置的檔案共用，除非其中至少一個是唯讀的。
從多個閘道同時寫入相同的檔案會被視為多寫入器案例，這可能會導致資料完整性問題。