Nexus 7000 Supervisor 2/2E闪存故障恢复
目录
简介
本文档介绍软件缺陷CSCus22805中记录的Nexus 7000 Supervisor 2/2E闪存故障问题、所有可能的故障场景和恢复步骤。
背景
每个N7K Supervisor 2/2E都配备2个RAID1配置的eUSB闪存设备，一个主镜像和一个镜像。它们共同为启动映像、启动配置和持久应用数据提供非易失性存储库。
在服务数月或数年的时间内，其中一个设备可能会从USB总线断开，从而导致RAID软件从配置中丢弃该设备。设备仍可通过1/2设备正常运行。但是，当第二台设备从阵列中退出时，bootflash会以只读方式重新加载，这意味着您不能将配置或文件保存到bootflash，或允许备用设备在重新加载时同步到主用设备。
在双闪存故障状态下运行的系统不会受到操作影响，但需要重新加载受影响的Supervisor才能从该状态恢复。此外，对运行配置的任何更改都不会反映在启动中，而且会在断电时丢失。
症状
已发现以下症状：
- 闪存诊断故障
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故障，通常在尝试故障切换到备用Supervisor时
诊断
要诊断闪存卡的当前状态，您需要使用这些内部命令。请注意，该命令不会解析出，并且必须完整键入：
switch# show system internal raid | grep -A 1 "当前RAID状态信息"
switch# show system internal file /proc/mdstat
如果机箱中有两个管理引擎，您需要检查备用管理引擎的状态并确定您面临的故障场景。检查这一点，方法是使用“slot x”关键字预置命令，其中“x”是备用Supervisor的插槽编号。这允许您在备用设备上远程运行命令。
switch# slot 2 show system internal raid | grep -A 1 "当前RAID状态信息"
switch# slot 2 show system internal file /proc/mdstat
这些命令将提供大量RAID统计信息和事件，但您只关注当前RAID信息。
在“来自CMOS的RAID数据”行中，您需要查看0xa5之后的十六进制值。 这将显示当前可能面临问题的闪烁数量。
例如：
switch# show system internal raid | grep -A 1 "Current RAID status info"
Current RAID status info:
RAID data from CMOS = 0xa5 0xc3
在此输出中，您想要查看0xa5旁边的编号，即0xc3。 然后，您可以使用这些密钥来确定主闪存或辅助闪存是否发生故障，或者两者都发生故障。上面的输出显示0xc3，它告诉我们主压缩闪烁（闪烁）和辅助压缩闪烁（闪烁）都失败了。
| 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]
在此场景中，您看到主闪存未启动[_U]。正常输出将显示所有块为[UU]。
场景
要确定您所面临的场景，您需要使用上述“Diagnostics”（诊断）部分中的命令与下面的Scenario Letter(场景字母)关联。 使用这些列，匹配每个管理引擎上失败紧凑闪烁的数量。
例如，如果您看到代码在活动Supervisor上是0xe1，在备用上是0xd2，则此代码在活动Supervisor上是“1 Fail”，在备用Supervisor上是“1 Fail”，即方案字母“D”。
单个管理引擎：
| 场景字母 | 主用管理引擎 | 活动管理引擎代码 |
| A | 1失败 | 0xe1或0xd2 |
| B | 2个失败 | 0xc3 |
双管理引擎：
| 场景字母 | 主用管理引擎 | standby supervisor | 活动管理引擎代码 | 备用管理引擎代码 |
| C | 0失败 | 1失败 | 0xf0 | 0xe1或0xd2 |
| D | 1失败 | 0失败 | 0xe1或0xd2 | 0xf0 |
| E | 1失败 | 1失败 | 0xe1或0xd2 | 0xe1或0xd2 |
| F | 2个失败 | 0失败 | 0xc3 | 0xf0 |
| G | 0失败 | 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（0在主用设备上发生故障，1在备用设备上发生故障）
故障场景：
0在活动时失败
1在备用设备上发生故障
解决步骤：
在双Supervisor设置的情况下，主用设备上无闪存故障，备用设备上无单一故障，可以执行无影响的恢复。
1.由于主用设备没有发生故障，而备用设备只有一次故障，因此可以将闪存恢复工具加载到主用设备上并执行。运行该工具后，它将自动将其自身复制到备用设备并尝试重新同步阵列。 恢复工具可在此处下载：
下载该工具、解压缩并将其上传到盒子的bootflash后，您需要执行以下命令开始恢复：
# 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.如果闪存恢复工具不成功，因为主用磁盘已启动两个磁盘，则备用磁盘应该能够在重新加载时成功同步到主用磁盘。
因此，在计划的窗口中，对备用Supervisor执行“out-of-service module x”，建议对备用Supervisor进行控制台访问，以便在出现任何意外问题时观察引导过程。在Supervisor关闭后，等待几秒钟，然后对备用设备执行“no power off 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在主用模式下发生故障，0在备用模式下发生故障）
恢复场景：
1在活动时失败
0在备用设备上发生故障
解决步骤：
在双Supervisor设置方案中，主用设备有1个闪存故障，备用设备无故障，因此可以使用闪存恢复工具执行无影响的恢复。
1.由于备用设备没有故障，而主用设备只有单个故障，因此可以将闪存恢复工具加载到主用设备上并执行。运行该工具后，它将自动将其自身复制到备用设备并尝试重新同步阵列。 恢复工具可在此处下载：
下载工具、解压缩并将其上传到活动程序的bootflash后，您需要执行以下命令开始恢复：
# 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.由于没有管理引擎处于只读状态，第一步是尝试使用快速恢复工具。
恢复工具可在此处下载：
下载工具、解压缩并将其上传到活动程序的bootflash后，您需要执行以下命令开始恢复：
# 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的当前状态。如果两个交换机上仍有一个闪存故障，则尝试“系统切换”，这将重新加载当前主用模式，并强制备用模式成为主用模式。
将上一个主用设备重新加载回“ha-standby”后，检查其RAID状态，因为在重新加载期间应将其恢复。
如果Supervisor在切换后成功恢复，您可以再次尝试运行闪存恢复工具以尝试修复当前主用Supervisor上的单个磁盘故障，或者尝试另一个“系统切换”以重新加载当前主用并强制将之前已修复的主用和当前备用状态恢复为主用角色。验证重新加载的Supervisor是否再次修复了两个磁盘，如有必要，请重新运行恢复工具。
3.如果在此过程中，切换未修复RAID，请对备用模块执行“服务中断模块x”，然后执行“no power off module x”以完全移除模块并重新为其供电。
如果停止服务不成功，尝试物理重新拔插备用。
如果在运行恢复工具后，一个管理引擎恢复其RAID，而另一个管理引擎仍有故障，则强制发生单个故障的管理引擎备用，如有必要，执行“系统切换”。如果只有一个故障的Supervisor是
已处于备用状态，请对备用模块执行“服务中断模块x”操作，并执行“无电源模块x”操作，以完全移除模块并重新为其供电。如果仍然无法恢复，请尝试物理重新拔插模块。如果重新拔插无法修复，
使用密码恢复过程进入交换机引导提示符，然后执行“init system”以重新初始化bootflash。如果仍失败，请让TAC尝试手动恢复。
场景 F（2在活动状态发生故障，0在备用状态发生故障）
恢复场景：
2在活动接口上失败
0在备用设备上发生故障
解决步骤：
如果主用管理引擎上有2个故障，备用管理引擎上有0个故障，则有可能进行无影响的恢复，具体取决于由于备用管理引擎无法将其运行配置与主用管理引擎同步而添加了多少运行配置。
恢复过程将是：从主用管理引擎复制当前运行配置，故障切换至正常备用管理引擎，将缺少的运行配置复制到新的主用管理引擎，手动使以前的主用管理引擎联机，然后运行恢复工具。
2. 将运行配置从活动Supervisor复制出来后，最好将其与启动配置进行比较，以查看自上次保存以来发生了哪些更改。 这可以通过“show startup-configuration”看到。 当然，差异将完全取决于环境，但最好了解当备用设备作为主用设备联机时可能缺少什么。 最好在记事本中复制这些差异，以便在切换后快速将其添加到新的活动Supervisor。
3. 评估差异之后，您需要执行管理引擎切换。 TAC建议在维护时段期间完成此操作，因为可能会出现未知问题。 执行到备用设备的故障切换的命令将是“system switchover”。
4. 切换应会非常快地进行，并且新的备用设备将开始重新启动。 在此期间，您需要将所有缺失的配置重新添加到新的主用配置中。 这可以通过从TFTP服务器复制配置（或以前保存的任何位置），或者只在CLI中手动添加配置来实现。 在大多数情况下，缺少的配置非常短，而CLI选项将是最可行的。
5. 一段时间后，新的备用Supervisor可能会以“ha-standby”状态重新联机，但通常会出现的情况是，它将停滞在“powered-up”状态。 可使用“show module”命令并参考模块旁边的“Status”列查看状态。
如果新的备用设备处于“通电”状态，则需要手动使其重新联机。 这可以通过发出以下命令来完成，其中“x”是停滞在“通电”状态的备用模块：
(config)# out-of-service module x
(config)#no poweroff module x
6. 一旦备用设备在“ha-standby”状态下重新联机，您需要运行恢复工具以确保恢复完成。 可通过以下链接下载该工具：
下载该工具、解压缩并将其上传到盒子的bootflash后，您需要执行以下命令开始恢复：
# 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（0在主用设备上发生故障，2在备用设备上发生故障）
0在活动模式上发生故障，2在备用模式上发生故障
恢复场景：
0在活动时失败
2在备用设备上发生故障
解决步骤：
在主用管理引擎上有0个故障，备用管理引擎上有2个故障，可以实现无影响的恢复。
恢复过程将是重新加载备用设备。
1.在双闪存故障的管理引擎中，通常可以看到，软件“reload module x”只能部分修复RAID或在重新启动时使其停电。
因此，建议使用双闪存故障物理重新拔插Supervisor以完全移除并重新接通模块的电源，或者您可以执行以下操作（x表示备用插槽编号）：
# out-of-service module x
# no power off module x
如果您看到备用设备一直停滞在通电状态，并最终在上述步骤后保持电源循环，这可能是由于主用设备重新加载备用设备导致无法及时启动。
这可能是由于正在引导的备用设备尝试重新初始化其bootflash/RAID（可能需要10分钟），但它在完成之前一直被主用设备重置。
要解决此问题，请使用“x”为停留在通电状态的备用插槽#配置以下内容：
(config)# system standby manual-boot
(config)# reload module x force-dnld
上述操作将使主用设备不会自动重置备用设备，然后重新加载备用设备并强制其从主用设备同步其映像。
等待10-15分钟，查看备用设备是否最终能够进入ha-standby状态。当它处于ha-standby状态后，使用以下命令重新启用备用设备的自动重启：
(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”，以确定第二个磁盘何时发生故障，即系统变为只读状态。从那里，您可以查看每个VDC的“show accounting log”，以确定自双闪存故障以来进行了哪些更改，这样您就会知道重新加载后如果启动配置继续存在，要添加什么。
请注意，在双闪存故障的Supervisor重新加载时，启动配置可能会被擦除，因此必须在外部备份配置。
2. 将运行配置从活动Supervisor复制出来后，最好将其与启动配置进行比较，以查看自上次保存以来发生了哪些更改。 这可以在“show startup-configuration”中看到。 当然，差异将完全取决于环境，但最好了解当备用设备作为主用设备联机时可能缺少什么。 最好在记事本中复制这些差异，以便在切换后快速将其添加到新的活动Supervisor。
3. 评估差异之后，您需要执行管理引擎切换。 TAC建议在维护时段期间完成此操作，因为可能会出现未知问题。 执行到备用设备的故障切换的命令将是“系统切换”。
4. 切换应会非常快地进行，并且新的备用设备将开始重新启动。 在此期间，您需要将所有缺失的配置重新添加到新的主用配置中。 这可以通过从TFTP服务器复制配置（或以前保存的任何位置）完成，或者只需在CLI中手动添加配置，不要直接从tftp复制到运行配置，先复制到bootflash，然后再复制到运行配置。 在大多数情况下，缺少的配置非常短，而CLI选项将是最可行的。
5. 一段时间后，新的备用Supervisor可能会以“ha-standby”状态重新联机，但通常会出现的情况是，它将停滞在“powered-up”状态。 可使用“show module”命令并参考模块旁边的“Status”列来查看状态。
如果新的备用设备处于“通电”状态，则需要手动使其重新联机。 这可以通过发出以下命令来完成，其中“x”是停滞在“通电”状态的备用模块：
(config)#服务中断模块
(config)#no poweroff module x
如果您看到备用设备一直停滞在通电状态，并最终在上述步骤后保持电源循环，这可能是由于主用设备重新加载备用设备导致无法及时启动。
这可能是由于正在引导的备用设备尝试重新初始化其bootflash/RAID（可能需要10分钟），但它在完成之前一直被主用设备重置。
要解决此问题，请使用“x”为停留在通电状态的备用插槽#配置以下内容：
(config)# system standby manual-boot
(config)# reload module x force-dnld
上述操作将使主用设备不会自动重置备用设备，然后重新加载备用设备并强制其从主用设备同步其映像。
等待10-15分钟，查看备用设备是否最终能够进入ha-standby状态。当它处于ha-standby状态后，使用以下命令重新启用备用设备的自动重启：
(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阵列将完全备份，两个磁盘均同步。
如果恢复工具未恢复出现单个故障的当前主用状态，则尝试另一个“系统切换”，确保当前备用状态处于“ha-standby”状态。 如果仍不成功，请联系思科TAC
场景I（1在主用模式下发生故障，2在备用模式下发生故障）
恢复场景：
1在活动时失败
2在备用设备上发生故障
解决步骤：
在双管理引擎场景中，主用管理引擎上有1个故障，备用管理引擎上有2个故障，因此可以执行无影响恢复，但在很多情况下，可能需要重新加载。
此过程将首先备份所有运行配置，然后尝试使用恢复工具恢复主用上的故障闪存，如果成功，您将手动重新加载备用闪存并再次运行恢复工具。 如果初始恢复尝试无法恢复活动上的失败闪存，则必须让TAC尝试使用调试插件进行手动恢复。
下载该工具、解压缩并将其上传到盒子的bootflash后，您需要执行以下命令开始恢复：
# 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阵列将完全备份，两个磁盘均同步。
3. 如果在步骤2中运行恢复工具后，无法恢复活动Supervisor上发生故障的闪存，必须联系TAC尝试使用Linux调试插件进行手动恢复。
4. 检验活动状态下两个闪烁均显示为“[UU]”后，您可以继续手动重新启动备用Supervisor。 这可以通过发出以下命令来完成，其中“x”是停滞在“通电”状态的备用模块：
(config)# out-of-service module x
(config)#no poweroff module x
这应该使备用Supervisor恢复到“ha-standby”状态(通过查看“show module”输出中的Status列检查此情况)。 如果此操作成功，请继续步骤6，如果不成功，请尝试步骤5中概述的步骤。
5. 如果您看到备用设备一直停滞在通电状态，并最终在上述步骤后保持电源循环，这可能是由于主用设备重新加载备用设备导致无法及时启动。 这可能是由于正在引导的备用设备尝试重新初始化其bootflash/RAID（可能需要10分钟），但它在完成之前一直被主用设备重置。 要解决此问题，请使用“x”为停留在通电状态的备用插槽#配置以下内容：
(config)# system standby manual-boot
(config)# reload module x force-dnld
上述操作将使主用设备不会自动重置备用设备，然后重新加载备用设备并强制其从主用设备同步其映像。
等待10-15分钟，查看备用设备是否最终能够进入ha-standby状态。当它处于ha-standby状态后，使用以下命令重新启用备用设备的自动重启：
(config)# system no standby manual-boot
6. 一旦备用设备在“ha-standby”状态下重新联机，您需要运行恢复工具以确保恢复完成。 您可以为此步骤运行在主用设备上使用的相同工具，由于恢复工具在主用和备用设备上运行，因此无需额外下载。
场景 J（2在活动状态上失败，2在备用状态上失败）
恢复场景：
2在活动接口上失败
2在备用设备上发生故障
解决步骤：
摘要
常见问题解答
这个问题有没有永久性的解决办法？
请参见下面的长期解决方案部分。
为什么不能通过重新加载备用Supervisor和故障转移来恢复主用和备用上的双故障切换？
无法这样做的原因是，为了允许备用Supervisor在“ha-standby”状态下启动，主用Supervisor必须向其闪存（SNMP信息等）中写入若干内容，如果它自身有双闪存故障，则无法执行此操作。
如果闪存恢复工具无法重新装载闪存，会发生什么情况？
请联系Cisco TAC了解此场景中的选项。
此Bug是否也会影响Nexus 7700 Sup2E?
N7700 Sup2E - CSCuv64056有一个单独的缺陷。 恢复工具在N7700上不起作用。
恢复工具是否适用于NPE映像？
恢复工具不适用于NPE映像。
ISSU到已解析版本的代码是否会解决此问题？
不可以。 ISSU将使用管理引擎切换，由于紧凑型闪存故障，该功能可能无法正常运行。
重置受影响的主板。Raid状态显示0xF0，但GOLD测试仍失败？
RAID状态位在应用自动恢复后板重置后重置。
但是，并非所有故障条件都能自动恢复。
如果RAID状态位未打印为[2/2] [UU]，则恢复未完成。
执行列出的恢复步骤
闪存故障是否会对操作产生影响？
否，但系统可能无法在电源故障时重新启动。启动配置也会丢失。
从客户的角度出发，在监控和恢复方面，建议如何使系统正常运行？
检查GOLD compact test状态是否有任何故障，并在第一个闪存部件出现故障后立即尝试恢复。
能否通过将受影响代码中的ISSU更改为固定版本来修复发生故障的eusb闪存故障？
ISSU无法修复发生故障的eUSB。最佳选择是在管理引擎上运行单个eusb故障的恢复工具，或在双eusb故障时重新加载sup。
一旦问题得到纠正，则进行升级。针对CSCus22805的修复程序有助于仅纠正单个eusb故障，它通过定期扫描系统并尝试使用脚本重新唤醒无法访问的或只读的eUSB来修复此问题。
Supervisor上同时出现两个eusb闪存故障的情况非常少见，因此这种解决方法将非常有效。
如果使用插件或重新加载修复闪存故障，问题需要多长时间才能重新出现？
通常，正常运行时间较长。这不能准确量化，范围可能在一年或更长。最重要的是，在读取写入方面，eusb闪存上的压力越大，系统进入此场景的概率越高。
Show system internal raid在不同部分显示两次闪存状态。这些部分也不一致
第一部分显示当前状态，第二部分显示启动状态。
当前状态是重要的，它应始终显示为UU。
长期解决方案
此缺陷在6.2(14)中有解决方法，但固件修复已添加到6.2(16)和7.2(x)及更高版本。
建议升级到包含固件修复程序的版本，以完全解决此问题。
如果您无法升级到NXOS的固定版本，有两种可能的解决方案。
解决方案1是每周使用调度程序前瞻性地运行闪存恢复工具。 在bootflash中使用闪存恢复工具配置以下调度程序：
功能调度程序
计划程序作业名称Flash_Job
copy bootflash:/n7000-s2-flash-recovery-tool.10.0.2.gbin bootflash:/flash_recovery_tool_copy
load bootflash:/flash_recovery_tool_copy
退出
scheduler schedule name Flash_Recovery
作业名称Flash_Job
时间每周7
注意：
- 闪存恢复需要具有相同的名称并且位于bootflash中。
- “time weekly 7”配置中的7表示一周中的一天，在本例中为星期六。
- Cisco建议运行闪存恢复工具的最大频率为每周一次。
解决方案2在以下技术说明链接中提供
反馈