On 06/25/2015 07:21 AM, Gal Sagie wrote: > Hello All, > > Currently OVN uses centralized ovsdb-server to serve the Northbound and the > Southbound DB to all the local controllers (sitting at each of the compute > nodes). > > It is a single point of failure and probably a major bottleneck to the > operation of OVN in scale.
Yes, it's definitely something we need to address one way or another. > I know there are efforts to make ovsdb-server distributed using Raft, while > i think this is an important effort i believe that open source is about > being open to alternative and choices while reusing other open and reliable > solutions, this is why i want to suggest the following idea: > > Design the DB distribution layer in a pluggable manner, doing so, users can > pick alternate distributed DB options that are reliable and have been in > the market for some time which also have performance optimizations. (Of > course that the default plugin will use the ovsdb-server implementation) > I think an important aspect in this regards is that different > environments/setups with different scale needs can have different solutions > that fits them, the ability to choose which back end to use can help in > these scenarios. > > If we analyze OVSDB, there are 3 major areas an alternate solution needs to > support: > > 1) The DB JSON schema itself > Should be the same between all solutions > > 2) The OVSDB protocol features > like: monitor (publish-subscribe) / transactions / garbage collection / > locking > sync-verify (multi writes/reads for same values) > > It is important to note that any pluggable solution must support all > these features > > 3) The connection between the client and the server > This i believe can be pluggable as long as the messages that are > exchanged (the protocol > features) are still exchanged > > Then the only thing that needs to be modified is basically the client > library which can map > the API's to the client requests depending on the picked solution. > > Looking forward hearing your opinions. Do you have a particular alternative db in mind? Just curious. I think it'd be easier for me to think through it with a specific example in mind. One way I've thought about approaching playing with this is to write a ovsdb-to-<whatever> proxy that would run local to each ovn-controller. Of course, I'm sure it's harder than it seems in my head. :-) It's probably a waste of time since I don't think anyone would want to use that for real. In any case, I do like the idea of still being able to use ovsdb-server even if we started adding support for something else. ovsdb-server keeps the deployment really simple since you already have it for OVS. I think some abstraction here would be nice. Even if ovsdb-server becomes a distributed db, I suspect there would be a difficult perception and trust battle. "Ugh, they implemented their own distributed db?! NIH, etc .." "Ugh, a distributed db that nobody else uses? I don't trust that." Those are the reactions I'm already hearing talking to people about this stuff. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
