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


Reply via email to