1 / 14

OC2

Open Compute Cloud. OC2 . What is OC2?. An open-source package for providing dynamic virtual machine (VM) creation and management Based on the concept of Amazon's EC2 Elastic, full guest control, flexible, reliable, and secure It should also have some other nice properties:

trung
Download Presentation

OC2

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Open Compute Cloud OC2

  2. What is OC2? • An open-source package for providing dynamic virtual machine (VM) creation and management • Based on the concept of Amazon's EC2 • Elastic, full guest control, flexible, reliable, and secure • It should also have some other nice properties: • Research vehicle, easy deployment, exotic features

  3. Why OC2? • There is significant commercial and research interest in such a system • It has some nice properties – dynamic host creation, resource sharing, potentially reduced maintenance and upkeep costs • An open-source solution can provide access to others as well as the right access points to experiment with different configurations

  4. Targeted Functionality(Kozuch's Kommandments)‏ • Command line & web interface to control VMs • Possibly directly compatable with EC2 utilities & images • Direct access to VMs (root user, IP addr, etc)‏ • Transparent VM migration, checkpointing • Boot images natively (boot-agnostic)‏ • Use distributed store (exclusively for persistent data)‏ • Single-core guests to start with

  5. Architecture

  6. Virtual Machines • Several projects/mechanisms to consider: • Qemu (software, open)‏ • Xen paravirtualization (guest changes necessary, open)‏ • Xen HVM (VT + Qemu + host kernel changes, open)‏ • VMware (VT and/or software, closed)‏ • KVM (VT + Qemu, open)‏ • Believe KVM has the right set of trade-offs, but staying agnostic is a plus • Using bridging to make them visible directly

  7. Client/Server Software • Currently a set of scripts that use wget, curl, etc. to issue requests to the server • The server currently uses PHP and a database backend for information management • Eventually there could be a layer that simulates the behavior of the EC2 utilities (SOAP)‏ • This is and should be the simplest part of the system

  8. Server/Host Software • Currently a very rudimentary direct connection • Switching to libvirt • libvirt provides an API to manipulate VMs and supports multiple backends (KVM, Qemu, Xen, etc.)‏ • Nice abstraction layer for functionality that also provides security options (SASL and SSL)‏

  9. Migration • KVM/Qemu already support a form of live migration • Limited to the memory & CPU state • Disk changes must be in a shared R/W file • Adding support to migrate disk changes • libvirt only supports migration for Xen • Adding support to migrate Qemu • Still have switch problem to solve

  10. Checkpointing • KVM/Qemu support checkpointing • Checkpoints are saved to the disk image, however • Disk image likely comes from some distributed store • Migration, if it includes disk state, can be used to perform checkpointing • Allows background checkpointing • Disk vs. memory checkpointing • Still need to support using disk changes from migration file only

  11. Native Boot • Would like to boot a disk image on real hardware for some users • Can be done using a minor addition to a script • Save disk image on local disk of machine • Copy initrd and kernel image out • Modify script in initrd to loopback mount the image • PXE boot new initrd with kernel • Still has intermittent access to distributed store

  12. Distributed Store • Currently using HDFS+FUSE • Modifications necessary because the FUSE code is less than alpha • Works correctly and performance is alright • Still need a better characterization • How this is going to work for application data is also an issue to be explored

  13. Work Done • Qemu changes to support disk migration • libvirt changes to support Qemu migration • Simple command line utilites and database backend • Native image booting process • Distributed store used for images • Started IT rolling on new IP addresses

  14. Work To Do • Replacing server->host communication with libvirt • Distributed store evaluation • Hooks (automatic migration, checkpoint/resume)‏ • Automatic native booting • EC2 SOAP compatability • Code cleanups and submission

More Related