ucarp Virtual IP Addresses

I haven’t written a blog post for a while; like everyone else I’m working on other things and haven’t been able to dedicate any time towards blogging. However, on a slow Sunday morning I thought I’d take a quick look at ucarp which is a way to provide virtual IPs, ie. IP addresses that can failover to another server, should the one it’s running on stop working.

Highly available IP addresses

Frankly I don’t have a lot of experience providing highly available IP addresses (from now on I’ll call the virtual IPs or vips, though that’s probably not the right term). There are quite a few ways to achieve vips, such as using technologies like VRRP, Pacemaker, Corosync, Keepalived, ECMP/BGP, etc. All have their pros and cons, some are simpler than others…make your own well-informed decision. :)

For my particular purposes, at this time at least, I chose CARP.

CARP

There was a big kerfuffle back in the late 90’s about Cisco creating, and patenting, VRRP. OpenBSD was not happy with the situation, and created CARP. I’ve used CARP a lot over the years, especially with OpenBSD firewalls. So when it came time to do highly available virtual IPs with Linux, CARP seemed a good choice. I didn’t want to over-engineer too early, so using something simple like CARP seemed a good strategy.

PS. Use more OpenBSD!

ucarp

UCARP allows a couple of hosts to share common virtual IP addresses in order
to provide automatic failover. It is a portable userland implementation of the
secure and patent-free Common Address Redundancy Protocol (CARP, OpenBSD’s
alternative to the patents-bloated VRRP).

Configuration

Once the ucarp package is installed, the /etc/network/interfaces file can be configured to use ucarp.

Below are a couple example sections from a ucarp configured network interface file. Please note that I am using bonding and VLANs as well as ucarp. Bonding and vlans are not required to use ucarp, but it’s fun so why not.

As can be seen above, only one of the nodes has the ucarp vip. If I were to power off node2 one of the other nodes would obtain the vip. If you see more than one node with the same IP then likely ucarp is configured but the ucarp package is not installed.

Thoughts and future work

Right now, to me ucarp’s only limitation is that it’s active/passive. However, ucarp is quite easy to setup and works well. Simplicity helps uptime too.

There are a few things I still have to investigate

Dialing in the failover time

Determining if the master should take back the vip when it’s restored

Configuring more than on vip per interface is not straight forward

While we are investigating other more complicated active/active HA processes for IP addresses, thanks to its simplicity I’m quite sure parts of my infrastructure will continue to use ucarp.