本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
策略
Amazon SageMaker HyperPod 任务管理简化了您的 Amazon EKS 集群资源的分配方式以及任务优先级的排列方式。以下内容提供有关 HyperPod EKS 集群策略的信息。有关如何设置任务管理的信息，请参阅任务管理设置。
这些策略分为计算优先级划分和计算分配。以下政策概念将在这些政策的背景下进行整理。
计算优先级或集群策略决定了如何借用闲置计算以及团队如何确定任务的优先级。
-
空闲计算分配定义了如何在团队之间分配闲置计算。也就是说，如何从团队那里借用未使用的计算。选择空闲计算分配时，可以在以下选项中进行选择：
-
先到先得：应用后，团队不会优先考虑彼此，每个即将到来的任务都同样有可能获得超额配额的资源。根据提交顺序对任务进行优先排序。这意味着，如果用户先提出请求，他们可能能够使用 100% 的空闲计算。
-
公平共享：应用时，团队会根据分配的公平份额权重借用闲置计算。这些权重在计算分配中定义。有关如何使用它的更多信息，请参阅共享闲置计算资源示例。
-
-
任务优先级划分定义了计算可用时任务的排队方式。选择任务优先级时，可以在以下选项中进行选择：
-
先到先得：应用任务后，按请求的顺序排队。
-
任务等级：应用任务后，按优先级定义的顺序排队。如果选择此选项，则必须添加优先级类别以及应按其优先级排序的权重。相同优先级的任务将按先到先得的原则执行。在 “计算分配” 中启用后，团队中优先级较高的任务将抢占优先级较低的任务。
当数据科学家向集群提交作业时，他们使用 YAML 文件中的优先级类名。优先级类别的格式为
priority-class-name-priority -
优先级类别：这些类别为借用容量时任务确定相对优先级。当任务使用借用的配额运行时，如果传入的任务没有更多可用容量，则该任务可能会被优先级高于该任务的另一个任务抢占。如果在计算分配中启用了抢占功能，则优先级较高的任务也可能抢占自己团队中的任务。
-
计算分配或计算配额定义了团队的计算分配以及为公平共享空闲计算分配赋予团队的权重（或优先级）。
-
球队名称：球队名称。将创建一个相应的命名空间，其类型为
hyperpod-ns-。team-name -
成员：团队命名空间的成员。您需要为想要加入该团队的数据科学家用户设置基于角色的 Kubernetes 访问控制 (RBAC)，以便在使用 Amazon EKS 编排的集群 HyperPod上运行任务。要设置 Kubernetes RBAC，请按照创建团队角色中的说明进行操作。
-
公平份额权重：这是在空闲计算分配中应用公平份额时分配给团队的优先级别。最高优先级的权重为 100，最低优先级的权重为 0。权重越高，团队就可以更快地访问共享容量内未使用的资源。零权重表示优先级最低，这意味着与其他球队相比，这支球队将始终处于不利地位。
在与其他队伍争夺可用资源时，公平份额权重为这支球队提供了比较优势。录取优先考虑权重最高和借款最少的团队安排任务。例如，如果团队 A 的权重为 10，团队 B 的权重为 5，则团队 A 将优先访问未使用的资源，因为任务安排的时间早于团队 B。
-
任务抢占：根据优先级从任务中接管计算。默认情况下，借出闲置计算的团队将抢占其他团队的任务。
-
借出和借用：团队如何借出闲置计算，以及团队是否可以向其他团队借用。
-
借用限制：允许团队借用的空闲计算上限。一个团队最多可以借用已分配计算的 500%。您在此处提供的值被解释为百分比。例如，值为 500 将被解释为 500%。
-
有关如何使用这些概念（例如优先级类和命名空间）的信息，请参阅 HyperPod 任务管理 Amazon CLI 命令示例。
共享闲置计算资源示例
为确保适当的配额管理，总预留配额不应超过集群为该资源提供的可用容量。例如，如果集群包含 20 个ml.c5.2xlarge实例，则分配给团队的累积配额应保持在 20 以下。
如果团队的计算分配策略允许 “借入和借用” 或 “借用”，则闲置容量将在这些团队之间共享。例如，团队 A 和团队 B 已启用借贷功能。A队的配额为6个，但只使用2个作为任务，而B队的配额为5个，正在使用4个来完成任务。提交给团队 B 的作业，需要 4 个资源。3 个将从团队 A 那里借用
如果任何团队的计算分配策略设置为 “不借出”，则除了自己的分配之外，该团队将无法借用任何其他容量。
要维护一个或一组可供所有团队借用的资源，您可以组建一个专门的团队，其资源可以弥合其他团队的分配与集群总容量之间的差距。确保此累积资源分配包括相应的实例类型，并且不超过群集的总容量。为确保这些资源可以在团队之间共享，请允许参与的团队将此公共资源池的计算分配设置为 “借入和借用” 或 “借出”。每次引入新团队、更改配额分配或集群容量发生任何变化时，请重新审视所有团队的配额分配，并确保累积配额保持在或低于集群容量。