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. • Provider’s 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 transparentlyvia 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 QoSagreements 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 QoSmodule 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 consumersuse 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.