当前位置：首页 > 顶级会议 > 正文

【ATC'21】MigrOS：对容器化RDMA应用程序的透明实时迁移支持

顶级会议
2022-10-18
2546
更新：2022-10-18 08:51:46

## 摘要

RDMA网络将数据包处理卸载到网络接口控制器（NIC）的专用电路上，并绕过操作系统以改善网络延迟和带宽。因此，操作系统失去了对活动RDMA连接的控制，失去了透明迁移RDMA应用程序的可能性。本文介绍了MigrOS，一种用于容器化RDMA应用程序透明实时迁移的操作系统级体系结构。MigrOS表明，对RDMA通信协议的一组最小更改可以在不插入关键路径操作的情况下重新进行实时迁移。我们的方法不需要更改用户应用程序，并在网络堆栈的所有级别上保持向后兼容性。总体而言，与纯软件技术相比，MigrOS可以实现高达33%的网络延迟降低。

## 1 导言

很多云提供商越来越多地向最终用户提供RDMA网络连接和高性能网络堆栈。RDMA网络通过将数据包处理卸载到RDMA NIC并将操作系统从通信关键路径移除，从而降低通信延迟并增加网络带宽。为了去除操作系统，用户应用程序使用专门的RDMA API，在发送和接收消息时直接访问RDMA NIC。这些性能优势使得RDMA网络在HPC和云环境中无处不在。

与此同时，容器已经成为轻量级虚拟化的流行工具。容器化应用程序独立于主机的用户空间（库、应用程序、配置文件），极大地简化了分布式应用程序的部署和管理。但是，RDMA网络和容器遵循的架构原则相互矛盾：容器化在应用程序和主机之间实现了更严格的隔离，而RDMA网络则试图使应用程序和底层硬件“更接近”。

容器编排系统（如Kubernetes）停止容器并在其他主机上重新启动它们，以实现负载平衡、弹性和管理。为了保持效率，容器化应用程序期待能快速重启。不幸的是，快速应用程序重启需要应用程序内部支持，而且成本非常高，因为RDMA应用程序往往具有较大的状态空间。相反，实时迁移以透明的方式移动应用程序状态，并且不会对应用程序提出额外的要求。

在实时迁移的上下文中，大部分容器状态驻留在主机操作系统内核中。它可以在以后的其他地方提取和回收。此可恢复状态包括打开的TCP连接、shell会话、文件锁。但是，正如我们在第3节中所阐述的，RDMA通信信道的状态不能由现有系统恢复，因此无法对RDMA应用程序进行检查点设置或迁移。

为了概述保存RDMA通信通道状态所涉及的概念性困难，我们比较了传统的基于TCP/IP的网络堆栈和IB Verbs API（见图1）。首先，对于传统的网络堆栈，内核完全控制通信发生的时间：应用程序需要执行系统调用来发送或接收消息。在IB Verbs中，由于NIC和应用程序之间的直接通信，操作系统无法更改连接状态，除非断开连接。尽管操作系统可以停止进程发送更多消息，但NIC仍可以静默地更改应用程序状态。其次，部分连接状态驻留在NIC上，操作系统无法访问。在这种情况下，透明地创建一致的检查点是不可能的。

本文的贡献是一种克服现有RDMA网络和操作系统支持限制的方法，它采用了一种新的体系结构。要解决的问题的根源是操作系统不可能截获数据包来操纵和修复中断的连接，就像透明的实时应用程序迁移中发生的那样。该体系结构的核心点是RDMA协议中的一个小变化，通常在RDMA NIC中实现：**我们建议在RoCEv2（一种流行的RDMA通信协议）中添加两个新状态和两种新消息类型，同时注意向后兼容性。**

为了使提议的修改可信，我们证明它们是：1、足以进行迁移，例如连接中断，以及；2、确实很小。为了证明第一点，我们为容器化RDMA应用程序设计并实现了一个透明的端到端实时迁移体系结构。为了证明第二点，并启用软件架构，我们通过修改SoftRoCE来实现新协议，SoftRoCE是RoCEv2协议的软件实现。

提供可信的评估对我们来说很难，因为我们无法修改RDMA NIC的状态机。相反，我们通过使用SoftRoCE实现比较原始协议和修改协议的延迟和带宽来证实我们的说法，并表明迁移阶段之外的网络性能没有受到影响。为了证明提议的协议更改和基于容器的软件体系结构的合理性，我们评估了透明实时迁移的软件级支持。我们表明，这些方法为正常操作增加了大量开销。

## 2 背景

本节简要介绍容器化和RDMA网络。我们进一步概述了实时迁移以及RDMA网络如何阻碍这一过程。

### 2.1 容器

在Linux中，进程可以使用名称空间从逻辑上与系统的其余部分分离。通过这种方式，进程可以对文件系统、网络设备、用户等有一个独立的视图。容器运行时利用名称空间和其他低级内核机制，在包含一个或多个进程的容器内创建完整的系统视图。容器的迁移会移动在给定容器内运行的所有进程。分布式应用程序可以包括网络上的多个容器：例如，Spark应用程序可以隔离容器中的每个工作者，MPI应用程序可以将每个列组（rank）容器化。

### 2.2 Infiniband Verbs

IB verbs API是当今高性能RDMA通信的事实标准。RDMA应用程序通过直接访问NIC（操作系统旁路）、减少内存移动（零拷贝）和将数据包处理委托给NIC（卸载）来实现高吞吐量和低延迟。

图2显示了通信中涉及的以下对象。内存区域（MRs）表示应用程序和NIC之间共享的固定内存。由发送队列（SQ）和接收队列（RQ）组成的队列对（QP）表示连接。为了减少内存占用，可以用单个共享接收队列（SRQ）替换多个QP的单个RQ。完成队列（CQ）通知应用程序已完成的通信请求。保护域（PD）将所有这些对象分组在一起，并表示NIC的进程地址空间。

为了建立连接，IB verbs规范要求应用程序交换以下寻址信息：允许访问远程MRs的内存保护密钥、全局供应商分配的地址（GUID）、可路由地址（GID）、不可路由地址（LID）和特定于节点的QP号（QPN）。执行此交换的一种方法是通过带外网络，例如以太网。在连接设置期间，为特定类型的服务配置每个QP。MigrOS仅支持可靠连接（RC），它在两个通信伙伴之间提供可靠的有序消息传递。另一种流行的服务类型是不可靠数据报（UD），它不提供这些保证。

应用程序通过将发送请求（SR）或接收请求（RR）作为工作队列条目（WQE）发布到QP来发送或接收消息。这些请求描述消息并指向(refer to)先前创建的MRs中的内存缓冲区。应用程序通过轮询CQ的工作完成（WC）来检查未完成的工作请求是否完成。

对于不同的硬件，IB Verbs API有多种实现，包括Infiniband、iWarp和RoCE。InfiniBand通常是这些网络中速度最快的，但需要专门的NIC和交换机。RoCE和iWarp更易于部署，因为它们在以太网中提供RDMA功能。它们仍然需要NIC中的硬件支持，但不依赖于专用交换机。这项工作的重点是RoCEv2，一种越来越流行的RoCE协议版本。同时，我们只更改了部分RoCEv2，这些RoCEv2以与Infiniband和RoCEv1相同的方式定义，因此MigrOS也与其他RDMA协议兼容。

要启用RDMA应用程序迁移，必须考虑以下挑战：

1、 用户应用程序必须使用物理网络地址（QPN、LID、GID、GUID），但IB Verbs API未指定虚拟化这些地址的方法。

2、 NIC可以写入它与应用程序共享的任何内存，而无需操作系统注意。

3、 操作系统无法指示NIC暂停通信，除非突然终止通信。

4、 用户应用程序不处理连接目标地址的更改，并将进入错误状态。因此，应用程序将突然终止。

5、 尽管操作系统驻留在控制路径上，因此可以识别应用程序创建的所有IB Verbs对象，但操作系统并不控制这些对象的整个状态，因为状态部分驻留在NIC上。

我们在第3节中讨论了所有这些挑战。

### 2.3 CRIU

CRIU是一个用于透明检查点和Linux进程恢复的软件框架。它支持进程和容器的实时迁移、快照或加速启动。为了提取用户空间应用程序状态，CRIU使用传统的调试机制，如ptrace。然而，为了提取特定于进程的内核对象的状态，CRIU依赖于特殊的Linux内核接口。

在恢复期间，CRIU在目标进程内运行，并代表目标重新创建所有OS对象。这样，CRIU利用可用的操作系统机制运行大部分恢复，而无需对内核进行重大修改。最后，CRIU从过程中去除任何自身痕迹。

CRIU还可以恢复TCP连接的状态，这是分布式应用程序实时迁移的关键功能。Linux内核为此引入了一种新的TCP连接状态，即TCP_REPAIR。在此状态下，用户级进程可以修改发送和接收消息队列，获取和设置消息序列号和时间戳，或者在不通知另一方的情况下打开和关闭连接。

到目前为止，CRIU不支持保存和恢复对象。在迁移过程中放弃IB Verbs对象，天真地希望应用程序能够恢复，这很容易失败：一旦应用程序遇到错误的IB Verbs对象，在大多数情况下，应用程序将挂起或崩溃。因此，MigrOS为CRIU中的IB Verbs对象提供了明确的支持（见第3节）。

## 3 设计

MigrOS基于现代容器运行时(runtimes)，以最小的更改重用了大部分现有基础设施（见第3.1节）。最重要的是，我们不需要修改容器中运行的软件。相反，MigrOS包含以下关于RoCEv2的变更：

两个新的QP状态，用于创建一致的检查点（参见第3.2节）、连接迁移协议（第3.3节）和对数据包级RoCEv2协议的修改（第3.4节）。最后，第3.5节描述了我们对IB Verbs API的修改以及CRIU如何使用它们。仅使用IB Verbs支持扩展CRIU就足够了，现有的容器运行时使用CRIU实现其检查点/恢复功能。

### 3.1 软件栈/Software Stack

通常，对RDMA网络的访问隐藏在软件堆栈的深处。图3给出了一个容器化RDMA应用程序的示例。容器映像附带所有库依赖项，如libc，但不包括内核级驱动程序。在此示例中，应用程序使用通信库堆栈，包括Open MPI、Open UCX（未显示）和IB Verbs。通常，要迁移，容器运行时需要容器内的应用程序终止并稍后恢复所有IB Verbs对象。这将消除实时迁移的透明度。

MigrOS与包含容器运行时（例如Docker）、CRIU和IB Verbs库的容器一起运行。我们对CRIU进行了修改，使其能够识别IB Verbs，因此它可以在遍历属于容器的内核对象时保存IB Verbs对象。我们扩展了IB Verbs库（m-ibv-user和m-ibv-kern），以实现IB Verbs对象的序列化和反序列化。重要的是，API扩展与容器内运行的IB Verbs库向后兼容。因此，m-ibv-user和ibv-user都使用相同的IB Verbs内核版本。所有IB Verbs组件（ibv-user、m-ibv-user、m-ibv-kern）都包含一个通用部分和一个特定于设备的部分。MigrOS依赖于修改过的内核和用户部分（m-ibv-user和m-ibv-kern），但不需要修改容器内的软件。

### 3.2 队列对状态

在解释QP迁移之前，我们首先概述QP的一般功能。当应用程序通过一系列状态（如图4所示）获取QP来建立连接时，通信可以开始。每个新创建的QP都处于重置（R）状态。要发送和接收消息，QP必须达到其最终就绪发送（RTS）状态。在到达RTS之前，QP将遍历Init和Ready-to-Receive（RTR）状态。在错误的情况下，QP进入错误状态之一；错误（E）或发送队列错误（SQE）。在发送队列排出（SQD, Send Queue Drain）状态下，QP不接受新的发送请求。除此之外，SQD相当于RTS状态，我们在本文中不再进一步描述它。

为了安全地迁移连接，我们添加了两个对用户应用程序不可见的新状态（参见图4）：**Stopped**（S）和**Paused**（P）。当内核检查一个进程时，它的所有QP都进入停止状态。停止的QP不发送或接收任何消息。QP保持停止状态，直到它们与检查点进程一起销毁。

当QP得知其目的地QP已转换为停止(**Stopped**)状态时，QP将暂停(**Paused**)。暂停的QP不发送消息，但也没有其他QP从中接收消息。QP保持暂停状态，直到迁移的目标QP在新位置恢复并发送带有新位置地址的消息。暂停的QP保留目的地QP的新位置并返回到RTS状态。之后，通信可以继续。

### 3.3 连接迁移

迁移连接时有两个注意事项。首先，迁移容器的通信伙伴不得将迁移与网络故障混淆。其次，一旦迁移完成，迁移容器的所有合作伙伴都需要了解它的新地址。

我们通过使用连接迁移协议扩展RoCEv2来解决第一个问题。连接迁移协议在迁移期间和迁移之后处于活动状态（见图5）。此协议是低级数据包传输协议的一部分，通常完全在NIC内实现。此外，我们还添加了一个新的否定确认类型NAK_STOPPED。如果停止的QP接收到一个数据包，它会用NAK_STOPPED进行回复并丢弃该数据包。当伙伴QP接收到该否定确认时，它转换到暂停（P）状态，并且在接收到新的恢复类型的消息之前不发送进一步的分组。如果N0在N2发送恢复消息之前销毁QP，则来自N1的数据包将被丢弃，并且不会发送否定确认。可以同步旧QP的销毁和恢复消息的传输，但我们没有在原型中实现此功能，因为这样的数据包丢失不会影响正确性。

迁移完成后，迁移进程的新主机将所有QP恢复到其原始状态，并发送恢复消息。即使合作伙伴QP之前未暂停，也会无条件发送恢复消息。恢复消息的任何接收者都会将其QP的目标地址更新为恢复消息的源地址，即迁移的QP的新位置。

每个暂停和恢复消息都包含源和目标信息。因此，如果多个QP同时迁移，则不会混淆哪些QP必须暂停或恢复。另一方面，MigrOS必须防止在同一连接的两端同时迁移QP，因为恢复消息的发送者可能只知道旧的、过时的位置。如果迁移过程在任何时候失败，暂停的QPs将保持停滞状态，并且不会恢复通信。此场景完全类似于TCP连接迁移期间的故障。在这两种情况下，MigrOS将负责清理资源。

### 3.4 协议变更

我们的协议更改必须反映在RDMA NIC中，因为大多数数据包级RoCEv2协议实现都在硬件中运行。我们从一个典型的RDMA NIC执行所有数据包级别的工作这一事实出发，包括自行发送数据包和确认。因此，操作系统本身无法组装和处理任意数据包，包括MigrOS引入的数据包。

因此，为了使迁移能够工作，我们需要修改RDMA NIC。NIC根据服务（RC、UD等）和消息（读取、发送等）类型添加不同的数据包头。我们的更改只涉及两个报文头：基本传输报文头（BTH）和ACK扩展传输报文头（AETH）。BTH是第一个RDMA特定的报头，紧跟在IP和UDP报头之后。此外，NIC需要为每个QP维护两个新的暂停和恢复状态标志。NIC必须能够将QP转换到停止或暂停状态，使用操作系统发出的恢复消息处理发送请求，并处理暂停/恢复数据包。

我们的更改（见图6）涵盖了底层RoCEv2协议中的三个现有工作流：1. 处理发送请求WQE（图6a），2. 接收数据包（图6b），以及3. 接收确认（图6c）。NIC必须在所有这些工作流中考虑QP的两个新状态。这种逻辑变化很小，并且不会改变分组布局，因为它只是QP内部状态的一部分。

NIC必须组装新的恢复消息，或者让操作系统组装。与普通消息不同，恢复/resume从最后确认的消息而不是最后发送的消息中获取数据包序列号（PSN）。接收方通过BTH报头中的新操作码识别恢复消息。由于大量未使用的操作码，创建新的消息类型不需要更改消息布局。

类似地，暂停/pause作为新的否定确认类型发送，在AETH报头中使用syndrome字段的未使用值。因此，新的暂停NACK也不需要改变现有的分组布局。

图6中的工作流在用户通过门铃寄存器(doorbell register)触发NIC，这会在消息到达或超时时运行。除非QP暂停或停止，否则NIC将尝试一次发送或完成多条消息（图6a和图6c）。作为恢复的一部分，NIC也会触发这些工作流。

例如，为了简洁起见，图6不包括额外的超时反应逻辑。总的来说，逻辑上的变化很简单，并且大部分是重用现有功能。因为我们只更改AETH和BTH头，所以我们的更改同样适用于其他RDMA协议（例如Infiniband或RoCEv1）以相同方式使用这些报文头。我们认为，无论是新逻辑还是新状态，都不会产生令人望而却步的设计或实现成本。

真正的RDMA NIC需要硬件支持新的QP状态，并遵循相应的协议。完全迁移支持还需要NIC提取Infiniband对象的状态并处理新的消息类型。我们相信所有这些都可以在NIC的固件中实现。第4节介绍了拟议变更的概念验证软件实现。

### 3.5 检查点/恢复API

为了为进程和容器启用检查点/恢复，我们通过两个新调用扩展了IB verbs API（请参见清单1）：ibv_dump_context和ibv_restore_object。CRIU依赖于由两个新调用补充的普通IB Verbs API来保存和恢复应用程序的IB Verbs状态。

ibv_dump_context调用返回特定IB Verbs上下文中所有IB Verbs对象的转储/dump，该对象表示进程和RDMA NIC之间的连接。

转储/dump的创建几乎完全在内核内部运行，原因有二：首先，对象之间的一些链接是仅在内核级别可见。其次，为了获得一致的检查点，确保转储是原子的是至关重要的。

尽管现有的IB Verbs API允许创建新对象，但它不足以恢复它们。例如，在恢复完成队列（CQ）时，当前API不允许为此队列指定共享内存区域的地址，而是由内核分配该地址。也不可能在原始状态下直接重新创建队列对（QP），如就绪发送（RTS）。相反，QP必须遍历所有中间状态以达到所需状态。

我们引入细粒度ibv_restore_object调用，以便在现有API不足的情况下逐个恢复IB Verbs对象。在恢复过程中，CRIU读取对象转储，并为每个对象类型应用特定的恢复过程。例如，为了恢复QP，CRIU使用命令CREATE调用ibv_restore_object，并使用ibv_modify_QP通过Init、RTR和RTS状态转换QP。使用标准文件和内存操作恢复内存区域或QP缓冲区。最后，当QP达到RTS状态（表示活动连接）时，新主机使用ibv_restore_object调用执行重新填充命令(REFILL command)。此命令恢复特定于驱动程序的内部QP状态，并向合作伙伴QP发送恢复消息。

## 4 实现

为了提供透明的实时迁移，MigrOS对CRIU、IB Verbs库、RDMA设备驱动程序（SoftRoCE）和数据包级RoCEv2协议进行了更改。要迁移应用程序，容器运行时将调用CRIU，该CRIU将检查目标容器。CRIU停止活动RDMA连接并保存IB Verbs对象的状态（参见第4.1节）。然后，SoftRoCE使用我们对数据包级协议的扩展暂停通信。将检查点转移到目标节点后，该节点上的容器运行时调用CRIU来恢复IB Verbs对象并恢复应用程序。然后，SoftRoCE恢复所有暂停的通信以完成迁移过程。

SoftRoCE是一种Linux内核级软件实现（不是RoCEv2协议的仿真）。RoCEv2通过通过一个著名的UDP端口对Infiniband数据包进行隧道传输来运行RDMA通信。与其他RDMA设备驱动程序不同，SoftRoCE允许操作系统完全检查、修改和控制IB Verbs对象的状态。

作为RDMA通信的性能关键组件，RoCEv2通常在NIC的硬件和固件中运行。我们专注于最小化这些协议更改。MigrOS的关键部分是将连接迁移功能添加到现有RoCEv2协议中（参见第4.2节）。

### 4.1 状态提取和恢复

当CRIU发现其目标进程已打开设备时，状态提取开始。我们修改了CRIU，以使用第3.5节中介绍的API提取所有可用IB Verbs对象的状态。CRIU将该状态与其他过程数据一起存储在镜像/image中。稍后，CRIU使用新的API在另一个节点上恢复镜像/image。

当CRIU恢复迁移应用程序的MR和QP时，恢复的对象必须保持其原始唯一标识符。这些标识符是系统全局标识符，由NIC（在本例中为SoftRoCE驱动程序）以顺序方式分配。我们扩展了SoftRoCE驱动程序，将最后分配的MR和QP的ID公开给用户空间中的MigrOS。这些ID分别是内存区域号（MRN）和队列对号（QPN）。在重新创建MR或QP之前，CRIU会适当配置最后一个ID。如果没有其他MR或QP占用此ID，则新创建的对象将保持其原始ID。此方法类似于CRIU使用Linux的ns_last_pid机制维护还原进程的进程ID的方式，该机制公开内核分配的最后一个进程ID。

其他进程可能占用CRIU想要恢复的MRN或QPN。两个进程不能在同一节点上使用相同的MRN或QPN，从而导致冲突。在当前方案中，我们通过在应用程序启动之前在系统中的所有节点之间全局划分QP和MR地址来避免这些冲突。CRIU在进程ID冲突方面也面临同样的问题。这个问题只有通过引入进程ID名称空间才能得到解决。为了解决IB Verbs对象的冲突问题，需要类似的基于名称空间的机制，以及虚拟RDMA网络。我们把这个问题留给今后的工作。

此外，恢复的MR必须保留其原始内存保护密钥。保护密钥是NIC提供的伪随机数，远程通信伙伴在发送数据包时使用。RDMA操作仅在提供的密钥与给定MR的预期密钥匹配时成功。除此之外，密钥的值不包含任何附加语义。因此，保护密钥不存在冲突问题。

CRIU通过使用ibv_restore_MR_keys命令调用ibv_restore_object，将所有保护密钥设置为其原始值，然后重新启动通信。

### 4.2 恢复连接

连接迁移协议确保连接正常终止并恢复到一致状态。此协议的实现是特定于设备和驱动器的。在这项工作中，我们通过提供检查点/恢复API的实现（第3.5节），修改SoftRoCE驱动程序，使其符合连接迁移协议（第3.3节）。

图7概述了SoftRoCE驱动的基本操作，它为每个QP创建三个并发任务：请求者、响应者和完成者。当应用程序向QP发布发送（SR）和接收（RR）工作请求时，请求者和响应者会相应地处理它们。根据MTU的大小，工作请求可以被分成多个数据包。当整个工作请求完成时，响应者或完成者通过将工作完成发布到完成队列来通知应用程序。

这些任务逐包处理所有请求。每个任务维护下一个数据包的数据包序列号（PSN）。请求者发送数据包以在其伙伴QP的响应者处进行处理。响应者回复并向完成者发送确认。完成者在收到SR中最后一个数据包的确认后生成工作完成（WC）。类似地，响应者在收到RR的所有数据包后生成WC。

迁移之后，当恢复的QP_a准备好再次通信时，它会向QP_b发送一条带有新地址的恢复消息。在接收到恢复消息后，QP_b的响应者学习QP_a的新位置。然后，响应者用最后成功接收的数据包的确认进行应答。如果某些数据包在迁移过程中丢失，则QP_b响应方的下一个PSN小于QP_a请求方的下一个PSN。差异对应于丢失的数据包。同时，QP_b的请求者可以开始发送消息。此时，QP_a和QP_b之间的连接完全恢复。

所提出的协议确保两个QP在不丢失无法恢复的数据包的情况下恢复连接。如果数据包在迁移过程中丢失，QP可以确定哪些数据包丢失并重新传输，这是正常RoCEv2协议的一部分。整个连接迁移协议对用户应用程序透明地运行。

## 5 评价

我们从三个主要方面评估MigrOS。首先，我们分析实现工作，特别关注RoCEv2协议的变化幅度。其次，我们研究在迁移阶段之外添加迁移能力的开销。第三，我们估计了单个IB Verbs对象的细粒度迁移成本，以及实际RDMA应用程序中迁移的全部延迟。

对于大多数实验，我们使用两台机器的系统：每台机器配备一个Intel i7-4790 CPU、16 GiB RAM、一个板载Intel 1 Gb以太网适配器、一个Mellanox ConnectX-3 VPI适配器和一个Mellanox Connect IB 56 Gb适配器。Mellanox VPI适配器设置为40 Gb以太网模式。SoftRoCE驱动程序通过该适配器进行通信。这些机器使用基于Linux 5.7的定制内核运行Debian 11。我们将此设置称为本地设置。与DMTCP和FreeFlow相比，我们使用的是Ubuntu 14.04。

我们在由两个插槽Intel E5-2680 v3 CPU节点组成的集群上进行进一步测量，该节点具有Bull部署的Connect IB 56 Gb NIC。我们将此设置称为集群。在本地设置中使用了两个与集群中节点类似的节点，并配备了配置为56 Gb InfiniBand模式的Mellanox ConnectX-3 VPI NIC。

### 5.1 变化的大小/Size of Changes

为了量化MigrOS需要的更改，我们计算软件堆栈不同组件中新添加或修改的源代码行（SLOC）。在大约4 k SLOC中，只有大约10%适用于内核级SoftRoCE驱动程序。这些更改主要集中于保存和恢复对象的状态。我们分别统计了负责通信活动阶段的请求者、响应者和完成者QP任务的变化（见图7）。这些任务将在NIC中实现，用于基于硬件的RDMA实现。因此，我们保持对QP任务的更改简单而小，因为这些更改必须反映在固件或硬件中。在我们的实现中，对QP任务的更改仅占总体更改的6%左右。

使用gcov，我们验证了QP任务的大多数更改不会影响通信的关键路径。在通信的活动阶段，gcov识别为可执行的SoftRoCE驱动程序的4808行中有1213行被触发。在接触的行中，只有28行对应于我们为迁移添加的代码，其中3行对应于变量赋值，其余的与检查暂停或停止状态相关。对QP任务的其余代码更改仅在连接迁移阶段运行。

除了QP任务中的附加逻辑之外，保存和恢复IB Verbs对象还需要操作特定于实现的属性。其中一些属性无法通过原始IB Verbs API设置。例如，恢复MR需要额外的能力来恢复内存密钥和MRN的原始值。其他一些属性在原始IB Verbs API中根本不可见。SoftRoCE中实现的队列（CQ、SRQ、QP）需要能够保存和恢复备份队列的环形缓冲区的元数据。如果QP使用共享接收队列（SRQ），则QP的转储还包括当前工作队列条目（WQE）的完整状态。我们确定了SoftRoCE所需的所有属性，计算了它们的内存占用（见表1），并实现了这些属性所需的所有特性。

在SoftRoCE中实现的对RoCEv2的更改很小，仅在迁移阶段之外对关键通信路径产生轻微影响。我们相信，对于RDMA NIC，RoCEv2的相同变化将保持同样小。

### 5.2 迁移的开销/Overhead of Migratability

即使在不进行迁移的情况下，仅仅添加透明容器迁移的功能也可能会产生开销。

例如，DMTCP（参见第6节）拦截所有IB Verbs库调用，并在将其转发到NIC之前重写工作请求和完成。对于DMTCP和FreeFlow，即使进程从未迁移，这种拦截也会持续发生。与此相反，MigrOS不会拦截关键路径上的通信操作，因此不会引入可测量的开销。本小节将探讨不进行迁移的正常通信操作所增加的开销。

DMTCP和FreeFlow不提供实时迁移。尽管如此，它们可以扩展以提供这种服务。因此，我们首先估计在用户级别添加迁移功能的成本。我们使用perftest基准测试套件中的延迟和带宽基准测试。我们使用CX3/40 NIC在本地设置中以10000次迭代的方式运行每个实验30次。

这两个框架都对每个IB Verbs工作请求进行额外的处理，这导致延迟开销几乎恒定（见表2）。每个工作请求对应一条消息，而不是一个数据包，因此对于较大的消息大小，开销会减少。表2表明，带宽直接受到延迟增加的影响，因此只有小消息的带宽较低。我们预计这样的带宽减少对于实际应用来说是一个小缺点，而对于许多对延迟敏感的应用来说，延迟增加近50%可能是至关重要的。

尽管我们尽了最大努力尽量减少NIC的变更，但MigrOS提出的变更可能会带来可测量的开销。因此，我们需要证明MigrOS在消息传输过程中不会增加额外的周期。为此，我们将可迁移和不可迁移版本的SoftRoC驱动的性能与运行不可迁移版本SoftRoCE的DMTCP进行比较。在三种不同的配置中运行ib_send_lat基准测试表明（参见表3），可迁移性不会增加任何可见的开销。同时，DMTCP的延迟增加也很小，因此很难区分所有三种配置。不同配置之间差异如此之小的原因是SoftRoCE引入的巨大通信开销。因此，我们的实验仅表明可迁移性不会增加大量开销，但无法对潜在的微秒级开销做出可靠的判断。这种情况是SoftRoCE的一个不幸限制。考虑到我们期望的开销有多小，即使是FPGA实现也可能不是商业RDMA NIC的精确反映，因为FPGA和实际硬件实现之间存在显著差异。根据第3节中给出的论点，我们确信MigrOS不会引入甚至微秒级的开销。

### 5.3 迁移的代价/Migration Costs

通过增加对迁移IB Verbs对象的支持，容器迁移时间将与重新创建这些对象所需的时间成比例增加。我们的目标是估计迁移支持RDMA的应用程序的额外延迟。本小节显示了迁移SoftRoCE创建的连接的成本，以及使用基于硬件的IB Verbs实现创建连接的成本。

在建立可靠连接（RC）之前，需要几个IB Verbs对象，见第2.2节。通常，应用程序为每个通信伙伴创建一个PD、一个或两个CQ、多个内存区域和一个QP。

为了衡量创建单个IB Verbs对象的成本，我们修改了IB_send_bw以创建其他MR对象。我们每次运行创建一个CQ、一个PD、64个QP和64个1 MiB大小的MRs。图8显示了在50次运行中创建每个对象所需的平均时间。每个测试的NIC由一个条形图表示。我们从这个实验中得出两个结论。首先，不同NIC之间的所有操作都有很大差异。其次，大多数操作所需的时间在毫秒范围内。

迁移RDMA连接所需的确切时间取决于两个因素：QP的数量和分配给MR的内存总量。这两个因素都是特定于应用程序的，可能会有很大的差异。因此，接下来，我们将展示应用程序使用MR和QP对迁移时间的影响。

图9显示了MR注册时间，具体取决于区域大小。MR注册成本在操作系统和NIC之间分摊：操作系统固定内存，NIC了解注册区域的虚拟内存映射。SoftRoCE不承担“NIC部分”的代价，因此使用SoftRoCE注册MR比使用RDMA的NIC注册更快。对于本实验，我们不考虑迁移过程中MR内容的转移成本。

QP的数量是影响迁移时间的第二个变量。图10显示了迁移运行ib_send_bw基准的容器的时间。该基准测试由两个运行在两个不同节点上的单进程容器组成。通信开始三秒钟后，容器运行时将其中一个容器迁移到另一个节点。迁移时间以未移动的容器所看到的最大消息延迟来度量。检查点通过基准用于通信的相同网络链路传输。随着QP数量的增加，基准测试会消耗更多内存，从8MIB到20MIB不等。为了更好地理解这一点，我们通过计算为支持RDMA的NIC重新创建IB Verbs对象的时间来估计实际设备的迁移时间。我们从测量的迁移时间中减去使用SoftRoCE创建IB verbs对象的时间，并添加使用RDMA NIC创建IB verbs对象所需的时间（见图8）。我们用虚线表示我们的估计。

### 5.4 MPI应用程序迁移

为了评估真实世界应用程序的透明实时迁移，我们选择迁移NPB 3.4.1，这是一个MPI基准测试套件。MPI应用程序运行在OpenMPI 4.0之上，后者反过来使用OpenUCX 1.6.1进行点对点通信。我们将UCX配置为通过可靠连接（RC）使用IB Verbs通信。

此设置对应于图3。我们使用基于libcontainer自行开发的运行时konyk对应用程序进行了容器化。与Docker不同，我们的运行时通过在检查点过程中将映像直接发送到目标节点，而不是本地存储，从而加快实时迁移。此外，konyk在RAM中存储检查点，从而进一步减少迁移延迟。与任何其他容器运行时一样，konyk在内部使用CRIU检查和恢复容器。对容器运行时的进一步描述超出了本文的范围。

为了测量应用程序迁移延迟，我们用四个进程（ranks）启动每个MPI应用程序。大约在应用程序进程的中间，其中一个迁移到另一个节点。每个基准都有一个大小（A到F）参数。我们选择的大小使所有基准测试都在10到300秒之间运行。我们排除了“dt”基准测试，因为它只运行大约一秒钟。图12显示了容器迁移延迟和平均值周围的标准偏差，每个基准测试平均运行20次。

我们将迁移延迟分为三个部分：检查点、传输和恢复。MigrOS首先停止目标容器并准备检查点。MigrOS几乎立即开始将检查点数据传输到目标节点，这与检查点同步。传输发生在基准测试用于通信的网络链路上。检查点和数据传输的这种重叠使独占数据传输的时间最小化。传输完成后，MigrOS将在目标节点恢复容器。总体而言，基准测试的运行时延迟与迁移延迟成正比，迁移延迟与检查点大小成正比。

MPI应用程序（图12）的迁移速度比微基准（图10）慢，即使在考虑了检查点大小后也是如此，因为测量方法不同。对于微基准，我们根据非迁移进程观察到的最大消息延迟来计算迁移时间。对于MPI基准，我们根据整个基准的总执行时间的增加来计算迁移时间。这种差异表明，并行应用程序的迁移可能会对应用程序性能造成比简单状态转移时间所能解释的更大的破坏。

为了展示MigrOS与其他容器运行时的互操作性，我们测量了使用Docker 19.03时的迁移成本（见图11）。我们必须自己提供端到端迁移流，因为Docker只提供检查点和恢复。令我们失望的是，Docker没有采用一些重要的优化，并且需要很多时间来完成迁移。为了更好地理解性能差异，我们在konyk中禁用了一些优化：将检查点保存到主内存（而不是硬盘），在转储期间发送检查点，并使用优化的方式传输检查点。所有这些都不足以与Docker的表现相匹配。进一步的调查显示Docker不必要地在文件系统中移动检查点映像，这证明了容器运行时中显式实时迁移支持的重要性。尽管如此，我们还是展示了使用Docker进行容器化RDMA应用程序迁移的基本可能性。

## 7 讨论和结论

MigrOS是一种操作系统级体系结构，支持透明的实时容器迁移，而不牺牲RDMA网络性能。我们确信MigrOS的体系结构对于云或HPC环境中的动态负载平衡、高效准备的故障切换和实时软件更新非常有用。

**硬件修改和软件实现**

我们认为，有限的硬件更改值得考虑，并且已经证明是可行的，甚至对于RDMA协议。然而，修改硬件的提议经常会遭到批评，因为对于操作系统设计者来说，很难验证和评估这些提案。为了克服这个困难，我们修改了SoftRoCE。事实证明，只需要向状态机添加几个状态和两种新的消息类型。因此，我们实现了容器化RDMA应用程序的透明实时迁移，而不会影响通信的关键路径。Lesokhin等人已经证明，RDMA协议的更改只需通过固件更新即可实现，无需更换NIC。此外，我们的设计在各个级别都与现有RDMA网络基础设施保持完全向后兼容性，并且可以被其他RDMA协议（例如Infiniband和RoCEv1）采用。

不可靠数据报通信

MigrOS为可靠通信（RC）提供实时迁移，但不为不可靠数据报（UD）提供实时迁移，因为首先，通过UD接收的每条消息都公开其发送者的地址。当此发送方迁移时，其地址将发生更改，目前，MigrOS无法向接收方隐瞒更改。其次，UD QP不知道迁移后向何处发送恢复消息，因为它可以从任何地方接收消息。因此，为了支持UD，NIC需要维护一个额外的简单表，以便在用户可见地址和实际地址之间进行转换。我们把这个问题留给今后的工作。

**安全**

到目前为止，缺乏身份验证和完整性控制是RDMA网络中的一个普遍问题。因此，现代RDMA网络依赖于可信的NIC和主机。在本文中，我们要求主机操作系统确保暂停和恢复消息只能由授权主机发送。如果NIC或主机不可信，则附加协议必须防止发送未经授权（例如通过欺骗）的暂停和恢复消息。在这方面，我们不会降低RDMA网络的安全性。

**白盒迁移**

以前的实时迁移技术需要代表应用程序进行合作，因为它们将RDMA NIC视为黑盒。据我们所知，我们的工作首先考虑RDMA NIC作为一个白盒，用于实时迁移。我们将设备状态分类为：1、公共状态，可通过IB Verbs API观察，2、设备-驱动程序可见状态，由内核级和用户级驱动程序可见，3、内部状态，在设备外部不可见。设备必须在迁移时向操作系统公开其内部状态。我们希望，当为其他设备（如GPU）实现实时迁移时，这些发现可能有用。

**除了迁移**

我们相信暂停/恢复协议还可以找到其他用途，如有效的故障转移、拥塞控制或负载平衡。作为一个例子，考虑MasQ，具有防火墙能力的虚拟RDMA网络。MasQ可以关闭RDMA连接，但与TCP/IP防火墙不同，MasQ不能临时阻塞它们。我们的协议可以返回对操作系统的RDMA连接的控制，并将类似TCP/IP的行为复制到RDMA防火墙。

> 参考网址：github.com/TUD-OS/migros-atc-2021

> 参考文献：Planeta, Maksym, Jan Bierbaum, Leo Sahaya Daphne Antony, Torsten Hoefler and Hermann Härtig. “MigrOS: Transparent Live-Migration Support for Containerised RDMA Applications.” USENIX Annual Technical Conference (ATC2021).

> <span style="font-style: italic;">声明：本文素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。由于本人水平有限，如有纰漏，请以参考文献文章为准。</span>

RDMA