CloudAP: Improving the QoS of Mobile Applications with Efficient VM Migration
Renyu Yang, Ph.D. Student School of Computing, Beihang University
[email protected] In IEEE HPCC, Zhangjiajie, China, 2013
1
Joint work with Yunkai Zhang, Tianyu Wo, Chunming Hu, Junbin Kang and Lei Cui
Mobile Computing and Cloud • Mobile device
– the amount of smartphone users worldwide exceeded 1 billion in the third quarter of 2012 and continues to grow sharply.
– Shortcomings: low battery volume, poor resource configuration
• Cloud Computing – elastic resource management
– application hosting
– resource poverty compensation
2
• “Mobile + Cloud” – Virtualization techniques & Remote Execution
• Execution separates from display and the results are transmitted to the thin device client
• Cross-platform enhanced execution mechanism. Ex: make Windows application run on Android mobile phones
– Challenges: WAN(Wide Area Network) latency!
Motivation • How to mitigate the WAN latency?
– trusted, resource rich computers or clusters near mobile users -- Cloudlet proposed by Mahadev
– Initialize custom VMs on Cloudlet Software is run on cloudlets
– Drawbacks:
• the software can only be run on one single cloudlet
• discard the previous execution environment before initializing a new one.
3
• Requirements: – Pervasive and seamless continuous software service provision.
• Short service interruption time.
– service’s continuous execution
• Rapid and transparent execution environment switch.
• CloudAP
CloudAP
• Inspired by “Access Point” in communication areas.
• Small-scale cloud infrastructure close to the mobile devices and can be connected to Cloud datacenter
• CloudAP + Cloud Center
• Typical Scale
– Cloud Center – CloudAPs – Servers –VMs
– VM – User
• Example
4
Options CloudAP Cloud Center
Network LAN WAN
Sharing Few users Large numbers of users
Software Execution Yes Yes
Latency Low High
Bandwidth High Low
Scale Small Large
Scenario
5
Moving
How to make these functionalities come true ? How to maintain the execution environment by using an efficient mechanism?
Proposed Two-tier Architecture
6
VM Schedule Manager
AP Agent
Local scheduler
monitoring
Resource pool
Registry
VM Migration Controller
Cloud Agent
App VNC viewer VM VM
PM PM
VM VM VM VM
VMM VMM
Portal
Portal
Detect the geographical location Parse messages and send operation instructions
Design of Whole-system VM live migration
7
• Objective: shorten the switch time – The duration from when the migration initiates to when the VM runs
in the destination.
– Prompt execution environment switch into a better QoS surroundings.
• Solutions – COW(copy-on-write) file system: base + cow image
• Base image(large size) : read only and well-planned in advance.
• Cow image: the added or modified.
– Hybrid Copy Strategy • Disk : post copy but only for the cow image
• Memory : pre & post hybrid copy
– Considering the high frequency of access to memory pages, pure post-copy will lead to frequent memory page fault and performance degradation.
Design
8
Pre-copy memory single round
Suspend VM, migrate CPU statesSuspend VM, migrate CPU states
Resume the VM on destinationResume the VM on destination
Dirty memory post-copy
and whole disk post-copy
InitializationInitialization
Freeze-an
d-
copy
Post-co
py
Pre-co
py
Transfer the memory dirty-bitmap
• Only one iteration • Dirty-bitmap is used to record
the modified memory
• Pull on demand : dirty page pulling request occurs once a dirty page in the dirty-bitmap is accessed to.
• Push actively: the source pushes dirty memory pages to the destination according to the dirty-bitmap
Similarly, all the sectors in the disk image file should be set dirty in a block-bitmap
Optimization • Most dirty sectors are pushed in advance rather than pulled
when they are operated?
– Analyze the disk I/O characteristics
– Predict the I/O behaviors
– Push the suitable sectors intelligently
• Strong locality and continuity for read operations.
– If a read operation occurs to one dirty sector, the backward dirty sectors adjacent to this sector have a high probability to be accessed to.
• Data Compression Approach
– A long serial bit 0 or 1 in most dirty sectors.
– RLE9(Run-Length Encoding) strategy.
9
Experimental Setup
10
QEMU-KVM kvm-84 512MB memory 10GB base disk image 250MB cow image
16 dell servers with Intel(R) Core(TM) i7 860 2.80GHz CPU, 4GB memory and 320GB disk
VM
≤100Mbps
WiFi(54Mbps)
simulated 3G network (average 5Mbps bandwidth and 35 ms latency)
3 dell servers
Metrics
• Downtime *
– the time interval during which software service is entirely unavailable
• Switch time*
– the duration from when the migration is initiated to when the VM resumes and starts to run in the destination
• Total migration time
– the duration from when the migration starts to when the VM runs independently in the destination
• Amount of migrated data
11
QoS improvement in two-tier architecture
12
Operations Cloud center(s) CloudAP(s)
Page scrolling 1.08 0.54
Text input 0.32 <0.10
Text selection 0.51 <0.10
Color change 0.53 <0.10
Table insertion 0.52 <0.10
Text dragging 1.04 0.34
Text centering 0.32 <0.10
We emulate the typical behavior of a user who tries to use Abiword, a popular text editing remote executed software on his own mobile phone.
only takes less than 0.1s, which is acceptable for users
Efficient execution environment migration
13
Execution environment migration may cause a temporal downtime and a moment of turbulent service.
Workload Downtime(ms) Switch time(s)
Abiword 9.5 24.16
Openoffice 10 25.93
Firefox 9.6 29.91
• The service downtime can be limited in 10 milliseconds, which can be nearly neglected.
• The total VM switch time is limited within 30s, which is acceptable for user to sacrifice this time for obtaining a better software service
Migration performance comparison
14
TPM Deltas Ours TPM Deltas Ours TPM Deltas Ours
1
10
100
1000
10000
1955
9.5
2020
FirefoxAbiword
do
wn
time
(ms)
OpenOffice
downtime(ms)
21001930
10 9.6
30603020
TPM Deltas Ours TPM Deltas Ours TPM Deltas Ours
0
20
40
60
80
29.9
97.795.2
24.2
7473.7
25.9
75.675.1
switc
h tim
e(s)
switch time(s)
Abiword OpenOffice Firefox
Firstly realize the TPM[11](Three Phase Migration) and Deltas-apply[13] scheme in the hypervisor KVM
reduced significantly to only 10 milliseconds in comparison to 2-3s
Downtime Switch time
reaches an average 67% switch time reduction
15
0
10
20
30
40
50
60
70
80
90
100
110
34.81
74
FirefoxOpenOffice
time
cons
umpt
ion(
s)
Abiword
disk post synchronization
memory migration
disk precopy
73.976.06 75.6
39.12
102.93
97.7
43.15
TPM Deltas Ours TPM Deltas Ours TPM Deltas Ours
0
100
200
300
400
500
600
700
800
900
1000
1100
1200
437.91
817.04816.7
417.51
795.75793.7
OursDeltasTPM
FirefoxOpenOffice
amou
nt o
f mig
ratio
n da
ta(M
B)
disk synchronization
memory migration
disk precopy
Abiword
TPM Deltas Ours DeltasTPM Ours
1080.791107.34
481.66
Migration performance comparison
Migration time Migrated Data
Although takes a slight longer time(13.6s) during disk post synchronization, the total migration time is greatly reduced by at most 58% in all circumstance.
The entire migration data is only 481.66MB reaching roughly 55.4% and 56.5% decrease.
Conclusion
• Two-tier software execution architecture considering CloudAP and Cloud center (Public cloud).
• Optimized whole-system VM migration approach which fulfills rapid migration and effective execution environment switch.
16
Thank you for your attention!
Renyu Yang, Ph.D. student School of Computing Beihang University, Beijing, China Homepage: http://act.buaa.edu.cn/yangrenyu Email: [email protected]