The Trouble with Blades

That new blade looks good, sounds good. But will it stop your system working?

Managing the old server farm is getting more difficult nowadays. What's the business going to be doing next year? Will it be bigger? Smaller? What are the critical applications which are going to eat up all your server power and bandwidth? Which critical supplier is going to disappear, leaving you with the extra workload of engineering a band aid workaround? Oh yes - and your IT budget is going to be much less than you really need to cope. Again.

At times of high uncertainty, users can reduce risk by choosing flexible solutions which can be built (or unbuilt) incrementally. Monolithic solutions which claim to offer lower total cost of ownership sound fine on the vendor's web site, but you can't afford to bet the farm on a single solution, knowing your target may have changed before the new system is even installed.

Maybe that's one of the reasons we've been seeing such high reader interest in SPARC blade products on the SPARC Product Directory web site in recent quarters. Pageviews on SPARC blade pages overtook volume on rackmount SPARC systems last year, and oscillates with SPARC portables in being the #1 or #2 most popular product area that our readers visit. In this context SPARC blades (as opposed to SPARCblades which are a trademark of Continuous Computing) are single board SPARC computers, which are designed for easy insertion into rackmount systems.

The flavor of the month for high performance SPARC blade backplane architecture is compact PCI. Market analysts have been saying that standard form factors like this one will succeed in the market in preference to proprietary solutions from any small group of vendors. Compact PCI is mechanically based on the decades old Eurocard form factor - which also spawned the VMEbus. But its timing specs are rooted in the ubiquitous and similarly named PCI. The first cPCI SPARC SBC was launched 1997 by Force Computers, but now 6 manufacturers compete in this SPARC space, and I confidentally predict that the number will grow when the product marketers have digested the reality of this trend.

Plugging an another processor when you need it is an attractive idea. Even better than the preinstalled extra processors shipped in Sun mainframes, the blade concept holds out the promise that when you plug in a new processor in about 12 months time, it could be faster and cheaper than the original generation of processors with which you started.

However that's when you'll learn that most manufacturers don't test their cards properly in heterogenous systems, and every now an again you're going to find that adding a new card will stop the older ones working.

Before my cut and paste career as editor of this publications, I managed a technical group which supported the 1980s equivalent of today's blades - based on the 6U VMEbus form factor. Back then we supported over 130 different cards including manufacturers like Sun, Force, Motorola and dozens more companies which made specialised processors or I/O. The list of cards which we found didn't work in our systems was almost as long as the list of those we used. Usually the failed cards would work fine by themselves, or if they were only used in simple configurations with other cards from the same manufacturer. But often you would find that putting 3 or 4 cards of the same type in a system would stop it working. "Why would you want to put so many processors in a rack?" we would be asked by vendors. "We never thought anyone would do that."

Timing problems were the least of our worries, because they could be ferreted out quickly.

Subtle problems would arise due to cabling design. When you tried putting 8 high density I/O cards next to each other, the thickness and inflexibility of the cables would sometimes make it difficult to route the signals out of the card cage without making it a couple of inches deeper. Space which just wasn't there. That's not a problem which you see coming until too late.

Some cards were easier to insert than remove. You'd eventually figure out that a rogue high performance card had been designed to fit into a single slot, but actually consumed about five times as much power as the maximum power budget defined by the bus specs. The plastic connectors on these cards melted slightly and would stick to the backplane. So, after a few months of operation, when you tried swapping the card as part of your fault finding process - you couldn't get the damn thing out without using excessive force and nearly ripping your fingers off.

Thermal problems caused the hardest to solve of intermittent faults. If you were lucky you might discover the tell tale blackening caused by hot spots on adjacent cards having a bake off. The symptoms would be that the system would work fine for a couple of days, and then just fail due to heat exhaustion... Once a new card we tried, set our system on fire.

The blade approach is a powerful and flexible paradigm, and you'll be glad you used it. But its simplictity is deceptive. No single manufacturer makes the best of everything you want.You'll have to learn new skills of detection, and like Sherlock Holmes, you'll have to use evidence and logic to pin the blame on the right culprits. But you can have a lot of fun too, and your skills will become greatly sought after and highly valued. So, when the upturn comes, and you've saved your organization a bundle on monolithic alternatives, that might be a good time to put in for a pay rise.