We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Cloud.SM - FIWARE Forge Wiki

FIWARE.OpenSpecification.Cloud.SM

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Cloud.SM
Chapter Cloud,
Catalogue-Link to Implementation Claudia
Owner FI-WARE Telefónica I+D, Fernando López Aguilar

Contents

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.

FIWARE WIKI editorial remark:
This page corresponds to Release 3 of FIWARE. The latest version associated to the latest Release is linked from FIWARE Architecture

Copyright

Copyright © 2011-2013 by Telefónica I+D. All Rights Reserved.

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.

Overview

This specification describes the Infrastructure as a Service (IaaS) Service Manager GE (IaaS SM GE), which is the key enabler for deployment and lifecycle management of virtual appliances (vApps). A vApp refers to the virtual infrastructure required by an application (or part of a larger application) to run. A vApp is typically structured into tiers, each of which is made up of a set of connected virtual servers that share the same virtual image. The IaaS SM GE is able to perform up/down (vertical) and in/out (horizontal) scaling of virtual servers within the tiers of a given vApp in an automated manner, based on defined rules.

The IaaS SM GE provides a more flexible and easier way to use the FI-WARE platform to deploy services based on the definition of infrastructure requirements using vApps. It brings lots of benefits to the traditional IaaS cloud model and helps to save valuable time/resources by automating the management of tasks that need to be done repeatedly. These tasks include the provisioning of servers, volumes and networks as well as the management operations related to them. Since it is working at the virtual appliance level, operations are done only once for the whole process and not one by one for each component, hiding the complexity of the platform to service providers.

Additionally, this GE allows Cloud users to extend the basic functionalities offered by the DataCenter Resource Management (DCRM) GE in order to cope with elasticity management. It allows, through the definition of elasticity rules, scaling in/out the virtual servers associated to tiers in a given vApp and configures the appropriate load balancer to do it. The scaling in operation allows increasing horsepower of your virtual infrastructure through provisioning of additional copies (clones) of allocated virtual servers in a given tier and configuring the load balancer associated to the tier to manage them.

Last but not least, the architecture of the IaaS SM GE is defined to allow the integration with other private or public cloud offerings by alternative cloud providers. Thus, it helps to build a federated cloud solution in a very simple manner. Cloud federation is defined here as the deployment and management of several internal and/or external cloud computing services to match business needs. Cloud federation enables cloud providers to expand their geographic locations and accommodate sudden pikes in demand without having to build new access point to the Internet (physical location with servers, routers and so on).

The following diagram shows the main components of IaaS SM GE (in gray boxes).

IaaS SM  Architecture Overview


IaaS SM architecture specification


In the above diagram, the Service Manager Interface (SMI) is the front-end of the IaaS SM GE, providing an OpenStack Compute API compliant interface. It dispatches the requests received from the cloud user or cloud portal to components handling each of the vApps management operations/tasks (e.g., deploy servers, deploy vApps and management of scalability rules). At the back-end, different aspects of vApp management are handled by the corresponding internal components, such as elasticity, vApps management, projects management and domain management. A detailed description of these operations is shown in section Interfaces together with the description of these components in section Components. Note that additional management functionality and components will be added in future releases of the IaaS SM GE.

Target Usage

The IaaS SM GE introduces a layer on top of DCRM, as well as other components in the FI-WARE Cloud Reference Architecture, in order to provide a higher-level of abstraction to Application/Service providers. Thus, the service provider does not have to manage the individual placement or location of servers, storage and networks on physical resources but only has to deal with the definition of the virtual resources it needs to run an application/service. For this purpose, an upper abstraction level, called vApp, is used to define those resources and their relationships. Moreover, vApp allows defining dynamic assignment of values to resource parameters related to virtual resources (e.g., CPU, memory and local storage capacity, capacity on virtual storage and bandwidth and QoS on virtual networks). Last, but not least, vApp allows defining elasticity rules which are used to govern the dynamic deployment or deactivation of virtual resources.

Basic Concepts

Following the above FMC diagram of the IaaS SM GE, in this section we introduce the main concepts related to this GE through the definition of their interfaces and components and finally an example of their use.

The IaaS SM GE is responsible for the deployment and lifecycle management of vApps. The IaaS SM GE will evolve in Release 3 to incorporate SLA management features targeted to avoid over/under provisioning of resources and to reduce over-costs, based on SLAs and business-rules protection techniques.

The key concepts, components and interfaces associated to the IaaS SM GE and visible to the cloud user, are described in the following subsections.

Entities

To use the IaaS Service Manager Interface (SMI) effectively, you should understand several key concepts, see the diagram below:

  • Virtual Server. A virtualized container that can host an arbitrary Operating System and an arbitrary software stack on top, installed within the virtual server. Virtual servers are also referred as Virtual Machines (VMs) or (virtual) image instances (see definition of virtual image below).
  • Virtual Appliance (vApp). A vApp refers to the virtual infrastructure required by an application (or part of a larger application) to run. A vApp is typically structured into tiers, each of which is made up of a set of connected virtual servers that share the same virtual image. The description of a vApp may also comprise a set of elasticity rules establishing how to perform up/down (vertical) and in/out (horizontal) scaling of virtual servers within the tiers of a given vApp in an automated manner.
  • Projects. vApps and/or servers reside in a Project context. A Project is a high-level container for vApps, virtual servers, virtual storage and virtual networks. In other words, a project is a pool of virtual resources.
  • Domains. A high-level container for projects, users and groups, as defined by keystone. A project is only in one domain. A project represents an independent unit, which manages its own virtual resources (e.g., enterprises, divisions, groups‚...).
  • Virtual Infrastructure. Any kind of IaaS resource offered to cloud consumers as part of a cloud service that is managed through SMI, e.g., vApps, virtual servers, volumes, firewalls, load balancers, etc.
  • Computing Flavor. A computing flavor is a hardware configuration that can be associated to a virtual server. Each flavor has a unique combination of CPU cores, memory capacity and disk space. An example of this combination could be 8 virtual CPUs, 16 Gb RAM, 10 Gb HDD and 160 Gb of ephemeral disk (a disk that is stored locally on the hypervisor host). Computing flavors must be registered and made available prior to their association to virtual servers.
  • Virtual image. An image is a collection of packaged files used to create or rebuild a virtual server. Basically, a virtual image is a snapshot of a virtual server from which you can create new virtual servers (i.e., image instances). Each virtual server derived from a virtual image hosts the Operating System and software stack associated to the virtual image and is assigned one among the set of available computing flavors. A number of pre-built virtual images can be made available to cloud users but they may also create their own images using tools defined for that purpose. These custom images are useful for backup purposes or for producing "gold" server images if you plan to deploy a particular server configuration frequently. DCRM GE supports life cycle of virtual images, as well as provisioning of virtual servers based on virtual images.
  • Volume. Extra block level storage to your Virtual Server. This is an iSCSI solution that employs the use of Logical Volume Manager (LVM) for Linux. Note that a volume may only be attached to one instance at a time. This is not a ‘shared storage’ solution like a SAN of NFS on which multiple servers can attach to.


Concepts class diagram
Concepts class diagram

Architecture Components

The IaaS SM GE is split into two main modules that could be deployed on the same or different machines:

  • Scalability & Optimization Manager (SOM) is responsible for the management of monitoring events and scalability rules as well as the distribution of queries and actions to the different Service Lifecycle Managers (SLM), see below. It is composed of the following components:
    • Query Manager, which is the Service Endpoint (SE) of the IaaS SM GE and implements an SMI server. The SE is the main entry into the IaaS provider. All received data is analyzed in order to get information about cloud components (i.e. pointers to machines, volumes, networks, vApps, projects, etc.) and the operations over them. Query Manager has to split the incoming messages into actions, queries and elasticity rules, depending of those operation requests. Action means an asynchronous operation associated to a vApp. By contrast, a query is a synchronous operation associated to a vApp. Finally, elasticity rules allow describing the actions to be applied when we want to scale up/down a server.
    • Rules Engine, which provides the management of the elasticity rules based on monitoring data. These rules are associated to a vApp description and passed from the Query Manager through shared memory (i.e. Message Queue component in the IaaS SM architecture specification diagram). The Rules Engine triggers actions when a specific elasticity rule fires based on the data provided by the Monitoring GE.
    • Action Switch, which takes as input both the asynchronous action requests coming from the SMI and the action requests generated by some activated elasticity rules. These action requests lead to the execution of specific operations over an individual virtual server such as increasing or decreasing the memory, the virtual CPU, the disk capacity (scale up/down), or the number of servers associated to a vApp (scale in/out). Besides, it must know which host it has to send the action requests to.
    • Distributed Query System, which receives the definition of a vApp through the Query Manager and sends the information to the appropriate Query System (see below). It uses shared memory in order to store the information related to the vApp (i.e. Query Queue component in the IaaS SM architecture specification diagram) in order to use it afterwards. Since the Query System could be in a different host, the Distributed Query System must know to which host it has to send the information related to a vApp.
  • Service Lifecycle Manager (SLM) is responsible for performing queries and actions over the vApps through the provisioning component, which connects directly to the Data Center Resource Manager GE.
    • Query System receives the queries associated to a specific resource and passes them to the Provisioning component.
    • Action System receives the actions from the Action Switch and sends it to a shared memory (Action Queue) where they are processed by the provisioning component in an asynchronous way.
    • Provisioning, this component deals with the interface related to the DCRM. Its purpose is to translate the queries and actions to the appropriate interface in order to be sent to DCRM. In case of actions, Provisioning is responsible for deleting the actions after their execution from the Action Queue.

Interfaces

The IaaS SM GE is currently composed of three main interfaces:

  • The Service Manager Interface (SMI) is the exposed REST interface that implements all features of the IaaS SM GE. The SMI allows service providers to control the vApps provisioning lifecycle using a vApp manifest, which is based on the Open Virtualization Format (OVF). This file declares the vApp components, requirements, monitoring, SLA targets and elasticity rules (based on the W3C RIF standard). The SMI implements a standard API compliant with the OpenStack Compute API working at the whole application-level abstraction. The SMI supports two different kind of features:
    • vApp deployment features, which involve the different operations to deploy and un-deploy vApps as well as also retrieve information about them.
    • vApp provisioning features, which involve the operations related to the deployment of applications. It means that an application can be deployed on a single server or on a set of servers. In case that a deployment is made on a set of servers, it is necessary to know the way in which these servers are connected through a network, which are their interrelations, etc.
  • The Resource Manager Interface (RMI) abstracts the IaaS SM GE from the heterogeneity existing in cloud infrastructure providers. It is a REST client interface (OCCI compliant or OpenStack Compute API compliant) and includes primitives and data types dealing with servers, flavors and images.
  • The Monitoring Manager Interface (MMI) provides a REST client interface and provides connectivity to the Monitoring GE in order to retrieve information about the status of the deployed vApps. This information is used by the Rules Engine (see section Components to get a description of it) in order to activate or deactivate the elasticity rules associated with a specific vApp.

Example Scenario

This section provides three general scenarios illustrating how the IaaS SM GE can be used. They exemplify how the IaaS SM GE architecture works.

Deployment Scenario

This example tries to explain the simpler scenario in which a user wants to provision a new virtual server or a vApp using the IaaS SM GE. Before beginning the provisioning process, some information is needed to configure the virtual server like the virtual image to use and the computing flavor. Available virtual images and computing flavors could be obtained through the 'getImageList' and listFlavors operation. Firstly, the user needs to get the list of Images available in the DCRM through the getImageList operation, which returns the URL of the images. The user needs to select the image to use and take the corresponding URL to be passed during virtual server provisioning. In the same way, the user needs to retrieve the list of computing flavors supported by the DCRM using the listFlavors operation, in order to select one of them.

In the next steps, still prior to deployment, the application/service provider must define the characteristics of the virtual server or the vApp to be deployed. This information will be provided by means of invoking the createServer or the createService operations. A description based on Image Id and Flavor Id is provided whenever a single virtual server is going to be deployed, On the other hand, a description of each of the tiers (number of virtual servers, virtual images and flavors associated to virtual servers, characteristics of networks connecting virtual servers, etc.) as well as characteristics of the connection between tiers, will be provided whenever a vApp is going to be deployed. This last option implies the use of a DMTF's Open Virtualization Format (OVF) descriptor. OVF is a packaging standard designed to address the portability and deployment of virtual appliances. OVF enables simplified and error-free deployment of virtual appliances across multiple virtualization platforms. At this point, the service provider has to generate the OVF section with all the information related to the servers involved in the vApp and pass this information to the DCRM interfaces. Please refer to the OpenStack extension API for further details.

In case the user (i.e. service provider) has the definition of servers in OVF, IaaS SM GE revises the OVF descriptor looking up useful information for service lifecycle management. This information includes for example the start-up order of all the servers of the vApp, scalability rules, resource requirements, etc. IaaS SM GE also translates the OVF Descriptor into the necessary Virtual Images and Computing Flavors, which are stored in the IaaS DCRM.

The IaaS SM management interface allows stopping a specific virtual server through the stopServer operation. The user has the possibility to restart it again invoking the startServer operation. By default, when we create a server or a vApp, the server/servers will be started automatically.

Scalability Scenario

As previously described, IaaS SM GE will provide service elasticity. Thus, service providers define elasticity rules in the vApp manifest (OVF descriptor) to assure the right operation of their services and/or the final quality of experience. Moreover, the service provider can define elasticity rules, which allows adding a new instance of a concrete server to avoid system overload.

In addition, it is possible to define, after the provision of the vApp through the OVF service definition, elasticity rules specified in W3C format using the createRule operation. These rules can be changed over time, as a result of adding more controls over the data or managing new information not previously taken into account, using the updateRule operation. Both operations are under development and they will be supported in release 3.

The Monitoring GE measures key performance indicators (KPIs) associated to the vApp and provides them to the IaaS SM GE through the MMI. The Rules Engine of the IaaS SM GE evaluates, in real time, the elasticity rules associated to the vApp with the information provided by the Monitoring GE in the rule engine. When a given KPI exceeds the defined threshold, the IaaS SM GE starts the deployment process of a new virtual server using the createServer operation or converts the server to a different flavor (scaling the server up and down) through the resizeServer operation.

If the KPI that has triggered the scaling gets fixed, the Rule Engine can decide to scale out a server through the deleteServer operation. Alternatively, it can scale down a server to less-restricted hardware requirements, represented by a new flavor, by means of invoking the resizeServer operation.

Concrete Scenario

Based on the previous information, the goal of this section is to translate it into a more concrete scenario. The purpose of the scenario is twofold: firstly show the deployment and configuration of a vApp based on a set of servers and networks organized in tiers. And secondly show the scaling up or down of the vApp based on monitoring of KPIs

Imagine that we want to develop a service consisting of an auction site (e.g., eBay.com). It contains all the elements of a typical enterprise application and potentially allows us to benchmark the performance of the platform. This service needs to implement functionalities like selling, browsing and bidding. Like any auction portal, the demand for any application fluctuates; consequently the IaaS SM must identify bottlenecks (idleness) at the various tiers (database, portal, business logic) and deploy/remove resources, ideally automatically through the rules defined in the vApp. It means that the vApp, which is sent to the IaaS SM, has all the infrastructure description needed to install and execute the service.

The steps that we must take in order to deploy the service can be summarized as follows:

  1. The service provider describes the auction service, which involves the definition of the virtual infrastructure required to run the service. Such virtual infrastructure will be represented by a vApp, defined using the OVF format, which will comprise three different tiers: a tier linked to a farm of front-end web servers handling interaction with end users, a tier comprising a set of application servers on top of which the business logic will run, and finally a tier where the database will be deployed.
  2. The service provider generates all the virtual images associated to virtual servers in each tier and stores them into the Object Storage GE. This operation is made through the OpenStack Compute API CreateImage operation.
  3. Using the SMI API, the service provider requests the deployment of the vApp. This request includes the OVF descriptor as a parameter.
  4. The IaaS SM GE parses the OVF descriptor and processes the information for the vApp lifecycle management (e.g., scalability rules, startup order, needed KPIs, etc.).
  5. Using the DCRM interface, the IaaS SM starts the final phase of the deployment (that is, network generation and server startups).

Once the vApp is up and running, the scaling process can be started. IaaS SM manages the horizontal scaling by deploying and starting additional virtual servers in the proper tier and configuring the load balancer necessary to deal with the different virtual servers. This mechanism allows increasing the number of front-end/backend nodes if the measured KPIs violate some rules defined by the user. In this case the steps would be the following:

  1. The monitoring system collects the KPIs information samples of each server involved in the vApp.
  2. IaaS SM evaluates the elasticity rules to apply scalability if needed.
  3. Using the DCRM API, IaaS SM requests the deployment of a new virtual server (e.g., a front-end web server in the corresponding tier) of the vApp.
  4. DCRM manages the deployment of the new server of the vApps, taking the info from the Object Storage GE.
  5. IaaS SM configures the new instance of the web service application in order to use it and configures a load balancer in order to redirect traffic from one node to another.

Main Interactions

In this section, the most important SMI operations are described, please refer to the open specifications for a complete list and further details. These operations are classified in the following areas:

  • Browsing operations. These operations are used to discover virtual resources and obtain their specific information.
  • Provisioning operations. These operations are used to provision new resources.
  • Management operations. These operations are used to manage the resources previously deployed.
  • Elasticity & Monitoring operations. These operations are used to manage the elasticity rules and obtain the monitoring information to work with them.
  • Miscellanea operations. Operations not included in the previous areas.


Browsing operations

The browsing operations include all those operations used for discovering and browsing virtual resources. The output of the operations will be returned in XML or JSON format. These operations include the following:

  • Using the project IDs (aka tenant id in previous version of OpenStack), it is possible to obtain the representation of a project through the getProject operation, which returns a name attribute, a project ID and a description of the project. The information must include the domain ID, which references the parent domain for this project and the list of references to vApps instantiated for this project identified by their vApp IDs. Additionally, getProject returns the capacity restrictions for this project (storage and computing) and the list of networks available for this project identified by their network ID.
  • Using the vApp IDs of a previously provisioned vApp, we can use the getvAppDetails operation, which returns the description of the vApp in OVF format. Children vApps and Servers can be also browsed. This vApp element will include the list of servers identified through their server ID.


IaaS SM  Architecture Overview
Browsing operations 1


  • There is the possibility to use the listServers operation with parameter vApp ID to get the list of servers associated to a vApp, including image ID, flavor ID, networks ID and their associated IP.
  • Using the previously obtained server ID, we can use getServerDetails, which obtains the description for a previously provisioned server, returning a server element, including server ID, image ID, flavor ID, networks ID and its IP addresses (IPv4 and/or IPv6).
  • listImages queries the public image catalogue provided by the DCRM, returning a description of the stored images in the image repository and identified by image ID.
  • getImageDetails, with parameter image ID, will return the specific information for the image identified by this parameter.
  • listFlavors returns all the available flavors identified by their flavor ID.
  • getFlavorDetails, with parameter flavor ID, will return the specific information for the image identified by this parameter. The output will be in XML or JSON format.


IaaS SM  Architecture Overview
Browsing operations 2

Provisioning operations

This group includes capabilities for instantiating and configuring Virtual Infrastructure (servers, vApps, projects and domains). The Provisioning API includes the following operations used for resource provisioning.

  • vApp provisioning through createvApp, which instantiates a new vApp in the target project, based on an OVF description and several deployment parameters. The deployment parameters define several aspects regarding the deployment of the vApp like number of tiers associated, network connectivity, and so on. These parameters describe how the vApp is going to be provisioned. Need to know the project ID.
  • vApp unprovisioning through deletevApp, which removes an existing vApp, including all its children, releasing its consumed resources. It requires the vApp ID as parameter.
  • Server provisioning through createServer specifying the flavor id, image id and name. The server creation will be always associated to a vApp, so we need to pass the vApp ID as additional parameter. It returns the description of the server including the server ID, user ID, admin password, progress attribute (0-100% completion) and status (BUILD, ACTIVE, ERROR).
  • Server unprovisioning, through deleteServer with parameter Server ID, deletes a cloud server from the system.
  • Once provisioned, a vApp can be updated invoking the updatevApp operation with the new OVF description as parameter.
  • Once provisioned, a server configuration may be altered in terms of its flavor through resizeServer with parameter server ID and flavor ID. This operation, in essence, scales the server up or down. The original server is saved for a period of time to allow rollback if there is a problem. The server status will pass from ACTIVE to RESIZE and finally to VERIFY_RESIZE, waiting to confirm that all is ok in order to pass the status to ACTIVE again.
  • To confirm the resize, we have the confirmResize with parameter server ID, which deletes the original server.
  • If we detect a problem during the resize we can call revertResize with parameter server ID to roll back to the original server.
  • Server cloning. Once provisioned, a server may be cloned, creating a new one with the same image, flavor and network connectivity, through the createImage operation. It requires the server ID in order to create the image.


Regarding the Domain, it requires a special care because of legal issues. The creation of a domain resource may mean the establishment of a contractual relationship between cloud provider and cloud consumer. This relationship cannot be made implicitly by just an invocation of a programmatic interface due to the legal issues of accepting service level agreements (SLA) and End-user license agreement (EULA). On the other hand, there are some scenarios where the presence of the SLA and EULA are not required, as when the cloud consumer and cloud provider are in a trusted environment and no contractual relation is needed. This interpretation of the domain requires establishing a close relationship between this concept and the accounting and billing mechanisms to be implemented in FI-WARE, which are not covered by the IaaS SM GE.

Management operations

Management API includes operations for managing cloud resources. These operations may be categorized as follows.

  • vApp activation and deactivation through the activatevApp operation with parameter vApp ID and a boolean parameter (true or false). This boolean is used to specify if it is an activation operation (boolean equal to true) or a deactivation operation (boolean equal to false). vApp deactivation consists of releasing the vApp resources and storing it for a later use. The server or servers included in a vApp will be stopped and the memory and computing resources will be freed. The vApp activation will produce an activation of all the servers associated to this vApp. Finally, the vApp may be activated again invoking the activation operation with the boolean parameter set to true.
  • Stop a server through stopServer operation with parameter server ID, will stop the server.
  • Start a server through startServer with parameter server ID. By default all deployed servers will be ACTIVE at the beginning.
  • Reboot a server through rebootServer with parameter server ID and the type of reboot (soft or hard). With a soft reboot the operating system is signaled to restart. A hard reboot is equivalent to a switch off and on the server.
  • We can change the name and IPs associated to a server through the updateServer operation with parameters server ID and details of name and IPs.
  • The image stored can be deleted from the image repository through deleteImage operation, which only needs the image ID.
  • Once provisioned, a server may be cloned, creating a new server with the same image, flavor and network connectivity. This operation is invoked through the cloneServer operation with server ID parameter.

Elasticity & Monitoring operations

The elasticity rules defined for a server are associated to the description of the vApp. In addition we can create new rules in RIF format for already running vApps (i.e. already running servers inside vApp). The interfaces that we can use for this are the following.

  • We can assign a new rule to a server if it has not been specified in the OVF or we want to add a new one through the createRule operation specifying the elasticity rule and the vApp ID as parameters. It produces a new rule associated to a server identified by rule ID. The fact that we assign an elasticity rule associated to a vApp (rather than to a server) affects the entire system. That is, we cannot associate a rule to a specific server without affecting other components (i.e. other servers) in the system. Obviously, the elasticity rule has associated the identifier of the server to which it is to be associated.
  • We can update a specific rule through updateRule operation with parameters new elasticity rule, vApp ID and rule ID of the rule to be updated.
  • Invoking deteleRule operation with parameter vApp ID and rule ID allows deleting a specific rule.
  • Invoking the getRule operation with parameter vApp ID and rule ID, we can obtain the description of the elasticity rule in RIF format.


Elasticity rules operations
Elasticity rules operations

Security operations

In this section the operations not included in previous categories are described. It includes the following security operations.

  • API consumer verification. This includes the ability for IaaS SM to validate the user against the IdM. This will be done through validateToken operation with parameter token to be validated. This operation is not exposed by the SM GE and it is only used in order to validate each operation received.
  • Get credentials from IdM to assign to a server. This operation requests the admin credentials to the IdM in order to incorporate in the server administrator user and password. The operation will be getCredentials with no parameter and will return a credential to be used in the server user/password configuration. This operation is not exposed by the SM GE and it is only used in order to validate each operation received.
  • At any moment in time the administrator password of a server can be changed through the changePassword operation with password parameter.

Basic Design Principles

Design Principles

Implementations of the IaaS SM GE have to meet the following technical requirements:

  • The cloud works in a distributed environment. The design does not depend on any global, critical or centralized service and the solution provided has to be highly available and scalable.
  • IaaS SM GE allows running a single instance of a service on a server, being accessed by multiple users.
  • The Cloud Users can either deploy a single instance of a service defined through its vApp or use a single instance of a vApp previously deployed.
  • A single instance of a service defined by its vApp could be composed by either a simple server or a group of servers. The system should also be able to deploy full vApps from OVF file format.
  • IaaS SM GE should manage limits of project resources (i.e. quotas). Each project will have defined some amount of resources which will be assigned to the services deployed on it.
  • IaaS SM GE supports standard REST interfaces, with all the information and capabilities of the system being exposed via this interface.
  • Cloud Users can deploy vApps onto a physical server without knowing the infrastructure providers or the cloud providers in which the servers will be finally deployed. IaaS SM GE should be able to work transparently with multiple hypervisor technologies and provide an abstraction layer to the cloud user.
  • IaaS SM GE and its interface are capable of being implemented and used in different operating systems environments.
  • IaaS SM GE has to support federation capabilities through the separation of SOM from SLM, which means that it has to be able to deploy servers and move them between different cloud data centers. A data center is a centralized repository, either physical or virtual, for the storage, management, and dissemination of data and information organized around a particular body of knowledge or pertaining to a particular business. Each data center will be managed by a different IaaS SM GE instance.
  • IaaS SM GE should aggregate data from different data centers when asked about global information and should distribute actions to the right data centers.
  • IaaS SM GE should offer an interface for the clients to create service management rules, dealing with infrastructure management capabilities, in a standard way.
  • IaaS SM GE should be able to create and manage server templates, as well as full OVA files.
  • The system should manage monitoring information from Monitoring GE.
  • The system has to support both synchronous and asynchronous notifications.
  • The system has to implement mechanisms to secure the communications and operations through authentication and authorization processes.

Resolution of Technical Issues

When applied to IaaS SM GE, the general design principles outlined at Cloud Hosting Architecture can be translated into the following key design goals:

  • Fully-automated provisioning, elasticity and life cycle of vApps, requested, managed and released via a standards-based REST API (OpenStack Compute API compliant).
  • Provide the necessary levels of isolation, availability and performance of provisioned vApps.
  • Ability to dynamically control the amount of allocated resources in the DCRM, to scale them up and down, as well as monitor the deployed vApps.
  • High availability, virtualized, cross-platform and scalability of IaaS SM.
  • Non-disruptive, automated administrative tasks (e.g., service maintenance).
  • Avoid non-authorized access to vApps.


Regarding the general design principles not covered at Cloud Hosting Architecture, they can be translated into the following key design goals:

  • Support multitenancy architecture, in which a single instance of a software application serves multiple customers.
  • Provide the necessary functionality to work with vApps, which could be composed of one or several servers.

Detailed Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Open API Specifications

Re-utilised Technologies/Specifications

The IaaS Service Manager GE is based on RESTful Design Principles. The technologies and specifications used in this GE are:

Terms and definitions

This section comprises a summary of terms and definitions introduced in the previous sections. It intends to establish a vocabulary that will be helpful to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FI-WARE Global Terms and Definitions

  • Infrastructure as a Service (IaaS) -- a model of delivering general-purpose virtual machines (VMs) and associated resources (CPU, memory, disk space, network connectivity) on-demand, typically via a self-service interface and following a pay-per-use pricing model. The virtual machines can be directly accessed and used by the IaaS consumer (e.g., an application developer, an IT provider or a service provider), to easily deploy and manage arbitrary software stacks.
  • Platform as a Service (PaaS) -- an application delivery model in which the clients, typically application developers, follow a specific programming model to develop their applications and or application components and then deploy them in hosted runtime environments. This model enables fast development and deployment of new applications and components.
  • Project is a container of virtual infrastructure that has a set of virtual resources (e.g., computing capacities, storage capacities) to support the former. In other words, a VDC is a pool of virtual resources that supports the virtual infrastructure it contains.
  • Service Elasticity is the capability of the hosting infrastructure to scale a service up and down on demand. There are two types of elasticity -- vertical (typically of a single VM), implying the ability to add or remove resources to a running VM instance, and horizontal (typically of a clustered multi-VM service), implying the ability to add or remove instances to/from an application cluster, on-demand. Elasticity can be triggered manually by the user, or via an Auto-Scaling framework, providing the capability to define and enforce automated elasticity policies based on application-specific KPIs.
  • Service Level Agreement (SLA) is a legally binding contract between a service provider and a service consumer specifying terms and conditions of service provisioning and consumption. Specific SLA clauses, called Service Level Objectives (SLOs), define non-functional aspects of service provisioning such as performance, resiliency, high availability, security, maintenance, etc. SLA also specifies the agreed upon means for verifying SLA compliance, customer compensation plan that should be put in effect in case of SLA incompliance, and temporal framework that defines validity of the contract.
Personal tools
Create a book