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>> 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>>> 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?
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.
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.
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.
Besides, don't we also want ovn-northd to support multiple addresses for
NB/SB then?
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>
http://openvswitch.org/mailman/listinfo/dev
<http://openvswitch.org/mailman/listinfo/dev>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
