OpenStack and OpenDaylight Workshop: ONUG Spring 2014

12,832 views

Published on

This was a presentation I gave at the Open Networking Users Group (ONUG), Spring 2014. This talk covers some background on OpenStack and OpenDaylight, walks through Group Based Policy and OpFlex, and ends with a tutorial walk through of installing and using OpenStack with OpenDaylight.

Published in: Technology
  • Be the first to comment

OpenStack and OpenDaylight Workshop: ONUG Spring 2014

  1. 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. 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. 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
  4. 4. OpenStack Overview
  5. 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. 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. 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
  8. 8. Networking in OpenStack …
  9. 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. 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. 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. 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. 13. A special note on OpenStack Neutron ML2
  14. 14. What is Modular Layer 2 (ML2)? Neutron ML2 Plugin Network OVS LinuxBridge Vendor X Vendor YHyper-V
  15. 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. 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
  17. 17. OpenDaylight Overview
  18. 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. 19. * What is OpenDaylight building? *
  20. 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. 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. 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. 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
  24. 24. OpenStack Neutron Integration with OpenDaylight
  25. 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. 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. 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. 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
  29. 29. Quick Overview of Group Based Policy
  30. 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. 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
  32. 32. 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.
  33. 33. OpenDaylight OpFlex Architecture
  34. 34. 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
  35. 35. 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
  36. 36. Workshop Walkthrough
  37. 37. 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
  38. 38. Logistics • The Fedora20 VM has the following information: • Users: • root/password • odl/odl • Setup for DHCP for the image itself.
  39. 39. 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.
  40. 40. 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
  41. 41. Browse to your ODL Window over HTTP
  42. 42. 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
  43. 43. Your devstack will look like this
  44. 44. Login to Horizon (go to the IP of your control node)
  45. 45. Login as (admin/ad min) to see the Horizon Dashboard
  46. 46. Spinup a VM
  47. 47. Spinup a VM (cont.)
  48. 48. Instance is now booted
  49. 49. Repeat process for a second VM
  50. 50. Checkout OpenDaylight Web GUI
  51. 51. Ping test between VMs
  52. 52. Thank You!
  53. 53. 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
  54. 54. 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
  55. 55. 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

×