An Innovative Open Source Middleware for Managing Virtual Resources in Federated Clouds

An Innovative Open Source Middleware for Managing Virtual Resources in Federated Clouds

Francesco Tusa, Maurizio Paone, Antonio Celesti, Massimo Villari, Antonio Puliafito
Copyright: © 2012 |Pages: 29
DOI: 10.4018/978-1-4666-0098-0.ch004
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

This chapter describes the CLEVER architecture, focusing on its design process and highlighting the communication mechanisms employed by its entities. The last part of the chapter discusses how CLEVER could be easily integrated with higher-level cloud middleware for managing service deployment according to the cloud users’ requests.
Chapter Preview
Top

Introduction

In the current cloud ecosystem, the interest is growing on the development of tools that let organizations build their own IaaS clouds using their internal computing resources (Foster, Llorente, Montero, & Sotomayor, 2009). This is the idea on which private clouds are based: they are provided by an organization and offer a dedicated operating environment with high trust level. The computing infrastructure is thus owned by a single customer that controls the applications being executed. These clouds, differently from the public ones, do not provide and sell computing capacity over the Internet through publicly accessible interfaces, but give to local users a flexible and agile private infrastructure for running service workloads within their administrative domains. For the successful implementation of the Cloud computing paradigm, well-developed resource markets are fundamental (Altman, et al., 2011). Cloud computing markets face challenges, such as low liquidity of tradable goods caused by the heterogeneity of resource types. Illiquid goods have a risk of not being purchasable when needed, driving market participants away. Hence Cloud Infrastructures have to enable new capabilities for easily combine heterogeneous resources.

Looking forward, private clouds can also support a hybrid cloud model, by adding to the local infrastructure more computing capacity coming from an external public cloud (Rochwerger, et al., 2011). A private/hybrid cloud can allow remote access to its resources over the Internet using remote interfaces, such as the Web services interfaces that Amazon EC2 uses (Amazon EC2, 2011; Amazon VPC, 2011). The logical organization of private/hybrid cloud architectures can be analyzed keeping in mind the stack of Figure 1, where three different levels exist: the lowest one named Virtual Machine Manager, the second one named Virtual Infrastructure Manager and finally the highest one named Cloud Manager.

Figure 1.

Three tier stack of private/hybrid cloud architectures

978-1-4666-0098-0.ch004.f01
  • The Virtual Machine Manager (VMM) can be generally associated to the Hypervisor running on top of the Operating System;

  • The Virtual Infrastructure Manager (VIM) which acts as a dynamic orchestrator of Virtual Environments (VMs);

  • The Cloud Manager which manages the service requests coming from the cloud users, interacts with the VIM and addresses security, contextualization and federation issues.

The VMM provides an abstraction layer to the VIM. It interacts with the Hypervisor running on top of the Operating System (OS) of each server composing the cloud's datacenter, and enables the capability of deploying Virtual Environments (VEs) or Virtual Machines (VMs) on the physical hardware where it is running. Most of cloud middlewares mainly exploit this layer adding some new features.

Complete Chapter List

Search this Book:
Reset