It's true: Two is definitely better than one, at least when you're talking about high availability. For most server manufacturers, that means two or more identical servers in some form of cluster. Outside the clustering code, these servers are singular entities without a direct relationship with one another.
Stratus takes a different approach with its ftServer W Series 4300: It combines two discrete servers within a common backplane, operating as complete mirrors of each other. Using custom drivers, all tasks handled by the ftServer 4300 are executed in parallel. Each instruction is simultaneously computed on processors across both units. Each I/O call is handled in parallel, simultaneously. The Stratus code is essentially a traffic cop of sorts, making sure that traffic is flowing, even if there's an accident. Should a CPU or DIMM fail, the OS never sees the event and continues as normal.
Thus, the ftServer 4300 isn't really a cluster but a wholly redundant single server. In essence, Stratus has crafted a shim, abstracting the hardware layer from the OS, presenting the OS with only what it needs to see, regardless of the physical hardware in use. Suffice it to say, the ftServer 4300 is like no other server you've seen.
Two by four
Considering the spec is similar to a 1U dual-CPU server, this box is relatively large, consuming 4U in the rack version. Each server chassis in my evaluation unit came complete with dual single-core 3.2GHz 1MB cache Xeon CPUs, 2GB DDR2 RAM, three 72GB SATA drives, and a CD-ROM drive. Each chassis has a single power supply that's housed within the chassis, as well as two gigabit NICs.
These chassis units slide into a common backplane that is little more than a shell with shared video and USB ports on the back. When the ftServer 4300 is up and running, only the equivalent of one chassis is actually available to the OS, similar to a RAID1 disk mirror.
Speaking of operating systems, Stratus currently supports Windows Server 2003 and the company's own Linux distribution. However, Stratus expects to support Red Hat Enterprise Linux 4 early this year. An OS installation on a Stratus fault-tolerant server isn't exactly like a standard install, as Stratus' suite of custom drivers need to be present. Because those custom drivers are required for all expansion cards, only Stratus-approved expansion cards, such as Fibre Channel HBAs, can be used in the server.
After racking the chassis cage, I slid each chassis in and ran power, USB KVM, and network cabling to the back. After power was applied to both units, the top CPU chassis' power button turned green. Flipping open the protective cover, I hit the button and both chassis sprang to life. A few minutes later, the Windows Server 2003 log-on screen appeared.
I ran a few benchmarks on the server running normally, and all signs pointed to it performing exactly as I would expect from a dual single-core 3.2GHz Xeon server. The disk I/O performance was slightly lower, perhaps, and this is likely due to the cross-chassis mirroring configuration that Stratus uses to maintain block-level synchronization across all disks.
Otherwise, the server looked and felt absolutely normal -- no clustering heartbeat status to worry about, for instance. Stratus does include the ftServer management tools, which are built on Microsoft's Management Console. This provides a current overview on the server health: From DIMM sockets to CPU temps, it's all listed here. In the event of a chassis or component malfunction, warning icons appear in the hierarchical tree displaying the various server parameters, simplifying problem identification.
Breaking the box -- or not
My first set of tests was to determine the raw performance of the server. Throughout the CPU and memory testing, I couldn't detect any negative ramifications of the Stratus design on overall server performance.
The second set of tests revolved around trying to break the ftServer 4300. Generally, I don't focus my testing on trying to break products, but Stratus' claims were such that I decided to go a bit overboard. I started by simply dropping power to one system unit during heavy network and disk I/O operations. The server simply didn't skip a beat. No lost packets, no stutters, no hiccups.
I powered that system unit back up and pulled the power on the other system unit; all while the heavy I/O test was still in progress. Still, the ftServer 4300 didn't budge. Throughout these tests, the nbench SMB file-sharing benchmark I was running didn't appreciably deviate from 39MBps throughput. That isn't a great mark for nbench on a server with these specs, but the fact that there were results at all was certainly respectable, given the duress the system experienced during the test. Raw disk I/O throughput tests showed roughly 70MBps sustained unbuffered sequential and random reads, but only 18MBps unbuffered sequential writes, with unbuffered random writes dropping to 15MBps
Following these tests, I equipped the ftServer 4300 with a utility from Stratus that triggers component failures. I then proceeded to fail individual CPUs and I/O hardware, all while running heavy I/O through the server. Furthermore, I performed these tests while connected to the server remotely via RDP (Remote Desktop Protocol). Again, not a whimper from the ftServer 4300.
Finally, I literally pulled a system unit from the chassis while the server was running. Even Stratus says that this isn't a supported action, and the company places locks over the power supplies to prevent this from happening while a system unit is powered up. This time, I got a flicker on the monitor, but otherwise, no ill effects, even after hot-reseating the system unit. That was enough proof for me.
The next day, I received a call from Stratus. The company's network operating center had received the notification that my system was experiencing failure events, but they hadn't contacted me immediately because it was classified as an evaluation system. In production, Stratus would have contacted me immediately and begun troubleshooting the problem or scheduling a replacement parts shipment. Not too shabby.
The ftServer 4300 is truly in a class by itself. It begs to be placed in a demanding role, such as a database server, but it might lack the onboard I/O throughput and disk space to handle that task. Implementing this server in a SAN should mitigate that caveat, however. The other drawback is the lack of dual-core CPU support, although Stratus claims that this is coming "sooner rather than later." The company has no plans to support AMD processors.
The Stratus ftServer W Series 4300 is not a cluster in the true sense of the word, but it could loosely be called an active/passive fail-over solution. The upshot here is that you need only to buy a server OS license for one server and CPU licensed software for two CPUs, yet you get the redundancy benefits of two servers and four CPUs, if not the performance. It's a solid bet if maximum uptime is the goal.
Overall Score (100%)
|ftServer W Series 4300||10.0||25.0||10.0||15.0||20.0||20.0|
You may still be better off sticking with Win7 or Win8.1, given the wide range of ongoing Win10...
Now that we're down to the wire, many upgraders report that the installer hangs. If this happens to...
Based on a technique created by a German blogger, here's how to stop wasting hours checking for Windows...
Sponsored by Hewlett Packard Enterprise
Sponsored by Intel
Cloud storage vendors don't provide a comfortable balance for some IT admins, but third-party options...
The bad guys are wreaking havoc. Why can't they be brought to justice?
A project sponsored in part by Google aims to allow algorithms to be optimized to get the most out of...
Not every enterprise application makes sense for the cloud. Here's how you'll know when you've...