Cloud Standards: EnablingInteroperability.and.package.delivery

ABIQUO TECHNICAL OVERVIEW

Cloud Standards

Enabling Interoperability and Package Delivery

June 21, 2010

Cloud Expo Europe

Hilton Prague, Czech Republic

Revolutionary Cloud Management

Introduction

Diego ParrillaVP Product Management

[email protected]

www.abiquo.com

twitter.com/abiquo

mailto:[email protected]

http://www.abiquo.com/

http://twitter.com/abiquo


Agenda

1. About Abiquo

2. The Cloud Dream and Virtualization 1.0

3. Vendor Lock-in

4. Open Clouds are Standards Based

5. The Abiquo Vision

6. The Abiquo Solution

7. Portability via OVF

8. Interoperability: OVF and APIs

9. Conclusions

10.Q&A


About Abiquo


About Abiquo

Our Company

Founded 2006 in Barcelona by Diego Mariño and Xavier

Fernández

Our Team

Pete Malcolm, CEO

Trevor Chamberlain, VP Business Development

Xavier Fernández, Founder and VP Engineering

Helena Torras, VP Operations

Diego Parrilla, VP Product Management

Steve Soechtig, VP Global Sales

Nick Wetton, VP Regional Sales


About Abiquo

Our Technology

Abiquo product development commenced early 2008

First open source pre-release April 2009

Over 15,000 downloads

Formal 1.0.0 release February 2010

Our Mission

Become a leading vendor of groundbreaking virtualization

management solutions, liberating both IT organizations and

the users they serve, while increasing business agility, efficiency, and reducing cost.


The Cloud Dream

and

Virtualization 1.0


The Cloud Dream

Cloud Users

No upfront commitment, no CAPEX, only OPEX

Pay-per-use, no long-term contracts Dynamic Scaling

Physical location irrelevant

Cloud Provider Higher ratio of servers per Sys Admin

Higher efficiency

Built on top of commoditized hardware

Cloud Computing is the ideal solution for users & providers


The Cloud created additional problems, including:

High Provisioning Effort = IT Bottleneck

Poor Capacity Planning and Utilization

Vendor Lock-In

Low-efficiency Virtual Server Sprawl

Security and Compliance Concerns

Virtualization 1.0 Issues


The Cloud Nightmare

Examples of common problems experienced by Users and Providers:

“Our Cloud Provider SLA is not meeting our needs, but there is

no easy way to move our solution to another provider.”

“We had all of our project data stored virtually, but the hosting

provider corrupted it. How can we trust the cloud for future

projects?”

“I developed my solution on top of an existing platform, which

was sold to another company. Now I have 30 days to remove

all aspects of my solution and have no control over it.”

“There are new players in the Cloud Provider arena that we

might want to try, but it is impossible to transfer our servers and

data.”


Vendor Lock-In


What is Vendor Lock-in?

“#2 Obstacle for Adoption and Growth of Cloud Computing:

The degree of difficulty associated with moving an application from one

cloud provider to another, to your datacenter, or simply take your data

out of the cloud.” Above the Clouds: A Berkeley View of Cloud Computing

Reliant on one vendor and cannot switch to another vendor

without substantial costs

No alternative if the vendor fails or the product is no longer viable

Cloud Users risk being completely reliant on one vendor

Cloud Providers are limited to customers that only want to use

the vendor they support


Vendor Lock-in

Impacts on the Cloud User:

Lock-in prevents three crucial benefits of cloud computing:

Portability

Interoperability

Federation


Vendor Lock-in

Impacts on the Cloud Vendor:

Vendor lock-in does not allow you to change any of your

providers during the Platform‟s lifetime.

A Cloud Platform is composed of:

Servers

Storage Systems Networking devices

Hypervisors

Monitoring tools

Cloud Management Software

The lifespan of a Cloud Platform can last many years.


Open Clouds are

Standards-Based


The Open Cloud Manifesto

Principles of an Open Cloud

1. Open collaboration

2. No platform vendor lock-in

3. Use and adopt existing standards

4. Promote innovation

5. Customer-driven

6. Collaboration to prevent open-source effort overlap


Open Clouds

Required Features

Portability: move a cloud solution (apps, data, network,

config)to other Cloud Platform than the one that it was

created

Interoperability: use the services of more than one Cloud

Platform

Federation: Cloud Platforms can talk to each

other to offer interoperability or transparency


The Abiquo Vision


The Abiquo Vision


The Abiquo Vision

Choose their infrastructure, including: Servers

Hypervisors

Open-source and proprietary solutions

Storage Array Networks Networking devices

Mix different technologies and make them interoperable

Provide elasticity

Cloud Providers should be able to:


The Abiquo Vision

Import existing Standard (gold) images

Use any infrastructure of their choice

Manage Global Resources from one dashboard

Manage the platform using different types of APIs

Portability

Interoperability

Federation

Cloud Users should be able to:


The Abiquo Solution



Vendor independent

Supports ESX, ESXi, Xen, Xen Server, KVM, Hyper-V

Virtual-to-virtual (V2V) conversion between all hypervisors

Enterprise class

Standards-based

Policy-driven

Multi-tenancy delegated control

Manages private and public clouds

The Abiquo Solution


The Abiquo Solution

Developed in Java, C (Cloud Nodes) and Flex (interface)

MySQL as the database backend

Service Oriented Architecture (SOA)

Abiquo Enterprise Edition codebase extends the Abiquo

Community Edition

Standards:

OVF

WS-Management / CIM resources

API based on vCloud 0.9 (beta)

Stateless architecture (horizontal scalability)

Background Information


Use of standards effectively overcomes lock-in

and achieves:

The Abiquo Solution

Portability

Interoperability

Federation


Portability via OVF


Portability via OVF

Open Virtualization Format (OVF) enables people to move a cloud

solution (apps, data, network, config) from one Cloud Platform to another.

Packaging and distributing virtual appliances

Software to be run in virtual machines

Not tied to any particular hypervisor or processor architecture

An OVF Package contains one or more virtual systems

Can be deployed to several virtual machines

Supported by DMTF

OVF is the only open standard getting traction in the industry and

community


OVF Package

An OVF Package consists of:

OVF descriptor (.ovf)

Disk images

Additional resources (ISO files, XML files, icons)

Manifest files (.mf)

Certificates (.cert)

Debian-5-lenny-32bit.ovf

Debian-5-lenny-32bit-streamOptimized.vmdk

Debian_logo.png

Debian-5-lenny-32bit.mf


Disk Formats

OVF does not require any specific disk format

VMDK Stream Optimized is the preferred

Every disk should have a static URI which identifies the format in the OVF

descriptor

<DiskSection>

<Info>List of the virtual disks used in the package</Info>

<Disk

ovf:capacity="1073741824"

ovf:diskId="vmdisk1"

ovf:fileRef="file1"

ovf:format="http://www.vmware.com/technical-

resources/interfaces/vmdk_access.html#streamOptimized"/>

</DiskSection>


OVF Descriptor

XML document

Stores product details, virtual hardware requirements, licensing and others

Extensible: metadata can be added with new ‘Section’ nodes.

Envelope

References (One)

File

File

DiskSection (Zero or One)

NetworkSection (Zero or One)

VirtualSystem or VirtualSystemCollection

SomeSection (Extension)


Virtual System

Description of the content of a Virtual Machine

Stores product details, virtual hardware requirements, licensing and others

Extensible: metadata can be added with new ‘Section’ nodes.

VirtualSystem

VirtualHardwareSection (One)

System

Item (N elements)

OperatingSystemSection

ProductSection


OVF Custom Extensions

OVF requires custom extensions to do the following:

Define multiple networks

Set up firewalls

Set up load balancers

Define startup process


OVF Custom Extensions

OVF was designed for static deployments, not Cloud Computing

Does not work for elastic, self-configuring environments.

Focused in the Virtual Machine, not in the Virtual

Datacenter.

Ambiguous about disk formats.

No SLA or QoS attributes.

Extensions and an API are necessary to manage OVF in the Cloud


OVF Conformance Levels

Three levels of conformance (1 is the highest):

1. OVF descriptor uses only sections and elements and attributes that are

defined in this specification.

2. OVF descriptor uses custom sections or elements or attributes that are

not defined in this specification, and all such extensions are optional.

3. OVF descriptor uses custom sections or elements that are not defined

in this specification and at least one such extension is required

“The use of conformance level 3 limits portability

and should be avoided if at all possible”Open Virtualization Format Specification DSP0243 V1.1.0


Achieve Interoperability

with

OVF and APIs


OVF and Interoperability

OVF is not inherently

interoperable

APIs enable

interoperability for

OVF

There are several

API standards


Cloud APIs

Far from a homogenous scenario:

EC2 API is the de facto standard of the industry. IP belongs to

Amazon. Rumors of changing to an open license since end 2009.

vCloud API used to manage VMware„s virtualized infrastructures.

Fastest growing API.

Cloud API is an opensource initiative from SUN, handicapped by

Oracle‟s new strategy. An inspiration for other initiatives.

OCCI API covers the provisioning, monitoring and definition of

Cloud Infrastructure services. Lacks traction in the industry.

TCloud is an initiative from Telefónica. vCloud + Telefonica

extensions. They were (are?) one of the biggest supporters of OCCI

Abiquo published Cloud Service API based on vCloud 0.9

(beta) in Abiquo v1.6


Why vCloud?

Choosing the right cloud API:

EC2 semantics and model do not meet our needs. Would lose

70% of features.

Sun Public Cloud was promising and we developed a

prototype, but had to abandon it due to the changes at Sun.

OCCI has a lot of great features, but it lacks of traction in the

industry.

vCloud has staying power in the industry, some customers

prefer vCloud to OCCI or EC2.

vCloud semantics and model are a good fit for our platform.


vCloud Properties

Based on REST principles

Basic HTTP Authentication

A Cloud is composed of

Organizations

Virtual DataCenters

Catalogs

Virtual Apps (vApps)

Use Case Categories:

Browsing

Provisioning

Self-Service Datacenter Operations


Abiquo vCloud Browse Request

Browse the information of an organization

GET http://vcloud.abiquolabs.com/org/69

Content-Type: application/vnd.vmware.vcloud.org+xml

200 OK

<?xml version="1.0" encoding="UTF-8"?>

<Org href="http://vcloud.abiquolabs.com/org/69" name="Abiquo"

xsi:schemaLocation="http://www.vmware.com/vcloud/v0.8 organization.xsd"

xmlns="http://www.vmware.com/vcloud/v0.8"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<Link rel="down" href="http://vcloud.abiquolabs.com/catalog/1"

type="application/vnd.vmware.vcloud.catalog+xml" name="Apps Library"/>

<Link rel="down" href="http://vcloud.abiquolabs.com/vdc/1"

type="application/vnd.vmware.vcloud.vdc+xml" name="HyperV-VDC"/>

<Link rel="down" href="http://vcloud.abiquolabs.com/vdc/2"

type="application/vnd.vmware.vcloud.vdc+xml" name="KVM-VDC"/>

<Link rel="down" href="http://vcloud.abiquolabs.com/network/1"

type="application/vnd.vmware.vcloud.network+xml" name="Public Network"/>

<Description>Abiquo Default Organization</Description>

</Org>

Abiquo vCloud implementation will run on top of any hypervisor


vCloud and OVF

vCloud gives ‘dynamism’ to OVF

OVF is the unit of distribution for vApps and vApp Templates.

vCloud API defines the façade to the instantiation mechanism of

the platform that transforms the OVF package into a deployable

vApp.

Deployable OVF packages are not Level 1 Conformant.

OVF is too generic.

Need to modify the OFV package.

Extra sections need to be added before passing the package

to the platform.


vCloud Network Section

Example from the vCloud specification document 0.8

...

<NetworkSection>

<Info>The list of logical networks</ovf:Info>

<Network ovf:name="Network 1"/>

</NetworkSection>

<NetworkConfigSection>

<NetworkConfig name="Network 1">

<Features>

<Dhcp>true</Dhcp>

<Nat></Nat>

<Firewall></Firewall>

</Features>

</NetworkConfig>

</NetworkConfigSection>

<NetworkConnectionSection>

<NetworkConnection name="Network 1">

<IPAddress>192.168.1.100</IPAddress>

</NetworkConnection>

</NetworkConnectionSection>

...


vApp Templates Instantiation

vApp is resolved by being bound to a provider specific platform:

Parameters mapped to the core metadata of the Envelope must

be specified to resolve the template.

Two-step process specific to the cloud platform:

1. „Annotate‟ the vApp template

2. Construct and send the Instantiation Parameters

Then the vApp template instance can be deployed in the Virtual

Data center.

Deployment means „reservation‟ of the resources.

Finally, the user can start the vApp deployed.


POST http://vcloud.abiquolabs.com/vdc/69/action/instantiateVAppTemplate

Content-Type: application/vnd.vmware.vcloud.instantiateVAppTemplateParams+xml


<InstantiateVAppTemplateParams name="Test App" xmlns="http://www.vmware.com/vcloud/v0.8"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.vmware.com/vcloud/v0.8

http://vcloud.example.com/ns/vcloud.xsd">

<VAppTemplate href=”http://vcloud.abiquolabs.com/vAppTemplate/1” />

<InstantiationParams xmlns:vmw="http://www.vmware.com/schema/ovf">

<NetworkConfigSection>

<NetworkConfig name="Network 1">

<Features>

<vmw:FenceMode>allowInOut</vmw:FenceMode>

<vmw:Dhcp>true<vmw:Dhcp>

</Features>

<NetworkAssociation href="http://vcloud.abiquolabs.com/network/1">

</NetworkConfig>

</NetworkConfigSection>

</InstantiationParams>

</InstantiateVAppTemplateParams>

200 OK


<VApp name="Test App" status="1"

href="http://vcloud.abiquolabs.com/vapp/1" xmlns="http://www.vmware.com/vcloud/v0.8"

xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1"




<Link rel="up" href=http://vcloud.abiquolabs.com/vdc/69 type="application/vnd.vmware.vcloud.vdc+xml”/>

</Vapp>

POST http://vcloud.abiquolabs.com/vapp/1/action/deploy

202 Accepted

<Task

href="http://vcloud.abiquolabs.com/task/31"

startTime=""

expiryTime=""

status="running"

xsi:schemaLocation="http://vcloud.example.com/ns/vcloud.xsd"



<Link rel="task:cancel" href="http://vcloud.abiquolabs.com/task/31/action/cancel"/>

<Owner href="http://vcloud.abiquolabs.com/vapp/1"

type="application/vnd.vmware.vcloud.vApp+xml" name="Test App"/>

</Task>

POST http://vcloud.abiquolabs.com/vapp/1/power/action/powerOn

202 Accepted

<Task

href="http://vcloud.abiquolabs.com/task/32"

startTime=""

expiryTime=""

status="running"

xsi:schemaLocation="http://vcloud.example.com/ns/vcloud.xsd



<Link rel="task:cancel" href="http://vcloud.abiquolabs.com/task/32/action/cancel"/>

<Owner href="http://vcloud.abiquolabs.com/vapp/1"

type="application/vnd.vmware.vcloud.vApp+xml" name="Test App"/>

</Task>

POST http://vcloud.abiquolabs.com/vdc/69/action/annotate

Content-type: application/vnd.vmware.vcloud.annotate+xml


<Annotate xmlns="http://www.vmware.com/vcloud/v0.8"




<VAppTemplate href="https://vcloud.abiquolabs.com/vAppTemplate/1"/>

</Annotate>

200 OK


<Envelope ... >

...

<NetworkSection>

...

<Network>

...

</Network>

<vmw:ProvidedNetwork href="https://vcloud.example.com/network/1"

type="application/vnd.vmware.vcloud.network+xml" name="Network 1"/>

</NetworkSection>

...

</Envelope>

vApp Deployment Workflow

Example adapted from the vCloud specification document

http://vcloud.abiquolabs.com/vdc/69


Conclusions


Conclusions

Still in early stage of the evolution of standards

OVF is too „Virtual Machine oriented‟.

OVF should evolve to cover more custom extensions made by

cloud providers (OVF 2.0?).

vCloud seems to be the future standard for Cloud Interoperability,

but has yet to address several challenges.

vCloud delegates a lot of capabilities to the underlying platform. It

should explicitly define features of these platforms.

vCloud HTTP basic security should be an option among more

secure and stronger authentication mechanisms.


Q & A

Date post:	17-May-2015
Category:	Documents
Upload:	abiquo-inc
View:	2,166 times
Download:	2 times

Cloud Standards: EnablingInteroperability.and.package.delivery

Documents