Transcript
Page 1: June Boston openStack Summit: Preparing quantum for the data center

Preparing Quantum for the

Data Center

Bob Kukura <[email protected]>

Boston OpenStack User GroupJune 21, 2012

Page 2: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 20122

Agenda

● Red Hat + OpenStack Background

● Quantum Overview as of Essex

● Quantum in Folsom

● Data Center Enhancements

Page 3: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 20123

Red Hat + OpenStack Background

● Red Hat involved with OpenStack since mid 2011

● Full-time [core] developers on most OpenStack upstream projects

● Platinum member of OpenStack Foundation

● Fedora as a primary OpenStack development platform

● Multiple downstream activities

● Packaging OpenStack for Fedora and Enterprise Linux (EPEL)

● OpenStack sessions and labs at Red Hat Summit in Boston next week

● Proof-of-concept integration of Quantum with oVirt (RHEV upstream)

● Demo of OpenShift PaaS running on OpenStack

● Aeolus (CloudForms upstream) adding support for OpenStack

● Heat project – Implementing AWS CloudFormation API on OpenStack

● Red Hat actively hiring for OpenStack in Westford & globally

Page 4: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 20124

Quantum Overview as of Essex● OpenStack incubation project

● Layer 2 Virtual Networking Service

● Network – Isolated L2 network segment

● Port – point of attachment to Network

● Extensible REST API

● Example V 1.1 API requests on following slides

● Plugins – Implements API with specific virtual networking technology

● openvswitch, linuxbridge, cisco, nicira, ryu

● Agents – execute network commands on compute nodes for certain plugins

● Nova Integration – usable, but limited

● VIF Drivers

● Nova Network Service

● QuantumManager

● Nova or Melange IPAM

Page 5: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 20125

V1.1 API – Create Network

POST /v1.1/tenants/XYZ/networks.json

Request:

{ "network": { "name": "test_create_network" }}

Response:

{ "network": { "id": "158233b0-ca9a-40b4-8614-54a4a99d47d1", }}

Page 6: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 20126

V1.1 API – Create Port

POST /v1.1/tenants/XYZ/networks/158233b0-ca9a-40b4-8614-54a4a99d47d1/ports.json

Request:

{ "port": { "state": "ACTIVE" }}

Response:

{ "port": { "id": "98017ddc-efc8-4c25-a915-774b2a633855" }}

Page 7: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 20127

V1.1 API – Attach VM Interface

PUT /v1.1/tenants/XYZ/networks/158233b0-ca9a-40b4-8614-54a4a99d47d1 \ /ports/98017ddc-efc8-4c25-a915-774b2a633855/attachment.json

Request:

{ "attachment": { "id": "test_interface_identifier" }}

Page 8: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 20128

Quantum in Folsom● Core project

● May be default networking service for Nova, but legacy NetworkManagers still available

● L3 functionality

● IPAM from Melange

● DHCP, firewall, NAT, ...

● V2 API

● Adds Subnet as top-level resource

● Port becomes top-level resource

● Example requests on following slides

● New client library and CLI

● Authentication and authorization via Keystone

● Tenant_id eliminated from resource URLs

● New Nova integration

● Nova Networking service and QuantumManager eliminated

● Horizon integration

Page 9: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 20129

V2.0 API – Create Network

POST /v2.0/networks

Request:

{ "name" : "net1"}

Response:

{ "id": "98bd8391-199f-4440-824d-8659e4906786", "name": "net1", "admin_state_up": True, "op_status": "ACTIVE", "tenant_id": "a4fc5328-c270-4891-845a-e61c9153d261", "subnets" : [], }

Page 10: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 201210

V2.0 API – Create SubnetPOST /v2.0/subnets

Request:

{ "network_id": "98bd8391-199f-4440-824d-8659e4906786", "ip_version": 4, "cidr": "10.0.0.0/24", }

Response:

{ "id": "e76a23fe-b028-47b8-a765-858b65c0f857", "network_id": "98bd8391-199f-4440-824d-8659e4906786", "ip_version": 4, "cidr": "10.0.0.0/24", "gateway_ip": "10.0.0.1", "dns_nameservers": ["8.8.8.8"], "reserved_ranges": [ { "start" : "10.0.0.1", "end": "10.0.0.1"}, {"start": "10.0.0.255", "end" : "10.0.0.255"}], "additional_host_routes": [], }

Page 11: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 201211

V2.0 API – Create Port with InterfacePOST /v2.0/ports

Request:

{ "network_id": "98bd8391-199f-4440-824d-8659e4906786", "device_id": "32aeb491-4e78-4c24-8ab8-363daa65aa4d", }

Response:

{ "id": "b08a3807-5d3b-4ab8-95ce-3ed5aa28bdf6", "network_id": "98bd8391-199f-4440-824d-8659e4906786", "admin_state_up": True, "op_status": "ACTIVE", "mac_address": "ca:fe:de:ad:be:ef", "fixed_ips": [ "10.0.0.2" ], "host_routes": [ { "destination": "0.0.0.0/0", "nexthop" : "10.0.0.1" }, { "destination": "10.0.0.0/24", "nexthop": Null }], "device_id": "32aeb491-4e78-4c24-8ab8-363daa65aa4d", }

Page 12: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 201212

Data Center Challenge

● Quantum currently assumes "green-field" cloud deployment

● Uniform pool of similar compute nodes● Uniform connectivity● Tenant networks are completely isolated

● What about Quantum in existing data centers?● On-premise private OpenStack clouds ● As networking service for "enterprise virtualization"

● Red Hat PoC: Integrate Quantum with oVirt

Page 13: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 201213

Provider Networks

● Problem: How can VMs connect to existing data center networks using Quantum?

● Solution: provider-networks blueprint for Folsom

● Add “provider” API extension● Extend create_network operation so admins can specify VLAN tags and/or select

physical network ids via extended parameters

● Provider details visible to admins via GET operations

● Non-admins can use admin-defined provider networks if authorized

● Implement “provider” extension in (at least) linuxbridge and openvswitch plugins

● Support “flat” (untagged) networks and VLANs

● Support multiple physical network devices with separate VLAN tag spaces

● Map physical network names to node-specific network devices

● Will also need flexibility in layer 3● e.g. Use existing DHCP server

Page 14: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 201214

V2.0 API – Create Provider Network

POST /v2.0/networks

Request:

{ "name" : "net1_vlan29" “provider:phys_net”: “phys_net1” “provider:vlan_id”: 29}

Response:

{ "id": "98bd8391-199f-4440-824d-8659e4906786", "name": "net1_vlan29", "admin_state_up": True, "op_status": "ACTIVE", "tenant_id": "a4fc5328-c270-4891-845a-e61c9153d261", "subnets" : [], “provider:phys_net”: “phys_net1” “provider:vlan_id”: 29}

Page 15: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 201215

Multiple Networking Technologies

● Problem: What if data center includes multiple networking technologies (Linux bridging, OVS, UCS, VLAN, VXLAN, GRE)?

● Quantum only supports a single plugin

● Several options to consider:

● Use plugin that supports all the technologies you need● nicira & ryu plugins interface quantum to external virtual network controllers

● Deploy separate quantum service for each technology

● Enhance quantum to support multiple simultaneous plugins

● Meta-plugin that manages multiple standard Quantum plugins

● Modular plugin that uses drivers for different technologies

● Topic for next OpenStack Design Summit

Page 16: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 201216

Non-Uniform Connectivity

● Problem: What if not all compute nodes connect to the same physical networks?

● Not all virtual networks accessible to VMs on every node● Virtual networks accessible via different technologies at

different nodes

● Possible approaches:

● Model physical connectivity within Quantum API or API extension

● Assert equivalence of set of virtual networks● Tag virtual networks and/or nodes with metadata

representing connectivity zones

● Nova scheduler plugin aware of nodes' Quantum connectivity

Page 17: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 201217

Deployability

● Scalability

● Current agents periodically poll plugin DB via SQL● Replacing with openstack-common RPC in Folsom● Ensure Quantum server can be replicated

● Upgrades

● Support rolling upgrade of servers, nodes

● SLA / QoS

● Port mirroring

● IDS / IPS

● Debugging / Monitoring / Instrumentation

Page 18: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 201218

Summary

● Nova transitioning to use Quantum in Folsom

● Quantum being “completed” with L3 features● Integrations with Nova, Keystone, Horizon being improved

● Refinements needed for additional data center use cases

● Provider network support coming in Folsom● Multiple technologies, non-uniform connectivity to be

addressed later● Deployability improvements ongoing

● Questions?

Page 19: June Boston openStack Summit: Preparing quantum for the data center

Boston OpenStack User Group 201219

Contact Info

● Bob Kukura

● Email: [email protected]

● IRC: rkukura on freenode

● OpenStack in Fedora & EPEL

● http://fedoraproject.org/wiki/OpenStack

● http://fedoraproject.org/wiki/Getting_started_with_OpenStack_on_Fedora_17

● http://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL

● Red Hat Summit and JBoss World – Hynes Convention Center, June 26-29, 2012

● http://www.redhat.com/summit/

● Red Hat OpenStack Jobs

● https://careers-redhat.icims.com/jobs/search?searchKeyword=OpenStack


Recommended