O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Running Neutron at Scale - Gal Sagie & Eran Gampel - OpenStack Day Israel 2016

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 23 Anúncio

Running Neutron at Scale - Gal Sagie & Eran Gampel - OpenStack Day Israel 2016

Baixar para ler offline

For the past 2 years we’ve been working on running OpenStack in ever growing scales. In Juno we started Dragonflow, a Neutron integrated distributed SDN project with an ambitious goal – scaling to 10,000 physical servers in a single zone. Although we’re not there yet, we’re definitely on the right track.

Dragonflow employs the following principles

• Pluggable NoSQL DB – to adapt for different size deployments and SLAs

• Distribution of Policies rather than flows – moving the “brain” to the edges

• Distributed architecture – enforcing network policies in the compute nodes

• Hybrid flow pipeline – Utilizing both proactive and reactive flows to easily allow built-in distributed smart apps (e.g. distributed DHCP)

For the past 2 years we’ve been working on running OpenStack in ever growing scales. In Juno we started Dragonflow, a Neutron integrated distributed SDN project with an ambitious goal – scaling to 10,000 physical servers in a single zone. Although we’re not there yet, we’re definitely on the right track.

Dragonflow employs the following principles

• Pluggable NoSQL DB – to adapt for different size deployments and SLAs

• Distribution of Policies rather than flows – moving the “brain” to the edges

• Distributed architecture – enforcing network policies in the compute nodes

• Hybrid flow pipeline – Utilizing both proactive and reactive flows to easily allow built-in distributed smart apps (e.g. distributed DHCP)

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Running Neutron at Scale - Gal Sagie & Eran Gampel - OpenStack Day Israel 2016 (20)

Anúncio

Mais de Cloud Native Day Tel Aviv (20)

Mais recentes (20)

Anúncio

Running Neutron at Scale - Gal Sagie & Eran Gampel - OpenStack Day Israel 2016

  1. 1. Eran Gampel Gal Sagie Running Neutron At Scale
  2. 2. OpenStack Challenges • Scalability • Networking does not scale (<500 compute nodes) • Performance • Networking performance is low (namespace overhead, huge control plane overhead, …) • Operability • Reference implementation has lots of maintenance problems (e.g. thousands of concurrent DHCP servers, namespaces, etc.)
  3. 3. Network Node Compute Node DHCP Namespace Metadata Proxy Metdata Agent L2 Agent L3 Agent OVS DVR Namespaces Linux BridgeLinux BridgeLinux Bridge RPC VM Turning This… Controller Node
  4. 4. Compute Node Network Node OVS VM Controller Node Into This Dragonflow Controller
  5. 5. Dragonflow Highlights • Integral “Big Tent” project in OpenStack • Designed to Scale with High Throughput and Low Latency • Lightweight and Simple • Easily Extensible • Distributed SDN Control Plane Architecture • Focused on advanced networking services • Distributes Policy Level Abstraction to the Compute Nodes
  6. 6. 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 .. Distributed SDN
  7. 7. “Under The Hood” Compute NodeCompute NodeCompute Node Dragonflow Network DB OVS Neutron Server Redis OVSDB-Server ETCD RethinkDBRAMCloud Kernel Datapath Module NIC User Space Kernel Space DB Drivers Redis ETCD RethinkDBRMC Future Dragonflow Plugin Route Core API SG vswitchd Container VM Dragonflow Controller Abstraction Layer L2 App L3 App DHCP App FWaaS LBaaS …FIP/DNAT Pluggable DB Layer NBDBDrivers SB DB Drivers SmartNIC OVSDB ZooKeeper ETCD RMC Redis OpenFlow SG App ZooKeeper Zookeeper Pub/Sub Drivers Redis ØMQ
  8. 8. Current Release Features (Mitaka) L2 core API, IPv4, IPv6  GRE/VxLAN/STT/Geneve tunneling protocols Distributed L3 Virtual Router Distributed DHCP Pluggable Distributed Database  ETCD, RethinkDB, RAMCloud, Redis, ZooKeeper Pluggable Publish-Subscribe  ØMQ, Redis Security Groups  OVS Flows leveraging connection tracking integration Distributed DNAT Selective Proactive Distribution  Tenant Based
  9. 9. Pluggable 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
  10. 10. Distributed DB DB Data 3 DB Data 2 DB Data 1 Full Distribution Compute Node 1 Dragonflow Local Cache OVS Compute Node N Dragonflow OVS Local Cache Dragonflow DB Drivers Redis ETCD ZookeeperRMC DB Data 3 DB Data 2 DB Data 1 DB Data 3 DB Data 2 DB Data 1
  11. 11. Distributed Database DB Data 3 DB Data 2 DB Data 1 Selective 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 Redis ETCD ZookeeperRMC
  12. 12. Compute Node Dragonflow Local Controller Subscriber Redis ØMQ Compute Node Dragonflow Local Controller Subscriber Redis ØMQ Compute Node Dragonflow Local Controller Subscriber Redis ØMQ Compute Node Dragonflow Local Controller Subscriber Redis ØMQ Neutron Server Dragonflow Plugin Publisher Redis ØMQ Neutron Server Dragonflow Plugin Publisher Redis ØMQ Neutron Server Dragonflow Plugin Publisher Redis ØMQ . . . DB . . . Pluggable Pub/Sub
  13. 13. Example Distributed DHCP Page 13
  14. 14. 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
  15. 15. 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 Distributed DB
  16. 16. Roadmap
  17. 17. Dragonflow ScalabilityScale (# Compute Nodes) today 10,000 2,500 Time to Market n+2 1,000 Dragonflow & Redis Dragonflow & RAMCloud & ØMQ Optimized Hybrid (Reactive/Proactive) Dragonflow 4,000 n+1soon
  18. 18. Roadmap Additional DB Drivers ZooKeeper, Redis… Selective Proactive DB Pluggable Pub/Sub Mechanism DB Consistency Distributed DNAT Security Group New Applications Hierarchical Port Binding (SDN ToR) move to ML2 Containers (Kuryr plugin and nested VM support) Topology Service Injection / Service Chaining Inter Cloud Connectivity (Border Gateway / L2GW) Optimize Scale and Performance
  19. 19. Rack ToR Overlay Virtual Topology Underlay Hardware DB Core RouterODL Neutron Server ML2 Mechanism Drivers ODLDragonflow Hierarchical Network Management
  20. 20. Newton Release New Applications  IGMP Application  Distributed Load Balancing (East/West)  Brute Force prevention  DNS service  Distributed Metadata proxy  Port Fault Detection
  21. 21. Dragonflow and Containers
  22. 22. Network Services
  23. 23. Ride the Dragon! • 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)

Notas do Editor

  • 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

×