APIC クラッシュ シナリオのトラブルシューティング
クラスタのトラブルシューティング シナリオ
| 問題 | ソリューション | ||
|---|---|---|---|
| APIC ノードはクラスタ内でエラーが発生します。たとえば、5 つの APIC のクラスタのノード 2 がエラーを起こすとします。 |
2 つの解決策があります。
|
||
| 新しい APIC はファブリックに接続し、リーフ スイッチへの接続は失われます。 |
インフラ（インフラストラクチャ）VLAN の不一致があるかを確認するには、次のコマンドを使用します。
これらのコマンドの出力が異なる VLAN を表示する場合、新しい APIC は正しいインフラ（インフラストラクチャ）VLAN で設定されていません。この問題を解決するには、次の手順に従います。
|
||
| 2 つの APIC は、再起動後に通信できません。 |
この問題は次の一連のイベントの後に発生することがあります。
このシナリオでは、APIC1a が APIC2 を検出しますが、APIC2 はオフラインと見なされる APIC1 があるクラスタ内に存在するので使用できません。その結果、APIC1a は APIC2 からのメッセージを受け入れません。 この問題を解決するには、APIC2 上の APIC1 をデコミッションし、再度 APIC1 を稼働させます。 |
||
| デコミッションされた APIC がクラスタに参加します。 |
この問題は次の一連のイベントの後に発生することがあります。
この問題を解決するには、クラスタの回復後に APIC をデコミッションします。 |
||
| 再起動後の ChassisID が一致しません。 | この問題は、APIC がクラスタで登録されたシャーシ ID と異なるシャーシ ID で起動したときに起こります。その結果、この APIC からのメッセージが廃棄されます。
この問題を解決するには、リブートの前に APIC が解放されていることを確認してください。 |
||
| APIC はクラスタ サイズの変更時のエラーを表示します。 |
さまざまな条件が、AdminstrativeClusterSize に合わせたクラスタによる OperationalClusterSize の拡張の妨げになる可能性があります。詳細については、障害を調べて、Cisco APIC ベーシック コンフィギュレーション ガイド の「クラスタ障害」セクションを確認してください。 |
||
| APIC がクラスタに参加できない |
この問題は、クラスタを拡大するときに 2 つの APIC が同じクラスタ ID で設定されると起こります。その結果、2 つのうち 1 つの APIC がクラスタに参加できず、拡張競合シャーシ ID 不一致のエラーが表示されます。 この問題を解決するには、新しいクラスタ ID でクラスタの外側に APIC を設定します。 |
||
|
APIC がクラスタで到達不能です。 |
この問題を診断するには、次の設定を確認してください。
|
||
|
クラスタは拡張しません。 |
この問題は、次の状況で発生します。
|
||
|
APIC がダウンしています。 |
|
クラスタの障害
APIC は、クラスタの問題の診断に役立つさまざまなエラーをサポートします。ここでは、2 つの主要なクラスタのエラーの種類について説明します。
エラーの破棄
APIC は現在のクラスタのピアまたはクラスタ拡大候補以外からのクラスタ メッセージを破棄します。APIC によりメッセージを破棄した場合、発信元の APIC のシリアル番号、クラスタ ID、タイムスタンプを含むエラーが発生します。次の表で、破棄されるメッセージのエラーを要約します。
| Fault | 意味 |
|---|---|
| expansion-contender-chassis-id-mismatch | 送信側 APIC のシャーシ ID が拡大のためにクラスタが認識するシャーシ ID と一致しません。 |
| expansion-contender-fabric-domain-mismatch | 送信側 APIC のファブリック ID が拡大のためにクラスタが認識するファブリック ID と一致しません。 |
| expansion-contender-id-is-not-next-to-oper-cluster-size | 送信側 APIC に拡大に不適切なクラスタ ID があります。値は、現在の OperationalClusterSize よりも 1 大きい必要があります。 |
| expansion-contender-message-is-not-heartbeat | 送信側 APIC が継続的ハートビート メッセージを送信しません。 |
| fabric-domain-mismatch | 送信側 APIC のファブリック ID がクラスタのファブリック ID と一致しません。 |
| operational-cluster-size-distance-cannot-be-bridged | 送信側 APIC に、受信側 APIC のものとは 1 以上違う OperationalClusterSize があります。受信側 APIC は要求を拒否します。 |
| source-chassis-id-mismatch | 送信側 APIC のシャーシ ID がクラスタに登録されたシャーシ ID と一致しません。 |
| source-cluster-id-illegal | 送信側 APIC に許可されていないクラスタ ID 値があります。 |
| source-has-mismatched-target-chassis-id | 送信側 APIC の目標シャーシ ID が受信側 APIC のシャーシ ID に一致しません。 |
| source-id-is-outside-operational-cluster-size | 送信側 APIC に、クラスタの OperationalClusterSize 外のクラスタ ID があります。 |
| source-is-not-commissioned | 送信側 APIC にクラスタで現在解放されている ID があります。 |
クラスタ変更時エラー
次のエラーは、APIC のクラスタ サイズの変更時のエラーがある場合に適用されます。
| Fault | 意味 |
|---|---|
| cluster-is-stuck-at-size-2 | このエラーは、OperationalClusterSize が拡張期間にわたり 2 のままになると発行されます。問題を解決するには、クラスタの目標サイズをリストアします。 |
| most-right-appliance-remains-commissioned | クラスタ内の最後の APIC が稼働中で、クラスタの縮小を妨げています。 |
| no-expansion-contender | クラスタがより大きいクラスタ ID を持つ APIC を検出できず、クラスタの拡張を行えません。 |
| service-down-on-appliance-carrying-replica-related-to-relocation | 移動するデータのサブセットは、障害が起きているサービス上にコピーがあります。APIC に複数のこのような障害があることを示します。 |
| unavailable-appliance-carrying-replica-related-to-relocation | 移動するデータのサブセットは、使用できない APIC 上にコピーがあります。このエラーを解決するには、使用できない APIC を復元します。 |
| unhealthy-replica-related-to-relocation | 移動するデータのサブセットは、正常でない APIC 上にコピーがあります。このエラーを解決するには、障害の根本原因を特定します。 |
APIC 使用不可
次のクラスタのエラーは、APIC が使用できない場合に適用できます。
| Fault | 意味 |
|---|---|
| fltInfraReplicaReplicaState | クラスタがデータのサブセットを起動できません。 |
| fltInfraReplicaDatabaseState | データ ストア サービスの破損を示します。 |
| fltInfraServiceHealth | データのサブセットが完全には機能していないことを示します。 |
| fltInfraWiNodeHealth | APIC が完全には機能していないことを示します。 |
ファブリック ノードとプロセス クラッシュのトラブルシューティング
ACI スイッチ ノードには、システムのさまざまな機能面を制御する多数のプロセスがあります。システムの特定のプロセスでソフトウェア障害が発生した場合、コア ファイルが生成され、プロセスがリロードされます。
プロセスが Data Management Engine（DME）プロセスの場合、DME プロセスは自動的に再起動します。プロセスが非 DME プロセスの場合、プロセスは自動的に再起動せず、スイッチが再起動して回復します。
このセクションでは、さまざまなプロセスの概要、プロセスがコア化したことを検出する方法、およびこれが発生したときに取るべきアクションについて説明します。
DME プロセス
APIC で実行されている重要なプロセスは、CLI で見つけることができます。APIC とは異なり、 の GUI を介して表示できるプロセスには、リーフで実行されているすべてのプロセスが表示されます。
ps-ef | grep svc_ifc を経由：
rtp_leaf1# ps -ef |grep svc_ifc
root 3990 3087 1 Oct13 ? 00:43:36 /isan/bin/svc_ifc_policyelem --x
root 4039 3087 1 Oct13 ? 00:42:00 /isan/bin/svc_ifc_eventmgr --x
root 4261 3087 1 Oct13 ? 00:40:05 /isan/bin/svc_ifc_opflexelem --x -v
dptcp:8000
root 4271 3087 1 Oct13 ? 00:44:21 /isan/bin/svc_ifc_observerelem --x
root 4277 3087 1 Oct13 ? 00:40:42 /isan/bin/svc_ifc_dbgrelem --x
root 4279 3087 1 Oct13 ? 00:41:02 /isan/bin/svc_ifc_confelem --x
rtp_leaf1#スイッチで実行されている各プロセスは、システムのログ ファイルにアクティビティを書き込みます。これらのログ ファイルは、techsupport ファイルの一部として処理されていますが、CLI アクセスを介して /tmp/logs/ ディレクトリにあります。たとえば、ポリシー エレメントのプロセス ログ出力は、/tmp/logs/svc_ifc_policyelem.log に書き込まれます。
以下は、システムで実行されている DME プロセスの簡単な説明です。これは、特定のプロセスのトラブルシューティング時にどのログ ファイルを参照するかを理解したり、プロセスがクラッシュした場合のシステムへの影響を理解したりするのに役立ちます。
|
プロセス |
機能 |
|---|---|
|
ポリシー要素 |
ポリシー要素: APIC からの論理 MO を処理し、具体的なモデルをスイッチにプッシュします |
|
eventmgr |
イベント マネージャ：ローカルの障害、イベント、ヘルス スコアを処理します |
|
opflexelem |
Opflex 要素: スイッチ上の Opflex サーバ |
|
observerelem |
オブザーバ要素: APIC に送信されたローカル統計を処理します |
|
dbgrelem |
デバッガー要素：コア ハンドラ |
|
nginx |
スイッチと APIC 間のトラフィックを処理する Web サーバ |
プロセスがいつクラッシュしたかを特定する
プロセスがクラッシュしてコア ファイルが生成されると、イベントだけでなく障害も生成されます。APIC からの次の syslog 出力に示されているように、特定のプロセスの障害は「プロセス クラッシュ」として表示されます。
Oct 16 03:54:35 apic3 %LOG_LOCAL7-3-SYSTEM_MSG [E4208395][process-crash][major]
[subj-[dbgs/cores/node-102-card-1-svc-policyelem-ts-2014-10-16T03:54:55.000+00:00]/
rec-12884905092]Process policyelem coredスイッチのプロセスがクラッシュすると、コア ファイルが圧縮され、APIC にコピーされます。syslog メッセージ通知は APIC から送信されます。
プロセスがクラッシュしたときに生成される障害は、プロセスが再起動された Cisco Application Centric Infrastructure 275 のトラブルシューティングでクリアされます。障害は、 でファブリック履歴タブの GUI を介して表示できます。
コア ファイルの収集
APIC GUI は、ファブリック ノードのコア ファイルを収集するための中心的な場所を提供します。
エクスポート ポリシーは、 から作成されます。ただし、ファイルを直接ダウンロードできるデフォルトのコア ポリシーがあります。
コア ファイルには、コア ファイルが配置されている APIC の /data/techsupport にある APIC を介して SSH/SCP 経由でアクセスできます。コア ファイルは、クラスタ内の 1 つの APIC の /data/techsupport で入手できることに注意してください。コア ファイルが存在する正確な APIC は、GUI に表示されるエクスポート ロケーション パスで見つけることができます。たとえば、エクスポート先が「files/3/」で始まる場合、ファイルはノード 3（APIC3）にあります。
APIC プロセスのクラッシュの検証と再起動
症状 1
スイッチ ファブリックのプロセスがクラッシュします。プロセスが自動的に再起動するか、スイッチがリロードして復元します。
-
検証：
概要セクションに示されているように、DME プロセスがクラッシュした場合、スイッチを再起動せずに自動的に再起動する必要があります。非 DME プロセスがクラッシュした場合、プロセスは自動的に再起動せず、スイッチが再起動して回復します。
どのプロセスがクラッシュするかによって、プロセス コアの影響は異なります。
非 DME プロセスがクラッシュすると、通常コンソールに表示されるように HAP リセットが発生します。
[ 1130.593388] nvram_klm wrote rr=16 rr_str=ntp hap reset to nvram [ 1130.599990] obfl_klm writing reset reason 16, ntp hap reset [ 1130.612558] Collected 8 ext4 filesystems -
プロセス ログの確認：
クラッシュするプロセスには、クラッシュ前に何らかのレベルのログ出力が必要です。スイッチのログの出力は、/tmp/logs ディレクトリに書き込まれます。プロセス名はファイル名の一部になります。たとえば、ポリシー エレメント プロセスの場合、ファイルは svc_ifc_policyelem.log です。
rtp_leaf2# ls -l |grep policyelem -rw-r--r-- 2 root root 13767569 Oct 16 00:37 svc_ifc_policyelem.log -rw-r--r-- 1 root root 1413246 Oct 14 22:10 svc_ifc_policyelem.log.1.gz -rw-r--r-- 1 root root 1276434 Oct 14 22:15 svc_ifc_policyelem.log.2.gz -rw-r--r-- 1 root root 1588816 Oct 14 23:12 svc_ifc_policyelem.log.3.gz -rw-r--r-- 1 root root 2124876 Oct 15 14:34 svc_ifc_policyelem.log.4.gz -rw-r--r-- 1 root root 1354160 Oct 15 22:30 svc_ifc_policyelem.log.5.gz -rw-r--r-- 2 root root 13767569 Oct 16 00:37 svc_ifc_policyelem.log.6 -rw-rw-rw- 1 root root 2 Oct 14 22:06 svc_ifc_policyelem.log.PRESERVED -rw-rw-rw- 1 root root 209 Oct 14 22:06 svc_ifc_policyelem.log.stderr rtp_leaf2#/tmp/logs にあるプロセスごとにいくつかのファイルがあります。ログ ファイルのサイズが大きくなるにつれて、ログ ファイルは圧縮され、古いログ ファイルはローテーションされなくなります。コア ファイルの作成時刻（GUI とコア ファイル名に表示される）を確認して、ファイルのどこを確認すればよいかを理解します。また、プロセスが最初に起動しようとすると、ログ ファイルに「クラッシュ後にプロセスが再起動しています」というエントリが記録されます。このエントリを使用して、クラッシュの前に何が起こったかを遡って検索できます。
-
アクティビティをチェック：
実行中のプロセスに変更が加えられたため、クラッシュが発生しました。多くの場合、変更はシステムの構成アクティビティによるものである可能性があります。システムで発生したアクティビティは、システムの監査ログ履歴で確認できます。
-
TAC に連絡する：
通常、プロセスのクラッシュは発生しません。上記の手順を超える理由をよりよく理解するには、コア ファイルをデコードする必要があります。この時点で、ファイルを収集して、さらに処理するために TAC に提供する必要があります。
上記の方法でコア ファイルを収集し、TAC でケースをオープンします。
症状 2
ファブリック スイッチが継続的にリロードするか、BIOS ローダー プロンプトでスタックします。
-
検証：
DME プロセスがクラッシュした場合、スイッチの再起動をせずに自動的に再起動する必要があります。非 DME プロセスがクラッシュした場合、プロセスは自動的に再起動せず、スイッチが再起動して回復します。ただし、いずれの場合でもプロセスが継続的にクラッシュすると、スイッチは継続的なリロード ループに入るか、BIOS ローダー プロンプトで終了する可能性があります。
[ 1130.593388] nvram_klm wrote rr=16 rr_str=policyelem hap reset to nvram [ 1130.599990] obfl_klm writing reset reason 16, policyelem hap reset [ 1130.612558] Collected 8 ext4 filesystems -
HAP リセット ループを破る：
最初のステップは、スイッチをさらに情報を収集できる状態に戻すことです。
スイッチが継続的に再起動している場合、スイッチの起動時に、スイッチが起動サイクルの最初の部分である場合 CTRL C を入力して、コンソールから BIOS ローダー プロンプトに侵入します。
スイッチがローダー プロンプトに表示されたら、次のコマンドを入力します。
-
cmdline no_hap_reset
-
ブート
cmdline コマンドは、hap リセットが呼び出されたときにスイッチがリロードするのを防ぎます。2 番目のコマンドでは、システムを起動します。リロードによって入力された cmdline オプションが削除されるため、ローダーでのリロードの代わりに boot コマンドが必要であることに注意してください。
これで、システムはデータを収集するためのより適切なアクセスを許可するようになったはずですが、プロセスがクラッシュするとスイッチの機能に影響を与えます。
-
前の表のように、プロセス ログ、アクティビティを確認し、TAC の手順に連絡してください。
APIC プロセス クラッシュのトラブルシューティング
APIC には、システムのさまざまな機能的側面を制御する一連のデータ管理エンジン（DME）プロセスがあります。システムの特定のプロセスでソフトウェア障害が発生すると、コア ファイルが生成され、プロセスが再ロードされます。
次のセクションでは、システム プロセスのクラッシュやソフトウェアの障害に関連する潜在的な問題について説明します。まず、さまざまなシステム プロセスの概要、プロセスがコア化されたことを検出する方法、およびこれが発生したときに取るべきアクションについて説明します。正常に動作しているシステムの表示は、突然終了した可能性のあるプロセスを特定するために使用できます。
DME プロセス
APIC で実行されている重要なプロセスは、GUI または CLI のいずれかで見つけることができます。GUI を使用すると、実行中のプロセスとプロセス ID が に表示されます。
CLI を使用すると、プロセスとプロセス ID は、/aci/system/controllers/1/processes（APIC1 の場合）のサマリ ファイルにあります。
admin@RTP_Apic1:processes> cat summary
processes:
process-id process-name max-memory-allocated state
---------- ----------------- -------------------- -------------------
0 KERNEL 0 interruptible-sleep
331 dhcpd 108920832 interruptible-sleep
336 vmmmgr 334442496 interruptible-sleep
554 neo 398274560 interruptible-sleep
1034 ae 153690112 interruptible-sleep
1214 eventmgr 514793472 interruptible-sleep
2541 bootmgr 292020224 interruptible-sleep
4390 snoopy 28499968 interruptible-sleep
5832 scripthandler 254308352 interruptible-sleep
19204 dbgr 648941568 interruptible-sleep
21863 nginx 4312199168 interruptible-sleep
32192 appliancedirector 136732672 interruptible-sleep
32197 sshd 1228800 interruptible-sleep
32202 perfwatch 19345408 interruptible-sleep
32203 observer 724484096 interruptible-sleep
32205 lldpad 1200128 interruptible-sleep
32209 topomgr 280576000 interruptible-sleep
32210 xinetd 99258368 interruptible-sleep
32213 policymgr 673251328 interruptible-sleep
32215 reader 258940928 interruptible-sleep
32216 logwatch 266596352 interruptible-sleep
32218 idmgr 246824960 interruptible-sleep
32416 keyhole 15233024 interruptible-sleep
admin@apic1:processes>APIC で実行されている各プロセスは、システムのログ ファイルに書き込みます。これらのログ ファイルは、APIC techsupport ファイルの一部としてバンドルできますが、/var/log/dme/log の SSH シェル アクセスを介して確認することもできます。たとえば、Policy Manager プロセス ログ出力は /var/log/dme/log/svc_ifc_policymgr.bin.log に書き込まれます。
以下は、システムで実行されているプロセスの簡単な説明です。これは、特定のプロセスのトラブルシューティング時にどのログ ファイルを参照するかを理解したり、プロセスがクラッシュした場合のシステムへの影響を理解したりするのに役立ちます。
|
プロセス |
機能 |
|---|---|
|
カーネル |
Linux カーネル |
|
dhcpd |
APIC がインフラ アドレスを割り当てるために実行されている DHCP プロセス |
|
vmmmgr |
APIC とハイパーバイザ間のプロセスを処理します |
|
neo |
Shell CLI インタープリタ |
|
ae |
ローカル APIC アプライアンスの状態とインベントリを処理します |
|
eventmgr |
システム上のすべてのイベントと障害を処理します |
|
bootmgr |
ファブリック ノードでの起動とファームウェアの更新を制御します |
|
snoopy |
Shell CLI ヘルプ、タブ コマンド補完 |
|
scripthandler |
L4-L7 デバイスのスクリプトと通信を処理します |
|
dbgr |
プロセスがクラッシュしたときにコア ファイルを生成します |
|
nginx |
Web サービス処理 GUI および REST API アクセス |
|
appliancedirector |
APIC クラスタの形成と制御を処理します |
|
sshd |
APIC への SSH アクセスを有効化 |
|
perfwatch |
Linux cgroup 技術情報の使用法を監視します |
|
observer |
ファブリック システムと状態、統計、正常性のデータ処理を監視します |
|
lldpad |
LLDP エージェント |
|
topomgr |
ファブリックのトポロジとインベントリを維持します |
フィードバック