On Fri, Aug 19, 2016 at 1:40 AM, Valentine Sinitsyn < valentine.sinit...@gmail.com> wrote:
> 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. HA manager works. Do you mean the narrow window between a backup server has transitioned into an active server, but before HA manager adds the next backup server? If it helps, we can update the SB with new backup server address *before* making it active. Current OVSDB does not allow this, but can be fixed. Are there other race windows? > > > >> >> 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
