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

[Kyle Mestery]

On Thu, Jun 25, 2015 at 8:07 AM, Russell Bryant <rbryant at redhat.com> wrote:

> 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.
>
>
Agreed, which is why I think this is a good thing to consider. Allowing
other DBs to plugin may relieve some of this angst others feel, and does
fit in with the general model of pluggability OpenStack has.


> --
> Russell Bryant
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>