Design of a Platform of Virtual Service Containers for Service Oriented Cloud Computing

1
Design of a Platform of Virtual Service
Containers for Service Oriented Cloud Computing

• Carlos de Alfonso
• Andrés García
• Vicente Hernández

2
Index

• Introduction
• Our approach
• Platform design
• Storage
• Security
• Management and QoS
• Catalogue
• User Interface
• Virtual Container
• User profiles
• Working lines and open problems

3
Introduction

• In the latter years there have been a growing
  interest in Cloud Computing technologies and its
  possible applications.
• There have appeared many commercial products
• Mainly storage and Infrastructure as a Service.
• Storage examples Amazon S3, Nirvanix, Savvis
• IaaS examples Amazon EC2, GoGrid, 3Tera
• Other examples Google App Engine, Salesforce,
  Engine Yard
• Some small sets of open Cloud Computing tools
  have been also developed.
• Eucalyptus, Nimbus, OpenNebula, Enomaly,
  Abicloud, etc.
• Almost any of them are oriented to the IaaS
  level, since there is a lack of research projects
  towards other cloud approaches.

4
INTRODUCTION

• Currently most of cloud computing solutions are
  focusing in the lowest levels of the
  infrastructure.
• Virtual machine deployment and management
  infrastructure.
• Storage management infrastructure.
• The current approach of vendors, to deploy
  Services in the cloud, is based in those levels
  instead of Services virtualization.
• Providers approach is to package a preconfigured
  service in a virtual machine image, and deploy a
  whole virtual appliance to run the service.
• There are some drawbacks like the waste of
  resources, a less direct service management, the
  low abstraction level, etc.

5
Our approach

• To offer a platform which enable developers to
  deploy and to manage virtual services as IaaS
  platforms deploy and manage virtual machines.
• That means to deploy only the service instance
  that is needed, instead of deploying the whole
  virtual appliance.
• Allow consumers to search and use services in a
  Software as a Service basis.
• Usage on demand, access via internet,
  scalability, monitoring, etc.
• Provide the platform administrators with a
  transparent security model, and a framework to
  define QoS constraints and SLA with developers
  and consumers.
• Including mechanisms such as authentication and
  authorization, user preferences, usage limits,
  etc.

6
Platform design

• The platform is composed by a set of
  interconnected functional modules and two
  abstraction layers.
• An abstraction layer is conceived as an Interface
  used by the components, independently of the
  underlying implementation.
• A module is defined as an individual software
  component that can be instanced, added or removed
  to the platform.
• A platform instance is formed by at least one
  instance of each module.
• Each module implements a specific functionality.
• Modules interact with each other via messages.

7
Platform design

• The following diagram outlines the general
  architecture of the platform components.
• Vertical boxes represent layers, not directly a
  implementing component.
• Horizontal boxes represents system components.

8
Layers Storage

• A virtual storage layer provides a set of
  features.
• Ubiquitous access to data.
• Any service should be able to read any data
  independently of where the service is running or
  where the data is stored (under the scope of the
  platform).
• Virtualized file system.
• Final users do not care about where to store
  data.
• Users are provided with a virtual uniform file
  system, even if files are stored in physically
  distributed places
• Isolation.
• Users are only able to read and write what they
  are authorized to.
• Data management, replication and QoS.
• Need to move the data where the problem is or
  to deploy the problem where the data is.
• Need to replicate or move data to improve
  resilience and QoS.
• Need to be done transparently via SLA and
  developer directives.
• Different implementations are to be made, to
  couple this virtual layer to the physical system
  where the data will be stored.
• Usage of GridFTP.
• Connection to the Amazon S3 system.
• Just the local hard drive.

9
Layers Security

• The platform makes use of a default security
  system.
• Any users, either administrators, developers or
  consumers are identified by a credential.
• The credential provides authentication and it is
  used for authorization.
• Each user identity is bound to a set of
  preferences, SLA and storage.
• Credentials enable developers to deploy services,
  manage them and negotiate QoS agreements with the
  platform.
• Credentials enable consumers to search and use
  deployed services in a private virtual space,
  having access only to their own personal service
  instance.
• Credential delegation allows service composition
  and cloud interoperability.

10
Components Management and QoS

• The Management and Quality of Service component
  provides the functionality to deploy and to
  manage services while maintaining a reasonable
  quality of service of the platform.
• The management module provide a set of
  functionalities.
• Service deployment, to deploy copies of the
  service bundle in a set of Virtual containers.
• Service undeployment from the Virtual containers,
  keeping alive the running service instances until
  they finish.
• Upgrade services to new versions, so that the new
  service requests will get an instance of the new
  service, and not the old one. The downtime is
  minimized by using an upgrade protocol.
• Live migration, for undeploying a service from a
  virtual containers and deploying it into another
  one, minimizing the downtime and keeping running
  instances alive.
• Using the live migration ability, it provides
  load balancing and auto scale based in a certain
  criteria.
• Developers can attach a SLA to each service,
  based on its own base SLA, to specify parameters
  such as minimum number of replicas, geographical
  constraints in the deployment place, etc.

11
Components Management and QoS

• The QoS module provides resilience and avoids the
  degradation of the service quality.
• The QoS module monitors the state of the platform
  and performs actions to improve the general
  performance.
• Live service migration and service replication
  allows load balancing.
• Replication of platform components provides
  resilience.
• The Interoperability module complements the QoS
  module.
• When the platform cannot meet the requirements of
  its SLA due to overload, components failures,
  etc., it can negotiate with other clouds the rent
  of resources.
• Platforms will negotiate based on their own
  platform credentials, SLA, the resources required
  and a internal policy set by the system
  administrators.

12
Components Catalogue

• The Catalogue stores information about the state
  of the platform as a whole.
• Each module provides the Catalogue with specific
  information about different aspects of the
  platform, sending status reports periodically.
• Services Provide information about services,
  their name, developer, description and a
  reference to the resource itself. Service
  consumers use this catalogue via the User
  Interface in order to get access to the services.
• Metrics Provides a snapshot of the platform
  state e.g. number of components, number of
  services, active service images, service CPU
  consumption, etc.
• Statistics Provides long term information about
  the platform and its services e.g. usage info for
  services.

13
Components Catalogue

• The Catalogue component work as a peer-to-peer
  distributed hierarchical system.
• Inspired by existing P2P discovery models for
  Grid systems.
• Catalogues are organized in groups, associated to
  a platform, and each catalogue has only a partial
  state of the group.
• A query must be distributed to every member on
  the group in a P2P basis.
• Catalogue groups are organized hierarchically,
  and queries in a group must be distributed to
  their child groups.
• Queries to one member of a group are broadcasted
  to the whole group.
• Each module reports its status to a set of n
  catalogues, using a hash algorithm.
• This organization provides resilience
  capabilities and improves the QoS.
• There are no single points of failure, implements
  a load balancing between nodes.
• Hierarchical organization of the catalogues may
  enable a logical association of clouds.
• Several private clouds can be federated in a top
  level cloud.
• Defining such top level catalogue group would
  allow users to access services in a
  semi-centralized way.

14
Components User Interface

• The UI is the entry point to the whole platform,
  which provides consumers and developers with
  different functionalities, according to the
  profile and needs.
• It acts as a platform front-end, connecting
  external users and applications to the other
  components.
• This component does not implement any
  functionality per-se, but calls other components
  to perform different tasks.
• Query the catalogue for information.
• Deploy, undeploy and manage services.
• Define user parameters or preferences.
• Etc.

15
Components Virtual Container

• Virtual containers are the key component of the
  Virtual Service Platform.
• This component run and give access to the
  virtualized services.
• A Virtual Container is a regular service
  container with additional functionality such as
  functions to deploy, undeploy and migrate
  services, as well as statistics and metrics
  tracking and a security framework to fit the
  platform.
• The virtual containers make use of most of the
  components outlined in previous slides.
• Virtual Containers define what kind of virtual
  services support our platform.

16
User profiles

• Developers can deploy services in the platform
  written in any supported language, provided that
  it is instrumented with the platform API
  primitives.
• Service deployment and management is made via
  User Interface.
• A different SLA can be specified to each service
  based in the developer personal SLA.
• It is possible the usage of hosted services by
  other services, due to the credential delegation.
• Consumers can use services deployed in the system
  by providing their credentials to be
  authenticated.
• Query the catalogue to get info about hosted
  services.
• Ask the manager for a service.
• Once an service reference is retrieved, it can be
  used directly.

17
Working lines and open problems

• Some problems about the platform design are
  solved, while other are yet to be studied.
• The SLA definition language.
• Define the load balancing terms.
• Mechanisms and languages for cloud
  interoperability and resource negotiation.
• Adaptation of regular service containers to a
  Virtual Service Platform.
• Definition of the adequate security framework.
• Design of the proper storage organization.