Preparing Quantum for the                   Data CenterBob Kukura <rkukura@redhat.com>Boston OpenStack User GroupJune 21, ...
Agenda    ●   Red Hat + OpenStack Background    ●   Quantum Overview as of Essex    ●   Quantum in Folsom    ●   Data Cent...
Red Hat + OpenStack Background●   Red Hat involved with OpenStack since mid 2011     ●   Full-time [core] developers on mo...
Quantum Overview as of Essex●   OpenStack incubation project●   Layer 2 Virtual Networking Service     ●   Network – Isola...
V1.1 API – Create Network    POST /v1.1/tenants/XYZ/networks.json    Request:    {        "network":          {           ...
V1.1 API – Create Port    POST /v1.1/tenants/XYZ/networks/158233b0-ca9a-40b4-8614-54a4a99d47d1/ports.json    Request:    {...
V1.1 API – Attach VM Interface    PUT /v1.1/tenants/XYZ/networks/158233b0-ca9a-40b4-8614-54a4a99d47d1         /ports/98017...
Quantum in Folsom    ●   Core project         ●   May be default networking service for Nova, but legacy NetworkManagers s...
V2.0 API – Create Network    POST /v2.0/networks    Request:    {        "name" : "net1"    }    Response:    {        "id...
V2.0 API – Create Subnet     POST /v2.0/subnets     Request:     {         "network_id": "98bd8391-199f-4440-824d-8659e490...
V2.0 API – Create Port with Interface     POST /v2.0/ports     Request:     {         "network_id": "98bd8391-199f-4440-82...
Data Center Challenge     ●   Quantum currently assumes "green-field" cloud         deployment          ●   Uniform pool o...
Provider Networks     ●   Problem: How can VMs connect to existing data center networks         using Quantum?     ●   Sol...
V2.0 API – Create Provider Network     POST /v2.0/networks     Request:     {         "name" : "net1_vlan29"         “prov...
Multiple Networking Technologies     ●   Problem: What if data center includes multiple networking         technologies (L...
Non-Uniform Connectivity     ●   Problem: What if not all compute nodes connect to the         same physical networks?    ...
Deployability     ●   Scalability          ●   Current agents periodically poll plugin DB via SQL          ●   Replacing w...
Summary     ●   Nova transitioning to use Quantum in Folsom          ●   Quantum being “completed” with L3 features       ...
Contact Info     ●   Bob Kukura          ●   Email: rkukura@redhat.com          ●   IRC: rkukura on freenode     ●   OpenS...
Upcoming SlideShare
Loading in...5
×

June Boston openStack Summit: Preparing quantum for the data center

1,872
-1

Published on

Quantum, OpenStack's virtual networking service, is slated to replace Nova's networking service in the upcoming Folsom release. Initial Quantum development has focused on the basic requirements of a green-field Nova cloud deployment. Additional requirements will be discussed that enable Quantum to support private Nova cloud deployments within existing data centers, as well as enterprise virtualization with the oVirt project. Initial work is underway for Folsom, and additional work will follow.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,872
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
145
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

June Boston openStack Summit: Preparing quantum for the data center

  1. 1. Preparing Quantum for the Data CenterBob Kukura <rkukura@redhat.com>Boston OpenStack User GroupJune 21, 2012
  2. 2. Agenda ● Red Hat + OpenStack Background ● Quantum Overview as of Essex ● Quantum in Folsom ● Data Center Enhancements2 Boston OpenStack User Group 2012
  3. 3. 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 & globally3 Boston OpenStack User Group 2012
  4. 4. 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 IPAM4 Boston OpenStack User Group 2012
  5. 5. 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", } }5 Boston OpenStack User Group 2012
  6. 6. 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" } }6 Boston OpenStack User Group 2012
  7. 7. 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" } }7 Boston OpenStack User Group 2012
  8. 8. 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 integration8 Boston OpenStack User Group 2012
  9. 9. 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" : [], }9 Boston OpenStack User Group 2012
  10. 10. 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": [], }10 Boston OpenStack User Group 2012
  11. 11. 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", "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", }11 Boston OpenStack User Group 2012
  12. 12. 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 oVirt12 Boston OpenStack User Group 2012
  13. 13. 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 server13 Boston OpenStack User Group 2012
  14. 14. 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 }14 Boston OpenStack User Group 2012
  15. 15. 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 Summit15 Boston OpenStack User Group 2012
  16. 16. 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 connectivity16 Boston OpenStack User Group 2012
  17. 17. 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 / Instrumentation17 Boston OpenStack User Group 2012
  18. 18. 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?18 Boston OpenStack User Group 2012
  19. 19. 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=OpenStack19 Boston OpenStack User Group 2012
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×