修正不可能なECCエラーとフォールバック方法の評価
以前に発生したことのないエラーが発生したばかりのサーバーを実行しています。ビープ音が数回鳴り、再起動して、起動画面（BIOSがロゴを表示し、情報の一覧表示を開始する部分）で次のエラーで止まってしまいました。
Node0：DRAMの訂正不可能なECCエラー
ノード1：HTリンクSYNCエラー
ハードリセット後、システムは正常に起動し、edac-utilに関する情報はまだ報告されていません。
私の調査によると、ECCメモリとシステムが理想的な状態であっても、修正不可能なエラーが発生する可能性があり、システムの寿命のある時点で発生する可能性があります。一部の報告では、少なくとも年に1回またはそれより早く提案しています。
サーバーは、いくつかのECCモジュールを備えたCentOS6.5を実行します。私はすでに、どのモジュールがエラーをスローしたかを診断して、これが障害なのか、宇宙線などの不可避なものの結果なのかを評価しようとしているところです。
私の調査では、システムがこのように停止した場合、ログが書き込まれる場所はなく、これを行う唯一の信頼できる方法は、シリアルポートを介してログが書き込まれている別のシステムに接続することです。
通常のedac-util、memtest、ストレステスト、および予防的交換以外に、このエラーに対処するときに考慮すべきことはありますか？
検索したCentOSログでこのクラッシュの記録を見つけることができませんでした。これは、このエラーをローカルディスクに記録することはできないという私の信念と一致しています。エラーは、自動再起動後にBIOSによってのみ報告されました。これらの種類のエラーを記録するために、システムログを常にシリアルに書き込むことをお勧めしますか？
この種の障害は単一のシステムを使用して回避できますか、それとも高価なエンタープライズソリューションを使用した場合にのみ可能ですか？
単一の本番サーバーでこれらの障害が発生した場合にフォールバック対策を提供するにはどうすればよいですか。のように、本番サーバー自体は複数のマシンにまたがることはありませんが、フォールバックサーバーが存在する可能性があります。
これは、システムがクラッシュするのをどのように止めたかを共有するための回答ですが、元の質問には対応していません。私はまだ解決策を研究していて、私がそれを学ぶとき、私が思いついた新しい情報を共有します。
システムは、64GB（16x4）ハイニックス、32GB（16x2）バイキングラムを搭載したSupermicro H8SGL-Fマザーボードを搭載したホワイトボックスです。マザーボードの仕様では、プロセッサはクアッドチャネルメモリコントローラを使用しているため、RAMモジュールは4個セットで取り付ける必要があるとされています。私は余分な2つのバイキングモジュールを投入して、それが機能するかどうかを確認しました。このソリューションは数か月間機能しましたが、私の最初の間違いでした。
2つ目の間違いは、RAMを誤ってインストールしたことです。メモリスロットは色分けされており、クアッドチャネル設定用にインターリーブされています。私は次のようにRAMをインストールしました：
[ ========== ] 16GB Hynix
[ ---------- ] 16GB Hynix
[ ========== ] 16GB Hynix
[ ---------- ] 16GB Hynix
[ ========== ] 16GB Viking
[ ---------- ] 16GB Viking
[ ========== ]
[ ---------- ]
このセットアップは数か月間機能し、最近問題が発生し始めたばかりですが、モジュールに実際に問題があるかどうかの仕様外のレイアウトで問題を引き起こしている容量の増加が原因であるかどうかはわかりません。
私は本番システムが1つしかなかったので、すべてのモジュールを取り外し、2つをペアにして（まだ仕様外です）回転させ始め、数週間、システムを少ない容量で実行しました。クラッシュは発生せず、edac-utilからのeccエラーの報告もありませんでした。ただし、障害のあるモジュールが2番目のスロットにあり、単にアクセスされなかったために障害が発生した可能性があります。
ラムを回転させてもエラーを再現できなかった後、ラムを正しく設定していないことに気付きました。バイキングモジュールを削除し、次のように新しいレイアウトを設定しました。
[ ========== ] 16GB Hynix
[ ---------- ]
[ ========== ] 16GB Hynix
[ ---------- ]
[ ========== ] 16GB Hynix
[ ---------- ]
[ ========== ] 16GB Hynix
[ ---------- ]
この変更を行ってから、システムは安定したままでした。ただし、仕様に合わせているにもかかわらず、これは、障害がレイアウトにあるのか、バイキングモジュールにあるのか（削除されたため）、または問題のあるモジュールが、アクセス頻度が十分に低いレイアウトのさらに下にあるHynixモジュールの1つにすぎないのかどうかを確認しません。過失ではありません。
この回答を問題の結論としてではなく、私が全体的な問題に対処するために取った一歩として見てください。私はまだ終わっていません。解決策を探し続けているので、報告を続けます。
また、メモリを新しいレイアウトに設定して以来、昨日初めてシステムの電源が再投入されました。これが対処されたメモリの問題によるものなのか、それとも電源の別の問題なのかを確認できないので、これまでのところ、この1つのインシデントを一粒の塩と見なしてください。
まあ、これはHP、Dell、IBMサーバーのような完全に統合されたシステムではないので、そのような障害の監視と報告は存在しないか、一貫性がありません。
私が管理しているシステムでは、ディスクが最も頻繁に故障し、次にRAM、電源、ファン、システムボード、CPUが故障します。
メモリが失敗する可能性があります...それについてできることはあまりありません。
参照： サーバークラスのハードウェアの場合、バーンインRAM）する必要がありますか？
あなたは本当にECCエラーとRAM障害を防ぐことができないので、それのために準備してください。スペアを保管してください。システムに物理的にアクセスし、コンポーネントの保証を維持してください。私は間違いなく「予防交換」を環境に導入しますこれの一部はハードウェアの機能です... IPMIを持っていますか？時々ハードウェアログがそこに行き着きます。
これは、より優れたサーバーハードウェアの付加価値の1つです。 RAMのECCしきい値を超えた後、無効になっているDIMMに進んだHP ProLiant DL580 G4サーバーからのスニペットを次に示します。最後にサーバーがクラッシュ（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
DIMMに修正不可能なエラーがある場合は、交換することをお勧めします。それが低率で修正可能なエラーのみである場合、おそらくそれと一緒に暮らすことができ、いずれにせよ修正可能なエラーについては、払い戻しを受けるのが難しくなります。
レコードがあるかどうかを確認する場合は、ipmitool sel elistまたは同等のツールを使用して、IPMI SELレコードにアクセスしてみてください。
もう1つの方法は、dmesgを起動して保存するようにLinuxクラッシュカーネルを設定することです。これにより、ハードウェア障害に関する情報も取得できます。
3番目の方法は、サーバーのシリアルコンソールを永続的な場所に記録することです。これには、ソフトウェアまたはハードウェアの種類のサーバークラッシュの手がかりも含まれます。