At a bit of a loss with a two server set up

Question

I've been running a single Xserve (G5) for the last 5 years, but now we have just got one of the last new Xserves to become our main server, I want to keep the old server running light duties, but be ready to take over again as the main server if the new one went down for any reason, but with minimum fuss to switch over. I know because the are different models running different OS X server, I can't have anything like IP failover. But I can't figure out the best way to set this up.
For instance how do you handle port forwarding, would you manually have to go to the router and change all the services to forward to the other server whenever you change? and all the services on the server, I was hoping it would be as simple as turning them back on, but I'm not sure it is because everything is looking for the old server. Just feel in a bit of a muddle.
On our single G5 it was running the following:
AFP ( all files stored on Xserve RAID )
DHCP
DNS
iChat
Open Directory
Web
Kerio Connect
Retrospect
Rumpus FTP server
So now with the Intel Xserve I was going to move all the main services to that and just leave Retrospect and Rumpus running on the G5, but have it ready to take over if the Intel goes down.
But unless I'm missing something that would involve me, plugging the Fiber channel leads from the RAID to other server, moving the User Network home drive from one server to the other, reconfiguring all the services to look for the other server, changing all the Port forwarding on the router to the other server ect…
Doesn't sound like something that would go smoothly in an emergency

Answer 1

You're setting up a failover configuration, and an attempt to increase uptime, and this capability involves the particular implementation of and the configuration of each of the services. Not all services allow this. (Google around for previous discussions of failover. Some cases and some services are ease (eg: DNS), and some cases can get gnarly.)
AFP ( all files stored on Xserve RAID )
Not shared, though with Xsan and shared SAN access, you can fail over via DNS changes.
DHCP
Not shared. Can start another server easily when the active DHCP server fails.
The ISC DHCP server can do DHCP fail-over, and that can be retrofit onto a Mac OS X Server box with a little effort.
Given the usual lease times, you will have some time to get the server back online before problems become systemic, or to activate a standby DHCP server.
DNS
Can inherently be shared; primary and secondary.
iChat
Not shared.
Open Directory
Can be shared; primary and replica.
Web
Not replicated, though with Xsan and shared SAN access, you can fail over via DNS changes.
Kerio Connect
Likely can be clustered and almost certain to allow mail to be queued, but you'd have to check with Kerio for details.
Retrospect
Not likely shared. I do not know the details nor status of Xsan support with this package.
Rumpus FTP server
Not replicated. Likely with Xsan and shared SAN access, you can probably fail over via DNS changes.
There have been previous discussions, so some searching might find some insights. Here is [Failover Cluster Possible?|http://discussions.apple.com/message.jspa?messageID=11812720], for instance.
Apple had documented [High Availability IP Failover features|http://docs.info.apple.com/article.html?path=ServerAdmin/10.5/en/c3fs2 9.html] in earlier Mac OS X Server releases, but most of the documentation has disappeared. (Whether this failover mechanism is considered deprecated with Snow Leopard 10.6, I don't know.) That written, the key pieces of this capability including [failoverd failover daemon |http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPage s/man8/failoverd.8.html] and [heartbeatd heartbeat daemon|http://developer.apple.com/library/mac/#documentation/Darwin/Reference/M anPages/man8/heartbeatd.8.html%23//apple_ref/doc/man/8/heartbeatd] are still listed, however. And as the documentation for that daemon states +Configuring your nodes to support IP Failover is a non-trivial task and not to be taken lightly! Significant data loss or corruption may result from poorly configured systems.+