Cloud Standards: EnablingInteroperability.and.package.delivery
1 like1,235 views
The document provides an overview of Abiquo, a cloud management software company. It discusses Abiquo's vision of enabling portability, interoperability, and federation across cloud platforms through open standards. Abiquo aims to allow both cloud providers and users to avoid vendor lock-in and have flexibility in their choice of infrastructure and ability to move workloads. The Abiquo solution is presented as a revolutionary cloud management platform that supports multiple hypervisors and achieves portability through the use of open standards like OVF and interoperability through its APIs.
Cloud Standards: EnablingInteroperability.and.package.delivery
- 1. ABIQUO TECHNICAL OVERVIEW Cloud Standards Enabling Interoperability and Package Delivery June 21, 2010 Cloud Expo Europe Hilton Prague, Czech Republic
- 2. Introduction Revolutionary Cloud Management Diego Parrilla VP Product Management [email protected] www.abiquo.com twitter.com/abiquo
- 3. Agenda Revolutionary Cloud Management 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
- 4. Revolutionary Cloud Management About Abiquo
- 5. About Abiquo Revolutionary Cloud Management 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
- 6. About Abiquo Revolutionary Cloud Management 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.
- 7. Revolutionary Cloud Management The Cloud Dream and Virtualization 1.0
- 8. The Cloud Dream Revolutionary Cloud Management Cloud Computing is the ideal solution for users & providers 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
- 9. Virtualization 1.0 Issues Revolutionary Cloud Management 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
- 10. The Cloud Nightmare Revolutionary Cloud Management 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.”
- 11. Revolutionary Cloud Management Vendor Lock-In
- 12. What is Vendor Lock-in? Revolutionary Cloud Management 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 “#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
- 13. Vendor Lock-in Revolutionary Cloud Management Impacts on the Cloud User: Lock-in prevents three crucial benefits of cloud computing: Portability Interoperability Federation
- 14. Vendor Lock-in Revolutionary Cloud Management 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.
- 15. Revolutionary Cloud Management Open Clouds are Standards-Based
- 16. The Open Cloud Manifesto Revolutionary Cloud Management 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
- 17. Open Clouds Revolutionary Cloud Management 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
- 18. Revolutionary Cloud Management The Abiquo Vision
- 19. The Abiquo Vision Revolutionary Cloud Management
- 20. The Abiquo Vision Revolutionary Cloud Management Cloud Providers should be able to: 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
- 21. The Abiquo Vision Revolutionary Cloud Management Cloud Users should be able to: 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
- 22. Revolutionary Cloud Management The Abiquo Solution
- 23. The Abiquo Solution Revolutionary Cloud Management Revolutionary Cloud Management 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
- 24. The Abiquo Solution Revolutionary Cloud Management Background Information 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)
- 25. The Abiquo Solution Revolutionary Cloud Management Use of standards effectively overcomes lock-in and achieves: Portability Federation Interoperability
- 26. Revolutionary Cloud Management Portability via OVF
- 27. Portability via OVF Revolutionary Cloud Management 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
- 28. OVF Package Revolutionary Cloud Management 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
- 29. Disk Formats Revolutionary Cloud Management 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>
- 30. OVF Descriptor Revolutionary Cloud Management 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) SomeSection (Extension) VirtualSystem or VirtualSystemCollection
- 31. Virtual System Revolutionary Cloud Management 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) ProductSection OperatingSystemSection
- 32. OVF Custom Extensions Revolutionary Cloud Management OVF requires custom extensions to do the following: Define multiple networks Set up firewalls Set up load balancers Define startup process
- 33. OVF Custom Extensions Revolutionary Cloud Management 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
- 34. OVF Conformance Levels Revolutionary Cloud Management 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
- 35. Revolutionary Cloud Management Achieve Interoperability with OVF and APIs
- 36. OVF and Interoperability Revolutionary Cloud Management OVF is not inherently interoperable APIs enable interoperability for OVF There are several API standards
- 37. Cloud APIs Revolutionary Cloud Management Far from a homogenous scenario: Abiquo published Cloud Service API based on vCloud 0.9 (beta) in Abiquo v1.6 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. OCCI API covers the provisioning, monitoring and definition of Cloud Infrastructure services. Lacks traction in the industry. Cloud API is an opensource initiative from SUN, handicapped by Oracle‟s new strategy. An inspiration for other initiatives. TCloud is an initiative from Telefónica. vCloud + Telefonica extensions. They were (are?) one of the biggest supporters of OCCI
- 38. Why vCloud? Revolutionary Cloud Management 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.
- 39. vCloud Properties Revolutionary Cloud Management 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
- 40. Abiquo vCloud Browse Request Revolutionary Cloud Management 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
- 41. vCloud and OVF Revolutionary Cloud Management 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.
- 42. vCloud Network Section Revolutionary Cloud Management 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> ...
- 43. vApp Templates Instantiation Revolutionary Cloud Management 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.
- 44. vApp Deployment Workflow Revolutionary Cloud Management POST http://vcloud.abiquolabs.com/vdc/69/action/instantiateVAppTemplate POST http://vcloud.abiquolabs.com/vapp/1/action/deploy http://vcloud.abiquolabs.com/vapp/1/power/action/powerOn Example adapted from the vCloud specification document Content-Type: application/vnd.vmware.vcloud.instantiateVAppTemplateParams+xml 202 Accepted <Task version="1.0" encoding="UTF-8"?> <?xml POST http://vcloud.abiquolabs.com/vdc/69/action/annotate <InstantiateVAppTemplateParams name="Test App" xmlns="http://www.vmware.com/vcloud/v0.8" href="http://vcloud.abiquolabs.com/task/32" href="http://vcloud.abiquolabs.com/task/31" Content-type: application/vnd.vmware.vcloud.annotate+xml xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" startTime="" xsi:schemaLocation="http://www.vmware.com/vcloud/v0.8 expiryTime="" encoding="UTF-8"?> http://vcloud.example.com/ns/vcloud.xsd"> <?xml version="1.0" status="running" <VAppTemplate href=”http://vcloud.abiquolabs.com/vAppTemplate/1” /> <Annotate xmlns="http://www.vmware.com/vcloud/v0.8" xsi:schemaLocation="http://vcloud.example.com/ns/vcloud.xsd xsi:schemaLocation="http://vcloud.example.com/ns/vcloud.xsd" <InstantiationParams xmlns:vmw="http://www.vmware.com/schema/ovf"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <NetworkConfigSection> xmlns="http://www.vmware.com/vcloud/v0.8" xsi:schemaLocation="http://www.vmware.com/vcloud/v0.8 <NetworkConfig name="Network 1"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> http://vcloud.example.com/ns/vcloud.xsd"> <Features> <Link rel="task:cancel" href="http://vcloud.abiquolabs.com/task/31/action/cancel"/> href="http://vcloud.abiquolabs.com/task/32/action/cancel"/> <VAppTemplate href="https://vcloud.abiquolabs.com/vAppTemplate/1"/> <vmw:FenceMode>allowInOut</vmw:FenceMode> <Owner href="http://vcloud.abiquolabs.com/vapp/1" </Annotate> <vmw:Dhcp>true<vmw:Dhcp> type="application/vnd.vmware.vcloud.vApp+xml" name="Test App"/> </Features> </Task> OK 200 <NetworkAssociation href="http://vcloud.abiquolabs.com/network/1"> </NetworkConfig> <?xml version="1.0" encoding="UTF-8"?> </NetworkConfigSection> <Envelope ... > </InstantiationParams> ... </InstantiateVAppTemplateParams> <NetworkSection> 200 OK ... <?xml version="1.0" encoding="UTF-8"?> <Network> <VApp name="Test App" status="1" ... href="http://vcloud.abiquolabs.com/vapp/1" xmlns="http://www.vmware.com/vcloud/v0.8" </Network> xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" <vmw:ProvidedNetwork href="https://vcloud.example.com/network/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" type="application/vnd.vmware.vcloud.network+xml" name="Network 1"/> xsi:schemaLocation="http://www.vmware.com/vcloud/v0.8 </NetworkSection> http://vcloud.example.com/ns/vcloud.xsd"> ... <Link rel="up" href=http://vcloud.abiquolabs.com/vdc/69 type="application/vnd.vmware.vcloud.vdc+xml”/> </Vapp> </Envelope>
- 45. Revolutionary Cloud Management Conclusions
- 46. Conclusions Revolutionary Cloud Management 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.
- 47. Revolutionary Cloud Management Q&A