FastMig: Leveraging FastFreeze to Establish Robust Service Liquidity in Cloud 2.0

《FastMig: Leveraging FastFreeze to Establish Robust Service Liquidity in Cloud 2.0》

来源

2024 IEEE 17th International Conference on Cloud Computing (CLOUD)

1 为什么

1.1 背景需求

  • Cloud 2.0

    • 标志着下一代云计算，集成了人工智能、机器学习和物联网等尖端技术。
    • 此阶段强调更高的效率、可扩展性和异构资源的使用，为先进和创新的应用程序奠定了基础。

  • 服务

    • 被设想为真正的分布式，
    • 要么跨边缘到云以支持低延迟服务[18]，
    • 要么跨多云以获得高可靠性和成本效率[14]。

  • Cloud 2.0 中的下一代服务需要跨资源连续体 resource continuum的服务流动性 service liquidity。

    • 也就是说，服务必须能够在分布式和异构平台上自由执行和无缝重新定位relocate。
    • 除了未来的用例use cases之外，服务流动性还为日常 IT 运营提供了多种优势，
      • 例如促进维护任务（例如执行硬件升级）容灾
      • 以及通过在主机之间动态重新分配工作负载而不中断其运营来提高资源利用率。负载均衡
    • 建立服务流动性需要一种从一台主机到另一台主机的无缝实时服务迁移解决方案，而不会降低体验质量。

  • 一个示例

    • 边缘下联邦学习federated learning场景：
      • 其中模型训练仅在本地边缘服务器上进行，以保护用户的数据隐私。
      • 训练好的模型被传输到中央（云）服务器以执行模型聚合[27]。
      • 在这种情况下，数据收集通常在移动用户的设备（例如智能手机）上执行，该用户往往会随机从一台边缘服务器断开连接并连接到另一台边缘服务器。如果必须重新训练模型，这种移动性可能会减慢训练速度。
      • 然而，跨边缘服务器实时迁移训练服务的能力可以在新的边缘服务器上无缝恢复训练过程，从而节省训练时间[27]。

  • 需要一种独特的方法，

    • 其目标不是迁移整个容器，而是仅迁移“服务的嵌入式进程”，
    • 以最大限度地减少开销overhead、
    • 最大限度地提高可移植性并满足多云优势。

1.2 研究现状

  • 容器迁移
    • 容器技术是一种虚拟化技术，它捆绑应用程序及其所有依赖项，提供应用程序隔离并使应用程序可迁移，同时保留完整的功能[9]，[21]。
    • 在系统之间迁移容器化服务的能力有利于通过负载平衡或容错来提供服务。
    • 在较高的层面上，对于实时迁移，容器化服务迁移可以通过对容器内的进程设置检查点、将检查点文件移动到目的地并将容器恢复到其原始状态来完成[25]。
  • 在现代云环境中，为了可移植性和隔离性，服务越来越容器化，人们研究了各种迁移方法，包括
    • 需要容器运行时checkpoint/restore功能的方法[25]
    • 和嵌套的容器嵌套方法[6]
  • 有一些技术可以帮助减少传输过程中的停机时间，例如预/后复制pre/post-copy [23] 或页面服务器page-server [25]，但总体操作保持不变。
  • 用于执行容器检查点/恢复操作的主要工具是CRIU[1]。
    • 优点
      • CRIU 通过使用 ptrace 来实现这一点，ptrace 是一个用于检查当前进程执行和使用的内存的内核接口。
      • CRIU 还可以与多进程应用程序配合使用，因为它可以检查点并恢复整个进程树。
    • 局限
      • 使用 CRIU 恢复应用程序时，应用程序进程的 PID 必须与设置检查点之前相同。
      • 需要足够的权限或权限（例如 root 或 CAP_SYS_ADMIN 功能2），CRIU 才可以在恢复时实现所需的 PID。
        • 控制进程 PID 的另一个解决方案是修改文件 /proc/sys/kernel/ns_last_pid ，该文件指示最后分配的 PID 并确定当前 PID 命名空间中的下一个 fork PID ，以满足其需要（例如，所需的 PID-1 ）。
  • FastFreeze 是专为容器化服务构建的检查点/恢复实用程序。
    • 它是 CRIU 的包装wrapper；因此，FastFreeze 将主要进程检查点/恢复委托给 CRIU。
    • FastFreeze 提供检查点/恢复的管理工具，提供定制的 init 进程使容器化服务处理其子进程。
      • 容器init进程是容器进程树的根。其状态代表容器状态；例如，如果容器的 init 进程退出，则认为该容器已关闭。
      • init进程还负责其他职责，例如向子进程转发信号和收割僵尸进程。
    • 此外，FastFreeze 设计为可在非特权容器中使用。
      • 它使用一种称为fork bomb的技术，快速fork并杀死子进程，直到它获得所需的 PID，以便在恢复时处理 CRIU PID 要求。
      • 对于单进程应用恢复来说，延迟并不显着；然而，对于多进程应用程序[13]，叉子炸弹程序的延迟可能会很大。
      • Chanikaphon 等人 [6] 表明，使用 FastFreeze 的迁移方法每增加 1 个子进程，迁移开销就会增加约 40 秒。
    • 最后，FastFreeze 仅提供了一个命令行界面来激活其所有操作；
      • 这导致容器访问权限、同步和监控方面的迁移需求存在障碍。
    • 此外，缺乏易于使用/标准的接口阻碍了与Web服务的集成，并导致与面向服务的架构（SOA）不兼容。

1.3 挑战

  • 由于现代容器的设计以及跨系统迁移过程的不确定性，简单地将现有的检查点/恢复解决方案（例如 FastFreeze）导入到容器镜像中很容易失败。
    • 在传统容器中，服务进程在检查点步骤完成后退出。
    • 然后，整个容器被运行时视为已关闭，并失去执行正常关闭指令的机会，这可能会对源系统产生不利影响。
      • 例如，服务的退出行为可能与预期不同，可能会中断源系统的后续操作。
  • 此外，在迁移期间绑定容器化服务管理和执行（或者换句话说，将容器启动与容器化服务启动绑定）会限制容器化服务的热恢复warm-restored。
    • warm-restored指执行容器启动指令并非必须等待检查点文件完成传输。
  • 结论是，我们意识到缺乏以下过程阻碍了强大的容器迁移服务：
    • post-checkpointing
    • pre-restoration

2 做什么

2.1 解决方案（创新点）

  • 本文做出以下贡献：
    • 开发FastMig，一种实时容器化服务迁移解决方案，将FastFreeze与服务管理层相结合，实现服务流动性
    • 开发 FastFreeze Daemon，将容器化服务管理与其执行分离。它支持post-checkpointing和pre-restoration操作，并采用warm-restored技术来减少迁移时间。
    • 开发可配置的容错机制，通过允许在不重新创建容器的情况下重新启动服务来增强服务流动性的稳健性。
    • 扩展 FastFreeze 以缩短迁移时多进程服务的恢复时间，并开发标准 API 以使 FastMig 可插入其他解决方案。
    • 评估和分析 FastMig 在现实场景和设置下的影响

2.2 总体框架

  • 该系统利用改编后的 FastFreeze 来跨计算系统提供强大的服务流动性。
  • 该系统由 5 个主要模块组成：
    • (A) the FastMig Interface，允许来自外部的请求；
    • (B) FastFreeze Daemon，提供容器化服务管理；
    • (C) FastFreeze，利用 CRIU 进行检查点/恢复操作，并充当容器化服务的父进程。服务，
    • (D) the containerized service
    • (E) the Fault Handling Module，它是用于处理日志故障的可配置逻辑。
  • 还有另一个组件称为启动选项配置the Start Option Config，它是指示如何启动服务的文件。

2.3 采用 FastFreeze 建立稳健性

  • 为了增强稳健性，我们解决了三个关键方面。

    • 服务管理解耦

      • 对于现代容器化服务，容器和容器化服务执行是绑定在一起的。
        • 例如，当服务退出时，容器也退出，服务随着容器启动而启动。
      • 此因素限制了在迁移期间管理容器化服务生命周期的能力。
      • 为了建立服务流动性的稳健性，我们构建了一个解决方案，使我们能够将容器化服务管理（例如状态）及其执行分开。
        • FastFreeze作为容器化服务的父进程，覆盖服务执行层；
      • 因此，我们为服务管理层开发了一个名为 FastFreeze Daemon 的组件:FastFreeze Daemon 为容器化服务提供备用行为。
      • 当内部服务未运行时，容器可以处于运行状态。
      • 由于 FastFreeze Daemon 是容器中第一个且始终运行的进程，因此在待机模式下，它会侦听传入的请求以运行服务、恢复或从头开始启动。
      • 配备 FastFreeze Daemon 的容器化服务可以通过三种不同的方式启动，如图 4 所示：
        • (i) 从头开始​​启动服务，忽略检查点;
        • (ii) 从给定检查点恢复服务；
        • (iii) 保持待命状态——不运行该服务。
      • 通过向 FastFreeze 提供指示启动模式和相关信息的启动选项配置，可以配置每种情况的启动行为。
      • 如果未提供配置，FastFreeze Daemon 默认保持待机模式。

    • 容错机制

      • 传统的 FastFreeze 已经实现了一项功能，供用户（即服务开发人员）插入指标记录器程序，该程序使用 FastFreeze JSON 结构的日志作为其参数。

      • 我们开发了故障处理模块

        • 用于分析服务如何退出的日志并决定如何重新启动。
        • 之后，它将其决定输出到启动选项配置中
        • 然后 FastFreeze 守护程序在下一次服务启动时读取它。

      • 综上所述，我们使用自我反馈方法进行类比。

      • 基于服务退出代码作为演示。上述逻辑的伪代码如清单 1 所示。该逻辑表明，当服务按照代码 0 正常退出时，FastFreeze Daemon 将在下次启动时尝试从检查点文件中恢复服务，如果服务退出则通过接收信号，包括来自FastFreeze检查点操作的信号，启动选项将为待机；否则，FastFreeze Daemon 将强制服务从头开始。

      • 在其他用例中，根据不同的要求，用户可以指定容器化服务在发生特定故障和情况后如何重新启动的逻辑。

    • The FastMig Interface

      • FastMig 接口公开了可从容器外部使用的 FastFreeze 操作。具体来说，HTTP 接口是在 FastFreeze Daemon 中实现的。
      • 通过提供的HTTP API，外部实体可以通过发送请求来调用迁移命令，与命令行执行不同，HTTP请求不需要容器访问权限。
      • 因此，这增强了 FastFreeze 与其他系统的集成并增强了迁移操作的安全性。我们通过修改 FastFreeze 以在每次操作后通过 Unix 域套接字进行通信来实现此目的。
      • FastMig 不断监听套接字，等待操作完成标志，然后响应客户端。 FastMig 接口的 API 模仿 FastFreeze 命令，因此它有两个主要 API，即运行 API 和检查点 API。
      • 两个 API 均接受与每个 FastFreeze 命令一致的 JSON 请求正文。 FastMig Interface收到请求后，处理请求体和Startup Option Config；然后它会生成带有提取参数的 FastFreeze。
      • HTTP 接口和 FastFreeze 命令行界面之间的另一个显着行为差异是 API 是同步的，而之前的命令行不是同步的。 FastMig 接口仅在调用的操作结束后（完成或失败（例如，应用程序成功启动））才响应客户端。
      • 此特性使检查点/恢复和迁移操作更加可追踪，并简化了测量其持续时间的评估。

2.4 使 FastFreeze 适应多进程服务

  • 在非特权场景中使用 FastFreeze 恢复多进程服务时可能会出现明显的延迟。

    • 这通常是 FastFreeze 使用叉子炸弹解决方法引起的正常和实际情况。
    • 我们的检查表明，当前的 FastFreeze 解决方案首先尝试编辑 /proc/sys/kernel/ns_last_pid 以设置所需的进程 ID，如果不能，它将使用 fork 炸弹，直到获得所需的 ns_last_pid，如清单 2 所示。

  • 为了避免延迟，它必须通过允许 FastFreeze 写入 /proc/sys/kernel/ns_last_pid 来防止 fork 炸弹，同时仍然不向容器和 FastFreeze 本身过度授予权限。为此，有两个限制阻止 FastFreeze 编辑 /proc/sys/kernel/ns_last_pid：(i) 如果没有 root 权限，FastFreeze 无权编辑 /proc/sys/kernel/ns_last_pid，这是一个系统文件，(ii)在典型的容器环境中（例如 Kubernetes [3]、Docker [2]），容器挂载 /proc 目录作为只读目录。

  • 从Linux内核版本5.9开始，它引入了一个名为CAP_CHECKPOINT_RESTORE [20]的新功能，它提供了通过编辑ns_last_pid和clone3系统调用来控制相应PID命名空间的PID的能力。有了这个能力，第一个限制就可以克服。为了解决第二个限制，我们研究了在 Docker 容器中运行 FastFreeze 的情况，并调整 Docker 安全选项 systempath=unconfined 和 apparmor=unconfined 以允许访问系统目录。然而，禁用 AppArmor 允许对所有系统文件进行写入访问，并可能导致安全问题。

    • AppArmor 是 Linux 的强制访问控制 (MAC) 系统。它与 Docker 容器交互作为另一层安全性。 Docker 容器应用默认的 AppArmor 配置文件，限制操作和访问，例如避免编辑 /proc 文件系统。用户不仅可以禁用 AppArmor，还可以提供安全的自定义配置文件以进行强化。

  • 因此，它必须与自定义 AppArmor 配置文件一起设置，仅允许修改 ns_last_pid，但不允许修改 /proc 文件系统中的其他文件。

  • 清单 3 中显示了避免 fork 炸弹延迟的 Docker 配置示例，以及清单 4 中的 AppArmor 配置文件条目。

3 实验

  • 为了评估FastMig是否能够以最小的开销和停机时间进行实时容器迁移，同时仍然具有容错机制的鲁棒性，我们在以下指标中总结了多个方面的评估：
    • 1 将 FastFreeze 和 FastMig 合并到容器中导致的服务性能开销是否增加
    • 2 授予适当权限时服务恢复时间是否改进
    • 3 使用 FastMig 和热恢复时迁移时间是否改进
    • 4 迁移性能的容错机制及其对各类故障的覆盖范围

3.0 实验设置

  • 我们创建了 Ubuntu 22.04 LTS 虚拟机，将每个虚拟机表示为具有 4 个 vCPU、16 GiB 内存和 100 GiB 存储的物理计算节点。
  • 所有虚拟机均通过 1 GiB 以太网连接。我们使用 Docker 版本 25.0.1 作为容器引擎，使用 FastFreeze 版本 1.3.0。
  • 实验中执行的实时迁移采用stop-and-copy方法，通过对容器设置检查点，将检查点文件转储到共享文件系统（NFS），并使用共享检查点文件在目的地恢复容器
  • 在大多数实验中，我们部署了 2 个具有不同内存占用行为的不同应用程序，因为它是迁移性能的关键因素。
    • 首先，我们部署了一个名为 memhog 的流行基准测试应用程序 [25]。
      • 我们配置 memhog 将随机数据写入分配的内存并每秒打印一个计数器编号，代表静态内存占用应用程序。
    • 其次，我们配置了 YOLOv3-tiny [22]，一个流行的对象检测应用程序，从其存储库中为其提供输入图像 (160KB)。
      • 与 memhog 不同，YOLOv3-tiny 具有动态内存占用。

3.1 资源使用和性能开销（无迁移）

  • 本实验旨在通过测量正常操作（即无迁移）期间的服务性能来评估将 FastFreeze 和 FastMig 合并到容器中的影响。

  • 为此，我们配置了三种容器，并比较容器资源使用情况和性能。包括

    • （A）常规Ubuntu容器
    • （B）运行FastFreeze的Ubuntu容器
    • （C）运行FastMig的Ubuntu容器

  • 首先，我们使用 memhog 基准测试（每个容器上的静态内存占用为 128 MiB），使用 docker stats 检查 CPU 使用率和内存使用率 30 次并计算平均值。

    • CPU 使用率没有显着差异。
    • 对于内存使用，使用 FastFreeze 的容器比常规容器多使用 <1 MiB
      • 因为 FastFreeze 将生成一个进程（在 II-B 中称为自定义 init 进程）并充当服务父进程。
    • FastMig 容器的内存使用量增加了 1 MiB。
      • 现代容器的平均内存占用量在每个容器 50 MB 到 300 MB 之间 [13]，
    • 但我们得出的结论是，资源使用开销非常可以忽略不计。

  • 其次，我们利用 iperf3 [10] 基准测试来测量网络比特率，并利用 Sysbench [16] 来测量性能指标，

    • 指标包括
      • CPU 速度（以每秒处理的事件数）
      • 内存访问吞吐量
      • I/O 读/写吞吐量。
    • 我们在每个容器上运行每个基准测试 30 次。
    • 结果表明所有测试用例的性能均没有显着下降。

3.2 多进程应用程序恢复时间

  • 与多进程应用程序一起使用时，FastFreeze 恢复时间异常长，并会影响迁移期间的服务停机时间。
  • 我们进行了实验，比较了在没有额外权限的情况下使用 FastFreeze 和允许其修改 /proc/sys/kernel/ns_last_pid 之间的迁移时间。
  • 我们以之前的实验类似的方式部署 memhog。
    • 单个容器中运行的 memhog 进程数量为 2-16，比例因子为 2
    • 针对具有不同进程数量的每种情况执行了 30 轮
  • 当允许 FastFreeze 修改 ns_last_pid 文件时，与使用具有相同进程数的非特权 FastFreeze 相比，迁移时间显着减少。
    • 对于两个进程，迁移时间减少了约 30 秒，对于 16 个进程，减少幅度更大，即约 450 秒。
    • 这些差异主要受到恢复时间差异的影响，因为在具有相同服务进程数的情况下，检查点时间大多相同。

3.3 测量实时迁移的开销

  • 此实验首先测量使用 FastFreeze 进行实时迁移的迁移时间开销，其次使用允许在目的地进行热恢复的迁移的 FastMig。
    • memhog 和 YOLOv3-tiny 这两个应用程序都是为此目的而配置的。
  • 为了强调热恢复的影响，它通过省略目的地的容器启动时间来改善容器迁移时间，我们测量了容器上暴露的不同端口数量的迁移时间，因为暴露的端口数量是影响容器启动时间的一个因素。
    • 每个测试进行 30 次，测量从检查点阶段到目的地完全恢复的总时间。
  • 从结果来看
    • 当不使用 FastMig 并且不允许在目的地进行热恢复时，迁移时间随着端口数量的增加而线性增加。其与使用 FastMig 和热恢复相比，迁移时间没有显着增加，即约 2 秒。
    • checkpoint时间比restore时间受到(热恢复)的影响要小。这显示了热恢复的好处。
  • 当使用 YOLOv3-tiny 作为评估应用程序时，也发生了相同的情况。
    • 尽管公开 50 个端口是一个不常见的用例，但它强调了隐藏容器启动时间的影响。
    • 此外，即使只暴露 10 个端口，FastMig 也展示了大约 1 秒的改进，这对于实时迁移用例来说已经很重要了。
    • 需要注意的是，暴露端口不仅会影响容器启动时间，图像大小和图像层数等其他因素也会影响整体启动持续时间[26]。
  • 此外，我们观察到使用 FastMig 时的迁移时间会不一致。
    • 每个案例之间的checkpoint时间是均匀的，但restore时间却不是。
    • 由于恢复操作依赖于节点之间的网络（例如跨节点的操作请求、从网络文件系统读取检查点），我们推测迁移时间不一致是由于网络不一致而发生的。

3.4 容错机制的作用

  • 我们提出的解决方案依赖于日志记录机制，并且我们构建了一个可配置函数（在故障处理模块中使用）来决定容器应如何重新启动。
  • 本实验重点评估该机制的开销，通过使用具有不同时间复杂度的不同字符串处理逻辑（函数），包括 O(1)、O(n)、O(n2) O(n3) 以及不使用的情况。
    • 我们将输入大小 (n) 定义为我们输入的服务日志的行数。
    • 我们利用 2000 行 Apache Web 服务器日志作为模拟输入日志 [29]。
    • 实验针对每个函数时间复杂度进行了 30 次重复。
  • 容错机制引入了约 0.2 秒的可忽略不计的额外迁移开销。
  • 由于 n 的大小很小，因此在函数时间复杂度上，开销几乎是恒定的；然而，数千行日志通常足以确定故障原因和适当的启动选项配置。

3.5 容错机制覆盖范围

  • 为了确定容错机制如何应对各种类型的故障，我们设置了一个故障注入实验，故意在容器迁移的每个阶段引发常见故障并检查其行为。
  • 为了提供各种特定用例的通用性，我们使用默认逻辑，在本实验中根据 FastFreeze 退出代码确定 FastFreeze 重新启动状态。
    • 在可能的情况下，每个故障在每种情况下都被注入十次。
  • 如果应用程序和 FastFreeze 重新启动并且仍然正常运行（例如，可以在事件修复后设置检查点/恢复或迁移），这将被指示为有效结果。
    • 表 II 报告了设置错误。有些故障未包含在实验中，因为它们在该阶段不可能发生。
  • 大多数结果都是有效的，但只有应用程序恢复期间的网络故障是例外。
    • 发生这种情况是因为 FastFreeze 等待从 NFS 服务读取检查点文件，而由于网络断开，该服务无法到达其对等方。
    • NFS 无限期地阻止 FastFreeze 进程并等待重新连接，而不会超时。
    • 在这种情况下，用户必须手动停止容器或等待网络重新连接，这会导致 NFS 服务解除阻塞进程并恢复恢复。
  • 此外，我们观察到容错机制的两个局限性，尽管结果是有效的。
    • 首先，如果在服务检查点或恢复过程中发生故障，则中断操作的进度将被丢弃；然后，从头开始下一次尝试相同的操作。
      • 例如从相同的检查点文件进行第二次恢复，就好像以前从未运行过一样。
    • 其次，对于系统/硬件故障，行为可能取决于系统（即操作系统）如何作用于容器。
      • 例如，当系统正常关闭并向容器中的进程发送终止信号时，故障处理模块将控制FastFreeze重启模式为待机模式，但在另一种情况下，当没有信号发送到容器中的进程时，故障处理模块将控制FastFreeze重启模式为待机模式。
      • 容器（即硬关闭）时，逻辑没有任何机会评估故障。
      • 结果重启后会进入待机模式作为默认模式或将处于上一个功能触发的启动选项配置中指示的状态。
posted @ 2024-11-09 00:06  DarkLights  阅读(39)  评论(0)    收藏  举报