基于Fork实现SPDK nvmf_tgt的热升级

weixin_37097605

于 2024-07-12 12:01:18 发布

阅读量1k

点赞数 8

文章标签： github 网络 linux 运维服务器

本文链接：https://blog.csdn.net/weixin_37097605/article/details/140393129

版权

SPDK NVMe-oF Target[1][2]，在存算分离的部署中，越来越起到关键的作用，结合SPDK的用户态NVMe驱动以及SPDK支持不同存储后端的通用块设备层，为计算侧的存储接入提供了高性能、可扩展的网络存储。比如在Ceph社区， SPDK NVMe-oF Target作为高性能网关的实践[3]。

长期而言，对于存储target服务，要实现对initiator影响极小、甚至initiator侧无感的热升级是非常重要的特性。而如何保证升级过程中target 与initiator之间的链接（基于不同fabrics通道建立的数据交互链路）不中断，以及链接上传输的I/O数据的完整性则是实现该热升级特性的关键。升级实际就是需要运行一个新版本的程序实例，在此过程中要实现已经和 initiator侧建立的链接不中断，可能的一个思路就是此前我们的合作伙伴（阿里云服务器智算系统创新和测试团队，在此也感谢合作伙伴的分享）宣传过的方式------通过Fork的方式继承原来的target服务进程中的链接句柄等上下文信息，然后再在通过exec来运行新的实例后重构出原有的链接[4]。本文对近期基于SPDK nvmf_tgt服务采用Fork方式实现热升级的方案及验证情况进行简要介绍。

方案概述本方案的主要逻辑可以分成三大部分: 升级前处理、运行新的nvmf_tgt实例和升级后的恢复。具体这三部分的实现可以分别描述如下。升级前处理：

触发升级后，nvmf_tgt服务会处理完已接收的完整的NVMe command并停止接收新的NVMe command，其后暂停NVMf subsystem，继而保存相关的必要信息。保存的信息中除了常规的诸如NVMf subsystem、ctrlr、listener、transport、namespace等外，还有listener以及各ctrlr的QPair对应在transport层的句柄等关键信息。

运行新的 nvmf_tgt 实例：

完成前述操作后，即可以执行Fork操作 “复制” 出一个拥有和原nvmf_tgt 进程相同上下文的新进程。Fork操作执行完成后，原有的nvmf_tgt服务进程就可以平稳退出，而新fork出来的nvmf_tgt进程由于继承了原有进程的相关上下文信息（如前述的各个transport层的句柄），可以实现既有的传输层链接（如TCP、 RDMA的链接）仍然被 “保持” 住，不会中断。接着在新Fork出来的进程中以exec的方式运行新的要升级到的nvmf_tgt实例以替换原有的 “代码段” 。这样，Fork出来的新进程运行的就是需要升级到的版本了。

升级后的恢复：

在新的nvmf_tgt版本实例运行起来后，即可以根据之前已经保存的各方面信息来恢复原有的NVMf subsystem、transport、listener、namespace和ctrlr了。恢复操作中，比较特别的地方在于ctrlr的恢复。为了尽可能复用原有SPDK NVMf实现的逻辑，目前是先根据继承的transport层的句柄恢复出transport层的链接，然后构造模拟NVMf Fabrics command以完成ctrlr的创建和Admin QPair、 IO QPair的重建。ctrlr恢复完成后，NVMf tgt在各个CPU核的轮询操作即可以从原有的链接句柄中接收新的还未被处理的NVMe command进行处理，从而因升级 “中断” 的I/O即恢复运行。

在上述的这几个步骤中，有个比较关键的点就是如何保证I/O的完整性，一者是要避免由于中间状态或者缓存造成原有nvmf_tgt进程退出前有数据丢失未被处理的情况，其次就是恢复过程中，要确保新的NVMe命令在ctrlr恢复完成后再进行接收和处理，以免由于状态不符合预期而报错。同时，对于基本信息的保存和恢复可以复用SPDK中既有的save_config和load_config这两个RPC接口的实现来进一步简化所需的工作量和逻辑复杂度。

实行升级这几个步骤的操作过程可以很短，而且其间没有断链和重新建链的操作，因而对于initiator而言可以做到几近无感知。

在当前的实现中，暂时是增加了两个RPC的接口来完成nvmf_tgt的热升级触发和升级后的恢复操作，实际业务中完全可以做到运行新实例后根据保存的相关信息执行自动恢复。

方案验证

基于当前的方案实现，已按如下的业务模型进行了验证，相关的过程和结果可以见下文描述。

1. 验证业务模型和拓扑：

图1基于SPDK的软件拓扑

如图1中所示，验证测试的场景是VM通过vhost来访问SPDK nvmf_tgt提供的存储。在VM中运行fio访问SPDK nvmf_tgt服务提供的存储的过程中，对SPDK nvmf_tgt服务程序进行版本升级，其间VM内运行的fio的I/O短暂停滞，在升级完成后恢复并正常完成。2. 验证过程和结果：

在VM中跑fio开始后，以RPC命令：“./scripts/rpc.py nvmf_start_hot_upgrade -i /home/zj/spdk/build/bin/nvmf_tgt”来触发对nvmf_tgt服务的热升级，其中-i 后边的参数指定的是新版本nvmf_tgt实例的完整路径。在新版本nvmf_tgt实例运行起来后就可以通过RPC命令: “./scripts/rpc.py nvmf_resume_after_hot_upgrade” 来触发相应的恢复操作。其后，VM中fio的I/O就会恢复运行。RPC命令执行的过程可如图2所示。