For companies that have grown on an assortment of mismatched machines, the efficiency and flexibility of a server-based workflow can be liberating. Open Directory, managed services, portable home directories, and many other features are impossible to use without a server to to drive them. This dependance on a single, central system can be a detriment as well. After all, what can you do when your all-important server inevitably fails?

You can already have a second server in place. IP failover lets another machine take charge should your primary server cease to function. This feature isn’t for novices (and is one of Apple’s only Leopard sales points that lacks a graphical interface), but if you can’t afford any downtime its a feature the deserves serious consideration.

IP Failover Planning:

Before you begin, there are some significant considerations when designing a failover setup. Most importantly, IP failover doesn’t work on OS X between Apple’s older PowerPC and newer Intel machines. Ideally, you’ll want to failover between identical hardware and operating systems, but at a bare minimum you need to be working with the same architecture and major OS version.

Next, you’ll likely be inclined to give your failover server a “real” job, having it offer services on your network to stay busy instead of just waiting for your main server to fail. Unfortunately, those services often become an essential element of users’ workflow, meaning a failover that changes the failover server’s IP could be as disastrous as losing your main server itself.

While IP failover doesn’t require a Directory Service scheme, any authenticated services will need account information from the main server. Setting up your failover server as an Open Directory replica is certainly the simplest method to achieve this, and provides essential authentication should your main server go down.

Finally, IP Failover can provide an available server at an expected address, but it doesn’t guarantee the files you need are available as well. You’ll need both servers to access data from a shared store of some kind (preferably an XSan volume), a task outside the scope of this article.

IP Failover Basics:

To start your IP failover setup, you’ll need to make sure that both servers are networked correctly. It’s best if their primary ethernet ports (en0 on the command line) have IPs from the same subnet, making it more likely that anyone who can reach the first can reach the second. In our examples we’re using 192.168.0.250 and 192.168.0.251. You’ll also want to have a direct connection from the main server to it’s failover, rather than connecting them through a switch or other network device, preferably using IP over Firewire. This direct connection will carry the heartbeat signal, which lets the failover know the main server is still functioning.

To provide the heartbeat connection, go to System Preferences and select the “Network” pane. The graphical interface calls this port “Firewire 1″, while on the command line it’s fw0. Set the IP address and subnet mask on the main server (but no router or DNS servers) on your main server, choosing a private subnet not used by your regular IP network, then set up your failover server in the same fashion with a subsequent IP. Here we’ll use 10.0.0.1 and 10.0.0.2 for our heartbeat connection.

Now we’ll configure IP failover itself by editing the /etc/hostconfig files. On your main server, add the following:

FAILOVER_BCAST_IPS="192.168.0.251 10.0.0.2"
FAILOVER_EMAIL_RECIPIENT=USER@DOMAIN

Here FAILOVER_BCAST_IPS lets the server know first which IP to failover to and second which IP to send the heartbeat signal. The FAILOVER_EMAIL_RECIPIENT setting tells the server to send mail to the address provided when failover takes place. You’ll need to replace the IPs here with the IPs of your failover server and heartbeat connection respectively, and USER@DOMAIN with the appropriate administrative email address. On the second server, edit the same file, adding:

FAILOVER_PEER_IP_PAIRS="en0:192.168.0.250"
FAILOVER_PEER_IP="10.0.0.1"
FAILOVER_EMAIL_RECIPIENT=USER@DOMAIN

The FAILOVER_PEER_IP_PAIRS setting provides the ethernet port to handle failover (using the command line numbering) as well as the IP to adopt should the heatbeat signal fail. FAILOVER_PEER_IP tells the failover server which address to expect the heartbeat connection from. Keep in mind that to send email alerts, you’ll need SMTP service configured on both servers.

To test your failover setup, simply ping the main server from a workstation, then disconnect the server’s ethernet connection. The ping should stop momentarily, then pick up again once the failover server stops receiving the heartbeat signal.

Next week, in part two of this article, we’ll discuss configuring high availability for AFP connections and extending IP failover with custom shell scripts.