[ovs-dev] [PATCH 1/4] docs: OVSDB replication design document

[Russell Bryant]

On Thu, Mar 31, 2016 at 11:26 AM, Marcelo E. Magallon <
marcelo.magallon at hpe.com> wrote:

> Hi Ben,
>
> On 03/30/2016 06:13 PM, Ben Pfaff wrote:
>
> I understand the technical differences between the approaches. My question
>> is whether high availability is your actual goal. If it is, then it
>> probably does not make sense to have multiple implementations. If you are
>> trying to accomplish something else, then it could be that there is
>> something complementary about the two implementations.
>>
>
> I believe the two approaches are complementary.
>
> Like I said, the proposed patch aims at having a stand by database
> available, but since there's no proxy or anything like that, if the active
> database goes down, clients would have to reconnect. Ideally, after
> failover, the stand-by database becomes the active and clients can reuse
> the same connection parameters, but a reconnection must happen. If someone
> is interested in filling that gap, haproxy is an option, but I have not yet
> tested it. Same thing applies to a Raft-based solution.
>
> What you are doing with Raft is complementary in the sense that you can
> have six database servers, expose three of them to the clients and the
> other three become stand-bys for the three active ones. If any of the three
> actives go down, the corresponding stand-by steps up. With Raft, with 6
> active databases, you can loose 2 (4 are needed for consensus). With this
> approach you only have 3 databases in service, but you can loose all three.
> Obviously you can come up with other topologies like 3+1, or 5+1, etc. The
> proposed patch is the "+" part in that design.


I don't understand the value of combining the two in the same installation.

This all just sounds like an active-passive versus active-active HA
solution.  Active-passive seems a bit easier to implement, but I would
always prefer the active-active solution if it's available.

The one thing this approach would provide is an HA solution for 2 nodes
instead of at least 3.  We're already using at least 3 nodes for HA reasons
in all of the environments that I care about for my use cases since we need
3 for other active-active solutions.

Do you have a requirement for a 2-node solution?  Could you expand on your
use case?

-- 
Russell Bryant