Server blades could be the single biggest thing since Apache for Linux adoption in mainstream IT—if proprietary pitfalls don't get in the way.

These new servers come totally self-contained on single cards dubbed 'blades.' Server blades sport low-power processors that were designed for laptops, along with memory, network connections, and associated electronics for local I/O from keyboards to disks. Each blade runs its own operating system instance, which means a system administrator can insert or remove blades without affecting the operation of others. Legend has it that with these mystical blades, any CIO can slay the total cost-of-ownership (TCO) dragon and be anointed a 'Hero of the Corporation' by the CFO.

Unfortunately, the stuff that dreams are made of often differs from the real world. In the case of server blades, these differences can be substantial.

The initial value proposition for server blades rests in leveraging standard chassis components for power, cooling as well as electronics for environmental monitoring and management. What's more, rack-mounted server deployment is both time-consuming and resource-intensive—especially with a cage and multiple servers. Just cabling to power sources and the network in a high-density server environment can be problematic.

In sharp contrast, an administrator only needs to cable a single chassis when installing multiple servers on blades. Adding a new system in a blade server environment is very much analogous to plugging in an additional SCSI hard drive into a RAID array with a hot-swap backplane. In fact, it is much too analogous.

What makes popping SCSI drives in and out of arrays so easy is an industry-standard SCA interface. Thanks to that standard interface, SCSI drives from the likes of  IBM, Hitachi, or Seagate can be used interchangeably in any manufacturer's storage array. Just pop the drive into a canister and presto, the canister slides into the array: Just so long as the canister is the right one for that array. If it's not the right canister, you've got a serious problem. That's because today's drive canisters are about as proprietary as anything there ever was in the realm of computing.

Which brings us to one of the most fundamental issues of server blades: How valuable is the capability to hot plug a server blade into a chassis? Hanging on the answer to that question lies the profit aspirations of a number of PC vendors and just perhaps a tipping point for Linux in corporate IT.

 Here again, the analogy to hot-swap RAID arrays has enormous currency. For years, drive prices have been falling faster that a ballast weight dropped from a hot-air balloon. Yet IT has been quite willing to pay a princely premium for perceived value when it comes to RAID subsystems.

For our tests, OpenBench Labs installed two SlotServer 1000 blades in an HP Vectra desktop system. Each SlotServer 1000 comes with external connectors for SVGA video, USB 1.0 peripherals, 10/100 Fast Ethernet, and audio in and out ports. Each blade also has an internal IDE connector, which is used to connect local hard drives and CD ROMs. Moreover, each of the SlotServers uses the host's PCI bus to establish a private Gigabit network linking the SlotServers and the host.

The most important thing to note about the OmniCluster Technologies SlotServer is that it is a rapidly evolving product both in hardware and in software. Two important improvements nearing general availability are the SlotServer 3000 blade sporting an Intel P-III processor clocked at 700 MHz and new drivers for Linux-based hosts, which will support more than one SlotServer.

The main software components for turning a standard PC host into a SlotServer blade chassis are the SlotServer drivers and a Virtual Disk Manager (VDM) package. Here OmniCluster Technologies knows that to open up the future for growth, the keys are Linux and Free BSD. If they can continue to drive down costs using industry-standard components, Redmond's draconian licensing policies will eventually make Windows software irrelevant in this market sector. For the (very) short term, however, only the Windows VDM supports multiple SlotServers.

 Using the VDM, system administrators can effortlessly  deploy software to one or more blades in a single drag-and-drop operation. After provisioning the blades, an administrator can then manage them using the KVM switch option within the VDM. This feature, dubbed SlotCon, in the VDM provides the necessary tools to run the SlotServer in a headless configuration. In other words, there is no need to plug a separate video monitor along with a USB-based keyboard and mouse into the SlotServer.

There is, however, one important caveat: The SlotCon window cannot display X Windows graphics. If you plan on using X-based applications on the SlotServer, then you'll either have to make due with an HTML-based administration tool such as Webmin or you'll need to attach an external monitor, keyboard and mouse. Given that the BusCluster architecture automatically configures a private virtual Gigabit ethernet for the host (90.0.0.1) and resident SlotServers (90.0.0.x), OBLlabs found the Webmin option quite viable.

For serious SlotServer deployment, another key component for consideration is a dedicated SlotServer staging platform. As we've noted, the provisioning of SlotServers is a rather trivial task, once you have a library of virtual drives resident on the host from which to drag and drop different configurations onto any given SlotServer. To create such a disk library, at least one SlotServer must be configured with its own dedicated IDE hard drive and CD ROM. Currently, the only physical drives that VDM can attach to SlotServer are the host's floppy drives.

As a result, sites deploying server blades will of neccessity have to choose between Ethernet and Fibre Channel for connectivity to external storage. In all likelihood, this choice will default to Ethernet for the first generation of blades, because of its cost-effectiveness and pervasiveness.

Using Ethernet, server blades can connect to network-attached storage (NAS) and emerging Internet Protocol storage (IPS) technologies like iSCSI (Internet SCSI), which provides block-level access to storage over Ethernet. Fibre Channel connectivity will more likely come through integration with InfiniBand switching. 

First on the agenda, however, is the necessity to standardize on file sharing protocols. In our test scenario, the dominant OS was Linux and so we chose NFS as our storage networking protocol.

To this end, we installed DiskAccess from Shaffer Solutions on the HP Vectra host. We only had one minor connectivity glitch using the virtual network with DiskAccess. A problem with connection persistence was easily cured by simply declining the DiskAccess default to favor TCP on the internal network.

With DiskAccess, we were able to access NFS shares exported by the SlotServers over the private Gigabit Ethernet network created by the OmniCluster ClusterBus architecture using the standard Windows Network Neighborhood GUI. In essence, DiskAccess enabled us to move files into the file that the OmniCluster VDM software was presenting to RedHat on the SlotServer as a virtual disk.

The other issue for the first generation of server blades is that of CPU performance. The SlotServer 1000 typifies this issue through its use of a low-power low-performance Cyrix processor from National Semiconductor clocked at 300 MHz and equipped with a meager 16KB cache.

Using our OBLcpu benchmark, we pegged the performance of this processor at about that of a 100MHz Pentium. By way of comparison, the processor in our HP Vectra workstation was 19 times as powerful.

More mainstream application processing such as database services and thin-client computing will come into play with the arrival of more powerful blades like the SlotServer 3000, which is powered by a 700MHz P-III engine. The more powerful SlotServer 3000 will better marry the features available from today's high-performance 1U servers such as the HP Netserver 1000 and the cost, deployment, and density benefits of server blades. This should also foster an evolution into High-Performance Computing (HPC) clusters from the current High Availability (HA) clusters.