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.
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.
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.
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.
Once up and running, the ftServer drives like any other RHEL 4.5 system. I promptly dropped on some of my heavy database/Web application test code and put it to work. It handled the load without issue, performing much like I would expect a single system of that spec.
Pulling a server module during periods of heavy load elicited no complaints from the server or the client running the tests, and reseating the module produced no ill effects – not even a ping drop. In production, the local software mirroring is sufficient for boot volumes, but for production data, the use of external storage is a must.
High-availability trade-offsIt’s worthwhile to note that advances in virtualization technology such as VMware’s VMotion and HA can be used to achieve similar levels of redundancy for server instances, and that has to be taken into account when discussing the ftServer line, but there’s still much to be said for instruction-level fault tolerance. VMware’s HA won’t keep a server online through a server mainboard failure, for instance, even though it will reboot and be available a few minutes later.Stratus offers extended maintenance and service options that allow Stratus engineers to access the server directly, and even enable the system to order its own replacement parts if necessary – a nice touch.
As with the Windows-based ftServer I tested in January, I couldn’t break the ftServer 4400. It just runs. There may be a slight penalty introduced by the synchronous processing, but if so, it’s negligible. The CPUs are slower than I’d like, and it would be nice to see the Intel quad-core CPUs as an option. The price of the ft4400 is far higher than the cost of a clustered solution’s, but if the goal is a completely fault-tolerant single-server solution, look no further.
