[ovs-dev] RFC: OVN database options

[Ben Pfaff]

On Fri, Mar 11, 2016 at 12:55:54AM +0900, Dan Mihai Dumitriu wrote:
> The NB DB does need HA and ACID transactions, but it has few clients, so
> it's probably not a very hard problem - could even use BDB with log
> shipping -
> http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/overview/index-085366.html
> .

I don't think that BDB is a great idea for new use in an open source
project, because Oracle is increasingly hostile to open source and due
to recent license changes some distributions, including Debian, have
elected not to package BDB 6.0:
        https://lwn.net/Articles/557820/

> However, one more potential requirement for the NB DB is secondary indices,
> because the NB clients may expect to query the NB models in various ways
> that weren't considered a priori. I bring this up because in the OpenStack
> context the NB DB could be used to store the Neutron data model entirely,
> thus obviating the need for the Neutron DB, and eliminating the "syncing
> problem" between Neutron and the NB DB. I could see the same applying in
> the context of containers.

I had not considered the possibility that the NB DB might become the
database of record for Neutron.  This might be hard to do while allowing
OVN to work gracefully with a variety of CMSes, rather than making it
OpenStack/Neutron specific.

> Regarding the SB DB, as Liran pointed out, it doesn't necessarily need
> durable persistence. It would be possible to make the whole thing work with
> an in memory SB DB. (I am waiting for you to start shooting holes in this
> hypothesis, but I'm reasonably confident those holes can be filled.) 

I basically agree.  I think that the requirements that I wrote cover
this pretty well:

    - Transactions: Clients expect atomic, consistent, isolated
      transactions.

      Durability is not essential, because the clients will reissue
      lost transactions (up to and including completely refilling an
      empty database, although this can be slow).

    - High availability: If the database server goes down, then this
      freezes the OVN configuration.  This is OK briefly for running
      clients--the existing configuration continues to work, it just
      can't be updated--but it prevents new clients or clients that
      restart from using OVN at all.

      For the same reason that durability is not essential, it is
      acceptable if an occasional fail-over between database servers
      loses a few transactions, though of course it's best to minimize
      the probability and the amount of data lost.

> That said, it does need to be replicated for HA - luckily the
> replication of an in memory data structure is easier and more
> performant than that of a durably persistent data structure. 

Yes.

> In order to support efficient syncing with clients (ovn-controller
> agents) the in memory replication should be a form of log shipping, so
> that clients that disconnect from one SB DB instance and reconnect to
> different SB DB instance can do a resync without a full table
> download. Is this premature optimization?

I think it's a prudent plan, since OVSDB already works in terms of log
shipping, although we don't call it that.