![OpenStack Integration: Status
• ML2 Driver available in Icehouse release!
• Supports VXLAN and GRE tunnel networks
• devstack support merged upstream
• Run OpenDaylight as a top-level service in devstack!
• OpenStack Neutron API Service available now in OpenDaylight
o provides Neutron API handling for multiple implementations
• Initial ML2 plugin focused on core Neutron functionality
o Still uses Neutron [DHCP, L3] agents](https://image.slidesharecdn.com/openstackandodlonug-140507143644-phpapp02/85/OpenStack-and-OpenDaylight-Workshop-ONUG-Spring-2014-25-320.jpg)
![Common Problems
• Remove devstack/local.conf before stacking
• Copy in local.conf.[control,compute] fresh
• Edit as appropriate
• Problem: OVS not running after reboot
• Solution: sudo systemctl restart openvswitch
• Make sure you have a default GW configured correctly
• Possible solution: sudo route add default gw 192.168.1.1
• There are two interfaces on the guest VM
• If you run into issues, bring down eth1
• Edit /etc/sysconfig/network-scripts/ifcfg-eth1](https://image.slidesharecdn.com/openstackandodlonug-140507143644-phpapp02/85/OpenStack-and-OpenDaylight-Workshop-ONUG-Spring-2014-55-320.jpg)
OpenStack and OpenDaylight Workshop: ONUG Spring 2014
- 1. OpenStack and OpenDaylight: Overview and Workshop Kyle Mestery OpenStack Neutron PTL OpenDaylight OVSDB Project Developer Open vSwitch Committer Principal Engineer, Cisco mestery@mestery.com @mestery
- 2. What Will I Learn During This Workshop? • A high level overview of OpenStack Neutron • A high level overview of OpenDaylight • A quick overview on Group Based Policy in both projects • How OpenStack Neutron and OpenDaylight integrate together • How to bring up a multi-node OpenStack environment • How to use OpenDaylight for virtual networks with OpenStack Neutron
- 3. For Advanced Users • Feel free to take the image for a spin during my presentation! • If you hit any issues, we’ve got you covered! • Hop onto #opendaylight-ovsdb on Freenode • A fine selection of Open Source engineers will assist you with any questions
- 5. OpenStack: The Open Source Cloud Platform Compute (Nova) Self-service provisioning of virtual machines through a software API Object Storage (Swift) Massively scalable, distributed object store Network Service (Neutron) For tenant created, virtual isolated networks and subnets, and services Your Application
- 6. OpenStack continues to build services which abstract infrastructure and provide highly scalable utilities through REST APIs, command tools and user portals Every 6 month release, new services are added: moving quickly into auto-scaling, app orchestration, and network services Compute (VM provisioning) Networking (Virtual, Physical) Storage (Object) Identity/Authentication VM Image Catalog User/Admin Portal Metering (Ceilometer) Storage (Block) Orchestration (HEAT) Networking Services (LB, FW, VPN, IDS..) API’s - API’s
- 7. OpenStack Community Releases (started October 2010 – 6 month release cycle) Austin – October 2010 • Initial Release • Compute (dev) • Object Storage Bexar– February 2011 • Second Release • Compute – prod ready Diablo – September 2011 • First “production-ready” release • Initial deployments Essex– April 2012 • Identity, Dashboard • Quantum incubation Catus – April 2011 • Multi-hypervisor • KVM/QEMU, Xen Folsom – October 2012 • Quantum core • Cinder block storage Grizzly– April 2013 • Metering, Orchestration, Bare metal, LBaaS Havana – October 2013 • L3 Network services • (planned) 2011 2012 2013 2014 Icehouse– April 2014 • Stability • Test coverage gaps
- 9. Neutron Network Service - OpenStack Design Summit,April 2011 • 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 (Neutron): virtual networks • Create/delete private network • Attach VM to network resource • Maintain compatibility with Nova networking model • Work with different networking environments • Capabilities • Routing • IP address management • Service attachment App Svr OS VM App Svr OS VM App Svr OS VM
- 10. OpenStack Portal gives each user a view of their own network topology (vm’s, subnets, routers) Cisco developed visual interface for network containers
- 11. OpenStack Use Cases – going beyond public cloud service providers • On premise, private cloud • Large scale consumer-facing web applications/services • Media companies • Storage • Mobile packet core • Turn infrastructure into a set of services (FWaaS, LBaaS) • NFV, elastic network services • Span multiple data centers and service providers • Big data analytics with optimized networking • Bare metal provisioning using a “cloud-like” API
- 12. OpenStack’s design principle is to be built as a set of loosely coupled, but related projects developing advanced cloud services Neutron networking Nova compute Glance image Keystone security Incubated Projects Horizon web interface Swift storage • Covers compute, storage and networking • Used to build “public” or “private” clouds • Each service is driven by community projects with contributions from many companies • Easier for innovation through adding new services • Small number of core services – larger number of associated services
- 13. A special note on OpenStack Neutron ML2
- 14. What is Modular Layer 2 (ML2)? Neutron ML2 Plugin Network OVS LinuxBridge Vendor X Vendor YHyper-V
- 15. ML2 Use Cases • Replaces existing monolithic plugins, eases development of new plugins • Eliminates redundant code • Reduce development and maintenance effort • New features • Top-of-Rack switch control • Avoid tunnel flooding via L2 population • Modular Agents • Heterogeneous deployments • Specialized hypervisor nodes with distinct network mechanisms • Integrate *aaS appliances • Roll new technologies into existing deployments
- 16. ML2 Architecture Diagram Neutron Server ML2 Plugin Type Manager Mechanism Manager API Extensions GRE TypeDriver Arista VLAN TypeDriver VXLAN TypeDriver Cisco Nexus Hyper-V L2 Population Linuxbridge Open vSwitch Tail-FNCS
- 18. What is OpenDaylight? OpenDaylight is an Open Source Software project under the Linux Foundation with the goal of furthering the adoption and innovation of Software Defined Networking (SDN) through the creation of a common industry supported platform Code Acceptance Community To create a robust, extensible, open source code base that covers the major common components required to build an SDN solution To get broad industry acceptance amongst vendors and users • Using OpenDaylight code directly or through vendor products •Vendors using OpenDaylight code as part of commercial products To have a thriving and growing technical community contributing to the code base, using the code in commercial products, and adding value above, below and around.
- 19. * What is OpenDaylight building? *
- 20. Base Network Service Functions Management GUI/CLI Controller Platform Southbound Interfaces & Protocol Plugins OpenDaylight APIs (REST) DOVE Mgr Data Plane Elements (Virtual Switches, Physical Device Interfaces) Service Abstraction Layer (SAL) (plug-in mgr., capability abstractions, flow programming, inventory, …) OpenFlow 1.0 1.3 LISP Topology Mgr Stats Mgr Switch Mgr Host Tracker Shortest Path Forwarding VTN Coordinator Affinity Service Network Applications Orchestration & Services OpenStack Neutron OpenFlow Enabled Devices VTN Manager VTN: Virtual Tenant Network DOVE: Distributed Overlay Virtual Ethernet DDoS: Distributed Denial Of Service LISP: Locator/Identifier Separation Protocol OVSDB: Open vSwitch DataBase Protocol BGP: Border Gateway Protocol PCEP: Path Computation Element Communication Protocol SNMP: Simple Network Management Protocol LISP Service NETCONF BGP-LS Additional Virtual & Physical Devices Hydrogen Release (Jan 2014) SNMP DDoS Protection Open vSwitches OVSDB PCEP OpenStack Service Network Config
- 21. Base Network Service Functions Management GUI/CLI Controller Platform Southbound Interfaces & Protocol Plugins OpenDaylight APIs (REST) Data Plane Elements (Virtual Switches, Physical Device Interfaces) Service Abstraction Layer (SAL) (plug-in mgr., capability abstractions, flow programming, inventory, …) OpenFlow 1.0 1.3 Topology Mgr Stats Mgr Switch Mgr Host Tracker Shortest Path Forwarding Network Applications Orchestration & Services OpenFlow Enabled Devices VTN: Virtual Tenant Network DOVE: Distributed Overlay Virtual Ethernet DDoS: Distributed Denial Of Service LISP: Locator/Identifier Separation Protocol OVSDB: Open vSwitch DataBase Protocol BGP: Border Gateway Protocol PCEP: Path Computation Element Communication Protocol SNMP: Simple Network Management Protocol NETCONF Additional Virtual & Physical Devices Base Edition Open vSwitches Network Config
- 22. Base Network Service Functions Management GUI/CLI Controller Platform Southbound Interfaces & Protocol Plugins OpenDaylight APIs (REST) Data Plane Elements (Virtual Switches, Physical Device Interfaces) Service Abstraction Layer (SAL) (plug-in mgr., capability abstractions, flow programming, inventory, …) OpenFlow 1.0 1.3 LISP Topology Mgr Stats Mgr Switch Mgr Host Tracker Shortest Path Forwarding Affinity Service Network Applications Orchestration & Services OpenFlow Enabled Devices VTN: Virtual Tenant Network DOVE: Distributed Overlay Virtual Ethernet DDoS: Distributed Denial Of Service LISP: Locator/Identifier Separation Protocol OVSDB: Open vSwitch DataBase Protocol BGP: Border Gateway Protocol PCEP: Path Computation Element Communication Protocol SNMP: Simple Network Management Protocol LISP Service NETCONF BGP-LS Additional Virtual & Physical Devices Service Provider Edition SNMP DDoS Protection Open vSwitches PCEP Network Config
- 23. Base Network Service Functions Management GUI/CLI Controller Platform Southbound Interfaces & Protocol Plugins OpenDaylight APIs (REST) DOVE Mgr Data Plane Elements (Virtual Switches, Physical Device Interfaces) Service Abstraction Layer (SAL) (plug-in mgr., capability abstractions, flow programming, inventory, …) OpenFlow 1.0 1.3 Topology Mgr Stats Mgr Switch Mgr Host Tracker Shortest Path Forwarding VTN Coordinator Affinity Service Network Applications Orchestration & Services OpenStack Neutron OpenFlow Enabled Devices VTN Manager VTN: Virtual Tenant Network DOVE: Distributed Overlay Virtual Ethernet DDoS: Distributed Denial Of Service LISP: Locator/Identifier Separation Protocol OVSDB: Open vSwitch DataBase Protocol BGP: Border Gateway Protocol PCEP: Path Computation Element Communication Protocol SNMP: Simple Network Management Protocol NETCONF Additional Virtual & Physical Devices Virtualization Edition DDoS Protection Open vSwitches OVSDB OpenStack Service Network Config
- 25. OpenStack Integration: Status • ML2 Driver available in Icehouse release! • Supports VXLAN and GRE tunnel networks • devstack support merged upstream • Run OpenDaylight as a top-level service in devstack! • OpenStack Neutron API Service available now in OpenDaylight o provides Neutron API handling for multiple implementations • Initial ML2 plugin focused on core Neutron functionality o Still uses Neutron [DHCP, L3] agents
- 26. OpenStack/OpenDaylight Integration Neutron Node Compute Node OpenDaylight Node Network Node Neutron Server ML2 Plugin w/ OpenDaylight Driver OpenDaylight Server Neutron API Service OVSDB Plugin OVS VM1 VM2 OVS L3 Agent DHCP Agent REST API RPC OpenFlow & OVSDB
- 27. OpenStack Integration: Next Steps • Updates planned for Helium and Juno: • VIF plugging changes for stability improvements • Notify from ODL to MechanismDriver once ODL has setup the port on the host • Security groups implemented using OpenFlow rules • L3 routing handled by OpenDaylight • Removes the need for the L3 agent • Additional refinements and bug fixes
- 28. OpenVSwitch OVSDB Protocol Library Bidirectional JSON-RPC Library Netty.io Configuration Service Inventory Service API Driven SAL (ADSAL) OpenFlow 1.0 Plugin OpenFlow 1.0 Library Connection Service Flow Programmer java.nio.socket Model Driven SAL (MDSAL) Inventory Service Connection Service Flow Programmer OpenFlow 1.3 Plugin OpenFlow 1.3 Library Netty io OVSDB South-bound Plugin OpenFlow 1.0 SB Plugin OpenFlow 1.3 SB Plugin Controller Neutron ML2 Plug-In OpenDaylight NorthBound API Layer - REST APIs OpenDaylight Neutron REST-API OVSDB Neutron Application OpenFlow 1.0
- 30. What is Group Based Policy? • GBP introduces the notion of groups of endpoints and policy abstractions governing communication between these groups • Northbound API which accepts abstract policy based on application requirements • Multiple southbound implementations for programming network elements • GBP is a project in both OpenStack Neutron and OpenDaylight • Incubated project in ODL • BP accepted for Juno in OpenStack Neutron
- 31. Group Based Policy Goals • Fundamentally change how applications interface with the network • Instead of dealing with network constructs (networks, subnets, ports, routes), applications can deal with their intent in a declarative manner • Provide application oriented interfaces to OpenStack Neutron and OpenDaylight • Provide a simpler interface and abstractions for applications • Allow for easier consumption of resources by applications
- 33. OpFlex Overview What exactly is OpFlex? • The OpFlex Architecture Provides a distributed control system based on a declarative policy information model. • An incubated project in OpenDaylight consisting of three things: The OpFlex protocol, the OpFlex SB plugin, and the OpFlex Policy Agent.
- 35. Group Based Policy in the Open Source Community Group Policy API1 2 3 OpFlex Agent Group Policy API OpFlex Southbound Plugin Contributors Contributors Contributors Group Based Policy Information Model OpFlex Agent Framework
- 36. How to get involved … https://wiki.opendaylight.org/view/OpFlex:Main https://wiki.opendaylight.org/view/Group_Policy:Main #opendaylight-opflex on Freenode #opendaylight-group-policy on Freenode
- 38. What You Will Need • OpenDaylight Virtualization Edition with OVSDB • Can be in a VM or on your laptop directly • Download Link • Two or more OpenStack Nodes • One node running control software and optionally compute services • One or more compute nodes
- 39. Logistics • The Fedora20 VM has the following information: • Users: • root/password • odl/odl • Setup for DHCP for the image itself.
- 40. Boot Your VM Images • Boot the VM which you will run OpenDaylight inside of. • Optionally bring-up OpenDaylight on your laptop natively. • This will work in either scenario. • Verify IP addresses on your VMs (may require reboots). • This should be done for all VMs. • This may change once you import the OVF file.
- 41. OpenStack VM Setup • Copy the VM image twice: • Once for control and once for compute • On both nodes: • Update your networking • The setup assumes eth0 as a NAT interface for external access, and eth1 on a private host only network for communication between the nodes. • On the control node: • Login as odl/odl • Copy local.conf.control to devstack/local.conf • Edit devstack/local.conf and change IP addresses • On the compute node: • Login as odl/odl • Copy local.conf.compute to devstack/local.conf • Edit devstack/local.conf and change IP addresses
- 42. Browse to your ODL Window over HTTP
- 43. Boot Up Your OpenStack Instances • Control Node: • cd devstack • ./stack.sh • Compute Node: • cd devstack • ./stack.sh • If you hit issues … • Troubleshooting guide at the end of this slide deck
- 44. Your devstack will look like this
- 45. Login to Horizon (go to the IP of your control node)
- 46. Login as (admin/ad min) to see the Horizon Dashboard
- 47. Spinup a VM
- 49. Instance is now booted
- 50. Repeat process for a second VM
- 51. Checkout OpenDaylight Web GUI
- 52. Ping test between VMs
- 53. Thank You!
- 54. Troubleshooting The following slides all provide some general troubleshooting advice for the image provided on the USB keys and available for download here: https://wiki.opendaylight.org/images/HostedFiles/Fedora20_ODL_OpenStack.zip
- 55. Common Problems • Remove devstack/local.conf before stacking • Copy in local.conf.[control,compute] fresh • Edit as appropriate • Problem: OVS not running after reboot • Solution: sudo systemctl restart openvswitch • Make sure you have a default GW configured correctly • Possible solution: sudo route add default gw 192.168.1.1 • There are two interfaces on the guest VM • If you run into issues, bring down eth1 • Edit /etc/sysconfig/network-scripts/ifcfg-eth1
- 56. Volume problems A volume group called stack-volumes already exists. • Two solutions: • Restack • ./unstack.sh • ./stack.sh • Delete the volume file and remove the VG • sudo rm -rf /opt/stack/data/stack-volumes-backing-file • sudo vgchange -a n stack-volumes && sudo vgremove stack-volumes
Editor's Notes
- #8: Forrester predicts that in 2014, OpenStack APIs will become the 4th standard.OpenStack has crossed the threshold and will become another de facto IaaS standard before the end of the year, when OpenStack compatibility will be a must, not a nice-to-have.” (Source: Forrester Research, Inc., State Of Cloud Platform Standards: Q1 2014, March 2014).
- #12: OpenNFVMoving beyond public cloud
- #15: A Neutron core plugin in Havana and IcehouseModularDrivers for layer 2 network types and mechanisms interface with agents, hardware, controllers, …Works with existing L2 agentsopenvswitchlinuxbridgehypervDeprecates existing monolithic pluginsopenvswitchlinuxbridge
- #27: OpenDaylight exposes a single common NB interface for all SB usersAPI exposed matches Neutron API 1:1Multiple implementations in ODLODL Plugin in Neutron passes information throughMoves complexity to ODL (scaling, etc.)