我运行的服务器刚刚遇到了一个我以前从未遇到过的错误。它发出几声哔哔声，重新启动，然后卡在启动屏幕（BIOS 显示其徽标并开始列出信息的部分），并出现错误：
Node0：DRAM 不可纠正的 ECC 错误
节点 1：HT 链路同步错误
硬重置后，系统启动正常，并且尚未在 edac-util 上报告任何内容。
我的研究告诉我，即使使用 ECC 内存和处于理想条件的系统，仍然可能出现无法纠正的错误，并且很可能在系统的使用寿命期间的某个时间点发生；一些报告表明至少每年一次或更早。
服务器运行带有多个 ECC 模块的 CentOS 6.5。我已经开始尝试诊断哪个模块引发了错误，以评估这是一个故障还是某种不可避免的事情（例如宇宙射线）的结果。
我的研究还表明，当系统像这样停止时，没有地方可以写入日志，而唯一可靠的方法是将系统连接到另一个系统，并通过串行端口写出日志。
除了常见的 edac-util、memtest、压力测试和预防性更换之外，在解决此错误时还应该考虑什么？
在我搜索的所有 CentOS 日志中，我都找不到关于这次崩溃的任何记录，这与我认为不可能将此错误记录到本地磁盘的想法一致。只有在自动重启后，BIOS 才会向我报告此错误。是否建议始终将系统日志写入串行以记录此类错误？
使用单一系统是否可以避免这种故障，还是只有使用昂贵的企业解决方案才有可能？
我该怎么做才能为单个生产服务器在这些故障情况下提供后备措施；因为生产服务器本身并不跨越多台机器，但可以存在后备服务器。
答案1
嗯，这不是像 HP、Dell 或 IBM 服务器那样的完全集成的系统，因此这种故障的监控和报告不会出现或不一致。
在我管理的系统中，磁盘故障最常见，其次是 RAM、电源、风扇、系统板和 CPU。
记忆可能会失败......对此你无能为力。
由于您无法真正防止 ECC 错误和 RAM 故障，因此请做好准备。保留备用件。物理访问您的系统并维护组件的保修。我绝对不会在环境中引入“预防性更换”。其中一些是硬件的功能...您有 IPMI 吗？有时硬件日志会出现在那里。
这是更好的服务器硬件的附加值之一。以下是 HP ProLiant DL580 G4 服务器的片段，其中 RAM 上的 ECC 阈值被超出，然后发展到 DIMM 被禁用...最后服务器崩溃（ASR）并重新启动，损坏的 DIMM 被停用。
0004 Repaired 22:21 12/01/2008 22:21 12/01/2008 0001
LOG: Corrected Memory Error threshold exceeded (Slot 1, Memory Module 1)
0005 Repaired 20:41 12/06/2008 20:43 12/06/2008 0002
LOG: POST Error: 201-Memory Error Single-bit error occured during memory initialization, Board 1, DIMM 1. Bank containing DIMM(s) has been disabled.
0006 Repaired 21:37 12/06/2008 21:41 12/06/2008 0002
LOG: POST Error: 201-Memory Error Single-bit error occured during memory initialization, Board 1, DIMM 1. Bank containing DIMM(s) has been disabled.
0007 Repaired 02:58 12/07/2008 02:58 12/07/2008 0001
LOG: POST Error: 201-Memory Error Single-bit error occured during memory initialization, Board 1, DIMM 1. Bank containing DIMM(s) has been disabled.
0008 Repaired 19:31 12/08/2009 19:31 12/08/2009 0001
LOG: ASR Detected by System ROM
答案2
如果 DIMM 有无法纠正的错误，我建议更换它。如果只是可纠正的错误，而且发生率很低，您可能可以忍受，而且无论如何，对于可纠正的错误，获得退款会比较困难。
如果您想查看是否有记录，请尝试使用ipmitool sel elist或等效工具访问 IPMI SEL 记录。
另一种选择是设置一个 Linux 崩溃内核来启动并保存 dmesg，这也可以捕获有关硬件故障的信息。
第三种选择是将服务器的串行控制台记录到某个持久的地方，它还将包含软件或硬件服务器崩溃的线索。
答案3
这是关于我如何阻止系统崩溃的答案，但并未解决原始问题。我仍在研究解决方案，并将在学习过程中分享我获得的任何新信息。
该系统是一个白色盒子，配有 Supermicro H8SGL-F 主板、64GB (16x4) Hynix、32GB (16x2) Viking 内存。主板规格说明，由于处理器使用四通道内存控制器，内存模块必须以四个为一组安装。我把额外的两个 Viking 模块放进去看看是否有效，结果确实有效。这个解决方案有效了几个月，但这是我的第一个错误。
我的第二个错误是我没有正确安装内存。内存插槽采用颜色编码，并交错排列，以适应四通道设置。我是这样安装内存的：
[ ========== ] 16GB Hynix
[ ---------- ] 16GB Hynix
[ ========== ] 16GB Hynix
[ ---------- ] 16GB Hynix
[ ========== ] 16GB Viking
[ ---------- ] 16GB Viking
[ ========== ]
[ ---------- ]
虽然这种设置确实工作了几个月，而且最近才开始出现问题，但我无法确定故障是否是由于容量增加导致我的超出规格的布局出现问题，或者模块是否真的存在问题。
由于我只有一个生产系统，我移除了所有模块，并开始以两个为一对轮换它们（仍然超出规格），并以降低的容量运行系统数周。我没有收到崩溃，也没有来自 edac-util 的 ecc 错误报告。但是，可能有故障模块位于第二个插槽中，只是没有被访问，从而导致故障。
在旋转内存未能重现错误后，我意识到内存设置不正确。我移除了 Viking 模块并设置了新的布局，如下所示：
[ ========== ] 16GB Hynix
[ ---------- ]
[ ========== ] 16GB Hynix
[ ---------- ]
[ ========== ] 16GB Hynix
[ ---------- ]
[ ========== ] 16GB Hynix
[ ---------- ]
自从我做了这个改变后，系统就一直保持稳定。尽管符合规格，但这并不能确认故障是出在布局上，还是出在 Viking 模块上（因为它们已被移除），或者故障模块是否只是布局中较靠下的 Hynix 模块之一，该模块很少被访问，因此不会发生故障。
请将此答案视为问题的结论，而不是我为解决总体问题而采取的措施。我还没有完成，我会继续报告，并继续寻找解决方案。
另外值得注意的是，自从我将内存设置为新布局以来，昨天系统第一次进行电源循环。我无法确认这是由于内存问题正在解决还是电源问题，因此到目前为止，对这一事件持怀疑态度。