本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
車隊自動擴展策略
了解 AppStream 2.0 執行個體
AppStream 2.0 叢集執行個體的使用者對叢集執行個體比例為 1:1。這表示每個使用者都有自己的串流執行個體。您同時連線的使用者數量將決定叢集的大小。
擴展政策
AppStream 2.0 叢集是在應用程式自動調整群組中啟動的。這可讓叢集根據使用情況進行擴充,以滿足需求。隨著使用量的增加,叢集會向外擴充,而當使用者中斷連線時,叢集會重新擴充。這是透過設定資源調整政策來控制。您可以設定以排程為基礎的擴展、步驟擴展和目標追蹤擴展政策。如需這些擴展政策的詳細資訊,請參閱 Amazon AppStream 2.0 的叢集 Auto Scaling。
步進縮放
這些原則會依目前叢集大小的百分比或特定數目的執行個體來增加或減少叢集容量。步驟擴展政策由Capacity
Utilization
、Available Capacity
或的 AppStream 2.0 CloudWatch 指標觸發Insufficient Capacity
Errors
。
使用步驟擴展政策時,AWS建議您新增容量百分比,而不是固定數量的執行個體。這可確保您的擴展動作與叢集的大小成正比。這將有助於避免擴展過慢的情況(因為您新增了少量的執行個體相對於叢集大小),或在叢集較小時發生過多的執行個體。
目標追蹤
使用此原則可指定叢集的容量使用率層級。應用程式自動調度資源會建立和管理 CloudWatch警示,以觸發擴展政策。這會增加或移除將叢集保持在指定目標值或接近指定目標值的容量。為了確保應用程式可用性,您的叢集會盡可能快地按比例擴展量度,但會逐步擴展。設定目標追蹤時,請考慮縮放冷卻時間,以確保在所需的間隔內進行擴充和縮放。
目標跟踪對高流失情況有效。流失率是指大量使用者在短時間內開始或結束工作階段的時間。您可以通過檢查車隊的 CloudWatch指標來識別流失率。您的叢集具有非零擱置容量而未變更 (或極少變更) 所需容量的期間,表示可能會發生高流失率。在高流失情況下,請設定目標追蹤原則,其中 (100 — 目標使用率百分比) 在 15 分鐘內超過流失率。例如,如果 10% 的叢集因使用者流失而在 15 分鐘內終止,請將容量使用率目標設定為 90% 以下,以抵消高流失率。
以排程為基礎的縮放
這些原則可讓您根據以時間為基礎的排程來設定所需的叢集容量。當您瞭解登入行為並可預測需求變更時,此原則就會生效。
例如,在工作日開始時,您可能會預期有 100 位使用者在上午 9:00 要求串流連線。您可以設定以排程為基礎的擴展政策,在上午 8:40 將叢集大小下限設為 100。這可讓叢集執行個體在工作日開始時建立並提供使用,並允許 100 位使用者同時連線。然後,您可以設定另一個已排程的政策,以便在下午 5:00 將叢集中調整至少 10 個。這可讓您節省成本,因為下班後的工作階段需求少於工作日的需求。
在生產環境中擴展原
您可以選擇在單一叢集中合併不同類型的擴展政策,以協助為您的使用者行為定義精確的擴展政策。在前面的範例中,您可以將排程的擴展政策與目標追蹤或步驟擴展政策結合,以維持特定的使用率層級。排程擴展和目標追蹤擴展的結合,有助於在立即需要容量時減少使用率層級急劇增加的影響。
擴展政策變更所需執行個體數量時,連線至串流工作階段的使用者不會受到擴充或擴充的影響。擴展政策不會結束現有的串流工作階段。現有工作階段將持續不中斷,直到工作階段由使用者或叢集逾時原則結束為止。
透過 CloudWatch 指標監控 AppStream 2.0 使用情況可協助您隨著時間的推移最佳化擴展政策。例如,在初始設定期間過度佈建資源是很常見的,而且您可能會看到長時間的低使用率。或者,如果叢集佈建不足,您可能會看到高容量使用率和「容量不足」錯誤。檢閱 CloudWatch 指標可協助您調整資源調整政策,以協助減輕這些錯誤。如需詳細資訊以及您可以使用的 AppStream 2.0 擴展政策範例,請參閱擴展 Amazon AppStream 2.0 叢集