内容

概要

前提条件

要件

必要なログファイル

ログを分析して最初の手がかりを探す

UCSの設定に関する情報の収集

FIを予防的に監視するための提案

関連情報

概要

このドキュメントでは、Unified Computing System(UCS)ファブリックインターコネクト(FI)のクラッシュまたは予期しないリブート障害を調査する手順について説明します。

概要では、次の問題によりFIがリブートされる可能性があります

- カーネル空間プロセスがクラッシュした（カーネルパニック）

- カーネルのメモリ不足（メモリ不足 – OOMによるユーザープロセスの強制終了によるメモリの再利用）

- ユーザ空間プロセスがクラッシュした(- netstack、fcoe_mgr、callhomeなど)

- FIファームウェアの問題(まれなシナリオ、例：CSCuq46105 )、またはハードウェアコンポーネントの障害（ストレージに使用されるSSDなど）

前提条件

要件

次の項目に関する知識があることが推奨されます。

Cisco UCS Manager

Cisco Unified Computing System （UCS） Manager コマンド ライン インターフェイス（CLI）

必要なログファイル

FIが予期せずリブートしたら、次のログを収集し、TACサービスリクエストにアップロードします。

- UCSM techsupportログバンドル

- コアダンプファイルがリブートイベントの前後に作成されているかどうかを確認します。

CLIまたはGUIでコアダンプファイルを確認できます

UCS-FI番号のスコープモニタリング

UCS-FI /monitoring # scope sysdebug

UCS-FI /monitoring/sysdebug # show cores detail

- FIがsyslogサーバにログをエクスポートするように設定されている場合は、リブートのタイムスタンプの7日前に履歴を提供するデバイスのsyslogサーバからログメッセージを収集してください。

- カーネルスタックトレース（リブートがカーネルパニックによるものである場合）

ログを分析して最初の手がかりを探す

1) Nexusオペレーティングシステム(NX-OS)の再起動の理由とタイムスタンプを確認します。「show version」コマンドの出力

2)リブートのタイムスタンプの前に、「show logging nvram」コマンドの出力でログメッセージを確認します

3) syslogサーバに保存されているログメッセージをチェックして、追加の手がかりがないか確認します

4)ユーザ空間プロセスのクラッシュによってリブートがトリガーされた場合は、プロセス名とリブートのタイムスタンプに一致するコアダンプをチェックします。

6)カーネルパニックの場合は、sw_kernel_trace_logという名前のファイルにカーネルスタックトレースの出力がないかを確認します。

UCSM 2.2.1bから、このファイルはUCSM show techsupport bundleに含まれています。

2.2.1bより前のUCSMバージョンでは、次のコマンドの出力を収集してください

connect nxos

show logging onboard  kernel-trace | no-more

show logging onboard  obfl-history | no-more

show logging onboard  stack-trace | no-more

show logging onboard internal kernel | no-more

show logging onboard internal kernel-big | no-more

show logging onboard internal platform | no-more

show logging onboard internal reset-reason | no-more

7) " topout.log "には、2秒ごとに" top "コマンドの出力が含まれます。リブートの前に、UCSMは古いログセットを/opt/sam_logs.tgzファイルとして保存します。メモリ、使用率、またはプロセスに関する情報を提供できます。

8)Out of Memory( OOM )などのメッセージがプロセスを強制終了し、プロセスのクラッシュがFIの再起動を引き起こし、リセットの理由として表示される場合は、そのプロセスがメモリ不足の状態に陥り、クラッシュやメモリリークの原因ではない可能性があります。

UCSの設定に関する情報の収集

次の質問に答えると、システムの設定とリブート前の状態を理解しやすくなります。

1)この問題は以前に発生しましたか。

2)リブート前後に特定のユーザアクティビティはありましたか。

3) FIに対して最近行われたソフトウェア/ハードウェア/設定の変更

4)Fiは外部アプリケーションによって監視されていますか（SNMP、XML APIを使用）?

5)はい、データのFIをポーリングする頻度はどのくらいですか。 これらのアプリケーションによって定期的にポーリングされる情報はどれですか。（SNMPクエリーなど）

6) FI管理ポートへのトラフィックストームはありますか。

7)このスケール設定ですか。（シャーシ、ブレード、仮想インターフェイスの数）

FIを予防的に監視するための提案

1)ログをsyslogサーバにエクスポートするためのUCSMの設定

2) CPUおよびメモリの傾向を監視するために、定期的にlocal-mgmtから「show processes」の出力を収集します

プロセスの使用状況。FIが外部アプリケーションによってモニタされている場合は、これは必要ありません。

関連情報

Cisco UCS Managerコンフィギュレーションガイド