Paul Lynch's Pages

Our existing server environment is getting old, and with changing requirements, is getting harder to maintain. Time for a change!

Starting from the outside in, the router connects to a firewall, which is an old box (an AST) running FreeBSD. Inside that is an Airport, which is used to partition off all the workstations and personal machines, and our remaining server.

The primary server handles mail, DNS and doubles as our CVS repository, which needs to have external access. This is a very old custom assembled PC in a large tower case, running FreeBSD. Upgrading new versions is a bit of a pain, as several services need to be reviewed and upgraded for new features at once – notably the mail service, which hasn’t kept pace: no SSL login, no webmail, minimal spam filtering. It also runs a nightly network wide backup to tape.

We have two ‘production’ web servers: the main one is an oldish Sun Ultra 5, running Solaris with WebObjects 4.5 installed and OpenBase. This holds our main company web sites, including our Mesa license server (both the shopping cart application and the internal use licensing databases). The next web server is used for personal sites, and is a mid-era iMac (graphite); it runs WebObjects 5.2 and OpenBase, and is used for a couple of old WebObjects content management applications that should really be converted into blogs. It also runs blosxom for blogs (this one comes to mind, while it is still there), and a PHPbb, which means also MySQL, all for internal use.

Another web server is used for fallback, rapid deployment of test WebObjects applications, hosting for clients (which is usually an emergency service), etc.

We moved over to this system round about 1997, from a mainly NeXT based server structure, and it has worked reliably since then – with several hardware changes, mostly upgrades rather than failures, along the way.

This configuration gives me several worries – although it does run very stably. As already mentioned, upgrades and adding new required functionality is troublesome. Then if either of the three main servers suffer a hardware failure, replacing them will be time consuming, as well as a high priority task. I don’t necessarily have instant memory recall of what is required to rebuild any of them, either at the system software level, or in terms of my own data and applications. It isn’t as simple as just restoring from a backup.

Effectively, our site functions, despite being on three boxes, represent a single failure point.

My solution is to merge all the functions under MacOS X Server, using the ‘easy’ administration tools to allow me to easily upgrade and add new functions. At first, I was considering an XServe, but that is still a single point of failure with significant replacement time involved. However, the Mac Mini has sufficient power for the tasks required, and is significantly cheaper than the XServe (because it is a lot less powerful, there are good reasons for the price difference), sufficiently so that buying two of them isn’t an issue. One disadvantage of this is that the Minis only have a single network port, and so I won’t be able to migrate the firewall onto the Minis as well. Frustrating, but not unreasonable.

I intend to keep both with identical configurations and data. In MacOS X Server, there is a fallover option whereby a backup machine can quickly take over a main servers IP address – but I suspect that I don’t need to use this, I will investigate later on. If a failure occurs, we can manually switch over fast enough to keep me happy. The only worry then will be the risk of a second failure within Apple’s normal (slow) delivery times.

My switch over plan is to configure one Mini to handle DNS and mail, then swap it in for the old main server, which will suffer a name (and IP address) change. If that goes well, then I will fold in the web sites, coping with an upgrade of the main applications to WebObjects 5.2 along the way (the apps have already been upgraded, but the server hasn’t).

I will document whatever is required to make MacOS X Server work productively, and will stick to basic admin applications if at all possible. I can already see that DNS requires more effort to maintain than ‘classic’ DNS configuration files, and switching from blosxom to blojsom may be quite intensive.

Backup strategy will change to a manually driven ‘burn a DVD’ process, as well as the network backups between the two Minis.