Nexus 7000 スーパーバイザ 2/2E コンパクト フラッシュ障害リカバリ
内容
概要
このドキュメントでは、ソフトウェアの問題 CSCus22805 に記載されている Nexus 7000 スーパバイザ 2/2E Compact Flash の障害に関する問題、起こりうるすべての障害シナリオ、および回復手順について説明します。
背景
各 N7K Ssupervisor 2/2E には 2 つの eUSB フラッシュ デバイス（プライマリとミラー）が RAID1 構成で搭載されています。これらのデバイスにより、ブート イメージ、スタートアップ コンフィギュレーション、永続アプリケーション データのための不揮発性リポジトリが提供されます。
数か月または数年にわたって使用するうちに、いずれかのデバイスと USB バスの接続が切断され、これが原因で RAID ソフトウェアが設定からそのデバイスを削除します。2 つのデバイスのうち 1 つのデバイスだけでも引き続き正常に機能できます。ただし、2 つ目のデバイスがアレイからドロップされると、ブートフラッシュは読み取り専用として再マウントされます。つまり、設定やファイルをブートフラッシュに保存できず、またリロード時にスタンバイがアクティブと同期できなくなります。
デュアル フラッシュ障害状態で稼働するシステムでは、その動作には影響はありませんが、この状態から回復するには、影響を受けるスーパバイザをリロードする必要があります。また、実行コンフィギュレーションの変更は起動時には反映されず、停電発生時にはこの変更が失われます。
症状
次の症状が確認されています。
- Compact Flash 診断の失敗
switch# show diagnostic result module 5
Current bootup diagnostic level: complete
Module 5: Supervisor module-2 (Standby)
Test results: (. = Pass, F = Fail, I = Incomplete,
U = Untested, A = Abort, E = Error disabled)
1) ASICRegisterCheck-------------> .
2) USB---------------------------> .
3) NVRAM-------------------------> .
4) RealTimeClock-----------------> .
5) PrimaryBootROM----------------> .
6) SecondaryBootROM--------------> .
7) CompactFlash------------------> F <=====
8) ExternalCompactFlash----------> .
9) PwrMgmtBus--------------------> U
10) SpineControlBus---------------> .
11) SystemMgmtBus-----------------> U
12) StatusBus---------------------> U
13) StandbyFabricLoopback---------> .
14) ManagementPortLoopback--------> .
15) EOBCPortLoopback--------------> .
16) OBFL--------------------------> .
- 「copy run start」を実行できない
dcd02.ptfrnyfs# copy running-config startup-config
[########################################] 100%
Configuration update aborted: request was aborted
- eUSB が読み取り専用になる、または応答しない
switch %MODULE-4-MOD_WARNING: Module 2 (Serial number: JAF1645AHQT) reported warning
due to The compact flash power test failed in device DEV_UNDEF (device error 0x0)
switch %DEVICE_TEST-2-COMPACT_FLASH_FAIL: Module 1 has failed test CompactFlash 20
times on device Compact Flash due to error The compact flash power test failed
- 通常スタンバイ スーパバイザにフェールオーバーを実行するときに発生する ISSU の失敗
診断
Compact Flash カードの現在の状態を診断するには、以下の内部コマンドを使用する必要があります。コマンドでは解析は実行されません。またコマンドは以下のように完全に入力する必要があります。
switch# show system internal raid | grep -A 1 "Current RAID status info"
switch# show system internal file /proc/mdstat
シャーシに 2 台のスーパバイザがある場合、発生している障害シナリオを判別するためにはスタンバイ スーパバイザの状態をチェックする必要もあります。これを確認するには、コマンドの前に「slot x」キーワードを追加します。「x」はスタンバイ スーパバイザのスロット番号です。これにより、スタンバイでコマンドをリモート実行することができます。
switch# slot 2 show system internal raid | grep -A 1 "Current RAID status info"
switch# slot 2 show system internal file /proc/mdstat
これらのコマンドでは、多くの RAID 統計情報とイベントが示されますが、関心があるのは現在の RAID 情報のみです。
「RAID data from CMOS」の行で、0xa5 の後の 16 進数値を確認します。 これにより、現在問題が発生しているフラッシュの数がわかります。
以下に、いくつかの例を示します。
switch# show system internal raid | grep -A 1 "Current RAID status info"
Current RAID status info:
RAID data from CMOS = 0xa5 0xc3
この出力から、0xa5 の横にある番号 0xc3 を確認します。 これらのキーを使用して、障害が発生しているのはプライマリまたはセカンダリどちらの Compact Flash か、あるいは両方であるかを確認できます。上記の出力には 0xc3 と示されているので、プライマリとセカンダリ両方の Compact Flash で障害が発生していることがわかります。
| 0xf0 | 障害は報告されていない |
| 0xe1 | プライマリ フラッシュで障害が発生している |
| 0xd2 | 代替（ミラー）フラッシュで障害が発生している |
| 0xC3 | プライマリと代替の両方で障害が発生している |
「/proc/mdstat」出力を見ると、すべてのディスクが「U」として表示されています。これは、「U」P（起動）を表します。
switch# slot 2 show system internal file /proc/mdstat
Personalities : [raid1]
md6 : active raid1 sdc6[0] sdb6[1]
77888 blocks [2/1] [_U]
md5 : active raid1 sdc5[0] sdb5[1]
78400 blocks [2/1] [_U]
md4 : active raid1 sdc4[0] sdb4[1]
39424 blocks [2/1] [_U]
md3 : active raid1 sdc3[0] sdb3[1]
1802240 blocks [2/1] [_U]
このシナリオでは、プライマリ Compact Flash が起動していない（[_U]）ことがわかります。正常な出力ではすべてのブロックが [UU] として表示されます。
シナリオ
発生しているシナリオを確認するには、「診断」セクションの上記コマンドを使用して、以下のシナリオ文字に関連付ける必要があります。 カラムを使用して、各スーパバイザで障害が発生している Compact Flash の数と照合します。
たとえば、アクティブ スーパバイザのコードが 0xe1 で、スタンバイが 0xd2 の場合は、アクティブで「1 つの障害」、スタンバイで「1 つの障害」となり、シナリオ文字は「D」となります。
シングル スーパバイザ：
| シナリオ文字 | アクティブ スーパバイザ | アクティブ スーパバイザのコード |
| A | 1 つの障害 | 0xe1 または 0xd2 |
| B | 2 つの障害 | 0xC3 |
デュアル スーパバイザ：
| シナリオ文字 | アクティブ スーパバイザ | スタンバイ スーパバイザ | アクティブ スーパバイザのコード | スタンバイ スーパバイザのコード |
| C | 障害なし | 1 つの障害 | 0xf0 | 0xe1 または 0xd2 |
| D | 1 つの障害 | 障害なし | 0xe1 または 0xd2 | 0xf0 |
| E | 1 つの障害 | 1 つの障害 | 0xe1 または 0xd2 | 0xe1 または 0xd2 |
| F | 2 つの障害 | 障害なし | 0xC3 | 0xf0 |
| G | 障害なし | 2 つの障害 | 0xf0 | 0xC3 |
| H | 2 つの障害 | 1 つの障害 | 0xC3 | 0xe1 または 0xd2 |
| I | 1 つの障害 | 2 つの障害 | 0xe1 または 0xd2 | 0xC3 |
| J | 2 つの障害 | 2 つの障害 | 0xC3 | 0xC3 |
各シナリオの回復手順
シングル スーパバイザの障害シナリオ
シナリオ A（アクティブで 1 つの障害）
回復シナリオ：
アクティブで 1 つの障害
解決の手順：
switch# show system internal file /proc/mdstat \
Personalities : [raid1]
md6 : active raid1 sdd6[2] sdc6[0]
77888 blocks [2/1] [U_] <-- "U_" represents the broken state
resync=DELAYED
md5 : active raid1 sdd5[2] sdc5[0]
78400 blocks [2/1] [U_]
resync=DELAYED
md4 : active raid1 sdd4[2] sdc4[0]
39424 blocks [2/1] [U_]
resync=DELAYED
md3 : active raid1 sdd3[2] sdc3[0]
1802240 blocks [2/1] [U_]
[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
unused devices: <none>
switch# show system internal file /proc/mdstat Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
77888 blocks [2/2] [UU] <-- "UU" represents the fixed state
md5 :active raid1 sdd5[1] sdc5[0]
78400 blocks [2/2] [UU]
md4 :active raid1 sdd4[1] sdc4[0]
39424 blocks [2/2] [UU]
md3 :active raid1 sdd3[1] sdc3[0]
1802240 blocks [2/2] [UU]
unused devices: <none>
シナリオ B（アクティブで 2 つの障害）
回復シナリオ：
アクティブで 2 つの障害
解決の手順：
デュアル スーパバイザの障害シナリオ
シナリオ C（アクティブの障害なし、スタンバイで 1 つの障害）
障害シナリオ：
アクティブの障害なし
スタンバイで 1 つの障害
解決の手順：
デュアル スーパバイザ設定のシナリオで、アクティブにはフラッシュ障害がなく、スタンバイで 1 つの障害が発生している場合は、影響を与えない回復を実行できます。
1.アクティブには障害がなく、スタンバイには1つの障害しかないため、フラッシュ回復ツールをアクティブにロードして実行できます。ツールを実行すると、ツールそのものがスタンバイに自動的にコピーされて、アレイの再同期が実行されます。 回復ツールは下記からダウンロードできます。
ツールをダウンロードして解凍し、ボックスのブートフラッシュにアップロードした後、次のコマンドを実行して回復を開始する必要があります。
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
ツールの実行が開始され、切断されたディスクが検出されて、それらのディスクが RAID アレイと再同期されます。
回復の状態を次のコマンドで確認できます。
# show system internal file /proc/mdstat
回復処理が進んでいることを確認します。すべてのディスクが完全に修復されて [UU] の状態になるまで数分かる場合があります。回復処理例は次のようになります。
switch# show system internal file /proc/mdstat \
Personalities : [raid1]
md6 : active raid1 sdd6[2] sdc6[0]
77888 blocks [2/1] [U_] <-- "U_" represents the broken state
resync=DELAYED
md5 : active raid1 sdd5[2] sdc5[0]
78400 blocks [2/1] [U_]
resync=DELAYED
md4 : active raid1 sdd4[2] sdc4[0]
39424 blocks [2/1] [U_]
resync=DELAYED
md3 : active raid1 sdd3[2] sdc3[0]
1802240 blocks [2/1] [U_]
[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
unused devices: <none>
回復が終了すると、次のようになります。
switch# show system internal file /proc/mdstat Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
77888 blocks [2/2] [UU] <-- "UU" represents the correct state
md5 :active raid1 sdd5[1] sdc5[0]
78400 blocks [2/2] [UU]
md4 :active raid1 sdd4[1] sdc4[0]
39424 blocks [2/2] [UU]
md3 :active raid1 sdd3[1] sdc3[0]
1802240 blocks [2/2] [UU]
unused devices: <none>
すべてのディスクが [UU] 状態になった後、RAID アレイは両方のディスクが同期された状態で完全にバックアップされます。
2.フラッシュ回復ツールが失敗した場合、アクティブに両方のディスクが起動しているため、スタンバイはリロード時にアクティブに正常に同期できます。
したがって、スケジュールされた期間に、スタンバイ スーパバイザに対して「out-of-service module x」を実行します。予期しない問題が生じた場合のためにブート プロセスを確認できるようスタンバイにコンソールからアクセスできるようにしてください。スーパバイザがダウンした後、数秒間待機してから、スタンバイで「no poweroff module x」を実行します。スタンバイが「ha-standby」の状態で完全に起動するまで待機します。
スタンバイをバックアップしたら、「slot x show system internal raid」と「slot x show system internal file /proc/mdstat」で RAID をチェックします。
リロード後に両方のディスクが完全にバックアップされなければ、回復ツールをを再度実行します。
3.リロードと回復ツールが失敗した場合は、ウィンドウ内のスタンバイモジュールを物理的に再装着して、状態をクリアすることを試みることをお勧めします。 物理的な抜き差しが失敗した場合は、パスワード回復手順に従ってブート時にスイッチ ブート モードに入り、このモードで「init system」を実行してみてください。 それでも成功しない場合は、TAC に手動リカバリを依頼してください。
シナリオ D（アクティブで 1 つの障害、スタンバイの障害なし）
回復シナリオ：
アクティブで 1 つの障害
スタンバイの障害なし
解決の手順：
デュアル スーパバイザ設定のシナリオで、アクティブで 1 つのフラッシュ障害が発生し、スタンバイでは障害が発生していない場合は、フラッシュ回復ツールを使用して影響を与えない回復を実行できます。
1.スタンバイには障害がなく、アクティブには1つの障害しかないため、フラッシュ回復ツールをアクティブにロードして実行できます。ツールを実行すると、ツールそのものがスタンバイに自動的にコピーされて、アレイの再同期が実行されます。 回復ツールは下記からダウンロードできます。
ツールをダウンロードして解凍し、アクティブのブートフラッシュにアップロードした後、次のコマンドを実行して回復を開始する必要があります。
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
ツールの実行が開始され、切断されたディスクが検出されて、それらのディスクが RAID アレイと再同期されます。
回復の状態を次のコマンドで確認できます。
# show system internal file /proc/mdstat
回復処理が進んでいることを確認します。すべてのディスクが完全に修復されて [UU] の状態になるまで数分かる場合があります。回復処理例は次のようになります。
switch# show system internal file /proc/mdstat \
Personalities : [raid1]
md6 : active raid1 sdd6[2] sdc6[0]
77888 blocks [2/1] [U_] <-- "U_" represents the broken state
resync=DELAYED
md5 : active raid1 sdd5[2] sdc5[0]
78400 blocks [2/1] [U_]
resync=DELAYED
md4 : active raid1 sdd4[2] sdc4[0]
39424 blocks [2/1] [U_]
resync=DELAYED
md3 : active raid1 sdd3[2] sdc3[0]
1802240 blocks [2/1] [U_]
[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
unused devices: <none>
回復が終了すると、次のようになります。
switch# show system internal file /proc/mdstat Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
77888 blocks [2/2] [UU] <-- "UU" represents the correct state
md5 :active raid1 sdd5[1] sdc5[0]
78400 blocks [2/2] [UU]
md4 :active raid1 sdd4[1] sdc4[0]
39424 blocks [2/2] [UU]
md3 :active raid1 sdd3[1] sdc3[0]
1802240 blocks [2/2] [UU]
unused devices: <none>
すべてのディスクが [UU] 状態になった後、RAID アレイは両方のディスクが同期された状態で完全にバックアップされます。
2.フラッシュ回復ツールが失敗した場合は、次のステップとして「システムスイッチオーバー」を実行し、メンテナンス時間帯にスーパーバイザモジュールをフェールオーバーします。
したがって、スケジュールされた期間に、「system switchover」を実行します。予期しない問題が生じたときのためにブート プロセスを確認できるようコンソール アクセスできるようにしてください。 スタンバイが「ha-standby」の状態で完全に起動するまで待機します。
スタンバイをバックアップしたら、「slot x show system internal raid」と「slot x show system internal file /proc/mdstat」で RAID をチェックします。
リロード後に両方のディスクが完全にバックアップされなければ、回復ツールをを再度実行します。
3.リロードと回復ツールが失敗した場合は、ウィンドウ内のスタンバイモジュールを物理的に再装着して、状態をクリアすることを試みることをお勧めします。 物理的な抜き差しが失敗した場合は、パスワード回復手順に従ってブート時にスイッチ ブート モードに入り、このモードで「init system」を実行してみてください。 それでも成功しない場合は、TAC に手動リカバリを依頼してください。
シナリオ E（アクティブで 1 つの障害、スタンバイで 1 つの障害）
回復シナリオ：
アクティブで 1 つの障害
スタンバイで 1 つの障害
解決の手順：
アクティブとスタンバイの両方で 1 つのフラッシュ障害が発生した場合も、影響を与えない回避策を実行できます。
1.スーパーバイザが読み取り専用状態ではないため、最初のステップはフラッシュ回復ツールを使用することです。
回復ツールは下記からダウンロードできます。
ツールをダウンロードして解凍し、アクティブのブートフラッシュにアップロードした後、次のコマンドを実行して回復を開始する必要があります。
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
これによって、アクティブで切断されているディスクが自動的に検出されて、修復が行われます。またツールそのものが自動的にスタンバイにコピーされ、障害の検出と修正が行われます。
回復の状態を次のコマンドで確認できます。
# show system internal file /proc/mdstat
回復処理が進んでいることを確認します。すべてのディスクが完全に修復されて [UU] の状態になるまで数分かる場合があります。回復処理例は次のようになります。
switch# show system internal file /proc/mdstat \
Personalities : [raid1]
md6 : active raid1 sdd6[2] sdc6[0]
77888 blocks [2/1] [U_] <-- "U_" represents the broken state
resync=DELAYED
md5 : active raid1 sdd5[2] sdc5[0]
78400 blocks [2/1] [U_]
resync=DELAYED
md4 : active raid1 sdd4[2] sdc4[0]
39424 blocks [2/1] [U_]
resync=DELAYED
md3 : active raid1 sdd3[2] sdc3[0]
1802240 blocks [2/1] [U_]
[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
unused devices: <none>
回復が終了すると、次のようになります。
switch# show system internal file /proc/mdstat Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
77888 blocks [2/2] [UU] <-- "UU" represents the correct state
md5 :active raid1 sdd5[1] sdc5[0]
78400 blocks [2/2] [UU]
md4 :active raid1 sdd4[1] sdc4[0]
39424 blocks [2/2] [UU]
md3 :active raid1 sdd3[1] sdc3[0]
1802240 blocks [2/2] [UU]
unused devices: <none>
すべてのディスクが [UU] 状態になった後、RAID アレイは両方のディスクが同期された状態で完全にバックアップされます。
両方のスーパバイザが [UU] 状態で回復した場合、回復は完了です。 回復が部分的に成功した場合や、失敗した場合は、手順 2 に進みます。
2.回復ツールが成功しなかった場合は、モジュールのRAIDの現在の状態を特定します。両方で 1 つのフラッシュ障害がまだ発生する場合は、「system switchover」を実行して現在のアクティブをリロードし、スタンバイを強制的にアクティブ ロールにします。
前のアクティブがリロードされて「ha-standby」状態に戻ったら、リロード中に回復している必要のある RAID の状態を確認します。
スーパバイザがスイッチオーバー後に正常に回復した場合は、フラッシュ回復ツールを再実行して現在のアクティブ スーパバイザの 1 つのディスク障害を修復するか、もう一度「system switchover」を実行して現在のアクティブをリロードし、前のアクティブと修復された現在のスタンバイを強制的にアクティブ ロールにすることができます。リロードされたスーパバイザで両方のディスクが再度修復されているか確認し、必要に応じて回復ツールを再実行します。
3.このプロセスの間にスイッチオーバーでRAIDが修正されない場合は、スタンバイに対して「out-of-service module x」を実行し、次に「no poweroff module x」を実行して電源を完全に切断し、モジュールに再供給します。
out of service が失敗した場合は、スタンバイの物理的な抜き差しを試してみてください。
回復ツールの実行後に 1 台のスーバーバイザの RAID が回復し、もう 1 台に障害が残る場合は、1 つの障害があるスーパバイザを必要に応じて「system switchover」で強制的にスタンバイにします。1 つの障害があるスーパバイザが
すでにスタンバイになっている場合は、スタンバイに対して「out-of-service module x」を実行し、「no poweroff module x」を実行して電源を完全に切断し、モジュールに電力を再供給します。それでも回復しない場合は、モジュールの物理的な抜き差しを試します。抜き差しで修正されない場合は、
パスワード回復手順を使用してスイッチ ブート プロンプトに入り、「init system」を実行してブートフラッシュを再初期化します。それでも失敗する場合は、TAC に手動回復を依頼してください。
シナリオ F（アクティブで2つの障害、スタンバイで0つの障害）
回復シナリオ：
アクティブで 2 つの障害
スタンバイの障害なし
解決の手順：
アクティブに 2 つの障害があり、スタンバイのスーパバイザに障害がない場合、スタンバイが実行コンフィギュレーションをアクティブと同期できなくなってから追加された実行コンフィギュレーションの量によっては、影響を与えない回復が可能です。
回復手順では、アクティブ スーパバイザの現在の実行コンフィギュレーションをコピーして、正常なスタンバイ スーパバイザにフェールオーバーし、不足している実行コンフィギュレーションを新しいアクティブにコピーして、前のアクティブを手動でオンラインにした後に、回復ツールを実行します。
2. 実行コンフィギュレーションをアクティブ スーパバイザからコピーしたら、スタートアップ コンフィギュレーションと比較して、最後の保存以降の変更内容を確認することをお勧めします。 これは、「show startup-configuration」で確認できます。 当然、違いは環境によってまったく異なりますが、スタンバイがアクティブとしてオンラインになるときに失われている内容を把握しておくと役に立ちます。 また、違いをメモ帳にコピーして、スイッチオーバー後に新しいアクティブ スーパバイザにすぐに追加できるようにすることをお勧めします。
を選択します。 違いを評価した後に、スーパバイザのスイッチオーバーを実行する必要があります。 TAC では、予測しない問題が生じる可能性があるため、スイッチオーバーはメンテナンス期間に実行することをお勧めします。 スタンバイへのフェールオーバーを実行するコマンドは、「system switchover」です。
4. スイッチオーバーは非常に迅速に実行され、新しいスタンバイがリブートを開始します。 この際に、失われたコンフィギュレーションを新しいアクティブに追加します。 これは TFTP サーバ（または以前にコンフィギュレーションを保存した場所）からコンフィギュレーションをコピーするか、単純に CLI でコンフィギュレーションを手動で追加することで可能になります。 ほとんどの場合、失われたコンフィギュレーションは非常に短く、CLI オプションで対応できます。
5. しばらくすると、新しいスタンバイ スーパバイザが「ha-standby」状態でオンラインに復帰する場合がありますが、通常は「powered-up」状態でスタックします。 この状態は、「show module」コマンドを使用して、モジュールの横にある「Status」列を参照することで確認できます。
新しいスタンバイが「powered-up」状態で起動する場合は、手動でオンラインに戻す必要があります。 これは、次のコマンドを実行して行います。「x」は「powered-up」状態でスタックしているスタンバイ モジュールです。
(config)# out-of-service module x
(config)# no poweroff module x
6. スタンバイが「ha-standby」状態でオンラインに戻ったら、回復ツールを実行して回復が完了したか確認する必要があります。 ツールは次のリンクからダウンロードできます。
ツールをダウンロードして解凍し、ボックスのブートフラッシュにアップロードした後、次のコマンドを実行して回復を開始する必要があります。
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
ツールの実行が開始され、切断されたディスクが検出されて、それらのディスクが RAID アレイと再同期されます。
回復の状態を次のコマンドで確認できます。
# show system internal file /proc/mdstat
回復処理が進んでいることを確認します。すべてのディスクが完全に修復されて [UU] の状態になるまで数分かる場合があります。回復処理例は次のようになります。
switch# show system internal file /proc/mdstat \
Personalities : [raid1]
md6 : active raid1 sdd6[2] sdc6[0]
77888 blocks [2/1] [U_] <-- "U_" represents the broken state
resync=DELAYED
md5 : active raid1 sdd5[2] sdc5[0]
78400 blocks [2/1] [U_]
resync=DELAYED
md4 : active raid1 sdd4[2] sdc4[0]
39424 blocks [2/1] [U_]
resync=DELAYED
md3 : active raid1 sdd3[2] sdc3[0]
1802240 blocks [2/1] [U_]
[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
unused devices: <none>
回復が終了すると、次のようになります。
switch# show system internal file /proc/mdstat
Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
77888 blocks [2/2] [UU] <-- "UU" represents the correct state
md5 :active raid1 sdd5[1] sdc5[0]
78400 blocks [2/2] [UU]
md4 :active raid1 sdd4[1] sdc4[0]
39424 blocks [2/2] [UU]
md3 :active raid1 sdd3[1] sdc3[0]
1802240 blocks [2/2] [UU]
unused devices: <none>
すべてのディスクが [UU] 状態になった後、RAID アレイは両方のディスクが同期された状態で完全にバックアップされます。
シナリオ G（アクティブの障害なし、スタンバイで 2 つの障害）
アクティブの障害なし、スタンバイで 2 つの障害
回復シナリオ：
アクティブの障害なし
スタンバイで 2 つの障害
解決の手順：
アクティブに障害がなく、スタンバイ スーパバイザに 2 つの障害がある場合は、影響を与えない回復を実行できます。
回復手順では、スタンバイのリロードを実行します。
1.通常、デュアルフラッシュ障害のあるスーパーバイザでは、ソフトウェアの「reload module x」によってRAIDが部分的にしか修復されないか、またはリブート時に電源投入状態のままになる可能性があります。
そのため、デュアル フラッシュ障害が発生しているスーパバイザの物理的な抜き差しを行い、電源を外してからモジュールに電力を再供給するか、以下のコマンドを実行できます（x はスタンバイ スロット番号）。
# out-of-service module x
# no poweroff module x
スタンバイが powered-up 状態でスタックし、上記の手順を実行した後、最終的に電源サイクルが続くのは、スタンバイをリロードしているアクティブが時間内に起動しないことが原因である可能性があります。
これは、ブートフラッシュや RAID の再初期化を試行するスタンバイを起動していることが原因です。この処理には最大 10 分かかる可能性がありますが、その処理が完了する前にアクティブによってリセットが行われます。
この問題を解決するには、powered-up 状態でスタックしているスタンバイ スロット番号を表す「x」を使用して、次を設定します。
(config)# system standby manual-boot
(config)# reload module x force-dnld
上記のコマンドを実行すると、アクティブがスタンバイを自動的にリセットすることはなくなり、スタンバイをリロードしてそのイメージをアクティブから強制的に同期します。
10 ～ 15 分待つと、スタンバイは最終的に ha-stanby 状態になります。ha-stanby 状態になった後、次のコマンドでスタンバイの自動リブートを再度有効にします。
(config)# system no standby manual-boot
6. スタンバイが「ha-standby」状態でオンラインに戻ったら、回復ツールを実行して回復が完了したか確認する必要があります。 ツールは次のリンクからダウンロードできます。
switch# show system internal file /proc/mdstat
Personalities : [raid1]
md6 : active raid1 sdd6[2] sdc6[0]
77888 blocks [2/1] [U_] <-- "U_" represents the broken state
resync=DELAYED
md5 : active raid1 sdd5[2] sdc5[0]
78400 blocks [2/1] [U_]
resync=DELAYED
md4 : active raid1 sdd4[2] sdc4[0]
39424 blocks [2/1] [U_]
resync=DELAYED
md3 : active raid1 sdd3[2] sdc3[0]
1802240 blocks [2/1] [U_]
[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
unused devices: <none>
回復が終了すると、次のようになります。
switch# show system internal file /proc/mdstat Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
77888 blocks [2/2] [UU] <-- "UU" represents the correct state
md5 :active raid1 sdd5[1] sdc5[0]
78400 blocks [2/2] [UU]
md4 :active raid1 sdd4[1] sdc4[0]
39424 blocks [2/2] [UU]
md3 :active raid1 sdd3[1] sdc3[0]
1802240 blocks [2/2] [UU]
unused devices: <none>
すべてのディスクが [UU] 状態になった後、RAID アレイは両方のディスクが同期された状態で完全にバックアップされます。
シナリオ H（アクティブで 2 つの障害、スタンバイで 1 つの障害）
アクティブで 2 つの障害、スタンバイで 1 つの障害
回復シナリオ：
アクティブで 2 つの障害
スタンバイで 1 つの障害
解決の手順：
アクティブで 2 つの障害が発生し、スタンバイ スーパバイザで 1 つの障害が発生している場合、スタンバイがアクティブと実行コンフィギュレーションを同期できなくなってから追加された実行コンフィギュレーションの量によっては、影響を与えない回復が可能です。
回復手順では、アクティブ スーパバイザの現在の実行コンフィギュレーションをバックアップして、正常なスタンバイ スーパバイザにフェールオーバーし、不足している実行コンフィギュレーションを新しいアクティブにコピーして、前のアクティブを手動でオンラインにした後に、回復ツールを実行します。
1. すべての実行コンフィギュレーションを「copy running-config tftp:vdc-all」を使用して外部にバックアップします。 デュアル フラッシュ障害が発生している場合、読み取り専用に再マウントされたシステムがスタートアップ コンフィギュレーションに存在しないため、コンフィギュレーションが変更されています。影響を受けるモジュールの「show system internal raid」を参照して、2 つ目のディスクで障害が発生してこのシステムが読み取り専用になった時点を確認できます。そこから、各 VDC の「show accounting log」を参照して、デュアル フラッシュ障害後に実行された変更内容を確認し、リロード時にスタートアップ コンフィギュレーションで維持される追加内容を把握できます。
デュアル フラッシュ障害が発生している 1 台のスーパバイザをリロードすると、スタートアップ コンフィギュレーションが消去される可能性があるため、コンフィギュレーションを外部にバックアップする必要があります。
2. 実行コンフィギュレーションをアクティブ スーパバイザからコピーしたら、スタートアップ コンフィギュレーションと比較して、最後の保存以降の変更内容を確認することをお勧めします。 これは、「show startup-configuration」で確認できます。 当然、違いは環境によってまったく異なりますが、スタンバイがアクティブとしてオンラインになるときに失われている内容を把握しておくと役に立ちます。 また、違いをメモ帳にコピーして、スイッチオーバー後に新しいアクティブ スーパバイザにすぐに追加できるようにすることをお勧めします。
を選択します。 違いを評価した後に、スーパバイザのスイッチオーバーを実行する必要があります。 TAC では、予測しない問題が生じる可能性があるため、スイッチオーバーはメンテナンス期間に実行することをお勧めします。 スタンバイへのフェールオーバーを実行するコマンドは、「system switchover」です。
4. スイッチオーバーは非常に迅速に実行され、新しいスタンバイがリブートを開始します。 この際に、失われたコンフィギュレーションを新しいアクティブに追加します。 これは TFTP サーバ（または前にコンフィギュレーションが保存された場所）からコンフィギュレーションをコピーするか、単純に CLI でコンフィギュレーションを追加して実行できます。tftp から実行コンフィギュレーションに直接コピーせず、最初にブートフラッシュにコピーしてから実行コンフィギュレーションにコピーします。 ほとんどの場合、失われたコンフィギュレーションは非常に短く、CLI オプションで対応できます。
5. しばらくすると、新しいスタンバイ スーパバイザが「ha-standby」状態でオンラインに復帰する場合がありますが、通常は「powered-up」状態でスタックします。 この状態は、「show module」コマンドを使用して、モジュールの横にある「Status」列を参照することで確認できます。
新しいスタンバイが「powered-up」状態で起動する場合は、手動でオンラインに戻す必要があります。 これは、次のコマンドを実行して行います。「x」は「powered-up」状態でスタックしているスタンバイ モジュールです。
(config)# out-of-service module
(config)# no poweroff module x
スタンバイが powered-up 状態でスタックし、上記の手順を実行した後、最終的に電源サイクルが続くのは、スタンバイをリロードしているアクティブが時間内に起動しないことが原因である可能性があります。
これは、ブートフラッシュや RAID の再初期化を試行するスタンバイを起動していることが原因です。この処理には最大 10 分かかる可能性がありますが、その処理が完了する前にアクティブによってリセットが行われます。
この問題を解決するには、powered-up 状態でスタックしているスタンバイ スロット番号を表す「x」を使用して、次を設定します。
(config)# system standby manual-boot
(config)# reload module x force-dnld
上記のコマンドを実行すると、アクティブがスタンバイを自動的にリセットすることはなくなり、スタンバイをリロードしてそのイメージをアクティブから強制的に同期します。
10 ～ 15 分待つと、スタンバイは最終的に ha-stanby 状態になります。ha-stanby 状態になった後、次のコマンドでスタンバイの自動リブートを再度有効にします。
(config)# system no standby manual-boot
6. スタンバイが「ha-standby」状態でオンラインに戻ったら、回復ツールを実行して回復が完了したことことを確認し、アクティブの 1 つのディスク障害を修復する必要があります。 ツールは次のリンクからダウンロードできます。
switch# show system internal file /proc/mdstat \
Personalities : [raid1]
md6 : active raid1 sdd6[2] sdc6[0]
77888 blocks [2/1] [U_] <-- "U_" represents the broken state
resync=DELAYED
md5 : active raid1 sdd5[2] sdc5[0]
78400 blocks [2/1] [U_]
resync=DELAYED
md4 : active raid1 sdd4[2] sdc4[0]
39424 blocks [2/1] [U_]
resync=DELAYED
md3 : active raid1 sdd3[2] sdc3[0]
1802240 blocks [2/1] [U_]
[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
unused devices: <none>
回復が終了すると、次のようになります。
switch# show system internal file /proc/mdstat Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
77888 blocks [2/2] [UU] <-- "UU" represents the correct state
md5 :active raid1 sdd5[1] sdc5[0]
78400 blocks [2/2] [UU]
md4 :active raid1 sdd4[1] sdc4[0]
39424 blocks [2/2] [UU]
md3 :active raid1 sdd3[1] sdc3[0]
1802240 blocks [2/2] [UU]
unused devices: <none>
すべてのディスクが [UU] 状態になった後、RAID アレイは両方のディスクが同期された状態で完全にバックアップされます。
1 つの障害が発生している現在のアクティブが回復ツールで回復しない場合は、もう一度「system switchover」を試して現在のスタンバイを「ha-standby」の状態にします。 それでも成功しない場合は、Cisco TAC にお問い合わせください。
シナリオ I（アクティブで 1 つの障害、スタンバイで 2 つの障害）
回復シナリオ：
アクティブで 1 つの障害
スタンバイで 2 つの障害
解決の手順：
アクティブに 1 つの障害があり、スタンバイ スーパバイザに 2 つの障害があるデュアル スーパバイザのシナリオでは、影響を与えない回復が可能ですが、多くの場合はリロードが必要です。
このプロセスでは、最初にすべての実行コンフィギュレーションをバックアップした後に、回復ツールを使用して障害のある Compact Flash をアクティブに回復するように試み、成功した場合は、スタンバイを手動でリロードして回復ツールを再実行します。 最初の回復でアクティブの障害のあるフラッシュを回復できなかった場合は、TAC にデバッグ プラインを使用した手動回復を依頼する必要があります。
ツールをダウンロードして解凍し、ボックスのブートフラッシュにアップロードした後、次のコマンドを実行して回復を開始する必要があります。
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
ツールの実行が開始され、切断されたディスクが検出されて、それらのディスクが RAID アレイと再同期されます。
回復の状態を次のコマンドで確認できます。
# show system internal file /proc/mdstat
回復処理が進んでいることを確認します。すべてのディスクが完全に修復されて [UU] の状態になるまで数分かる場合があります。回復処理例は次のようになります。
switch# show system internal file /proc/mdstat \
Personalities : [raid1]
md6 : active raid1 sdd6[2] sdc6[0]
77888 blocks [2/1] [U_] <-- "U_" represents the broken state
resync=DELAYED
md5 : active raid1 sdd5[2] sdc5[0]
78400 blocks [2/1] [U_]
resync=DELAYED
md4 : active raid1 sdd4[2] sdc4[0]
39424 blocks [2/1] [U_]
resync=DELAYED
md3 : active raid1 sdd3[2] sdc3[0]
1802240 blocks [2/1] [U_]
[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
unused devices: <none>
回復が終了すると、次のようになります。
switch# show system internal file /proc/mdstat
Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
77888 blocks [2/2] [UU] <-- "UU" represents the correct state
md5 :active raid1 sdd5[1] sdc5[0]
78400 blocks [2/2] [UU]
md4 :active raid1 sdd4[1] sdc4[0]
39424 blocks [2/2] [UU]
md3 :active raid1 sdd3[1] sdc3[0]
1802240 blocks [2/2] [UU]
unused devices: <none>
すべてのディスクが [UU] 状態になった後、RAID アレイは両方のディスクが同期された状態で完全にバックアップされます。
を選択します。 手順 2 で回復ツールを実行した後に、アクティブ スーパバイザの障害のある Compact Flash を回復できない場合は、TAC に linux デバッグ プラグインを使用した手動回復の実行を依頼する必要があります。
4. 両方のフラッシュが「[UU]」としてアクティブに表示されたことを確認した後、スタンバイ スーパバイザの手動リブートに進みます。 これは、次のコマンドを実行して行います。「x」は「powered-up」状態でスタックしているスタンバイ モジュールです。
(config)# out-of-service module x
(config)# no poweroff module x
これによりスタンバイ スーパバイザは「ha-standby」状態になります（「show module」出力の Status カラム表示で確認します）。 成功したら、手順 6 に進み、成功しない場合は手順 5 で説明している手順を試します。
5. スタンバイが powered-up 状態でスタックし、上記の手順を実行した後、最終的に電源サイクルが続くのは、スタンバイをリロードしているアクティブが時間内に起動しないことが原因である可能性があります。 これは、ブートフラッシュや RAID の再初期化を試行するスタンバイを起動していることが原因です。この処理には最大 10 分かかる可能性がありますが、その処理が完了する前にアクティブによってリセットが行われます。 この問題を解決するには、powered-up 状態でスタックしているスタンバイ スロット番号を表す「x」を使用して、次を設定します。
(config)# system standby manual-boot
(config)# reload module x force-dnld
上記のコマンドを実行すると、アクティブがスタンバイを自動的にリセットすることはなくなり、スタンバイをリロードしてそのイメージをアクティブから強制的に同期します。
10 ～ 15 分待つと、スタンバイは最終的に ha-stanby 状態になります。ha-stanby 状態になった後、次のコマンドでスタンバイの自動リブートを再度有効にします。
(config)# system no standby manual-boot
6. スタンバイが「ha-standby」状態でオンラインに戻ったら、回復ツールを実行して回復が完了したか確認する必要があります。 この手順でアクティブに対して実行したものと同じツールを実行できます。回復ツールはアクティブとスタンバイで実行されるため、追加のダウンロードは不要です。
シナリオ J（アクティブで2つの障害、スタンバイで2つの障害）
回復シナリオ：
アクティブで 2 つの障害
スタンバイで 2 つの障害
解決の手順：
要約
FAQ
この問題に対する恒久的な解決策はありますか。
以下の「長期にわたる解決策」を参照してください。
スタンバイのスーパバイザをリロードしてフェールオーバーすることにより、アクティブとスタンバイでデュアル フェールオーバーを回復できないのはなぜですか。
回復できない原因は、スタンバイ スーパバイザを「ha-standby」状態で起動可能にするために、アクティブ スーパバイザがいくつかのデータ（SNMP 情報など）を Compact Flash に書き込む必要がありますが、それ自体にデュアル フラッシュ障害がある場合、その処理を実行できないためです。
フラッシュ回復ツールで Compact Flash をマウントし直すことができない場合どうなりますか。
このシナリオのオプションについては、Cisco TAC にお問い合わせください。
このバグは Nexus 7700 Sup2E にも影響しますか。
N7700 Sup2E - CSCuv64056 には別の欠陥があります。 回復ツールは N7700 では機能しません。
回復ツールは NPE イメージに対して機能しますか。
回復ツールは NPE イメージでは機能しません。
コードの解決済みバージョンへの ISSU によってこの問題は解決されますか。
いいえ。ISSUはスーパーバイザのスイッチオーバーを利用しますが、コンパクトフラッシュの障害が原因で正常に動作しない場合があります。
影響を受けるボードをリセットします。RAID の状態は 0xF0 を示しますが、GOLD テストは失敗しますか。
RAID の状態ビットは、自動回復の適用後ボードがリセットされるとリセットされます。
ただし、すべての障害状態が自動的に回復されるわけではありません。
RAID の状態ビットが [2/2] [UU] として示されない場合、回復は不完全です。
リストされている回復手順に従ってください。
フラッシュの障害は動作に影響しますか。
いいえ。ただし、システムでは電源障害でバックアップをブートしない場合があります。スタートアップ コンフィギュレーションも失われます。
監視と回復に関してユーザの観点から健全な実行システムを実現するにはどのような推奨事項がありますか。
GOLD コンパクト テストの状態で障害がないか確認し、最初のフラッシュ パーツで障害が発生するとすぐに回復を行います。
影響のあるコードから修正済みリリースへの ISSU を実行して eUSB フラッシュの障害を修正できますか。
ISSU は障害が発生した eUSB を修正しません。最適なオプションは、sup の 1 つの eUSB 障害に対して回復ツールを実行するか、デュアル eUSB 障害の場合は sup をリロードします。
問題が修正されたら、アップグレードを実行します。CSCus22805 の修正では 1 つの eUSB 障害のみを修正できます。これは、システムを定期的にスキャンし、スクリプトを使用してアクセス不可または読み取り専用の eUSB を復帰させることで実行できます。
スーパバイザで両方の eUSB フラッシュ障害が同時に発生することはまれであるため、この回避策は有効です。
プラグインまたはリロードを使用してフラッシュの障害を修正した場合、問題が再発するまでどのくらいの時間がかかりますか。
通常、この問題は稼働時間が長いと発生します。この期間は正確に定量化されていませんが、1 年以上にわたる場合があります。結果として、読み書きについて eUSB フラッシュにかかる負荷が多いほど、システムでこのシナリオが生じる可能性が高くなります。
show system internal raid では、フラッシュの状態が異なるセクションに 2 回表示されます。また、これらのセクションは一致していません。
最初のセクションには現在の状態が表示され、2 番目のセクションにはブートアップの状態が表示されます。
現在の状態は重要で、常に UU が示される必要があります。
長期にわたる解決策
この問題の回避策は 6.2(14) にありますが、ファームウェアの修正が 6.2(16) と 7.2(x) 以降に追加されています。
この問題を完全に解決するには、ファームウェアの修正を含むリリースにアップグレードすることをお勧めします。
NXOS の修正済みバージョンにアップグレードできない場合は、2 つの解決策があります。
解決策 1 は、スケジューラを使用してフラッシュ回復ツールを毎週予防的に実行する方法です。 ブートフラッシュでフラッシュ回復ツールとともに以下のスケジューラ設定を使用します。
feature scheduler
scheduler job name Flash_Job
copy bootflash:/n7000-s2-flash-recovery-tool.10.0.2.gbin bootflash:/flash_recovery_tool_copy
load bootflash:/flash_recovery_tool_copy
exit
scheduler schedule name Flash_Recovery
job name Flash_Job
time weekly 7
注：
- フラッシュ回復は同じ名前とし、ブートフラッシュ内に保存する必要があります。
- 「time weekly 7」設定の 7 は曜日を表し、この場合は土曜日です。
- 推奨されるフラッシュ回復ツールの最大実行頻度は週に 1 回です。
解決策 2 は、このtechnote リンクで説明されています。
フィードバック