Clustering vs. Fault-Tolerant Servers

mstansberry writes "According to SearchDataCenter.com fault-tolerant server vendors say the majority of hardware and software makers have pushed clustering as a high-availability option because it sells more hardware and software licenses. Fault-tolerant servers pack redundant components such as power supply and storage into a single box, while clustering involves the networking of multiple, standard servers used as failover machines." Perhaps some readers on the front lines can shed a bit more light on the debate based on both proprietary and Linux-based approaches.

Comments

Software vendors

[PCM2]

So if you ask a software vendor whether it's better to buy expensive hardware or to save money on hardware and install more copies of software, what's he going to say? Even if you had a site license he'd still say that, because guess what ... he's a software vendor. He's not in the business of solving your problems with hardware.

Re:It depends on what you want to do.

[Tenareth]

A Web farm is the simplest form of clustering, some would argue it isn't even a cluster because the nodes are not aware of each other. However, it gets more confusing when you add a Java layer that load balances...

Anyway, I do agree that I've seen more trouble caused by DB Clustering solutions than it helps...

A cluster adds complexity to the environment, Complexity == Cost, even without the expensive software.

Re:It depends on what you want to do.

[Donny Smith]

Well, in case you haven't noticed, it's late 2005 now.
Some things have changed, for example Windows 2003 Server came out and MSCS is now quite a decent HA solution.

(BTW, the grandparent post didn't say that Microsoft's own clustering solution was lame, he made a general statement about all clustering software for the Windows platform).

Re:It depends on what you want to do.

[Marillion]

That makes lots of sense. Software costs do multiply in clustering. Zero times 100 is still zero. But, clustering has other headaches beyond money.

The usual clustering I've seen is "Hot Spare" clustering. The primary runs until it goes kaput, then the second takes over. For database clustering, the two boxes usually share the same disks. I think I've seen more outages from false takeovers by the seconday than real failures of the primary.

The other problem with clustering is that all of your software applications have to be cluster tolerant. If the user app keeps a database connection open and a rollover occurs, the connection state doesn't and can't rollover with it. To a client system, a cluster failover looks like a server reboot. Don't underestimate the difficulty of this problem. A new application has to be designed with that in mind. Retro-fitting it in later is hard - and costly, even with free platforms.

Another issue that can't be solved with clustering is application failure or application limits. You may recall the airline system failure last Christmas? Some 80% of Slashdot readers asked where was the backup? (there was) should have used Unix (they were). The box (RS6000) and operating system (AIX) kept running just fine. A hundred computer cluster couldn't solve the the real problem: the application couldn't handle the volume of information it was required to hold and they at the mercy of a proprietary source code vendor.