June Boston openStack Summit: Preparing quantum for the data center

Preparing Quantum for the
Data Center
Bob Kukura <rkukura@redhat.com>

Boston OpenStack User Group
June 21, 2012

Agenda
● Red Hat + OpenStack Background
● Quantum Overview as of Essex
● Quantum in Folsom
● Data Center Enhancements

2 Boston OpenStack User Group 2012

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


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

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",
}
}


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"
}
}


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"
}
}


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

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" : [],
}


V2.0 API – Create Subnet
POST /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": [],
}

V2.0 API – Create Port with Interface
POST /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",
"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",
}


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


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


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",
"tenant_id": "a4fc5328-c270-4891-845a-e61c9153d261",
"subnets" : [],
“provider:phys_net”: “phys_net1”
“provider:vlan_id”: 29
}

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


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

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


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?


Contact Info
● Bob Kukura
● Email: rkukura@redhat.com
● 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


June Boston openStack Summit: Preparing quantum for the data center

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to June Boston openStack Summit: Preparing quantum for the data center (20)

More from Kamesh Pemmaraju (20)

Recently uploaded (20)

June Boston openStack Summit: Preparing quantum for the data center