Georgiana Macariu, Dana Petcu, CiprianCraciun, Silviu Panica, Marian Neagul eaustria Research Institute Timisoara, Romania

Transcription

1 Open source API and platform for heterogeneous Cloud computing environments Georgiana Macariu, Dana Petcu, CiprianCraciun, Silviu Panica, Marian Neagul eaustria Research Institute Timisoara, Romania

2 Problem definition

3 Portability in Clouds? API spec Q1: How to port the application? API spec API spec

4 Interoperability in Clouds? API spec Q2: How to interoperate? API spec API spec

5 Scenarios for multiple Clouds Federation of Clouds: Horizontal or InterClouds Main issues: Portability & Interoperability On-the-fly Multiple Clouds: Cross-Cloud or Sky computing

6 Use cases for multiple Clouds Cloud Computing standard, 2011 (NIST) classification Serially (one Cloud after another) 1. Migration between Clouds 2. Interface across multiple Clouds 3. Work with a selected Cloud 4. Change Cloud vendors Simultaneously (several Clouds at a time) Cloud Operate across Clouds Work with a selected Cloud Interface between Clouds Migrate between Clouds Cloud

7 Interoperability definition Dictionary: Property referring to the ability of diverse systems to work together By mottos: avoid vendor lock-in develop your application once, deploy anywhere one API to rule them all

8 Portability between Clouds Ability to use components or systems lying on multiple hardware or software environments Dimensions: DATA: Import & export functionality SERVICE: On the fly add, reconfig and remove resources FUNCTION: Define appl. functionality in platform-agnostic manner

9 Portability at XaaSlevel SaaS PaaS IaaS Preserve/enhance functionality when substitute SW Measures: - open source; proprietary/open formats; - integration techs; appl server/os Minim. appl. rewriting while preserve/enhance control Measures: - proprietary vs. open APIs, prog. languages, data formats - tight vs. loose coupled services - abstract layers for queuing & messaging Appls and data migrate and run at a new provider Measures: - ability to port VMs and data - underlying configurations across providers

10 mosaic Open-source API and Platform for multiple Clouds

11 Motto: Fly through the Clouds API spec API spec API spec : Find A Cloud 2: Build the application 3: Move the application to another cloud

12 Keywords Vendor agnostic API Open source PaaS Cloud broker Multi-agent technologies SLA negotiations Semantic processing Multiple Clouds Long time running applications Component-based applications Event driven, asynchronous

13 API requirements Application portability Elasticity at the level of application components Freedom to choose the programming paradigm Build own stack of software needed for the application 13

14 Based on the Cloud offers: Hosted systems Vision Deployable Cloud-aware products Novelty: Build applications on top of deployable Cloud-aware products Support components communications Elasticity to a new level (application dependent) Architectural selection: Event driven Asynchronous communications 14

15 Types of applications API support: Long-running scalable applications ( new ) Run for undefined period of time Scale upward and downward as the usage demands it Composed by multiple and communicating components Examples: web-crawlers, forecasting systems (financial, meteorology), economical applications (ERP) etc Supplementary platform support: Massive batch processing ( legacy ) Run for defined period of time Data or computational intensive applications 15

16 Cloud Building Block (CBB): Basic concepts basic component of an application can be CR or CC Cloud Resource (CR): CBB controlled by Cloud provider Cloud Component (CC): configurable CBB controlled by application developer CC instances consume CR communication between CC via CR like message queues (control redirection in case faults, scale-up) example: a virtual appliance (e.g. web server + appl server + customized e-commerce appl) 16

17 Cloud components (CC) properties Elastic scale up and down no. of instances of the same CC Manageable Possible to configure it and change the parameters Isolated CC instances independent from other CC Fault tolerant Automated using the Container (instance manager) Implemented by a Container + several Cloudlets instances 17

18 Cloudlet: Cloudlet and Connector Behavior: event-driven, stateless Elasticity: - no. of Cloudlet instances controlled by Container - no. of Containers Functionality does not depend on no. instances Its backend interface: defines the set of events to which the Cloudlet should react Connector: Behavior: RPC Abstract the access to Cloud resources 18

19 Interoperability API and Drivers Interoperability API Ensure language independence Protocol syntax and semantic enforcements RPC solution Stubs to Driver API and Proxies to Connector Driver API Wraps the native API All resources of the same type are exposed with the same interface Eg. a Membase vs. a Riak key-value store: a matter of configuration. 19

20 API layers Component Component Component Component Application parts Cloudlet API Cloudlet API CC reacting to events Connector API Connector API Operations with CR Interoperability API Proxies generator Driver Driver API for same type of CR API API API API 20

21 Implementation status Proof-of-the-concept version - implemented in Java Available - on BitBucketopen-source repository: Developed on verticality of all layers - core functionalities - to ensure the possibility to develop first applications and test Not developed on horizontal on all layers - small lists of deployable system to be used - e.g. databases: key-value-store solution 21

22 Platform: User Requirements Find the proper Cloud(s) satisfying the appl needs Talk the same language Negotiate the services Service discovery Automate the deployment process Deploy own software stack Private Clouds Public Clouds Use IaaS offers Dynamic adaptation Auto-scaling Renegotiations Monitor the Cloud service usage by the applications 22

23 Support for the Applsusing the API Based on the application descriptor Description of the components to a high abstract level Modules: Cloud components source locations Cloud resources (e.g. storage, queues) Interdependences between the aboves Currently implementation: allows the deployment of a applsbuild from components on Amazon compatible infrastructures offer the possibility to build a Private Cloud on own infrastructure 23

24 Details: Selected papers/mosaic in 2011: API layers: Towards a cross-platform Cloud API, CLOSER 2011, SciTePress. API interoperability: Building an Interoperability API for Sky Computing, InterCloud/HPCS, IEEE CS Platform services: Arhitecturing a Sky Computing Platform, ServiceWave Workshops 2010, LNCS 6569 Test appls: Building a Mosaic of Clouds, EuroPar Workshops 2010, LNCS 6586 Current implementation: Documentation and link to source: Official webpage:

25 Thank you!?