NEC Fault-Tolerant Linux Server
The best benchmark is the load you plan to run, and a lot of benchmarks can be used. Each captures some limited view of what a system can do. As benchmarks become popular, manufacturers tweak hardware and installations to optimize benchmark results, and results thus become less applicable.
At Linux Journal we perform a rough evaluation of servers based on results of bonnie++, kernel build and the PostgreSQL regression test. These are run several times and the results averaged. We compared this server to a spare generic server having a single Athlon XP 2100+ processor using two different disk configurations, a single IDE drive and IDE hardware RAID-5. The results are shown in Tables 1–5.
The NEC unit held up well against the IDE RAID system in I/O tests, beating it handily in block output and block rewrite and narrowly in block input. In creating large numbers of zero-size files, the generic machine having the faster CPU won. The NEC server fell between the two configurations of the generic machine on elapsed time in the PostgreSQL regression test, while devoting a higher proportion of its CPU time, though at a lower load average—a measure of number of processes ready to run but not running. The kernel build test saw the NEC unit fare not nearly so well. Perhaps this is because compiling a kernel is computationally more intensive than the other two tests, but it doesn't adapt as well to multiple CPU operation, even though multiple processes are at work.
We did dry runs of these tests, and the relative loads on the two CPUs swung widely back and forth during the bonnie++ and kernel compilation tests. The PostgreSQL test showed fairly stable load allocation between the two CPUs. This is not entirely surprising, as the PostgreSQL test splits processing between client and server, offering better possibilities for distributing load between two CPUs.
Overall, the NEC machine was not blazingly fast as compared with our generic computer, a middle-of-the-road machine of recent vintage. But, it held its own nicely. The NEC machine's claim to fame, in any case, is its fault tolerance. In this, our generic machine offers not much comparison.
The NEC server comes equipped with NEC Linux, derived from Red Hat 7.1. It is text-only at the console, with no X server included. X libraries and clients are furnished for use from remote displays. Installation was reasonably complete, although I found somewhat annoying the absence of certain programs I rely on, such as procinfo.
Software re-installation is accomplished using Red Hat's kickstart method. When we tried it, re-installation from the provided CDs went without a hitch.
Some of the installed dæmons are very old releases and contain serious security holes. Examples include Sendmail 8.11.2, Apache 1.3.19, OpenSSL 0.9.6 and OpenSSH 2.5.2p2. We were unable to learn of concrete plans to ship newer versions. John Fitzsimmons of Aspire Communications, who served as our liaison with NEC during this review, indicated NEC expects its customers will customize the distribution to their own liking, clearing the final setup with NEC prior to deployment. Upgrading these things is likely to be the least part of the customization. Notwithstanding, an upgraded NEC Linux may be available later this year. It may contain an X server; we hope it contains security upgrades.
NEC supplies extensive proprietary software for configuration and monitoring of the server. This allows setup and configuration of the redundant hardware and monitoring and reporting over SNMP or other means to remote systems.
At press time, quite a bit of work remained to be done on the software load. For the price, starting at $24,000 US for the server reviewed, it would be nice if the customer did not immediately need to begin significant security-related upgrades.
We have some concern about the future of the kernel on which this server's fault tolerance depends. There have been many changes to the 2.4 kernel since 2.4.2, the version this server's kernel is based on. We were unable to obtain a clear reading of NEC's plans with respect to carrying forward its changes to later 2.4. Although there is a plan to carry forward these changes to kernel version 2.6 and beyond, and to offer Linux on other NEC fault-tolerant servers, there seems to be no announced dates associated with this plan.
NEC told us they are firmly committed to releasing all changes to the public under GPL. Until this happens, some time after this article goes to press, there is no way to evaluate how extensive NEC's changes are or what their likely fate might be, as to integration into the mainline sources for the kernel.
Our overall evaluation is favorable, but with caution. This server has more than adequate processing capacity for many applications. It is nice to be able to replace failed hardware without bringing down a system. It is nicer still to have hardware that takes itself out of service, without interrupting anything, pending a convenient time for repairs. That said, we'd advise a company considering purchase of a number of these servers to ask careful questions concerning ongoing kernel development. Also, ask about NEC's demo or “try 'n buy” programs under which you may be able to obtain one of these machines and test it hard against its intended application.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Tech Tip: Really Simple HTTP Server with Python
- Kernel Problem
1 hour 7 min ago
- BASH script to log IPs on public web server
5 hours 34 min ago
9 hours 10 min ago
- Reply to comment | Linux Journal
9 hours 42 min ago
- All the articles you talked
12 hours 6 min ago
- All the articles you talked
12 hours 9 min ago
- All the articles you talked
12 hours 10 min ago
16 hours 35 min ago
- Keeping track of IP address
18 hours 26 min ago
- Roll your own dynamic dns
23 hours 39 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?