最佳化 SQL Server 資料庫備份的 S3 檔案閘道 - AWS Storage Gateway
在與 SQL Server 相同的位置部署閘道減少慢速磁碟所造成的瓶頸調整 CPU、RAM 和快取磁碟的 S3 檔案閘道虛擬機器資源配置透過調整 S3 檔案閘道的安全層級來改善 SMB 用戶端輸送量將 SQL 備份分割成多個檔案，以改善 SMB 用戶端輸送量增加 SMB 逾時設定，防止大型檔案複製失敗增加 Amazon S3 上傳程式執行緒的數量關閉自動快取重新整理部署多個閘道以支援工作負載資料庫備份工作負載的其他資源

Amazon FSx File Gateway 不再提供給新客戶。FSx File Gateway 的現有客戶可以繼續正常使用服務。如需類似 FSx File Gateway 的功能，請造訪此部落格文章。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

最佳化 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 執行個體的置放群組。

減少慢速磁碟所造成的瓶頸

我們建議您監控 IoWaitPercent CloudWatch 指標，以識別 S3 檔案閘道上緩慢儲存磁碟可能造成的效能瓶頸。嘗試最佳化磁碟相關的效能問題時，請考慮下列事項：

  • IoWaitPercent 報告 CPU 從根磁碟或快取磁碟等待回應的時間百分比。

  • 當 IoWaitPercent 大於 5-10% 時，這通常表示由於磁碟效能不佳而導致閘道效能瓶頸。此指標應盡可能接近 0%，這表示閘道永遠不會在磁碟上等待，這有助於最佳化 CPU 資源。

  • 您可以檢查 Storage Gateway 主控台的IoWaitPercent監控索引標籤，或設定建議的 CloudWatch 警示，以便在指標峰值超過特定閾值時自動通知您。如需詳細資訊，請參閱為您的閘道建立建議的 CloudWatch 警示。

  • 建議您將 NVMe 或 SSD 用於閘道的根磁碟和快取磁碟，以將 降至最低IoWaitPercent。

調整 CPU、RAM 和快取磁碟的 S3 檔案閘道虛擬機器資源配置

嘗試最佳化 S3 檔案閘道的輸送量時，請務必將足夠的資源配置給閘道 VM，包括 CPU、RAM 和快取磁碟。4 個 CPUs、16GB RAM 和 150GB 快取儲存體的最低虛擬資源需求通常僅適用於較小的工作負載。為較大的工作負載配置虛擬資源時，我們建議下列事項：

  • 根據 S3 檔案閘道產生的典型 CPUs 使用量，將配置的 CPU 數量增加到 16 到 48 之間。您可以使用 UserCpuPercent 指標監控 CPU 用量。如需詳細資訊，請參閱了解閘道指標。

  • 將配置的 RAM 增加到 32 到 64 GB 之間。

    注意

    S3 檔案閘道無法使用超過 64 GB 的 RAM。

  • 將 NVMe 或 SSD 用於根磁碟和快取磁碟，並調整快取磁碟的大小，以符合您計劃寫入閘道的尖峰工作資料集。如需詳細資訊，請參閱官方 Amazon Web Services YouTube 頻道上的 S3 File Gateway 快取大小調整最佳實務。

  • 將至少 4 個虛擬快取磁碟新增至閘道，而不是使用單一大型磁碟。即使多個虛擬磁碟共用相同的基礎實體磁碟，也可以改善效能，但當虛擬磁碟位於不同的基礎實體磁碟時，改善功能通常會更大。

    例如，如果您想要部署 12TB 的快取，您可以使用下列其中一個組態：

    • 4 x 3 TB 快取磁碟

    • 8 x 1.5 TB 快取磁碟

    • 12 x 1 TB 快取磁碟

    除了效能之外，這還允許在一段時間內更有效率地管理虛擬機器。隨著工作負載變更，您可以逐步增加快取磁碟的數量和整體快取容量，同時維持每個個別虛擬磁碟的原始大小，以保持閘道完整性。

    如需詳細資訊，請參閱決定本機磁碟儲存量。

將 S3 檔案閘道部署為 Amazon EC2 執行個體時，請考慮下列事項：

  • 您選擇的執行個體類型可能會大幅影響閘道效能。Amazon EC2 提供調整 S3 File Gateway 執行個體資源配置的廣泛彈性。

  • 如需 S3 檔案閘道的建議 Amazon EC2 執行個體類型，請參閱 Amazon EC2 執行個體類型的需求。

  • 您可以變更託管作用中 S3 檔案閘道的 Amazon EC2 執行個體類型。這可讓您輕鬆調整 Amazon EC2 硬體的產生和資源配置，以找到理想的price-to-performance比率。若要變更執行個體類型，請在 Amazon EC2 主控台中使用下列程序：

    1. 停止 Amazon EC2 執行個體。

    2. 變更 Amazon EC2 執行個體類型。

    3. 開啟 Amazon EC2 執行個體的電源。

    注意

    停止託管 S3 檔案閘道的執行個體將暫時中斷檔案共用存取。如有必要，請務必排定維護時段。

  • Amazon EC2 執行個體price-to-performance比是指您支付的價格獲得的運算能力。一般而言，較新一代的 Amazon EC2 執行個體提供最佳price-to-performance比，與較舊世代相比，硬體和效能提升的成本相對較低。執行個體類型、區域和使用模式等因素會影響此比率，因此請務必為特定工作負載選取正確的執行個體，以最佳化成本效益。

透過調整 S3 檔案閘道的安全層級來改善 SMB 用戶端輸送量

SMBv3 通訊協定允許 SMB 簽署和 SMB 加密，這在效能和安全性方面有一些取捨。若要最佳化輸送量，您可以調整閘道的 SMB 安全層級，以指定要針對用戶端連線強制執行哪些安全功能。如需詳細資訊，請參閱設定閘道的安全層級。

調整 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 伺服器的多個執行緒來平行寫入多個檔案，並同時使用多個 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 在備份期間可以寫入多少檔案沒有嚴格的限制，但儲存架構和網路頻寬等實際考量應該會引導此選項。

如需詳細資訊，請參閱：

增加 SMB 逾時設定，防止大型檔案複製失敗

當 S3 File Gateway 將大型 SQL 備份檔案複製到 SMB 檔案共享時，SMB 用戶端連線可能會在較長的一段時間後逾時。我們建議您將 SQL Server SMB 用戶端的 SMB 工作階段逾時設定延長至 20 分鐘或更長時間，具體取決於檔案大小和閘道的寫入速度。預設值為 300 秒或 5 分鐘。如需詳細資訊，請參閱您的閘道備份任務失敗，或寫入閘道時發生錯誤。

增加 Amazon S3 上傳程式執行緒的數量

根據預設，S3 File Gateway 會為 Amazon S3 資料上傳開啟 8 個執行緒，這可為大多數典型部署提供足夠的上傳容量。不過，閘道可能會以高於標準 Amazon S38 執行緒容量的速率從 SQL 伺服器接收資料，這可能會導致本機快取達到其儲存限制。

在特定情況下， 支援 可以將閘道的 Amazon S3 上傳執行緒集區計數從 8 增加到 40，這允許平行上傳更多資料。根據頻寬和部署特有的其他因素，這可以大幅提高上傳效能，並有助於減少支援工作負載所需的快取儲存量。

我們建議您使用 CachePercentDirty CloudWatch 指標來監控儲存在本機閘道快取磁碟上尚未上傳至 Amazon S3 的資料量，並聯絡 支援 以協助判斷增加上傳執行緒集區計數是否可能改善 S3 檔案閘道的輸送量。如需詳細資訊，請參閱了解閘道指標。

注意

此設定會使用其他閘道 CPU 資源。我們建議您監控閘道 CPU 用量，並視需要增加配置的 CPU 資源。

關閉自動快取重新整理

自動化快取重新整理功能可讓您的 S3 檔案閘道自動重新整理其中繼資料，這有助於擷取使用者或應用程式對檔案集所做的任何變更，方法是直接寫入 Amazon S3 儲存貯體，而不是透過閘道。如需詳細資訊，請參閱重新整理 Amazon S3 儲存貯體物件快取。

若要最佳化閘道輸送量，建議您在部署中關閉此功能，其中所有讀取和寫入 Amazon S3 儲存貯體的作業都會透過 S3 檔案閘道執行。

設定自動快取重新整理時，請考慮下列事項：

  • 如果您需要使用自動快取重新整理，因為部署中的使用者或應用程式偶爾會直接寫入 Amazon S3，則建議您設定重新整理之間的最長時間間隔，這仍然適合您業務需求。較長的快取重新整理間隔有助於減少閘道在瀏覽目錄或修改檔案時需要執行的中繼資料操作數量。

    例如：如果工作負載可容忍，請將自動快取重新整理設定為 24 小時，而不是 5 分鐘。

  • 最短時間間隔為 5 分鐘。間隔上限為 30 天。

  • 如果您選擇設定非常短的快取重新整理間隔，建議您測試 SQL 伺服器的目錄瀏覽體驗。重新整理閘道快取所需的時間可能會大幅增加，具體取決於 Amazon S3 儲存貯體中的檔案和子目錄數量。

部署多個閘道以支援工作負載

Storage Gateway 可以透過跨多個閘道分割工作負載，為具有數百個 SQL 資料庫、多個 SQL Server 和數百 TB 備份資料的大型環境支援 SQL 備份。

規劃具有多個閘道和 SQL 伺服器的部署時，請考慮下列事項：

  • 單一閘道通常每天最多可以上傳 20 TB，具有足夠的硬體資源和頻寬。您可以增加 Amazon S3 上傳程式執行緒的數量，將此限制提高到每天 40 TB。

  • 我們建議您進行proof-of-concept測試，以測量效能並考慮部署中的所有變數。確定 SQL 備份工作負載的最高輸送量之後，您可以擴展閘道數量以符合您的需求。

  • 我們建議您以成長為考量來設計解決方案，因為資料庫數量和資料庫大小可能會隨著時間增加。若要繼續擴展和支援不斷增加的工作負載，您可以視需要部署其他閘道。

資料庫備份工作負載的其他資源