Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I work for a small ISP, and we host about 250 domains and all the stuff that goes along with that: DNS, mail, spam filtering, and backups. Currently, we have separate DNS servers (two of them) and mail servers (outgoing mail is actually on the secondary DNS server, but was previously on its own server). In the past, this was done as an insurance measure. The last thing we need is for some doofus (usually yours truly) to hose a server, taking out DNS and mail right along with it, or for spammers to jam our incoming SMTP server, preventing outgoing mail from being sent too. In the past, this was a problem, and our servers were set up the way they are now to combat it.

However, clustering solutions like Sun's Cobalt RAQ (in days of olde) and Virtualmin appear to cater to an all-in-one approach, then deal with failures through redundant servers. I have avoided this thus far, but we've been using Virtualmin on our web server for a while now, and I'd like to expand into using it for a high availability cluster. Our networking partner has recently built a datacenter that has eliminated all of our other bugaboos like network, cooling, and power issues, so now the only thing left to go wrong is me hosing a server, which happened earlier this month.

One of the bigger reasons we've avoided going this route is because our hardware requirements aren't particularly high. One server easily handles all the sites we host (most of them are flat sites). Also, load-balancing routers tend to be expensive and complicated. All that I'm really expecting to do is building a two-node cluster for redundancy so that when I hose a server (however rare that might be), we're not out for 8-12 hours while I rebuild it.

What I need to know is how to get started, and if I'm really in a position to bother with this kind of thing at all.

share|improve this question

I've found that using load balancing is my preferred solution for introducing high availability to Web servers. There's advantages for staging code deployments, not idling available resources, and introducing redundancy. LVS is my preferred solution there. Others seem to like Pound and I'm also intrigued by HAProxy. With LVS, configuring a ldirectord server and using arptables on the Web server can be a straight-forward implementation. You can prevent single point of failure with LVS by having an active/passive server implementation with failover using heartbeat.

Now, if you're shared hosting selling accounts, introducing high availability with automatic failover is going to be more complicated. With this, you might have to consider a redundant storage solution that multiple servers can access and configure an active/passive server using heartbeat. DRBD seems like it could be useful here.

You can implement complete high availability solutions with no single point of failure using entirely open source and commodity hardware. If you want additional recommendations, I would be happy to help. This is one of my favorite areas to focus in.

share|improve this answer

What we recently did was setup ucarp on our cluster, and setup 4 identically configured nodes. We run an in-house developed webapp, so the 4 nodes, when not serving as a front-end actually do back-end work.

UCARP and a few scripts I put together will automatically bring up an IP on another node when the node serving things starts acting out. NGINX is our front-end server, and it handles ensuring requests are routed to an available node.

The upshot of all this is that I can, w/o warning knock out just about any one of our 4 nodes, and services will automatically migrate to another available node within seconds. (Existing connections to that node are interrupted, but there's only a small handfull at any given moment, by the time they reload, things are back to full speed elsewhere.) UCARP will detect failures in IP connectivity --- if other things are going bad, you have to work out a way to knock IP connectivity off the bad node, so the other functioning nodes take over.

All 4 nodes mount an nfs-exported file system, which is handled by a pair of machines running drbd

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.