揭秘IT界尚未全面考虑的问题：容器实时迁移

主要结论

• 实时迁移是指在客户端访问不中断的情况下移动应用程序实例。
• 实时迁移有助于促进服务器维护工作并缓解失衡负载等场景。
• 目前流行的实现策略包括“复制前（Pre-copy）”将状态复制到备用主机并切换流量，以及“复制后（Post-copy）”对初始状态进行复制并将残余组件置于“惰性加载（Lazy loaded）”状态下。
• 实时迁移面临的挑战包括：迁移过程中性能略微退化，如果依赖的服务（例如大数据或其他专有服务）在备用位置不可用将难以在主机间移动。

本文介绍了一个目前IT界尚未全面考虑过的问题：容器的实时迁移。这种技术的工作原理如何，能解决哪些问题？由于能为应用程序生命周期管理提供更大灵活性，塑造更丰富的使用场景，业界对这一技术的需求已经有了显著提升。

实时迁移到底是什么？

容器实时迁移是指在确保客户端访问不中断的情况下在不同的物理计算机或云平台之间移动应用程序的过程。在裸机硬件基础上运行容器所需的内存、文件系统，以及网络连接都可以从源主机转移至目标主机，同时可以确保状态持续不中断。

实时迁移可以解决的问题

实时迁移技术可以解决多种问题：

• 硬件维护期间的停机。当系统管理员需要升级硬件时，将所有客户从一个硬件节点移动至另一个硬件节点的过程极为痛苦，很多时候甚至不可能在不停机的情况下实现。
• 失衡的集群负载。当一个硬件节点开始过载，再平衡过程可能需要执行特定的应用程序模式以缩小可在集群中运行的工作负载的选择范围。
• 云平台故障。目前市面上有很多云平台，有时候这些云平台也会停机，更改定价策略，或服务质量退化。大部分情况下如何轻松地将应用程序从一个云供应商迁移至另一个供应商，这是个很大的问题。

备选解决方案

上述问题可通过多种方式解决。一起分析一下人们是如何使用实时迁移之外的其他方式解决这些问题的。

• 计划内停机。为了对集群进行维护，应用程序的所有者可以提前公布维护窗口和可能的停机，随后关闭硬件并等待所有变动均已完成后重新开机。这种方式的问题在于停机时间会非常长。
• 流量重路由。为了进行维护，可将每个应用程序的副本还原至另一个硬件节点，随后将流量重路由至新的副本，并将原先的副本关闭。这种方式的问题在于复杂性：应用程序必须明确针对这种情况进行设计才能实现高可用性和数据同步。此外这种方式需要使用更多的硬件资源。
• 微服务。将应用程序服务进一步细分至多个容器，并将容器分散保存在不同的物理服务器上，以避免硬件故障导致的停机。受影响的容器可以在活跃硬件节点上自动还原。然而这种方式的问题依然是复杂性，因为集群中的应用程序必须经过恰当的设计才能实现高可用并能在故障后还原。

实时迁移的工作原理

一起使用下面的结构看看实时迁移过程在技术上是如何实现的。

• 源节点 – 实时迁移前容器所在位置
• 目标节点 – 实时迁移后容器所在位置

为了执行实时迁移，平台首先需要将源节点的容器冻结，阻止内存、进程、文件系统，以及网络连接，并获得该容器的状态。随后将这些内容复制到目标节点。平台会在目标节点上还原状态并解冻容器，并在源节点执行一个快速的清理过程。

整个过程相当直观：获取状态，复制状态，还原状态。然而要注意，容器会在一段时间内处于冻结状态，因此在设计应用程序体系结构时需要考虑到这一问题，这一特点有可能让某些应用程序出现问题。

实时迁移解决方案有两种类型。其一是复制前内存（Pre-copy memory）。如果要迁移容器，平台会开始追踪源节点的内存使用，并将内存并行复制到目标节点，直到两个节点的内存差异实现最小化。随后平台会冻结容器，获取剩余的状态数据，将其迁移至目标节点，还原并解冻容器。

另一种解决方案是复制后内存（Post-copy memory），也可以叫做惰性迁移（Lazy migration）。系统会在一开始冻结源节点中的容器，从飞速变化的内存页中获取状态，将状态移动至目标节点并还原，然后解冻容器。随后用后台模式将剩余状态信息从源节点复制到目标节点。

取决于具体应用程序，通常每个容器需要冻结5-30秒。相比集群维护过程中长达数小时的停机，这个时间已经很短了。

实时迁移的用例

不停机硬件维护

在维护窗口中，容器可以用实时模式从一台物理硬件节点迁移至统一数据中心内的另一个节点，这一过程完全不造成停机。

负载平衡

通过实时迁移将容器从一个硬件节点迁移到另一个，借此实现负载平衡。通过实现相应的调度算法和触发器，这一切甚至可以自动完成。

同一硬件区域和数据中心内的高可用性

云服务供应商可以在一个或多个数据中心内预配置并提供一系列硬件可用性区域，因此最终用户可以在无需系统管理员介入的情况下执行容器的实时迁移，借此获得更多高可用性选项。

更换云供应商

实时迁移还可以帮助最终用户避免云基础结构供应商的锁定。应用程序可以迁移至另一个云服务供应商处，迁移过程中无需任何重配置或重部署操作。

瓶颈和潜在问题

如果想要通过实时迁移解决方案解决上述问题，还需要考虑到可能面临的各种挑战：

• 实时迁移过程中，容器冻结后可能会产生性能退化。对于某些可能无法接受任何性能退化（例如高负载的整体式实时应用程序）的应用程序来说这是个大问题。但是对于互联网上的大部分应用程序，尤其是Web应用程序，短时间内的冻结还是可以接受的。
• 另一个挑战与大数据和因为快速变化而无法在不同云供应商之间轻松移动的数据有关。网络延迟和数据量可能是成功实现实时迁移的最大障碍。
• 多云环境内的公有IP。使用公有IP地址的容器无法在不同云供应商之间迁移，因为IP地址只能留在各供应商自己的网络内。
• 如果容器内的应用程序使用了原生API或特定云服务供应商的原生云服务，跨云进行的实时迁移可能难以实现甚至完全不可行。

市面上的实时迁移产品

目前哪些公司提供了实时迁移产品？现在已经有多个产品可以对容器进行实时迁移。

• Virtuozzo – 正是该团队为容器开发了实时迁移技术，他们是这一领域的先锋，目前已经提供了可用于生产环境，包含实时迁移功能的容器引擎。
• runC，源自Open Containers Initiative，是另一个即将包含基于CRIU的实时迁移功能的容器引擎解决方案。
• Jelastic提供的容器编排平台为生产应用程序提供了跨越硬件区域、数据中心，以及云供应商进行实时迁移的功能。

演示：用实时模式迁移Minecraft

下列视频演示了使用实时模式将Minecraft应用程序从AWS不停机迁移至Azure的过程。

视频地址：https://www.youtube.com/embed/HfN4L6RFL10?list=PL88903F00A39DAF30

容器的实时迁移目前依然是一项比较新的技术。然而对企业来说这种技术的收益是显而易见的：不停机维护，无需花费大量时间对一切进行准备、确认，以及再次确认。因此这种解决方案是改善可用性，获得更高灵活性的好方法。如果你对于通过实时模式将容器从一个实例跨越数据中心移动到另一个实例有自己的经验，欢迎与我们一起分享。

关于本文作者

Ruslan Synytsky是Jelastic的CEO兼共同创始人，这家公司为DevOps提供了PaaS和托管业务。借助在IT界超过15年的经验，Ruslan已成为大规模分布式Java应用程序和企业平台领域的专家。在于2011年创办Jelastic之前，Ruslan是乌克兰国家航天局的重要工程主管，从事过多种创新式项目。Ruslan Synytsky有着丰富的科学经验，积极参与针对开发者、主机托管商、集成商，以及大型企业的各类技术大会。

本文译者：大愚若智