[ovs-dev] OVSDB Replication: Clarifications required

Andy Zhou azhou at ovn.org
Mon Jul 17 18:40:38 UTC 2017


On Sat, Jul 15, 2017 at 10:58 PM, Arunkumar Rg <arunkumar.rg at gmail.com> wrote:
> Hi Andy Zhou,
>
> Thanks for looking into this!
>
> Please find my replies inline:
>
> On Tue, Jul 11, 2017 at 1:30 AM, Andy Zhou <azhou at ovn.org> wrote:
>>
>> On Tue, Jul 4, 2017 at 10:52 PM, Arunkumar Rg <arunkumar.rg at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > Got few clarifications on OVSDB replication. Please let me know your
>> > inputs
>> > on it.
>> >
>> > 1. From the ovsdb-server code(main_loop()), it seems that the standby
>> > ovsdb-server becomes 'Active' if the JSONRPC session with the
>> > active-ovsdb-server is not alive.
>> > Instead of this behavior, is there a way(probably some CLI option)
>> > wherein
>> > we can instruct the ovsdb-server to not become active even if the
>> > session
>> > to 'active' is not alive??
>>
>> It is technically possible.  What is a good use case for this?
>
> Arun: The use case I'm looking at is - ovsdb-server runs in a VxLAN HW-VTEP.
> Now if we want to provide HW-VTEP redundancy(something like MC-LAG), then
> we'll use
> ovsdb-server replication in these redundant HW-VTEPs i.e ovsdb-server
> running in one of the
> HW-VTEPs will be acting as 'Active' and other HW-VTEP as 'standby'. With
> this, the controller
> will see a single HW-VTEP instead of multiple HW-VTEPs. Now, in this case,
> if the HW-VTEPs
> already has an inherent mechanism to call which HW-VTEP is active and which
> is standby, then I want
> to use that mechansim to dictate ovsdb-server to become active/standby
> accordingly.

In this use case, would you want to switch the back-up HW-VTEP to
backup the new 'active'
server?   Whenever an backup server become active due to the current active
server failure, you can always force it into backup server mode again.
The limitation
is there will be a brief moment that multiple active server will be
running. I am not
sure this is a concern in practice. If this is a concern, what you
proposed is a reasonable
solution. May be you post a patch for this feature.
>
>> >
>> > 2. I understand in the standby-ovsdb-server then no transaction(write
>> > operation) can be done on it's DB. At the same time, I see an option in
>> > appctl to exclude few tables from syncing, whether we can do
>> > transaction(write operation) on those tables in the
>> > standby-ovsdb-server??
>>
>> This may be a good extension to current implementation.
>
> Arun: This would be helpful for the above use case I described. I'm new to
> this ovs-dev.
> If you are aware, please share me on how to put this request to ovs
> community.

Sending email to the 'dev' mailing list is the usual approach I am aware of.

>
>>
>> >
>> > 3. Can the below runtime management commands of ovsdb-server can be done
>> > via API calls(something like IDL APIs)??
>> > ovsdb-server/connect-remote-ovsdb-server
>> > ovsdb-server/disconnect-remote-ovsdb-server
>> > ovsdb-server/set-sync-exclude-tables {db:table,...}
>> > ovsdb-server/get-sync-excluded-tables
>>
>> Current design and implementation are for integration with Linux HA
>> framework. Those
>> extensions are technically possible. Would implementing them improve
>> Linux HA integration
>> better? or for supporting other HA framework?
>
> Arun: Currently I'm trying a prototype of running a ovsdb-server on a
> HW-VTEP.
> For this I have written a small ovsdb-client program using the
> IDL(vtep-idl).
> Now I'm planning to do some prototype for HW-VTEP redundancy(as described in
> my
> above replies) and for this it seems to me using ovsdb-server replication to
> be useful.
> So if IDL has APIs for ovsdb-server replication related operations as well,
> then I can
> use those APIs straight away instead of calling the command lines through
> system calls.

ovs-appctl talks to the ovsdb-server process over a unix domain
socket. If your client
program can open a socket, it should also be able to talk to
ovsdb-server without
using cli.
>
> Thanks,
> Arun.
>>
>> >
>> > Thanks,
>> > Arun.
>> > _______________________________________________
>> > dev mailing list
>> > dev at openvswitch.org
>> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>


More information about the dev mailing list