【论文】略读笔记70-前沿-跨多层级管理域容器迁移

📖《UMS: Live Migration of Containerized Services across Autonomous Computing Systems》

2023 年 拉斐特路易斯安那大学（Louisiana）团队 发表于 CCF-C 类会议 GLOBECOM（短论文）。

🎯需求

• 部署在边缘和云等各种计算系统中的容器化服务需要实时迁移支持，以实现用户移动性、弹性和负载平衡。
  • 基于智能物联网的系统中的应用，如辅助技术和自动驾驶汽车中的应用，往往需要低延迟限制才能实现其目标。这就是边缘计算出现的原因，它可以绕过网络瓶颈，将计算带到用户（数据）附近，从而满足延迟限制。
  • 然而，边缘计算固有的资源短缺和缺乏弹性的问题，催生了一种新的分布式计算范式，这种范式基于连续的层级运行，可包括边缘、雾和云系统。为了克服边缘弹性不足的问题，在从边缘到云的连续统一体中进行实时服务搬迁（即服务迁移）的能力至关重要。
  • 此外，实现服务迁移还有助于克服现代分布式系统长期面临的其他挑战，如用户移动性、供应商锁定、能效、负载平衡和实现多云等。
    • 1）作为一个示例用例，可以考虑：
      • 将一副智能眼镜与边缘-云连续体一起使用，通过识别障碍物和检测接近物体的实时服务为盲人和视障人士提供环境感知。在我们希望创造的未来假设场景中，
        • 一位盲人走进一家咖啡店，店里的人正在利用资源有限的内部边缘服务器玩一款在线游戏。为了为盲人的辅助服务获取资源，必须将游戏服务迁移到云端，同时不对游戏玩家造成任何重大影响。
        • 当残疾人离开时，就会发生反向迁移。打个比方，这就像在公共交通系统中为残疾人保留优先座位一样。
    • 2）实时服务迁移的另一个动机用例是通过跨多云（即从一个云提供商迁移到另一个云提供商）无缝迁移服务来避免供应商锁定。
  • 由于 DevOps 和 CI/CD 等现代软件工程方法主要利用容器和容器编排器（如 Kubernetes）进行服务部署，因此实现服务迁移的关键在于实现容器化服务在计算系统间的实时迁移。

🚧现状

• 为了实现这种无处不在的高效服务迁移，实时迁移解决方案需要处理用户对底层计算系统拥有不同权限级别（完全控制、有限控制或无控制）的情况。支持这些级别的实时迁移是互操作性的基石，并能在各种形式的分布式系统中释放出多种用例。
  • 有人可能会说，要迁移容器化服务，我们只需要对服务容器进行检查点、转移和还原。的确，在高层次上，这是一个有效的论点，容器可以在源端透明地进行检查点，然后传输到目的地。
    • 但问题是，容器恢复后，目的地编排器无法识别和采用容器，也就无法提供任何管理设施（如扩展）。
  • 目前解决这一问题的方法是对底层计算系统的平台进行侵入式更改。
    • 虽然侵入式方法通常效率较高，因为它们带来的迁移开销较低（轻量级），
    • 但不同的计算系统通常是自主控制的，系统管理员无权同时修改源系统和目标系统。
    • 此外，这些系统有可能采用不同的编排器（如 Kubernetes 和 Mesos），而现有的作品只在同类编排器之间执行迁移，这就限制了迁移的可用性，并产生了供应商锁定的影响。
  • 据我们所知，目前还没有人尝试过基于容器级迁移方法在编排器级别进行迁移，没有一种实时服务迁移解决方案能做到两全其美：
    • (i) 在自治系统和异构编排器之间无处不在地运行；
    • (ii) 保持迁移效率。

🛩创新

• 为了实现这种无处不在的高效服务迁移，我们在本文中开发了无处不在的迁移解决方案（Ubiquitous Migration Solution，UMS），它可根据用户对底层计算系统的不同授权级别提供迁移服务：
  • (A) 完全控制：允许在源系统和目标系统的平台级别上进行更改；
  • (B) 有限控制：只允许更改两个系统中的服务映像；
  • (C) 无控制：不允许对底层系统进行任何更改。
• UMS 作为一个总括解决方案，涵盖了与上述权限级别相对应的以下三种迁移方法：
  • (A) 编排器级迁移方法，要求对源系统和目标系统进行完全控制，以便对其编排器进行更改；
    • 需要：将源系统和目标系统的编排器配置为完全兼容。更具体地说，应将编排器配置为调用底层容器运行时使用的相同检查点/恢复和同步模块。虽然这种方法具有侵入性，但它能使容器在无需任何修改的情况下高效迁移。
    • 我们：
      • 1）为实现无共享存储的容器化服务迁移，开发了一个新的同步模块，用于接收迁移请求中的目标地址，并将检查点文件传输到该地址。
      • 2）为减少迁移开销，我们将同步模块设置为与容器检查点和文件传输步骤重叠，即文件传输步骤无需等待检查点步骤完成即可开始。这是通过监控文件系统中的写入事件并将更改的内容复制到检查点文件来实现的。
  • (B) 服务级迁移方法，只要求对服务容器映像进行有限的控制更改；
    • 需要：在没有编排器配合的情况下在服务级运行，必须在容器中嵌入检查点/还原和同步模块。因此，只需在目的地的另一个容器中对服务内存足迹进行检查点和还原，而无需迁移整个容器。
      • 不过，我们注意到，这种方法要求开发人员在源系统和目标系统中都构建一个可迁移的容器映像。此外，这种方法还需要开发人员参与实时迁移的细节。
    • 我们：
      • 采用了现有的服务级迁移解决方案，即 FastFreeze 容器，并对其进行了扩展，以便与编排器协同工作。
  • (C) 容器级迁移方法，不要求对底层系统或服务进行任何控制。
    • 需要：
      • 1）一种非侵入式方法，以自给自足的方式执行实时迁移。
      • 2）然而，仅凭这种能力并不能解决服务迁移问题，因为在迁移时，目标编排器无法识别并逃避管理迁移的服务容器。
    • 我们：
      • 1）利用容器运行时独立于编排器执行容器检查点/恢复的能力。
      • 2）将可迁移容器嵌套在外层容器中。一方面，外层容器与目的地编排器保持绑定，另一方面，外层容器作为嵌套容器托管迁移服务。
      • 如下图第3部分所示，外层容器包括容器运行时（如 Docker 引擎）、检查点/恢复模块（如 CRIU）和同步模块。
        • 源代码中的这种安排使外层容器能够将其嵌套容器迁移为目的地中对等外层容器的嵌套容器，而无需任何编排者的参与。
        • 值得注意的是，嵌套容器只是一个普通容器，没有任何具体调整，由外部容器进行管理（例如，在资源使用跟踪方面）。
        • 为了实现容器嵌套的想法，我们采用了 Docker 中的 Docker，这是一个 Docker 引擎，并将其部署在外层容器内。
        • 为了在不跨系统共享存储的情况下同步检查点文件，我们采用了与编排器级方法相同的方法。
• 支持多种迁移方法给 UMS 带来了挑战，即:
  • (A) 如何透明地检测底层容器的结构，并采用适当的迁移方法。
  • (B) 此外，为了支持异构编排器，UMS 必须能够编排源系统和目标系统之间的迁移，而不论其底层平台如何。
  • (C) 除此之外，UMS 还必须为迁移选择合适的容器。
• 为了处理所有这些复杂问题，我们将 UMS 设计成一个多层次的系统，使其能够从迁移编排挑战和核心迁移过程中抽象出决策方面的问题。
  • UMS 不会干扰编排器处理容器的方式，并能在编排器不参与的情况下编排迁移。
  • 此外，UMS 与编排器无关，即可以插入任何底层编排器平台。
  • UMS 配备了新颖的方法，可以在编排器、容器和服务层面编排和执行实时迁移。
• 总之，本文做出了以下贡献：
  • • 开发UMS框架 ，该框架可在具有潜在异构编排器的自主计算系统中实现容器化服务的无缝、轻量级实时迁移。
  • • 开发在编排器、容器和服务层面运行的容器实时迁移方法。
  • • 证明在异构编排器（Kubernetes、Mesos、K3S 和 Minishift）之间以及微软 Azure 和谷歌云之间实时迁移容器化服务的可行性。我们还分析了不同迁移方法的开销。

📊效果

• 实验结果表明，对于单进程容器，采用服务级方法；对于内存占用较小（< 128 MiB）的多进程容器，采用容器级迁移方法，迁移开销和服务停机时间最低。为了证明 UMS 在实现互操作性和多云场景方面的潜力，我们测试了 UMS 在异构编排器之间以及 Microsoft Azure 和 Google Cloud 之间执行实时服务迁移的能力。
• 结果表明，UMS 可以在任意两个计算系统之间执行低开销的服务迁移。我们得出的结论是，尽管服务级方法是最轻量级的，但对于权限不足的多进程容器，其性能会下降。我们还演示了 UMS 在异构编排器之间执行容器迁移的用例，以实现多云的理念。

⛳️未来机会

• 本文只设计了“已知迁移源与目标后的”迁移系统，没有自动决策模块，也没有设计决策所需的信息获取模块。

🧠疑问

1. 案例中为什么能够“不对游戏玩家造成任何重大影响”？按理解游戏类型的应用一旦迁移到云则会产生较大的用户体验影响。是否有其他更合适的案例？
2. 核心逻辑：云边协同场景中，为了应对用户移动性、供应商锁定等问题，需要实时迁移 -> 容器是现有主流基础设施，因此本文考虑容器 -> 调度器对不同集群所拥有的管理权限不同、不同集群底层管理平台不同，因此需要有适应于“完全控制”、“有限控制”、“无控制”三种情况的迁移方法 -> 带来三大难点：检测权限、异构管理平台兼容、迁移目标选择
3. 具体咋做的迁移？在摘要中没有提及方法或核心思想
4. 没有完全控制权限的前提下需要使用哪些信息？是否有取舍？
5. “编排器级”、“服务级”、“容器级”分别代表什么含义？
6. FastFreeze是用来干啥的？如何运转？

---

---

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

🗺参考文献

[1] 论文引用