So, having returned from a month's vacation, I'm back to work on attempting to build a set of small form factor CentOS compatible computers. I've really tried to do my homework, but this doesn't appear (at first glance) to be at all easy. It's not made easier by the fact that I have to get it right the first time (and I haven't built a PC in a decade); the time and money cost of shipping anything to and from my remote location in Chile means I can't afford to waste time buying and returning things.
First question: does anyone have any experience with the Jetway NF9E-Q77 or ZOTAC Z77ITX-A-E motherboards? Having struck out on Intel Q77 or Z77-based SFF motherboards (the DQ77** series is completely out of stock everywhere, and the DZ77** series is ATX only), I have found a couple of Mini-ITX systems based on these two motherboards.
Second question: Where can I get information about which Intel chipsets (Z77 vs Z87 vs Q77 vs C602 vs ...geez, there are a LOT of chipsets, as evidenced by http://www.supermicro.com/support/faqs/os.cfm) are supported by CentOS 6 / RHEL 6? I have not been able to find this information on either the Intel, RedHat, or CentOS web sites.
Third (more general) question: My requirements are (I believe) modest: * 1U short-depth rackmount chassis OR Mini-ITX small-footprint chassis * Dual GbE network ports * Dual 1920x1200 monitor display * One SSD drive * 32-bit CentOS 6.4 compatible.
It's the combination of the first, third, and fifth requirements that really seems to get me hung up. I've found plenty of 1U server systems (such as SuperMicro), but none of them support dual displays. (Some of them have a PCIe16x riser card that could conceivably accomodate a separate graphics card, assuming I could find one that fits; I have Emails in to various tech supports to inquire about this. I've found LOTS of 2U solutions, thanks, but only have 1U of available rack.) As far as Linux support goes, the RHEL Hardware List has thus far been pretty useless (much of the hardware on it is obsolete or discontinued), and most manufacturers' web sites have been equally useless. (One exception being ASUS, which has a Linux-compatibility list at http://www.asus.com/websites/global/aboutasus/OS/Linux.pdf SuperMicro has a very nice list referenced above, but none of their small form factor motherboards support dual displays AFAICT; I have found nothing useful at Intel's site.)
Does anyone have any resources they'd like to point me to?
Thanks, -G. -- Glenn Eychaner (geychaner@lco.cl) Telescope Systems Programmer, Las Campanas Observatory
Glenn Eychaner wrote:
So, having returned from a month's vacation, I'm back to work on attempting to build a set of small form factor CentOS compatible
computers. I've
really tried to do my homework, but this doesn't appear (at first glance) to be at all easy. It's not made easier by the fact that I have to get it right the first time (and I haven't built a PC in a decade); the time and money cost of shipping anything to and from my remote location in Chile means I can't afford to waste time buying and returning things.
First question: does anyone have any experience with the Jetway NF9E-Q77 or ZOTAC Z77ITX-A-E motherboards? Having struck out on Intel Q77 or
Z77-based
SFF motherboards (the DQ77** series is completely out of stock everywhere, and the DZ77** series is ATX only), I have found a couple of Mini-ITX systems based on these two motherboards.
Second question: Where can I get information about which Intel chipsets (Z77 vs Z87 vs Q77 vs C602 vs ...geez, there are a LOT of chipsets, as evidenced by http://www.supermicro.com/support/faqs/os.cfm) are supported by CentOS 6 / RHEL 6? I have not been able to find this information on either the Intel, RedHat, or CentOS web sites.
<snip> VERY STRONG RECOMMENDATION: DON'T buy Supermicro. They have a *lot* of trouble with this new, fuzzy concept called "quality control".
For example, we have a cluster with 21 Penguin servers, about half with 48 cores, and the rest with 64 cores. You'd think this kind of hot, high end server would call for a lot of attention.
No. We've sent back to Penguin at *least* 5 or 6, and a couple of those went back *twice*, and almost all had m/b's replaced, and one a CPU, I think. That's an absurdly high percentage....
Now, about what you're looking to build - you say that you want 1U, and mention rackspace: in my experience, rackmounts are a *lot* larger than a pizza box, so I'm a little confused at the requirements you're building for.
mark
On 8/12/2013 11:01, m.roth@5-cent.us wrote:
VERY STRONG RECOMMENDATION: DON'T buy Supermicro. They have a *lot* of trouble with this new, fuzzy concept called "quality control".
We have a *lot* of SuperMicro based systems in the field, and they aren't failing. In fact, I can't remember the last time we had to fix an actual motherboard issue. It seems like every field hardware failure for years has come down to dying HDDs.
We did once upon a time have a QC problem with SuperMicro, around Y2K, but that was because we chose to use AMD processors, and AMD OEM fan/heat sink combos at the time used little 60mm 6000 RPM pancake fans that would seize up after a few years. This was before processors had overtemp shutdown features, so once the fan seized, the processors would cook themselves.
You can't really lay that one at SuperMicro's feet. AMD screwed up.
The real fix was switching back to Intel processors, which shipped with bigger and slower-moving fans, which lasted longer.
You'll notice that both of these failure modes are due to mechanical wear. I can't say I've *ever* seen a SuperMicro board fail in any of the solid-state components, solder joints, capacitors, etc.
Warren Young wrote:
On 8/12/2013 11:01, m.roth@5-cent.us wrote:
VERY STRONG RECOMMENDATION: DON'T buy Supermicro. They have a *lot* of trouble with this new, fuzzy concept called "quality control".
We have a *lot* of SuperMicro based systems in the field, and they aren't failing. In fact, I can't remember the last time we had to fix an actual motherboard issue. It seems like every field hardware failure for years has come down to dying HDDs.
We did once upon a time have a QC problem with SuperMicro, around Y2K, but that was because we chose to use AMD processors, and AMD OEM fan/heat sink combos at the time used little 60mm 6000 RPM pancake fans that would seize up after a few years. This was before processors had overtemp shutdown features, so once the fan seized, the processors would cook themselves.
<snip>
You'll notice that both of these failure modes are due to mechanical wear. I can't say I've *ever* seen a SuperMicro board fail in any of the solid-state components, solder joints, capacitors, etc.
Well, *all* of these are rackmount servers, with no moving-the-server wear. We start seeing userspace compute-intensive processes crashing the system a number of times a day. We have a canned package that we send to Penguin on the disk we put in, which has a generic CentOS install, and running that, the crash is repeatable. They replace the m/b, and it doesn't happen again. (Or at least with that program - we've got issues with some *other* users, with different software, that seem to be crashing it. With us, this is seriously important, since the users' jobs run for days, sometimes a week or more, on the cluster....
mark
On 8/12/2013 12:54, m.roth@5-cent.us wrote:
Well, *all* of these are rackmount servers, with no moving-the-server wear.
Our servers are all rack-mounted, too, and pretty much never get moved after being installed.
In any case, I was referring to wear in the electromechanical components of a server. HDDs and fans, primarily. In olden days, optical disks, too. These are expected to fail over time.
We start seeing userspace compute-intensive processes crashing the system a number of times a day.
Define "crash the system".
Hard lock-up, requiring a power toggle or Reset press?
Server unresponsive to keyboard, except for Ctrl-Alt-Del?
Kernel panic?
X11 unresponsive but you can still ssh in?
User program dies mysteriously, but other programs still run?
Keyboard lights blink in patterns, monitor won't wake on mouse wiggle?
Box reboots spontaneously?
BIOS beeps?
I don't suppose you've gathered continuous temp data, say with Cacti?
They replace the m/b, and it doesn't happen again.
Okay, so either this one motherboard product from Supermicro has a QC problem, or Penguin has an application or design problem with it. Or, your environment is somehow pushing them past their design limits. (e.g. insufficient cooling)
You're painting with far too broad a brush here to say Supermicro is bad, period.
On 08/12/13 18:16, Warren Young wrote:
On 8/12/2013 12:54, m.roth@5-cent.us wrote:
Well, *all* of these are rackmount servers, with no moving-the-server wear.
Our servers are all rack-mounted, too, and pretty much never get moved after being installed.
In any case, I was referring to wear in the electromechanical components of a server. HDDs and fans, primarily. In olden days, optical disks, too. These are expected to fail over time.
We start seeing userspace compute-intensive processes crashing the system a number of times a day.
Define "crash the system".
The whole system reboots. <snip>
I don't suppose you've gathered continuous temp data, say with Cacti?
No, I haven't. It's a thought, thought the HVACs good (too good, he says, when he needs a long sleeved shirt, and sometimes a sweater). ipmitool sel list isn't showing a problem.
They replace the m/b, and it doesn't happen again.
Oh, except for the one or two that we sent back a *second* time, and they replaced the m/b again....
Okay, so either this one motherboard product from Supermicro has a QC problem, or Penguin has an application or design problem with it. Or, your environment is somehow pushing them past their design limits. (e.g. insufficient cooling)
That's certainly not the problem.
You're painting with far too broad a brush here to say Supermicro is bad, period.
You like them, fine. We really don't, and the only thing that we were buying that had their m/b, etc, were honkin' hot severs.
mark
On 12.08.2013 20:42, Warren Young wrote:
On 8/12/2013 11:01, m.roth@5-cent.us wrote:
VERY STRONG RECOMMENDATION: DON'T buy Supermicro. They have a *lot* of trouble with this new, fuzzy concept called "quality control".
We have a *lot* of SuperMicro based systems in the field, and they aren't failing. In fact, I can't remember the last time we had to fix an actual motherboard issue. It seems like every field hardware failure for years has come down to dying HDDs.
We did once upon a time have a QC problem with SuperMicro, around Y2K, but that was because we chose to use AMD processors, and AMD OEM fan/heat sink combos at the time used little 60mm 6000 RPM pancake fans that would seize up after a few years. This was before processors had overtemp shutdown features, so once the fan seized, the processors would cook themselves.
You can't really lay that one at SuperMicro's feet. AMD screwed up.
The real fix was switching back to Intel processors, which shipped with bigger and slower-moving fans, which lasted longer.
You'll notice that both of these failure modes are due to mechanical wear. I can't say I've *ever* seen a SuperMicro board fail in any of the solid-state components, solder joints, capacitors, etc.
Same here. We have several racks full if Supermicro systems and never had any issues with them.
Regards, Dennis
On 8/12/2013 9:14 AM, Glenn Eychaner wrote:
- 1U short-depth rackmount chassis OR Mini-ITX small-footprint chassis
...
- Dual 1920x1200 monitor display
those two requirements together are unusual. most rackmount 1U systems are headless, except a basic VGA for initial configuration.
dual display is generally found on a desktop system.
On Mon, Aug 12, 2013 at 12:14 PM, Glenn Eychaner geychaner@mac.com wrote: [snip]
Third (more general) question: My requirements are (I believe) modest:
- 1U short-depth rackmount chassis OR Mini-ITX small-footprint chassis
- Dual GbE network ports
- Dual 1920x1200 monitor display
- One SSD drive
- 32-bit CentOS 6.4 compatible.
For the display configuration, do you need to run any graphics-intensive software? If not, I have seen some devices that act as miniature broadcast devices. The monitors don't need to be physically attached to the system unit. They do need some sort of wireless access to the server though. They are useful for monitoring stations, electronic signage, etc.., but not so good for fast updates (i.e., no games, videos would probably be degraded).
-
Dennis Jacobfeuerborn -
Glenn Eychaner -
John R Pierce -
Kwan Lowe -
m.roth＠5-cent.us -
mark
-
Warren Young