Open Source Cloud, Virtualization and Deployment Technologies

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1

Kyle Mestery

Office of the Cloud CTO, Cisco

Open Source Cloud, Virtualization and Deployment Technologies


Open Source Cloud and Virtualization Technologies


So Many Choices!


Infrastructure Layer• Linux

Red Hat

Fedora

Ubuntu

• HypervisorKVM

Xen

• Virtual SwitchingOpen vSwitch


Infrastructure Management Layer• Host Management

libvirt

• Infrastructure as a Service OrchestrationOpenStack

CloudStack

oVirt

Eucalyptus


Platform Layer• Platform as a Service

Cloud Foundry

OpenShift

• Cloud OrchestrationAeolus

Heat APIs (open source implementation of Amazon Cloud Forms APIs)


Automation Layer• DevOps #ftw!

• Automation OptionsPuppet

Chef


Building blocks are here

Linux (Fedora, Ubuntu, Red Hat, etc.)Xen or KVM

OpenStack or CloudStack or Eucalyptus or oVirt

Cloud Foundry or OpenShift

Automation

At the heart of all of this …

IaaS for the masses!

PaaS for the masses!

DevOps at scale!

Applications! Yay to applications!


Focus in on IaaS Layer




Automation




DevOps at scale!



What is OpenStack?


OpenStack Mission

“To produce the ubiquitous open source cloud computing platform that will meet the needs of

public and private cloud providers regardless of size, by being simple to implement and

massively scalable.”


OpenStack Technology

Today (Folsom release)• Compute Service (Nova)• Object Storage Service (Swift)• Image Service (Glance)• Identity Service (Keystone)• Dashboard (Horizon)• Network Service (Quantum)

Also• Load Balancer Service (proposed)• Database Service (proposed)• Heat API (AWS CloudForms compatible)• Ceilometer monitoring and metering (proposed)

Releases• Cactus (Q1 2011)• Diablo (Q3 2011)• Essex (Q1 2012)• Folsom (Q3 2012)• Grizzly (Q1 2013)


Asynchronous eventually consistent

communication

REST-based API

Horizontally and massively scalable

Hypervisor agnostic: support for Xen ,XenServer, Hyper-V,

KVM, UML and ESX Hardware agnostic: standard hardware, RAID not required

OpenStack Compute Key Features


REST-based API Data distributed evenly throughout system

Hardware agnostic: standard hardware, RAID not required

No centraldatabase

Scalable to multiple petabytes, billions of objects

Account/Container/Object structure (not file system, no nesting) plus Replication (N copies of accounts, containers, objects)

OpenStack Object Storage Key Features


OpenStack Community


OpenStack Quantum


OpenStack + Quantum: beginnings of a virtual data center• Advantages of cloud computing

On-demand virtualized resources, self-service, lower cost

Resources managed by others

• Ability to create your own isolated private networks

• Extensible

• Challenge!!Easy-to-use

Minus the complexity of the traditional data center

Should work with different networking infrastructure

QuantumNetwork Service


OpenStack Design Summit April 2011

• Compute service (EC2): virtual machines• Specify vCPU, Memory, Disk

• Launch instance (image, mem_size, disk)

• Suspend, clone, migrate

• Storage service (S3, EBS): virtual disks• Specify storage amount, access rights

• Store object

• Create/attach block

• What to do about networks?Simplistic implementation

Embedded in the compute component

App Svr

OS

VM

??


2011 Design Summit - community-driven merger of proposals

NetworkServicePOCNTT/Midokura

NetworkContainersCisco

NetworkServiceCitrix/Rackspace/Nicira

NaaS Core DesignIntel

… more

Quantum


Quantum Network ServiceResource abstractions and service interfaces

• Compute service (EC2): virtual machines• Launch instance (image, mem_size, disk)

• Suspend, clone, migrate

• Storage service (S3, EBS): virtual disks• Store object

• Create/attach block

• Network service (Quantum): virtual networks• Create/delete private network

• Attach VM to network resource

• Work with different networking environments

App Svr

OS

VM

App Svr

OS

VM

App Svr

OS

VM


Quantum Virtual Network Service: A first class citizen in cloud computing

Cloud Platform - Developer API

Compute(Nova)

Servers

Storage(Swift)

Disks

Network(Quantum)

Networks

Identity(Keystone)

Portal(Horizon)

Images(Glance)

Applications OtherServices

Folsom Release


Quantum Abstractions Virtual Networks:

A basic dedicated L2 network segment

Common realization is a VLAN

Virtual Ports:

Attachment point for devices connecting to virtual networks.

Ports expose configuration and monitoring state via extensions (e.g., ACLs, QoS policies, Packet Statistics)

Subnets (new in v2):

An IPAM construct to store CIDR

Also allows to set the Gateway IP and host routes


Quantum Plugins & Extensions Plugin:

Realization of the Quantum abstractions

Supports different back-end technologies and vendors

One plugin per Quantum deployment (there could be sub-plugins managed by the main plugin)

Examples: Linux Bridge Plugin, OVS Plugin, Cisco (Nexus)

Extensions:

API Extensibility for new or back-end specific features

Example: Port-profiles, quality-of-service, etc.


Quantum Plug-in Architecture

Quantum Service API

Quantum API & Extensions Framework

Quantum Plug-in Framework

API Extensions

Cisco Network Plugin

Cisco Device Managers

Cisco Compute & Networking Infra• Switching portfolio (Nexus 3k/5k/7k)

• Unified Computing System• Routing portfolio (e.g. ASR, CRS)


Plugins and Drivers Plugin:

A plugin registers to handle all Quantum API calls (e.g., all network/port calls)

Plugins may make decisions that are technology, but not device-specific (e.g., mapping quantum network ‘HR’ to VLAN 100)

There needs to be a master entity making/resolving decisions in a deployment, that entity is the plugin

Drivers:

The plugin may use drivers to communicate the results of this decision to different devices (e.g., it may configure the VLAN on a port on a virtual switch port, and also tell the upstream physical switch to trunk that VLAN)

Configurable components which can be shared/reused


Extending Quantum to support L3 Constructs Routing within the

tenant (support multi-tier topologies)

Overlapping IP addresses

Support gateways – Internet, VPN

Support other L3 services – LB, Firewall, Caching, etc.

Hybrid Cloud (Public + Private)

Further evolve Quantum to be a multi-tenant network service for creating virtual data centers (application specific topologies + network services)


Why is Quantum important to OpenStack?


Current Infrastructure-as-a-Service has Challenges

ComputeService

(VMs, Memory, Local Disk)

StorageServices

(Block, Massive Key-value

store)

User and System Admin

Basic Network Connectivity

Developer API

Servers Disks Accounts

• Only provides basic Network Connectivity. • Difficult to create N-tier apps.

• Limited ability for applications to take advantage of network services.


Network Services Enable Developer Solutions

User and System Admin

Network Connectivity

Developer API

ComputeService

(VMs, Memory, Local Disk)

Servers

StorageServices

(Block, Massive Key-value store)

Disks

NetworkServices

(Subnets, Network Svcs, Security)

VirtualNetworks

Network APIs

Create-network(“L2”) Attach-vm-to-network(vnet-a) Attach-service-to-network(vnet-b)


Open Source Is Where “Standard” Cloud Infrastructure Will Be Defined

[O]pen standards [require] multiple providers, access to code and data, [and] interoperability of services. Whilst open standards provide part of the solution, it is critical…that a common reference model (i.e. running code) is provided.

[T]he obvious solution is an open source reference model as the standard. Potential examples of such would be the OpenStack effort.

- Simon Wardley, CSC

From “A Question of Standards”http://blog.gardeviance.org/2011/04/question-of-standards.html


Focus in on Automation Layer




Automation




DevOps at scale!



Problem: Scale makes you pull your hair out

X 1000 =




Puppet and Chef to the Rescue!• Designed to assist with configuration and management of systems

• Automates deployment

• Automates configuration

• Automates management

• Written in Ruby

• How does it do this?Declarative language

Puppet: Manifests

Chef: Recipes or cookbooks


Automation and OpenStack• OpenStack automation can be achieved using both Puppet and Chef

Active development and community around both

Cisco is actively participating and contributing to Puppet at the moment

Chef integration is planned

• These technologies are critical to successfully deploying an OpenStack IaaS cloud at any sort of realistic scale

Replicating configuration by hand is doomed to failure

Replicating things with custom scripts is doomed to not scale

Replicating things with Puppet/Chef allows for advanced, scalable configuration management


Cisco OpenStack and Automation• What is Cisco doing around OpenStack and Automation?

• Working closely with Puppet Labs to enable Puppet manifests for deploying OpenStack on Cisco equipment

UCS B-Series and C-Series Compute

Nexus Switches

• All of these manifests are available on the Cisco githubAllows partners and customers to fully take advantage of this advanced automation

Cisco Confidential© 2010 Cisco and/or its affiliates. All rights reserved. 38

Questions?


OpenStack Quantum Demo Background


The goal of the demo• Demonstrate flexible VM communication using open source technologies

• Applications (running in tenants running VMs) should not know or care about underlying technologies

Flexible, isolated network segmentation utilizing OpenFlow and GRE tunnels

Applications just want to communicate

Think the standard 3-tier web app deployment … but at huge scale

“If they have to think about infrastructure, we’ve failed.”

• All orchestrated by softwareHint: SDN


60 Second Background on Demo Components• OpenStack

Nova: Compute manager

Glance: Image management

Quantum: Network service

• Open vSwitchAn open source virtual switch

Uses GRE tunnels for tenant isolation (also possible to use VXLAN)

• Ryu Network Operating SystemOpen Source OpenFlow controller

Works with Quantum as a plugin to setup flows for VM communication


Demo Components• OpenStack

Using devstack on Ubuntu 12.04

Nova, Glance, and Quantum

• Open vSwitchTop of tree (pre 1.9 release)

• Ryu Network Operating SystemOpenFlow Controller plus Quantum Plugin

• All of this is running as VMs on the Macbook Pro I’m using for the preso


Demo Architecture

OpenStack Control Node + Compute

Nova

Glance

Quantum

OpenStackComponents

VM1

RyuController Open

vSwitch

VM2

OpenStack Compute

Nova

OpenStackComponents

RyuAgent Open

vSwitch

1. VMs are started, VIFs are plugged in2. Ryu sets up flows for VM1 to VM2

communication3. Ryu sets up GRE for VM1/VM2 to VM3

communication4. VM1 pings VM25. VM1 pings VM3 over GRE6. Application developer is very happy!

VM3

VXLAN


Demo