Two-in-one server's promise of high availability proves unbreakable
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|
ARM's Mbed OS will be free for use on ARM chips when it's released next year
Google fires back at Microsoft, which last week cut prices of some Azure services
The software you'll install on your PC is an early stage version of the OS that'll have bugs and...
The larger design is very welcome, but there's much more to the iPhone 6 than a bigger screen
Get the scoop on the security threat billed as the biggest since Heartbleed
The company is expected to unveil a preview of the Windows 8 successor on Tuesday
Modularity, JSON, smart compilation -- Java's future offers compelling features to look forward to
Remember that incredibly stupid thing you did a decade or two ago? You wouldn't want to live it down
The reality distortion field wasn’t merely clever PR: Jobs used the three tools of classic rhetoric to
Brick 2.0 creates customizable Web UI elements via features in HTML5