Get Out of My Dreams and Into My CARP

Redundancy is all the rage these days. People want to have some sort of backup situation in place to handle the inevitable hardware failure. If you have two webservers hosting your files and one of them crashes, wouldn't it be great if the other system could recognize the problem and take over the other system's requests?

Yeah. Yeah, that would be nice. Here's how to do it in two lines on OpenBSD 3.5 and up using CARP.

Step 1: Before you type a single character, you need to pick four pieces of information: the virtual host ID, the password, the network interface you want to use, and the IP information.

I'll just pick some example values.

Virtual host ID: this is an integer v such that 1 <= v <= 255. I'll pick a vhid of 7. This value is what creates redundancy groups, so every system I want to run CARP on a particular address needs to have the same value here.

Password: this is a plaintext string that I include in the configuration in order to prevent forgeries. This password is not sent to other hosts in the clear, but it is used to authenticate them. I want my password to be "never1dropofH20onarrakis".

Network interface: I need to tell CARP which interface it's going to listen on for advertisements. I only have one network card, and OpenBSD calls it "dc0". I'd have to be more careful if I had more interfaces.

IP information: CARP creates a virtual IP address. If you have two OpenBSD servers with IPs 1.2.3.4 and 1.2.3.5, you can create a new IP, say 1.2.3.100, which you will assign to multiple systems with CARP instead of with DHCP of explicitly setting the Ethernet interface. I want my IP to be 192.168.0.123 and have a netmask of 255.255.255.0.

# ifconfig carp0 create
# ifconfig carp0 vhid 7 pass never1dropofH20onarrakis 
carpdev dc0 192.168.0.123 255.255.255.0

That's it, folks. I can go around to every OpenBSD box I want to use, type these two lines, and have redundancy working on them in no time flat. If I want to determine a precise order in which hosts will take over in the event of a failure, I can use "advskew". Hosts advertise to each other, literally saying "Hey, everyone. I'm still alive. Just so you know." They do this at regular intervals, and if you skew advertisements accordingly, then certain hosts advertise more slowly than others. Lower numbers = higher probability of a system becoming the master. The system with the lowest advskew value will usually win.

There's only one snag with implementing CARP, and it's that a system who has assumed control of a virtual IP address will not by default relinquish control. If host1 and host2 use CARP and host1 crashes in the middle of the night, host2 will take over. If host1 reboots and everything gets sorted out, host2 doesn't care. It's still going to keep control of the IP until it crashes or has control taken away manually. If you want to disable this behavior so that when host1 comes back up it forcibly reasserts its master status, you need to set a sysctl option:

# sysctl -w net.inet.carp.preempt=1

None of these will withstand a reboot, of course, so you should probably put some of this into an /etc/hostname.carp0 file:

# cat /etc/hostname.carp0
inet 192.168.0.123 255.255.255.0 vhid 7 carpdev dc0 pass
never1dropofH20onarrakis

Pretty easy to set up. Next up? UCARP.