On 8/27/2015 10:22 PM, Nathan Williams wrote: > We have 2 OpenStack VMs with IPs on the internal network, a keepalived > -managed VIP on the internal network that's added to each VMs allowed > -address-pairs in neutron, and a floating IP from the external network > mapped to the internal VIP (OpenStack floating IP is just a SNAT/DNAT). > Depending on your environment, that's probably not super relevant, but > it's essential to being able to have a public VIP under neutron, so I > thought I'd mention it.
Lots of things I've never touched. My load balancers are behind the firewall, but use actual public IP addresses on the outside interface, with a private address on the inside interface. One of the VIPs is a gateway on the private network for the back end servers. No NAT required. > keepalived.conf[0]: keepalived manages the vip, runs scored health > checks: the master has the highest score. keepalived also handles VIP > migration and gratuitous arp to announce the change on failover. > > role-check.sh[1]: fail the master if it doesn't have the VIP. not > strictly necessary, but we're paranoid. > > keepalive-notify.sh[2]: record history of state changes, last row used > by role-check.sh to determine current state. These are currently unfamiliar concepts, perhaps they will become familiar once I start digging into keepalived. > It's been really stable over the last 8 months we've been running it; > failover works really cleanly like you'd expect, there's been no > unexplainable failovers we've run into so far, no failure to failover > when it should. Without using LVS to do the actual load-balancing, > there's no keepalived-associated tools I'm aware of to let you inspect > the cluster state (as compared to pacemaker `crm_mon -Af`). It doesn't > really matter with this simple cluster configuration, though; the > master's the one with the VIP, so `ip addr show` tells you which one's > the master, and the notify script-generated log file confirms it. > > You can manually force a failover by stopping the keepalived service on > the master or adding an exit 1 to the top of the role-check.sh script > (adjusting the scoring). Ditto for putting the standby into maintenance > mode, you just ensure it can't end up with a higher score than the > master. > > One thing to be aware of is that keepalived uses multicast by default, > so you want to make sure every cluster uses a unique router-id, or your > clusters might interfere with each other. I'm using multicast now with the corosync that operates under pacemaker, so this is not an unusual requirement. I just choose a different multicast address for each cluster. Thanks for the info. Thanks, Shawn
