At $work – 1, I’ve been familiar with the spread + wackamole combo to float and failover two IPs amongst two hosts.
A typical use-case is when we have a couple (or more) web servers independent of each other (say, webmail web servers: webmail.mydomain.com), I’d add multiple A records for the same domain so that DNS resolution happens in a round-robin manner at the client’s end. i.e.,
dig +short webmail.mydomain.com
184.xx.yy.154
184.xx.yy.155
The client uses the first IP it gets during resolution and as the number of clients that are resolving your domain (and making HTTP requests) grow, you’ll start seeing a more or less equitable distribution of HTTP requests hitting each of your hosts.
These IPs are meant to float and be handled by your spread/wackamole tools. (i.e., they’re not hard-configured into network config files like permanent configs: i.e. /etc/sysconfig/networking/ifcfg-*). Say, the .154 IP was on host A and .155 on host B, host B goes down, spread daemon on host A detects that host B isn’t responding to "are you alive?" requests and instructs wackamole daemon on host A to take over the IP that host B had (.155). Sometimes – depending on the router in your environment – one might have to send a gratuitous ARP packet to the router and hook this up with wackamole’s "post-up" action.
This post is about how I couldn’t find usable RPMs for spread/wackamole (and was in a time crunch to shave that yak) and looked for an alternative.
Pacemaker and Keepalived are known entities in the market. So is UCARP (as userland implementation of BSD’s CARP for Linux). Being on a time crunch and noticing how the former options seemed a little complex at first sight, I settled on deploying UCARP.
The configurations on the Internet typically show how one IP is floated around between two hosts. Now this doesn’t let me have DNS-based round-robin’d "load" balanced incoming requests. So here’s how I configured UCARP on host A (assuming you have installed from EPEL repo as `yum install ucarp’):
[root@web02-dal07 nvenkateshappa]# cat /etc/ucarp/vip-001.conf
# Virtual IP configuration file for UCARP
# The number (from 001 to 255) in the name of the file is the identifier
# In the simple scenario, you want a single virtual IP address from the _same_
# network to be taken over by one of the routers.
ID="001"
VIP_ADDRESS="184.xx.yy.154"
PASSWORD="love"
BIND_INTERFACE="eth1"
SOURCE_ADDRESS="184.xx.yy.179"
# In more complex scenarios, check the "vip-common" file for values to override
# and how to add options.
And on host B:
[root@web01-dal07 nvenkateshappa]# cat /etc/ucarp/vip-001.conf
# Virtual IP configuration file for UCARP
# The number (from 001 to 255) in the name of the file is the identifier
# In the simple scenario, you want a single virtual IP address from the _same_
# network to be taken over by one of the routers.
ID="001"
VIP_ADDRESS="184.xx.yy.154"
PASSWORD="love"
BIND_INTERFACE="eth1"
SOURCE_ADDRESS="184.xx.yy.180"
OPTIONS="--shutdown --preempt --advskew=10"
# In more complex scenarios, check the "vip-common" file for values to override
# and how to add options.
The above vip-001.conf on the two hosts is for managing the first floating IP, and the following are for the second: vip-002.conf
Copy over the same configs on each host, change ID to 002, VIP_ADDRESS to 184.xx.yy.155 and swap the OPTIONS line.
The –advskew option (advertisement skew) is what gives a sense of affinity for your virtual IPs.
Let me know in what other interesting use-cases you’ve used UCARP in.