On 19.08.2016 02:44, Andy Zhou wrote:
On Thu, Aug 18, 2016 at 1:41 PM, Valentine Sinitsyn
<valentine.sinit...@gmail.com <mailto:valentine.sinit...@gmail.com>> wrote:
On 18.08.2016 23:49, Andy Zhou wrote:
On Thu, Aug 18, 2016 at 8:34 AM, Valentine Sinitsyn
<valentine.sinit...@gmail.com
<mailto:valentine.sinit...@gmail.com>
<mailto:valentine.sinit...@gmail.com
<mailto:valentine.sinit...@gmail.com>>> wrote:
On 18.08.2016 17:42, Russell Bryant wrote:
On Thu, Aug 18, 2016 at 2:30 AM, Valentine Sinitsyn
<valentine.sinit...@gmail.com
<mailto:valentine.sinit...@gmail.com>
<mailto:valentine.sinit...@gmail.com
<mailto:valentine.sinit...@gmail.com>>
<mailto:valentine.sinit...@gmail.com
<mailto:valentine.sinit...@gmail.com>
<mailto:valentine.sinit...@gmail.com
<mailto:valentine.sinit...@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@openvswitch.org <mailto:dev@openvswitch.org>
<mailto:dev@openvswitch.org <mailto:dev@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>>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
