EEDC34330 Execution Environments for Scientific Cloud Distributed Interoperability Computing Javier Álvarez

Transcription

1 EEDC Execution Environments for Distributed Computing Master in Computer Architecture, Networks and Systems - CANS Scientific Cloud Interoperability Javier Álvarez javicid@gmail.com

2 Outline Cloud Computing Infrastructure as a Service Problematic Goals Many alternatives Vendor lock-in Possible Approaches Standarization OVF OCCI Federation Pros / Cons Pros /Cons Interoperability Semantics Pros /Cons Research Efforts Conclusions Bibliography References 2

3 Cloud Computing Software as a Service Deliver of applications Platform as a Service Platform for developing and deploying applications Infrastructure as a Service Deliver of computer resources Physical Infrastructure 3

4 Infrastructure as a Service 4

5 Infrastructure as a Service 5

6 Infrastructure as a Service 6

7 Infrastructure as a Service 7

8 Infrastructure as a Service 8

9 Infrastructure as a Service IP addr 9

10 Infrastructure as a Service IP addr ssh 10

11 Problematic: Many alternatives Which one to choose? Different APIs Different features Different prices 11

12 Problematic: Vendor lock-in Increments in price Not enough capacity Changes in policies Software incompatibilities Unexpected crashes Migrations are very expensive! 12

13 Goals Break API bonding (ideal) Multiple Cloud interactions Save money More flexibility Open new possibilities 13

14 Possible Approaches Standarization Federation Interoperability 14

15 Standarization Agree in a common: Protocol API Datamodel Hypervisor Some standards already exist: Open Virtualization Format (OVF) Open Cloud Computing Interface (OCCI) 15

16 Standarization: OVF Datamodel to define virtual appliances DMTF standard Open XML based Vendor independent Complex (maybe too much) 16

17 Standarization: OCCI Cloud API OGF standard Open REST based Simple Datamodel independent (OCCI + OVF) Implemented by: EMOTIVE Cloud Eucalyptus OpenNebula OpenStack 17

18 Standarization? Best approach Cheapest (once done) Everything works! Different implementations Universality is hard Big companies rule De facto standards: vcloud Amazon EC2 deltacloud 18

19 Federation A Cloud provider outsources some resources to another one InterCloud Hybrid Cloud Cloud bursting Usually private + public Some examples: OpenNebula Amazon EC2 RightScale's Multicloud 19

20 Federation? Capacity limitations solved Enables use of more than one Cloud Previous agreement needed sometimes Limited to a few providers Still bond to a particular API 20

21 Interoperability Transparent interaction with multiple Cloud providers Usually plug-in based Some examples: deltacloud Dasein Cloud 21

22 Interoperability: Semantics Use of semantics to describe provider's APIs Semantic rules can then be used to translate between different APIs Service Owner Interoperability System Resource Mapper Source Provider Source Interface Annotation / Deannotation Action Mapper Process Enactor Target Interface Target Provider 22

23 Interoperability: Semantics More complex system Easier to add new providers as they appear Real interoperability, very powerful Not bond to any particular interface 23

24 Interoperability? No need of standarization No need of previous agreements Can include new providers Plug-ins: Semantics: Limited Implementation cost API bonding Many issues to solve Complex platform 24

25 Research Efforts SIENA: Standards and Interoperability for einfrastructure Implementation Initiative Drive forward the development and adoption of interoperability and standards in Grid and Cloud infrastructures RESERVOIR: Resources and Services Virtualization without Barriers European project addressed to achieve Cloud federation A Cloud provider outsources some of its demand to another one which whom it has a previous agreement 25

26 Research Efforts NUBA: Normalized Usage of Business-oriented Architectures Spanish project that built a federated platform to manage virtual appliances EMOTIVE Cloud and OpenNebula were used as Cloud providers Semantic interoperability basis was settled Use of OVF Cloud4SOA European project focused on resolving semantic interoperability between Cloud providers Defines a Cloud API and a common ontology to unify Cloud services 26

27 Research Efforts Venus-C: Virtual multidisciplinary EnviroNments USing Cloud infrastructures European project aimed to build a Cloud platform to develop and deploy scientific applications Federated Cloud composed by EMOTIVE, OpenNebula and Azure Promotion of standards: OVF + OCCI OPTIMIS: Optimized Infrastructure Services European project focused on the hybrid Cloud Externalize services and applications to public Clouds 27

28 Conclusions There will always be multiple Cloud providers The ability to interact with more than one of them is essential This interaction can bring new opportunities (e.g. Green Computing) 28

29 Bibliography Ejarque, J., Álvarez, J., Sirvent, R. & Badia, R.M. Orchestrating Services on a Public and Private Cloud Federation. 5th Iberian Gird Infrastructure Conference Proceedings (2011). Ejarque, J., Álvarez, J., Sirvent, R. & Badia, R.M. A Rule-based Approach for Infrastructure Providers' Interoperability Third IEEE International Conference on Coud Computing Technology and Science (2011). R. Buyya, R. Ranjan and R. N. Calheiros, InterCloud: Utility-Oriented Federation of Cloud Computing Environments for Scaling of Application Services, Algorithms and Architectures for Parallel Processing, LNCS vol 6081, 13-31,

30 References el.html