当开发人员将工作负载部署到云计算平台时，他们往往不会停下来考虑其服务所运行的底层硬件。在理想化的 "云 "形象中，硬件维护和物理限制是不可见的。不幸的是，硬件偶尔需要维护，这可能会导致停机。为了避免将这种停机时间转嫁给我们的客户，并践行云计算的承诺，Linode 实施了一种称为实时迁移的工具。
实时迁移是一项技术，允许Linode实例在物理机之间移动而不中断服务。当一个Linode通过实时迁移被移动时，过渡对该Linode的进程是不可见的。如果一个主机的硬件需要维护，实时迁移可以用来将该主机的所有Linode无缝过渡到一个新主机。在这个迁移完成后，物理硬件可以被修复，而且停机时间不会影响到我们的客户。
对我来说，开发这项技术是一个决定性的时刻，是云技术和非云技术之间的转折点。我对实时迁移技术情有独钟，因为我花了一年多的时间来研究它。现在，我可以和大家分享这个故事了。
实时迁移是如何进行的
Linode的实时迁移像大多数新项目一样开始；有大量的研究，一系列的原型，以及许多同事和经理的帮助。第一个进展是调查QEMU如何处理实时迁移。QEMU是Linode使用的一种虚拟化技术，而Live Migrations是QEMU的一个功能。因此，我们团队的重点是将这项技术带到Linode，而不是发明它。
那么，Live Migration技术是如何以QEMU的方式实现的呢？答案是一个四步过程：
- 目标qemu实例以与源qemu实例上存在的完全相同的参数被启动。
- 磁盘被实时迁移过来。在这个转移过程中，对磁盘的任何改变也会被告知。
- RAM是实时迁移过来的。任何对RAM页面的改变也必须被告知。如果在这个阶段也有任何磁盘数据的变化，那么这些变化也将被复制到目标QEMU实例的磁盘上。
- 切换点被执行。当QEMU确定有足够多的RAM页可以放心地进行切换时，源和目的QEMU实例就会暂停。QEMU复制最后几页RAM和机器状态。机器状态包括CPU缓存和下一条CPU指令。然后，QEMU告诉目标程序开始，目标程序就从源程序停止的地方开始工作。
这些步骤从高层次上解释了如何用QEMU进行实时迁移。然而，确切地指定你希望目标QEMU实例如何启动是一个非常手动的过程。而且，这个过程中的每个动作都需要在正确的时间启动。
实时迁移是如何在Linode实施的
在看了QEMU开发者已经创建的东西之后，我们如何在Linode利用这个东西？这个问题的答案是我们团队大部分工作的地方。
根据 "实时迁移 "工作流程的第 1 步，启动目标 QEMU 实例，以接受传入的 "实时迁移"。在实施这一步时，我们首先想到的是将当前 Linode 的配置文件在目标机器上启动。这在理论上很简单，但进一步思考后会发现情况更为复杂。尤其是，配置文件会告诉你 Linode 是如何启动的，但并不一定能描述启动后 Linode 的完整状态。例如，用户可以通过将设备热插拔到 Block Storage设备，但这不会记录在配置文件中。
为了在目标主机上创建QEMU实例，必须对当前运行的QEMU实例进行剖析。我们通过检查QMP接口对当前运行的QEMU实例进行剖析。这个界面给我们提供了关于QEMU实例是如何布置的信息。它并不提供从客户的角度看实例内部正在发生什么的信息。它告诉我们磁盘插在哪里，虚拟磁盘插在哪个虚拟化的PCI插槽上，包括本地SSD和块存储。在查询了QMP并检查和内省了QEMU实例后，建立了一个配置文件，准确地描述了如何在目的地复制这个机器。
在目标机器上，我们收到源实例的完整描述。然后我们可以在这里忠实地重新创建这个实例，但有一点不同。不同的是，目标QEMU实例在启动时有一个选项，告诉QEMU接受传入的迁移。
在这一点上，我们应该从记录实时迁移中休息一下，转而解释一下QEMU是如何实现这些壮举的。QEMU的进程树是由一个控制进程和几个工作进程组成的。其中一个工作进程负责返回QMP调用或处理实时迁移等事务。其他进程一对一地映射到客户的CPU上。客人的环境与QEMU的这一边隔离，作为它自己的独立系统行事。
在这个意义上，我们有3个层面的工作：
- 第1层是我们的管理层；
- 第2层是QEMU进程的一部分，为我们处理所有这些动作；以及
- 第3层是Linode用户与之互动的实际客户层。
在目的地启动并准备好接受传入的迁移后，目的地硬件让源硬件知道，源应该开始发送数据过来。源端一旦收到这个信号就会开始，我们在软件中告诉QEMU，开始磁盘迁移。软件会自主地监控磁盘的进度，以检查它何时完成。当磁盘完成后，软件会自动切换到RAM迁移。然后软件再次自主监控RAM迁移，并在RAM迁移完成后自动切换到切换模式。所有这些都是通过Linode的40Gbps网络进行的，所以网络方面的事情是相当快的。
切换：关键部分
切换步骤也被称为实时迁移的关键部分，理解这个步骤是理解实时迁移的最重要部分。
在切换点，QEMU已经确定它已经准备好切换并开始在目标机器上运行。源QEMU实例指示双方暂停。这意味着几件事：
- 时间根据客人的情况停止。如果客户机正在运行像网络时间协议（NTP）这样的时间同步服务，那么NTP将在实时迁移完成后自动重新同步时间。这是因为系统时钟会落后几秒。
- 网络请求停止。如果这些网络请求是基于TCP的，如SSH或HTTP，将不会有感知的连接损失。如果这些网络请求是基于UDP的，如实时流媒体视频，它可能会导致一些丢帧。
因为时间和网络请求都停止了，我们希望切换尽可能快地发生。然而，有几件事我们需要先检查一下，以确保切换的成功：
- 确保实时迁移的完成没有错误。如果有错误，我们就回滚，取消源Linode的暂停，不要再继续下去了。这一点在开发过程中特别花了很多试验和错误来解决，它是很多痛苦的来源，但我们的团队最终找到了它的底部。
- 确保网络要在源头关闭，在目的地正确启动。
- 让我们基础设施的其他部分清楚地知道这个Linode现在驻扎在什么物理机器上。
由于切换有时间限制，我们希望迅速完成这些步骤。在解决了这些问题后，我们完成了切换。源Lanode自动获得完成的信号，并告诉目的地开始。目的地的Linode会在它离开的地方继续工作。源节点和目的地节点上的任何剩余项目都被清理掉。如果目标节点在未来某个时间点需要再次进行实时迁移，可以重复这一过程。
边缘案例概述
这个过程的大部分都是直接实施的，但实时迁移的开发被边缘案例所扩展。完成这个项目的很大功劳要归功于管理团队，他们看到了完成工具的愿景，并分配了资源来完成任务，还有那些见证项目完成的员工。
以下是遇到边缘案例的一些领域：
- 必须建立内部工具，为Linode客户支持和硬件运营团队协调实时迁移。这与我们当时拥有和使用的其他现有工具相似，但又有足够的不同，因此需要大量的开发工作来建立它：
- 优雅地处理故障情况，包括终端用户的干预或实时迁移过程中的网络损失。这些故障情况将在本篇文章的后面部分详细列举。
- 跟上Linode平台的变化，这是一个持续的过程。对于我们现在和将来在Linode上支持的每一个功能，我们必须确保该功能与实时迁移兼容。这个挑战在本篇文章的末尾有描述。
CPU标志
QEMU对如何向客户操作系统展示CPU有不同的选择。其中一个选项是将主机CPU的型号和功能（也被称为CPU标志）直接传递给客户。通过选择这个选项，来宾可以使用KVM 虚拟化系统所允许的全部不受约束的能力。当KVM 最初被Linode采用时（在Live Migrations之前），选择这个选项是为了最大化性能。然而，这一决定后来在Live Migrations的开发过程中出现了许多挑战。
在实时迁移的测试环境中，源主机和目标主机是两台相同的机器。在现实世界中，我们的硬件机群并不是100%相同的，机器之间的差异会导致不同的CPU标志的出现。这很重要，因为当一个程序在Linode的操作系统内加载时，Linode会向该程序提出CPU标志，该程序会将软件的特定部分加载到内存中，以利用这些标志。如果一个Linode被实时迁移到一个不支持这些CPU标志的目标机器上，程序将崩溃。这可能导致客户操作系统崩溃，并可能导致Linode重新启动。
我们发现有三个因素影响到机器的CPU标志如何呈现给客人：
- CPU之间有微小的差异，这取决于CPU的购买时间。在年底购买的CPU可能与年初购买的CPU有不同的标志，这取决于CPU制造商何时发布新硬件。Linode不断购买新硬件以增加容量，即使两个不同硬件订单的CPU型号相同，CPU标志也可能不同。
- 不同的Linux内核可能会向QEMU传递不同的标志。特别是，实时迁移的源机器的Linux内核可能会向QEMU传递与目标机器的Linux内核不同的标志。更新源机器上的Linux内核需要重新启动，所以这种不匹配不能通过在进行实时迁移之前升级内核来解决，因为这将导致该机器上的Linodes停机。
- 同样地，不同的QEMU版本会影响到哪些CPU标志的呈现。更新QEMU也需要重新启动机器。
因此，实时迁移需要以一种防止CPU标志不匹配导致程序崩溃的方式来实现。有两个选项可供选择：
- 我们可以告诉QEMU来模拟CPU的标志。这将导致过去运行速度快的软件现在运行速度慢，而且没有办法调查原因。
- 我们可以在源程序上收集一个CPU标志的列表，并在继续进行之前确保目的地也有这些标志。这比较复杂，但它可以保持我们用户的程序速度。这就是我们为实时迁移实施的选项。
在我们决定匹配源和目的地的CPU标志后，我们用一种包括两种不同方法的皮带和吊带的方法完成了这项任务：
- 第一种方法是两种方法中比较简单的。所有的CPU标志都从源站点发送到目标硬件。当目标硬件设置新的qemu实例时，它检查以确保它至少拥有源Linode上的所有标志。如果它们不匹配，实时迁移就不会进行。
- 第二种方法要复杂得多，但是它可以防止因CPU标志不匹配而导致的迁移失败。在启动实时迁移之前，我们创建一个具有兼容CPU标志的硬件列表。然后，从这个列表中选择一个目标机器。
这第二种方法需要快速执行，而且它带有很大的复杂性。在某些情况下，我们需要在900多台机器上检查多达226个CPU标志。编写所有这些226个CPU标志的检查将是非常困难的，而且它们必须被维护。这个问题最终由Linode的创始人Chris Aker提出的一个惊人的想法解决了。
关键的想法是把所有的CPU标志做成一个列表，并以二进制字符串的形式表示。然后，可以用比特和操作来比较这些字符串。为了演示这种算法，我将从以下一个简单的例子开始。考虑一下这段Python 代码，该代码使用bitwise and对两个数字进行比较：
>>> 1 & 1
1
>>> 2 & 3
2
>>> 1 & 3
1为了理解为什么顺时针和操作会产生这些结果，用二进制表示数字是有帮助的。让我们来看看用二进制表示的数字2和3的顺位和运算：
>>> # 2: 00000010
>>> # &
>>> # 3: 00000011
>>> # =
>>> # 2: 00000010比特和操作比较两个不同数字的二进制数字，或比特。从上述数字中最右边的数字开始，然后向左进行：
- 2和3的最右边/第一位分别为0和1。的位数和结果为
0 & 1是0。 - 2和3的最右边第二位对这两个数字来说都是1。的位数和结果为
1 & 1是1。 - 这些数字的所有其他位都是0，0和0的位和结果是0。
那么，全部结果的二进制表示是 00000010，等于2。
对于实时迁移，CPU标志的完整列表被表示为一个二进制字符串，其中每个位代表一个标志。如果该位是0，那么该标志就不存在，如果该位是1，那么该标志就存在。例如，一个位可能对应于AES标志，另一个位可能对应于MMX标志。这些标志在二进制表示中的具体位置由我们数据中心的机器维护、记录和共享。
维护这种列表表示法比维护一组假设检查CPU标志是否存在的if语句要简单和有效得多。例如，假设有7个CPU标志需要被跟踪和检查。这些标志可以存储在一个8位的数字中（留出一位供将来扩展）。一个例子的字符串可以是这样的 00111011，其中最右边的位显示AES被启用，最右边的第二位显示MMX被启用，第三位表示另一个标志被禁用，以此类推。
如下面的代码片段所示，我们可以看到哪些硬件会支持这种标志组合，并在一个周期内返回所有的匹配结果。如果我们使用一组if语句来计算这些匹配，则需要更多的周期来实现这一结果。对于一个源机器上有4个CPU标志的Live Migration例子，将需要203,400个周期来找到匹配的硬件。
实时迁移代码对源机和目的机上的CPU标志串进行位和操作。如果结果等于源机器的CPU标志字符串，那么目标机器是兼容的。考虑一下这个Python 代码片段：
>>> # The b'' syntax below represents a binary string
>>>
>>> # The s variable stores the example CPU flag
>>> # string for the source:
>>> s = b'00111011'
>>> # The source CPU flag string is equivalent to the number 59:
>>> int(s.decode(), 2)
59
>>>
>>> # The d variable stores the example CPU flag
>>> # string for the source:
>>> d = b'00111111'
>>> # The destination CPU flag string is equivalent to the number 63:
>>> int(d.decode(), 2)
63
>>>
>>> # The bitwise and operation compares these two numbers:
>>> int(s.decode(), 2) & int(d.decode(), 2) == int(s.decode(), 2)
True
>>> # The previous statement was equivalent to 59 & 63 == 59.
>>>
>>> # Because source & destination == source,
>>> # the machines are compatible注意，在上面的代码片段中，目标机比源机支持更多的标志。这些机器被认为是兼容的，因为源程序的所有CPU标志在目标程序上都存在，这也是位和操作所确保的。
这个算法的结果被我们的内部工具用来建立一个兼容硬件的列表。这个列表会显示给我们的客户支持和硬件运营团队。这些团队可以使用该工具来协调不同的操作：
- 该工具可用于为特定的Linode选择最佳的兼容硬件。
- 我们可以在不指定目的地的情况下为一个Linode启动实时迁移。同一数据中心的最佳兼容硬件将被自动选择，迁移将开始。
- 我们可以把一个主机上的所有Linodes的实时迁移作为一个单一的任务来启动。这个功能是在对主机进行维护之前使用的。该工具将自动为所有的Linode选择目的地，并为每个Linode协调实时迁移。
- 我们可以指定一个需要维护的几台机器的列表，工具将自动协调所有主机上的Linodes的实时迁移。
大量的开发时间用于使软件 "只是工作"。
失败案例
在软件中不常被谈论的一个特点是优雅地处理失败的情况。软件应该是 "只是工作"。大量的开发时间用于使软件 "正常工作"，而这正是实时迁移的情况。我们花了很多时间来考虑这个工具不能工作的所有情况，并优雅地处理这些情况。下面是其中的一些情况，以及如何处理这些情况：
- 如果一个客户想从他们的Linode的一个功能中访问，会发生什么？ Cloud Manager?例如，用户可以重新启动 Linode 或将Block Storage 卷附加到它。
- 答复：：客户有权力这样做。实时迁移会被打断，不能继续进行。这个解决方案是合适的，因为实时迁移可以在以后尝试进行。
- 如果目的地Linode无法启动，会发生什么？
- 答案是：让源硬件知道，并设计内部工具来自动选择数据中心的另一块硬件。同时，通知运营团队，让他们调查原目的地的硬件。这种情况曾在生产中发生过，并由我们的实时迁移实施来处理。
- 如果你在迁移过程中失去了网络，会发生什么？
- 答案是：自主监测实时迁移的进度，如果在最后一分钟内没有任何进展，就取消实时迁移，并让运营团队知道。这在测试环境之外还没有发生过，但我们的实施方案已经为这种情况做好了准备。
- 如果互联网的其他部分关闭了，但源和目的硬件仍在运行并进行通信，而且源或目的Linode运行正常，会发生什么情况？
- 解答：如果实时迁移不在关键部分，请停止实时迁移：如果实时迁移不在关键部分，请停止实时迁移。然后稍后再尝试。
- 如果你处于关键部分，继续进行实时迁移。这一点很重要，因为源Linode已经暂停了，而目标Linode需要启动才能恢复操作。
- 在测试环境中对这些情况进行了模拟，并发现规定的行为是最佳的行动方案。
跟上变化的步伐
在经历了数十万次成功的实时迁移后，人们有时会问一个问题："实时迁移何时结束？"实时迁移是一项技术，其使用范围随着时间的推移而扩大，并不断得到完善，因此标记项目的结束不一定是直接的。回答这个问题的一个方法是考虑这个项目的大部分工作何时完成。答案是：对于可靠的、可信赖的软件来说，这项工作在很长一段时间内都不会完成。
随着时间的推移，为Linodes开发新的功能，必须进行工作以确保这些功能与Live Migrations的兼容性。当引入一些功能时，没有新的Live Migrations开发工作要做，我们只需要测试Live Migrations仍能按预期工作。对于其他功能，在新功能开发的早期，Live Migrations的兼容性工作被标记为一项任务。
就像所有的软件一样，总有一些更好的实施方法是通过研究发现的。例如，从长远来看，更模块化的Live Migrations集成方法可能会提供更少的维护。或者，有可能将实时迁移的功能融合到较低级别的代码中，这将有助于在未来的Linode功能中实现开箱即用。我们的团队考虑了所有这些选项，为Linode平台提供动力的工具是活的实体，将继续发展。
注释