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

# 策略
<a name="sagemaker-hyperpod-eks-operate-console-ui-governance-policies"></a>

Amazon SageMaker HyperPod 任务管理简化了您的 Amazon EKS 集群资源的分配方式以及任务优先级的排列方式。以下内容提供有关 HyperPod EKS 集群策略的信息。有关如何设置任务治理的信息，请参阅[任务治理设置](sagemaker-hyperpod-eks-operate-console-ui-governance-setup-task-governance.md)。

这些策略分为**计算资源优先级**和**计算资源分配**。以下策略概念将围绕这些策略的框架进行整理。

**计算资源优先级**（又称集群策略）决定了空闲计算资源的借入方式，以及团队为任务设置优先级的方式。
+ **空闲计算资源分配**定义在团队间分配空闲计算资源的方式。也就是说，如何从团队处借入未使用的计算资源。选择**空闲计算资源分配**时，可以在以下选项中进行选择：
  + **先到先得**：应用此选项后，团队之间不进行优先级区分，并且每个传入任务获得超额配额资源的概率均等。根据提交顺序设定任务的优先级。这意味着，如果用户最先提出申请，就有可能使用 100% 的空闲计算资源。
  + **公平共享**：应用此选项时，团队将根据其分配到的**公平共享权重**借入空闲计算资源。这些权重是在**计算资源分配**中定义的。有关其使用方式的更多信息，请参阅[共享空闲计算资源示例](#hp-eks-task-governance-policies-examples)。
+ **任务优先级**定义任务在计算资源可用时的排队方式。选择**任务优先级**时，可以在以下选项中进行选择：
  + **先到先得**：应用此选项时，按任务的请求顺序对任务排队。
  + **任务排名**：应用此选项时，按任务优先级所定义的顺序对任务排队。如果选择此选项，则必须添加优先级类以及这些优先级类应遵循的权重排序规则。相同优先级类的任务将按先到先得的原则执行。在“计算资源分配”中启用此选项后，团队内部优先级较高的任务会抢占优先级较低的任务的资源。

    当数据科学家向集群提交作业时，他们会在 YAML 文件中使用优先级类名称。优先级类的格式为 `{{priority-class-name}}-priority`。有关示例，请参阅[向 SageMaker AI 管理的队列和命名空间提交作业](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md#hp-eks-cli-start-job)。
  + **优先级类**：这些类为借用容量时任务确定相对优先级。当任务使用借入的配额运行时，如果传入任务无可用容量，该任务可能会被优先级高于它的其他任务抢占资源。如果在**计算资源分配**中启用**抢占**选项，则优先级较高的任务也可能抢占其团队内部任务的资源。
+ **未分配的资源共享**使团队能够借用未通过计算配额分配给任何团队的计算资源。启用后，未分配的集群容量将可供团队自动借用。有关更多信息，请参阅 [未分配资源共享的工作原理](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works)。

**计算资源分配**（又称计算资源配额）定义了团队的计算资源分配，以及在公平共享空闲计算资源分配中为团队设定的权重（或优先级级别）。
+ **团队名称**：团队的名称。将创建一个类型为 `hyperpod-ns-{{team-name}}` 的相应的**命名空间**。
+ **成员**：团队命名空间的成员。您需要为想要加入该团队的数据科学家用户设置基于角色的 Kubernetes 访问控制 (RBAC)，以便在使用 Amazon EKS 编排的集群 HyperPod上运行任务。要设置 Kubernetes RBAC，请按照[创建团队角色](https://github.com/aws/sagemaker-hyperpod-cli/tree/main/helm_chart#5-create-team-role)中的说明进行操作。
+ **公平共享权重**：在对**空闲计算资源分配**应用**公平共享**时，这是为团队分配的优先级级别。最高优先级的权重为 100，最低优先级的权重为 0。权重越高，团队在共享容量内获取未使用资源的速度就越快。权重为零表示最低优先级，这意味着与其他团队相比，该团队将始终处于不利地位。

  公平共享权重可让该团队在与其他团队竞争可用资源时获得相对优势。准入机制会优先调度权重最高且资源借入量最少的团队所提交的任务。例如，如果团队 A 的权重为 10，团队 B 的权重为 5，则团队 A 在获取未使用资源时将拥有优先权，也就是说，团队 A 的作业会比团队 B 的作业更早被调度。
+ **任务抢占**：计算资源会依据优先级从某个任务中被接管。默认情况下，借出空闲计算资源的团队会抢占其他团队的任务资源。
+ **借出和借入**：团队如何借出空闲计算资源，以及团队是否能从其他团队借入空闲计算资源。
  + **基于百分比的借用限制**：允许团队借用的闲置计算上限，以其保证配额的百分比表示。一个团队最多可以借用 10,000% 的已分配计算量。您在此处提供的数值将被解读为百分比。例如，数值 500 将被解读为 500%。该百分比统一适用于团队配额中的所有资源类型（CPU、GPU、内存）和实例类型。
  + **绝对借用限制**：允许团队借用的空闲计算上限，定义为每种实例类型的绝对资源值。这为特定实例类型的借用行为提供了精细控制。您需要使用与**计算配额**相同的架构来指定绝对限制，包括实例数、加速器、vCPU、内存或加速器分区。您可以在团队的配额中为一个或多个实例类型指定绝对限制。

有关如何使用这些概念（例如优先级类和命名空间）的信息，请参阅[HyperPod 任务管理 Amazon CLI 命令示例](sagemaker-hyperpod-eks-operate-console-ui-governance-cli.md)。

## 共享空闲计算资源示例
<a name="hp-eks-task-governance-policies-examples"></a>

总预留配额不应超过集群中该资源的可用容量，以确保正常管理配额。例如，如果一个集群包含 20 个 `ml.c5.2xlarge` 实例，则分配给各个团队的累计配额应保持在 20 个以下。

如果团队的**计算资源分配**策略允许**借出和借入**或**借出**，则这些团队之间将共享空闲容量。例如，团队 A 和团队 B 已启用**借出和借入**。团队 A 的配额为 6，但当前仅将 2 个资源用于其作业；团队 B 的配额为 5，当前将 4 个资源用于其作业。向团队 B 提交的一个作业需要 4 个资源，其中 3 个资源将从团队 A 借入。

如果任意团队的**计算资源分配**策略设置为**不借出**，则该团队无法借入超出自身配额的额外容量。

## 未分配资源共享的工作原理
<a name="sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works"></a>

未分配的资源共享会自动管理未分配给集群中任何计算配额的资源池。这意味着 HyperPod 持续监控您的集群状态，并随着时间的推移自动更新到正确的配置。

**初始设置**
+ 当您在`Enabled`中设置`IdleResourceSharing`为 ClusterSchedulerConfig （默认情况下为`Disabled`）时， HyperPod 任务管理将开始监控您的集群，并通过从节点总容量中减去团队配额来计算可用的闲置资源。
+ 创建未分配的资源共享 ClusterQueues 是为了表示可借用的资源池。
+ 首次启用未分配资源共享时，基础架构设置需要几分钟。您可以通过策略`Status`来监控进度 ClusterSchedulerConfig。`DetailedStatus`

**正在进行的对账**
+ HyperPod 任务治理会持续监控诸如节点添加或移除以及集群队列配额更新之类的更改。
+  发生更改时，未分配的资源共享会重新计算配额并进行更新。 ClusterQueues协调通常会在几秒钟内完成。

**监控**

 您可以通过检查未分配的资源共享来验证未分配的资源共享是否已完全配置： ClusterQueues

```
kubectl get clusterqueue | grep hyperpod-ns-idle-resource-sharing
```

当你看到类似 ClusterQueues 的名字时`hyperpod-ns-idle-resource-sharing-cq-1`，未分配的资源共享处于活动状态。请注意， ClusterQueues可能存在多个未分配的资源共享，具体取决于群集中的资源规格数量。

## 未分配资源共享的节点资格
<a name="sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-node-eligibility"></a>

未分配的资源共享仅包括满足以下要求的节点：

1. **节点就绪状态**
   + 节点必须处于`Ready`状态才能为未分配的资源池做出贡献。
   + 容量计算中不包括处于`NotReady`或其他未就绪状态的节点。
   + 当一个节点变为时`Ready`，它会自动包含在下一个协调周期中。

1. **节点可调度状态**
   + 带有的节点`spec.unschedulable: true`将排除在未分配的资源共享之外。
   + 当一个节点再次变为可调度状态时，它会自动包含在下一个协调周期中。

1. **MIG 配置（仅限 GPU 节点）**
   + 对于具有 MIG（多实例 GPU）分区的 GPU 节点，必须显示`nvidia.com/mig.config.state`标签，该节点才能`success`将 MIG 配置文件贡献给未分配的资源共享。
   + MIG 配置成功完成后，将自动重试这些节点。

1. **支持的实例类型**
   + 该实例必须是支持的 SageMaker HyperPod 实例类型。
   + 查看集 SageMaker HyperPod 群中支持的实例类型列表。

**Topics**
+ [共享空闲计算资源示例](#hp-eks-task-governance-policies-examples)
+ [未分配资源共享的工作原理](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-how-it-works)
+ [未分配资源共享的节点资格](#sagemaker-hyperpod-eks-operate-console-ui-governance-policies-idle-resource-sharing-node-eligibility)
+ [创建策略](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-create.md)
+ [编辑策略](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-edit.md)
+ [删除策略](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-delete.md)
+ [在 Amazon SageMaker HyperPod 任务管理中分配计算配额](sagemaker-hyperpod-eks-operate-console-ui-governance-policies-compute-allocation.md)