The last time I had a Stratus server in the lab, it was the ftServer W Series 4300, back in January 2006. That was a Windows-based system, and discussions with Stratus about Linux distributions showed that although it had a Linux version, it was the company's own distribution, and not standard. For some Linux shops, this wasn't a problem, but for those looking to run specific applications and services -- such as Oracle Database -- that require a certified distribution, it was an obstacle.
Now, Stratus has introduced the ftServer 4400, running RHEL (Red Hat Enterprise Linux) Advanced Server 4.5 x86_64, which is about as standard as it gets. This is very good news for anyone who doesn't do Windows and is looking to deploy a completely redundant server. Yes, I do mean completely redundant.
Box of boxes
The magic behind Stratus' ftServer line is the bundling together of essentially two discrete servers into a single entity. This doesn't mean that the ftServer is a cluster, however. Each server in the two-server package is joined by a common backplane, although option cards are placed in each server. The video and USB ports are on the chassis shared by the server modules, though the NICs are located on the server modules themselves. Disks are configured in a similar fashion, with three hot-swap drive bays per server module, and like all other components, they must be configured identically between modules.
So in essence, the ftServer consists of two physical servers with identical CPUs, RAM, disk, and I/O options joined at the hip, and all communication between these two modules is tightly controlled by custom drivers. This makes the two modules appear as one from the console and from the network and -- most importantly -- to the OS.
Unlike paired servers in clusters, these modules aren't active/passive, where one module works while the other sits idly by. Instead, each module runs every instruction at the CPU level, every write to and read from RAM, and every write to and read from disk. The drivers and custom hardware within the modules allow them to perform the very same tasks simultaneously, and they chug along as perfect mirrors until something breaks. However, when a component fails, this same code allows the ftServer to continue to function normally, bypassing the failed component completely, and using the redundant component to pick up the slack.
This fail-over protection isn't limited to NICs or disk, though -- a sudden failure of a DIMM or a complete CPU failure can be overcome without missing a beat. This forms the core of Stratus' mission: to provide a completely redundant server in every respect, without clustering. To replace the failed components, you just pull out the module with the bad part, replace it, and slide the module back into the chassis, without any downtime.
There are caveats to the Stratus approach, of course. First, since the coordination between modules is so tight, the variety of compatible option cards is very limited. You're not going to be able to use these servers with iSCSI HBAs, for instance, but Fibre Channel will work, as long as specific cards are used. It's also possible to add more NICs and U320 SCSI controllers for tape drives, but that's it.
Surviving the death lab
My review unit carried three hard drives of different types and sizes, 6GB of RAM, and two Intel 5130 dual-core 2.0GHz CPUs on each of its two server modules. The ftServer backplane holds three USB ports, a serial port, and a video port. On the modules, the only connections were a single power input and two gigabit NICs. In keeping with the duplication theme, if one NIC is linked, they both need to be linked to the same VLAN because they function as the same interface. Stratus handles this particular redundant aspect with standard NIC bonding at the OS level, similar to the software RAID used to mirror the local disk.
One thing the ftServer lacks is any form of lights-out management. I suppose that if the server never goes down, the need for remote management is reduced, but it would be nice to have anyway.
The boot process is handled by one module and behaves pretty much like any other server. Once the OS boots, however, Linux admins will note a few differences, such as the Stratus drivers that are loaded during the initialization phase, and the collection of drivers and support code placed under /opt. I also noticed some odd video artifacts on my KVM while working on the ftServer 4400, but only in text mode.