本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 使用 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`后，集群将过渡到。
+ **跟踪进度**：监控每次实例启动尝试并记录状态。
+ **处理失败**：自动异步重试工作节点失败的启动。

默认情况下，持续预调配功能处于禁用状态。要使用此功能，请在`NodeProvisioningMode``CreateCluster`请求`Continuous`中设置为。

启用持续预调配功能后，您可以同时启动多个扩展操作，无需等待之前的操作完成。这使您能够同时扩展同一个集群中不同的实例组，并向同一个实例组提交多个扩展请求。

## 基于优先级的配置
<a name="sagemaker-hyperpod-scaling-slurm-priority"></a>

Slurm 集群需要控制器节点才能运行，然后工作节点才能注册和接受作业。持续资源调配通过基于优先级的资源调配自动处理此问题：

1. 首先配置控制器实例组。

1. 一旦一个控制器节点运行正常，登录节点和工作节点就会开始并行配置。

1. `InService`当一个控制器节点启动而一个登录节点已启动时（如果指定了登录实例组），则集群将过渡到。如果未指定登录实例组，则集群将在配置控制器节点后立即转换为。`InService`

1. 由于容量限制而无法立即配置的工作节点会进入异步重试循环，并在可用时自动添加到 Slurm 集群。

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

在创建集群期间，如果控制器节点无法配置，则行为取决于错误是可重试还是不可重试。

**可重试的错误**（例如，不健康的实例或暂时性故障）：
+ HyperPod 持续替换实例并重试配置，直到控制器启动为止。
+ 已经配置的工作节点和登录节点仍然可用，但是`InService`直到控制器运行状况良好，集群才会过渡到。

**不可重试的错误**（例如，控制器实例类型没有可用容量或生命周期脚本失败）：
+ 该群集被标记为`Failed`。
+ 您将收到失败原因的通知，并且必须采取纠正措施，例如选择不同的实例类型、修复生命周期脚本或在其他可用区重试。

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

持续配置要求通过每个实例组字段中的 API 负载提供 Slurm 配置参数（节点类型、分区名称）。`SlurmConfig`依赖于 Amazon S3 中旧`provisioning_parameters.json`文件的集群与持续配置不兼容。

**注意**  
Slurm 集群的持续配置目前不支持以下功能：迁移现有集群、通过基于 API 的 Slurm 拓扑进行多头节点配置，以及。`SlurmConfigStrategy`持续资源调配仅在合并模式下运行，便于`slurm.conf`管理。

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

HyperPod 具有持续预配功能的集群使用实例级计量来提供反映实际资源使用情况的准确账单。这种计量方法不同于传统的集群级别计费，它会对每个实例进行独立跟踪。

**实例级别计费**

利用持续预调配功能，计费将在单个实例级别开始和停止，而不是等待集群级别的状态变化。此方法具有以下优势：
+ **精准的计费准确性**：生命周期脚本开始执行时，开始计费。如果生命周期脚本失败，则将重试实例配置，并向您收取生命周期脚本运行时间的费用。
+ **独立计量**：每个实例的账单生命周期均单独管理，防止出现级联计费错误。
+ **实时账单更新**：计费从实例开始执行其生命周期配置脚本时开始，在实例进入终止状态时停止。

**计费生命周期**

 HyperPod 集群中的每个实例都遵循以下账单生命周期：
+ **计费开始**：当实例成功启动并开始执行其生命周期配置脚本时。
+ **继续计费**：在实例的整个运行生命周期内。
+ **计费停止**：当实例进入终止状态时，无论终止原因如何。

**注意**  
对于启动失败的实例，不会开始计费。如果因容量不足或其他问题导致实例启动失败，您无需为失败的尝试付费。计费在实例级别计算，费用将汇总并显示在集群的 Amazon 资源名称（ARN）下。

## 创建一个已启用持续预调配的集群
<a name="sagemaker-hyperpod-scaling-slurm-create"></a>

**注意**  
准备生命周期配置脚本并将其上传到您的执行角色可以访问的 Amazon S3 存储桶。有关更多信息，请参阅 [SageMaker HyperPod Slurm 集群操作](sagemaker-hyperpod-operate-slurm.md)。

准备一个 JSON 格式的 `CreateCluster` API 请求文件。设置`NodeProvisioningMode`为`Continuous`并在每个实例组的字段中提供 Slurm 拓扑信息。`SlurmConfig`

```
// 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 错误。