[ovs-dev] OVN: Possible scalability bottleneck around the port binding table
LIRANS at il.ibm.com
Tue Aug 25 08:46:36 UTC 2015
I would like to initiate an open discussion on a possible scalability
bottleneck and ways to address it.
OVN implements a pro-active approach for disseminating port binding
updates - all vSwitches monitor the Port_Binding table as a whole and are
being notified by the SouthBound DB upon each change in the table. For
installations with a very large amount of logical ports and a very high
rate of change in port bindings this can lead to a major scalability
For example, it's not uncommon for large scale data centers to contain
tens of thousands of physical hosts running tens of VMs/containers each.
Dynamic lifecycle of a typical cloud workload (application elasticity, VM
migration, workload onboarding and sunset) generates large amount of
changes. Containing all the changes in a single monolithic table and
distributing them by sending the whole table to each vSwitch can result in
overwhelming amount of control plane traffic. Unresolved, this issue can
make OVN unsuitable to large clouds people try to build with, for example,
There are multiple ways to address the issue (see for example the two
options I present below). Can this question be opened up to discussion
aiming at visibility of the design decision and realization plans/roadmap?
Proposed solutions: both options are based on allowing the vSwitch
(ovn-controller) to monitor only a subset of the port binding table. You
can think about it as a compromise between the fully pro-active and the
re-active approaches (push vs. pull).
Option 1: Extend OVSDB protocol to include a new method to allow the
client to monitor a table under a specific condition and being updated
only on rows that satisfy the condition ( e.g "datapath"== XYZ ). This
will allow each vSwitch in OVN to monitor only a subset of the logical
Option 2: Allow the user to create a new table during run-time. OVN will
create a port binding table for each logical datapath and vSwitches will
monitor only a subset of the tables.
More information about the dev