Categories
Software

UCARP for IP failover on CentOS 6

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.

Categories
Software

rpmbuild behaviour: CentOS5 vs. CentOS6

Those of you who’ve tried building RPMs for c5 on a c6 machine might’ve faced the symptoms described in http://samixblog.blogspot.com/2011/11/yum-errno-3-error-performing-checksum.html

The cause seems to involve a couple of things: 1. c6 having adopted a stronger file digest algorithm (sha256 as opposed to md5 in c5) and 2. compressing the payload with xz (as opposed to nothing in c5).

This is easily remedied by passing relevant options to `rpmbuild’ and `createrepo’.

If you’re using fpm in your CI, you can now append the following to your fpm command invocation:

--rpm-rpmbuild-define '_source_filedigest_algorithm md5' \
--rpm-rpmbuild-define '_binary_filedigest_algorithm md5' \
--rpm-rpmbuild-define '_source_payload nil' \
--rpm-rpmbuild-define '_binary_payload nil' \

And invoke createrepo as `createrepo -d -s sha1 –update /path/to/rpms/for/c5′

UPDATE (2012-04-23):

fpm now supports quick shortcuts to the above:

% fpm --help
[...]
--rpm-digest sha512|md5|sha384|sha256|sha1 (rpm only) Select a digest
algorithm. md5 works on the most platforms. (default: "md5")
--rpm-compression xz|gzip|bzip2 (rpm only) Select a compression method.
gzip works on the most platforms. (default: "gzip")
Categories
LAN Work Life

Using Dnsmasq to serve from a central /etc/hosts

Recently at $work, I came across a situation where: a. public DNS records are served off of a GoDaddy account and b. a couple of domain names needed a office network-wide override pointing it to IPs in the local network.

i.e.

dig +short @8.8.8.8 qa.example.com

<returns public IP>

dig +short qa.example.com

<returns private IP>

If there aren’t too many consumers for this name resolution, we could’ve done with putting in entries into /etc/hosts on each consumer host. But our consumer hosts included a lot of android phones. And we didn’t want to root them all to be able to modify their /etc/hosts.

If we were running our own DNS server in our DMZ, we could’ve configured the infamous split-DNS setup through BIND or tinydns. (Un)fortunately, we didn’t.

The first "workaround" to this was to maintain a duplicate zone for example.com on our local DNS server (the one served by our DHCP server) and override the records as required. This would soon start to suck.

A colleague of mine – who didn’t take my word that the above two methods are our only options available – persevered through the PowerDNS docs and found an option where it could serve off the host’s /etc/hosts file. Now what was brilliant about this was, adding a ‘192.168.1.223 qa.example.com’ into /etc/hosts effectively solved the problem we had!

We didn’t really needed a full-fledged DNS server like PowerDNS and I looked if dnsmasq could solve the same problem – and it does.

[root@blr-vbox1 ~]# egrep -v ‘^#|^\B+’ /etc/dnsmasq.conf
bogus-priv
resolv-file=/etc/resolv.conf.isp
interface=eth0
no-dhcp-interface=eth0
no-dhcp-interface=lo0
conf-dir=/etc/dnsmasq.d

Our ISP’s DNS servers go into /etc/resolv.conf.isp

Ensure that the host that’s running dnsmasq has only ‘nameserver 127.0.0.1’ in /etc/resolv.conf and put in all your entries to be served into /etc/hosts.