Eucalyptus - An Open-source Infrastructure for Cloud Computing


Published on

Published in: Technology
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Eucalyptus - An Open-source Infrastructure for Cloud Computing

  1. 1. An Open-source Infrastructure for Cloud Computing Tudor Zaharia
  2. 2. Overview of the presentation What is a Cloud? Public Clouds Open Source Cloud Infrastructure Eucalyptus What is it? Goals Features Design and architecture Experiment Conclusions
  3. 3. What is a Cloud? SLAs Web Services Virtualization
  4. 4. Public Clouds (Now) Large scale infrastructure available on a rental basis Operating System virtualization (e.g. Xen) provides CPU isolation Network isolation Locally specific storage abstractions Fully customer self-service Service Level Agreements (SLAs) are advertized Requests are accepted and resources granted via web services Customers access resources remotely via the Internet Accountability is e-commerce based Web-based transaction “Pay-as-you-go” and flat-rate subscription Customer service, refunds, etc.
  5. 5. Open Source Cloud Infrastructure Simple Transparent Scalable => complexity often limits scalability Extensible New application classes and service classes may require new features Clouds are new => need to extend while retaining useful features Commodity-based Must leverage extensive catalog of open source software offerings New, unstable, and unsupported infrastructure design is a barrier to uptake, experimentation, and adoption Easy To install => system administration time is expensive To maintain => system maintaining time is really expensive
  6. 6. Eucalyptus
  7. 7. Eucalyptus Elastic Utility Computing Architecture Linking Your Programs To Useful Systems
  8. 8. Eucalyptus - what does it brings? • Web services based implementation of elastic/utility/cloud computing infrastructure — Linux image hosting ala Amazon • How do we know if it is a cloud? — Try and emulate an existing cloud: Amazon AWS • Functions as a software overlay — Existing installation should not be violated (too much) • Focus on installation and maintenance — “System Administrators are people too.”
  9. 9. Design goals Extensibility Non-intrusiveness
  10. 10. Features Current release is version 1.5.1: Interface compatibility with EC2 (both Web service and Query interfaces) Support for the KVM hypervisor Stand-alone RPMs for non-Rocks RPM based systems Secure internal communication using SOAP with WS-security Elastic Block Store (EBS) compatible storage service Basic "Cloud Administrator" tools for system management and user accounting The ability to configure multiple clusters, each with private internal network addresses, into a single Cloud.
  11. 11. Installation prerequisites Support XEN virtualization Host Web services
  12. 12. Architecture Starting point: Firewall
  13. 13. Architecture Hierarchical design reflecting underlying resources:
  14. 14. Architecture Hierarchical design reflecting underlying resources: Cloud controller
  15. 15. Cloud Controller user/admin entry point high-level VM instance scheduling decisions processing SLAs maintaining system and user metadata
  16. 16. Cloud Controller as a service provider handle user requests and authentication handle persistent system and user metadata (VM images and ssh keys) manage and monitor VM instances Web interfaces and Query interfaces
  17. 17. Architecture Hierarchical design reflecting underlying resources: Cluster controller
  18. 18. Cluster Controller groups collections of Node Controllers that logically belong together gathers state information from its nodes schedules incoming VM instance execution requests manages the configuration of public and private instance networks described as WSDL
  19. 19. Architecture Hierarchical design reflecting underlying resources: Node controller
  20. 20. Node controller executes on the physical resources instance startup inspection shutdown cleanup only one NC per physical machine is needed (regardless on the number of VM's on that machine) calls the hypervisor (XEN) to control and inspect running instances.
  21. 21. Virtual networking Things to address: Performance Isolation Connectivity
  22. 22. Virtual network connectivity Each instance is given: one "public" network interface handles communication to "outside" world bridged to real network device one "private" network interface used only for inter - VM communication CC deals with set-up and tear down of virtual network
  23. 23. Virtual network isolation instances are assigned tags used as VLAN identifiers tag incomming traffic forward packets that have the same VLAN
  24. 24. Experiment Small research Linux cluster: System description: 7(compute nodes) + 1(head node) of Intel Xeon 3.2GHz, 3GB of RAM, 40GB single SCSI disk single CLC single CC one NC per node Access and restrictions Granted by the CLC through user signup web page Allocation is limited to 4 instances killed after 6 hours Reverse firewall for preventing EPC accesing external network addresses (except Linux distribution sites) Ambient induced load
  25. 25. Comparison - Instance throughput
  26. 26. Comparison - Instance throughput
  27. 27. Comparison - Instance throughput
  28. 28. Comparison - Network performance Eucalyptus vs. EC2
  29. 29. Conclusions Eucalyptus was designed from the ground up to be easy to install and as non-intrusive as possible (can be installed on a laptop for experimentation) Highly modular External interface is based on highly popular API of Amazon (industry standard interface) Unique among the open-source offerings in providing a virtual network overlay
  30. 30. Questions? Anyone?
  31. 31. Challenges Extensibility Simple architecture and open internal APIs Client-side interface Amazon’s EC2 interface and functionality (familiar and testable) Networking Virtual private network per cloud Must function as an overlay => cannot supplant local networking Security Must be compatible with local security policies Packaging, installation, maintenance system administration staff is an important constituency for uptake
  32. 32. EC2 Compatibility Interface is based on Amazon’s published WSDL 2008 compliant except for static IP address assignment Security groups “Availability” zones correspond to individual clusters Uses the EC2 command-line tools downloaded from Amazon REST interface S3 support/emulation: not yet, but on its way Images accessed by file system name instead of S3 handle for the moment Unless user wants to use the actual S3 and pay for the egress charges System administration is different Eucalyptus defines its own Cloud Admin. tool set for user
  33. 33. Networking Eucalyptus does not assume that all worker nodes will have publicly routable IP addresses Each cloud allocation will have one or more public IP addresses All cloud images have access to a private network interface Two types of networks internal to a cloud allocation Virtual private network Uses VDE interfaced to Xen that is set up dynamically Substantial performance hit within a cluster Allows a cloud allocation to span clusters High-performance private network (availability zone) Bypasses VDE and uses local cluster network for each allocation Runs at “native” network speed (I.e. with Xen) Cloud allocations cannot span clusters
  34. 34. Performance of the Virtual Network
  35. 35. Security All Eucalyptus components use WS-security for authentication Encryption of inter-component communication is not enabled by default Configuration option Ssh key generation and installation ala EC2 is implemented Cloud controller generates the public/private key pairs and installs them User sign-up is web based User specifies a password and submits sign-up request Cert is generated but withheld until admin. approves request User gains access to cert. through password-protected web page Similar to EC2 model without the credit cards
  36. 36. Packaging, Installation, and Deployment Rocks “One-button” install per cluster Requires Rocks V (the most current release) for Xen support If you know what you are doing, RPMs can be extracted and installed manually Multiple clusters requires a configuration file Multi-cluster configuration tools ala Rocks not readily available Build-from-source “Many-button” install Instructions, scripts, rsync, and perseverance Single-machine “cloud”