Re: Regarding nopreempt and the recent related patches
Assaf Muller <[email protected]>
| Newsgroups | gmane.linux.keepalived.devel |
|---|---|
| Message-ID | <[email protected]> |
----- Original Message ----- > Well if the priority difference is more than 50 a fail over will occur any > way regardless of nopreempt Right now I'm using the same priority on all nodes. > > The only thing I can think of is maybe the interface tracking may be going > wrong. I'm inducing failover by setting the track interface down on the master node, but it's definitely up on both of the other nodes. > And in your config the track_interface section is redundant. Because you did > not tell it explicitly not to track the "interface" Ack - Thanks. > > > > Sent from my BlackBerry 10 smartphone. > Original Message > From: Assaf Muller > Sent: Monday, March 16, 2015 21:52 > To: [email protected] > Cc: [email protected] > Subject: Re: [Keepalived-devel] Regarding nopreempt and the recent related > patches > > > > ----- Original Message ----- > > I suspect you a bug in all the howtos I'm about to write a new one that > > explains it and corrects it. > > > > The short answer is set the state in all of the configs in the cluster to > > BACKUP. > > I am. Here's a sample of a keepalived.conf I'm using (Identical on all nodes > apart from the name of the interface and track_interface, which is unique > per node): > http://www.fpaste.org/198754/ > I tried putting a unique priority per node, that gave me the same result, > which after looking at the code makes sense. > > What I'm seeing is that when the master goes down, the other 2 nodes go to > MASTER, > then to STANDBY, then to master again, rinse and repeat. Sometimes one of the > node > 'wins' after 60 seconds, sometimes it can go on for 15 minutes or more. > One of the 2 says it received a lower priority message and goes to standby: > https://github.com/acassen/keepalived/blob/master/keepalived/vrrp/vrrp.c#L1010 > > The other says it received a higher priority message and goes to standby: > https://github.com/acassen/keepalived/blob/master/keepalived/vrrp/vrrp.c#L1037 > > > > > > > > If you have one set as MASTER it breaks no preempt and preempt delay > > options. > > It also tends to break VRRP groups. > > > > > > Well saying it's a bug is harsh they are all based on the first howto which > > represented the best practice thinking at the time which assumed you backup > > probably didn't have as much capacity as your primary to save money. Now > > servers and VM are relitivly cheap in comparison ans you can turn a $300 > > desktop form any of tthe big manufacturers with an added network card into > > a > > 1Gb fulduplex firewall and or loadbalancer with capacity to spare. > > > > Sent from my BlackBerry 10 smartphone. > > Original Message > > From: Assaf Muller > > Sent: Monday, March 16, 2015 21:34 > > To: [email protected] > > Subject: [Keepalived-devel] Regarding nopreempt and the recent related > > patches > > > > Hello everyone, > > > > I'm an OpenStack Neutron dev working on a high availability solution > > for virtual routers which uses keepalived internally. These two patches > > that were merged for 1.2.14: > > > > e18370cb165d21db954c08ddbce1b39d97858012 > > 13693a2d1b834c749394ef0bdee6afe9eb1fad2d > > > > Changed the behavior of nopreempt and I'm seeing a severe regression. > > Short story: Why does keepalived go to standby when it receives a message > > with a lower priority? > > > > Long story: > > I opened a RHBZ (I probably should have sent a message here first): > > https://bugzilla.redhat.com/show_bug.cgi?id=1202584 > > > > That has a lot more context and information, including the keepalived.conf > > we spit out in Neutron code. It also has exerts from syslog that > > demonstrate > > the issue. If any more context or information is needed please let me know. > > I'm also available as 'amuller' on Freenode (keepalived channel as well as > > openstack-neutron). > > > > Thank you, > > Assaf Muller, Cloud Networking Engineer > > Red Hat > > > > ------------------------------------------------------------------------------ > > Dive into the World of Parallel Programming The Go Parallel Website, > > sponsored > > by Intel and developed in partnership with Slashdot Media, is your hub for > > all > > things parallel software development, from weekly thought leadership blogs > > to > > news, videos, case studies, tutorials and more. Take a look and join the > > conversation now. http://goparallel.sourceforge.net/ > > _______________________________________________ > > Keepalived-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/keepalived-devel > > > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Keepalived-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/keepalived-devel