近年来随着云计算技术的快速发展，基于云原生的业务和应用也如雨后春笋般迅速生长。IPU (Infrastructure Processing Unit，也叫DPU --- Data Processing Unit)的出现，使得很多存储、网络、加密、压缩等处理的逻辑可以被卸载到硬件上执行，这一方面节省出更多的主机资源给上层应用以支持更多的用户，同时也能更好的实现存算分离，为云业务提供更好的安全性。因而IPU在云原生业务场景中的应用也一直广受关注。在此前的文章中，我们已介绍过IPU应用于加速容器镜像的准备和容器启动过程的内容 [1][2] ，让大家看到了IPU在云业务场景中的使用优势，本文将以Intel基于ASIC的IPU (Mount Evans, Intel 2100 series) 为例，说明如何通过SPDK-CSI [3]和SMA (Storage Management Agent) [4] 实现在Kubernetes部署的容器中使用IPU提供的NVMe接口类型的存储资源 (virtio-blk也是IPU在此种场景下可支持的存储类型，使用方式与NVMe类似，本文不单独展开) 。
在此之前，基于SPDK-CSI插件的支持，Kubernetes已经可以使用藉由SPDK技术提供的高性能存储，但主要是结合NVMe-Over-Fabric的方式来使用远端的存储，具体可以如图1所示。
图1. Kubernetes通过SPDK-CSI使用远端的NVMf Target为POD提供存储的方案
目前，Intel 2100 的IPU可以对主机提供virtio-blk和NVMe类型的存储接口，既可以在IPU下直连NVMe盘作为后端的存储资源，也可通过100G的Ethernet去访问远端的存储[5]，相关的场景可如图2和图3所示。
图2. Intel 2100 IPU使用本地直连的NVMe盘为主机提供virtio-blk/NVMe类型存储接口示例
图3. Intel 2100 IPU通过Ethernet访问远端存储资源为主机提供virtio-blk/NVMe类型存储接口示例
为了方便和Kubernetes等云编排软件对接，目前Intel 2100 IPU支持以SMA (Storage Management Agent) 和 OPI (Open Programmable Infrastructure) [6]的方式来实现远程配置和管理。SMA和OPI的两套接口对于Intel 的IPU而言是相似的，均是基于SPDK的JSON-RPC接口框架进行封装，以gRPC的形式来对外暴露可配置的接口，其逻辑关系可如图4所示。远端主机或者编排软件可以通过gRPC的客户端将请求发送到IPU上运行的SMA类型的server [4] 或者OPI 类型的server [7] 从而实现对IPU上资源和特性的配置。
图4. Intel 2100 IPU通过SMA或者OPI的接口支持远程配置的逻辑关系示意
为了实现Kubernetes和IPU进行对接，当前SPDK-CSI中已经有了对接SMA 类型gRPC server的客户端实现逻辑[3] ，同时支持OPI 类型gRPC server的客户端实现逻辑的patch也已经在review中[8] 。但已有开源的SPDK-CSI中关于通过SMA和OPI方式对接IPU的实现，目前还都是以软件(如基于SPDK实现的target) 来模拟了IPU，因而还需要在此基础上对SPDK-CSI的相关逻辑进行一些修改，才能和真正的IPU进行对接。
若选择以SMA接口的方式来对接IPU，则通过SPDK-CSI使用IPU为Kubernetes调度的POD提供存储的方案示意可如图5所示。
图5. 通过SPDK-CSI和SMA接口使用IPU为Kubernetes的POD提供存储资源示意
当前Intel 2100 IPU对主机暴露的NVMe PF (Physical Function)可以支持1023个VF，并且这些VF可以通过SR-IOV的方式来分配使用。针对当前介绍的云原生的使用场景，为了达到更好的灵活性，可以预先一次性将1023个VF均分配初始化，只是预先在IPU上创建各个VF对应的controller资源时并不添加namespace资源 (例如，不为其连接远端的存储资源) 。等Kubernetes调度的各个POD创建时申请使用其中的一个VF，再为其添加请求大小的namespace资源。而当POD销毁时，则删除对应的namespace资源，从而VF可以等待被下一个POD分配使用。如此，就实现了根据具体用户请求的动态的资源分配和回收。这个特殊的处理对应在图5中所示的步骤中就是以橙色虚线框标识的第2步操作，也即各次POD创建和销毁时该操作并不执行（已在初始时VF预先分配过程中执行）。
在部署的单节点的Kubernetes集群中，使用Intel 2100 IPU对主机呈现的NVMe VF为POD提供存储资源进行测试时的相关过程可参见图6~9所示。并且通过修改SPDK-CSI的配置，可以让从IPU的VF初始化的存储资源以Block或者FS的方式提供给POD对应的Container使用。此处示例设置为以Block的方式提供给POD中的Container使用。
图6. 使用Intel 2100 IPU为Kubernetes集群的POD提供存储资源测试时的POD
(spdk-test和spdk-test1为应用所在的POD, controller和node标识的是运行SPDK-CSI逻辑的POD)
图7. 使用Intel 2100 IPU为Kubernetes集群的POD提供的存储资源在系统下的呈现
图8. 登录使用IPU提供存储资源的POD对应的容器对容器下的存储跑FIO测试
图9. Kubernetes通过SPDK-CSI的SMA插件向IPU请求存储资源过程举例
虽然相比于图1中所示的直接在主机上连接远端存储的场景而言使用IPU为Kubernetes提供存储的情况下IO路径看着有所增长，但得益于IPU卸载了主机侧网络以及存储客户端逻辑(特别是针对远端存储为Ceph的这种情况)，主机可以获得更多的CPU用于支持应用的运营和扩展。具体而言，使用IPU来为Kubernetes等云原生场景提供存储，主要有如下的优势：
1. 卸载网络栈和存储客户端逻辑，可以节省出更多的CPU用于上层的应用。
2. IPU提供的加密、压缩等硬件特性，可以对业务中的相关处理进行加速。
3. IPU的引入更好的实现了存算分离，提供更高的安全性。
4. 对于IPU直连本地NVMe盘的场景，IPU能够实现更为灵活的空间管理和资源分配。
综合而言，随着IPU提供的功能更加丰富以及更高性能的处理能力，在云原生场景使用IPU将会带来更多的便利和优势。随着云时代的发展的大势，加速和扩展云业务的使用场景也必将是IPU应用的一个重要方面。
参考信息：
2. 利用DPU/IPU 卸载容器镜像以及文件系统的相关操作
3. https://github.com/spdk/spdk-csi
4. https://spdk.io/doc/sma.html
5. https://ci.spdk.io/download/2022-virtual-forum-prc/D2_6_Jun_Accelerating_The_Storage_Application_with_Intel_MEV_IPU.pdf
6. https://github.com/opiproject/opi
7. https://github.com/opiproject/opi-intel-bridge
8. https://review.spdk.io/gerrit/c/spdk/spdk-csi/+/18747
转载须知
推荐阅读
点点“赞”和“在看”，给我充点儿电吧~
