内容

はじめに

前提条件

要件

使用するコンポーネント

背景説明

共通の不具合参照

トラブルシューティング

シナリオ 1

シナリオ 2

シナリオ 3

結論

はじめに

このドキュメントでは、ほとんどのタイプのUCSサーバで見られるサーバアクセス不能障害の一般的な原因をトラブルシューティングする方法について説明します。

前提条件

要件

Unified Computing System Manager(UCSM)およびIntersightマネージドモード(IMM)でのサーバ管理に関する知識があることが推奨されます。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

ユーザがUCSドメインで受け取る可能性のある一般的な障害があります。これは、サーバにアクセスできないことを通知することです。これは多くの理由で発生する可能性があり、モニタリングツールとUCSM/IMMのバージョンによって障害の表示方法が異なる場合があります。

System Notification from [UCSM Domain Name] - diagnostic:GOLD-minor - 2023-05-25 01:56:41 GMT-04:00 Recovered : Server x/y (service profile: org-root/ls-[service_profile]) inaccessible

Serial number: [Server Serial]

Alert:  System Name: [UCSM Domain Name]

Time of Event:2022-08-31 03:15:04 GMT-05:00 Event Description:Server x (service profile: org-root/ls-[service_profile]) inaccessible Severity Level:4

IMMが使用中の場合、GUIに「Connection to Server was lost」メッセージが表示される場合があります。Intersight障害からの切断も確認できます。

サーバへの接続がIMMで失われました

このアラートは、ブレード上のCisco Integrated Management Controller(CIMC)で問題が発生し、リブートまたはリブートが試行された場合に表示されます。これにより、ブレードの管理プレーンが再起動中に、UCSM/IMMがブレードと通信できず、アクセス不能と認識されるため、Server Inaccessibleアラートがトリガーされます。CIMCがリブートすると、ブレードの状態は通常の状態に戻ります。

これが、このアラートを受け取り、ドメインを確認すると、サーバが起動して正常に動作していることを示しています。

共通の不具合参照

Cisco Bug ID CSCwe19822:Xシリーズの4.2(2c)/5.0(1c)以降のM5/M6サーバに適用

Cisco Bug ID CSCwa85667:4.1(3e) ～ 4.2(2a)のM5/M6サーバに適用され、5.0(1b)以降のXシリーズも含む

Cisco Bug ID CSCvz62711 - 4.1(3d) ～ 4.2(2a)のM5/M6サーバに適用

Cisco Bug ID CSCwi50991:4.3(2e)以前のコードのM5/M6シリーズブレードに適用されます

Cisco Bug ID CSCvv79912:4.0(4h)から4.2(1a)/4.1(3d)までのM5/M6サーバに適用

Cisco Bug ID CSCvh25786:2.0(13f)および3.0(4a)以降のM4/M5サーバに適用されます

トラブルシューティング

シナリオ 1

最初の最も一般的な状況はアラートを受け取り、UCSM/IMMをチェックする際にサーバが動作可能で正常に見え、（新しい）障害がないように見えます。OSを確認すると、システムは中断なく起動して動作しているようです。

UCSMの正常なサーバ

ログバンドルでは、CIMCx_TechSupport.tar.gz > obfl > obfl-logにあるOBFLログのいずれかで、このメッセージが表示されます。

3:2022 Sep  8 10:54:33 UTC:+0000:(4.2(2d)):kernel:-:[watchdog_init]:976:BMC Watchdog resetted BMC.

これは、CIMCがクラッシュし、自動的にリブートしたことを示しています。

このシナリオでは、CIMCが正常にリブートされ、サーバに問題がないため、これ以上のアクションは必要ありません。

シナリオ 2

次の状況ではアラートを受信しており、UCSM/IMMを確認すると、UCSMを使用している場合はサーバにアクセスできない、IMMを使用している場合はサーバが切断されたままになります。 オペレーティングシステムを確認すると、システムは中断なく起動して動作しているように見えます。

OSは稼働していますが、UCSM/IMMがブレードと通信できないため、CIMCがリブートしなかったか、プロセスが停止しました。

このシナリオの最初のステップは、Fabric Interconnect(FI)に対してSSHまたはコンソール接続を行い、このコマンドを実行してx/yを該当するシャーシ/ブレードに置き換えることです。3つの異なる結果があります。

1) CIMCへの接続が成功しました。

UCSM-A# connect cimc x (For C Series Rack Mount Server)

UCSM-A# connect cimc x/y (For B/X Series Blade Server)

Trying 127.5.1.1...

Connected to 127.5.1.1.

Escape character is '^]'.

CIMC Debug Firmware Utility Shell [ support ]

[ help ]#

この出力が表示される場合は、CIMCがまだ機能していないため、CIMCをリセットしてブレードを回復できます。

UCSMを使用している場合は、Equipment > Chassis > Chassis Number > Servers > Server Number > Recover Server > Reset CIMCの順に移動します。

ブレードのリカバリサーバの場所

CIMCのリセット

IMMを使用している場合、影響を受けるサーバに移動し、Actions > System > Reboot Management Controllerの順に選択します。

管理コントローラIMMのリブート

CIMCの再起動後にサーバが通常の状態に戻った場合、問題は解決され、それ以上の操作は必要ありません。

引き続き障害が発生する場合は、次のconnect cimc出力のトラブルシューティングステップに進みます。

2) CIMCへの接続が失敗する。

UCSM-A# connect cimc x (For C Series Rack Mount Server)

UCSM-A# connect cimc x/y (For B/X Series Blade Server)

Trying 127.5.1.8...

telnet: Unable to connect to remote host: No route to host

3) CIMCストールへの接続。この場合、コマンドを実行した後に何も起こらず、エスケープ(Ctrl + C)しようとすると、これが観察されます。

UCSM-A# connect cimc x (For C Series Rack Mount Server)

UCSM-A# connect cimc x/y (For B/X Series Blade Server)

^C

Console escape. Commands are:

l    go to line mode

c    go to command mode

z    suspend telnet

e    exit telent

continuing...

最後の2つの出力のどちらかのトラブルシューティングは同じです。この場合、CIMCは完全にダウンし、ファブリックインターコネクトと通信できません。CIMCを回復するには、サーバのリブートが必要です。ブレードをリブートする際には、必ずメンテナンス時間帯を設けることをお勧めします。

UCSMを使用している場合は、ファブリックインターコネクトにSSH接続し、このコマンドを実行してx/yを該当のシャーシ/サーバに置き換えることで、ブレードの物理的な抜き差しをシミュレートできます。このコマンドでは確認のプロンプトが表示されないため、正しいシャーシ/サーバを入力する必要があります。

UCSM-A# reset slot x/y

注:reset slotコマンドは、指定されたスロットx/yのブレードをただちにリブートします。OSがまだ動作している場合は、サーバを安全に再起動してください。

このコマンドは、成功した場合は何も返しません。コマンドの実行に失敗すると、メッセージが表示されます。

IMMを使用している場合、またはreset slotコマンドでアクセスできない問題が解決しなかった場合は、ブレードを物理的に再装着する以外に方法はありません。

ブレードを物理的に取り付け直した後も、問題が引き続き発生する場合は、TACに問い合せて、さらにトラブルシューティングを依頼してください。

シナリオ 3

最後の状況はアラートを受け取り、UCSM/IMMを確認する際に、UCSMを使用している場合はサーバにアクセスできないとして表示され、IMMを使用している場合は切断されたままになります。 オペレーティングシステムを確認すると、システムがダウンし、アクセスできなくなります。

この状況では、サーバをリブートするだけで済みます。リブートできない場合は、サーバを物理的に再装着します。

ブレードを物理的に取り付け直した後も、問題が引き続き発生する場合は、TACに問い合せて、さらにトラブルシューティングを依頼してください。

結論

Server Inaccessible faultsを受け取る理由は多数あり、他の障害よりも影響が大きい障害もあります。ここで説明する手順は、トラブルシューティングが必要かどうか、またはドメインが正常で対処の必要がないかどうかを評価する際に役立ちます。