Recuperación ante fallos de Compact Flash de Nexus 7000 Supervisor 2/2E
Contenido
Introducción
Este documento describe el problema de falla de Compact Flash de Nexus 7000 Supervisor 2/2E documentado en el defecto de software CSCus2805, todos los escenarios de falla posibles y los pasos de recuperación.
Background
Cada supervisor 2/2E N7K está equipado con 2 dispositivos flash eUSB con configuración RAID1, uno principal y un espejo. Juntos proporcionan repositorios no volátiles para imágenes de arranque, configuración de inicio y datos de aplicaciones persistentes.
Lo que puede suceder es que, durante un período de meses o años de servicio, uno de estos dispositivos se desconecte del bus USB, lo que provoca que el software RAID elimine el dispositivo de la configuración. El dispositivo todavía puede funcionar normalmente con 1/2 dispositivos. Sin embargo, cuando el segundo dispositivo se cae de la matriz, la memoria flash de inicialización se vuelve a montar como de solo lectura, lo que significa que no puede guardar la configuración o los archivos en la memoria flash de inicialización, ni permitir que la memoria en espera se sincronice con la activa en caso de que se vuelva a cargar.
No hay impacto operativo en los sistemas que se ejecutan en un estado de falla de flash dual; sin embargo, se necesita una recarga del supervisor afectado para recuperarse de este estado. Además, cualquier cambio en la configuración en ejecución no se reflejará en el inicio y se perderá en caso de un corte de energía.
Síntomas
Se han observado los siguientes síntomas:
- Fallo de diagnóstico de 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--------------------------> .
- No se puede realizar un 'copy run start'
dcd02.ptfrnyfs# copy running-config startup-config
[########################################] 100%
Configuration update aborted: request was aborted
- eUSB pasa a ser de solo lectura o no responde
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
- Fallos de ISSU, generalmente al intentar conmutar por error al supervisor en espera
Diagnóstico
Para diagnosticar el estado actual de las tarjetas Compact Flash debe utilizar estos comandos internos. Observe que el comando no se analizará y debe escribirse completamente:
switch# show system internal raid | grep -A 1 "Current RAID status info"
switch# show system internal file /proc/mdstat
Si hay dos supervisores en el chasis, también deberá comprobar el estado del supervisor en espera para determinar a qué escenario de error se enfrenta. Verifique esto anteponiendo el comando con la palabra clave "slot x" donde "x" es el número de slot del supervisor en espera. Esto le permite ejecutar el comando de forma remota en el modo de espera.
switch# slot 2 show system internal raid | grep -A 1 "Current RAID status info"
switch# slot 2 show system internal file /proc/mdstat
Estos comandos proporcionarán muchas estadísticas y eventos RAID, pero sólo le preocupa la información RAID actual.
En la línea "RAID data from CMOS" (Datos RAID de CMOS), desea ver el valor hexadecimal después de 0xa5. Esto mostrará cuántos flashes pueden estar enfrentando un problema actualmente.
Por ejemplo:
switch# show system internal raid | grep -A 1 "Current RAID status info"
Current RAID status info:
RAID data from CMOS = 0xa5 0xc3
Desde esta salida, desea ver el número al lado de 0xa5 que es 0xc3. Puede utilizar estas claves para determinar si la memoria Compact Flash principal o secundaria ha fallado, o ambas. El resultado anterior muestra 0xc3 que nos dice que los flashes compactos primarios y secundarios han fallado.
| 0xf0 | No se notificaron fallos |
| 0xe1 | Fallo de flash principal |
| 0xd2 | Fallo de flash alternativo (o espejo) |
| 0xc3 | Error en primario y alternativo |
En la salida "/proc/mdstat" asegúrese de que todos los discos se muestren como "U", que representa "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]
En este escenario, verá que la memoria Compact Flash principal no está activa [_U]. Un resultado correcto mostrará todos los bloques como [UU].
Escenarios
Para determinar a qué escenario se enfrenta, necesitará utilizar los comandos anteriores en la sección "Diagnóstico" para correlacionarse con una Carta de escenario a continuación. Con las columnas, haga coincidir el número de flashes compactos fallidos en cada supervisor.
Por ejemplo, si ha visto que el código es 0xe1 en el supervisor activo y 0xd2 en el modo en espera, sería "1 Fail" en el activo y "1 Fail" en el modo en espera, que es la letra de escenario "D".
Supervisor único:
| Carta de escenario | Supervisor activo | Código de supervisor activo |
| R | 1 Fallo | 0xe1 o 0xd2 |
| B | 2 Fallos | 0xc3 |
Supervisores duales:
| Carta de escenario | Supervisor activo | supervisor en espera | Código de supervisor activo | Código de supervisor en espera |
| C | 0 Fallo | 1 Fallo | 0xf0 | 0xe1 o 0xd2 |
| D | 1 Fallo | 0 Fallo | 0xe1 o 0xd2 | 0xf0 |
| E | 1 Fallo | 1 Fallo | 0xe1 o 0xd2 | 0xe1 o 0xd2 |
| F | 2 Fallos | 0 Fallo | 0xc3 | 0xf0 |
| G | 0 Fallo | 2 Fallos | 0xf0 | 0xc3 |
| H | 2 Fallos | 1 Fallo | 0xc3 | 0xe1 o 0xd2 |
| I | 1 Fallo | 2 Fallo | 0xe1 o 0xd2 | 0xc3 |
| J | 2 Fallos | 2 Fallos | 0xc3 | 0xc3 |
Procedimiento de recuperación para cada escenario
Escenarios de fallos de supervisor único
Escenario A (1 fallo en el activo)
Escenario de recuperación:
1 Fallo en el activo
Pasos para la resolución:
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>
Escenario B (fallo de 2 en el activo)
Escenario de recuperación:
2 Fallos en el activo
Pasos para la resolución:
Escenarios de falla de supervisor dual
Escenario C (0 falla en activo, 1 falla en espera)
Escenario de falla:
0 Fallos en el activo
1 Fallo en espera
Pasos para la resolución:
En el escenario de una configuración de supervisor dual, sin fallas de flash en el activo y una sola falla en el modo en espera, se puede realizar una recuperación que no afecte.
1. Como el activo no tiene fallas y el modo de espera solo tiene una falla, la Herramienta de Recuperación de Flash se puede cargar en el activo y ejecutarse. Después de ejecutar la herramienta, se copiará automáticamente en el modo de espera e intentará sincronizar la matriz. La herramienta de recuperación se puede descargar aquí:
Una vez descargada la herramienta, descomprimida y cargada en la memoria de inicialización de la caja, deberá ejecutar el siguiente comando para comenzar la recuperación:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
La herramienta comenzará a funcionar y detectará los discos desconectados e intentará sincronizarlos con la matriz RAID.
Puede comprobar el estado de recuperación con:
# show system internal file /proc/mdstat
Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:
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>
Una vez finalizada la recuperación, debe verse de la siguiente manera:
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>
Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.
2. Si la herramienta de recuperación de Flash no funciona, ya que el activo tiene ambos discos activados, el modo en espera debe poder sincronizarse correctamente con el activo durante la recarga.
Por lo tanto, en una ventana programada, realice una "x de módulo fuera de servicio" para el supervisor en espera, se recomienda tener acceso de consola al modo en espera para observar el proceso de inicio en caso de que surjan problemas inesperados. Después de que el supervisor esté inactivo, espere unos segundos y luego ejecute "no poweroff module x" para el modo de espera. Espere hasta que el modo de espera se inicie completamente en el estado "ha-standby".
Una vez que el modo de espera esté activo, verifique el RAID con "slot x show system internal raid" y "slot x show system internal file /proc/mdstat".
Si no se realiza una copia de seguridad completa de ambos discos después de la recarga, ejecute de nuevo la herramienta de recuperación.
3. Si la herramienta de recarga y recuperación no tiene éxito, se recomienda intentar volver a colocar físicamente el módulo en espera en la ventana para intentar borrar la condición. Si la reinstalación física no es exitosa, intente realizar un "sistema de inicialización" desde el modo de inicio del switch siguiendo los pasos de recuperación de contraseña para entrar en este modo durante el arranque. Si sigue sin tener éxito, póngase en contacto con el TAC para intentar la recuperación manual.
Situación D (1 fallo en el activo, 0 fallo en el modo de espera)
Escenario de recuperación:
1 Fallo en el activo
0 Fallos en espera
Pasos para la resolución:
En el escenario de una configuración de supervisor dual, con 1 falla de flash en el activo y sin fallas en el modo de espera, se puede realizar una recuperación sin impacto mediante la herramienta de recuperación de Flash.
1. Como el modo de espera no tiene fallas y el activo solo tiene una falla, la herramienta de recuperación de Flash se puede cargar en el activo y ejecutarse. Después de ejecutar la herramienta, se copiará automáticamente en el modo de espera e intentará sincronizar la matriz. La herramienta de recuperación se puede descargar aquí:
Una vez descargada la herramienta, descomprimida y cargada en la memoria de inicialización del activo, deberá ejecutar el siguiente comando para iniciar la recuperación:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
La herramienta comenzará a funcionar y detectará los discos desconectados e intentará sincronizarlos con la matriz RAID.
Puede comprobar el estado de recuperación con:
# show system internal file /proc/mdstat
Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:
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>
Una vez finalizada la recuperación, debe verse de la siguiente manera:
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>
Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.
2. Si la herramienta de recuperación de Flash no funciona, el siguiente paso sería realizar un "switchover del sistema" para conmutar por error los módulos supervisores en una ventana de mantenimiento.
Por lo tanto, en una ventana programada, realice un "switchover del sistema", se recomienda tener acceso a la consola para observar el proceso de arranque en caso de que surjan problemas inesperados. Espere hasta que el modo de espera se inicie completamente en el estado "ha-standby".
Una vez que el modo de espera esté activo, verifique el RAID con "slot x show system internal raid" y "slot x show system internal file /proc/mdstat".
Si no se realiza una copia de seguridad completa de ambos discos después de la recarga, ejecute de nuevo la herramienta de recuperación.
3. Si la herramienta de recarga y recuperación no tiene éxito, se recomienda intentar volver a colocar físicamente el módulo en espera en la ventana para intentar borrar la condición. Si la reinstalación física no es exitosa, intente realizar un "sistema de inicialización" desde el modo de inicio del switch siguiendo los pasos de recuperación de contraseña para entrar en este modo durante el arranque. Si sigue sin tener éxito, póngase en contacto con el TAC para intentar la recuperación manual.
Escenario E (1 fallo en el activo, 1 fallo en el modo de espera)
Escenario de recuperación:
1 Fallo en el activo
1 Fallo en espera
Pasos para la resolución:
En el caso de que se produzca un único fallo de flash tanto en el modo activo como en el modo en espera, se puede lograr una solución alternativa que no afecte a la capacidad.
1. Como ningún supervisor está en estado de solo lectura, el primer paso es intentar utilizar la herramienta de recuperación de Flash.
La herramienta de recuperación se puede descargar aquí:
Una vez descargada la herramienta, descomprimida y cargada en la memoria de inicialización del activo, deberá ejecutar el siguiente comando para iniciar la recuperación:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
Detectará automáticamente discos desconectados en el activo e intentará repararlos, así como se copiará automáticamente al modo de espera y detectará y corregirá los fallos allí.
Puede comprobar el estado de recuperación con:
# show system internal file /proc/mdstat
Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:
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>
Una vez finalizada la recuperación, debe verse de la siguiente manera:
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>
Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.
Si ambos supervisores recuperan el estado [UU], la recuperación se completa. Si la recuperación es parcial o no se realizó correctamente, vaya al paso 2.
2. En caso de que la herramienta de recuperación no funcionara, identifique el estado actual del RAID en los módulos. Si todavía hay una falla de flash en ambos, intente un "switchover del sistema" que recargará el activo actual y forzará el modo de espera al rol activo.
Después de que el activo anterior se vuelva a cargar en "ha-standby", verifique su estado de RAID, ya que debe recuperarse durante la recarga.
Si el supervisor se recupera correctamente después del switchover, puede intentar ejecutar la herramienta de recuperación de flash de nuevo para intentar reparar el fallo de disco único en el supervisor activo actual, o bien otro "switchover del sistema" para volver a cargar el activo actual y forzar el activo anterior y el en espera actual que se reparó de nuevo en el rol activo. Verifique que el supervisor recargado tenga ambos discos reparados nuevamente, vuelva a ejecutar la herramienta de recuperación si es necesario.
3. Si durante este proceso el switchover no está reparando el RAID, ejecute un "módulo fuera de servicio x" para el modo de espera y luego "no poweroff module x" para retirar completamente y volver a aplicar la energía al módulo.
Si el estado fuera de servicio no es correcto, intente volver a colocar físicamente el modo en espera.
Si después de ejecutar la herramienta de recuperación un supervisor recupera su RAID y el otro aún tiene una falla, fuerce al supervisor con la falla única a estar en espera con un "switchover del sistema" si es necesario. Si el supervisor con una única falla es
ya en espera, realice un "módulo fuera de servicio x" para el módulo en espera y un "módulo sin apagado x" para retirar por completo y volver a aplicar la alimentación al módulo. Si aún no se está recuperando, intente volver a colocar físicamente el módulo. En el caso de que no se corrija la reinstalación,
entre en la indicación de inicio del switch mediante el procedimiento de recuperación de contraseña y haga un "sistema de inicialización" para reiniciar la memoria flash de inicio. Si esto sigue sin tener éxito, solicite a TAC que intente la recuperación manual.
Situación F (2 fallos en el activo, 0 fallos en el espera)
Escenario de recuperación:
2 Fallos en el activo
0 Fallos en espera
Pasos para la resolución:
Con 2 fallas en el supervisor activo y 0 en el supervisor en espera, es posible una recuperación sin impacto, dependiendo de la cantidad de la configuración en ejecución que se ha agregado ya que el standby no pudo sincronizar su configuración en ejecución con el activo.
El procedimiento de recuperación consistirá en copiar la configuración en ejecución actual del supervisor activo, realizar una conmutación por error al supervisor en espera correcto, copiar la configuración en ejecución que falta en el nuevo supervisor activo, poner en línea manualmente el activo anterior y, a continuación, ejecutar la herramienta de recuperación.
2. Una vez que se haya copiado la configuración en ejecución del supervisor activo, será una buena idea compararla con la configuración de inicio para ver qué ha cambiado desde la última vez que se guardó. Esto se puede ver con "show startup-configuration". Por supuesto, las diferencias dependerán completamente del entorno, pero es bueno ser consciente de lo que puede faltar cuando el modo de espera se conecta como activo. También es una buena idea tener las diferencias ya copiadas en un bloc de notas para que se puedan agregar rápidamente al nuevo supervisor activo después del cambio.
3. Una vez evaluadas las diferencias, deberá realizar un switchover de supervisor. TAC recomienda que esto se realice durante una ventana de mantenimiento, ya que pueden ocurrir problemas imprevistos. El comando para realizar el failover al standby será "system switchover".
4. El switchover debe ocurrir muy rápidamente y el nuevo modo de espera comenzará a reiniciarse. Durante este tiempo, deseará volver a agregar cualquier configuración que falte al nuevo activo. Esto se puede hacer copiando la configuración desde el servidor TFTP (o donde se haya guardado anteriormente) o simplemente agregando manualmente la configuración en la CLI. En la mayoría de los casos, las configuraciones que faltan son muy cortas y la opción CLI será la más factible.
5. Después de un tiempo, el nuevo supervisor en espera puede volver a estar en línea en un estado de "espera ha", pero lo que ocurre normalmente es que se bloquea en un estado de "encendido". El estado se puede ver usando el comando "show module" y haciendo referencia a la columna "Status" junto al módulo.
Si el nuevo modo de espera aparece en estado "encendido", tendrá que volver a conectarlo manualmente. Esto se puede hacer ejecutando los siguientes comandos, donde "x" es el módulo en espera atascado en un estado "encendido":
(config)# out-of-service module x
(config)# no poweroff module x
6. Una vez que el modo de espera vuelva a estar en línea en un estado "ha-standby", tendrá que ejecutar la herramienta de recuperación para asegurarse de que la recuperación se ha completado. La herramienta se puede descargar en el siguiente enlace:
Una vez descargada la herramienta, descomprimida y cargada en la memoria de inicialización de la caja, deberá ejecutar el siguiente comando para comenzar la recuperación:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
La herramienta comenzará a funcionar y detectará los discos desconectados e intentará sincronizarlos con la matriz RAID.
Puede comprobar el estado de recuperación con:
# show system internal file /proc/mdstat
Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:
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>
Una vez finalizada la recuperación, debe verse de la siguiente manera:
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>
Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.
Escenario G (0 falla en activo, 2 falla en espera)
0 Falla en el Activo, 2 en el Standby
Escenario de recuperación:
0 Fallos en el activo
2 Fallos en espera
Pasos para la resolución:
Con 0 fallas en el supervisor activo y 2 en el supervisor en espera, es posible una recuperación sin impacto.
El procedimiento de recuperación consistirá en realizar una recarga del modo en espera.
1. Se observa comúnmente en supervisores con una falla de flash dual que un software "reload module x" solo puede reparar parcialmente el RAID o que se atasque encendido al reiniciar.
Por lo tanto, se recomienda volver a colocar físicamente el supervisor con falla de flash dual para remover por completo y volver a aplicar la energía al módulo, o puede realizar lo siguiente (x para la ranura en espera #):
# out-of-service module x
# no poweroff module x
Si observa que el modo en espera se mantiene atascado en el estado encendido y, en última instancia, mantiene el ciclo de alimentación después de los pasos anteriores, es probable que esto se deba a la recarga activa del modo en espera por no estar encendido a tiempo.
Esto puede deberse a que el arranque en espera intenta reiniciar su bootflash/RAID, lo que puede tardar hasta 10 minutos, pero el activo lo reinicia antes de que pueda lograr.
Para resolver esto, configure lo siguiente usando 'x' para el nº de ranura en espera bloqueado en encendido:
(config)# system standby manual-boot
(config)# reload module x force-dnld
Lo anterior hará que el activo no reinicie automáticamente el modo de espera, y luego recargue el modo de espera y fuerce la sincronización de su imagen del modo activo.
Espere de 10 a 15 minutos para ver si el modo de espera finalmente puede alcanzar el estado de espera en espera. Una vez que se encuentre en estado de espera, vuelva a habilitar los reinicios automáticos del modo de espera con:
(config)# system no standby manual-boot
6. Una vez que el modo de espera vuelva a estar en línea en un estado "ha-standby", tendrá que ejecutar la herramienta de recuperación para asegurarse de que la recuperación se ha completado. La herramienta se puede descargar en el siguiente enlace:
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>
Una vez finalizada la recuperación, debe verse de la siguiente manera:
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>
Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.
Escenario H (2 fallos en el activo, 1 en el en espera)
2 Fallos en el Activo, 1 en el Standby
Escenario de recuperación:
2 Fallos en el activo
1 Falla en espera
Pasos para la resolución:
Con 2 fallas en el supervisor activo y 1 en el supervisor en espera, es posible una recuperación sin impacto, dependiendo de la cantidad de la configuración en ejecución que se ha agregado ya que el standby no pudo sincronizar su configuración en ejecución con el activo.
El procedimiento de recuperación consistirá en realizar una copia de seguridad de la configuración en ejecución actual desde el supervisor activo, realizar una conmutación por error al supervisor en espera en buen estado, copiar la configuración en ejecución que falta en la nueva configuración activa, poner en línea manualmente la configuración activa anterior y, a continuación, ejecutar la herramienta de recuperación.
1. Realice una copia de seguridad externa de toda la configuración en ejecución con "copy running-config tftp: vdc-all". Tenga en cuenta que en caso de falla de flash dual, los cambios de configuración desde que el sistema se remontó a solo lectura no están presentes en la configuración de inicio. Puede revisar "show system internal raid" para el módulo afectado para determinar cuándo falló el segundo disco, que es donde el sistema pasa a ser de solo lectura. Desde allí puede revisar "show accounting log" para cada VDC para determinar qué cambios se hicieron desde la falla de flash dual para que sepa qué agregar si la configuración de inicio persiste luego de la recarga.
Tenga en cuenta que es posible que la configuración de inicio se elimine al recargar un supervisor con falla de flash dual, por lo que se debe realizar una copia de seguridad de la configuración externamente.
2. Una vez que se haya copiado la configuración en ejecución del supervisor activo, será una buena idea compararla con la configuración de inicio para ver qué ha cambiado desde la última vez que se guardó. Esto se puede ver con "show startup-configuration". Por supuesto, las diferencias dependerán completamente del entorno, pero es bueno ser consciente de lo que puede faltar cuando el modo de espera se conecta como activo. También es una buena idea tener las diferencias ya copiadas en un bloc de notas para que se puedan agregar rápidamente al nuevo supervisor activo después del cambio.
3. Una vez evaluadas las diferencias, deberá realizar un switchover de supervisor. TAC recomienda que esto se realice durante una ventana de mantenimiento, ya que pueden ocurrir problemas imprevistos. El comando para realizar el failover al standby será "system switchover".
4. El switchover debe ocurrir muy rápidamente y el nuevo modo de espera comenzará a reiniciarse. Durante este tiempo, deseará volver a agregar cualquier configuración que falte al nuevo activo. Esto se puede hacer copiando la configuración desde el servidor TFTP (o donde se guardó anteriormente) o simplemente agregando manualmente la configuración en la CLI, no copie directamente desde tftp a running-configuration, copie primero a bootflash y luego a la configuración en ejecución. En la mayoría de los casos, las configuraciones que faltan son muy cortas y la opción CLI será la más factible.
5. Después de un tiempo, el nuevo supervisor en espera puede volver a estar en línea en un estado de "espera ha", pero lo que ocurre normalmente es que se bloquea en un estado de "encendido". El estado se puede ver usando el comando "show module" y haciendo referencia a la columna "Status" junto al módulo.
Si el nuevo modo de espera aparece en estado "encendido", tendrá que volver a conectarlo manualmente. Esto se puede hacer ejecutando los siguientes comandos, donde "x" es el módulo en espera atascado en un estado "encendido":
(config)# módulo fuera de servicio
(config)# no poweroff module x
Si observa que el modo en espera se mantiene atascado en el estado encendido y, en última instancia, mantiene el ciclo de alimentación después de los pasos anteriores, es probable que esto se deba a la recarga activa del modo en espera por no estar encendido a tiempo.
Esto puede deberse a que el arranque en espera intenta reiniciar su bootflash/RAID, lo que puede tardar hasta 10 minutos, pero el activo lo reinicia antes de que pueda lograr.
Para resolver esto, configure lo siguiente usando 'x' para el nº de ranura en espera bloqueado en encendido:
(config)# system standby manual-boot
(config)# reload module x force-dnld
Lo anterior hará que el activo no reinicie automáticamente el modo de espera, y luego recargue el modo de espera y fuerce la sincronización de su imagen del modo activo.
Espere de 10 a 15 minutos para ver si el modo de espera finalmente puede alcanzar el estado de espera en espera. Una vez que se encuentre en estado de espera, vuelva a habilitar los reinicios automáticos del modo de espera con:
(config)# system no standby manual-boot
6. Una vez que el modo de espera vuelva a estar en línea en un estado "ha-standby", tendrá que ejecutar la herramienta de recuperación para asegurarse de que la recuperación se ha completado y para reparar la falla de disco único en el activo. La herramienta se puede descargar en el siguiente enlace:
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>
Una vez finalizada la recuperación, debe verse de la siguiente manera:
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>
Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.
Si la herramienta de recuperación no recupera el activo actual con una única falla, intente otro "switchover del sistema" asegurándose de que su espera actual esté en estado "ha-standby". Si sigue sin tener éxito, póngase en contacto con Cisco TAC
Escenario I (1 fallo en el activo, 2 fallo en el modo de espera)
Escenario de recuperación:
1 Fallo en el activo
2 Fallos en espera
Pasos para la resolución:
En un escenario de supervisor dual con 1 falla en el supervisor activo y 2 fallas en el supervisor en espera, puede ser posible una recuperación sin impacto, pero en muchos casos puede ser necesaria una recarga.
El proceso consistirá en realizar primero una copia de seguridad de todas las configuraciones en ejecución, luego intentar recuperar la memoria Compact Flash fallida en el activo mediante la herramienta de recuperación y, a continuación, si tiene éxito, volverá a cargar manualmente el modo de espera y ejecutar la herramienta de recuperación de nuevo. Si el intento de recuperación inicial no puede recuperar la memoria flash fallida en el activo, TAC debe participar para intentar una recuperación manual mediante el plugin de depuración.
Una vez descargada la herramienta, descomprimida y cargada en la memoria de inicialización de la caja, deberá ejecutar el siguiente comando para comenzar la recuperación:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
La herramienta comenzará a funcionar y detectará los discos desconectados e intentará sincronizarlos con la matriz RAID.
Puede comprobar el estado de recuperación con:
# show system internal file /proc/mdstat
Compruebe que la recuperación está en curso; puede tardar varios minutos en reparar completamente todos los discos con el estado [UU]. Un ejemplo de recuperación en funcionamiento es el siguiente:
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>
Una vez finalizada la recuperación, debe verse de la siguiente manera:
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>
Después de que todos los discos estén en [UU], la matriz RAID está completamente respaldada con ambos discos sincronizados.
3. Si, después de ejecutar la Herramienta de recuperación en el paso 2, no puede recuperar la memoria Compact Flash fallida en el supervisor activo, debe comunicarse con el TAC para intentar una recuperación manual mediante el plugin de depuración de linux.
4. Después de verificar que ambos destellos se muestren como "[UU]" en el activo, puede continuar con el reinicio manual del supervisor en espera. Esto se puede hacer ejecutando los siguientes comandos, donde "x" es el módulo en espera atascado en un estado "encendido":
(config)# out-of-service module x
(config)# no poweroff module x
Esto debería llevar al supervisor en espera de nuevo a un estado "ha-standby" (esto se verifica al ver la columna Status en la salida "show module"). Si el resultado es correcto, vaya al paso 6; de lo contrario, intente el procedimiento descrito en el paso 5.
5. Si observa que el modo en espera se mantiene atascado en el estado encendido y, en última instancia, mantiene el ciclo de alimentación después de los pasos anteriores, es probable que esto se deba a la recarga activa del modo en espera por no estar encendido a tiempo. Esto puede deberse a que el arranque en espera intenta reiniciar su bootflash/RAID, lo que puede tardar hasta 10 minutos, pero el activo lo reinicia antes de que pueda lograr. Para resolver esto, configure lo siguiente usando 'x' para el nº de ranura en espera bloqueado en encendido:
(config)# system standby manual-boot
(config)# reload module x force-dnld
Lo anterior hará que el activo no reinicie automáticamente el modo de espera, y luego recargue el modo de espera y fuerce la sincronización de su imagen del modo activo.
Espere de 10 a 15 minutos para ver si el modo de espera finalmente puede alcanzar el estado de espera en espera. Una vez que se encuentre en estado de espera, vuelva a habilitar los reinicios automáticos del modo de espera con:
(config)# system no standby manual-boot
6. Una vez que el modo de espera vuelva a estar en línea en un estado "ha-standby", tendrá que ejecutar la herramienta de recuperación para asegurarse de que la recuperación se ha completado. Puede ejecutar la misma herramienta que tiene en el activo para este paso, no se necesita ninguna descarga adicional ya que la herramienta de recuperación se ejecuta en el activo y en espera.
Situación J (2 Fallos en el Activo, 2 Fallos en el Standby)
Escenario de recuperación:
2 Fallos en el activo
2 Fallos en espera
Pasos para la resolución:
Summary
Preguntas más Frecuentes
¿Existe una solución permanente para este problema?
Consulte la sección Soluciones a largo plazo más abajo.
¿Por qué no es posible recuperar un failover dual en el activo y en espera recargando el supervisor en espera y fallando?
La razón por la que esto no es posible es porque para permitir que el supervisor en espera aparezca en un estado "ha-standby", el supervisor activo debe escribir varias cosas en su compact flash (información SNMP, etc.), lo que no puede hacer si tiene una falla de flash dual en sí.
¿Qué sucede si la herramienta de recuperación de Flash no puede volver a montar la memoria flash compacta?
Póngase en contacto con el TAC de Cisco para conocer las opciones de esta situación.
¿Este error también afecta al Nexus 7700 con motor supervisor 2E?
Hay un defecto separado para N7700 Sup2E - CSCuv64056 . La herramienta de recuperación no funcionará para N7700.
¿Funciona la herramienta de recuperación para imágenes NPE?
La herramienta de recuperación no funciona para las imágenes NPE.
¿Resolverá este problema un ISSU a una versión de código resuelta?
No. Un ISSU utilizará un switchover de supervisor, que puede no funcionar correctamente debido a la falla de la memoria Compact Flash.
Reiniciamos la placa afectada. ¿El estado de Raid imprime 0xF0, pero las pruebas GOLD siguen fallando?
Los bits de estado de RAID se restablecen después del restablecimiento de la placa después de aplicar la recuperación automática.
Sin embargo, no todas las condiciones de falla se pueden recuperar automáticamente.
Si los bits de estado RAID no se imprimen como [2/2] [UU], la recuperación está incompleta.
Siga los pasos de recuperación enumerados
¿Afectará la falla de la memoria flash a la operación?
No, pero es posible que el sistema no se inicie en caso de fallo de alimentación. Las configuraciones de inicio también se perderán.
¿Qué se recomienda para un sistema de funcionamiento saludable desde la perspectiva del cliente en términos de supervisión y recuperación?
Verifique el estado de la prueba compacta GOLD para detectar cualquier falla e intente la recuperación tan pronto como falle la primera parte flash.
¿Puedo corregir una falla de flash eusb fallida al hacer un ISSU desde el código afectado a la versión corregida?
ISSU no corregirá eUSB fallido. La mejor opción es ejecutar la herramienta de recuperación para un solo fallo de eusb en el sup o volver a cargar el sup en caso de fallo de eusb dual.
Una vez corregido el problema, realice la actualización. La corrección para CSCus2805 ayuda a corregir SOLO la falla de eusb individual y lo hace escaneando el sistema a intervalos regulares e intenta reactivar eUSB inaccesible o de solo lectura usando el script.
Es raro ver que ambos fallos de flash eusb en el supervisor se producen simultáneamente, por lo que esta solución alternativa será eficaz.
¿Cuánto tiempo tarda el problema en reaparecer si corrige las fallas de flash usando el plugin o recarga?
Por lo general, se ve por un tiempo de actividad más largo. Esto no se cuantifica exactamente y puede oscilar entre un año o más. La conclusión es que cuanto mayor sea la tensión en la flash eusb en términos de lectura y escritura, mayor será la probabilidad de que el sistema se encuentre con este escenario.
Show system internal raid muestra el estado de flash dos veces en diferentes secciones. Además, estas secciones no son coherentes
La primera sección muestra el estado actual y la segunda sección muestra el estado de inicio.
El estado actual es lo que importa y siempre debe aparecer como UU.
Soluciones a largo plazo
Este defecto tiene una solución alternativa en 6.2(14), pero la corrección del firmware se añadió a 6.2(16) y 7.2(x) y posteriores.
Se recomienda actualizar a una versión con la corrección del firmware para resolver completamente este problema.
Si no puede actualizar a una versión fija de NXOS, existen dos soluciones posibles.
La solución 1 es ejecutar la herramienta de recuperación de flash de forma proactiva cada semana mediante el planificador. La siguiente configuración del planificador con la herramienta de recuperación de flash en la memoria de inicialización:
programador de características
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
salir
scheduler schedule name Flash_Recovery
job name Flash_Job
tiempo semanal 7
Notas:
- La recuperación de flash debe tener el mismo nombre y estar en la memoria de inicialización.
- El 7 en la configuración "time weekly 7" representa un día de la semana, el sábado en este caso.
- La frecuencia máxima que recomienda Cisco para ejecutar la herramienta de recuperación de flash es una vez a la semana.
La solución 2 se documenta en el siguiente enlace de nota técnica
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)