VDN Virtual Machine Image Distribution Network for Cloud

VDN: Virtual Machine Image Distribution Network for Cloud Data Centers Chunyi Peng 1, Minkyong Kim 2, Zhe Zhang 2, Hui Lei 2 1 University of California, Los Angeles 2 IBM T. J. Watson Research Center IEEE INFOCOM 2012 Orlando, Florida USA

Cloud Computing the delivery of Computing as a Service Infocom 2012 C Peng (UCLA)

Service Access in Virtual Machine Instances Cloud Clients Web browser, mobile app, thin client, terminal emulator, … Infra structure Platform Application Client Service Requests (e. g. HTT Software as a Service (Saa. S) CRM, Email, virtual desktop, communications, … Platform as a games, Service (Paa. S) VM VM VM Execution runtime, database, web server, development … Infrastructure as a tools, Service (Iaa. S) Virtual machines, server storage, load balancer, networks, … Infocom 2012 C Peng (UCLA) Problem: On-demand VM provisioning Picture source: http: //www. wikimedia. org

Time for VM Image Provisioning User request Req process VM image transfer Our focus: Transfer time VM Bootup time Response in several or tens of minutes in reality! Infocom 2012 C Peng (UCLA)

Why Slow? � VM image files are large (several or tens of GB) � Centralized image storage becomes a bottleneck Data Center Core Aggregation Imageserver Access To. R switch RH 5. 6 Infocom 2012 RH 5. 6 C Peng (UCLA)

Roadmap � Basic VDN idea: enable collaborative sharing � VDN solution on efficient sharing � Basic sharing units � Metadata management � Performance evaluation � Conclusion Infocom 2012 C Peng (UCLA)

VDN: Speedup VM Image Distribution � Enable collaborative sharing � Utilize the “free” VM images � Exploit source diversity and make full use of network bandwidth Core Aggregation Imageserver Access To. R switch RH 5. 6 Infocom 2012 RH 5. 5 RH 5. 6 C Peng (UCLA) RH 6. 0 RH 5. 6

How to Enable Collaborative Sharing? � What is the basic data unit for sharing? � File-based sharing: Allow sharing only among same files � Chunk-based sharing: Allow sharing of common chunks from different files � How to manage content location information? � Centralized solution: directory service, etc. � Distributed solution: P 2 P overlay, etc. Infocom 2012 C Peng (UCLA)

What is the Appropriate Sharing Unit? � Two factors � The number of the same, alive VM image instances � The similarity of different VM images � Conduct real trace analysis and cross-image similarity measurement � VM traces from six operational data centers for 4 months � VM images including different Linux/Windows versions, IBM services (DB 2, Rational, Web. Sphere) etc Infocom 2012 C Peng (UCLA)

VM Instance Popularity � The distribution of image popularity is highly skewed �A few popular images take a large portion of VM instances � Many unpopular images have a small number of VM instances (< 5) �Few peers can involve in file-based sharing Unpopular VM images Infocom 2012 C Peng (UCLA)

VM Instance Lifetime � The lifetime of VM instance varies � 40% instances (more popular VM instances) < 13 minutes � The unpopular VM images have longer lifetime �VM image distribution network should cope with various lifetime instances 13 min Infocom 2012 C Peng (UCLA)

VM Image Structure � Tree-based VM image structure Red Hat (53%) Linux (60%) Enterprise Linux v 5. 5 (32 bit) Enterprise Linux v 5. 5 (64 bit) … Enterprise Linux v 5. 4 (32 bit) … Enterprise Linux v 5. 6 (32 bit) SUSE …… (7%) Windows…… (25%) Database …… IDE …… Services …… (11%) Web app. server …… Misc …… (4%) Infocom 2012 V 7. 0 B (0. 7%) V 7. 0. 0. 11 S P (0. 7%) V 7. 0. 0. 11 R B (0. 3%) V 7. 0. 0. 11 S D (0. 2%) V 7. 0 P (0. 1%) C Peng (UCLA) (26. 6%) (18. 7%) (4%) (0. 2%)

VM Image Similarity � High similarity across VM images � Chunk schemes: fixed size and Rabin fingerprinting � Similarity: Sim(A, B) = |A’s chunks that appear in B| /|A| � Chunk-based sharing can exploit cross-image similarity Infocom 2012 C Peng (UCLA)

Enable Chunk-based Sharing � Decouple VM images into VM chunks � Exploit similarity across VM images � Provide a higher source diversity and sharing opportunity RH 5. 6 RH 5. 5 RH 5. 6 RH 6. 0 RH 5. 6 Questions: How to maintain chunk location information (metadata) How to be scalable and also enable fast data transmission Infocom 2012 C Peng (UCLA)

How to Manage Location Information? � Solution I: centralized metadata server � Cons: be simple � Pros: bottleneck at metadata server � Solution II: P 2 P overlay network, e. g. , DHT � Cons: distributed operations � Pros: be unaware of data center topology and may introduce high network overhead Internet I-S Infocom 2012 C Peng (UCLA)

Issues in Conventional P 2 P Practice One logic operation (lookup/publish) Multiple physical hops Hop costs (e. g. time) can be high! Solution: Reduce # of hops Reduce the cost of physical hops Infocom 2012 C Peng (UCLA) Keep it local or with close buddies

Topology-aware Metadata Management � Divide all the hosts into different-level hierarchies and manage chunks in each hierarchy �Utilize static/quasi-static (controlled) topology �Exploit high bandwidth local links in hierarchical structure Internet L 3 L 2 I-S L 1 H H H Infocom 2012 C Peng (UCLA) L 1

VDN: Encourage Local Communication � Local chunk metadata storage � Index nodes maintain only metadata within this hierarchy � Unnecessary to maintain a global view at all index nodes � Local chunk metadata operation (e. g. , lookup/publish) Ask close index nodes first � Lower operation overhead � � Local chunk data delivery � Enable high bandwidth transmission between close hosts (e. g. within the rack) Infocom 2012 C Peng (UCLA)

VDN Operation Flows � Recursive operation from lower-hierarchy to higher- hierarchy L 3 A. Metadata update B. Metadata lookup C. Data transmission 3 C. Imageserver L 2 3 B. 1. L 1 2. Local Cache Infocom 2012 L 1 3 A. 4 A L 1 4 B 5 C Peng (UCLA) L 1

Performance Evaluation � Setting � One-month real trace driven simulation � VM image: 128 MB~ 8 GB � Tree topology: 4 x 4 x 8 (128 nodes) � Network I- (4 -) S disk I/O: 1 Gbps Net BW: 1 Gbps bandwidth: � Static throughput for one physical link (8 -nodes) � Queue-based simulation for multiple transmissions on one link � Schemes Baseline: centralized operation � Local: fetch VM chunks from local host if possible � VDN: enable collaborative sharing � Infocom 2012 C Peng (UCLA) 200 Mbps 500 Mbps 2 Gbps

Great Speedup on Image Distribution S 1 data center S 6 data center at S 6, VM image size = 4 GB Infocom 2012 C Peng (UCLA)

Scalable to Heavy Traffic Loads � Adjust time-of-arrival using factor 1 -60 S 6, Median Infocom 2012 S 6, 90 th C Peng (UCLA)

Low Metadata Management Overhead � Compare with three metadata management schemes � Naïve: on-demand topology-aware broadcast � Flat: manage metadata in a ring (e. g. DHT, P 2 P) � Topo: topology-aware design (VDN) �Assume the communication cost is 1: 4: 10 (reverse to bandwidth) (a) Number of messages Infocom 2012 C Peng (UCLA) (b) Communication cost

Conclusion � VDN is a network-aware P 2 P paradigm for VM image distribution � Reduce image provisioning time � Achieve the reasonable overhead � Chunk-based sharing exploit inherent cross-image similarity � Network-aware operations can optimize the performance in the context of data centers Infocom 2012 C Peng (UCLA)

THANKs Infocom 2012 C Peng (UCLA)