【论文】略读笔记68-前沿-实时渲染无缝迁移

📖《Seamless Cross-Edge Service Migration for Real-Time Rendering Applications》

2024 年发表于 CCF-A 类期刊 TMC。

🎯需求

• 实时渲染应用的无缝跨边缘迁移具有挑战性。实时渲染应用具有很强的交互性，要求停机时间低于15ms，以实现不易察觉的迁移。
  • 云游戏、云虚拟现实、云增强现实等实时渲染应用在 5G 时代蓬勃发展。它们有望成为现实世界与数字孪生世界之间的桥梁。
    • 然而，受限于可穿戴显示设备较弱的计算能力，实时渲染应用必须连接到功能强大但价格昂贵的本地主机。这使得它既不轻便，大多数人也负担不起。
    • 将渲染模块移动到云端并将渲染图像流式传输到用户设备（UE）似乎是一种成本友好的方案，但 UE 与云端之间的长距离会带来额外的高延迟，从而导致不愉快的用户体验。
    • 为了解决这个问题，有人提出了边缘渲染。这种设计可在网络边缘提供低延迟渲染服务，并将 UE 从计算密集型渲染操作中解放出来。因此，用户可以在瘦客户端上以可接受的价格享受实时渲染应用。
  • 然而，实时渲染应用依赖于实时流协议，如实时流协议（RTSP）和实时消息协议（RTMP）来向 UE 传输高分辨率视频流。低延迟要求限制了提供边缘渲染的边缘云的覆盖范围。
    • 此外，为了防止缓冲区带来的额外延迟，一些专为实时渲染应用设计的流媒体系统甚至采用了在 UE 端不缓冲视频帧的设计。
    • 上述设计使边缘渲染容易受到用户移动带来的延迟增加的影响。如果用户移出连接边缘云的覆盖区域，服务质量（QOS）就会因延迟增加而下降。
    • 为了解决这个问题，有人提出了 Follow me cloud，它利用边缘云之间的服务迁移，将服务实例动态地迁移到更邻近、延迟更低的边缘云上。
      • 然而，服务迁移是一项成本高昂的操作。它涉及大量数据传输，并带来服务停机时间。停机时间是指服务迁移过程中服务冻结和不可用的一段时间。在停机期间，用户会有晕机、屏幕冻结和黑边等不愉快的体验。
      • 因此，将停机时间缩短到 15 毫秒以内是防止不愉快体验并使服务迁移不易察觉的基本前提^[2]。
        

🚧现状

• 现有的基于虚拟机迁移和容器迁移的方法都存在脏页重传引起的重复内存数据拷贝和共享存储故障引起的大量磁盘数据拷贝所带来的令人不快的停机时间。
  • 进行服务迁移的主流方法是虚拟机（VM）实时迁移和容器实时迁移。
    • 1）虚拟机实时迁移是云数据中心广泛使用的成熟技术。然而，虚拟机实时迁移会迁移整个操作系统，因此会带来过多不必要的数据转移。
    • 2）为了使迁移更加轻量级，容器实时迁移成为移动边缘计算的热门研究课题。借助用户空间检查点/恢复（Checkpoint/Restore In Userspace，CRIU），容器实时迁移实现了进程级迁移。在容器实时迁移过程中，只传输相关文件和内存状态，因此比虚拟机实时迁移更轻便。
  • 然而，虚拟机迁移和容器迁移并不是保证跨边缘场景中实时渲染应用服务连续性的理想方法。
    • a. 首先，它们的停机时间是不可接受的。
      • 虽然已经采取了大量方法来减少停机时间，如预复制、后复制和分层结构，但它们的停机时间从几十毫秒到几秒不等。这些方法的性能都达不到 15 毫秒的标准。
      • 此外，我们的测量结果表明，如果在迁移过程中进行高频内存写入操作，虚拟机迁移和容器迁移的停机时间会急剧增加。这一特性使它们无法迁移计算密集型实时渲染应用。
    • b. 此外，虚拟机迁移和容器迁移还存在其他固有缺陷。
      • 虚拟机实时迁移主要依赖云内场景中提供的共享存储，如 Ceph 和 NFS，以防止大量文件系统转移，但由于广域网（WAN）环境带来的运行时性能下降，这种方法并不适用。
      • 由于容器实时迁移依赖的 CRIU 不支持图形应用程序的检查点，因此容器实时迁移无法用于实时渲染应用程序。

🛩创新

• 我们的见解是：

  • 直接从源边缘云复制所有状态数据成本太高。相反，实时渲染应用的复杂状态可以从边缘和云之间交换的逻辑数据流中恢复。
    • 例如，移动游戏客户端可以在断开连接后恢复游戏并赶上其他玩家的进度。
  • 因此，我们使用云辅助孪生渲染（dual rendering）来代替直接点对点跨边缘状态复制来实现状态同步。它利用逻辑流中的状态信息，在目的边缘云上创建一个孪生应用实例，并与原始实例同步。
  • 这样的设计绕过了内存复制过程中脏页重传带来的性能瓶颈，使进一步减少停机时间成为可能。

• 然而，要实现这种架构，必须克服以下两个关键挑战：

  • 1. 如何在限制停机时间的前提下实现应用会话和 5G用户面会话的同步切换。
    • 上述两个切换过程都应及时完成，以避免带来额外的停机时间。
    • 然而，这两个系统都有各自的控制器，这就增加了会话快速协调切换的难度。
  • 2. 如何在会话切换过程中保持 UE 屏幕的连续性，以保证迁移过程不被察觉。
    • 我们将迁移过程简化为从源边缘视频流到目的边缘视频流的切换。
    • 由于源边缘和目的边缘分别渲染图像，从两端到达UE的帧不可能完全一致。因此，即使停机时间可以压缩得足够短，用户仍可能会遭受令人不快的视觉突变，即帧闪烁。有了这种闪烁，迁移仍然是可感知的。

• 应对挑战的方法是：

  • 1）为了应对第一个挑战，我们提出了一种以UE为中心的会话管理机制。
    • 在预迁移阶段，迁移准备工作分别由计算控制器和 5G 核心网主导。
      • 在计算状态迁移方面，两个边缘云在云逻辑服务器的协助下同步计算状态。
      • 在通信网络方面，将建立从基站到目的地边缘云的新协议数据单元（PDU）会话，并与之前的 PDU 会话并行工作。
      • 由于采用了孪生渲染机制，在预迁移阶段结束时，UE 会同时接收来自两个边缘云的渲染流。
    • 在此基础上，计算和网络会话的物理切换变成了 UE 中的一次性软切换。
    • 迁移阶段简化为 UE 侧的流会话切换，通过交换 UE 流选择器中的配置来实现。
  • 2）为了应对第二个挑战，我们引入了一种平滑切换机制，包括结构相似性（SSIM）门限、帧滑动和异步一帧缓冲。
    • 2.1）SSIM阈值决定何时触发流切换。只有当来自两个边缘的视频帧流足够相似时，才允许进行流切换。
    • 2.2）帧滑动使 UE 端能够在触发切换后呈现两个视频流帧的加权平均值，从而使两个视频流之间的过渡更加平滑。
    • 2.3）异步一帧缓冲机制定义了 UE 中流媒体客户端线程和流媒体选择器线程之间的数据交换模式，可确保差异显著的帧及时刷新。

• 在本文中，我们提出了云辅助服务迁移（CSM），利用云边缘协作实现实时渲染应用的无缝服务迁移。CSM 从三个方面改善了服务迁移的用户体验：

  • 1）首先，它引入了孪生渲染机制，绕过了点对点数据复制，压缩了停机冻结阶段。
  • 2）第二，提出了以用户设备为中心的会话切换机制，通过很好地协调应用会话切换和 5G 用户平面会话切换来节省时间。
  • 3）第三，利用平滑切换机制防止会话切换期间出现令人不悦的帧闪烁。

• 概括而言，主要贡献如下。

  • 1）我们证明了脏页重传引起的重复内存数据拷贝导致的大量数据传输是虚拟机实时迁移和容器实时迁移的性能瓶颈（第二节）。
  • 2）然后，我们提出了基于云边缘协作的 CSM 方法，该方法专为实时渲染应用而设计（第三节-A 和 第三节-B）。CSM 以云辅助孪生渲染取代了点对点状态复制，从而压缩了冻结阶段。据我们所知，这项工作首次不仅考虑了计算状态转移，还考虑了 5G 用户平面 PDU 会话切换以减少服务停机时间。
  • 3）我们开发了以 UE 为中心的会话管理和平滑切换机制（第三节-C）。前者负责协调应用会话和 5G 用户平面会话的同步切换。后者使视频流从源边缘到目的边缘的转换不易察觉，并保证用户体验。
  • 4）我们在包含全栈 5G 核心网用户平面的 5G 核心网测试平台上实现了所提出的架构（第四节）。我们对边缘渲染模式进行了实验（第五节）。实验结果表明，我们的方法可以进一步将平均停机时间减少到 14 毫秒以下，这足以实现不易察觉的无缝迁移。

📊效果

• 我们在边缘渲染多人游戏中实现了 CSM，并将其部署在带有全栈用户平面协议栈的 5G 测试平台上。
• 评估结果表明，CSM可以将停机时间减少到<14ms，而且服务迁移过程是用户无法察觉的。

⛳️Discussion（未来机会）

• 与虚拟机和容器一起工作： CSM 与虚拟机和容器并不冲突。它只是为迁移提供了一种替代方法。虚拟机和容器的应用分发和部署功能可以保留。除了停机时间方面的性能提升，CSM 还可以被视为虚拟机和容器的补充。首先，它支持共享实例部署。虚拟机和容器只能迁移只服务于一个用户的独占实例。如果迁移共享实例，实例的其他用户也会受到影响。由于 CSM 是应用级的，因此它可以迁移一个用户的状态，而不会影响共享同一实例的其他用户。其次，它弥补了容器无法迁移图形用户界面应用程序的缺陷，使容器可用于部署实时渲染应用程序。这种组合充分利用了容器在应用部署中灵活轻便的特点和 CSM 的高迁移性能。
• 适用的应用程序类型： CSM 假定有一个包含全局状态信息的逻辑服务器。这种部署架构通常用于多用户应用程序，从本质上分离了全局逻辑模块和渲染模块，非常适合 CSM。然而，并非所有应用程序都符合这一假设。有些应用程序会将部分状态信息放在客户端，以减少信息交换，如用户视角。另一个例外是单用户应用程序，它根本没有中央逻辑服务器。为使 CSM 适用于上述例外情况，应对应用程序进行修改。对于客户端有部分状态的应用，源边缘云可以在迁移过程中临时将本地状态发送到全局逻辑服务器，以实现完整的状态同步。这种临时状态共享已在评估中使用的修改版 Minetest 中实现。用户的视角状态会首先发送到逻辑服务器，然后同步到辅助会话，以保证视图一致。对于单用户应用程序，渲染模型和逻辑模型可以解耦，使其与多用户应用程序相似。因此，在多用户应用中，逻辑模型可以发挥类似于云逻辑服务器的作用。此外，还应为跨服务器状态同步提供网络接口。
• 对应用程序进行必要的修改（侵入式）： 由于 CSM 是一种应用层面的方法，因此应修改应用程序，使 CSM 适用。好消息是，应用程序的核心逻辑不会受到影响。开发人员只需应用会话 III-C2 中提到的会话管理机制，即可支持协同会话。这将允许一个用户账户在迁移过程中在不同地点同时登录，并启用孪生渲染过程。

🧠疑问

1. 孪生渲染具体指什么？有什么缺点？
   1. 在做完迁移决策后，不从源主机复制内存，而是从云上获取逻辑操作，根据逻辑操作知道接下来需要渲染什么样的内容。
   2. 是否会导致切换时间短但预热时间长？如果这样的话，则要求有提前很多的预测、否则需要对很多个可能的主机都提前预热。
   3. 接2，在用户高速移动的场景下本方法会很难支持（但好像所有技术都无法支持，是整个场景的一大痛点）。
2. 如何判断移动性？
   1. 本文不做讨论，仅处理已确定移动性和迁移目标后的操作。如果联合考虑是否会存在问题？例如在决策迁移目标时就应该考虑到哪个机器更适合迁移（例如已有部分状态信息）。
3. 若资源是跨域的，没有完整权限，该怎么协作？
4. 云边协同体现在什么地方？
5. 本文实现强实时的代价是什么？能否优化？
   1. 资源浪费。
6. 本文方法是侵入式的，如果想使用非侵入式方式该怎么办（站在云供应商的角度）
7. 核心逻辑：渲染任务有强实时要求 -> 边缘计算能够满足强实时需求，但覆盖范围有限导致必须使用迁移技术(Follow me cloud) -> 传统迁移方式先拷贝状态再更新脏数据，存在无法避免的较高停机时间（大于15ms），使用户体验差 -> 本方法从源主机拷贝状态，而是通过上层下发的控制逻辑直接实时渲染最终结果，避免脏数据。
8. 论文写的太清晰了！值得学习！
9. 论文的insight是很重要的一部分，如果论文设计了case study体现insight，将会对读者产生巨大价值。

---

---

• 希望这篇博客对你有帮助！如果你有任何问题或需要进一步的帮助，请随时提问。
• 如果你喜欢这篇文章，欢迎动动小手 给我一个follow或star。

🗺参考文献

[1] Y. Li et al., “Seamless Cross-Edge Service Migration for Real-Time Rendering Applications,” in IEEE Transactions on Mobile Computing, vol. 23, no. 6, pp. 7084-7098, June 2024, doi: 10.1109/TMC.2023.3331773.

[2] “Cloud VR solution white paper”, Hua Wei iLab Tech. Rep, 2018, [online] Available: https://www.huawei.com/minisite/pdf/ilab/cloud_vr_network_solution_white_paper_en.pdf.