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 issue. 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, OpenStack. 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 datapaths. 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. - Liran _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
