OpenStack Dragonflow shenzhen and Hangzhou meetups
•Télécharger en tant que PPTX, PDF•
0 j'aime•554 vues
Slide for the shenzhen and Hangzhou mid cycle meetups for Dragonflow Distributed SDN Controller for OpenStack Neutron
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à OpenStack Dragonflow shenzhen and Hangzhou meetups
Similaire à OpenStack Dragonflow shenzhen and Hangzhou meetups (20)
Dernier
Dernier (20)
OpenStack Dragonflow shenzhen and Hangzhou meetups
- 1. Dragonflow Shenzhen OpenStack meet-up Ayal Baron Eran Gampel
- 2. Dragonflow Page 2 • Integral part of OpenStack • Fully Open Source • Scale, Performance and Latency • Lightweight and Simple • Easily Extendable • Distributed SDN Control Plane • Sync Policy Level abstraction to the CN
- 3. Dragonflow - Distributed SDN Neutron-Server Dragonflow Plugin DB OVS Dragonflow DB Driver Compute Node OVS Dragonflow DB Driver Compute Node OVS Dragonflow DB Driver Compute Node OVS Dragonflow DB Driver Compute Node DB VM VM .. VM VM .. VM VM .. VM VM ..
- 4. Compute NodeCompute NodeCompute Node Dragonflow Network DB OVS Neutron Server OVSDB OVSDB-Server ETCD RethinkDBRAMCloud Kernel Datapath Module NIC User Space Kernel Space Dragonflow DB Drivers OVSDB ETCD RethinkDBRMC Future Dragonflow Plugin Route Core API SG vswitchd Container VM Dragonflow Controller Abstraction Layer L2 App L3 App DHCP App Fault Detection SG LBaaS …FWaaS Pluggable DB Layer NBDBDrivers SB DB Drivers smartNIC OVSDB OVSDB ETCD RMC RethinkDB OpenFlow Dragonflow – Under The Hood
- 5. Current Release Features (Liberty) L2 core API, IPv4, IPv6 GRE/VxLAN/Geneve tunneling protocols Distributed L3 Virtual Router Hybrid proactive + reactive flow installation North-South traffic is still centralized Distributed DHCP (with just 500 lines of code!) Pluggable Distributed Database ETCD, RethinkDB, RAMCloud, OVSDB
- 7. Network Node DHCP namespace DHCP namespace DHCP namespace DHCP namespace Neutron DHCP Implementation DHCP namespace dnsmasq DHCP Agent Neutron Server Message Queue Example • 100 Tenants • 3 vNet / tenant = 300 DHCP Servers
- 8. 1 VM Send DHCP_DISCOVER 2 Classify Flow as DHCP, Forward to Controller 3 DHCP App sends DHCP_OFFER back to VM 4 VM Send DHCP_REQUEST 5 Classify Flow as DHCP, Forward to Controller 6 DHCP App populates DHCP_OPTIONS from DB/CFG and send DHCP_ACK Dragonflow Distributed DHCP VM DHCP SERVER 1 3 4 6 7 Compute Node Dragonflow VM OVS VM 1 2 br-int qvoXXX qvoXXX OpenFlow 1 4 2 5 7 Dragonflow Controller Abstraction Layer L2 App L3 App DHCP App SG 36 Pluggable DB Layer DB
- 9. Dragonflow Distributed DHCP Match: Broadcast +UDP +S_Port=68 +D_Port=67 Action: Send to DHCP table Service Table DHCP Table Match: in_port => Action: Set metadata with port unique key SEND TO CONTROLLER (for every local port that its network has DHCP enabled) Default: goto “L2 Lookup Table” Compute Node VM OVS br-int qvoXXX VM qvoXXX 1 2 Dragonflow Dragonflow Local Controller Abstraction Layer L2 App L3 App DHCP App SG DB OpenFlow Ingress Port Security Ingress Classification Dispatch to Ports
- 11. Database Framework Requirements • HA + Scalability • Different Environments have different requirements • Performance, Latency, Scalability, etc. Why Pluggable? • Long time to productize • Mature Open Source alternatives • Allow us to focus on the networking services only
- 12. DB Driver API Implementations RAMCloud ETCD RethinkDB Zookeeper Dragonflow Pluggable Database Compute NodeCompute NodeCompute Node Dragonflow Local Controller Pluggable DB Layer Applicative DB Layer Adapter DB Driver API Expose DB Features Neutron Server Dragonflow Neutron Plugin DB Operations Database Server DB Adapter DB Adapter DB Adapter
- 13. Distributed Database DB Data 3 DB Data 2 DB Data 1 Full Distribution Compute Node 1 Dragonflow Local Cache OVS DB Data 1 Compute Node N Dragonflow OVS Local Cache DB Data 3 DB Data 2 Dragonflow DB Drivers OVSDB ETCD RethinkDBRMC
- 14. Selective Proactive Distribution Compute Node 1 Dragonflow Local Cache OVS Net1 – VM1, VM2 Compute Node 2 Dragonflow OVS Local Cache Net2 – VM3, VM4 VM1 VM2 VM3 VM4 RethinkDB Net2 – VM3, VM4 Net1 – VM1, VM2
- 16. Roadmap Distributed DNAT Security Group Selective Proactive DB Containers (Kuryr plugin and nested VM support) Hierarchical Port Binding (SDN ToR) move to ML2 Pluggable Pub/Sub Mechanism Additional DBs Drivers ZooKeeper, Redis … Topology Service Injection / Service Chaining Inter Cloud Connectivity (Boarder Gateway / L2GW) …
- 18. DragonFlow Pipeline Installed in every OVS Service Traffic Classification Ingress Processing (NAT, BUM) ARP DHCP L2 Lookup L3 Lookup DVR Egress Dispatching outgoing traffic to external nodes or local ports Ingress Port Security (ARP spoofing , SG, …) Egress Port Security Egress Processing (NAT) Fully Proactive Has Reactive Flows to Controller Security Groups … Outgoing from local port Classification and tagging Dispatching Incoming traffic from external nodes to local ports
- 19. Dragonflow for Containers Architecture Blueprint
- 20. Project Kuryr and Dragonflow Dragonflow Plugin
- 21. Compute Node Mixed OpenStack Environments VM Dragonflow Controller OVS(Controller: Dragonflow) VM OVS Neutron network 1 Neutron network 2 Neutron network 3
- 23. Join the project Dragonflow • Documentation https://wiki.openstack.org/wiki/Dragonflow • Bugs & blueprints https://launchpad.net/dragonflow • DF IRC channel #openstack-dragonflow Weekly on Monday at 0900 UTC in #openstack-meeting-4 (IRC)
Notes de l'éditeur
- Why is this a good thing? Common Applicative DB Adapter Layer Same layer is used by all clients Dragonflow Neutron plugin Dragonflow local controller External/Internal applications Expressed in terms of the schema model Converts model to “Key / Value” Calls the DB Driver API for DB Operations Leverage DB advance features Knows to receive and wait for DB changes According to a pre defined generic API with the driver Selective publish-subscribe
- Each local controller sync only relevant data according to its local ports Depends on the virtual topology Local controller gets all local ports information DB framework must support waiting for changes on specific entry column values The plugin tags the related objects with a special column value Reduce the sync load and change rate Each local controller only gets the subset of the data that is relevant for it
- Each local controller sync only relevant data according to its local ports Depends on the virtual topology Local controller gets all local ports information DB framework must support waiting for changes on specific entry column values The plugin tags the related objects with a special column value Reduce the sync load and change rate Each local controller only gets the subset of the data that is relevant for it