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

# 政策
<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 會優先存取未使用的資源，因為其中的任務排程早於團隊 B。
+ **任務先佔**：根據優先順序從任務接管運算。根據預設，租用閒置運算的團隊會優先取代來自其他團隊的任務。
+ **借出和借用**：團隊如何借出閒置運算，以及團隊是否可以向其他團隊借用。
  + 以**百分比為基礎的借用限制**：允許團隊借用的閒置運算限制，以其保證配額的百分比表示。團隊最多可借用 10，000% 的已配置運算。您在此處提供的值會解譯為百分比。例如，500 的值將解譯為 500%。此百分比可統一套用至團隊配額中的所有資源類型 (CPU、GPU、記憶體） 和執行個體類型。
  + **絕對借用限制**：允許團隊借用的閒置運算限制，定義為每個執行個體類型的絕對資源值。這可讓您精細控制特定執行個體類型的借用行為。您需要使用與**運算配額**相同的結構描述來指定絕對限制，包括執行個體計數、加速器、vCPU、記憶體或加速器分割區。您可以在團隊的配額中指定一或多個執行個體類型的絕對限制。

如需如何使用這些概念的資訊，例如優先順序類別和命名空間，請參閱[HyperPod 任務控管 AWS 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 會持續監控您的叢集狀態，並隨著時間自動更新至正確的組態。

**初始設定**
+ 當您在 ClusterSchedulerConfig `Enabled`中`IdleResourceSharing`將 設定為 （預設為 `Disabled`) 時，HyperPod 任務控管會開始監控叢集，並透過從總節點容量減去團隊配額來計算可用的閒置資源。
+ 建立未配置的資源共用 ClusterQueues以代表可借用的資源集區。
+ 當您第一次啟用未配置的資源共用時，基礎設施設定需要幾分鐘的時間。您可以透過政策和 ClusterSchedulerConfig `Status``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) 分割`success`的 GPU 節點，`nvidia.com/mig.config.state`標籤必須顯示為節點提供 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)