概要
このドキュメントでは、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サービスリクエストにアップロードします。
- コアダンプファイルがリブートイベントの前後に作成されているかどうかを確認します。
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コンフィギュレーションガイド