Talkback
E-mail
Printer Friendly
Reprints
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.
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-offs
It'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.
Paul Venezia is senior contributing editor of the InfoWorld Test Center and writes The Deep End blog.
