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/)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 效能和最佳化
本節說明最佳化 File Gateway 效能的指引和最佳實務。
**Topics**
+ [FSx File Gateway 的基本效能指引](#performance-fgw)
+ [最佳化閘道效能](#Optimizing-common)
+ [最大化 S3 檔案閘道輸送量](Performance-Throughput.md)
+ [最佳化 SQL Server 資料庫備份的 S3 檔案閘道](SQL-Backup-Best-Practices.md)
## FSx File Gateway 的基本效能指引
在本節中，您可以找到為 FSx 檔案閘道 VM 佈建硬體的指引。資料表中列出的執行個體組態是範例，並提供參考。
若要獲得最佳效能，必須將快取磁碟大小調整到實際運作集合的大小。使用多個本機磁碟的快取，藉由平行存取資料提高寫入效能，並提高 IOPS。
**注意**
我們不建議使用暫時性儲存。如需使用暫時性儲存的詳細資訊，請參閱[搭配 EC2 閘道使用暫時性儲存](ephemeral-disk-cache.md)。
您連線到檔案閘道檔案系統中個別目錄的建議大小限制為每個目錄 10，000 個檔案。您可以使用檔案閘道搭配超過 10，000 個檔案的目錄，但效能可能會受到影響。
在下表中，*快取命*中讀取操作是從快取提供的檔案資料讀取。*快取遺漏*讀取操作是從 Amazon FSx for Windows File Server 提供的檔案資料進行讀取。
下表顯示 FSx File Gateway 組態範例。
### Windows 用戶端上的 FSx File Gateway 效能
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/filefsxw/Performance.html)
**注意**
效能可能會根據您的主機平台組態和網路頻寬而有所不同。寫入輸送量效能會隨著檔案大小而降低，小型檔案 （小於 32MiB) 可達到的最高輸送量為每秒 16 個檔案。
## 最佳化閘道效能
您可以在下列內容中找到最佳化閘道效能的方法資訊。本指南是以將資源新增至您的閘道，以及將資源新增至您的應用程式伺服器為基礎。
### 新增資源至您的閘道
您可以利用下列其中一或多個方法，將資源新增到您的閘道，以將閘道效能最佳化。
**使用高效能磁碟**
若要最佳化閘道效能，您可以新增高效能磁碟，例如固態硬碟 (SSD) 和 NVMe 控制器。您也可以將虛擬磁碟從儲存區區域網路 (SAN) 直接連接到您的 VM，而非從 Microsoft Hyper-V NTFS。改善的磁碟效能通常得以提供更高的輸送量及每秒輸入/輸出操作數 (IOPS)。如需新增磁碟的詳細資訊，請參閱 [設定額外的快取儲存](ConfiguringLocalDiskStorage.md)。
若要測量輸送量，請使用 `ReadBytes` 和 `WriteBytes` 指標搭配 `Samples` Amazon CloudWatch 統計資料。例如，將 5 分鐘範例期間內 `Samples` 指標的 `ReadBytes` 統計資料除以 300 秒，便可取得 IOPS。做為一般規則，當您檢閱閘道的這些指標時，請尋找低輸送量及低 IOPS 趨勢，以指出磁碟相關的瓶頸。
CloudWatch 指標不適用於所有閘道。有关网关指标的資訊，请参阅[監控 FSx 檔案閘道](monitoring-file-gateway.md)。
**新增 CPU 資源至您的閘道主機**
閘道主機伺服器的最低需求為四個虛擬處理器。若要最佳化閘道效能，請確認指派給閘道 VM 的四個虛擬處理器受到四個核心的支援。此外，確認您沒有過度訂閱主機伺服器的 CPU。
將額外的 CPU 新增到閘道主機伺服器時，您會提高閘道的處理容量。這樣做可讓您的閘道並行處理從應用程式將資料儲存到本機儲存，以及將此資料上傳至 FSx for Windows File Server。額外的 CPU 也可協助確保您的閘道在主機與其他 VM 共享時，也能取得足夠的 CPU 資源。提供足夠的 CPU 資源對於改善輸送量具有一般性的效果。
Storage Gateway 支援在閘道主機伺服器中使用 24 CPUs。您可以使用 24 個 CPU 大幅改善您的閘道效能。我們建議您的閘道主機伺服器使用下列閘道組態：
+ 24 個 CPU。
+ 16 GiB 保留 RAM，適用於檔案閘道
+ 16 GiB 保留 RAM，適用於快取大小高達 16 TiB 的閘道
+ 32 GiB RAM，適用於快取大小為 16 TiB 至 32 TiB 的閘道
+ 48 GiB 保留 RAM，適用於快取大小為 32 TiB 至 64 TiB 的閘道
+ 連接到全虛擬控制器 1 的磁碟 1，做為閘道快取使用，如下所示：
+ 使用 NVMe 控制器的 SSD。
+ 在 VM 網路 1 上設定的網路轉接器 1：
+ 使用 VM 網路 1 及新增用於擷取的 VMXnet3 (10 Gbps)。
+ 在 VM 網路 2 上設定的網路轉接器 2：
+ 使用 VM 網路 2 及新增用於連線至 AWS的 VMXnet3 (10 Gbps)。
**具備個別實體磁碟的後端閘道虛擬磁碟**
當您佈建閘道磁碟時，強烈建議您不要為使用相同基礎實體儲存磁碟的本機儲存佈建本機磁碟。例如，針對 VMware ESXi，基礎實體儲存體資源會以資料存放區表示。當您部署閘道 VM 時，您會選擇要存放 VM 檔案的資料存放區。當您佈建虛擬磁碟 (例如：做為上傳緩衝) 時，您可以將虛擬磁碟存放在與 VM 相同或不同的資料存放區。
若您有超過一個資料存放區，我們強烈建議您為每一種您正在建立的本機儲存體類型選擇一個資料存放區。只用一個基礎實體磁碟支援的資料存放區，可能導致效能不佳。當您使用這種磁碟來同時支援快取儲存體和閘道設定中上傳緩衝的情形時，即為一個例子。同樣地，使用較少高效能 RAID 組態 (例如 RAID 1) 支援的資料存放區，可能導致效能不佳。
### 新增資源到您的應用程式環境
**增加您應用程式伺服器和閘道之間的頻寬**
若要最佳化閘道效能，請確認您應用程式和閘道之間的頻寬足以供給您應用程式的需求。您可以使用閘道的 `ReadBytes`和 `WriteBytes`指標來測量總資料輸送量。
針對您的應用程式，將所需要的輸送量與測量的輸送量進行比較。若測量的輸送量低於所需的輸送量，則在網路為瓶頸時，增加應用程式與閘道之間的頻寬便可改善效能。同樣地，若 VM 和本機磁碟沒有直接連接，您可以增加兩者間的頻寬。
**新增 CPU 資源到您的應用程式環境**
若您的應用程式可使用額外的 CPU 資源，則增加更多 CPU 可協助您的應用程式擴展其 I/O 負載。
FSx File Gateway 上的某些檔案操作，例如頂層資料夾重新命名或許可變更，可能會導致多個檔案操作，導致 FSx for Windows File Server 檔案系統具有高 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 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 位置的檔案共用，除非其中至少一個是唯讀的。
從多個閘道同時寫入相同的檔案會被視為多寫入器案例，這可能會導致資料完整性問題。
# 最佳化 SQL Server 資料庫備份的 S3 檔案閘道
資料庫備份是 S3 File Gateway 的常見建議使用案例，它透過將資料庫備份儲存在 Amazon S3 中來提供經濟實惠的短期和長期保留，並能夠根據需要生命週期以降低成本儲存層。透過此解決方案，您可以使用 SQL Server Management Studio 和 Oracle RMAN 等內建工具，減少企業備份應用程式的需求。
下列各節說明調整 S3 File Gateway 部署的最佳實務，以最佳化效能，並為數百 TB 的 SQL 資料庫備份提供符合成本效益的支援。每個區段中提供的指引會逐步提升整體輸送量。雖然這些建議都不需要，而且不是相互依存的，但它們是以 支援 用來測試和調整 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 效能不是同等的比較。
## 在與 SQL Server 相同的位置部署閘道
建議您將 S3 File Gateway 虛擬設備部署在實體位置，並在其與 SQL 伺服器之間盡可能減少網路延遲。選擇閘道的位置時，請考慮下列事項：
+ 降低閘道的網路延遲有助於改善 SMB 用戶端的效能，例如 SQL 伺服器。
+ S3 檔案閘道旨在容忍閘道與 Amazon S3 之間的網路延遲高於閘道與用戶端之間的網路延遲。
+ 對於在 Amazon EC2 中部署的 S3 檔案閘道執行個體，我們建議將閘道和 SQL 伺服器保留在相同的置放群組中。如需詳細資訊，請參閱《[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 檔案閘道虛擬機器資源配置
嘗試最佳化 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比，與較舊世代相比，硬體和效能提升的成本相對較低。執行個體類型、區域和使用模式等因素會影響此比率，因此請務必為特定工作負載選取正確的執行個體，以最佳化成本效益。
## 透過調整 S3 檔案閘道的安全層級來改善 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 用戶端，新設定才會生效。
## 將 SQL 備份分割成多個檔案，以改善 SMB 用戶端輸送量
+ 使用一次只寫入一個檔案的 S3 檔案閘道，很難達到最大輸送量效能，因為從單一 SQL 伺服器循序寫入是單執行緒操作。反之，我們建議您使用每個 SQL 伺服器的多個執行緒來平行寫入多個檔案，並同時使用多個 SQL 伺服器到您的 S3 檔案閘道，以最大化閘道輸送量。使用 SQL 備份時，將備份分割成多個檔案可讓每個檔案使用單獨的執行緒，這會同時將多個檔案寫入 S3 檔案閘道檔案共享。執行緒越多，可達到的輸送量就越多，最高可達閘道的限制。
+ SQL Server 支援在單一備份操作期間同時寫入多個檔案。例如，您可以使用 T-SQL 命令或 SQL Server Management Studio (SSMS) 指定多個檔案目的地。每個檔案使用單獨的執行緒，將資料從 SQL 伺服器傳送至閘道檔案共享。此方法可提高 I/O 輸送量，大幅改善備份速度和效率。
設定 SQL 伺服器備份時，請考慮下列事項：
+ 透過將備份分割為多個檔案，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/)
+ [使用檔案閘道在 Amazon S3 中輕鬆存放 SQL Server 備份](https://aws.amazon.com/blogs/storage/easily-store-your-sql-server-backups-in-amazon-s3-using-file-gateway/)
## 增加 SMB 逾時設定，防止大型檔案複製失敗
當 S3 File Gateway 將大型 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 File Gateway 會為 Amazon S3 資料上傳開啟 8 個執行緒，這可為大多數典型部署提供足夠的上傳容量。不過，閘道可能會以高於標準 Amazon S38 執行緒容量的速率從 SQL 伺服器接收資料，這可能會導致本機快取達到其儲存限制。
在特定情況下， 支援 可以將閘道的 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 伺服器的目錄瀏覽體驗。重新整理閘道快取所需的時間可能會大幅增加，具體取決於 Amazon S3 儲存貯體中的檔案和子目錄數量。
## 部署多個閘道以支援工作負載
Storage Gateway 可以透過跨多個閘道分割工作負載，為具有數百個 SQL 資料庫、多個 SQL Server 和數百 TB 備份資料的大型環境支援 SQL 備份。
規劃具有多個閘道和 SQL 伺服器的部署時，請考慮下列事項：
+ 單一閘道通常每天最多可以上傳 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 備份工作負載的最高輸送量之後，您可以擴展閘道數量以符合您的需求。
+ 我們建議您以成長為考量來設計解決方案，因為資料庫數量和資料庫大小可能會隨著時間增加。若要繼續擴展和支援不斷增加的工作負載，您可以視需要部署其他閘道。
## 資料庫備份工作負載的其他資源
+ [使用 在 Amazon S3 中存放 SQL Server 備份 AWS Storage Gateway](https://aws.amazon.com/blogs/database/storing-sql-server-backups-in-amazon-s3-using-aws-storage-gateway/)
+ [使用檔案閘道在 Amazon S3 中輕鬆存放 SQL Server 備份](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/)
+ [大規模將 Oracle 資料庫備份至 Amazon S3 ](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 Hero 如何使用 AWS Storage Gateway 進行雲端內備份](https://aws.amazon.com/blogs/storage/how-one-aws-hero-uses-aws-storage-gateway-for-in-cloud-backup/)
+ [S3 File Gateway 快取調整大小最佳實務](https://www.youtube.com/watch?v=-ibL1eEcROI)