Amazon EKS 上增強型叢集操作的持續佈建 - Amazon SageMaker AI

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

Amazon EKS 上增強型叢集操作的持續佈建

使用 Amazon EKS 協同運作建立的 Amazon SageMaker HyperPod 叢集現在支援持續佈建,這項新功能可提高執行大規模 AI/ML 工作負載的彈性和效率。持續佈建可讓您快速開始訓練、無縫擴展、在不中斷操作的情況下執行維護,以及具有叢集操作的精細可見性。

注意

對於使用 EKS 協同運作建立的 HyperPod 叢集,連續佈建可以作為其選用組態使用。使用 Slurm 協同運作建立的叢集會使用不同的擴展模型。

運作方式

持續佈建系統引入了取代傳統請求型模型的所需狀態架構。此新架構可跨不同資源層級進行平行、非封鎖操作,同時維持系統穩定性和效能。持續佈建系統:

  • 接受請求:記錄每個執行個體群組的目標執行個體計數

  • 啟動佈建:開始啟動執行個體以符合目標計數

    追蹤進度:監控每個執行個體啟動嘗試並記錄狀態

  • 處理失敗:自動重試失敗的啟動

持續佈建預設為停用。若要使用此功能,請將 --node-provisioning-mode 設定為 Continuous

啟用持續佈建後,您可以同時啟動多個擴展操作,而無需等待先前的操作完成。這可讓您同時擴展相同叢集中的不同執行個體群組,並將多個擴展請求提交至相同的執行個體群組。

持續佈建也可讓您存取 DescribeClusterEventListClusterEvent,以取得詳細的事件監控和操作可見性。

用量計量

具有持續佈建的 HyperPod 叢集會使用執行個體層級計量,以提供反映實際資源用量的準確計費。這種計量方法與傳統的叢集層級計費不同,因為其獨立追蹤每個執行個體。

執行個體層級計費

透過持續佈建,計費會在個別執行個體層級開始和停止,而不是等待叢集層級狀態變更。此方法提供下列優勢:

  • 精確的計費準確性:計費開始於生命週期指令碼執行開始時。如果生命週期指令碼失敗,則會重試執行個體佈建,並在生命週期指令碼執行時期向您收取費用。

  • 獨立計量:個別管理每個執行個體的計費生命週期,防止階層式計費錯誤

  • 即時計費更新:計費會在執行個體開始執行其生命週期指令碼時開始,並在執行個體進入終止狀態時停止

計費生命週期

HyperPod 叢集中的每個執行個體都遵循此計費生命週期:

  • 計費開始:當執行個體成功啟動並開始執行其生命週期組態指令碼時

  • 計費繼續:執行個體的整個操作存留期

  • 計費停止:當執行個體進入終止狀態時,無論終止原因為何

注意

對於無法啟動的執行個體,計費不會開始。如果執行個體啟動由於容量不足或其他問題而失敗,則不會向您收取該失敗嘗試的費用。計費是在執行個體層級計算的,而且成本是在叢集的 Amazon Resource Name (ARN) 下彙總和報告。

建立已啟用持續佈建的叢集

注意

您必須具有已使用 VPC 聯網設定且已安裝必要 Helm Chart 的現有 Amazon EKS 叢集。此外,準備生命週期組態指令碼,並將其上傳至執行角色可以存取的 Amazon S3 儲存貯體。如需詳細資訊,請參閱管理由 Amazon EKS 協作的 SageMaker HyperPod 叢集

下列AWS CLI操作會建立啟用一個執行個體群組和連續佈建的 HyperPod 叢集。

aws sagemaker create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET'"] }' \ --instance-groups '{ "InstanceGroupName": "ig-1", "InstanceType": "ml.c5.2xlarge", "InstanceCount": 2, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create_noop.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'", "ThreadsPerCore": 1, "TrainingPlanArn": "" }' \ --node-provisioning-mode Continuous // Expected Output: { "ClusterArn": "arn:aws:sagemaker:us-west-2:<account-id>:cluster/<cluster-id>" }

建立了您的叢集後,您可以使用 ListClusterNodesDescribeClusterNode 來進一步了解叢集中的節點。

呼叫這些操作將傳回 ClusterInstanceStatusDetails 物件與下列其中一個值:

  • Running:節點運作狀態良好,並已向叢集協調器 (EKS) 註冊。

  • Failure:節點佈建失敗,但系統將會使用新的 EC2 執行個體自動重試佈建。

  • Pending:正在佈建或重新啟動節點。

  • ShuttingDown:節點正在終止中。節點將在終止遇到問題時轉換為失敗狀態,或者成功從叢集中移除。

  • SystemUpdating:節點正在進行 AMI 修補,可以是手動觸發或作為修補 cronjob 的一部分。

  • DeepHealthCheckInProgress:正在執行深層運作狀態檢查 (DHC)。這可能需要幾分鐘到幾個小時,取決於測試的本質。不好的節點會遭到取代,而運作狀態良好的節點會切換到 Running。

  • NotFound:用於 BatchAddClusterNodes 回應,表示節點已在冪等性重播期間刪除。

最小容量需求 (MinCount)

MinCount 功能可讓您指定執行個體群組轉換為 InService 狀態之前,必須成功佈建的執行個體數量下限。此功能可更好地控制擴展操作,並有助於防止部分佈建的執行個體群組無法有效地用於訓練工作負載的情況。

重要

MinCount 並非最低容量的永久保證。它只會確保執行個體群組第一次變成 時,指定的執行個體數量下限可供使用InService。低於 MinCount 的短暫下降可能會在正常操作期間發生,例如運作狀態不佳的執行個體替換或維護活動。

MinCount 的運作方式

當您建立或更新已啟用 MinCount 的執行個體群組時,會發生下列行為:

  • 新的執行個體群組:執行個體群組會保持 Creating 狀態,直到至少成功佈建並就緒 MinCount 執行個體為止。一旦達到此閾值,執行個體群組就會轉換為 InService

  • 現有執行個體群組:更新現有執行個體群組上的 MinCount 時,狀態會變更為 ,Updating直到滿足新的 MinCount 需求為止。

  • 持續擴展:如果 TargetCount 大於 MinCount,則持續擴展系統會繼續嘗試啟動其他執行個體,直到達到 TargetCount。

  • 逾時和轉返:如果無法在 3 小時內滿足 MinCount,系統會自動將執行個體群組轉返至其最後已知的良好狀態。如需轉返行為的詳細資訊,請參閱自動轉返行為

MinCount 操作期間的執行個體群組狀態

已設定 MinCount 的執行個體群組會顯示下列狀態行為:

正在建立

對於 CurrentCount < MinCount 時的新執行個體群組。執行個體群組會保持此狀態,直到符合最低容量需求為止。

更新中

針對修改 MinCount 且 CurrentCount < MinCount 的現有執行個體群組。執行個體群組會保持此狀態,直到滿足新的最小容量需求為止。

InService

當 MinCount ≤ CurrentCount ≤ TargetCount 時。執行個體群組已準備好可供使用,且所有變更操作都會解除封鎖。

CreatingUpdating 狀態期間,適用下列限制:

  • 變更 BatchAddClusterNodesBatchDeleteClusterNodes或 等操作UpdateClusterSoftware會遭到封鎖

  • 您仍然可以修改 MinCount 和 TargetCount 值來更正組態錯誤

  • 一律允許刪除叢集和執行個體群組

自動轉返行為

如果執行個體群組無法在 3 小時內達到其 MinCount,系統會自動啟動轉返,以防止無限期等待:

  • 新的執行個體群組:MinCount 和 TargetCount 重設為 (0、0)

  • 現有執行個體群組:MinCount 和 TargetCount 會從上次InService狀態還原至其值

  • 終止的執行個體選擇:如果執行個體需要在復原期間終止,系統會先選取運作狀態不佳的執行個體,然後選取最近佈建的執行個體。

  • 狀態轉換:執行個體群組會在復原啟動後立即轉換為InService狀態,允許持續擴展系統根據復原設定管理容量

每次更新 MinCount 時,3 小時逾時都會重設。例如,如果您多次更新 MinCount,逾時期間會從最近的更新開始。

MinCount 事件

系統會發出特定事件,協助您追蹤 MinCount 操作:

  • 達到容量下限:當執行個體群組成功達到其 MinCount 並轉換為 InService

  • 啟動回復:當 3 小時逾時過期且自動回復開始時發出

您可以使用 ListClusterEvents 監控這些事件,以追蹤 MinCount 操作的進度。

API 用量

MinCount 是在執行個體群組組態中使用 MinInstanceCount 參數來指定:

aws sagemaker create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET'"] }' \ --instance-groups '{ "InstanceGroupName": "worker-group", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 64, "MinInstanceCount": 50, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'" }' \ --node-provisioning-mode Continuous

MinCount 用量的主要考量事項:

  • MinInstanceCount 必須在 CreateClusterUpdateCluster 請求中指定之執行個體群組的 0 和 InstanceCount(包含) 值之間

  • MinInstanceCount 設定為 0 (預設) 可保留標準持續擴展行為

  • 設定MinInstanceCount等於 InstanceCount可提供全有或全無擴展行為 all-or-nothing

  • MinCount 僅適用於NodeProvisioningMode設定為 的叢集 Continuous