简介：随着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的功能、性能问题带来了极大的便利，还能通过告警及早发现各类问题，确保客户业务稳定、高效的运行。
