Changes between Initial Version and Version 1 of GENICloud/Feb2012-report

04/19/17 18:14:58 (5 years ago)
Vic Thomas



  • GENICloud/Feb2012-report

    v1 v1  
     1'''GENICloud Progress Report February 2012'''
     3In this period, we began the migration of GENICloud to an !OpenStack-based management framework, using KVM and LXC as, respectively, the virtual machine and container environment, replacing our previous PlanetLab-based installation.  The goal of this is threefold:
     4 1. To demonstrate that the SFA can be implemented on top of !OpenStack, and to develop a reference implementation of SFA on  OpenStack that we will be able to contribute back to the Open Stack  community.     Eventually, this could lead to a very large number of SFA-compliant Clouds throughout the US and the world.
     5 1. To leverage the tools and infrastructure developed by the !OpenStack community for GENI researchers; in particular, the integration of the Quantum programmable network infrastructure into the SFA GENI stack;
     6 1. Begin the migration of the PlanetLab operational infrastructure to an !OpenStack basis.    PlanetLab is a  10-year-old infrastructure whose functionality has since been partially duplicated by popular Cloud management stacks such as !OpenStack and Eucalyptus, and by virtualization technologies such as LXC and KVM.  The current PlanetLab implementation -- MyPLC as the cluster control and Vservers on the nodes -- involves tens of thousands of lines of code on the controller and a 35,000 line kernel patch, which must be maintained by a small team of PlanetLab developers.  Moving to standards will offer a more sustainable future for PlanetLab.
     8A further motivation for the GENICloud effort was to federate cloud systems into
     9the distributed and experimental infrastructures provided by GENI.     Current GENI platforms largely are
     10not designed to scale rapidly on demand.  Under the federation of a standard Cloud platform and GENI, a more comprehensive platform is available to users; for example, development, computation, data generation can be done within the cloud, and deployment of the applications and services can be done on distributed platforms (e.g., PlanetLab). By taking advantage of cloud computing, GENI users  can dynamically scale their services on GENI depending on the demand of their services, and benefit from other services and uses of the cloud. Take a service that analyzes traffic data as an example; the service can deploy traffic collectors to collect Internet traffic data on PlanetLab . The traffic collected can be stored and processed in the cloud.   
     12PlanetLab  has high global penetration. However, it was not designed for either scalable computation nor large data services. Some services and experiments require a huge amount of data or they need to persist a large amount of instrumental data; also, it lacks the computation power for CPU intensive services or experiments. GENICloud fills in the gap by federating heterogeneous resources, in this case, a cloud platform with PlanetLab.
     14Most of the implementation effort of GENICloud concentrated on implementing the aggregate manager on top of the existing Cloud Controller, under both Eucalyptus and !OpenStack. A key design choice was whether to
     15modify the existing Controller, or use an overlying controller which implemented SFA API calls by calling
     16through to the underlying controller.
     19We chose the latter.  In
     20our  architecture, both the fact that the user is coming through an SFA layer and the identity of   the underlying
     21controller is hidden.   The SFA aggregate manager acts an mediator between user requests and an underlying cloud. The primary advantage is that we need not maintain modifications and patches in existing
     22Cloud managers, updating them as new modifications come out; rather, we only need up date our Aggregate
     23Manager as the interface to the Cloud manager changes.   We have not yet implemented, but do not exclude,
     24Cloud controller specific optimizations for controllers with specific optimizations such as Tashi}\.  A secondary advantage is that the identity of the underlying
     25Cloud controller is hidden from the user, meaning that user-facing tools and scripts don't change when the
     26underlying Cloud controller is hidden.
     28In this period, we built an initial implementation of the SFA on OpenStack, using LXC as the Virtualization Layer, and Nova (the OpenStack compute manager) as the node manager.  MyPLC is retained as the front end to the cluster, and slices and slivers can be created using the standard PlanetLab front end.  PlanetLab user id's, passwords, and keys are used, so that the GENICloud resource is available to PlanetLab users who agree to the OpenCirrus tems and conditions.
     30We have built a command-line tool,, which allocates VMs through the sfi API.