ECCエラー監視：カーネルの検出から通知の検証まで

データベースのプロセスが予期せず終了し、同時にカーネルログにメモリエラーが記録された場合、アプリケーションを再起動してもプロセスが復旧するだけで、障害の原因は分かりません。ECCは一部のメモリエラーを訂正できますが、イベントの保存、傾向の判断、サポートチケットに添付する証跡の収集まで自動で行うわけではありません。物理サーバーの本番稼働前には、ハードウェアによる報告、カーネルでの受信、イベントの保存、監視による検知、アラートの到達まで、一連の経路を確認する必要があります。

CloudSFPのAMD EPYC 7543P物理サーバーはDDR4-3200 ECCを採用し、128GBと256GBの2構成を提供しています。以下ではDebian 12を例に、定期点検の手順を組み立てます。コマンドはゲストOSではなく、ホストOSで実行してください。取得できる情報はカーネルやファームウェアによって異なる場合があります。取得できないデータソースは個別に記録し、エラーがゼロであると扱ってはいけません。

一、エラーと監視の欠落をまず区別する

訂正可能なエラーは通常CEと表記され、そのエラーが訂正されたことを示します。訂正不可能なエラーは通常UEと表記され、その訂正機構では修復できないエラーであることを示します。実際の影響はエラーの発生箇所、カーネルの処理、影響を受けたプロセスにも左右されるため、略称だけを見て業務データが必ず無事だと判断することはできません。

CEで重視すべきなのは、増分、同じ箇所での繰り返し、発生時の負荷です。単発のイベントと同じ箇所で継続して発生するイベントでは、対応の優先度を変えるべきです。UEではデータ保護を優先し、プロセスの終了、システムの異常、既存のバックアップを確認するとともに、関連する負荷をこれ以上増やさないようにします。

「記録がない」ことを判断材料にできるのは、収集経路が正常に機能していると確認できている場合だけです。EDACディレクトリが空である、収集サービスが停止している、イベントデータベースを読み取れないといった状態は、監視の欠落であって、正常であることの証明ではありません。

ECCはデータ検証、ストレージの冗長化、バックアップの代わりにもなりません。アプリケーションが誤った結果を返した場合やファイルが破損した場合、それをメモリエラーと関連付けるには、時刻と業務上の証拠を突き合わせる必要があります。直接の因果関係があると決めつけてはいけません。

二、カーネルが実際に提供するデータソースを確認する

まず起動IDとカーネルバージョンを記録し、その後でメモリコントローラーのディレクトリとカーネルイベントを確認します。以下のコマンドは現在の状態を読み取るだけで、ドライバーのロードやハードウェア設定の変更は行いません。

uname -r
cat /proc/sys/kernel/random/boot_id
ls -ld /sys/devices/system/edac/mc
find /sys/devices/system/edac/mc -maxdepth 2 -type f \
  \( -name ce_count -o -name ue_count -o -name mc_name \) \
  -print -exec cat {} \;
sudo journalctl -k -b --no-pager \
  --grep='EDAC|MCE|Hardware Error|memory error'

ディレクトリ内のmc_nameはコントローラー名の確認に使います。ce_countとue_countは、そのコントローラーの累積カウントです。初めて読み取った値がゼロでない場合は、まず基準値として保存し、過去の累積分をすべて直近のアラートとして扱わないようにします。

ディレクトリが存在しない、またはコントローラーのエントリがない場合は、コマンドの出力を保存し、カーネルログにあるドライバーの初期化情報を確認してください。ドライバーの対応状況、ファームウェア設定、プラットフォームの報告経路によって、情報の見え方が変わる場合があります。本番サーバーで未知のモジュールを繰り返しロードして試すことは推奨しません。

カーネルログのMCEやHardware Errorも、必ずしもメモリ障害を示すとは限りません。他のハードウェアユニットに由来するイベントの可能性もあります。前後の文脈を含めて保存する必要があり、「error」を含む1行だけを抜き出して分類してはいけません。

三、rasdaemonの記録とカウントの基準値を整える

Debian 12では、ディストリビューションのパッケージを使ってrasdaemonをインストールできます。変更前に既存のサービス設定を保存し、インストール後はサービスの状態、起動引数、実際に動作しているプロセスをすべて確認します。

sudo apt-get update
sudo apt-get install rasdaemon
sudo systemctl enable --now rasdaemon
systemctl status rasdaemon --no-pager
systemctl cat rasdaemon
ps -C rasdaemon -o pid,args
sudo ras-mc-ctl --status
sudo ras-mc-ctl --summary
sudo ras-mc-ctl --errors

--statusは確認項目の一部にすぎず、システム全体の健全性を判定するものではありません。サービスログも確認し、イベントのサブスクライブ失敗、権限エラー、データベースへの書き込み問題がないか調べる必要があります。

sudo journalctl -u rasdaemon -b --no-pager

記録プロセスの稼働とディスクへの保存は別

起動引数で-rまたは--recordが有効になっているか確認し、使用中のパッケージがデータベースをサポートしていることも確かめてください。サービスが動作していても記録が永続化されていなければ、収集プロセスの再起動によって証跡が途切れる可能性があります。データベースの場所は実際のパッケージ設定に従い、他のディストリビューションのパスをそのまま当てはめないようにします。

各サンプリングでは、少なくともサーバー識別番号、起動ID、採取時刻、コントローラー名、CEとUEのカウントを保存します。カウントの増分は、起動IDとデータソースが同じ場合に限って比較してください。システムの再起動、モジュールの再ロード、カウントの減少があった場合は、基準値を取り直します。負の差分を算出してから無視する運用にはしません。

rasdaemonとEDACでは、取得対象の範囲が完全には一致しない場合があります。比較する際は、まずイベントの種類、収集開始時点、コントローラーを確認し、両者の記録総数が機械的に一致することを求めないようにします。

四、通知を積み上げるのではなく、リスクを伝える

監視は、収集経路の障害、CEの増加、UEの増加の3種類に分けることを推奨します。収集経路の障害には、サービスの停止、値の読み取り失敗、データベースのクエリエラーが含まれます。これらは独立したアラートにし、異常を数値のゼロで置き換えてはいけません。

CEの増加通知には、今回の増分、コントローラー、元のイベントを含めます。記録に位置情報のフィールドがある場合は、位置ごとに繰り返しイベントを集約できますが、すべてのサーバーに通用する「安全な回数」を定めることはしません。イベントの発生頻度、特定箇所への集中度、業務上の症状を合わせて、対応をエスカレーションするか判断します。

UEが増加した場合は優先度を上げ、発生時の状態を保存してから業務データの整合性を確認します。障害をさらに確かめるためのストレステストは行わず、カウントを消す目的で先にサーバーを再起動することも避けてください。

アラート経路の検証には、オフラインのサンプルを使えます。前後2つのカウント入力を用意し、増分ゼロ、CEの増加、UEの増加、読み取り失敗、起動IDの変更をそれぞれ検証します。テスト通知には訓練であることを明記し、監視パーサーへの入力だけに使用して、実際のハードウェアイベントデータベースには書き込みません。

本番サーバーでは、エラー注入による通知の受け入れ検証は行いません。通知テストの成功で確認できるのは、解析と通知の配信が機能することだけです。ハードウェアイベントをカーネルが受信できるかどうかは、ドライバーの状態、イベントソース、実際の記録に基づいて別途確認する必要があります。

五、ハードウェア調査につながる証跡を残す

エラーが繰り返し発生したら、まず現在の起動期間のカーネルログ、rasdaemonのサービスログ、イベントの照会結果をエクスポートし、その後でカウントのスナップショットを保存します。証跡を置くディレクトリのアクセス権限を制限し、サポートチケットにファイルを添付する前に、アドレス、アカウント情報、業務上の機密情報が含まれていないか確認してください。

サポートチケットには、次の順序で情報を整理します。

• サーバー識別番号、OSとカーネルのバージョン、起動ID。
• 最初に検知した時刻と明示的なタイムゾーン、エラーが継続して増加しているかどうか。
• CEとUEの元のイベント、前後のカウント。アラートのスクリーンショットだけにしないこと。
• 報告に含まれるコントローラーと位置情報のフィールド。欠けているフィールドは、その旨を明記すること。
• 同時期の業務上の症状、すでに実施した操作とその結果。

イベントに含まれるDIMMラベルやアドレスを、独自に物理スロット番号へ換算してはいけません。プラットフォームによって対応関係が異なる可能性があります。ハードウェアの特定は、サポート担当者がサーバー情報と照合して行います。利用者はOS、業務データ、バックアップの保護を担います。

定期点検の最終成果物は、すべてが緑色になったスクリーンショットではありません。再確認できる基準値、明確なデータソースの取得範囲、訓練済みのアラート経路、十分な障害証跡です。カーネル更新やサーバー再起動の後には、これらの条件を改めて確認し、収集機能の停止をエラーの解消と取り違えないようにしてください。

よくある質問