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

(1)

Execution

Environments for

Distributed

Computing

Scientific Cloud

Interoperability

EEDC

3

43 ₃

0

Master in Computer Architecture, Networks and Systems - CANS

Javier Álvarez [email protected]

(2)

2

Outline

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

(3)

3

Cloud Computing

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

(4)

4

(5)

5

(6)

6

(7)

7

(8)

8

(9)

9

Infrastructure as a Service

(10)

10

Infrastructure as a Service

ssh

(11)

11

Problematic: Many alternatives

Which one to choose?

➔

Different APIs

➔

Different features

(12)

12

Problematic: Vendor lock-in

●

Increments in price

●

Not enough capacity

●

Changes in policies

●

Software incompatibilities

●

Unexpected crashes

(13)

13

Goals

●

Break API bonding (ideal)

●

Multiple Cloud interactions

●

Save money

●

More flexibility

(14)

14

Possible Approaches

●

Standarization

●

Federation

(15)

15

Standarization

●

Agree in a common:

●

Protocol

●

API

●

Datamodel

●

Hypervisor

●

Some standards already exist:

●

Open Virtualization Format (OVF)

(16)

16

Standarization: OVF

●

Datamodel to define virtual appliances

●

DMTF standard

●

Open

●

XML based

●

Vendor independent

(17)

17

Standarization: OCCI

●

Cloud API

●

OGF standard

●

Open

●

REST based

●

Simple

●

Datamodel independent (OCCI + OVF)

●

Implemented by:

●

EMOTIVE Cloud

●

Eucalyptus

●

OpenNebula

(18)

18

Standarization?

✔

Best approach

✔

Cheapest (once done)

✔

Everything works!

✗

Different implementations

✗

Universality is hard

✗

Big companies rule

✗

De facto standards:

➔

vCloud

➔

Amazon EC2

(19)

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

(20)

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

(21)

21

Interoperability

●

Transparent interaction with multiple Cloud providers

●

Usually plug-in based

●

Some examples:

●

deltaCloud

(22)

22

Interoperability: Semantics

●

Use of semantics to describe provider's APIs

●

Semantic rules can then be used to translate between

different APIs

Service Owner Source Provider Target Provider Annotation / De-annotation Resource Mapper Action Mapper Process Enactor S ou rc e I nt er fa ce T ar ge t I nt er fa ce Interoperability System

(23)

23

Interoperability: Semantics

●

More complex system

●

Easier to add new providers as they appear

●

Real interoperability, very powerful

(24)

24

Interoperability?

✔

No need of

standarization

✔

No need of previous

agreements

✔

Can include new

providers

Plug-ins:

✗

Limited

✗

Implementation cost

✗

API bonding

Semantics:

✗

Many issues to solve

✗

Complex platform

(25)

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

(26)

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

(27)

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

(28)

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.

(29)

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 61-72 (2011).

Ejarque, J., Álvarez, J., Sirvent, R. & Badia, R.M. A Rule-based Approach for Infrastructure Providers' Interoperability. 2011 Third IEEE

International Conference on Coud Computing Technology and Science 272–279 (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, 2010