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

# 使用 Slurm 持續佈建增強型叢集操作
<a name="sagemaker-hyperpod-scaling-slurm"></a>

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

**注意**  
連續佈建可作為使用 Slurm 協同運作所建立之新 HyperPod 叢集的選用組態。目前，使用先前擴展模型的現有叢集無法遷移至連續佈建。

## 運作方式
<a name="sagemaker-hyperpod-scaling-slurm-how"></a>

持續佈建系統引入了所需狀態架構，取代了傳統的all-or-nothing擴展模型。在先前的模型中，如果任何執行個體群組無法完全佈建，整個叢集建立或更新操作會失敗並復原。透過持續佈建，系統會接受部分容量，並繼續以非同步方式佈建剩餘的執行個體。

持續佈建系統：
+ **接受請求**：記錄每個執行個體群組的目標執行個體計數。
+ **啟動佈建**：開始平行啟動所有執行個體群組的執行個體。
+ **先佈建優先順序節點**：在成功佈建至少一個控制器節點 （以及一個登入節點，如果已指定登入執行個體群組） `InService`之後，叢集會轉換為 。
+ **追蹤進度**：監控每個執行個體啟動嘗試並記錄狀態。
+ **處理失敗**：以非同步方式自動重試工作者節點的失敗啟動。

持續佈建預設為停用。若要使用此功能，請在`CreateCluster`請求`Continuous`中`NodeProvisioningMode`將 設定為 。

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

## 優先順序型佈建
<a name="sagemaker-hyperpod-scaling-slurm-priority"></a>

Slurm 叢集需要控制器節點可運作，工作者節點才能註冊和接受任務。持續佈建會透過優先順序型佈建自動處理此問題：

1. 首先佈建控制器執行個體群組。

1. 一旦一個控制器節點正常運作，登入節點和工作者節點就會開始平行佈建。

1. 當一個控制器節點啟動且一個登入節點啟動`InService`時 （如果指定登入執行個體群組），叢集會轉換為 。如果未指定登入執行個體群組，叢集會在佈建控制器節點`InService`後立即轉換為 。

1. 由於容量限制而無法立即佈建的工作者節點會進入非同步重試迴圈，並在 Slurm 叢集可用時自動將其新增至 Slurm 叢集。

## 控制器故障處理
<a name="sagemaker-hyperpod-scaling-slurm-controller-failure"></a>

在叢集建立期間，如果控制器節點無法佈建，則行為取決於錯誤是可重試還是不可重試。

**可重試的錯誤 **（例如運作狀態不佳的執行個體或暫時性故障）：
+ HyperPod 會持續取代執行個體，並重試佈建，直到控制器啟動為止。
+ 已佈建的工作者和登入節點仍然可用，但在控制器運作狀態良好`InService`之前，叢集不會轉換為 。

**無法重試的錯誤 **（例如，控制器執行個體類型或生命週期指令碼失敗沒有可用的容量）：
+ 叢集會標示為 `Failed`。
+ 您會收到失敗原因的通知，並且必須採取修正動作，例如選擇不同的執行個體類型、修正生命週期指令碼，或在不同的可用區域中重試。

## 先決條件
<a name="sagemaker-hyperpod-scaling-slurm-prerequisites"></a>

持續佈建需要透過每個執行個體群組 `SlurmConfig` 欄位中的 API 承載提供 Slurm 佈建參數 （節點類型、分割區名稱）。在 Amazon S3 中依賴舊版`provisioning_parameters.json`檔案的叢集與連續佈建不相容。

**注意**  
Slurm 叢集上目前不支援連續佈建下列功能：遷移現有叢集、透過 API 型 Slurm 拓撲進行多標頭節點組態，以及 `SlurmConfigStrategy`。持續佈建僅以合併模式運作以進行`slurm.conf`管理。

## 用量計量
<a name="sagemaker-hyperpod-scaling-slurm-metering"></a>

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

**執行個體層級計費**

透過持續佈建，計費會在個別執行個體層級開始和停止，而不是等待叢集層級狀態變更。此方法提供下列優勢：
+ **精確的計費準確性**：計費開始於生命週期指令碼執行開始時。如果生命週期指令碼失敗，將會重試執行個體佈建，並在生命週期指令碼執行時間期間向您收取費用。
+ **獨立計量**：每個執行個體的計費生命週期都會個別管理，防止串聯計費錯誤。
+ **即時計費更新**：計費會在執行個體開始執行其生命週期組態指令碼時開始，並在執行個體進入終止狀態時停止。

**計費生命週期**

HyperPod 叢集中的每個執行個體都遵循此計費生命週期：
+ **帳單開始**：當執行個體成功啟動並開始執行其生命週期組態指令碼時。
+ **帳單會繼續**：執行個體的整個操作生命週期。
+ **計費停止**：當執行個體進入終止狀態時，無論終止原因為何。

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

## 建立已啟用持續佈建的叢集
<a name="sagemaker-hyperpod-scaling-slurm-create"></a>

**注意**  
準備生命週期組態指令碼，並將其上傳至執行角色可存取的 Amazon S3 儲存貯體。如需詳細資訊，請參閱[SageMaker HyperPod Slurm 叢集操作](sagemaker-hyperpod-operate-slurm.md)。

準備 JSON 格式的 `CreateCluster` API 請求檔案。將 `NodeProvisioningMode`設定為 ，`Continuous`並在每個執行個體群組的 `SlurmConfig` 欄位中提供 Slurm 拓撲資訊。

```
// create_cluster.json
{
    "ClusterName": "my-training-cluster",
    "NodeProvisioningMode": "Continuous",
    "Orchestrator": {
        "Slurm": {}
    },
    "InstanceGroups": [
        {
            "InstanceGroupName": "controller-group",
            "InstanceType": "ml.m5.xlarge",
            "InstanceCount": 1,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Controller"
            }
        },
        {
            "InstanceGroupName": "login-group",
            "InstanceType": "ml.m5.xlarge",
            "InstanceCount": 1,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Login"
            }
        },
        {
            "InstanceGroupName": "worker-gpu-a",
            "InstanceType": "ml.p5.48xlarge",
            "InstanceCount": 16,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Compute",
                "PartitionNames": ["gpu-training"]
            }
        }
    ],
    "VpcConfig": {
        "SecurityGroupIds": ["sg-12345678"],
        "Subnets": ["subnet-12345678"]
    }
}
```

執行 `create-cluster`命令以提交請求。

```
aws sagemaker create-cluster \
    --cli-input-json file://complete/path/to/create_cluster.json
```

這會傳回新叢集的 ARN。

```
{
    "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345"
}
```

## Slurm 組態管理
<a name="sagemaker-hyperpod-scaling-slurm-config"></a>

持續佈建僅以合併模式運作，以進行`slurm.conf`分割區管理。在合併模式中，HyperPod 會在您在 中修改的任何內容上附加套用其分割區組態變更`slurm.conf`。HyperPod 只會更新 的分割區相關區段 `slurm.conf`（例如分割區名稱和節點名稱項目）；不會修改其他 Slurm 組態參數。這表示：
+ `slurm.conf` 系統會保留您對 的手動編輯。
+ 修改與 HyperPod 預期狀態之間的衝突不會自動偵測或解決偏離。

連續佈建不支援 `SlurmConfigStrategy` 參數 (`Managed`、`Merge`、`Overwrite`)。傳遞任何`SlurmConfigStrategy`值會導致 API 錯誤。