[ovs-dev] ovsdb active backup deployment
Valentine Sinitsyn
valentine.sinitsyn at gmail.com
Fri Aug 19 08:40:17 UTC 2016
On 19.08.2016 02:44, Andy Zhou wrote:
>
>
> On Thu, Aug 18, 2016 at 1:41 PM, Valentine Sinitsyn
> <valentine.sinitsyn at gmail.com <mailto:valentine.sinitsyn at gmail.com>> wrote:
>
> On 18.08.2016 23:49, Andy Zhou wrote:
>
>
>
> On Thu, Aug 18, 2016 at 8:34 AM, Valentine Sinitsyn
> <valentine.sinitsyn at gmail.com
> <mailto:valentine.sinitsyn at gmail.com>
> <mailto:valentine.sinitsyn at gmail.com
> <mailto:valentine.sinitsyn at gmail.com>>> wrote:
>
> On 18.08.2016 17:42, Russell Bryant wrote:
>
>
> On Thu, Aug 18, 2016 at 2:30 AM, Valentine Sinitsyn
> <valentine.sinitsyn at gmail.com
> <mailto:valentine.sinitsyn at gmail.com>
> <mailto:valentine.sinitsyn at gmail.com
> <mailto:valentine.sinitsyn at gmail.com>>
> <mailto:valentine.sinitsyn at gmail.com
> <mailto:valentine.sinitsyn at gmail.com>
>
> <mailto:valentine.sinitsyn at gmail.com
> <mailto:valentine.sinitsyn at gmail.com>>>> wrote:
>
> Hi everyone,
>
> Russell, Would HA manager also manage
> ovn-controller
> switch over?
>
>
> Yes, indirectly. The way this is typically
> handled
> is by
> using a virtual
> IP that moves to whatever host is currently
> the master
>
> Cool, then ovn-controller does not have to be HA
> aware.
>
>
> In my understanding, the virtual IP feature in
> Pacemaker (i.e.
> IPaddr2) works if both active and passive nodes of the
> cluster are
> in the same IP subnet.
>
> For some deployments, this would mean both nodes a
> located
> on the
> same physical rack. This is not actually a
> fault-tolerant design
> (think blackout).
>
> If I'm getting virtual IP addresses in Pacemaker
> correct,
> wouldn't
> it be better to make ovn-controller HA aware? That
> is, have
> a node
> switching command (akin to
> ovsdb-server/connect-active-ovsdb-server)
> and let Pacemaker make use it?
>
>
> I was not planning to have pacemaker manage
> ovn-controller on
> every host.
>
> OK, makes sense.
>
> Would using a proxy server, such as HAproxy, help?
>
> Help in what?
>
> To provide a single routable IP address for ovsdb clients to connect to.
Yes it would, but doesn't Pacemaker handle this already as well?
>
>
>
>
>
> If this sounds reasonable, I can take on it probably.
>
>
> In general, I think having ovn-controller able to connect to
> more than
> one database IP seems fine. I don't expect everyone to
> necessarily
> agree on the same HA architecture.
>
> Perhaps it's simple and good enough to add some support for
> multiple IP
> addresses for the southbound database that
> ovn-controller can rotate
> through on reconnect attempts?
>
> As passive ovsdb instance doesn't accept client connections,
> this
> wouldn't help much if the connectivity between
> ovn-controller and
> south ovsdb master is broken. But this scenario is likely
> outside
> current HA architecture either.
>
>
> Yes, something external should change ovsdb-server from backup into
> active. A backup server accepts clinet connections, but rejects any
> "write" transaction that can
> change the database.
>
> Pacamaker is a proposed way to do it, as far as I understand.
>
> Right. I am still in favor of using floating IP for this release.
Agree. That's a typical was to deploy Pacemaker, and something which
would work for most people, I guess.
I'm trying to find a solution for a different case, where this IP can
float within the single rack only (as L3 subnet is not permitted to
stretch across racks). The mechanisms involved are complementary, not
mutually exclusive.
>
>
>
>
>
> In short, yes, having support for multiple IPs in
> ovn-controller is
> certainly a step forward in the right direction IMO.
>
>
> I agree it could be a worthwhile feature. If we end up
> implementing this
> feature, I hope we don't statically configure the backup server IP
> address. It may be better
> for the idl client to keep track of current backup server. One
> possible
> way to implement it is to store the backup connection into the
> database.
>
> Which of the databases? ovn-controller connects to OVS one, and to
> SB. Storing this in OVS means the backup server need to know all
> ovn-controllers on the net, having this information in SB itself is
> somewhat chicken and the egg problem.
>
>
> I'd think we need store them in both DBs. HA manager or backup server
> can update the SB first, ovn-controller can then replicate the
> configurations to its local OVS DB.
An ovsdb-server updating itself sounds somewhat unnatural to me. HA
manager updating the SB (or NB) seems more straightforward. However this
leaves us a narrow race window when an active server fails and the
client is left with no way to learn the backup server address.
>
>
> Now we store OVN SB location in the OVS database, do we? My initial
> intent was store not one, but two addresses, and switch between them.
>
>
> I don't object we start there. and this may be fine for the situations
> where active and backup server will always occupy two well known
> addresses. I just hope we have
> a plan to to update those addresses in case HA manager launches the
> backup server with a differnt IP address.
Ack.
>
>
> Besides, don't we also want ovn-northd to support multiple addresses
> for NB/SB then?
>
>
> That would be nice too,
Will have a look on it.
Valentine
>
>
> The backup server
> can issue an transaction to record its connection information,
> before
> replicating.
>
>
> Valentine
>
>
>
> Best,
> Valentine
>
>
>
> --
> Russell Bryant
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org <mailto:dev at openvswitch.org>
> <mailto:dev at openvswitch.org <mailto:dev at openvswitch.org>>
> http://openvswitch.org/mailman/listinfo/dev
> <http://openvswitch.org/mailman/listinfo/dev>
> <http://openvswitch.org/mailman/listinfo/dev
> <http://openvswitch.org/mailman/listinfo/dev>>
>
>
>
More information about the dev
mailing list