[昇腾][MindX DL][白话系列]MindX DL集群调度组件介绍

前言

本文旨在用尽可能直白的语言对昇腾的MindX DL的集群调度组件做一个简单非官方的介绍，如有疑问欢迎留言讨论~！

这是第一期（完事开头难，中间难，最后也难…）

组件定位

官话：

MindX DL（昇腾深度学习组件）是支持 Atlas 800 训练服务器、Atlas 800 推理服务器的深度学习组件参考设计，提供昇腾 AI 处理器资源管理和记录、昇腾 AI 处理器优化调度、昇腾 AI 处理器故障诊断、分布式训练集合通信配置生成等基础功能，快速使能合作伙伴进行深度学习平台开发。

集群调度组件基于业界流行的集群调度系统Kubernetes，增加了昇腾AI处理器（下文出现的NPU表示昇腾AI处理器）的支持，提供昇腾AI处理器资源管理和查看、优化调度和分布式训练集合通信配置等基础功能。深度学习平台开发厂商可以有效减少底层资源调度相关软件开发工作量，快速使能合作伙伴基于MindX DL开发深度学习平台。

白话：

MindX DL集群调度组件是基于k8s生态而开发，适配昇腾NPU的一系列组件的总称。

接下来逐一介绍一下各组件的具体功能。

Ascend-Device-Plugin

当前K8S管理的硬件资源比较少，仅括CPU、内存和存储资源等，我们要想在K8S集群中使用昇腾NPU，就得先让K8S知道我们集群中有NPU资源，因此Ascend-Device-Plugin做的这样一个事，它会定期向K8S上报当前节点中设备的情况，让K8S知道，当前这个节点是有NPU可以使用的。

这样当有用户请求启动一个带NPU的任务（pod）时，K8S就会把相应的任务分配到相应的节点上，这个节点上的Ascend-device-plugin组件就会将这个任务和NPU进行一个绑定，从而让用户的任务能够使用NPU。

（注：这里其实是device-plugin先将信息上报给本节点的kubelet，然后由kubelet将设备信息上报给K8S集群，此处做了简略处理）

按道理，有了Ascend-device-plugin后，我就可以在集群中使用NPU了对不对，那还需要其他组件干什么呢？

有了Ascend-device-plugin后，确实可以在集群中使用NPU，但是会存在一些问题，比如我需要多个节点的NPU做联合计算，这种情况应该怎么搞？再比如，昇腾的部分NPU存在亲和性（关于亲和性请参考Atlas训练系列产品亲和性规则），应该如何根据亲和性分配这些卡？

因此，针对这些问题，我们还需要使用到下面的组件。

Volcano

Volcano是华为云开发的一款调度器，DL的Volcano是在其上面做的插件扩展。
前面说到，k8s能够对NPU进行调度分配，但是由于昇腾的NPU存在亲和性（具有亲和性的几个NPU做训练通信效率会更高），而K8S的分配是随机的，没有顾及昇腾的亲和性，所以就需要这样一款组件来高效的调度分配NPU。
以下发两卡训练任务为例，下图是k8s的kube-scheduler和Volcano调度两卡任务可能的情况：

图中的0-3卡具有亲和性，4-7卡具有亲和性。

Ascend-Operator/HCCL-Controller

当前我们的集群任务一般都是多机协同工作的，尤其是在训练大模型时，更需要多机联合计算，也称分布式计算。一旦需要分布式计算，就有一个绕不开的问题–通信。

这两个组件就是解决了集群内NPU任务通信的问题。
那这两个有什么区别呢？

HCCL-Controller是为训练任务所依赖的集合通讯配置（这个配置称为rank table，参考mindspore rank table方式启动），可以简单理解HCCL-Controller为NPU的任务提供了一个通讯录，里面有其他NPU的通讯地址。

Ascend-Operator为不同AI框架的分布式训练任务提供相应的环境变量，这个环境包含主训练进程的IP，这就可以理解为给不同的NPU任务提供了一个通信的中转站，每个NPU上的任务需要通信时，就去找这个中转站。

下面以两机8卡的分布式任务为例，简单描述下HCCL-Controller的作用：

NodeD

上述组件已经可以支持集群下发分布式任务了，但是存在一点问题，就是没法让集群知道某个节点的可用性，之前提到的Device-plugin只能及时上报芯片的健康状态，但是没法做到上报节点的情况，假如某个节点挂掉了，volcano不知道该节点还是否可以用。
于是为了解决这一问题，就引入了NodeD组件，当前该组件功能比较纯粹，就是定期给volcano汇报当前节点的状态。如果在一段时间内，volcano发现nodeD没有汇报了，volcano就认为该节点出问题了，volcano就不会把任务往该节点上调度了，如果该节点上面本身就有任务，那volcano就会为其重新找个节点，让其重新在新的节点上运行，也就是重调度。
如下图所示：

NPU-Exporter

运维监控也是集群内不可或缺的一块内容，NPU-Exporter就是基于Prometheus生态而开发的监控NPU状态的组件，在5.0.RC3版本后，NPU-Exporter还能够对接Telegraf，也就是一套组件兼容了两套监控体系。

Ascend-docker-runtime

以上组件都是围绕K8S开展的，那么另一个问题就来了，在只有Docker/containerd的场景下，应该怎么使用昇腾卡呢？
解决办法就是使用Ascend-docker-runtime，Ascend-docker-runtime是一款容器运行时插件，本质上是runC的插件，它可以帮助用户用极短的命令来启动一个绑定NPU的容器。
例如：

• 在不使用Ascend-docker-runtime，我如果希望启动一个8卡的容器，需要运行如下命令：

docker run -it --device=/dev/davinci0 --device=/dev/davinci1 --device=/dev/davinci2 --device=/dev/davinci3 --device=/dev/davinci4 --device=/dev/davinci5 --device=/dev/davinci6 --device=/dev/davinci7 --device=/dev/davinci_manager --device=/dev/hisi_hdc --device=/dev/devmm_svm -v /usr/local/dcmi:/usr/local/dcmi -v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi -v /usr/local/Ascend/driver/lib64:/usr/local/Ascend/driver/lib64 -v /usr/local/Ascend/driver/include:/usr/local/Ascend/driver/include ubuntu:18.04 bash

• 在使用Ascend-docker-runtime的情况下只需运行如下命令即可：

docker run -it -e ASCEND_VISIBLE_DEVICES=0-7 ubuntu:18.04 bash

有了Ascend-docker-runtime之后，Device-plugin也可以和Ascend-docker-runtime配合，帮助用户挂载驱动相关的文件和npu-smi工具。

以上就是对MindX DL组件的一个简单介绍，后续会更新组件的运行原理、安装步骤等。

最后展示下MindX DL组件的全局部署视图：

参考：
MindX DL组件资料