GPU-HPN拓扑感知调度_容器计算服务(ACS)-阿里云帮助中心

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调度器场景。