简介:随着AI计算及云游戏为代表的图形渲染业务的飞速发展,越来越多的企业和个人开始使用GPU实例。同时,由于GPU算力资源成本较高,对于负载相对较小的业务,客户会更倾向于选择使用1/2或者1/4甚至更小的vGPU实例来运行其业务,vGPU技术随之得以迅速发展。
背景
随着AI计算及云游戏为代表的图形渲染业务的飞速发展,越来越多的企业和个人开始使用GPU实例。同时,由于GPU算力资源成本较高,对于负载相对较小的业务,客户会更倾向于选择使用1/2或者1/4甚至更小的vGPU实例来运行其业务,vGPU技术随之得以迅速发展。
目前主流的vGPU技术是通过对物理GPU资源进行显存切分隔离,然后以时间片轮转的方式调度使用GPU资源。这就要求对物理GPU进行合理的切分、调度管理,并且能够及时监控物理GPU、vGPU的利用率、性能及健康状态,并且在GPU/vGPU异常时能够及时告知用户或研发人员,以便及时解决问题、避免长时间影响客户的业务。
下面,分两部分介绍下在阿里云上是如何提升vGPU资源利用率的,并且如何对vGPU进行监控与告警。
vGPU利用率的提升
当前主流的vGPU实例实现方案大体是这样的:首先将物理GPU切分为多个vGPU,然后根据资源分配策略将物理GPU上的vGPU分配给Guest VM,最后再根据调度策略将这些vGPU通过time-sliced的方式轮流使用GPU的Graphics/Compute、3D、编解码等引擎资源。在时间切片 vGPU 中,在 vGPU 上运行的进程被安排为串行运行。当进程在 vGPU 上运行时,vGPU 独占使用 GPU 的引擎,其它vGPU都会等待,直到自己的时间片到来。
在云厂商使用的主流的vGPU切分方案中,为了降低单物理GPU故障时对vGPU实例的影响,通常采用Breadth-first分配策略,即广度优先遍历算法,该策略尝试最小化每个物理 GPU上运行的 vGPU 数量,即分配支持该vGPU且其上运行vGPU数量最少的的物理GPU。然后,使用Fixed share按照time-sliced时间片轮转的方式将运行在vGPU上的业务调度到GPU引擎上,轮流使用GPU的Graphics/Compute、3D、编解码等引擎资源。在时间切片 vGPU 中,在 vGPU 上运行的进程被安排为串行运行。
当进程在 vGPU 上运行时,vGPU独占使用 GPU 的引擎,其它vGPU 都会等待,直到自己的时间片到来。该调度策略在云上可以保证各个vGPU实例的公平,避免graphics-intensive业务抢占graphics-light业务的运行时间。
但是,随着vGPU技术的日趋完善与稳定性的不断提高,加之很多云厂商为了提高物理GPU资源利用率,都支持了vGPU混部技术,阿里云的vGPU混部的实现需要考虑与老版本兼容,大体实现步骤为:
∙ 查询Host上的GPU信息,切片时会使用该信息。
∙ 查询当前某GPU上的vGPU信息,用于分配给待创建的vGPU实例。
∙ 根据创建的实例机型,分配空闲的vGPU device。当没有空闲的vGPU时,选择空闲GPU进行切片,并分配vGPU device给实例。
∙ 当某个GPU上的vGPU实例全部释放时,需要清除该GPU的切片信息,以便下次重新切片成其它规格的vGPU device。
∙ 切片的实现与释放都由管控侧操作,避免了上下信息不一致带来的实例启动失败等问题。
∙ 混部的实现中,需要指定vGPU所属GPU的BDF,以此来区分老版本,确保新老版本在现网正常运行。
由此可以看出,Breadth-frist分配策略与vGPU混部之间存在冲突,无法共存,这就降低了物理GPU资源的可用率。举个例子来说,例如在一个Host上有4个物理GPU,理论上可以创建8个1/2 vGPU实例或者16个1/4 vGPU实例。
如果采用breadth-first,客户A使用4个1/2实例,客户B使用4个1/4实例,如果客户A先创建实例,那么这4个1/2实例会占用4个物理GPU实例,导致客户B的实例无法创建。而使用depth-first,客户A的4个1/2实例会使用2个物理GPU,客户B的1/4实例则会使用另外2个物理GPU,显著提升了物理GPU的资源利用率,也就提高了资源售卖率、降低了成本。混部效果如下图所示:
目前已经支持1/1到1/24规格的vGPU切分,极大的方便了客户根据自身业务选择合适的规格,降低了客户成本,同时提高了GPU资源利用率。
vGPU的监控与告警
vGPU实例的最大客户就是云游戏,而云游戏对性能有极高的要求,例如大多数游戏需要满足60 FPS的要求,这就要求vGPU性能不能出现抖动和卡顿。而这类性能问题是无法通过日志来定位的,加上掉卡、TDR等常见问题的频发,监控与告警机制就显得尤为重要了。由于现有的监控工具容易导致Host vGPU driver死锁、CPU利用率冲高甚至hang住等问题,我们自己开发了一套vGPU监控程序来监控vGPU状态,大体步骤如下:
∙ 当机器部署上线后,监控任务开始启动,当vGPU VM启动后,开始采集物理GPU及vGPU相关信息,包括GPU温度、功耗、显存使用情况、GPU/vGPU利用率等,甚至还包括vGPU上进程的利用率以及license状态等信息。
∙ vGPU智能监控已经完全接入嫦娥,运维及研发同学在定位vGPU相关问题时,可以清晰直观地通过嫦娥上的监控信息进行分析与定位。目前已将上述所有信息都接入嫦娥监控,包括GPU的温度、功耗、显存利用率、GPU利用率、clock、编解码等:
还有vGPU相关的信息,包括vGPU利用率、显存利用率、进程利用率、编解码利用率、license状态等等。
设置各个指标的告警阈值,当达到阈值时触发告警,并及时通知到开发、运维人员,有必要时通知客户系统管理员,以便及时处理问题,保证系统和客户业务的稳定运行。
结合vGPU热迁移技术,将GPU负载高且满足热迁移条件的vGPU实例迁移到GPU负载低的Host上,达到负载均衡的目的,保证vGPU业务高效稳定的运行。
通过对用户实例使用vGPU情况进行大数据统计分析,了解典型客户、典型场景的真实资源需求情况,辅助PD进行产品设计,支撑异构实例研发的方向决策,制定更合理的实例规格,对剩余的CPU或内存资源与主售实例进行混买,提高实例密度、降低成本。
根据上述嫦娥展示的监控数据,就可以很方便的来定位vGPU实例性能问题, 例如:
∙ 对于FPS持续很低等问题,可以关注vGPU的License是否激活,1代表已激活,0代表未激活;
∙ 对于FPS达不到预期的60等问题,可以关注GPU的功耗、温度、利用率等是否已经到达瓶颈;
∙ 对于VM内应用性能、卡顿等问题,可以关注vGPU中的各项利用率指标是否正常;
当然了,Host驱动与Guest驱动版本是否匹配,clock是否有限频等,也可能导致性能问题。
如果以上都正常,就要结合是否有XID error,CPU、内存、网络、磁盘等是否有瓶颈来综合定位了。
结束语
阿里云的vGPU实现方案,集vGPU混部、监控告警、热迁移于一体,不仅最大的提高了GPU资源售卖率,而且为开发、运维人员定位GPU/vGPU的功能、性能问题带来了极大的便利,还能通过告警及早发现各类问题,确保客户业务稳定、高效的运行。