总21期
Solution    方案
Solution    方案
5G MEC算力资源的智能调配
文/孔波
分享

摘要:边缘计算将原本完全由云计算中心节点处理的大型服务加以分解,切割成更小的和更容易管理的小块服务,分散到边缘节点去处理。为了支持这种计算架构,原来云计算数据中心算力资源的集中调度方案需要被调整以适应边缘计算场景。

云计算,是在数据中心集中了大量的算力资源进行集中调度,通过共享电源、散热、通信网络等基础设施,以经过优化后的规模优势来大幅降低算力资源的使用成本。在智能设备和联网设备的增长大潮下,数据中心的数据传输、信息获取、带宽资源越来越捉襟见肘,集中化的云计算已经逐渐不能满足时代的需求。

边缘计算,是一种分散式运算的架构。边缘计算将原本完全由云计算中心节点处理的大型服务加以分解,切割成更小的和更容易管理的小块服务,分散到边缘节点去处理。为了支持这种计算架构,原来云计算数据中心算力资源的集中调度方案,需要调整以适应边缘计算场景。

从MEC到 5G MEC

MEC (Mobile Edge Computing,移动边缘计算) 是利用蜂窝通信的RAN无线接入网络(Radio A access Network),为电信用户就近提供IT服务和云端计算功能,最终形成一个高带宽、低延时、高性能的电信级服务网络。为避免移动承载网络被管道化,电信标准组织和电信运营们研究了如何深入融合移动互联网、物联网业务,将计算能力下沉到移动边缘节点的方案,以节省带宽算力资源,改善用户体验。

在大量结合了现有电信网络运营商的基础设施以后,MEC移动边缘计算的概念发生了蜕变,变成 MEC多接入边缘计算(Multi access Edge Computing) 的新网络架构。

MEC = 多接入 + 近地分流 + 资源开放 :

1. 多接入 (Multi Access)

用户其实并不太在意接入手段,4G也好,5G也好,Wi-Fi也行,甚至可以是固网接入,用户在意的是能不能访问到边缘部署的业务,并获得相同的用户体验。

2. 近地分流 (Near diversion)

需要在数据面感知用户流量并能分流,如果不能在网络的近地边缘位置,就将用户业务流分流转向到本地处理,就无法实现业务路径时延最小化目的。

3. 资源开放 (Open resources)

可以开放给用户使用的资源,有:边缘计算算力资源、无线网络资源、自定义业务资源等,在网络的边缘位置,给本地的计算、处理和应用提供开放接口。

多接入边缘计算开放了运营商网络的数据面,为移动边缘入口服务创新提供了基础,为物联网的未来铺平道路,为各种OTT(Over The Top)应用提供了技术条件。

MEC同时也是 5G标准的推动力量,是5G 实现uRLLC场景下保证低时延性能指标的唯一的技术手段。随着5G架构的演进,MEC 也随之演化成5G MEC:结合SDN 软件定义网络(Software Defined Network)、NFV网络功能虚拟化(Network Function Virtualization)、UPF用户端口功能(User Port Function) 下沉到边缘; 涵盖的技术面也更为广泛,包括点对点、网格计算、雾计算、区块链和CDN内容分发网络(Content Delivery Network )等。5G MEC的概念在移动领域已经深入人心,几乎遍及各行各业,5G MEC解决方案都大受欢迎。

算力资源的隔离问题

一般情况下,5G MEC边缘网关设备对CPU、GPU、RAM、IO资源不会进行隔离。而对算力资源的隔离是对算力资源进行管理的基础。

1. CPU、GPU算力资源隔离

CPU、GPU算力资源的隔离主要包括以下内容:

(1) CPU、GPU算力按照百分比进行使用和隔离。以保证每个用户的CPU、GPU算力得到充分的共享和使用,得到较高的CPU、GPU利用率。实际上保证的是每个用户的资源使用下限,大部分情况,能得到比期望要多的CPU、GPU算力资源;

(2) 严格限制每个用户的CPU、GPU算力使用上限。即使同机器上仍有大量的空闲算力资源,也不会允许使用。

(3) 限制虚拟CPU、虚拟GPU的使用上限。实现机制与(2)相同,针对虚拟CPU、虚拟 GPU的情况。一般虚拟设备和真实设备的比例是1:1,对异构集群,某些节点上的CPU拥有更强的计算能力,则可以调整物理CPU和虚拟CPU比例,以消除集群中CPU、GPU计算能力的异构性差异。

2. 内存算力资源隔离

考虑到内存算力资源的特殊性,若缺少内存的隔离机制,如果业务进程树使用的总物理内存或总虚拟内存量超过限制时,会产生内存抖动,造成系统的振荡和异常,可能会导致本业务进程被不优雅地杀掉。

所以需要监控每个业务的进程树,当发现业务的进程树的总物理内存或虚拟内存量超过了预设时,要主动将整个进程树杀死。

4. IO算力资源隔离

IO算力资源分为磁盘IO和网络IO两种。IO算力资源的隔离比CPU和内存复杂的多,为了便于用户量化IO算力资源,仿照“虚拟CPU”概念,引入了“虚拟磁盘”、“虚拟网络”概念,实现磁盘IO隔离 和 网络收发IO隔离和调度。

5G MEC算力分配和调度

5G MEC边缘计算网关的算力资源,需要为多接入的不确定用户提供服务。用户需要先提交算力申请,并进入5G MEC边缘网关的算力资源请求队列进行排序;获得算力资源后还需要进入执行调度队列,得到实际的执行调度。这是一种多用户多业务多进程的服务调度,为了保证服务质量,需要制定合适的策略,结合用户业务需要分别进行算力资源分配和业务调度。最基本的策略有:

1. 绝对公平的分配和调度策略

即不区分用户,所有用户一律平等,即先来先服务策略,根据请求者的先后次序,进行算力资源请求队列的排序。提申请在先的用户先分配到算力资源,如:CPU时间片、GPU处理单元数量、RAM配额、NVM容量等。若某项资源不足,则用户必须在资源请求队列中等待,直到有用户退出服务释放出足够的资源为止。执行调度也同样采用绝对公平的等时间片轮训调度。这种方式适合于平均计算时间、耗用算力资源情况差不多的业务。

2. 区分优先级的分配和调度策略

即歧视低优先级的原则,根据某种规则定义优先级给每个用户和应用打上优先级标签。在算力资源分配上,高优先级用户会优先分配算力资源;而低优先级用户要等高优先级用户全部分配完成以后,其所请求的算力资源才能得以分配。相同优先级的用户则按照先来后到方式进行算力资源的公平分配。

在执行调度上也要先匹配优先级,需要照顾后来的高优先级业务有机会提前运行,即高优先级的业务先执行,低优先级的业务即便得到资源分配,运行顺序也要靠后。

实际操作中会遇到优先级该如何判定问题:每个用户都倾向于认定自己的优先级最高,所以不能自己指定自己的优先级;而运营商指定的优先级则不灵活,流于死板。相同优先级用户之间的调度也缺乏灵活性,即便同样都是高优先级,排在后面的用户也有可能必须要被迫等待很久才被调度,特别是排在前面的相同优先级的业务需要耗费非常多的算力资源时,比如AI模型训练需要几个小时乃至几天的CPU时间和大量内存时,就导致排在后面的那些只要很少算力资源很快就能完成的业务被阻塞很久才被调度。因此用户的优先级必须能够动态调整才会更加恰当。

3. 最小算力资源优先的调度策略

针对上述特定问题的解决方案:如果用户业务所需算力资源最少、或执行时间最短,则其执行优先级可以临时动态调整为最高。这种貌似公允的策略也存在漏洞,如:为得到优先执行权,将同一个业务反复提交多次,如果这个业务的执行时间比较短,那这个用户将会得到调度优势,其他的诚实用户只能在等。

4. 执行算力资源配额策略

为每个用户分配一个执行算力资源配额,若该用户一次提交多个业务,用光了自己的执行算力资源配额,就只能干等了。从整体来看这个调度方案对大家都是公平的。

这个貌似公平的解决方案仍然存在“吃大锅饭”问题:如有的用户业务多工作重,分配到的执行算力资源配额和工作量不成比例; 反而和那些业务少工作轻的用户占用一样的执行算力资源配额。所以按用户数来平均的配额制,“吃大锅饭”不能做到真正公平。

5. 执行算力资源池调度策略

为用户分配的执行算力资源配额作为资源池化管理,即如果用户的执行算力资源配额有剩余,必须共享出来给其他有需要的用户用,由池化调度平台去保障这种配额容量的共享和分配。这种池化共享分配和调度算法实现起来比较复杂,和所得到收益相比很难量化。

可以看到,算力资源调度算法随着使用场景、实际需求、技术进步,而不断发展更新。在同一场景下面存在不同业务时候还会面临不同的权重,比如权衡不同的用户身份、不同的业务性质:是生产业务优先,还是训练业务优先;训练业务中断后恢复执行时的优先级如何调整;如CPU占用型、GPU占用型和RAM占用型业务,哪个更优先;根据算力资源的类别来权衡和分配策略;CPU、RAM、网络带宽几种算力资源之间的调度搭配,不同硬件性能服务器的算力资源调度侧重,等等,是很复杂的课题。

结束语

算力资源编排和调度并不神秘,使用算力资源调度服务也不是什么高深技术,重要的是熟悉和使用手边的工具,尽快搭建原型系统来解决当前最紧迫的基本问题。在此基础上丰富特性多次迭代,直到能满足用户对算力资源的分配编排和调度的需求。

分享到
关闭