ECCと非ECCサーバーメモリの比較

01

メモリを選択する前に結果を分類する

プロセッサファミリーではなくデータパスから始めます。誤ったメモリ内の値がデータベースにコミットされたり、ストレージメタデータに書き込まれたり、署名されたり、他のノードに複製されたり、不可逆的な決定に使用されたりする可能性があるかどうかを尋ねてください。出力が耐久性があり検証が難しいほど、ECCの必要性が高まります。成果物が独立して検証される使い捨てビルドランナーは、データベースプライマリやストレージホストとは異なる結果をもたらします。

可用性と整合性は別物です。ステートレスサービスの再起動は安価かもしれませんが、誤った成果物を黙って出力することはそうではないかもしれません。逆に、ECCは1台のホストを高可用性にするわけではありません。最大許容データ損失、中断、未検出エラーの影響を3つの異なる要件として記録してください。

02

完全なメモリパスを確認する

ECC は実装されたパスの特性であり、DIMM のステッカー単独の特性ではありません。プロセッサのメモリコントローラ、マザーボード、ファームウェア設定、搭載モジュールが意図したモードをサポートしている必要があります。オペレーティングシステムも、訂正済みおよび未訂正のイベントを監視に届けるための適切な報告パスが必要です。サーバークラスのプロセッサ名から ECC を推測せず、一般的なインベントリフィールドを訂正が有効である証拠として扱わないでください。

カタログエントリが明示的にECCとラベル付けされている場合は、その仕様を注文記録とともに保持してください。リストがDDR4またはDDR5のみを示している場合は、ECCが必須の場合に確認を要求してください。プロビジョニング後、プラットフォームに適したファームウェアとオペレーティングシステムの証拠を検査してください。Linux EDACは、ハードウェアとドライバーがサポートしている場合、修正済みイベントと未修正のメモリコントローライベントを区別します。カウンターがないことだけでは、イベントが発生しなかったことやレポートが利用可能であることを証明しません。

• LinuxカーネルEDACドキュメント ↗

03

メモリイベントをオペレーターアクションに変える

アラートの前に応答を定義します。デプロイ後にベースラインを取得し、修正済みおよび未修正のイベント数を保持し、プラットフォームが公開する場合はホスト、ソケット、またはモジュールの場所を添付します。修正済みイベントはメカニズムがエラーを検出して修正したことを意味し、有用な運用証拠ですが、増加または繰り返しパターンを無視する理由にはなりません。未修正イベントは、マシンが動作し続けていても、迅速なワークロードとデータ整合性の評価が必要です。

普遍的なしきい値を公開するのではなく、再発、集中、ワークロードの影響を中心にエスカレーションを設定してください。ハードウェアベンダーとプラットフォームは異なり、単一の数字ですべてをカバーすることはできません。ランブックには、誰がワークロードをドレインするか、診断をいつ収集するか、データをどのようにチェックするか、ホストをサービスに戻す前にどのような証拠が必要かを記載する必要があります。

04

ECCがカバーしないものを知る

ECC はファイルシステムのチェックサム、アプリケーションの検証、レプリカ、バージョン管理されたバックアップを置き換えるものではありません。それ自体ではソフトウェアのバグ、有効として受け入れられた不正な書き込み、侵害された資格情報、削除、コントローラ障害、シャーシの損失を修正できません。メモリ診断は一部の現在の障害を見つけることができますが、将来の障害が決して発生しないことを保証することはできません。

この演習の期待される結果は、短い決定記録です：結果クラス、ECC要件、構成の証拠、監視ソース、インシデント対応。その記録は、すべてのワークロードにECCが必要であるとか、非ECCメモリはリスクがないという包括的な主張よりも有用です。