UCS ファブリック インターコネクトのクラッシュや予想外の再起動のトラブルシューティング

概要 

このドキュメントでは、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コンフィギュレーションガイド