本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
在 中更新運算環境 AWS Batch
AWS Batch 提供多種策略來更新運算環境,每個都專為特定更新案例和需求而設計。這些方法使用相同的基礎更新 API,但代表有效管理更新的不同規範方法。您可以使用 AWS Batch 主控台或 來管理這些更新 AWS CLI。了解這些策略可協助您選擇最符合您需求的方法,同時將對工作負載的干擾降至最低。
本主題提供可用更新策略的概觀,以及何時使用每種方法的指引。如需詳細程序,請參閱每個更新策略的個別區段。
重要
AWS Batch 代表您和在您的帳戶中建立和管理多個 AWS 資源,包括 Amazon EC2 啟動範本、Amazon EC2 Auto Scaling 群組、Amazon EC2 Spot 機群和 Amazon ECS 叢集。這些受管資源經過專門設定,以確保最佳 AWS Batch 操作。除非 AWS Batch 文件中明確說明,否則手動修改這些 AWS Batch受管資源可能會導致意外行為,包括INVALID運算環境、次佳執行個體擴展行為、延遲工作負載處理或意外成本。 AWS Batch 服務無法確定是否支援這些手動修改。一律使用支援的 AWS Batch APIs或 AWS Batch 主控台來管理您的運算環境。
不支援的手動修改包括執行您自己的 Amazon ECS 任務或服務 AWS Batch受管 Amazon ECS 叢集,或直接啟動其他程序、協助程式或服務 AWS Batch受管執行個體。 AWS Batch 會完全控制受管運算環境中的運算資源,並且可以隨時終止執行個體、停止任務或擴展叢集。您在這些受管資源 AWS Batch 的任務提交之外執行的任何工作負載都可以中斷,而不會出現警告。執行非AWS Batch 工作負載的 AWS Batch受管叢集和執行個體也會干擾 AWS Batch 任務排程和執行個體擴展。
運算環境更新策略
當您使用擴展或基礎設施更新時,會更新運算環境。對於藍/綠更新策略,您要建立新的運算環境 (綠色),然後將工作負載從舊運算環境 (藍色) 遷移到新的運算環境 (綠色)。
AWS Batch 提供三種不同的運算環境更新策略:
- 擴展更新
-
擴展更新會透過新增或移除執行個體來調整運算環境的容量,而無需取代現有的執行個體。這是最快的更新案例,不需要停機時間。當您需要變更容量設定 (vCPUs時,請使用擴展更新。這些更新通常會在幾分鐘內完成。
Fargate 更新使用與擴展更新相同的程序執行。如需詳細資訊,請參閱執行擴展更新。
- 基礎設施更新
-
基礎設施更新會將運算環境中的執行個體取代為具有更新設定的新執行個體。這些更新需要特定的服務角色和配置策略組態,但可提供最短的停機時間,執行中的任務可能會中斷。當您需要修改執行個體類型、AMI 組態、聯網設定、服務角色、環境狀態或其他基礎設施元件時,請使用基礎設施更新。這些更新通常會在 10-30 分鐘內完成,視任務完成而定。
如需詳細資訊,請參閱執行基礎設施更新。
- 藍/綠更新
-
藍/綠更新會與您現有的環境一起建立新的運算環境,允許漸進式工作負載轉換,無需停機。此方法提供最安全的更新路徑,但需要暫時執行兩個環境。當您需要零停機時間、想要在完全部署之前測試變更、需要快速復原功能,或使用不支援的組態進行基礎設施更新時,請使用藍/綠更新。完成的時間是可變的,由您控制。
如需詳細資訊,請參閱執行運算環境的藍/綠更新。
選擇正確的更新策略
使用此決策指南來選取最符合您需求的更新策略:
在 時選擇擴展更新
當您只需要調整運算容量 (vCPUs) 時,請選擇擴展更新策略。當您需要快速更新而不需要停機時間,也不需要基礎設施組態變更時,擴展更新是理想的選擇。
如需詳細程序,請參閱執行擴展更新。
在 時選擇基礎設施更新
當您需要修改執行個體類型、AMI 設定、服務角色、環境狀態或聯網組態時,請選擇基礎設施更新策略。您的環境必須使用 AWSServiceRoleForBatch 服務連結角色,以及 BEST_FIT_PROGRESSIVE、BEST_FIT_PROGRESSIVE_ORDERED、SPOT_PRICE_CAPACITY_OPTIMIZED、 SPOT_CAPACITY_OPTIMIZED或 的配置策略SPOT_CAPACITY_OPTIMIZED_PRIORITIZED。當在更新期間接受某些任務中斷,而且您希望自動更新至最新的 Amazon ECS 最佳化 AMI 時,基礎設施更新運作良好。
如需詳細程序,請參閱執行基礎設施更新。
在 時選擇藍/綠更新
當您的工作負載需要零停機時間,或您需要在轉換生產工作負載之前測試變更時,請選擇藍/綠更新策略。當快速復原功能很重要、您的環境使用BEST_FIT配置策略,或您的環境不使用 AWSServiceRoleForBatch 服務連結角色時,這種方法至關重要。當您使用需要手動更新或需要進行主要組態變更AMIs 時,藍/綠更新也是最佳選擇。
如需詳細程序,請參閱執行運算環境的藍/綠更新。
AMI 更新考量事項
更新 AMIs的方法取決於您的運算環境組態。
將 AWS Batch 提供的預設 AMI 更新為最新
AWS Batch 當符合下列所有條件時, 可以在基礎設施更新期間更新至最新的 Amazon ECS 最佳化 AMI:
注意
基礎設施更新完成後updateToLatestImageVersion,會將 設定為 false。若要啟動另一個更新,updateToLatestImageVersion必須將 設定為 true。
-
運算環境使用 AWSServiceRoleForBatch 服務連結角色。
-
配置策略設定為
BEST_FIT_PROGRESSIVE、BEST_FIT_PROGRESSIVE_ORDERED、SPOT_PRICE_CAPACITY_OPTIMIZED、SPOT_CAPACITY_OPTIMIZED或SPOT_CAPACITY_OPTIMIZED_PRIORITIZED。 -
imageId、imageIdOverride或 啟動範本中未明確指定 AMI ID。 -
updateToLatestImageVersion設定為true。
使用藍/綠部署的 AMI 更新
在這些情況下,您必須使用藍/綠部署來更新 AMIs:
-
使用特定版本的 Amazon ECS 最佳化 AMI 時。
-
在下列任一個中指定 AMI ID 時:
-
啟動範本 (必須更新或移除範本)。
-
imageId參數。 -
EC2 組態中的
imageIdOverride參數。
-
-
使用
BEST_FIT配置策略時 (不支援基礎設施更新)。 -
不使用 AWSServiceRoleForBatch 服務連結角色時。
自訂 AMI 的 AMI 更新
如果您在運算環境的啟動範本中指定自訂 AMI,則 EC2 組態中的 imageId 參數或 imageIdOverride 參數 AWS Batch 不會在基礎設施更新期間自動更新您的自訂 AMI。您可以在最初在運算環境建立期間使用的 參數中指定新的 ID,以更新自訂 AMI ID。如果您想要使用 AWS Batch提供的 AMI 切換到 ,您可以在運算環境更新中移除自訂 AMI ID。