论文速读 - 移动计算中基于VM的Cloudlet案例

原文链接:The Case for VM-Based Cloudlets in Mobile Computing

M. Satyanarayanan, P. Bahl, R. Caceres and N. Davies, "The Case for VM-Based Cloudlets in Mobile Computing," inIEEE Pervasive Computing, vol. 8, no. 4, pp. 14-23, Oct.-Dec. 2009, doi: 10.1109/MPRV.2009.82.


Intro

移动计算还未真正挖掘其潜力,因此文章提出一种全新的架构。

一个移动用户将利用虚拟机(VM)技术在邻近的的cloudlet上快速的实例化定制化的服务软件,然后通过无线局域网来使用这个服务。就服务而言,移动设备通常充当的是瘦客户端的角色。Cloudlet是一个可信的,资源丰富的计算机或者计算机集群,它与互联网连接良好,可供附近的移动设备使用。

我们的策略是,当移动设备随着用户在物理世界中移动时,利用临时定制的邻近基础设施,这种策略被称为基于cloudlet、资源丰富的移动计算。清晰的交互式响应对于无缝增强人类认知是很重要的,它在这种架构中很容易实现,原因是cloudlet的物理邻近性,以及one-hop网络的低延迟性。使用cloudlet同时还简化了满足多个用户交互生成和接收媒体(如高清视频和高分辨率图像)的峰值带宽需求的挑战。针对不同应用程序的基础架构的快速定制成为一项关键要求,我们的概念验证原型结果表明,虚拟机技术确实可以帮助满足这一要求。

Resource-Poor Mobile Hardware

尽管移动硬件在不断发展,但是其计算资源总是受限制的。设备的重量,尺寸,电池寿命,人体工程学因素和散热等因素都会严重影响设备的计算资源,如处理器速度、内存大小和磁盘容量。所以相对于静态固定的硬件来说,移动设备硬件的计算资源总是受限的。

然而计算资源的严重受限将阻碍很多认知识别应用程序,因为它们需要大量的计算资源,远超移动设备的提供的范畴。文章举例机器翻译和人脸识别的极速发展,认为尽管这种应用程序的部署仍然需要技术的提高,但是依然需要认识到它们的巨大潜力。 而真正的挑战在于在轻量级、高能效、资源匮乏的移动硬件上,在高度多变的条件下,保持应用程序在室外的一流性能和质量。

The Limits of Cloud Computing

尽管一个显而易见的解决方案是云计算,移动设备在远程高性能计算机或服务器集群上执行计算任务,并使瘦客户端的用户通过互联网进行数据交互,但是WAN上的高延迟是一个严重的阻碍。

  • Why Latency Hurts

用户对于应用程序交互中的延迟是非常敏感的。

Horacio Andrés Lagar-Cavilla和他的同事通过一系列实验证明即使在高带宽的条件下低延迟也是非常影响用户体验的。

Niraj Tolia和他的同事们通过实验表明人们对瘦客户端性能质量的感知是高度可变的,并且取决于应用程序的交互性和网络的端到端延迟。

  • WAN Latency Is Unlikely to Improve

不幸的是,目前互联网发展的轨迹使得这些基本考虑在可预见的未来不太可能改变。当今网络改进的主要目标是带宽、安全性、能效和可管理性,用于解决这些问题的技术会损害latency。尽管随着时间的推移,带宽将继续改善,但延迟不太可能显著改善。事实上,情况可能会恶化。

  • Bandwidth-Induced Delays Also Hurt

用户感知延迟的另一个来源是必须在紧密的用户-机器交互循环中处理的大型数据项的传输。例如,在高分辨率图像或高清视频上执行计算机视觉算法是一项处理器密集型任务。在这种情况下,用户感知的延迟不仅仅是处理时间,还包括通过网络传输大量数据所需的时间。网络中可用的带宽决定了这种延迟。

无线局域网带宽通常比移动设备可用的无线互联网带宽高两个数量级。这说明了cloudlet的长效性,并大大增加了一个移动用户找到全世界任何位置兼容的cloudlet的机会。resource-rich的app的可扩展的软件接口被封装在客户环境中,因此在cloudlet定制化前就会被精准的创建。因此,VM-based的方案没有其他一些可选方案这么脆弱,如: process migration、software virtualization。而且它也不像language-based虚拟化方法那样需要在特定的环境中使用特定的语言如java、c#,没太多限制性,会比较通用。

两种不同的方法可以将虚拟机状态交付给基础架构。一种是虚拟机迁移,挂起已经在执行的虚拟机;其处理器、磁盘和存储器状态被转移;最后,虚拟机在目的地从确切的暂停点恢复执行。另一种方法,也是本文的重点,叫做动态虚拟机合成。移动设备将一个小的虚拟机overlay交付给已经拥有baseVM的cloudlet基础设施,该baseVM是该overlay的来源。基础设施将overlay应用于baseVM,以启动虚拟机,该虚拟机在之前暂停的精确状态下开始执行。如果cloudlet是一个集群,VM将快速克隆以并行启动。

动态虚拟机合成相比其他方法在两个关键方面有所不同。首先,它的性能完全取决于本地资源:cloudlet的带宽和cloudlet的计算能力。因此,本地硬件升级可以直接转化为更快的虚拟机合成。第二,广域网故障不影响合成。即使是完全与互联网隔离的cloudlet也是可用的,因为移动设备提供了overlay。在这种情况下,可以通过物理存储介质为cloudlet提供baseVM。

Feasibility of Dynamic VM Synthesis

为了验证可行性,创建了一个proof-of-concept原型叫做Kimberley。

mobile device:Nokia N810 Internet tablet running Maemo 4.0 Linux

cloudlet infrastructure:standard desktop running Ubuntu Linux

  • VM Overlay Creation
  1. 启动 baseVM
  2. 运行 install-script in the guest OS
  3. 运行 resume-script in the guest OS 启动期望的程序并进入用户交互期望的state
  4. 现在的状态叫launchVM,可以在运行时迅速恢复
  5. 创建launchVM后kimberlize区分它的memory和disk images和baseVM的以获取VMoverlay.
  6. 压缩并加密overlay.
  • Binding to Cloudlet Infrastructure

由一个用户级进程KCM管理。KCM的一个实例运行在设备和cloudlet上,它们一起将服务发现和网络管理从Kimberley进程的其余部分中抽象出来。

  • Speed of VM Synthesis
  • Improving Performance

对于未优化的概念原型来说,在60到90秒内合成虚拟机是可以接受的,但是对于实际部署来说,需要显著的改进。 虚拟机合成时间的两个主要因素是overlay transmission和在cloudlet上解压缩和应用。

我们可以通过使用更高带宽的短程无线网络来改善覆盖传输时间。为了减少解压缩和覆盖应用程序的时间,我们可以利用并行性。 另一种方法是使用缓存、推测合成和预取技术来消除虚拟机合成延迟。 最后,我们可以递归地应用合成来生成overlay family。

  • Deployment Challenges

文章在该部分提出许多在该思路变成现实之前要面临的现实挑战。

发布于 2020-11-23 02:22