Neutron internals and future plans

Transcript

1. Neutron internals and future plans Rossella Sblendido Ildikó Vancsa
2. When you hear the word Neutron... 1) 2) 3)
3. History
4. What is Neutron anyway? • Neutron − API exposing logical abstractions for consuming the networking service − One or more backend implementations of that API • Why? − Networking constructs baked into Nova (OpenStack compute) − No tenant control over network topology and service insertion − Multi-tenancy and scalability
5. • Modular Architecture − Plugin: custom back-end implementation of the Networking API − Neutron-server: exposes the API − Several agents (L2, L3, DHCP, Metadata, etc) Neutron architecture
6. • Monolithic plugin (direct control of core resources) • ML2 − Modular, delegates calls to proper drivers − Two kind of drives: • Type drivers (support specific network type) • Mechanism drivers (ensure the information established by the TypeDriver is properly applied) − 2 default implementations: OpenVSwitch and LinuxBridge Neutron Plugin
7. Different kinds of nodes
8. • Runs on hypervisor (compute node) • Configure the local vswitch • Communicates with the server over RPC • Wires new devices • Security Group Rules L2 Agent
9. • Provides L3/NAT • Runs network node • Uses namespaces • External network access L3 Agent
10. • Provides DHCP services • Communication over RPC • Isolation through namespaces • dnsmasq DHCP Agent
11. • Proxies Metadata requests to Nova • Routed Networks − Process embedded in router • Non-routed Networks − Static routes redirect traffic running in the DHCP namespace Metadata Agent
12. • Flat (no segmentation) • VLAN • Tunnels (GRE or VXLAN) How is traffic isolation achieved?
13. Neutron with OVS
14. Neutron with LinuxBridge
15. Telecom/NFV demands and Neutron • Reliability • Plannability • Performance ◦ Bandwidth ◦ Real-time-ness • QoS • SR-IOV
16. • VMs are able to send/receive tagged traffic • Motivations: ◦ Be able to connect to lots of networks ◦ Handle containers traffic ◦ Be compatible with legacy applications that expect to use VLANs ◦ New entities: ▪ Trunk port ▪ Sub port https://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html VLAN aware VMs
17. VM with a subport with seg ID 10
18. QoS - Minimum bandwidth support • Guaranteed minimum bandwidth • Egress traffic • Needs scheduling improvements ◦ No overcommitting of the physical interface https://bugs.launchpad.net/neutron/+bug/1560963 https://bugs.launchpad.net/neutron/+bug/1578989
19. QoS - Ingress bandwidth limiting • Noisy neighbors on the consumer side • CSP’s to ◦ plan and allocate bandwidth to customers ◦ Provide different levels of network services • Bandwidth limiting rules got a direction field ◦ By default set to egress (original functionality) • OVS Agent support is in progress https://blueprints.launchpad.net/neutron/+spec/instance-ingress-bw-limit
20. OVS + SR-IOV • SR-IOV accelerated OVS ◦ Better performance ◦ Same core functionality • Kernel support is in place from version 4.8 ◦ SW representation mode ◦ Allows to offload SW switch traffic rules to the HW e- switch • OVS support is in progress • Neutron status is dependent on the OVS upstream progress https://bugs.launchpad.net/neutron/+bug/1627987
21. QinQ • Adding QinQ to the supported network types • OVS QinQ support ◦ Related patches are merged upstream ◦ Will be released in August (version 2.8) • Neutron implementation is in progress • Adds support for vlan-transparent networks in the OVS ML2 driver https://review.openstack.org/#/c/446047/ https://bugs.launchpad.net/neutron/+bug/1604222
22. 谢谢