GPU-HPN拓撲感知調度 - Container Compute Service

GPU裝置的ACS叢集支援將多個GPU Pod調度到同一個GPU-HPN節點，Pod之間可以通過NVLink等方式實現GPU之間資料通訊。為了保障GPU裝置之間的通訊效率和公平性，ACS在裝置調度時會遵循不同機型的Partition約束。本文介紹ACS GPU的Partition調度機制以及使用情境案例。

前提條件

僅支援gpu-hpn計算類型（compute-class）的Pod和對應類型的節點。

背景介紹

節點中GPU裝置之間通過一條或多條通道相互串連通訊，ACS支援不同GPU規格的Pod在GPU-HPN節點上同時運行。為了保障GPU的通訊效率和公平性，避免Pod之間互相干擾，ACS會參考GPU的拓撲情況進行調度，針對不同的GPU數量需求劃為多個分區（Partition），為其分配最優結果。

下圖展示了一台8卡節點，每四張卡為一個分組，組內卡之間直通互聯，分組之間通過PCIe串連。

針對不同規格的Pod，ACS的Partition劃分如下。

Pod申請的GPU數量	可選的裝置分配結果
8	[0,1,2,3,4,5,6,7]
4	[0,1,2,3], [4,5,6,7]
2	[0,1], [2,3], [4,5], [6,7]
1	[0], [1], [2], [3], [4], [5], [6], [7]

隨著不斷有Pod在節點上建立刪除，GPU裝置可能出現Partition片段導致Pod Pending無法調度，您可以參考存量Pod的調度結果，結合業務優先順序情況驅逐部分Pod，以滿足Pending Pod的資源需求。

查詢GPU-HPN節點的Partition

ACS不同型號GPU-HPN節點的Partition情況和卡型有所不同。

gpu.p16en-16XL

共16張卡，卡型為P16EN，對於不同規格的Pod，具體情況如下。

Pod申請的GPU數量	可選的裝置分配結果
16	[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15]
8	[0,1,2,3,4,5,6,7], [8,9,10,11,12,13,14,15]
4	[0,1,2,3], [4,5,6,7], [8,9,10,11], [12,13,14,15]
2	[0,3], [1,2], [4,7], [5,6], [8,11], [9,10], [12,15], [13,14]
1	[0], [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15]

查詢Pod的調度結果

裝置分配結果

對於GPU-HPN類型的Pod，您可以在Pod Annotation中查看到裝置分配結果，格式如下。

apiVersion: v1
kind: Pod
metadata:
  annotations:
    alibabacloud.com/device-allocation: '{"gpus": {"minor": [0,1,2,3]}}'

Partition片段的調度失敗提示

當Pod不可調度時會處於Pending狀態，通過kubectl describe pod命令，可以看到類似0/5 nodes are available: xxx的資訊，其中Insufficient Partitioned GPU Devices表示節點因為裝置資源片段導致調度失敗，樣本如下。

kubectl describe pod pod-demo

預期輸出，省略其他內容：

...
Events:
  Type     Reason            Age    From               Message
  ----     ------            ----   ----               -------
  Warning  FailedScheduling  26m    default-scheduler  0/5 nodes are available: 2 Node(s) Insufficient Partitioned GPU Devices, 1 Node(s) xxx, 2 Node(s) xxx.

常見問題

如何規劃節點資源和策略，避免Partition片段？

根據業務Pod的GPU需求數量，為節點設定不同的分組標籤來管理資源，例如將8卡大任務和1卡小任務規划到不同的節點。
當叢集內出現因片段導致的Pending Pod時，可以利用重調度等機制，驅逐部分低優先順序的小任務，騰挪空閑資源供Pending Pod使用。
若節點規模較小或無法規劃分組標籤，且應用GPU規格繁雜，建議使用GPU Pod容量預留滿足應用資源需求。

解決Partition片段時如何選擇Pod驅逐

確定Pending Pod的資源規格，例如8卡。
查看目標Node中的Pod Annotation，從alibabacloud.com/device-allocation屬性中查看裝置分配結果。
根據分配結果確定待驅逐Pod，確保驅逐後的空閑裝置能夠滿足Pending Pod的資源需求和Partition約束，例如8卡的P16EN需求需要保證裝置編號[0,1,2,3,4,5,6,7]或[8,9,10,11,12,13,14,15]均未分配。
通過evict或delete等命令驅逐Pod。

使用自訂調度器時，關於Partition有哪些注意事項？

自訂調度器為Pod分配節點後，ACS會負責Pod在對應節點上的裝置分配，在裝置分配階段，ACS會盡量集中調度避免片段。

自訂調度器只需關注節點GPU整體容量，建議對於GPU資源優先採用Node集中調度策略（MostAllocated），可以有效減少Partition片段的出現。

各情境調度器對ACS GPU HPN的拓撲感知情況如何？

調度器類型	條件	說明
ACS預設調度器	同時滿足以下條件：叢集類型為ACS。 Pod的`schedulerName`為`default-scheduler`。未勾選開啟GPU-HPN節點自訂標籤、調度器。更多資訊，請參見kube-scheduler。	調度器會感知當前節點的Partition分配情況，對於Partition不滿足的節點不參與調度，對應原因為的提示資訊為“Insufficient Partitioned GPU Devices”，會體現在Pod調度失敗的事件中。
ACK調度器	同時滿足以下條件：叢集類型為ACK託管叢集、ACK One註冊叢集和ACK One分布式工作流程Argo叢集。 Pod的`schedulerName`為`default-scheduler`。	調度器不感知Partition拓撲關係，GPU-HPN節點側在分配裝置時會盡量集中分配，若Partition不滿足，會在節點側Pending，直至Parittion滿足後Pod才啟動，對應提示資訊中會包括“Insufficient Partitioned GPU Devices”。具體操作，請參見如何規劃節點資源和策略，避免Partition片段？。
自訂調度器	以下條件任意滿足其一：叢集不在以下類型之中：ACK託管叢集、ACK One註冊叢集和ACK One分布式工作流程Argo叢集。 Pod的`schedulerName`不為`default-scheduler`。	同ACK調度器情境。