eccvirtual-machinesxeon
I'm on a quest of building a virtualization server. However, I was asking myself a question: should I stick with non-ECC RAM for this server or not?
This because I found a Xeon CPU that falls in the budget I was given. However, if I want to have a CPU that supports ECC RAM, it goes out of the current budget for this.
The server will run around 10 virtual machines 24/7, with Linux and Windows virtual machines mixed.
Any oppinions about this?
After trying various types of memory, I am convinced that the memory controller of the Fujitsu Primergy TX150 S7 chokes on the databus-width of the individual DRAM chips.
The memory chips that the server came with, and that ultimately worked, all had a databus width of x8 (2Rx8).
That you can't mix ranks (1R and 2R), ECC, buffered and unregistered memory was clear, but I did not think that the databus width of the individual chips would matter. Up to now I thought that less databus width simply meant more chips on the RAM bar (and most sites I found on the internet describe the difference between 2Rx4 and 2Rx8 as being simply more/less chips on the RAM, and no other effect).
However, none of the memory chips with x4 (2Rx4) work in the TX150 S7, even though they work fine in other servers, and any of the x8 (2Rx8) do work, making it fairly obvious.
Today I found out that there is a commercial version of memtest86 (without the +) from PassMark that offers a free version too which thankfully included ECC-Checks.
In addition it also supports DDR4 and all the other features of memtest86+.
My result seem to be positive for ECC support, so I will call this done, even though I was hoping to get the same result with "traditional" tools like dmidecode.
If someone stumbles upon this post at a later point in time and needs further validation and tests, they also offer a paid version that supports ECC error injection for actually testing the ECC capabilities.
Best Answer
That depends on whether you're fine with a higher risk of in-memory corruption.
ECC in no way totally guarantees that all errors will be corrected or detected - but it does a pretty good job of detecting and even correcting quite a few types of failures. This is especially relevant if your stack is running on a single node rather than HA/replicated across more than one. If you only have one pool of memory that acts as a single source of truth, you better make it a good one.
That said, it's all about the use case. Let's say you get a module goes bad (or it's fine and you live close to a star) and you start to corrupt data silently (we're not using ECC here). Does it affect your business if some data gets lost or mangled before the condition is detected? In most cases, it does - so it's worth spending a bit more money on hardware to mitigate the possibility in those cases.
In general, applications and their developers rely heavily on the reliability of the datapath. Is a less reliable stack going to waste a significant amount of administrator and developer time? That could end up being more expensive than just buying better hardware.
Some of this is mitigated if your infrastructure is clustered and replicated, since there are many storage and application systems out there than can perform checksumming of a dataset that spans multiple hardware nodes. One bad node doesn't necessarily spoil the bunch in these systems, so at some scales you can afford to reduce per-node redundancy and error checking. It doesn't sound like this is the situation, though.