Live migration of virtual machines
Download
1 / 26

Live Migration of Virtual Machines - PowerPoint PPT Presentation


  • 90 Views
  • Uploaded on

Live Migration of Virtual Machines. Christopher Clark, Keir Fraser, Steven Hand, Jacob Gorm Hansen†,Eric Jul†, Christian Limpach , Ian Pratt, Andrew Warfield University of Cambridge Computer Laboratory † Department of Computer Science ,University of Copenhagen, Denmark.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Live Migration of Virtual Machines' - gretel


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Live migration of virtual machines

Live Migration of Virtual Machines

Christopher Clark, Keir Fraser, Steven Hand, Jacob GormHansen†,Eric Jul†, Christian Limpach, Ian Pratt, Andrew Warfield

University of Cambridge Computer Laboratory

† Department of Computer Science ,University of Copenhagen, Denmark

USENIX NSDI ‘05


Introduction
Introduction

  • Operating system virtualization has attracted considerable interest in recent years

    -In data Centers, cluster computing communities

  • allows many OS instances to run concurrently on a single physical machine

  • Migratingan entire OS and all of its applications as one unit

    • Compared to the process migration (residual dependencies)


Introduction1
Introduction

  • Live Migration

  • Without interfering the network connection

  • Allows a separation of concerns between the users and operator of a datacenter or cluster.

  • Allowing separation of hardware and software considerations


Introduction2
Introduction

  • Downtime

    • services are entirely unavailable

  • Total migration time

    • during which state on both machines is synchronized and which hence may affect reliability

  • This paper use the “pre-copy” approach to achieve live migration and target on decreasing the downtime (implemented on Xen)


  • Design
    Design

    • Network

      Generate an ARP reply from the migrated host, advertising that the IP has moved to a new location.

    • Storage

      Use a network-attached storage (NAS) device

      Do not need to migrate disk storage


    Design1
    Design

    • Memory Transfer

      • Push phase

      • Stop-and-copy phase

      • Pull phase

    • most practical solutions select one or two of the three phases

      • pure stop-and-copy, pure demand

    • This paper uses iterative push phase with a typically very short stop-and-copy phase.


    Related work
    Related Work

    • Shutdown the VM

    • Pre-Copy

    • VMware


    Related work1
    Related Work

    • Post-Copy Live Migration of Virtual Machines

    • Michael R. Hines, Umesh Deshpande, and Kartik Gopalan

      Computer Science, Binghamton University (SUNY)

      ACM SIGPLAN/SIGOPS VEE’09



    Writableworking sets
    WritableWorking Sets

    • Some pages will seldom or never be modified and hence are good candidates for pre-copy

    • Some will be written often and so should best be transferred via stop-and-copy

      => WritableWorkingSets




    Dynamic rate limiting
    Dynamic Rate-Limiting

    • Dynamically adapt the bandwidth limit during each pre-copying round

    • The administrator selects a minimum(m) and a maximum(M) bandwidth limit

    • The first pre-copy round transfers pages at the minimum bandwidth m


    Dynamic rate limiting1
    Dynamic Rate-Limiting

    • Dirtying rate =

      (the number of pages dirtied in the previous round)

      / (duration of the previous round)

    • Bandwidth rate for next round =

      Dirtying rate + 50 Mbits/sec

    • Stop pre-copy when

      • Calculated rate > M

      • Less than 256KB remains to be tranferred


    Some implementation issues
    Some implementation issues

    • Rapid Page Dirtying

      • Do not need to always transfer hot pages

    • Freeing Page Cache Pages

      • In the first round

    • Stunning Rogue Processes

      • Limit each process to 40 write faults each time


    Stunning rogue processes
    Stunning Rogue Processes


    Evaluation
    Evaluation

    • Dell PE-2650 server-class machines

    • dual Xeon 2GHz CPUs

    • 2GB memory

    • connected via Gigabit Ethernet

    • Storage: iSCSIprotocol NAS

    • XenLinux 2.4.27


    A simpleweb server
    a. SimpleWebServer

    • Apache 1.3 web server

    • Continuously serving a single 512KB file

    • memory allocation: 800MB

    • Initially rate limited to 100Mbit/sec

    • 776MB memory to be transferred in the first round

    • 165ms outage


    A simpleweb server1
    a. SimpleWeb Server


    B complexwebworkload specweb99
    b.ComplexWebWorkload:SPECweb99

    • memory allocation: 800MB

    • 30% require dynamic content generation

    • 16% are HTTP POST operations

    • 0.5% execute a CGI script

    • The server generates access and POST logs

    • 210ms outage



    C low latency server quake 3
    c. Low-Latency Server: Quake 3

    • a multiplayer on-line game server

    • a virtual machine with 64MB of memory

    • Six players joined the game and started to play within a shared arena

    • transfers so little data (148KB) in the last round

    • Downtime: 60ms



    D a diabolicalworkload mmuncher
    d. A DiabolicalWorkload: MMuncher

    • a virtual machine is writing to memory faster than can be transferred

    • Memory: 512MB

    • a simple C program that writes constantly to a 256MB

    • Downtime: 3.5 seconds


    D a diabolicalworkload mmuncher1
    d. A DiabolicalWorkload: MMuncher


    Conclusion
    Conclusion

    • A pre-copy live migration method on Xen

    • Concern about WWS

    • Dynamic network-bandwidth adaption

    • realistic server workloads such as SPECweb99 can be migrated with just 210ms downtime

    • a Quake3 game server is migrated with an imperceptible 60ms outage


    ad