I'm not an expert, and haven't done this for a while, so take this with a grain of salt...
There are basically 2 parts to getting failover to work: having the backup server take over the network identity of the primary (which is fairly easy), and having it provide the same services (which, depending on the service, can be quite difficult).
OS X Server has built-in components to handle the network identity portion. The recommended method is to set up 2 network connections between the servers, run heartbeatd on the primary (to send out "I'm alive packets") and failoverd on the backup (if stops receiving heartbeat, it takes over the primary's IP address). Here's a [MacTech Journal article|http://www.mactech.com/articles/mactech/Vol.23/23.03/OSXFailover-Part1/ index.html] with details.
(Note: there are also alternatives to use either DNS or a network device to redirect to the backup server.)
Getting the services to work properly after failover is more difficult, because they'll generally need access to the same data in order to provide equivalent service. For example:
- AFP
It's not enough for the backup server to have AFP running with the same settings as the primary, it has to be serving the same files. This generally means putting the shared files on an Xsan volume and mounting it on both servers. There's also a cheap-and-dirty alternative of storing the files on something like a fibre channel disk, and only mounting it from one server at a time (if both servers mount it at once without a SAN to manage access, filesystem corruption is a likely result).
Also, specifically for AFP, you'll want both servers to share the same AFP reconnect key (so clients transfer their connections fo the backup server without having to reauthenticate). The continuation of [that article|http://www.mactech.com/articles/mactech/Vol.23/23.04/OSXIPFailover/inde x.html] covers all this.
- DHCP
This one's relatively easy. If you have enough spare IP addresses (i.e. twice what you actually need), just give each server a range to hand out and call it done (well, maybe set the lease time fairly long so leases are unlikely to expire while a server is down). If you're short on IPs or want to get fancy, configure both servers the same (with the same IP range), and add "serveradmin start dhcp" to the backup's PostAcq script, and "serveradmin stop dhcp" to the PreRel script.
- DNS
Even easier. Create secondary zones on the backup server corresponding to the primary zones on the master, and it'll download and cache copies of all your zone data. You might want to edit the SOA records in the zone files (in /var/named/zones on the primary server) to increase the expiration time (see [here|http://en.wikipedia.org/wiki/Zone_file]), to give you longer to get the primary back on its feet.
- Firewall
Copy the settings, modifying as needed to deal with the different/multiple addresses. Make sure the heartbeat signals are not getting blocked.
- iCal
I don't know on this one.
- Mail
Dovecot supports clustering, but as I understand it requires that the mailboxes be stored on a shared volume (i.e. Xsan again). Basic config is in Server Admin, but I don't know if that's all that's needed...
- MySQL
I have no experience with this, but mySQL appears to have built-in replication capability ([google is your friend|http://www.google.com/search?q=mysql
serverfailover]).
- OD
Set the backup server up as an OD replica. Note that OD failover is handled automatically at the client, so the server IP failover may actually confuse this. You might need to add firewall rules on the backup server to block incoming LDAP, Password Server, and Kerberos traffic to the master's IP (i.e. so clients won't get confused by the replica suddenly answering at the master's IP address).
- Push Notification
Another I have no knowledge on.
- Web
Depends on the web site. If it's all static content, keeping a duplicate on the backup is all you need. If it's static except for a mySQL backend, solving the problem for mySQL should take care of it for web as well. For other sorts of dynamic content, you'll have to look at exactly how it works to figure out what's needed. In particluar, if you're using Apple's Wiki, Blog, etc, I'm not sure what's going to be needed, although I suspect Xsan and making sure only one of the servers is accessing it at a time (i.e. use the PostAcq and PreRel scripts to start and stop teamserver on the backup) might do the trick.
