分布式边缘云中的快速透明虚拟机迁移

摘要

边缘云正成为一种流行的计算范式。在边缘云中,计算和存储可以分布于大量位置,使得应用能够在靠近终端用户的网络边缘运行。虚拟机实时迁移是一种关键机制,能够使应用在响应用户位置和工作负载变化时保持灵活和可移动性。

然而,边缘云中的虚拟机实时迁移面临诸多挑战。通过缓慢的广域网链路在地理上相隔较远的位置之间迁移虚拟机,会导致较长的迁移时间和应用的高不可用性。这是由于用户流量被重定向到新迁移的位置时存在网络重构延迟。本文提出利用多路径TCP来同时改善虚拟机迁移时间和应用的网络透明性。

我们在商用公共云环境和基于仿真实验室的边缘云测试平台中评估了我们的方法,使用了多种网络条件,结果表明,我们的方法可将迁移时间最多减少2倍,同时几乎消除了大多数应用的停机时间。

关键词
多路径TCP,广域网迁移,边缘计算,虚拟机实时迁移

CCS概念
• 网络 → 网络性能分析;云计算;数据中心网络;
• 软件及其工程 → 云计算;
• 一般与参考 → 实证研究;

版权声明:允许为个人或课堂教学目的制作本作品全部或部分的数字或纸质副本,但前提是不得出于盈利或商业利益复制或分发这些副本,且所有副本均须包含此声明及首页上的完整引用信息。若作品组件的版权属于非作者的其他方,则必须尊重其版权。允许在注明出处的前提下进行摘要引用。如需以其他方式复制、重新发布、上传至服务器或再分发至列表,必须事先获得特别许可和/或支付费用。请向permissions@acm.org申请权限。

SEC’17, 2017年10月12日至14日, 美国加利福尼亚州圣何塞/硅谷
c© 2017 版权由所有者/作者持有。出版权利授权予ACM。ISBN 978‐1‐4503‐5087‐7/17/10… $15.00
DOI: https://doi.org/10.1145/3132211.3134445

1. 引言

云计算已成为托管各种在线应用和服务的流行范式。当今的商业云计算平台采用准集中式架构,其中服务器和存储等云资源托管在少数大型全球数据中心中。尽管这样做可以为大量客户群提供规模经济和资源的统计多路复用,但通常意味着将云应用托管在距离其终端用户较“远”的云站点上。

最近出现了一种新的云计算架构,该架构基于边缘计算原则——即将服务器和存储等云资源分布在大量边缘云位置的小型集群中。应用可以托管在网络边缘,更靠近其终端用户,以最小化延迟。

云微粒[39]和其他[7, 11, 35]已倡导这种分布式边缘云模型。边缘云也可被视为内容分发网络(CDN)的自然演进,后者依赖位于边缘位置的服务器和存储来交付视频等内容。而在边缘云的情况下,边缘位置托管的是完整的应用而不仅仅是数据。

手机和物联网(IoT)设备的日益普及使边缘云成为运行新兴移动和物联网服务的有吸引力的选择。由于这些设备通常资源受限,它们可以依赖附近的边缘云服务器上的计算和存储来实现其服务(例如计算卸载[5, 14,21])。此外,边缘云能够提供低延迟(因其靠近移动或物联网设备),从而支持移动多人游戏或需要执行和紧密控制回路的物联网应用等应用,其中低延迟是一项关键需求。

边缘云有望支持一系列具有新需求的创新应用。以一部运行移动应用(例如Kinect风格的手势识别)的手机为例,该应用将资源密集型计算任务卸载到附近的边缘云。当用户从家前往工作地点再返回时,手机当前位置最近的边缘云会随着时间推移而发生变化。为了提供最低延迟,支持计算卸载的边缘云虚拟机需要“跟随用户”,在用户位置变化时透明地迁移到新的边缘云位置。

示意图0

位置。类似地,基于云的虚拟桌面——通过移动设备上的瘦客户端访问的基于云的虚拟机[17] 也需要迁移到不同的边缘云站点,以在用户移动性存在的情况下继续提供低延迟访问。研究人员还提倡“跟随太阳”[36, 40]应用,即全球团队的用户通过基于云的应用协同完成任务——随着太阳在每个大陆升起,云应用被迁移到新的边缘位置,为该大陆的团队成员提供低延迟访问。最后,诸如在线多人游戏之类的多用户应用可能会在多个边缘站点进行复制,并且随着用户群体随时间变化,各区域内的副本可能会被迁移以优化性能。

透明地将边缘云应用的运行状态从一个边缘云位置迁移到另一个位置,是实现上述场景的关键。假设边缘云服务器已虚拟化,一种简单的方法可能是将虚拟机[13]及其相关状态从一个位置实时迁移到另一个位置。然而,虚拟机热迁移最初是为数据中心内的局域网迁移设计的,在广域网场景下面临两个关键限制。首先,虚拟机的网络IP地址在不同广域网边缘云站点之间会发生变化,导致正在访问虚拟机服务的终端设备(如手机、平板电脑和物联网设备)无法保持透明连接。其次,边缘云站点之间的带宽可能比局域网带宽更为受限,从而增加了迁移成本。尽管已有一些针对广域网虚拟机迁移的研究[23, 36, 40],但这些系统依赖网络隧道技术或需要网络的显式支持,限制了其广泛应用。

我们的方法依赖于多路径TCP[32],,该技术目前在服务器[33]和移动操作系统平台(例如Linux[30],、安卓、苹果 iOS[3])中已广泛可用。多路径TCP依赖客户端和服务器上的多个网络接口,以通过多条网络路径并行发送和接收 TCP数据。我们使用MPTCP来加速虚拟机迁移,并掩盖由于广域网虚拟机迁移导致的IP地址变更的影响。

我们的方法还解决了现有虚拟机迁移研究尚未涉及的边缘云场景中的诸多实际挑战。我们方法的一个关键特点是,它仅依赖于端主机,而不依赖底层网络的支持。以往在虚拟机迁移过程中保持网络透明性的研究通常依赖隧道技术和软件定义网络[36, 40]。在可能跨越多个独立异构网络的边缘云中,依赖底层网络提供此类功能可能并不现实。边缘云带来的第二个挑战是广域网链路参数的变化,例如带宽、往返时间以及拥塞情况。我们研究了这种变化的影响,并证明了我们的方法在网络异构性和参数变化面前具有良好的鲁棒性。

在开发一种用于广域网虚拟机实时迁移的多路径方法时,我们做出了以下贡献:

基于多路径TCP的虚拟机迁移

我们展示了多路径TCP如何通过允许利用虚拟机监控器以充分利用增加的聚合带宽。这使得我们的系统能够加快磁盘和内存状态的传输,迁移完成时间约为常规TCP迁移的一半。

虚拟机客户端的网络透明性

传统的广域网迁移过程依赖于网络隧道等技术,这会增加终端用户在虚拟机迁移期间感知到的停机时间和延迟。这种方法不适用于边缘云环境,因为在边缘云环境中,目标是通过迁移虚拟机来降低客户端感知的延迟。我们的系统利用多路径TCP通知客户端已迁移虚拟机的新网络地址,并在保持连接激活的同时将客户端切换到新地址,从而降低客户端感知的延迟并提高迁移后吞吐量。

广域网优化的预拷贝算法

对于资源不足的站点,边缘云虚拟机迁移可能需要数十分钟,而不是传统局域网环境中的几秒钟。由于迁移时间较长,传统的预拷贝算法优化方法可能不再适用。我们提出了热跳过,这是一种针对边缘云广域网环境优化的新型预拷贝算法,通过基于历史写入频率对内存页进行分组,与现有的 KVM实时迁移相比,可将迁移时间减少20%。

公共和模拟云中的原型与实验

我们将迁移系统实现为KVM虚拟机监控器的原型包装脚本。我们在IBM SoftLayer网络以及基于实验室的边缘云模拟器测试平台上,针对多种边缘云条件对原型的性能进行了评估。结果表明,我们的系统将迁移时间减少了50%,并在迁移后将吞吐量提升了12%至60%,具体提升幅度取决于客户端到边缘云位置的距离。

因此,我们的方法提供了一种广域网虚拟机迁移,具备易于部署、带宽聚合、端点透明性以及针对广域网优化的预拷贝算法。

2. 背景

在本节中,我们介绍边缘云、虚拟化与迁移以及多路径传输协议的背景。

2.1 边缘云

边缘云从网络边缘的多个位置提供计算和存储等云资源,旨在为终端用户提供低延迟和高带宽的访问。如第1节所述,边缘云特别适合移动用户和物联网设备,其他研究(例如云微粒[39],雾计算[7],计算卸载[5, 14, 11])也论证了此类架构的优势。

本文中,我们假设一种边缘云架构,其中存储与计算集群部署在横跨广阔地理区域的数百或数千个位置(图1)。我们进一步假设边缘云平台提供与传统集中式云平台类似的抽象——客户可以请求计算或

一个或多个位置的存储资源,云平台将在选定的位置为应用提供虚拟化资源。与托管和分发内容的内容分发网络[29]不同,边缘云可以在虚拟机内托管任意应用,并利用边缘的计算和存储资源提供在线服务。

2.2 边缘云中的虚拟化

如图1所示,每个边缘云服务器都被假定为已虚拟化,并可托管一个或多个运行终端用户应用的虚拟机。我们假设虚拟机的“控制平面”跨越各个边缘云位置。也就是说,身份管理、访问控制、安全组等信息可以随虚拟机一同迁移,或已通过某种一致的分布式存储在所有边缘云位置上可用。鉴于边缘位置数量众多,客户虚拟机的初始部署取决于终端用户的位置——通常将虚拟机部署在附近的边缘云站点,以降低延迟并最大化终端设备到云托管应用之间的带宽。

然而,由于边缘云工作负载关注移动用户和设备,因此其动态性预计将高于传统云工作负载。移动用户具有游牧特性,会频繁改变位置。同样,物联网工作负载在何时何地观测到重要事件方面可能存在偏差,这就要求在这些位置动态地提供计算资源。

边缘云可以通过持续调整应用虚拟机的部署位置来应对这些动态变化。这可以通过在新的位置配置额外副本,或将在一个边缘位置的应用虚拟机迁移到另一个边缘位置来实现。

在新的位置配置额外副本可以参照当前云平台的方式进行。然而,在边缘云位置之间迁移应用面临诸多挑战(目前的云平台并不支持这一功能)。首先,这样做需要将虚拟机的内存和磁盘状态从一个边缘云位置迁移到另一个边缘云位置。虽然局域网内的虚拟机迁移(即在同一云位置内的服务器之间迁移)已有成熟方案[13], WAN VM迁移并非如此。在局域网中进行虚拟机热迁移时,假设虚拟机的IP地址在迁移后保持不变,因此客户端设备与虚拟机之间的所有激活的网络套接字连接均不受影响。而在广域网迁移中,虚拟机的IP地址会更改为新站点新集群的 IP地址,这使得对终端客户端保持网络透明性变得具有挑战性。在访问延迟最小化至关重要的边缘云环境中,迁移期间客户端感知到的停机时间也需要尽可能减少。

边缘云位置之间的带宽可能比局域网带宽更受限,并且会因边缘云集群之间网络链路的配置方式不同而有很大差异。较低的带宽会增加迁移延迟,还可能增加数据传输开销(因为正在激活更改的数据可能需要多次重新传输)。在广域网情况下,该问题更加严重,因为迁移延迟要大得多。

在边缘云位置之间高效支持虚拟机迁移需要应对这些挑战。

2.3 多路径传输协议

如今的服务器拥有多个网络接口。同样,手机等终端设备也具有多个用于通信的接口(例如无线网络、蜂窝网络等)。多路径传输协议利用两台服务器之间或服务器与客户端之间存在的多个网络路径。在这种情况下,套接字端点之间的网络数据包通过多个网络接口传输(而非传统套接字中的单个接口),数据可经由多条路径到达目标主机(图2)。

为单个连接使用多条路径具有许多优势。首先是提高了可靠性,因为一个接口或路径上的网络问题可以通过其他接口和路径进行掩盖。多路径传输协议还能够动态适应拥塞和其他路径健康指标,并根据路径的适用性在多条路径上发送数据。第二个优势是多路径提供了链路聚合功能,能够在多条路径上传输数据,从而增加数据流的可用有效带宽。因此,应用可以通过利用多条路径提供的带宽来加速数据传输。

多路径网络连接的实现已以MPTCP[33]的形式存在——这是TCP的一种多路径版本。MPTCP是一种提议中的[15]协议扩展。如今,许多广泛使用的操作系统(如 Linux和安卓)通过内核补丁支持MPTCP,而苹果的 iOS则部署了对MPTCP的内置支持。MPTCP作为一组 TCP选项实现,允许两个端点之间同时使用多条路径——也称为子流[15]。这些子流在逻辑上默认由所有端到端接口对定义。例如,如果会话中的每个端点都有两个接口,MPTCP最多可以创建四个子流。MPTCP具有诸多优势:首先,它对用户应用透明。MPTCP层通过提供标准TCP套接字对用户应用隐藏。现有的TCP应用无需修改即可利用MPTCP的优势。其次,通过利用多个子流,MPTCP可以自然地

示意图1

rally 实现的吞吐量相当于最佳单个子流,有时甚至达到更高的带宽。最后,由于没有一条路径是单点故障,弹性得到提升。多路径TCP 能够根据变化的网络条件在路径之间动态迁移流量。

MPTCP通过新的TCP头部扩展来传递控制信息,这些扩展用于宣告多路径能力、可用接口,并建立和拆除子流。一旦MPTCP连接建立,每个终端主机至少知道其对等端的一个IP地址。如果客户端希望使用其拥有的另一个接口(例如蜂窝网卡)创建额外的子流,它可以发送另一个SYN数据包,其中包含带有该网卡IP地址的JOIN选项,发往服务器已知的IP地址。该子流将与当前已建立的 MPTCP连接相关联。

由于许多客户端位于网络地址转换器(NAT)之后,服务器很难向移动客户端发送JOIN数据包,因为NAT通常会过滤掉未识别数据包[33]。相反,如果服务器还有一个额外的接口,服务器会发送一个Add Address选项,以通知客户端可用的地址。一旦客户端接收到该选项,就可以向服务器新公布的IP地址发送另一个带有JOIN选项的SYN数据包,从而创建一个新的子流[16]。在多路径TCP中,客户端被定义为发送原始SYN数据包的端点。我们的方法利用多路径TCP来解决边缘云中广域网迁移所面临的网络透明性和带宽限制挑战。

3. 边缘云中的虚拟机迁移

示意图2

示意图3

我们现在解释当前迁移技术在边缘云中的不足之处,然后介绍我们方法背后的设计思路,接着阐述我们的迁移算法。

3.1 为什么现有的虚拟机迁移技术不够充分?

我们现在概述局域网和广域网虚拟机迁移的最新技术,并论述这些方法对于边缘云而言是不充分的。

局域网迁移

图3 描述了基于局域网的虚拟机热迁移所涉及的步骤。内存的实时迁移是局域网迁移中的关键挑战之一[13, 27, 34],,因为在许多场景中,虚拟机的磁盘状态在源和目标机器上均可访问(例如通过共享存储)。迁移的第一阶段称为迭代预拷贝,该阶段将虚拟机的内存页从源服务器迭代地复制到目标服务器。由于在此阶段应用持续不间断运行,内存页在被复制后可能再次被修改。因此,在每一轮之后,所有新被修改的页面将在下一轮中重新发送。该迭代过程将持续进行,直到剩余脏状态“足够小”——此时,源虚拟机被暂停,并将其剩余状态传送至目标端。目标虚拟机可以从源虚拟机暂停的位置恢复执行。

广域网迁移

在广域网情况下,由于目标主机属于不同的网络子网,虚拟机的IP地址无法保留;因此维持网络透明性更具挑战性。当前的方法[23, 38, 40]均需要通过广域网扩展数据链路层网络。如图4所示,现有及未来的客户端继续将网络流量发送到源主机上的旧IP地址,该地址通过网络隧道将其转发至目标主机上虚拟机的新IP地址。这种三角路由会在客户端与虚拟机之间引入显著的额外延迟,并降低可用带宽。这

示意图4

在边缘云场景中,这种情况尤为不利,因为虚拟机可能会迁移到新的边缘云位置以降低到终端用户的延迟,而三角路由实际上会进一步加剧延迟问题。

布拉德福德等人[8]提出了一种方法,该方法仅对当前客户端使用隧道技术,并更新虚拟机的DNS记录,以便未来客户端能够直接连接到虚拟机的新IP地址。然而,DNS更新传播可能较慢,且现有的长寿命网络连接仍会受到三角路由和隧道技术延迟的影响。CloudNet[40]采用 VPN技术,使虚拟机在目标主机上的IP地址保持不变,从而消除了这些缺点。但它需要路由器支持来实现其迁移方法,限制了其通用性。

因此,当前的广域网迁移方法要么会降低客户端‐边缘云延迟,要么需要路由器支持以维持网络透明性。此外,现有方法仅关注网络透明性,而未考虑较低的广域网带宽(以及更长的迁移延迟)所带来的影响。较长的延迟可能会增加脏数据量,并对迁移的预拷贝阶段产生负面影响。最后,当边缘云站点之间没有共享存储时,除了内存状态外,虚拟机的磁盘状态也可能需要进行迁移。这些限制因素促使我们提出一种针对边缘云定制的新型虚拟机迁移方法。

3.2 基于多路径TCP的迁移方法

我们的方法利用多路径传输来克服边缘云广域网虚拟机迁移中的网络透明性和带宽限制。由于多路径TCP现已在主要的服务器(如Linux)和移动设备(如iOS)操作系统平台上可用,因此我们的方法易于使用现有系统实现和部署。

我们假设每个边缘云服务器至少具有两个网络接口,并且这些服务器托管的云虚拟机具有两个或更多逻辑网络接口。这是一个合理的假设,因为大多数商用服务器配置都配备了双端口或四端口以太网卡,而商业云上的虚拟机至少具有两个逻辑网络接口(例如,亚马逊EC2云虚拟机的公网和私网 IP)。我们进一步假设客户端设备使用多路径TCP。

为了解决带宽限制问题,我们的虚拟机迁移技术在发送方和目标主机之间直接使用多路径TCP,如图5所示。通过使用多条路径迁移内存和磁盘状态并行化数据传输,增加迁移期间的可用带宽并降低网络延迟。如我们的实验所示,MPTCP在迁移期间通常使可用带宽翻倍。

然而,即使使用多路径TCP,边缘云站点之间网络路径上的广域网带宽可能仍比局域网带宽更受限制。因此,我们提出了一种针对广域网场景定制的新型预拷贝算法用于迁移。该算法跟踪内存页(或磁盘块)在各迭代过程中的脏页率,仅传输最冷的页面。这缩短了迭代周期,并减少了已发送页面被修改的可能性,从而降低了整体迁移时间。为进一步减少数据传输开销,尤其是磁盘传输的开销,我们的算法可以主动将磁盘快照复制到可能的候选位置,当虚拟机迁移到这些机器时仅需发送增量部分。在虚拟机可能回迁至旧位置的情况下,保留之前的磁盘状态并仅发送增量也能节省迁移开销。综上所述,我们的针对广域网优化的数据复制算法与多路径传输共同解决了边缘云迁移中的带宽问题。

我们还使用多路径TCP来解决广域网迁移后的网络透明性问题。我们的技术在虚拟机上使用两个逻辑网卡,一个处于激活状态,另一个处于未激活状态。所有网络连接均使用MPTCP,并配置为同时使用这两个网卡——由于只有一个逻辑网卡处于激活状态,因此实际上仅使用该网卡。迁移完成后,另一个逻辑网卡被激活并分配新IP地址,而第一个网卡则被停用。这样会导致所有客户端设备上的MPTCP套接字无缝切换到使用新的接口,并停止通过旧接口发送数据。因此,尽管虚拟机发生了IP地址变更,所有TCP连接仍保持激活despiteanIPaddresschangeat the VM。

3.3 边缘云计算迁移算法

我们现在提出我们的迁移算法。我们假设虚拟机和主机都至少有两个网络接口卡。为了避免混淆,我们将主机上的物理网络接口卡称为NIC1和NIC2,将虚拟机的逻辑网卡称为vNIC1和vNIC2。我们的边缘云迁移包含六个阶段:

阶段1:Tunnel创建和路由分离

作为第一步,我们在源主机和目标主机之间创建一个隧道,并为目标主机上虚拟机的入站和出站流量配置路由表。尽管该隧道直到阶段4才会被使用,但我们预先创建此网络状态,以减少将虚拟机从源主机切换到目标主机时客户端感知的停机时间,这对于保持网络透明性至关重要。我们特别启用了proxy-arp,创建了通往虚拟机及来自虚拟机的路由条目,并为隧道和路由设置安装了ebtables规则。

阶段2: 迁移虚拟机磁盘状态

接下来,我们迁移虚拟机的磁盘状态(即虚拟磁盘)。仅当两个边缘云站点之间没有共享存储时,此阶段才是必需的。如果存在共享磁盘存储(或分布式文件系统),则磁盘状态可以直接与新机器共享,无需迁移。

磁盘状态(可能相当大)通过以下方式迁移在源主机和目标主机之间通过多路径TCP连接执行逐块复制。由于虚拟机继续运行,数据块在发送后仍可能被修改,因此需要进行迭代复制以重新发送已修改的磁盘块。在慢速广域网链路上的磁盘迁移可以通过三种机制进行优化。首先,多路径TCP本身能够在多个网络路径上并行化传输,从而增加迁移可用的带宽。其次,通过根据磁盘块的写入频率对其进行排序,并按写入频率递增的顺序发送块,可以减少需要重传到目标主机的数据量。或者,可以根据块的脏页率来发送块,高频率修改的块可以留到后期再发送。块的写入频率或块的年龄由其所属文件的写入频率或年龄推导而来。第三,可以使用数据去重[2, 18]技术来降低数据传输开销。

阶段3: 迁移虚拟机的内存状态

当大部分磁盘状态迁移完成后,虚拟机内存状态的迁移开始。1我们的内存迁移采用了一种针对基于广域网的边缘云环境优化的迭代预复制方法,通过跳过最热页面来减少迭代的持续时间(第3.3.2节)。

阶段4: 虚拟机切换

在阶段3结束时,虚拟机的磁盘和内存状态均已迁移。目标主机上的虚拟机随即接管并从源虚拟机暂停的位置恢复执行。从源到目标主机的隧道被激活。

此时,客户端继续向与源主机相关联的虚拟机旧 IP地址发送网络流量,这些流量通过隧道转发到目标主机上的虚拟机。因此,所有网络连接保持激活状态,尽管由于隧道技术的使用导致往返延迟有所增加。

阶段5:基于多路径TCP的网络切换

接下来,虚拟机的非活动的第二接口(vNIC2)被激活,并分配一个属于目标边缘云子网的新IP地址。同时配置路由表,使得两个接口可以同时使用。流向和来自第二接口(vNIC2)的流量不经过隧道传输。

MPTCP自然地在现有连接中通告新获得的IP地址,并创建新的子流。一旦新的子流建立,原始的另一个接口vNIC1将被停用,隧道也被拆除。这会导致所有终端客户端直接向vNIC2的新IP地址发送MPTCP流量。这样做可优化终端客户端到虚拟机新边缘云位置之间的延迟。

阶段6:正常运行

虚拟机现在恢复到正常状态,与其迁移前的状态类似,只是现在位于新的边缘云位置,并处于不同的子网中。如果该虚拟机需要再次迁移,则使用相同的过程,只是两个逻辑网卡vNIC1和vNIC2的角色互换。

3.3.1 优化磁盘迁移开销

1磁盘和内存状态同时迁移。

由于虚拟机的磁盘状态可能非常大,磁盘状态的迁移可能会主导总的迁移延迟。我们迁移算法的第二阶段采用了多种优化措施来加速磁盘迁移。

在能够预测边缘云虚拟机未来位置的场景中,或当虚拟机在相同的一组位置之间“跳跃”时,可以实现额外的优化。如果能够预测虚拟机的未来位置,则可以在迁移前很久就将虚拟机磁盘的快照传输到一个或多个候选位置。在这种情况下,第二阶段只需迁移快照生成后被修改的磁盘状态增量部分。由于在数小时或数天过程中只有少量磁盘文件被修改,这可以显著减少磁盘状态的迁移量。

类似地,如果虚拟机在已知位置之间跳跃(例如跟随用户,用户从家到工作地点往返,或跟随太阳场景),则迁移后源机器上的磁盘状态不会被删除。当虚拟机迁回该位置时,只需将增量部分复制回去。

3.3.2 广域网优化的预拷贝算法

大多数虚拟机监控器(如KVM)中使用的迭代预复制方法适用于局域网环境,其中网络带宽足够高,虚拟机的状态可在一分钟内完成复制。广域网带宽可能比数据中心间带宽低几个数量级。这种带宽的降低对迁移过程尤为不利。

在预拷贝迁移方法中,虚拟机监控器迭代地识别并通过网络发送剩余的脏页。页面变脏率仅受内存带宽限制,可能高达数百Gbps,因此比网络带宽高出几个数量级。为了能够完全迁移虚拟机,预拷贝方法假设虚拟机的可写工作集——即其工作集中频繁写入的页面——较小。

因此,降低的广域网带宽会延长迁移所需的时间,因为虚拟机监控器需要更长时间来发送脏页,从而增加了连续迭代之间的时间间隔。这种增加的迭代时间会产生累积效应——随着迭代时间变长,在后续迭代中可能有更多的页面被修改。因此,降低的带宽不仅由于网络传输速率慢而增加了迁移时间,还增加了需要传输的数据量(脏页)。

为了解决由于带宽较低导致迁移时间急剧增加的问题,我们提出了一种改进的预拷贝算法,以减少在广域网环境中发送的页面数量(从而缩短总迁移时间)。该算法的核心思想是在每次迭代中不发送“热点页面”,以减少发送的页面数量。热点页面是指写流量较大的页面,在下一次迭代中极有可能被修改。因此,在初始迭代中发送热点页面只会增加迭代时间,并在后续迭代中导致更多脏页产生,造成累积效应。在每次迭代过程中,我们识别出脏页,并将其分为两类:热点页面和冷页面,仅发送冷页面。这使得迭代周期保持较短,并减少了总的迁移时间。我们将该方法称为“热跳过”方法,因为它会跳过并避免发送热点页面。为了确保迁移过程能够收敛,我们保证被跳过的热点页面数量单调递减。热点页面可通过阈值方案(写入频率最高的前10%页面为热点)识别,或通过其他内存分析技术[41] 实现,后者可根据应用行为动态确定阈值。

我们根据页面的长期写入频率来识别热页和冷页,该频率基于所有迭代中的脏位图进行记录。我们的方法类似于Xen实时迁移中用于跳过在一次迭代中被修改两次页面的跳表方法[13, 25]。然而,我们的方法不同之处在于,我们在将页面分类为热页或冷页时考虑了长期的历史信息,而跳表方法会在当前迭代结束后“遗忘”页面的历史。

3.4 系统实现

我们在KVM虚拟机监控器中实现了一个透明广域网迁移系统的原型。我们的实现在三个主要部分之间划分:虚拟机监控器、迁移管理器以及虚拟机中的客户操作系统。

虚拟机监控器

我们的迁移方法依赖于使用多路径TCP来迁移虚拟机状态。由于虚拟机监控器(在本例中为KVM版本 2.0)执行虚拟机的实际迁移,因此它必须具备使用基于多路径TCP的套接字的能力。KVM中的迁移由用户空间QEMU层执行,并打开一个标准TCP套接字。QEMU运行在Linux之上,我们通过使用针对多路径TCP版本0.91[30]的内核补丁,采用了支持多路径TCP的Linux内核(版本3.13)。这使得 QEMU迁移过程能够使用多路径TCP,并可以通过多个网络接口发送虚拟机状态,从而提高有效带宽。

我们观察到,MPTCP吞吐量对TCP窗口大小的依赖性远高于标准TCP[32]。根据RFC 6824[16],我们调整了内核TCP窗口缓冲区net.ipv4.tcp_rmem和 net.ipv4.tcp_wmem,将其设置为60 MB,该值约为可用带宽之和乘以最高往返时间值的两倍。我们未使用MPTCP校验和功能,以降低其CPU开销[33]——这不会影响TCP子流的校验和,子流仍然会进行校验和计算。我们采用默认MPTCP耦合拥塞控制算法LIA (链式增长算法)。LIA基于TCP Reno,为了实现公平比较,我们在TCP拥塞控制中也使用Reno。

迁移管理器

迁移管理器是运行在源主机和目标主机上的用户空间软件组件。它与QEMU迁移线程交互,并主要负责更新两端的网络配置以确保网络透明性。

迁移管理器是围绕常规迁移过程实现的一个封装 Perl脚本。我们的脚本读取包含虚拟机和网络详细信息的配置文件。该配置文件包括以下内容:源和目标主机的IP地址、目标主机名,虚拟机名称、虚拟机当前的网络细节(IP地址、网关、接口名称)以及虚拟机最终的网络细节(IP地址、IP前缀、接口名称)。然后我们按照第3.3节中概述的步骤进行操作。我们使用虚拟机网络细节来建立ebtables规则,以便在虚拟机到达目标主机后路由数据包。在阶段2中,我们使用目标主机的IP地址通过预先复制快照的方式在目标主机上建立磁盘状态。在阶段3中,我们使用虚拟机名称和目标IP地址通过virsh迁移虚拟机。在阶段4(一个时间关键步骤)中,我们使用虚拟机的网络配置结合ebtables [1]更改网络路由,使数据包通过我们预先建立的隧道进行转发。最后在阶段5中,我们使用指定的网络接口来决定在迁移完成后激活和停用哪个接口。

虚拟机客户操作系统

最后,我们的方法还要求客户操作系统使用多路径TCP,为此我们再次使用打过补丁的MPTCP Linux内核。这确保了在虚拟机内运行的所有应用都能使用多个虚拟网络接口卡和多路径TCP。除了需要支持多路径 TCP的内核外,我们的方法无需对其他应用进行任何修改。

我们的方法要求虚拟机监控器和虚拟机都具备多个网络接口。虚拟机监控器可以轻松地为每个虚拟机创建多个虚拟网络接口卡。由于我们在虚拟机中使用多路径TCP实现端点透明性,因此需要注意的是,虚拟机在正常运行期间不会主动使用多个接口。相反,我们采用MPTCP的“备份模式”,使得TCP连接的流量在迁移期间回退到备用接口。

我们的实现在EC2、Amazon、IBM SoftLayer云以及基于实验室的模拟边缘云测试平台上成功通过了测试。

4. 评估

在本节中,我们将展示当虚拟机监控器和虚拟机使用多路径TCP作为网络活动的默认传输协议时的实验结果。我们首先介绍实验环境,包括商业分布式云、模拟边缘云计算测试平台、硬件、软件和指标。然后,我们对多路径TCP进行评估。我们的实验旨在评估边缘云环境下基于多路径TCP的虚拟机状态迁移的以下方面:
我们迁移内存和磁盘状态的速度有多快?
不同的带宽和往返时间如何影响迁移?
我们提出的优化方案在减少内存和磁盘复制开销方面有哪些优势?
基于多路径TCP的切换在保持网络透明性的同时的有效性如何?

4.1 环境与方法论

我们将使用以下指标:

  • 应用吞吐量 : 对于网络密集型应用,我们希望了解我们的迁移方法对它们吞吐量的影响。
  • 迁移时间 :迁移过程所花费的总时间。这决定了虚拟机完全迁移到目标位置的速度。
  • 应用停机时间 :由于迁移可能导致网络连接的暂时性丢失,因此可能使应用面临停机时间。我们通过使用 tcpdump 获取迁移期间的数据包追踪来评估停机时间。我们将停机时间的开始定义为观察到虚拟机发送的最后一个未经过隧道的数据包的时间,停机时间的结束定义为观察到虚拟机在隧道上发送的第一个数据包的时间。
  • LossRate : 除了停机时间外,我们还测量迁移期间的数据包丢失率,以量化迁移的破坏性影响。

工作负载 。我们采用两种方法来评估系统在主机和客户机级别的性能。为了评估吞吐量性能,我们在广域网上迁移一台配备16 GB内存的30 GB虚拟机,同时运行内存工作负载。为了评估网络透明性,我们在广域网上迁移一台15 GB虚拟机,同时运行网络工作负载。

为了评估在模拟边缘云中的迁移性能,我们运行一个工作负载,该工作负载分配一块大小约等于虚拟机虚拟内存的内存(对于16 GB的虚拟机,我们使用15 GB),并通过修改大量内存页来迫使虚拟机监控器通过网络传输全部内存。除非另有说明,我们分别对多路径TCP和TCP各进行10次试验,并报告平均值。在评估网络透明性的实验中,我们在圣何塞运行iperf客户端,而虚拟机宿主运行 iperf服务器。我们使用我们的方法以及大多数现有广域网迁移系统所采用的隧道方法进行实验。为最小化拥塞的影响,我们在晚上9:00至早上7:00之间进行实验。我们报告10次运行的平均值以及90%置信区间。

商用分布式公共云 。我们从IBM的SoftLayer云中配置了多台裸金属服务器,如图6所示,并部署了支持MPTCP的虚拟机管理程序和迁移管理器。尽管SoftLayer云并非完整的边缘云,但它是一个提供北美多个站点的分布式商业云,我们从中选取了圣何塞、达拉斯、多伦多和蒙特利尔的位置作为我们的边缘云位置。我们在圣何塞使用一台独立的裸金属服务器作为

示意图5

我们的客户端和虚拟机始终从蒙特利尔启动。我们研究了将虚拟机迁移到达拉斯和圣何塞的场景。我们的 SoftLayer边缘云配备两个启用超线程的2.4 GHz Intel E5‐2620处理器,系统具有64 GB内存和1 TB SCSI硬盘,以及两个Intel 10千兆以太网网卡。

基于实验室的边缘云测试平台 。由于在真实的生产环境中难以控制网络带宽、延迟以及虚拟机分配,我们搭建了两个受控边缘站点,通过由Dummynet[10]模拟的广域网连接。这使得我们能够在受控环境中评估系统时,控制带宽、丢包率和延迟。

模拟边缘云环境由四台PowerEdge R430服务器组成,每台服务器配备2.10GHz的 Intel E5‐2620 v4处理器,具有两个套接字、八个核心并启用超线程技术。每台系统配有64 GB内存和一块TB级SATA硬盘。我们在每台机器上使用两个千兆以太网接口。我们的网络拓扑如图7所示。

我们在两台运行 FreeBSD 11.0‐STABLE 的服务器上使用 Dummynet 网络模拟器来模拟广域网路由器,队列大小分别为 8000 和 12000 KBytes。我们的边缘云节点直接接入这些路由器,由路由器将所有流量转发至目标主机。当数据包经过路由器时,Dummynet 会应用预配置的规则,调整 TCP连接 的带宽和延迟。我们通过这些规则来配置所需的网络条件。

示意图6

4.2 分布式公有云中的迁移

通过 MPTCP 迁移虚拟机可增加迁移可用的有效带宽,因为它支持通过多个接口传输虚拟机的内存和磁盘状态。因此,虚拟机监控器用于虚拟机迁移的传输协议选择会影响虚拟机迁移时间。

我们在图8所示的分布式公共云环境中评估了迁移时间,该图显示了在蒙特利尔和圣何塞位置之间迁移16 GB大小的虚拟机时的迁移时间。我们在为期三天的时间内共执行了195次虚拟机迁移。每次虚拟机迁移都有两条路径可选(通过公共云和私有网络)

示意图7

工作接口分别)。多路径TCP能够利用both这些路径,并且与单独使用TCP相比,几乎可将平均迁移时间减少30%。我们看到,在路径未发生拥塞的情况下,单条路径上的TCP(图8中的TCP路径1)有时可能优于多路径TCP,因为在该非拥塞路径上使用TCP传输数据会掩盖多路径 TCP的部分链路聚合优势。我们强调多路径TCP的自适应特性——尽管在手动选择的“最佳”路径上运行的TCP有时可与多路径TCP相媲美,但在网络特性具有高方差的边缘云中,选择该最佳路径可能并不现实。多路径TCP具有自适应特性,无需手动选择路径,因为它会自适应地在非拥塞路径上发送更多数据——从图8中与拥塞路径(TCP 路径2)相比最坏情况下的迁移时间减少可以看出这一点。

4.3 基于实验室的边缘云迁移

由于在全球分布式边缘云中的网络带宽和延迟可能在很大范围内变化,因此我们还在一个基于实验室的边缘云测试平台中评估了我们的迁移方法,该平台可以模拟广泛的网络行为。我们的设置允许我们在模拟的广域网中运行虚拟机实时迁移,类似于在边缘云设置中看到的情况。我们通过使用 Dummynet[10] 模拟器来控制带宽和延迟,从而在本地网络中模拟广域网的网络条件。

网络延迟 。我们首先分析网络延迟对迁移时间的影响。在网络延迟与位置之间的光速延迟成正比的情况下,由于边缘云位置可能是全球分布的,因此边缘云中的网络延迟可能会有很大差异。

图9展示了在大范围往返时间(RTT)下的迁移时间。我们看到,使用多路径TCP的迁移时间大约是使用TCP的一半——这是因为多路径TCP利用了两个物理网络接口,有效使可用带宽翻倍。使用多路径TCP的迁移时间约为150秒,而使用 TCP则接近300秒。对于多路径TCP和TCP而言,其

示意图8

往返时间对迁移时间的影响可以忽略不计。迁移时间取决于网络吞吐量,因为迁移涉及大量数据传输——虚拟机监控器在每次迭代中发送大批量的4 KB页面。由于两种传输层协议(MPTCP和TCP)均能在不同往返时间下实现相同的网络吞吐量,因此迁移时间不受往返时间的影响。

网络带宽 。边缘云不同位置之间的网络带宽也可能存在显著差异。我们在图10中评估了可用带宽对迁移时间的影响,所有情况下的往返时间(RTT)均保持恒定在60毫秒。在最高1 Gbps带宽下,使用多路径TCP的虚拟机迁移速度约比传统TCP快1.2倍。然而,随着可用带宽下降,多路径 TCP在缩短迁移时间方面的优势更加明显。在100 Mbps带宽下,迁移耗时约为15分钟,而使用TCP则需 28分钟,性能提升接近2倍。我们强调,由于地理位置分散以及跨大陆带宽成本高昂,边缘云中的网络带宽可能非常有限,因此在为边缘云设计应用和系统时,最小化带宽需求是一个主要的优化目标。在带宽受限的环境中,多路径TCP可使虚拟机迁移时间减少一半,相比现有的基于 TCP的方法具有显著优势。

虚拟机大小 。最后,由于不同应用的内存需求不同,虚拟机的内存大小也会有所变化。我们在图11中评估了虚拟机内存大小对迁移时间的影响。与使用TCP相比,对于大于或等于8 GB的虚拟机,多路径TCP可实现快2倍的迁移速度。我们分别对两个接口上的TCP进行了评估,图11中的结果表明,由于接口的选择,迁移时间没有明显差异。这表明,在我们的仿真网络设置中,多路径TCP即使在最佳路径上也优于TCP。

示意图9

示意图10

4.4 广域网优化预拷贝算法

接下来,我们评估第3.3.2节中描述的广域网优化的预拷贝算法。为了评估该算法的可行性,我们实现了一个由模型驱动的

示意图11

Python中的迁移模拟器。该模拟器通过计算每次迁移轮次中脏页和非脏页的比例,来评估我们的热跳过方法和默认KVM顺序算法。然后,模拟器通过将需要传输的页数除以可用带宽来计算每轮迭代的持续时间。模拟器重复执行这些迭代,直到达到给定的停止并复制阈值。

图12显示了我们的广域网优化热跳过预拷贝算法在不同可用网络带宽下的迁移时间。与默认的QEMU迁移算法(在每次迭代中发送所有脏页)相比,我们跳过热点页面的方法将总迁移时间减少了超过20%。从图12还可以观察到,在低带宽场景下,采用我们的热跳过方法对迁移时间的减少更为显著。

4.5 磁盘迁移

到目前为止,我们已经研究了虚拟机内存状态的迁移时间,并假设虚拟机的虚拟磁盘在源和目标边缘云位置之间共享。在虚拟磁盘通过网络挂载到两个位置的环境中,共享磁盘状态是常见的。然而,在某些场景中,虚拟机的磁盘内容(连同内存内容)也需要被

示意图12

迁移完成后,已迁移的虚拟机可以在目标主机上更快的本地磁盘访问虚拟磁盘,而无需每次磁盘访问都产生网络往返。因此,在边缘云中,磁盘迁移对于最小化延迟非常重要。

我们通过复制虚拟机的整个虚拟磁盘以及内存状态来评估磁盘迁移。在这种full-disk-copy方法中,由于数据传输量较大,迁移时间可能会显著增加,因为虚拟磁盘的大小可能达到几十甚至几百GB。我们观察到,使用多路径TCP consistently 将迁移时间降低15%或近10分钟。需要注意的是,磁盘迁移受限于磁盘带宽,而磁盘带宽可能明显低于网络带宽,尤其是在广域网环境中。虽然多路径TCP可以提高有效网络带宽,但由于低磁盘带宽造成的瓶颈,其有效性受到限制。

我们注意到,可以通过使用一种称为 incremental-disk-copy 的技术来进一步优化,其中在实时迁移之前先迁移快照,并将其用作基础镜像。这使得实时迁移过程仅需传输当前镜像与快照之间的增量,从而减少通过网络发送的数据量。

4.6 网络透明性

示意图13

我们现在来看我们的方法如何处理网络透明性及其对吞吐量的影响。我们评估虚拟机从蒙特利尔迁移到两个不同位置(圣何塞和达拉斯)时的迁移性能。在两种场景中,客户端均位于圣何塞,而虚拟机正在运行iperf服务器。

图14显示了当虚拟机分别迁移到达拉斯和圣何塞边缘站点时的实验结果。我们观察到,迁移后,使用多路径TCP的应用吞吐量高于仅使用隧道的方案。在迁移过程之前和期间,TCP和多路径TCP的吞吐量大致相同。然而,在虚拟机迁移到目标站点后,吞吐量表现出显著差异。当迁移到达拉斯时,多路径TCP的吞吐量是 TCP的1.8倍。类似地,在迁移到另一个位置(圣何塞)后,吞吐量差异超过13倍。

我们注意到,在两种方法下,迁移时间、服务中断时间以及迁移前和迁移期间的吞吐量在统计上是相同的。这是预料之中的,因为这两种技术在客户端使用虚拟机的新IP地址建立新的MPTCP子流之前是完全相同的。只有在迁移完成后,我们才能看到MPTCP系统在性能和透明性方面的优势。

5. 相关工作

我们的工作基于并结合了关于虚拟机实时迁移、多路径 TCP和边缘云的前期研究。

实时迁移 。现代虚拟机实时迁移首次在[13]中提出,该文献描述了Xen的迭代预复制迁移算法,这也是我们方法的基础。实时迁移已实现在几乎所有管理程序中,包括 VMware ESX[27]。

广域网迁移 。在广域网上进行虚拟机的迁移由于网络延迟增加和带宽减少,相较于局域网环境带来了额外的挑战。我们还表明,广域网带宽的高度可变性为迁移带来了更多挑战。虚拟机的广域网实时迁移在[40]中有描述,其中还开发了各种优化方法,例如页面并使用块压缩来减少网络数据传输。广域网实时迁移也被用于在云服务提供商之间迁移虚拟机以降低成本。通过使用隧道技术和软件定义网络等技术,可以在广域网迁移中保持网络透明性。VMware的XvMotion还可以远距离迁移虚拟机,并利用网络虚拟化技术将二层局域网扩展到两个数据中心之间。然而,隧道技术和网络虚拟化会带来额外的网络延迟,因为客户端请求首先被路由到虚拟机的原始源位置。将虚拟机迁移到更靠近客户端的位置以降低延迟是边缘云的重要特性,而隧道技术增加了延迟,因为它在客户端和新目标主机之间增加了一个额外的广域网跳转。相比之下,我们的方法依赖于使用MPTCP,无需任何隧道技术,因此可以通过将虚拟机迁移到更靠近客户端的位置来降低客户端延迟。

使用多路径TCP进行虚拟机迁移 。一些先前的研究工作提出了使用多路径TCP进行虚拟机迁移。[28]展示了如何在中间盒环境下利用多路径TCP更改连接的端点,并且还提出了广域网虚拟机迁移作为一个潜在的应用场景。他们的方法依赖于修改多路径TCP协议栈,而我们的方法则无需任何协议更改。先前的研究[24]探讨了将分层令牌桶调度与多路径 TCP和软件定义网络相结合,并研究虚拟机迁移。他们的重点仅限于局域网内的迁移,这不适用于边缘云的广域网场景,因为在跨站点发生虚拟机IP地址变更时无法提供网络透明性。我们的方法针对边缘云位置之间的广域网迁移进行了优化——我们提供网络透明性,优化了广域网环境下的虚拟机预拷贝迁移,并利用多路径TCP进行虚拟机磁盘传输。[37]研究了使用多路径TCP进行虚拟机迁移以及预先分配IP地址以减少停机时间的方法。他们依赖虚拟专用网络在非协作的边缘站点之间进行迁移,而我们的方法可在公共互联网上的边缘云位置之间运行。我们在虚拟机和管理程序中均启用了多路径TCP,以实现更快的迁移时间,提供更高的网络透明性,并优化广域网环境中的迁移。

迁移优化 。虚拟机实时迁移有两个重要指标:总迁移时间和停机时间。[25]中提供了这些指标的综合经验模型,并确定了影响迁移性能的因素,例如应用页面脏页率。文献[26]评估了页面去重和压缩等迁移优化的性能优势。最近,有研究提出利用应用提示(例如 Java垃圾回收)来减少迭代预复制过程中发送的页面的迁移优化方法[9,20]。通过调度存储块的传输并利用空间和时间局部性,可以降低存储迁移的开销[42]。

边缘云迁移 实时迁移已广泛应用于边缘云中的多种优化任务,是管理边缘应用的基本机制之一云。[19]研究了在用户移动时,利用实时迁移在边缘云位置之间进行无缝切换的方法。该方法依赖于利用目标主机上的虚拟机状态,并通过去重、压缩和虚拟机合成为技术减少网络传输的总体数据量。我们的系统结合多路径TCP,不依赖目标主机上已有的状态,因此在迁移到新目标主机时能够降低迁移时间。虚拟机切换可视作与我们系统的互补技术,若结合使用,可能进一步降低迁移时间。

多路径TCP 。多路径TCP在[16]中被提出,并且多路径TCP已在许多场景中得到应用和评估。已在[33,32]中对数据中心网络中的MPTCP进行了评估。MPTCP也已应用于移动环境,在该环境中允许同时使用WiFi和蜂窝网络等多种接口[31, 12, 22]。我们在使用多路径TCP方面的创新在于,它结合了MPTCP所提供的高吞吐量和网络透明性优势。也就是说,我们不仅利用MPTCP下更高的可用带宽来缩短迁移时间,还通过立即切换到其他接口来减少停机时间。

一些先前的研究也利用多路径TCP来实现端点透明性。[6]提出了一种支持多路径TCP的代理和中间盒以实现地址透明性。我们仅依赖于主机端支持,而无需中间盒。已有研究提出使用软件定义网络来提供多路径TCP的部分地址透明性功能[4]。然而,我们的基于多路径TCP的方法不依赖底层网络来实现地址透明性。

6. 结论

为了提供用户移动性和游牧性,边缘云必须依赖针对广域网场景优化的虚拟机实时迁移。我们为边缘云环境量身定制的迁移方法,利用多路径TCP来加速迁移,并为客户端提供更高的网络透明性。我们利用多路径 TCP提供的聚合吞吐量实现迁移的并行化,从而缩短迁移时间。此外,通过依赖多路径TCP的弹性特性,在迁移后自动将激活的网络连接切换到虚拟机的新地址,从而降低延迟,并消除了对持久隧道的需求。我们的系统引入了一种新的针对磁盘和内存的迭代预复制算法,该算法针对边缘云较低的带宽进行了优化。

我们已在分布式公共云和基于实验室的边缘云上展示了原型的性能。实验表明,与典型的隧道技术方法相比,我们的原型可将迁移时间减少多达50%,并且在某些场景下使客户端的迁移后吞吐量提升近6倍。

致谢. 我们感谢所有评审人员提出的富有见地的意见,这些意见提高了本文的质量。本工作部分由美国国家科学基金会资助 #1422245 和 #1229059、亚马逊网络服务( AWS)和微软Azure云积分,以及华为的捐赠和美国能源部合同 DE‐AC02‐06CH11357 资助。本文表达的任何观点、发现、结论或建议均为作者的观点,并不一定反映资助机构的看法。

Logo

腾讯云面向开发者汇聚海量精品云计算使用和开发经验,营造开放的云计算技术生态圈。

更多推荐