[ovs-dev] OVN - Pluggable Distributed DB Infrastructure for OVSDB

Russell Bryant rbryant at redhat.com
Thu Jun 25 14:07:13 UTC 2015


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



More information about the dev mailing list