CATERRはプロセッサよりアサートされるCatastrophic Errorのことです。
本エラーが発生した場合、SEL(System Event Log)ログに以下のようなメッセージが記録され、サーバがハングアップ、クラッシュ、自動リブートなどの現象が発生する可能性があります。
Processor CATERR_N #0xxx | Predictive Failure asserted | Asserted
CATERRは以下のような様々な要因で起きる可能性があります。
・Uncorrectable ECC Memory Error
・ハードウェア不良
・BIOS設定
・ファームウェア
・ドライバ
・OS
そのため、ハードウェア障害ではない可能性もありますので、トラブルシューティングを行う必要があります。
本ドキュメントではCATERR発生時の確認リストと取得する必要があるログについて説明します。
－確認リスト:
[一連の現象についての確認事項]
1.本サーバで以前同じ現象が発生したことがあるか。複数回発生したのか。
複数回発生した場合、発生日時も確認。
2.本サーバのハードウェアを交換したことがあるか。
3.ほかの同じ構成、設定、ワークロードのサーバで同じような現象が発生したことがあるか。
4.1台のみの現象か、複数サーバでの現象か。
[OS関連の確認事項]
1.OSバージョンとドライババージョン。
以下のサイトからCompatibilityを満たしているか確認できます。
「UCS Hardware and Software Compatibility」
https://ucshcltool.cloudapps.cisco.com/public/#
2.ホストでどのアプリケーションを運用しているか。
3.現象発生したタイミングで、何かスケジュールを組んだ、もしくは繰り返し実施のタスクが走っていたか。
4.サーバがクラッシュした時に特定のアクションを実行していたか。そのアクションは繰り返し実施可能か。
例：一度に多数のVDI VMをデプロイ。バックアップジョブの実行など。
5.ハイパーバイザーを使用している場合、その上で実行しているVMの数とVMのOSバージョンはいくつか。
[症状関連の確認]
1.現象はハングアップ（KVM上OS画面が見えるか反応なし）か、自動再起動か、それともPSOD/BSODか。
2.CATERRの発生時間はOS稼働中か、POST時か、それとも特殊タスク実行中か。
－ハードウェアログ取得：
[Bシリーズ]
サーバでWarm rebootを実施の上、ログを取得します。
※Warm bootの実施方法は以下のどちらかとなります。
・UCSMから該当サーバのreset項目を押し、"Gracefully restart OS"を選択して実施。
・KVMコンソールからResetを実施。
ログ収集方法：
UCS Manager (UCSM) の GUI で Technical Support ログを作成する方法 （HTML5版）
https://community.cisco.com/t5/-/-/ta-p/3228519
[Cシリーズ]
サーバでWarm rebootを実施の上、ログを取得します。
※Warm bootの実施方法は以下のどちらかとなります。
・CIMCのHost PowerからHard Resetを選択して実施。
・KVMコンソールからReset System(Warm Boot)を実施。
ログ収集方法：
[UCS C] CIMC 3.0(X) にてテクニカルサポートデータを取得する方法
https://community.cisco.com/t5/-/-/ta-p/3165617
なお、上記Warm rebootの手順で有効なMCAログが取得出来ていない場合も稀にあり、
その際は2～3回程Warm rebootを実施する必要があります。
－OSログ取得：
[VMware]
1.Vmware - ESXi vm-support bundleログを取得。
「VMware 製品の診断情報の収集 (1010705)」
https://kb.vmware.com/s/article/1010705?lang=ja
2.ダンプファイルが作成されている場合はダンプファイルを収集。
VMwarezdumpでMCE（Machine Check Exception）が収集される場合があります。
ダンプファイルを適切に作成するには、ESXiを手動で構成する必要があります。
「ESXi のコアダンプをパーティションではなくファイルに構成する (2077516)」
https://kb.vmware.com/s/article/2077516?lang=ja
3.PSOD画面のスクリーンショットを取得。
[Red Hat Linux]
1.Linux SOSReportログを取得。
「Red Hat Enterprise Linux 上での sosreport の役割と生成方法」
https://access.redhat.com/ja/solutions/78443
2.通常mcelogデーモンはデフォルトでインストールおよび実行され、MCE（Machine Check Exception）が/var/log/mcelogに保存される場合はそれを収集。
mcelogが書き込まれていない場合、プロセスが自動的に実行されるように構成されていない可能性があり、以下の手順でmcelogのインストール/構成する必要があります。
「mcelog とは何ですか? どのようにインストールしますか?」
https://access.redhat.com/ja/solutions/2971881
[Windows]
1.Windows イベントログ（システム、アプリケーション）とシステム情報（msinfo32）を取得。
「Windows OSに関するサポート時に必要となる情報の取得方法」
https://community.cisco.com/t5/-/-/ta-p/3157926
2.Windows dump fileが作成されている場合はWindows dump fileを収集。
memory dumpが収集できるように構成する必要があります。
「Overview of memory dump file options for Windows」
https://docs.microsoft.com/en-us/troubleshoot/windows-server/performance/memory-dump-file-options
3.BSOD画面のスクリーンショットを取得。
-ログ取得後、HW Diagnosticsを実施
［UCSM管理サーバのHW Diagnostics実施手順］
以下のドキュメントをご参考ください。
「UCSMで管理しているサーバのHW Diagnostics実施手順」
https://community.cisco.com/t5/-/-/ta-p/4273064
［スタンドアロンラックサーバのHW Diagnostics実施手順］
以下のドキュメントをご参考ください。
「[UCS C] UCS Server Diagnostics Utilityについて」
https://community.cisco.com/t5/-/-/ta-p/4266011
