The last time I had a Stratus server in the lab, it was the ftServer W Series 4300, back in January 2006 (see my review). 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.
[ See also: InfoWorld Technology of the Year Awards Hardware winners ]
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.
Click for larger view. |
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.
Paul Venezia is senior contributing editor of the InfoWorld Test Center and writes The Deep End blog.
Talkback
E-mail
Printer Friendly
Reprints



