Using OpenDaylight in Hybrid Cloud: issues or challenges Yi Yang @ Inspur.com

New Trends in Cloud VMs, Containers and Baremetals coexist Using containers for elastic scale-in and scale-out, self-healing, automated replication Meet 3-layer application scenarios: frontend:web services, middleware:Java application, backend: database system Kubernetes is very popular, but not all the applications can be split into microservices. Some applications prefer to run in baremetal for performance. Openstack over kubernetes: Openstack infrastructure runs in containers What CNI plugin is selected will impact on Opendaylight and Openstack integration less or more

Issue/Challenge #1: How to unify networking Containers, VMs and baremetals had better use unified networking solution Opendaylight seems one not-bad choice for this: networking-odl for Openstack, kuryr-kubernetes for Kubernetes, Opendaylight also can leverage networking-l2gw and ovsdb to manage ToR switch for VMs and Baremetals interconnection. But Opendaylight is not ready for this: other issues and challenges…

Issue/Challenge #2: How to manage ToR switches Many ToR switches can’t support ovsdb Opendaylight only can support ovsdb to manage ToR switch, just in test phase, not ready for production environment ToR switch has limit, maximal number of VXLAN VTEPs is small, it is 64 in our switch case, far from enough.

Issue/Challenge #3: How to Run Opendaylight in pod/containers Split Opendaylight into many small microservices: lighty.io, opendaylight-simple, strongly call Opendaylight community to take actions towards this direction, it is a very big big challenge. Standalone Opendaylight is a monster, very slow startup, occupy huge amount of memory, it is much much slower than VM launching, let alone container Deploy, online upgrade, etc…

Issue/Challenge #4: How to integrate with kata container In public cloud scenario, native container can’t meet multi-tenancy isolation, VM-level isolation is must-have. i.e. run container in lightweight VM, but container and its host VM are scheduled as a container by kubernetes. It is a challenge to use vhost/vhostuser for kata container (it is veth pair by default), it is very important for OVS DPDK case because veth performance is very very poor in OVS DPDK.

Present Future

Issue/Challenge #5: How to Use Opendaylight to control all the switches in leaf spine architecture SDN controller is a necessary requirement in private cloud tenders It will be better if Opendaylight can configure switches in leaf and spine, it is one factor why customers want to deploy SDN controller I propose Opendaylight can launch a new project which can create a switch configuration abstract layer (like SoNiC: https://azure.github.io/SONiC/), I believe switch vendors would like to add support for their switches by themselves.

Issue/Challenge #6: Is Centralized SDN controller model best in super scale data center Packet-in, Packet-out OVN model seems counter-example Cascaded SDN Controllers are typical use case to break such limitation

Issue/Challenge #7: How to support hierarchical port binding and EVPN VXLAN VTEP is handled in ToR switch in layer 3 leaf spine architecture EVPN is must-have in this case. Neutron ML2 plugin is needed to support hierarchical port binding HPB Networks:  Provide VXLAN scale with VLAN type host complexity  Encapsulation done on network edge in wire speed But Opendaylight can’t handle this case

Neutron Hierarchical Port Binding Each Port can be bound against mutilple segments, dependant on the binding host. It needs special ML2 mechanism driver.

Issue/Challenge #8: How to visualize network topology, traffic and troubleshooting Similar to Cumulus NetQ: show network toplogy including physical networks (ToR, spine) and virtual networks (virtual bridges, virtual ports) and hosts (compute nodes and network nodes) lighty.io UI Network Topology Visibility Component Flow stats and monitoring, sFlow, NetFlow

Issue/Challenge #9: Controller Cluster Scalability How can it work with 127 cluster nodes? Replication to other 126? More granular shard: e.g. per openvswitch group for topology and inventory Cluster leader, shard leader and openvswitch master, it will be better if shard leader is same as openflowplugin master for openvswitch. Is read possible in any follower shard? Is asymmetric clustering possible? Nodes for neutron server and nodes for southbound device/openvswitch. Does Database backend help on these issues? https://wiki.opendaylight.org/view/Project_Proposals:Alt-datastores

Issue/Challenge #10: Southbound Plugin Scalability Inventory and network topology data store are big Openflowplugin clustering just uses 3 controller nodes (one master, two slaves), master can do read, write, flow statistics and async messages handling, slave only can read. A small lightweight southbound 3 node cluster is preferred for a group of compute node/network node. The same solution is applied to ovsdb

ZTE vDC ZENIC SDN Controller V2.00.10 Distributed Controller Cluster Agile Controller - DCN ZENIC vDC Controller ZTE vDC ZENIC SDN Controller V2.00.10 Distributed Controller Cluster 2+N nodes：2 master controllers （Active/Passive），N（1-128）southbound controllers Database Distributed Message Queue Distributed Lock Distributed Cache O&M Proxy

Summary of Issues/Challenges #1: how to unify networking for VMs, containers and baremetals? #2: how to manage ToR switches? #3: how to run Opendaylight in k8s pod? #4: How to integrate with kata container? #5: how to use Opendaylight to control all the switches in leaf spine architecture? #6: Is Centralized SDN controller model best in super scale data center? #7: How to support hierarchical port binding and EVPN? #8: How to visualize network topology and troubleshooting? #9: ODL controller cluster scalability issue #10: ODL southbound plugin scalability issue These may be the directions ODL community can take efforts in the future.