Services‎ > ‎Usage scenarios‎ > ‎

Extended cloud


Extended Cloud Scenario

Motivation & Objectives

The primary goal of this scenario is to provide researchers with a flexible infrastructure for the on-the-fly provisioning of services. In order to fulfill this view, the BonFIRE testbed will address the following requirements:

  • The BonFIRE infrastructure should be service agnostic and the researchers should have full control of the software components installed as part of the service.
  • The BonFIRE users should define the experimental infrastructure with single declarative models (test descriptors) that include the network, storage and compute resources.
  • BonFIRE experiments should be defined, controlled and monitored through a single interface.
  • The researches should have full control over the service layout, and in general its components can be deployed across multiple sites which make up the BonFIRE testbed. In this case the interconnection between service components should be established by current Internet procedures like virtual private networks or forwarding techniques.
  • BonFIRE should not impose any special requirement to the individual sites, apart from providing basic infrastructure level SLAs to ensure the needed reproducibility of service experiments.

High level overview of extended cloud scenario
Figure 1: High level overview of extended cloud scenario.

Background

The BonFIRE infrastructure should be flexible enough to deploy a wide range of services in terms of their scale, components and layout. In order to fulfill this view, we assume the following structure for a service:

  • Components: A service is a set of functional components that can be put in one or more virtual machines (VM). The researchers will have total control over the type of VM (e.g. amount of memory, number of cores, or storage area) and the software stack installed in it.
  • Networking: Service components communicates through isolated networks. Researchers are able to generate any type of traffic (including multicast/broadcast) without interfering with others. Typically, these communications patterns are needed by monitoring tools, intrusion detection systems, or to stress the service.
  • Storage: Service components may rely on persistent storage areas to keep experiment configuration data (e.g. benchmarking data to be loaded in the service component) or to collect performance measurements form each experiment run.

A typical experiment in this scenario would require the following steps:

  • Service Definition: The experiment is expressed as a VM Group that defines the general layout of the service experiment and it includes VMs, networks and placement constraints. In this way, the researcher will be able to define an entire infrastructure by delivering a single declarative model.
  • Service Preparation: The researchers are responsible for preparing the service components (VMs).There is no restriction to the software installed in the VMs, assuming it is necessary for the execution of the experiment.
  • Service Deployment: The researcher will upload the VMs images to the BonFIRE infrastructure and start the service deployment.
  • Service Experimentation and Monitoring: Once the service is deployed and running the researcher can start the analysis and collect  monitoring information from both the service itself and the infrastructure.

Service components and networks can be placed in multiple BonFIRE sites, according to a set of allocation constraints specified by the researcher. The communication between service components in different BonFIRE sites should be established using current Internet technology. The schema of a service deployed on the BonFIRE infrastructure is depicted Figure 1

Enabling Technologies

The core of a BonFIRE site in this scenario is the OpenNebula Virtual Infrastructure Manager. OpenNebula is an open and flexible tool that fits into existing data center environments to build any type of Cloud deployment. OpenNebula can be primarily used as a virtualization tool to manage a virtual infrastructure in the data-cente (Private Clouds). OpenNebula also provides Cloud interfaces (the EC2 Query API and the OCCI standard) to expose its functionality for virtual machine, storage and network management. OpenNebula is based on a flexible, plug-able architecture that allows its integration with any storage, networking or virtualization technology.

Future Developments

To support the scenario described above, the BonFIRE infrastructure will comprise the federation of a number of BonFIRE sites. Each site should provide a Cloud-like interface for the instantiation, management and monitoring of virtualized resources including: networks, compute resources and storage. Future developments of this scenario will explore brokering techniques for the efficient multi-site deployment of services. Also, we will investigate the need to extend current standardsto support service semantics. The deployment of a service experiment in BonFIRE requires the preparation of the VMs that will support the service. Usually, this task involves low level administration tasks that may increase the  time-to deployment of an experiment. In a second phase of this scenario, we will provide basic VM templates, or BonFIRE appliances, with usual software installations, monitoring tools and network configurations. The BonFIRE appliance can be further customized by the experiments.