Source-linked AI summary
Live Service Migration in Mobile Edge Clouds
Andrew Machen, Shiqiang Wang, Kin K. Leung, Bong Jun Ko, Theodoros Salonidis
TL;DR
The paper addresses how to keep mobile-edge services near moving users while limiting migration downtime and total migration time. It presents a layered framework for live migration of VM- and container-encapsulated applications using existing tools, and evaluates it experimentally across real applications. The experiments examine how migration stages and application characteristics affect performance, while the discussion identifies container security and three-layer migration trade-offs.
Problem
MEC services must remain near moving users, but live migration must limit service downtime and overall migration time, especially for container-based applications that were not systematically studied.
Method
The paper presents a generic layered framework using incremental file synchronization for live migration of applications encapsulated in VMs or containers.
Results
Experiments evaluate the framework across applications with different installation footprints and memory requirements, relating migration-stage times to these application characteristics.
Takeaways & Limitations
The framework supports existing VM and container technologies without modifying application implementations, while layering can enable pre-caching of popular applications at MECs.
Abstract
from arXiv · showhide
Mobile edge clouds (MECs) bring the benefits of the cloud closer to the user, by installing small cloud infrastructures at the network edge. This enables a new breed of real-time applications, such as instantaneous object recognition and safety assistance in intelligent transportation systems, that require very low latency. One key issue that comes with proximity is how to ensure that users always receive good performance as they move across different locations. Migrating services between MECs is seen as the means to achieve this. This article presents a layered framework for migrating active service applications that are encapsulated either in virtual machines (VMs) or containers. This layering approach allows a substantial reduction in service downtime. The framework is easy to implement using readily available technologies, and one of its key advantages is that it supports containers, which is a promising emerging technology that offers tangible benefits over VMs. The migration performance of various real applications is evaluated by experiments under the presented framework. Insights drawn from the experimentation results are discussed.
I. INTRODUCTION
Mobile edge clouds place small cloud infrastructures near users to reduce latency and improve connectivity for real-time applications. The paper studies live migration between MECs so services can remain near users as they move.
- Centralized clouds can impose high latency through many network hops and may experience saturated ingress bandwidth.
- MECs place computing infrastructure at the network edge, typically one or a few network hops from mobile users.
- Real-time applications such as instantaneous object recognition and safety assistance require close proximity to users for low latency and high bandwidth connectivity.
- When users move away from their original MEC, migrating services to a nearby MEC can preserve performance.
- The proposed layered framework transfers only destination-missing layers, supports VMs and containers, and is implemented with existing tools.
II. LIVE SERVICE MIGRATION: MOTIVATION AND BACKGROUND
MEC service migration addresses mobility by moving active services closer to users, but practical migration must handle state, resource costs, and heterogeneous infrastructure. The paper focuses on stateful migration and container support over WAN-connected MECs.
- A mobile user may need service migration to a directly connected MEC because continued backhaul communication can substantially increase latency.
- Stateful migration preserves running application state, unlike stateless migration, which redirects requests to a separate service instance.
- Migration decisions must balance service interruption and computation or communication overhead against benefits after migration.
- VMs and containers encapsulate applications for distribution, but containers use fewer resources and have lower virtualization overhead than VMs.
- Prior MEC migration work focused on VMs, while container migration had not been systematically studied despite containers’ smaller size and suitability for resource-limited MECs.
- Existing VM migration methods often target data centers with SANs or shared storage, whereas this method is designed for WAN-connected MECs and different containers and VMs.
III. A LAYERED FRAMEWORK FOR LIVE MIGRATION
The paper proposes a generic layered migration framework that uses incremental file synchronization for both containers and VMs. It builds on existing technologies without modifying their internals.
- The framework uses incremental file synchronization to support migration across both containers and VMs.
- It relies on functionality already available in popular container and VM technologies, avoiding changes to implementation internals.
- LXC and KVM serve as representative container and VM technologies because of their popularity and ability to run Linux-built applications without modification.
- The framework first performs stateful live migration and then adds layering to further reduce migration time.
A. Basic Procedure of Stateful Live Migration in MECs
The basic stateful migration procedure records and transfers a running guest OS’s in-memory state and filesystem, then restores the service at the destination. Checkpointing or saving tools suspend the guest temporarily, while rsync transfers files incrementally.
- Migration records, transfers, and recreates the running guest OS’s in-memory state so applications can resume from their suspended progress.
- LXC checkpointing and KVM saving suspend the guest OS and store its in-memory state in transferable files.
- Complementary restore tools recreate the guest OS from its checkpoint or saved state at the destination.
- The procedure transfers the guest filesystem and saved in-memory state using rsync for compression and incremental file synchronization.
B. Layering
The framework reduces migration overhead by separating reusable system components, applications, and running state into layers. Its three-layer model transfers application data while the service runs, leaving mainly in-memory state for downtime.
- Two-layer motivation: 25 seconds for LXC and 160 seconds for KVM: base-package migration at 100 Mbps leaves services down and potentially unresponsive.Base packages are approximately 400 MB for LXC and 2.7 GB for KVM.
- Two-layer model: The two-layer model separates a generic base layer from a service-specific instance layer containing applications and running state.Every MEC is assumed to retain a copy of the base layer, so migration transfers only the instance layer when available.
- Three-layer model: The three-layer model moves the idle application and application-specific data into an intermediate application layer, leaving the instance layer for in-memory running state.A service is reconstructed from the base, application, and instance layers.
- Three-layer model: Migrating the application layer before suspending the service leaves only the running-state transfer contributing to service downtime.The approach transfers most program and data while the service continues running.
- Operational benefits: Pre-distributing application layers, potentially through demand-based caching, can reduce overall migration time to the instance-layer transfer.The distinct application layer also allows applications and related data to be distributed independently of a running service.
- Implementation: Pseudo-incremental migration clones a lower layer and uses incremental file synchronization to transfer differences needed to recreate missing higher layers.The cloning and synchronization process is repeated according to which layers are absent at the destination.
IV. EXPERIMENTATION RESULTS AND DISCUSSIONS
Experiments evaluated the layered migration framework across container and VM environments, applications, and network conditions. Migration stages vary with application installation size and RAM usage, while service downtime remains below total migration time.
- Experimental setup: The experiments used three host VMs connected through CORE, with 2 virtual CPU cores and 2 GB of virtual memory per host.The hosts emulated MEC environments for evaluating live migration.
- Experimental setup: 100 Mbps MEC-to-MEC bandwidth and 100 Mbps MEC-to-user bandwidth were used, with 25 ms latency and 5 ms jitter on user links.The MEC-to-MEC path used system-inherited latency and jitter.
- Workloads: The evaluated applications included Game Server and RAM Simulation, representing small-footprint and memory-intensive workloads.Game Server used approximately 0.7 MB of installation space and 1 MB of memory; RAM Simulation consumed user-defined RAM.
- Experimental setup: 10 independent experiments per case: results were averaged across the evaluated migration configurations.The results are reported in Table I and Figures 4 and 5.
- Results interpretation: Service downtime is always shorter than total migration time because cloning and data transfer can occur while the service remains running.Stage durations differ across applications because installation footprints and RAM occupation differ.
- Results interpretation: Application filesystem synchronization time follows installation size, whereas instance in-memory-state synchronization time follows application RAM usage.These relationships correspond to the layered separation of application data and running state.
A. Container vs. Virtual Machine
The experiments provide a quantitative comparison of container and VM migration, showing clear performance advantages for LXC while identifying compatibility and security trade-offs.
- Motivation: Containers lacked a systematic quantitative comparison with VMs, and the framework enables this evaluation.The framework supports both container and VM migration without modifying their internals.
- Experimental comparison: LXC clearly outperformed KVM across total migration time, service downtime, and transferred data for all example applications.The reported advantage is attributed to containers’ compactness and application-focused filesystem and memory contents.
- Experimental comparison: 19x: approximate number of containers that can be migrated compared to VMs, depending on application RAM utilization.For RAM Simulation, migration time for both technologies was approximately linear in RAM utilization because transferred in-memory state scales with RAM usage.
- Experimental comparison: 8x: LXC was faster to migrate than KVM when bandwidth exceeded 50 Mbps.The relative advantage increased from 2x at 1 Mbps to 4x at 10 Mbps, with transmission capped by rsync comparison and compression speed.
- Trade-offs: Containers are less adaptable than VMs because they share the host’s hardware and kernel, and nesting them can degrade performance.MEC infrastructure should maintain compatible operating systems across the network.
- Trade-offs: Security remains a major consideration because containers are not fully isolated from the host and may be more susceptible to attacks from a compromised host.The paper does not recommend containers over VMs in all scenarios without addressing security.
B. Two Layers vs. Three Layers
The three-layer model usually benefits applications whose data occupies a substantial filesystem, especially when that application is already present at the destination. Its total-time advantage can reverse when the application is absent.
- Results: 3x: Video Streaming and Face Detection reduced total migration time when the application was already present at the target.The three-layer model showed these reductions compared with using only two layers.
- Interpretation: Larger application or associated-data sizes produce greater benefits from adding an intermediate layer.Video Streaming and Face Detection benefited because they had larger filesystems than RAM Simulation and Game Server.
- Trade-offs: When the application is absent at the destination, three layers can increase total migration time because cloning and synchronizing the third layer add work.Service downtime remains the same because suspension occurs only after the application layer has transferred.
- Deployment choice: Two- or three-layer selection should depend on application characteristics, usage frequency, and the impact of service downtime.A practical MEC system can support both models and choose between them using profiling and historical migration performance.
V. OPEN ISSUES
The paper identifies storage inefficiency, migration-method extensions, technology alternatives, device–MEC migration, and large-scale evaluation as open issues for the framework.
- Storage: The current container implementation duplicates each previous layer’s entire filesystem, motivating overlayFS for more efficient storage sharing.LXC version 1.1.5 did not yet support overlayFS.
- Migration method: Iterative migration is proposed as a potential way to improve performance, especially service downtime, by transferring memory pages while the service runs.Only a small portion of remaining in-memory state would theoretically require transfer after suspension.
- Container technologies: Future work should compare Docker and other container technologies as possible alternatives to LXC.The paper notes Docker’s industrial backing and widespread adoption prospects as reasons for further investigation.
- Device–MEC migration: Vertical migration between mobile devices and MECs remains open because device and server operating systems may differ.A cross-platform encapsulation mechanism that supports application suspension is needed for this setting.
- Evaluation scope: Large-scale networked MEC systems require experiments with real application migration rather than relying mainly on simulation-based migration-decision studies.The paper focuses on implementing live migration itself and leaves realistic large-scale evaluation for future work.
VI. SUMMARY
The framework supports container- and VM-based service migration in MECs and is evaluated across applications and scenarios. Experiments indicate that three-layer container-based migration generally performs best overall, while other configurations remain preferable in specific cases.
- The framework supports service migration using both containers and virtual machines and can be implemented with existing technologies.
- Experiments evaluate different migration approaches across various applications and scenarios.
- Three-layer container-based migration gives the best overall performance in general, although specific cases may favor other options.
- The three-layer model enables pre-caching popular applications at MECs, shortening future application-instantiation time.
- Migrating the entire container or VM avoids requiring application-specific modifications, allowing existing applications to run in the framework.