本次分享的主题是GPU安全容器面临的问题和挑战，分为五个部分，首先介绍GPU安全容器的背景，其次从安全、成本还有性能这三个维度介绍在实践中碰到的一些问题的应对方案，最后分享GPU安全容器带状态迁移的话题。

 

本次分享的主题是GPU安全容器面临的问题和挑战，由阿里云智能集团弹性计算高级技术专家李亮分享。

 

一、GPU安全容器

首先是GPU安全容器的背景，阿里云的GPU的算力的产品其中有很多种形态，大家熟悉的可能是GPU裸金属和GPU虚拟机这两种，因为它的上线时间比较久并且受众也比较广。这些年随着容器技术的日益普及，还有在各种场合的广泛使用，逐渐意识到如果给用户直接提供GPU的容器产品，可能会进一步的提升用户使用GPU算力的便捷性。

考虑到GPU安全容器的特点，包括在资源的力度上其实可以做的更细，用户在申请资源的时候，其实可以以更小的力度去申请，另外在释放和使用方面确实有很多优势的地方，如果未来能推出这么一个产品，应该会给大家带来很多的便利。

GPU裸金属、虚拟机还有容器这三种产品形态的不同，从技术栈上去看，裸金属产品基本上是把整个物理机都完全交给用户，它的一个优点就是能够给用户提供最佳的一个性能，然后给用户提供使用这个机器最大的灵活性，相比之下虚拟机的话，这种产品形态的话会就有一些不同，就是在软件站上能够给用户掌控或者使用，主要是VM以上的这一层的软件栈，包括应用程序、用户状态、容器、OS，至于VM以下的一些组件，包括Hypevisor、Host OS、计算机硬件，这些都是云厂商来控制和管理的，GPU安全容器的产品形态就更加极致了。

基本上用户能掌控的就只有应用层面的东西，包括容器、Hypevisor、Host OS以及计算机硬件，所有的东西基本上都是由云厂商来掌控的。这样的一个资源交互界面的上移，背后实际上是云厂商把越来越多的复杂性都替用户处理，这样使得用户可以更聚焦于自己的一个业务，然后使用起来也会更加的方便，因为所有底层的一些复杂的问题，包括性能问题、配置问题，云厂商其实都帮忙解决了。

GPU安全容器与普通容器的区别，这两者之间看上去差不多，唯一多的地方是GPU安全容器的产品里面多一层硬件虚拟化，还有Guest Linuxkernel这一层，其他的和普通容器并没有区别，这样设计的好处是GPU安全容器可以利用硬件的虚拟化使得不同的容器之间可以提供一个有效的安全的隔离措施。可以把容器提供给多个租户使用，也就是多个租户都可以在一个节点上面去开容器的实例，不会担心有安全的问题。

这种方式最大的缺点就是虚拟化带来的两方面问题，一是虚拟化可能会带来额外的资源开销，另一个是说虚拟化可能会导致GPU性能的问题。核心有两个挑战，一个是能不能把虚拟化的资源开销降得尽可能的低。第二是在性能上能否把它做到跟普通的GPU容器一样的水平。

 

二、安全

首先在实践过程当中发现一个安全问题，本来是希望通过语音输入解决租户之间的隔离问题，但实际上发现，仅仅用现有的序列化解决不了，其中一个问题是GPU的MMIO攻击，虽然不同的容器是跑在不同的VM，但是在硬件层面，它还是会要共享像PCI总线的资源。GPU MMIO攻击其实是可以通过往GPU PCI BAR的空间里面去持续大量的写入一些随机的数据，这种方式很容易把一个GPU打挂，因为触发路径就是通过这样的方式导致GPU的行为异常，GPU的行为异常有的时候会触发PCI总线出现异常，如果PCI总线出现异常，这个时候问题就会比较复杂，就取决于你的硬件配置，有时候比较严重的情况可能就是机器直接挂掉，再差一点的情况就是机器不挂，但是整个PCI的总线可能对GPU的一些请求都已经失去响应。这个问题是非常严重的，在GPU裸机这种情况下解决这个问题，其实因为整个机器资源都是一个用户的，这种解法并没有必要，但是在容器这种场景，就需要在Hypervisor的层面，对于GPU所有MMIO的写入要做一个拦截，要把写入GPU MV寄存器的一些敏感数值要做一些过滤，防止它的一些特定的数值能够写到GPU的寄存器里面导致把GPU搞出问题来，需要GPU的厂商去提供需要拦截的寄存器列表，以及对应的过滤规则。

如果做这样的拦截之后，就会对GPU的性能有比较大的影响。发现在一些一对一的场景当中，发现大概有1%~3%左右的性能的影响，对于GPU这么贵的硬件来说，这种性能下降其实是不太能接受的。为了缓解这个措施，有两种手段其实可以解决，一个是在拦截的时候就只拦截写操作对读的操作就不做拦截，因为在实际中跑业务负载的时候，发现GPU寄存器的读操作要远远比写操作要多，通过这种方式是可以减少大部分不必要的拦截。第二个措施是把拦截的一个处理路径缩短一些，对于在KVM架构里面，把MMIO这种拦截的处理就是从用户态给它下沉到内核态里面，这样可以非常有效的减少用户态和内核态切换的开销。通过这样的两种方式，可以把性能的影响做到大约都0.1%以内，基本上就是不能因为跑一个一对一的负载完全就感知不出来，这样就解决在多种场景的一个安全隔离问题。

 

三、成本

接下来关于成本方面最大的问题就是GPU虚拟化引入的一些内存开销。现在GPU设备随着显存容量的越来越大，GPU设备的PCI BAR地址空间也是越来越大，如果一台机器有多张卡，这个空间就要到1T左右，在一个GPU做虚拟化，这个BAR空间的地址的映射处理是需要页表做一些映射支持，这里面就有两个页表占的内存量是比较大的，其中第一个就是把PCI、BAR空间映射到用户态，从BAR空间映射到VMM的用户空间的时候，这个时候实际上是一个页表的，这个页表是要覆盖所有的BAR空间，这一部分其实占比是比较大的。还有一个占比比较大的表是要把BAR空间映射到Guest物理地址空间，对应的就是EPT表或者NPT表，这个表也会比较大，在BAR地址空间大的时候也是很大的。此外在KVM里面可能有一些memslot相关的原数据，这部分也是属于占比比较大的地方，这些都是有办法可以优化掉的，尤其是rmap这一部是可以通过动态分配，或者采用大页化的方式解决。

接下来是主要的优化措施，对于两个页表占用空间比较大的问题，最简单的一个处理方式，通过大页替换原来的4k的小页映射，这里面可能就要需要在内核里面，对于设备的KVM空间的大页知识需要完善起来，关于rmap这一部分是做动态分配，或者是通过启用TDP MMU的方式，规避rmap的使用，在一个生产环境当中，通过上面的这些措施去优化，但是这不是最优的效果，但基本上就可以做到像Ampere 8卡的训练机型把虚拟化的内存开销降低大概6.5GB。

 

四、性能

还有一个是GPU性能的问题，性能问题里面首当其冲的可能就是p2p的性能，它会直接影响我们多卡场景的训练和推理，核心的原因是在虚拟化下面的话，为保证设备之间的隔离，都需要把PCI的ACS功能打开，这个功能一旦开启之后，因为地址翻译的原因，还有数据路径要多走，比如要到地址翻译单元，然后再回去，就这样一些路径就导致整个效率比较低，通过一些分析Mark也能测到虚拟化下和裸金属下的带宽，大概有百分之三四十，在一对一里面也会有影响。

关于P2P的性能，有一些方法可以解决，尤其是在GPU安全容器的场景下，比较好的方式是可以在这种情况下尝试把ACS关掉，同时要强制让guest里面的GPU用PCI BAR对应的HPA，通过这样的方式可以在虚拟化的场景里面不去KSS也能够保证整个P2P的功能可以正常工作。

通过这样的优化方式，基本上就可以把虚拟化下载P2P的性能起到和裸金属完全相当的一个水平。但是这种方式有一些依赖，尤其是它要求BAR的空间GPA==HPA，它就必须在Kenel os可控的情况下才能去做这个事情。像传统的GPU的虚拟机的场景，因为Kenel os的东西完全是用户自己控制，这种场景不太适合用这样的方式解决。

性能的第二个问题是GPU Direct，一个是GPU Direct RDMA,另一个是GPU Direct Storage，GPU Direct Storage实际上是英伟达提供的,在一些多机或者GPU需要往存储里面去传输数据的时候，这两个特性是可以非常好的提升对GPU和其他外设之间的更新效率。但是在虚拟化下，如果还要实现这个功能，就必须要求网卡或者存储设备都需要支持ATS，如果设备不支持，尤其是在GPU Direct，GPU安全容器没有办法做到和GPU裸金属一样的水平。

第三个问题是IOTLB miss导致的性能下降的问题，这个问题是在实际生产中碰到的，如果OEM配置的系统内存没有采用IOTLB miss，在是多卡的场景，如果做集合通讯，就会非常容易出现性能的抖动，这个抖动的幅度是有的时候比较大，甚至会达到60%~70%的水平。解决这个问题就是要尝试给KVM的内存采用1GB的大页使能，能够非常好地规避问题。

如果采用4兆，这个问题影响很大，2兆还是会有一些漏洞就没有完全根除，只有1GB才是最佳的选择。还有其他的影响GPU的一些因素，包括NUMA&PCI拓扑，主要是要在虚拟化的时候，务必要保证的一点是让Guest看到NUMA&PCI拓扑或者GPU PCI拓扑，它能够和house上面的拓扑最好是一致的，不至于在做拓扑探测的时候出现错误配置的情况，如果Guest里面拓扑探测和实际表现不一致，它可能又是按照某种它以为的策略配置P2P的一些级别，可能就会导致一些新的问题，其他的就更常规的可能就更多的跟CPU相关的vCPU，还有内存伸缩相关的一些特性，可能也都会影响到GPU的性能。

虽然说这些性能影响挺重要，在容器场景就是非常注重密度，尤其在CPU的容器场景上，可能就是把部署的这种密度做一个非常有竞争力的指标，所以在内存伸缩这一块是有非常多的优化，但是这些特性在在GPU的场景里面，它可能价值并不是那么大，因为GPU的部件占整个服务器的比重确实是太高，但凡在其他维度上优化这个东西，如果影响到GPU性能的时候，要掂量一下优化是否划算。

 

 

五、容器带状态迁移

下面介绍GPU的容器带状态迁移的问题，现在的业界的当前发展情况，以及有可能实现的其他路径。首先介绍特性的应用场景，GPU容器的迁移在很多业务场景是非常有用的，如果有带容器带状态迁移，可以通过周期性的做checkpoint，这种checkpoint能够保持业务状态，一旦故障发生，可以迅速回滚到之前的状态，不至于故障的影响范围太大。

第二点可以通过checkpoint机制做一些任务抢占，在给用户提供实例的时候，可以提供两种不同的形态，比如像阿里云的场景，非常多的产品是spot的实例，这种实例非常便宜，只有在其他用户不用的时候你可以用，但是一旦用不上来的时候需要释放，以前如果没有胁迫性能力，用户的spot实例可能就是在一个资源不足的情况下，可能就是对用户毫不知情的情况就被杀掉，用户里面的业务状态就全部丢失，下次要跑的时候可能再重新再来一遍，但如果有切换的功能，就可以处理spot实例的时候，把它状态做一个保存，下一次当有空闲的实例，可以把它拉起来，这样它可以从原来断的地方继续执行，这样可以给用户更好的体验。

还有其他的应用场景，包括结合故障预测，通过提前去做容器的迁移，可以规避物理机的故障带来的影响，包括通过利用迁移做GPU碎片资源的规整，这个规整能避免碎片资源的闲置，可以更好地利用GPU的资源。这是它的一个应用的业务场景。

根据展示三个层面的实现路径，第一个是在业务层面，第二个是在POD层面，第三个是VM的维度。POD状态迁移和VM状态迁移的差异，POD状态迁移是整个POD类的进程的状态，相当于把所有的进程状态移到另一个地方，它本质上还是一个进程维度的迁移，VM状态迁移实际上是把运行VM、POD的所有的CPU内存（包括计算机的状态）都迁移在另一个地方，里面运行的POD的状态也都全部过去。

因为业务状态的迁移认为是跟应用关联度比较高的，完全受用户控制的。云厂商是很难在这个层面做统一的东西给所有的人去用。重点在POD级别和VM级别做迁移。POD状态迁移现在正在处在发展中，CRIU的形态处于高速发展中，像各大的 GPU的厂商，比如英伟达在这一层都有他们自己提供的一些方案，从技术的角度讲，它们的通用性确实是比较好的，因为它不但可以去适用于普通的容器，而且安全容器架构也是可以用的，厂商推的方式有可能是未来的趋势，或者在后面能占一个主导的地位。

但是现在有一些问题，比如NV的checkpoint的范围到目前还是处于开发中的状态。在很多场景下评测过还是有一些问题，尤其是多卡的场景。因为现在整个AI领域，它这个产品的占比还是太少，虽然他们有这个技术，但是不一定能产生太多价值，因为他们都不具备现实落地的可能性，阿里云还有其他的一些厂商都在探索另外一种方式，就是CRIU+Log&Replay和CRIU+cuda的方式，这种方式虽然它可能不简单，甚至处理起来也不干净，但是确实在当前的状态下，它可能是唯一一个就是自己能掌控，能把事情往前推的一个选择。

安全容器由于它不一样的地方，因为它是在VM当中，除了上面说的两种方案，还有其它的选择。其中可能的一种方式就是因为所有的空间都是在VM里面,GPU的状态完全可以通过另外一种方式，就是CRIU之外的一种方式，可以利用OS的休眠的功能,就是Hibernate&Resume这种能力去BAR整个POD的状态，也是可以做一个保存。

这种方式虽然力度比较粗，但它确实挺简单的,唯一需要支持的就是在底层的设备驱动层面，需要支持一个完善的电源管理功能，现实中做了一些尝试，跑个简单的TOC是没有问题的。但是现在也发现还是有一些卡点，比如在英伟达在这种GPU上就发现一个问题，就是在同一张卡上去做休眠和热迁移能力是没有问题的，但是一旦跨卡就不行。原因可能在Hibernate的初衷没有支持跨卡功能，这种方式不仅能解决GPU安全容器领域的问题，而且直通GPU的热迁移现在实际上是一个一直没法解决的问题，如果它驱动能把Hibernate做好的话，至少外面状态做保存和恢复还是可能实现，很多业务场景有可能实现。这是Hibernate类。

还有一种方式是VM的状态迁移,VM的状态迁移就是普通的一个虚拟机的迁移,如果要真正用这样一个能力，对于使用的GPU的形态可能就有一些要求。比如如果是把一个GPU直通一个安全容器上可能就不行，可能就只能用vGPU&SRIVO，这种能支持热迁移的形式的GPU的形态，VM热迁移和Hibernate是可以做一个结合，如果能够把两个东西整合到一起，有可能迁移的效率会比单独各自迁移的更好,这种结合的形式是非常值得考虑的。

比如它的核心思想是直通GPU，这种没有办法获取状态或者保持状态,但是完全可以通过在OS内部把GPU的 DOS的信息做保存，GPU之外其他的DOS的信息，包括CPU的信息，都走热迁移的路径迁过去，迁过去之后，在目的地方恢复的时候，可以把通过在Guest内部保存的GPU的信息恢复起来，这样就可以把这条路走通了。