CN110471767B - 一种设备的调度方法 - Google Patents

Abstract

本披露公开了一种设备的调度方法，包括：确定单元设备的设备路径后，获取单元设备的设备唯一标识符，将设备路径和设备唯一标识符进行关联生成映射表，再根据设备路径查询设备健康信息，将设备唯一标识符和设备健康信息上传，当判定单元设备健康时，根据映射表确定单元设备的设备路径，进而***框架根据设备路径调取单元设备。通过本披露中的技术方案，实现了在***框架下，对物理机所挂载的多个单元设备进行调用和管理，提高了设备调用的灵活性。

Description

一种设备的调度方法

技术领域

本申请涉及人工智能的技术领域，具体而言，涉及一种设备的调度方法。

背景技术

Kubernetes是一种开源的容器编排引擎，该容器编排引擎用于管理云平台中多个主机上的容器化的应用，其目标是让部署容器化的应用简单并且高效。原生的该容器编排引擎仅支持对CPU和内存资源的管理和限制，但是在一些实际场景下，用户可能需要该容器编排引擎对自定义设备进行调度和管理。但是，对于每一种自定义设备来说，其驱动和设备管理方式***，通过修改该容器编排引擎源代码，以提供该容器编排引擎对自定义设备支持的方式，对用户来讲并不是一个好的解决方式。因此，该容器编排引擎提供了一种名为“device plugin”的设备插件机制，以实现该容器编排引擎对用户自定义设备的调度和管理支持。

异构加速设备，如机器学习单元、现场可编程门阵列以及图形加速设备等，是一种能够提供面向神经网络计算场景下的高性能计算加速设备，如机器学习单元(MachineLearning Unit，MLU)能够支持大部分机器学习算法和深度学习算法的计算。

而现有技术中，仅利用这种设备插件机制(device plugin)并不能够适用于该容器编排引擎(kubernetes)对云平台中异构加速设备的调度和管理，影响了异构加速设备在云平台中的运用。

发明内容

基于此，有必要针对上述技术问题，提供一种能够支持机器学习单元设备在kubernetes容器编排引擎的调度方法，调度方法适用于kubernetes框架，kubernetes框架连接有多个物理机，物理机上运行有设备插件，任一个物理机连接有多个机器学习单元，该调度方法包括：

步骤1，设备插件根据与所述物理机相连的机器学习单元的设备数量，确定机器学习单元的设备路径，并根据设备路径，获取机器学习单元的设备唯一标识符；

步骤2，设备插件将设备路径和设备唯一标识符关联，生成映射表，并根据设备路径调取机器学习单元中的设备健康信息，将映射表中的设备唯一标识符和设备健康信息上传至kubernetes框架；

步骤3，kubernetes框架判定设备健康信息正常时，设备插件根据映射表确定机器学习单元的设备路径，kubernetes框架根据设备路径调用机器学习单元。

本披露的有益效果是：

实现了在kubernetes***框架下，支持kubernetes容器引擎对多个机器学习单元的调用和管理，提高了设备调用的灵活性。

附图说明

本披露的上述和/或附加方面的优点在结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1是根据本披露的一个实施例的注册阶段的示意流程图；

图2是根据本披露的一个实施例的健康检查阶段的示意流程图；

图3是根据本披露的一个实施例的分配阶段的示意流程图；

图4是根据本披露的一个实施例的测试阶段的示意流程图。

具体实施方式

下面将结合本披露实施例中的附图，对本披露实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本披露一部分实施例，而不是全部的实施例。基于本披露中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本披露保护的范围。

还应当理解，在此本披露说明书中所使用的术语仅仅是出于描述特定实施例的目的，而并不意在限定本披露。如在本披露说明书和权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。还应当进一步理解，在本披露说明书和权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

在本实施例中，将kubernetes框架作为***框架，将机器学习单元作为单元设备，机器学习单元的设备路径是诸如mlu0，mlu1，mlu2，mlu3，...这样的设备序列，而设备唯一标识符是该机器学习单元的唯一身份标识，设备唯一标识符存储于内存中。

本实施例提供了一种设备的调度方法，该调度方法适用于kubernetes框架，支持机器学习单元设备在kubernetes容器编排引擎中的调度，

kubernetes框架连接有多个物理机，物理机上运行有设备插件，任一个物理机连接有多个机器学习单元。

为了注册mlu机器学习单元到kubernetes框架上，需要为mlu机器学习单元写一个device plugin插件程序作为设备插件，该设备插件运行在物理机上，device plugin插件程序可以通过使用grpc开源远端过程调用框架，与物理机中的kubelet(节点代理)执行程序通信，通过设备插件上报配置信息给kubernetes框架，进而实现mlu机器学习单元在kubernetes框架中的调用。本实施例中的调用方法，通过设备插件device plugin实现，该设备插件device plugin运行在物理机上。

需要说明的是，可以将本实施例中的mlu机器学习单元替换为其他异构加速设备，如专用集成电路(ASIC)、现场可编程门阵列(FPGA)和图形加速设备等。

在本实施例中，该调度方法包括：

步骤1，设备插件调用设备管理工具库，获取物理机上所连接的机器学习单元的设备数量，进而根据该设备数量，确定机器学习单元的设备路径，并根据设备路径，获取机器学习单元的设备唯一标识符。

具体地，对于kubernetes框架来说，受其管理的单元设备(机器学习单元)要求该单元设备的标识符在kubernetes框架中是全局唯一的，所以device plugin插件上报标识符给kubernetes框架，应该是机器学习单元所属的、由多个物理机构成的集群中、所有相同类型设备的唯一标识符。

在本实施例中，示出一种确定机器学习单元的设备路径的实现方式：

设备插件调用设备管理工具库，获得当前物理机下的机器学习单元总数n，并生成机器学习单元的设备序号；

通过机器学习单元驱动预定的设备路径命名规则，根据设备路径前缀和设备序号，生成设备路径。

例如，机器学习单元的序号是0，设备路径前缀为/dev/mlu，则生成的设备路径为：/dev/mlu0。

在本实施例中，采用Docker容器作为开源的应用容器引擎，利用kubernetes提供应用部署。对于Docker容器来讲，其挂载机器学习单元时，需要的是/dev/mlu目录下的设备路径，例如(/dev/mlu0)，该设备路径由设备数量确定，如果设备数量为n，则设备插件会生成/dev/mlu0,/dev/mlu1,...,/dev/mlu(n-1)这样的n个机器学习单元的设备路径。因此，需要在设备插件中，将设备路径和设备唯一标识符进行映射，但是由于机器学习单元的型号不同，存在尚未支持设备唯一标识符的机器学习单元，因此，在步骤1中获取机器学习单元的设备唯一标识符，具体包括：

步骤11，设备插件建立与机器学习单元之间的数据传输通道，并判断是否能够获取机器学习单元的设备唯一标识符，若不能够，执行步骤12，若能够，执行步骤13。

具体地，在该步骤中，如图1所示，由物理机上的设备插件device plugin与kubernetes框架进行通信，并调用设备管理工具库，获取机器学习单元的设备信息，判断机器学习单元是否支持设备唯一标识符获取，如果不支持，执行步骤12，否则，执行步骤13；

步骤12，根据随机生成函数，生成该机器学习单元的设备唯一标识符，其中，随机生成函数在go-uuid库中；

在本实施例的一种实现方式中，设备唯一标识符的随机生成函数可以为：DeviceGetUUID()(string,error)，返回值为string类型字符串，记作所述设备唯一标识符。该函数无输入参数。

步骤13，根据机器学习单元在物理机上的设备路径，调用设备管理工具库，采用查询方式，确定该机器学习单元的设备唯一标识符。

也就是说，对支持设备唯一标识符的机器学习单元，调用设备管理工具库，确定设备唯一标识符；而对于尚未支持设备唯一标识符的机器学习单元，利用随机生成函数，为该机器学习单元随机生成一个设备唯一标识符，通过上述方法，可以保证与物理机相连的机器学习单元，均对应于一个设备唯一标识符。

由于不同代的机器学***台采用现有的设备插件机制进行调用时，在物理机连接不同代的机器学***台的调用往往导致物理机的宕机，使得物理机无法正常运行，而采用本实施例中的调用方法进行调用时，针对不支持设备唯一标识符的机器学***台)，由kubernetes框架完成对机器学习单元的调取。

步骤2，设备插件将设备路径和设备唯一标识符关联，生成映射表，并根据设备路径调取机器学习单元中的设备健康信息，将映射表中的设备唯一标识符和设备健康信息，上传至kubernetes框架；

具体地，物理机中的设备插件，在获取所有机器学习单元的设备路径和设备唯一标识符之后，会将设备路径和设备唯一标识符进行映射，即当前节点(物理机)的单元设备(机器学习单元)的唯一标识符和设备路径存入映射表，该映射表存储于设备插件中，以映射表的形式将这种映射进行保存，通过这种方式，可以保证不会因为个别机器学习单元的不正常状态，导致当前物理机下的所有机器学习单元均无法正常工作。

通过上述步骤2中生成的映射表，完成机器学习单元在kubernetes框架中的注册，在设备插件向kubernetes框架发送设备唯一标识符和设备健康信息时，这些信息以kuberentes框架的device plugin机制中的接口定义文件proto中的RegisterRequest接口实现。

该步骤2中，物理机上的设备插件根据设备路径调取设备管理工具库，获取机器学习单元中的设备健康信息，具体包括：

根据预设轮询周期，物理机上的设备插件调用设备管理工具库提供的接口函数，设备管理工具库根据设备路径，获取物理机所连接的机器学习单元的设备健康信息，其中，设备管理工具库提供的接口函数可以为：DeviceHealthCheckState(deviceLocalID int,delayTime int)(int,error)。

具体地，如图2所示，先由kubernetes框架调用设备插件的健康检查接口，再由设备插件调用设备管理工具库的健康检查接口，设备插件查询映射表，获取当前节点所有设备唯一标识符。

设备管理工具库获取设备健康标识寄存器的值，设备管理工具库根据该寄存器的值为设备插件返回设备健康信息，返回设备唯一标识符及其健康信息。

该设备管理工具库接口函数的输入参数deviceLocalID表示机器学习单元在物理机上的设备序号0,1,…n-1，delayTime表示查询机器学习单元健康状态的时间间隔。该函数返回int型变量，表示设备的健康状态，如：(0,nil)，其中，0为健康，其余值为不健康。

通过设备插件调取设备管理工具库中评估设备健康状态的接口函数，该设备插件将会单独创建一个协程，根据预设轮询周期，轮询设备插件所属物理机下所有mlu机器学习单元的健康状态。

当有某些mlu机器学习单元出现问题时，设备插件会将这些不健康机器学习单元的健康状态置为不健康，并在下一次kubernetes框架调用设备插件程序的ListAndWatchgrpc接口时，将这些不健康机器学习单元的信息发送至kubernetes框架，这样kubernetes框架便可以感知这些不健康机器学习单元的存在，停止对这些不健康机器学习单元的调度。

步骤3，kubernetes框架判定设备健康信息正常时，设备插件根据映射表确定机器学习单元的设备路径，kuberentes框架根据设备路径调用机器学习单元。

进一步地，kubernetes框架判定所述设备健康信息正常的方法具体包括：

kubernetes框架接收设备插件发送的grpc消息；

读取grpc消息的返回信息中的healthy字段，当判定healthy字段为true时，判定设备健康信息正常。

在本实施例中，提供一种判定所述设备健康信息正常时，设备插件根据映射表，确定机器学习单元的设备路径的方式，具体包括：

设备插件调用设备管理工具库提供的int cndevGetDeviceCount()函数，其中，该函数返回int型值，代表当前节点机器学习单元数量，获得当前物理机下的机器学习单元设备总数n，然后根据总数n生成0,1,2...(n-1)个设备序号；

通过机器学习单元驱动预定的设备路径命名规则，根据设备路径前缀和设备序号，生成当前物理机上所有的单元设备的设备路径。

例如，机器学习单元的序号是0，设备路径前缀为/dev/mlu，则生成的设备路径为：/dev/mlu0。

具体地，如图3所示，kubernetes框架向机器学习单元传回分配(生成)的设备唯一标识符，设备插件向kubernetes框架返回要挂载的设备列表，通过Docker容器挂载mlu设备，实现mlu设备的调用。

为了方便用户使用cambricon-k8s-device-plugin，通过构建包含cambricon-k8s-device-plugin可执行文件的docker镜像，以及在kubernetes框架上布置该镜像到每个Worker节点的yaml文件，用户可以使用这样的yaml文件和docker镜像，通过kubectl命令，一键部署到kubernetes框架上所有含有mlu机器学习单元的Worker节点上。同样，用户可以使用kubectl解析提供的pod-example.yml文件，用作生产环境下cambricon-k8s-device-plugin布置是否成功的参考依据。

优选地，在本实施例中还包括：

当kubernetes框架接收到框架重启指令时，所述设备插件将检测到所述kubernetes框架的重启，并在所属kubernetes框架重启结束后重新连接至所述kubernetes框架。

在本实施例的又一种实现方式中，该调度方法还包括：

当机器学习单元与物理机断开连接时，由设备插件负责调用设备管理工具库的Release函数，释放机器学习单元设备占用的***资源。该函数接口为：voidcndevRelease_dl(),无返回值和输入参数。

优选地，该调度方法还包括：

设备插件调用测试桩工具库，并根据设备路径对机器学习单元进行测试。

为了保证plugin能在生产环境中稳定的工作，通过设计了一系列的测试用例，以覆盖了***可能遇到的工况。同时，为方便设备管理工具库和plugin的并行开发以及测试用例覆盖的比例，设计开发了名为mock-dev的桩工具库。mock-dev是一种可以通过修改动态加载的配置文件的方式模拟当前节点所有设备工作状态的桩工具库。

如图3所示，本实施例给出一种在kubernetes框架下的机器学习单元测试方法。

步骤31，开发人员将设备插件的设备管理工具库链接为mock-dev工具库，此时，无需配置真实板卡。

步骤32，用户编写将要虚拟的设备信息的mock-dev配置文件，即通过mock-dev工具库，测试时替换掉管理真实设备的设备管理工具库，可以在脱离真实物理板卡的虚拟环境中模拟cambricon-k8s-device-plugin在大规模集群的工作状态；也可以模拟某个mlu设备健康突然变为不正常的这种对真实板卡有损的情况。其中，配置文件包括设备数量、设备路径、设备健康状态。

步骤33，利用mock-dev读入上述配置文件中的信息，并将上述信息传回给设备插件；

步骤34，当判定开发人员在运行时更改配置文件时，mock-dev实时将虚拟出来的设备信息返回给设备插件。

通过自定义设备数量和信息，可以辅助排查集成测试中的***性Bug。综上，mock-dev增强了开发的灵活性，扩大了测试用例的覆盖范围。

为了验证本实施例中所涉及的调度方法，设定测试集群由三台物理机组成，一台是Master节点，两台是Worker节点，所有的Worker节点的kubelet执行程序均开启DevicePlugins feature Gate。设备驱动及设备管理工具库更新至支持mlu机器学习单元进行健康检查的稳定版本。

通过布置多个挂载不同数量机器学习单元的方式，测试能否将节点机器学习单元的信息正确上报给kubernetes框架，并使kubernetes框架做出正确的调度行为。Worker节点机器学习单元总数为4，测试部分结果如表1所示。

表1

通过表1中的结果可以看出，采用本实施例中的调度方法，能够正确上报当前节点的机器学习单元信息至kubernetes框架，且kubernetes框架根据上报的信息也做出了正确的调度。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本披露并不受所描述的动作顺序的限制，因为依据本披露，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本披露所必须的。

进一步需要说明的是，虽然图1-4的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1-4中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与所述其他步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。上述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

依据以下条款可更好地理解前述内容：

条款A1，一种设备的调度方法，其特征在于，所述调度方法适用于***框架对单元设备的调用，所述***框架连接有多个物理机，任一个所述物理机连接有多个所述单元设备，所述物理机上运行有设备插件，该调度方法包括：

步骤1，所述设备插件根据与所述物理机相连的所述单元设备的设备数量，确定所述单元设备的设备路径，并根据所述设备路径，获取所述单元设备的设备唯一标识符；

步骤2，所述设备插件将所述设备路径和所述设备唯一标识符关联，生成映射表，并调用设备管理工具库，根据所述设备路径获取所述单元设备的设备健康信息，将所述设备唯一标识符和所述设备健康信息发送至所述***框架；

步骤3，所述***框架判定所述设备健康信息正常时，所述设备插件根据所述映射表确定所述单元设备的设备路径，所述***框架根据所述设备路径调用所述单元设备。

条款A2，根据条款A1所述的方法，所述***框架为kubernetes框架，所述单元设备为机器学习单元。

条款A3，根据条款A1所述的方法，所述映射表存储于所述设备插件。

条款A4，根据条款A2所述的方法，步骤1中获取所述单元设备的设备唯一标识符，具体包括：

步骤11，所述设备插件建立与所述机器学习单元之间的数据传输通道，并判断是否能够获取所述机器学习单元的设备唯一标识符，若不能够，执行步骤12，若能够，执行步骤13；

步骤12，根据随机生成函数，生成所述机器学习单元的所述设备唯一标识符；

步骤13，根据所述设备路径，确定该机器学习单元的所述设备唯一标识符。

条款A5，根据条款A2所述的方法，步骤2中，所述设备插件调用所述设备管理工具库，根据所述设备路径获取所述机器学习单元的所述设备健康信息，具体包括：

根据预设轮询周期，所述设备插件调用所述设备管理工具库提供的接口函数，所述设备管理工具库根据所述设备路径，获取所述设备健康信息。

条款A6，根据条款A2所述的方法，步骤3中，所述kubernetes框架判定所述设备健康信息正常的方法具体包括：

所述kubernetes框架接收所述设备插件发送的grpc消息；

读取所述grpc消息的返回信息中的healthy字段，当判定所述healthy字段为true时，判定所述设备健康信息正常。

条款A7，根据条款A2所述的方法，步骤1中，确定所述单元设备的设备路径的步骤包括：

所述设备插件调用所述设备管理工具库，获得所述物理机连接的所述机器学习单元总数n，并生成所述机器学习单元的设备序号；

通过所述机器学习单元驱动预定的设备路径命名规则，根据设备路径前缀和所述设备序号，生成所述设备路径。

条款A8，根据条款A2所述的方法，该调度方法还包括：

当所述kubernetes框架接收到框架重启指令时，所述设备插件将检测到所述kubernetes框架的重启，并在所述kubernetes框架重启结束后重新连接至所述kubernetes框架。

条款A9，根据条款A2至A8中任一项所述的方法，该调度方法还包括：

当所述机器学习单元与所述物理机断开连接时，释放所述机器学习单元占用的***资源。

条款A10，根据条款A9所述的方法，该调度方法还包括：

所述设备插件调用测试桩工具库，并根据所述设备路径对所述机器学习单元进行测试。

以上对本披露实施例进行了详细介绍，本文中应用了具体个例对本披露的原理及实施方式进行了阐述，以上实施例的说明仅用于帮助理解本披露的方法及其核心思想。同时，本领域技术人员依据本披露的思想，基于本披露的具体实施方式及应用范围上做出的改变或变形之处，都属于本披露保护的范围。综上所述，本说明书内容不应理解为对本披露的限制。

Claims (9)

1.一种设备的调度方法，其特征在于，所述调度方法适用于kubernetes***框架对单元设备的调用，所述kubernetes***框架连接有多个物理机，任一个所述物理机连接有多个所述单元设备，所述单元设备为机器学习单元，所述物理机上运行有设备插件，该调度方法包括：

步骤1，所述设备插件根据与所述物理机相连的所述单元设备的设备数量，确定所述单元设备的设备路径，并根据所述设备路径，获取所述单元设备的设备唯一标识符；

步骤2，所述设备插件将所述设备路径和所述设备唯一标识符关联，生成映射表，并调用设备管理工具库，根据所述设备路径获取所述单元设备的设备健康信息，将所述设备唯一标识符和所述设备健康信息发送至所述***框架；

步骤3，所述***框架判定所述设备健康信息正常时，所述设备插件根据所述映射表确定所述单元设备的设备路径，所述***框架根据所述设备路径调用所述单元设备。

2.如权利要求1所述的设备的调度方法，其特征在于，所述映射表存储于所述设备插件。

3.如权利要求1所述的设备的调度方法，其特征在于，步骤1中获取所述单元设备的设备唯一标识符，具体包括：

步骤11，所述设备插件建立与所述机器学习单元之间的数据传输通道，并判断是否能够获取所述机器学习单元的设备唯一标识符，若不能够，执行步骤12，若能够，执行步骤13；

步骤12，根据随机生成函数，生成所述机器学习单元的所述设备唯一标识符；

步骤13，根据所述设备路径，确定该机器学习单元的所述设备唯一标识符。

4.如权利要求1所述的设备的调度方法，其特征在于，步骤2中，所述设备插件调用所述设备管理工具库，根据所述设备路径获取所述机器学习单元的所述设备健康信息，具体包括：

根据预设轮询周期，所述设备插件调用所述设备管理工具库提供的接口函数，所述设备管理工具库根据所述设备路径，获取所述设备健康信息。

5.如权利要求1所述的设备的调度方法，其特征在于，步骤3中，所述kubernetes框架判定所述设备健康信息正常的方法，具体包括：

所述kubernetes框架接收所述设备插件发送的grpc消息；

读取所述grpc消息的返回信息中的healthy字段，当判定所述healthy字段为true时，判定所述设备健康信息正常。

6.如权利要求1所述的设备的调度方法，其特征在于，步骤1中，确定所述单元设备的设备路径的步骤包括：

所述设备插件调用所述设备管理工具库，获得所述物理机连接的所述机器学习单元总数n，并生成所述机器学习单元的设备序号；

通过所述机器学习单元驱动预定的设备路径命名规则，根据设备路径前缀和所述设备序号，生成所述设备路径。

7.如权利要求1所述的设备的调度方法，其特征在于，该调度方法还包括：

当所述kubernetes框架接收到框架重启指令时，所述设备插件将检测到所述kubernetes框架的重启，并在所述kubernetes框架重启结束后重新连接至所述kubernetes框架。

8.如权利要求1至7中任一项所述的设备的调度方法，其特征在于，该调度方法还包括：

当所述机器学习单元与所述物理机断开连接时，释放所述机器学习单元占用的***资源。

9.如权利要求8所述的设备的调度方法，其特征在于，该调度方法还包括：

所述设备插件调用测试桩工具库，并根据所述设备路径对所述机器学习单元进行测试。

Images