Cloud portability e interoperability: il progetto europeo mOSAIC

1,699 views

Published on

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,699
On SlideShare
0
From Embeds
0
Number of Embeds
25
Actions
Shares
0
Downloads
1
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Cloud portability e interoperability: il progetto europeo mOSAIC

  1. 1. mOSAIC: Open-Source API andPlatform for Multiple CloudsCloudCamp – TechnologyBiz – 9 Novembre 2011 Beniamino Di Martino Project Coordinator – Second University of Naples
  2. 2. mOSAIC main facts• Project acronym: mOSAIC• Project full title: Open-Source API and Platform for Multiple Clouds• Grant agreement no: 256910• Funding Scheme: STREP• Call: FP7-ICT-2009-5 Obj: ICT-2009.1.2• Cost: 3,705 Meur (EC financing: 2,85 M)• Duration: 30 months• Start: Sept 1st 2010. End: Feb 28th 2013• Web site: http://www.mosaic-cloud.eu
  3. 3. mOSAIC PartnersSecond University of Naples – It (Prj Coordinator)Institute IeAT – RoEuropean Space Agency - FrAITIA - HuTecnalia - SpTerradue - ItXLAB - SloUniversity of Lubljiana - SloBrno University of Technology - Ck
  4. 4. The Cloud Computing ChallengesIn literature main challenges are identified:• data and application interoperability• data and application portability• governance and management,• metering and monitoring,• security.mOSAIC will fully address the first two of these challenges, and partially address the next two ones.
  5. 5. Portability and InteroperabilityAvoiding “Cloud Vendors Lock-in” and “Walled Gardens”Allow Interoperability among Clouds and Cloud Providers at API spec Service and Application level API spec 010 110 01 API spec
  6. 6. How we develop a Cloud-based application?High level Google App Engine Microsoft Azure Service Platform [or wait for Orleans] Manjrasoft Aneka Amazon Web ServicesLow level APIs offered by IaaS Cloud service providers to create and manage cloud resources, including compute, storage, and networking components e.g. Amazon EC2, Eucalyptus, Oracle (Sun) Cloud, ElasticHosts, FlexiScale, GoGrid, Enomaly, OpenNebula, SliceHost, Nimbus, AppNexus, F5, Tashi, CohesiveFT, Mosso, Joyent …… So many! So different! This are the right APIs for the Cloud appls?
  7. 7. Towards the usage of multiple CloudsPortability At high level? NO! At low level? Ongoing task! OCCI – January 2010 UniCluster, OpenStack, Jcloud, DeltaCloud … from Spring 2010Approaches: At IaaS level: Migration of VMs between Cloud providers (e.g. Reservoir) Agreements between Cloud providers Communications between Clouds At PaaS level: Use services from different Clouds
  8. 8. Federation of Clouds vs Using multipleClouds Federation On-demand of Clouds: Multiple Cloud: 01011 Horizontal 01011 Cross-Cloud 001 or 001 or ? InterClouds ? Sky computing 01 011 01 011 01011 001 01 01 01 011 011 011 001 01011 01 011
  9. 9. mOSAIC ApproachThe mOSAIC project aims to develop an open- source platform that enables applications to negotiate Cloud services as requested by their users.Using the Cloud ontology, applications will be able to specify their requirements and communicate them to the platform via the innovative API.The platform will implement a multi-agent brokering mechanism that will search for services matching the applications‟ request, and possibly compose the requested service if no direct hit is found.
  10. 10. mOSAIC ApproachCloud-application developers and maintainers will be able to postpone their decision on the procurement of Cloud services until runtime, while end-user applications will be able to find best-fitting Cloud services to their actual needs and efficiently outsource computations.The platform will facilitate competition and cooperation among Cloud providers, who, in return, will be able to reach customers they could not reach before.
  11. 11. mOSAIC Key features and technologiesVendor agnostic API Component-basedOpen source PaaS applicationsCloud resources and Multiple Clouds services brokering Long time runningCloud Agency applicationsSLA negotiations and Event driven, asynchronous monitoringCloud OntologySemantic Engine
  12. 12. mOSAIC goalsAn API Cloud-based language- and platform-independent API Extends the existing language- or platform-dependent API capabilities with composite features based on patternsA framework Semantic engine Cloud ontology & Semantic representation of Cloud resources Applications‟s needs in terms of SLAs and QoS requirements Cloud agencyAn open-source platform a proof-of-the-concept prototype ready to be tested, exploited or extended by its users include instances of the APIs for two programming languages and application toolsProofs of validity through the use cases and applications
  13. 13. mOSAIC goalsAPI at high level independent from the provider With implementation in high level languagesCommon representations of resources Cloud taxonomy and ontologyPowerful platform allowing dynamicity and Identification of appl‟s requirements in terms of resources (Re)Negotiation of the offers from different providers Monitoring and benchmarking Connectors to different services based on a common understanding
  14. 14. mOSAIC milestones September 2011: 1st implementation of API Cloud ontology September 2012: Platform available March 2013: Full software package
  15. 15. mOSAIC: A Global View VM mOSAIC Cloud Platform Provider mOSAIC-Based ApplicationUsers data Cloud Provider mOSAIC VM API mOSAIC Cloud Framework dataProvider Developers
  16. 16. mOSAIC: A Global View VM mOSAIC Cloud Platform Provider mOSAIC-Based ApplicationUsers data CloudUsers Sees only the ProviderFinal Applicantion mOSAIC VM APIThey does not know mOSAIC Cloudanything (as less as Framework dataProviderpossible) about theCloud Developers
  17. 17. mOSAIC: A Global View Cloud Provider are VM Resource owners. mOSAIC Cloud Platform Provider mOSAIC-Based They are involved for Application everything related to acquiring resources.Users data They are accessed Cloud trough mOSAIC, as less Provider as possible dependence between Provider and mOSAIC VM developer. API mOSAIC Cloud Framework dataProvider Only Framework knows about CP Developers
  18. 18. mOSAIC: A Global View VM mOSAIC Cloud Platform Provider mOSAIC-Based ApplicationUsers data Cloud Provider VM mOSAIC Cloud API mOSAIC Framework dataProvider Developers
  19. 19. Platform Components
  20. 20. Current ongoing relevant tasks  T2.3 → Semantic engine T1.2 → Cloud Ontology  Semantic query T1.3 → API design  Service discovery  APIs description  Matchmaking T2.2 → API implementation  T2.5 → Provider Agent T1.4 → Cloud agency  Agent protocols  Resources  Cloud request  Services T1.5 → SLA agreement and  Offer Qos  T2.6 → Negotiator module  Resource/services  Cloud Provider  T3.1 → Cloud usage patterns  Performance figures (QoS parameters)  Patterns description  T3.2 → Platform Use cases
  21. 21. Progress so farFinalized deliverables (at Y1)• API design• API first prototype implementation - in Java• Cloud Ontology• Cloud Usage patternsWork in progress• Semantic Engine• Cloud Agency• SLA management and monitoring• mOSAIC Applications development/porting
  22. 22. mOSAIC APIConcepts: in public D1.3/Sept 2011 & papersImplementations: In Java, available at: http://www.mosaic-cloud.eu -> <For Developers> box https://bitbucket.org/mosaic/ Guide in mosaic-api / mosaic-mvn / doc In Python, in February 2012
  23. 23. mOSAIC API ArchitecturemOSAIC API Layers Lowest Layer: Native resource protocol} (Web service, RPC, etc.), or a native resource API provided as a library by the vendor for a certain programming language. No uniformity. Driver API: Wraps the native API, providing the first level of uniformity: all resources of the same type are exported with the same interface. Thus exchanging, for example, an Amazon S3 with a Riak key-value store is just a matter of configuration. Connector API: depending on the programming language, provides abstractions for the cloud resources, suitable for the programming paradigm. This is where we provide the second kind of uniformity for the programming paradigms, as all the implementations of the connector API in object oriented programming languages will have similar class hierarchies, method signatures, or patterns. Cloudlet API: Even thought the developer already can access cloud resources, he or she must restrict himself or herself to a cloud compliant programming methodology, which we provide (integrated with all the layers already mentioned) that we call Cloudlet, as similar with the existing Java Servlet technology that provides standard programming components in J2EE environments.
  24. 24. mOSAIC API‟s Layers Component Component Component Component Component Application components Cloudlet API Cloudlet API Support for components Connector API Connector API For different languages Interoperability API Reference API Driver Driver For same service type API API API API
  25. 25. mOSAIC Cloud Ontology  Provides a unified description of  Cloud components  Interfaces  API  Requirements  SLA  …  Enables  Reasoning  Semantics-based queries executions  Brokering  Discovery  Matchmaking  Cloud Services Composition
  26. 26. mOSAIC Ontology: Top Level
  27. 27. mOSAIC Ontology: Top Level andStandards/Proposals NIST
  28. 28. mOSAIC Ontology: Top Level andStandards/Proposals OCCI
  29. 29. mOSAIC Ontology: Top Level andStandards/Proposals SLA@SOI
  30. 30. mOSAIC Ontology: Top Level andStandards/Proposals IBM/Oracle Azure/ Google
  31. 31. mOSAIC Semantic Engine Cloud Ontology Developer‟s requests: •Functional •Non-Functional (e.g. resources, SL requests) Provider AgentsCreate: Reasoning and matchmakingnew Agent(bindings) Looks for semantic descriptions of APIs APIs { CPU, descriptions EC2 Understands compliant, resource type and bindings interface }
  32. 32. mOSAIC Cloud Agency The mOSAIC Cloud agency will beconceived according a service-orientedarchitecture, where agents will implementstateful, eventually mobile, servicesNegotiation, monitoring, dynamicbenchmarking and reconfiguration ofcloud resources are some mandatoryservices to be implemented Why agents?
  33. 33. Cloud AgencyArchitecture
  34. 34. SLA and QoS monitoring and management QoS parameters Negotiation SLA Agreement Monitoring Re-negotiation T1.2 Ontology T1.4 Cloud Agency T2.5 Provider T2.6 Negotiator
  35. 35. mOSAIC Use casesExisting use cases OCCI use cases with IaaS API requirements Cloud Computing Use Case Discussion Group Provider‟s use cases Research use cassemOSAIC‟s use cases Type Title Data intensive Storage and data distribution in Earth Observation Earth Observation mission reprocessing Routine production of Earth Observation products Fast data access for crisis situations Distributed intelligent maintenance Compute Cloud-distributed parameter sweep
  36. 36. More details in papers:API layers: Towards a cross-platform Cloud API, CLOSER 2011, SciTePress.API interop: Building an Interoperability API for Sky Computing, InterCloud/HPCS, IEEE CSCloud ontology: An Ontology for the Cloud in mOSAIC Cloud. In Cloud computing: methodology, system, and applications. CRC, Taylor & Francis group, 2011An Analysis of mOSAIC ontology for Cloud Resources annotation, Proceedings of the Federated Conference on Computer Science and Information Systems pp. 983–990, 2011.Platform services: Arhitecturing a Sky Computing Platform, ServiceWave 2010, LNCS 6569Cloud agency: Agent based Cloud provisioning and management, CLOSER 2011, SciTePress.SLA manag: A Cloud Agency for SLA Negotiation and Management, EuroPar „10, LNCS 6586Use case: From Grid To Sky Computing. Case Study for Earth Observation, 10th CGW 2010,Patterns: Identifying Cloud Computing Usage Patterns, IEEE Cluster 2010,Test appls: Building a Mosaic of Clouds, EuroPar 2010, Springer, LNCS 6586

×