Reprise de panne de Compact Flash du superviseur 2/2E de Nexus 7000
Contenu
Introduction
Ce document décrit la question de panne de compact flash du superviseur 2/2E de Nexus 7000 documentée dans l'erreur de logiciel CSCus22805, tous les scénarios de panne possibles, et les étapes de reprise.
Fond
Chaque superviseur 2/2E N7K est équipé de 2 périphériques flash d'eUSB dans la configuration RAID1, un primaire et un miroir. Ensemble ils fournissent les référentiel non-volatiles pour des images de démarrage, la configuration de démarrage et des données des applications persistantes.
Ce qui peut se produire a lieu pendant des mois ou des années en service, un de ces périphériques peut être déconnecté du bus USB, faisant relâcher le logiciel RAID le périphérique de la configuration. Le périphérique peut encore fonctionner normalement avec des périphériques de 1/2. Cependant, quand le deuxième périphérique chute hors de la baie, le bootflash est remonté sur comme en lecture seule, la signification de vous ne peut pas save configuration ou fichiers au bootflash, ou le permettre au standby au sync à l'active en cas est rechargé.
Il n'y a aucune incidence opérationnelle sur des systèmes s'exécutant dans un double état de défaillance de mémoire Flash, cependant une recharge du superviseur affecté est nécessaire pour récupérer de cet état. En outre, aucun changement à la configuration en cours ne sera reflété de startup et serait perdu en cas d'une panne de courant.
Symptômes
Ces symptômes ont été vus :
- Panne de diagnostic 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--------------------------> .
- Incapable d'exécuter « un début de passage de copie »
dcd02.ptfrnyfs# copy running-config startup-config
[########################################] 100%
Configuration update aborted: request was aborted
- l'eUSB devient en lecture seule ou est nonsensible
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
- Pannes ISSU, habituellement en essayant au Basculement au superviseur de réserve
Diagnostic
Pour diagnostiquer l'état actuel des cartes compactflashs que vous devez utiliser ces commandes internes. Notez que la commande n'analysera pas, et elle doit être tapée complètement :
incursion interne de show system de switch# | grep - Un 1" les informations d'état en cours RAID »
fichier interne /proc/mdstat de show system de switch#
S'il y a deux superviseurs dans le châssis, vous devrez vérifier l'état du superviseur de réserve aussi bien pour déterminer à quel scénario de panne vous faites face. Vérifiez ceci en ajoutant la commande au début avec le mot clé du « emplacement X » où « x » est le nombre d'emplacement du superviseur de réserve. Ceci te permet pour exécuter la commande à distance en état d'alerte.
incursion interne de système de 2show d'emplacement de switch# | grep - Un 1" les informations d'état en cours RAID »
fichier interne /proc/mdstat de système de 2show d'emplacement de switch#
Ces commandes donneront beaucoup de statistiques et événements RAID, mais vous êtes seulement concerné par les informations RAID de courant.
Dans la ligne « données RAID de CMOS », vous voulez regarder la valeur hexadécimale après 0xa5. Ceci affichera combien de flashes peuvent actuellement faire face à une question.
Exemple :
switch# show system internal raid | grep -A 1 "Current RAID status info"
Current RAID status info:
RAID data from CMOS = 0xa5 0xc3
De cette sortie vous voulez regarder le nombre à coté de 0xa5 qui est 0xc3. Vous pouvez alors employer ces clés pour déterminer si le compact flash primaire ou secondaire a manqué, ou chacun des deux. La sortie ci-dessus affiche à 0xc3 ce qui nous indique que les compacts flashs primaires et secondaires ont manqué.
| 0xf0 | Aucune pannes signalées |
| 0xe1 | L'éclair primaire a manqué |
| 0xd2 | Alternez (ou miroir) l'éclair a manqué |
| 0xc3 | Primaire et alternatif manqué |
Dans la sortie « /proc/mdstat » assurez-vous que tous les disques affichent en tant que « U », qui représente « 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]
Dans ce scénario vous voyez que le compact flash primaire n'est pas en hausse [_U]. Un résultat sain affichera tous les blocs en tant que [UU].
Scénarios
Pour déterminer à quel scénario vous faites face, vous devrez utiliser les commandes ci-dessus dans la section de « diagnostic » de corréler avec une lettre de scénario ci-dessous. Utilisant les colonnes, correspondance vers le haut du nombre de compacts flashs défectueux sur chaque superviseur.
Par exemple, si vous voyiez que le code est 0xe1 sur le superviseur et le 0xd2 actifs en état d'alerte, ce serait « 1 échouer » sur l'Active et « 1 échouer » en état d'alerte qui est la lettre « D » de scénario.
Superviseur simple :
| Lettre de scénario | Superviseur actif | Code de supervision actif |
| A | 1 échouer | 0xe1 ou 0xd2 |
| B | 2 échoue | 0xc3 |
Doubles superviseurs :
| Lettre de scénario | Superviseur actif | Superviseur de réserve | Code de supervision actif | Code de supervision de réserve |
| C | 0 échouer | 1 échouer | 0xf0 | 0xe1 ou 0xd2 |
| D | 1 échouer | 0 échouer | 0xe1 ou 0xd2 | 0xf0 |
| E | 1 échouer | 1 échouer | 0xe1 ou 0xd2 | 0xe1 ou 0xd2 |
| F | 2 échoue | 0 échouer | 0xc3 | 0xf0 |
| G | 0 échouer | 2 échoue | 0xf0 | 0xc3 |
| H | 2 échoue | 1 échouer | 0xc3 | 0xe1 ou 0xd2 |
| I | 1 échouer | Échouer 2 | 0xe1 ou 0xd2 | 0xc3 |
| J | 2 échoue | 2 échoue | 0xc3 | 0xc3 |
Procédure de récupération pour chaque scénario
Scénarios de panne simples de superviseur
Scénario A (1 échouer sur l'Active)
Scénario de reprise :
1 échouer sur l'Active
Étapes à la résolution :
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>
Scénario B (2 échoue sur l'Active)
Scénario de reprise :
2 échoue sur l'Active
Étapes à la résolution :
Doubles scénarios de panne de superviseur
C de scénario (0 échoue sur l'Active, 1 échouer en état d'alerte)
Scénario de panne :
0 échoue sur l'Active
1 échouer en état d'alerte
Étapes à la résolution :
Dans le scénario d'une double installation de superviseur, sans des défaillances de mémoire Flash sur de la panne active et simple en état d'alerte, une reprise l'affectant non peut être exécutée.
1. Car l'active n'a aucune panne et le standby a seulement une panne simple, l'outil instantané de reprise peut être chargé sur l'active et être exécuté. Après avoir exécuté l'outil, il se copiera automatiquement sur le standby et la tentative sur la resync la baie. L'outil de reprise peut être téléchargé ici :
Une fois que vous avez téléchargé l'outil, avez défait la fermeture éclair lui, et lui avez téléchargé au bootflash de la case, vous devrez exécuter la commande suivante de commencer la reprise :
# chargement bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
L'outil commencera l'exécution et détectera les disques déconnectés et la tentative à la resync ils avec le volume RAID.
Vous pouvez vérifier l'état de reprise avec :
# fichier interne /proc/mdstat de show system
Vérifiez que reprise se poursuit, elle peut prendre plusieurs minutes pour réparer entièrement tous les disques à l'état a [UU]. Un exemple des aspects en fonction d'une reprise comme suit :
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>
Après que la reprise soit de finition elle devrait regarder comme suit :
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>
Après tout les disques sont dedans [UU], le volume RAID est sauvegardent entièrement avec le synchronization'd de les deux disques.
2. Si l'outil instantané de reprise est infructueux, puisque l'active a les deux disques, le standby devrait être avec succès sync capable à l'active sur la recharge.
Par conséquent, dans une fenêtre programmée, exécutez « un module hors service X » pour le superviseur de réserve, il est recommandé d'avoir accès de console au standby pour observer le processus de démarrage dans le cas toutes les questions inattendues pour surgir. Après que le superviseur soit vers le bas, attendez quelques secondes et puis n'exécutez « aucun poweroff module X » pour le standby. Attendez jusqu'à ce que le standby démarre entièrement dans l'état de « ha-standby ».
Après que le standby soit sauvegardez, vérifiez le RAID avec « l'incursion interne de show system de l'emplacement X » et « rainez le fichier interne /proc/mdstat de show system x ».
Si les deux disques ne sont pas entièrement de sauvegarder après recharge, exécutez l'outil de reprise de nouveau.
3. Si la recharge et l'outil de reprise ne sont pas réussis, il serait recommandé de tenter réinsérer physiquement le module de réserve dans la fenêtre pour essayer et effacer la condition. Si l'examen médical réinsèrent n'est pas réussi, essayent exécuter un « système d'init » de mode de démarrage de commutateur en suivant les étapes de reprise de mot de passe pour diviser en ce mode pendant le démarrage. Si encore infructueux, entrez en contact avec le TAC pour tenter la reprise manuelle.
Scénario D (1 échouer sur l'Active, 0 échoue en état d'alerte)
Scénario de reprise :
1 échouer sur l'Active
0 échoue en état d'alerte
Étapes à la résolution :
Dans le scénario d'une double installation de superviseur, avec 1 défaillance de mémoire Flash sur l'active et aucune pannes en état d'alerte, une reprise l'affectant non peut être exécutée à l'aide de l'outil instantané de reprise.
1. Car le standby n'a aucune panne et l'active a seulement une panne simple, l'outil instantané de reprise peut être chargé sur l'active et être exécuté. Après avoir exécuté l'outil, il se copiera automatiquement sur le standby et la tentative sur la resync la baie. L'outil de reprise peut être téléchargé ici :
Une fois que vous avez téléchargé l'outil, avez défait la fermeture éclair lui, et lui avez téléchargé au bootflash de l'active, vous devrez exécuter la commande suivante de commencer la reprise :
# chargement bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
L'outil commencera l'exécution et détectera les disques déconnectés et la tentative à la resync ils avec le volume RAID.
Vous pouvez vérifier l'état de reprise avec :
# fichier interne /proc/mdstat de show system
Vérifiez que reprise se poursuit, elle peut prendre plusieurs minutes pour réparer entièrement tous les disques à l'état a [UU]. Un exemple des aspects en fonction d'une reprise comme suit :
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>
Après que la reprise soit de finition elle devrait regarder comme suit :
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>
Après tout les disques sont dedans [UU], le volume RAID est sauvegardent entièrement avec le synchronization'd de les deux disques.
2. Si l'outil instantané de reprise est infructueux, l'étape suivante serait d'exécuter un « system switchover » au Basculement les modules de superviseur dans une fenêtre de maintenance.
Par conséquent, dans une fenêtre programmée, exécutez un « system switchover », il est recommandé d'avoir accès de console pour observer le processus de démarrage dans le cas toutes les questions inattendues pour surgir. Attendez jusqu'à ce que le standby démarre entièrement dans l'état de « ha-standby ».
Après que le standby soit sauvegardez, vérifiez le RAID avec « l'incursion interne de show system de l'emplacement X » et « rainez le fichier interne /proc/mdstat de show system x ».
Si les deux disques ne sont pas entièrement de sauvegarder après recharge, exécutez l'outil de reprise de nouveau.
3. Si la recharge et l'outil de reprise ne sont pas réussis, il serait recommandé de tenter réinsérer physiquement le module de réserve dans la fenêtre pour essayer et effacer la condition. Si l'examen médical réinsèrent n'est pas réussi, essayent exécuter un « système d'init » de mode de démarrage de commutateur en suivant les étapes de reprise de mot de passe pour diviser en ce mode pendant le démarrage. Si encore infructueux, entrez en contact avec le TAC pour tenter la reprise manuelle.
Scénario E (1 échouer sur l'Active, 1 échouer en état d'alerte)
Scénario de reprise :
1 échouer sur l'Active
1 échouer en état d'alerte
Étapes à la résolution :
En cas d'une défaillance de mémoire Flash simple sur l'actif et de réserve, un contournement l'affectant non peut encore faire.
1. Car aucun superviseur n'est dans un état en lecture seule, la première étape est de tenter utilisant l'outil instantané de reprise.
L'outil de reprise peut être téléchargé ici :
Une fois que vous avez téléchargé l'outil, avez défait la fermeture éclair lui, et lui avez téléchargé au bootflash de l'active, vous devrez exécuter la commande suivante de commencer la reprise :
# chargement bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
Il détectera automatiquement les disques déconnectés sur la réparation d'active et de tentative, aussi bien que se copie automatiquement sur le standby et détecte et corrige des pannes là.
Vous pouvez vérifier l'état de reprise avec :
# fichier interne /proc/mdstat de show system
Vérifiez que reprise se poursuit, elle peut prendre plusieurs minutes pour réparer entièrement tous les disques à l'état a [UU]. Un exemple des aspects en fonction d'une reprise comme suit :
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>
Après que la reprise soit de finition elle devrait regarder comme suit :
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>
Après tout les disques sont dedans [UU], le volume RAID est sauvegardent entièrement avec le synchronization'd de les deux disques.
Si les deux superviseurs récupèrent dans l'état [UU], alors la reprise est complète. Si la reprise est partielle ou ne réussissait pas passez à l'étape 2.
2. Au cas où l'outil de reprise ne réussissait pas, identifiez l'état actuel du RAID sur les modules. S'il y a toujours une défaillance de mémoire Flash simple sur chacun des deux, tentez un « system switchover » qui rechargera l'actif en cours et force le standby au rôle actif.
Après que l'active précédent soit rechargé de nouveau dans le « ha-standby », vérifiez son état RAID comme il devrait être récupéré pendant la recharge.
Si le superviseur récupère avec succès après le basculement, vous pouvez essayer exécuter l'outil instantané de reprise de nouveau pour essayer et réparer le manque de disque simple sur le superviseur actif en cours, ou un « system switchover » différent de recharger l'actif en cours et de forcer le standby actif et en cours précédent qui a été réparé de nouveau au rôle actif. Vérifiez le superviseur rechargé fait réparer les deux disques de nouveau, réexécute l'outil de reprise s'il y a lieu.
3. Si pendant ce processus le basculement ne répare pas le RAID, exécutez « un module hors service X » pour le standby et alors « aucun poweroff module X » entièrement pour couper et réappliquer l'alimentation au module.
Si hors service n'est pas réussi, tentent un examen médical réinsèrent du standby.
Si après s'être exécuté le superviseur de l'outil un de reprise récupère son RAID et l'autre a toujours une panne, forcez le superviseur avec la panne simple au standby avec un « system switchover » s'il y a lieu. Si le superviseur avec une panne simple est
déjà de réserve, faites « un module hors service X » pour le standby et « aucun poweroff module X » entièrement pour couper et réappliquer l'alimentation au module. S'il ne récupère toujours pas, tentez un examen médical réinsèrent du module. En cas un réinsérer ne répare pas,
la rupture dans la demande de démarrage de commutateur suivant la procédure de récupération de mot de passe et font un « système d'init » pour réinitialiser le bootflash. Si c'est encore infructueux, ayez la reprise de manuel de tentative TAC.
Scénario F (2 échoue sur l'Active, 0 échoue en état d'alerte)
Scénario de reprise :
2 échoue sur l'Active
0 échoue en état d'alerte
Étapes à la résolution :
Avec 2 pannes sur l'active et 0 sur le superviseur de réserve, une reprise non-l'affectant est possible, selon quelle quantité de configuration courante a été ajoutée depuis que le standby ne pouvait pas au sync son running-config avec l'active.
La procédure de récupération sera de copier la configuration en cours d'exécution du superviseur actif, Basculement sur le superviseur de réserve en bonne santé, copient la configuration en cours manquante sur le nouvel active, mettent manuellement en ligne actif précédent, exécutent alors l'outil de reprise.
2. Une fois que la configuration courante a été copiée hors fonction du superviseur actif, ce sera une bonne idée de la comparer à la configuration de démarrage pour voir ce qui a changé puisque la dernière sauvegarde. Ceci peut être vu avec le « startup-configuration d'exposition ». Les différences naturellement dépendront complètement de l'environnement, mais il est bon de se rendre compte de ce qui peut manquer quand le standby est livré en ligne comme active. C'est également une bonne idée pour avoir les différences déjà copiées dans un Notepad de sorte qu'elles puissent être rapidement ajoutées au nouveau superviseur actif après le basculement.
3. Après que les différences aient été évaluées, vous devrez exécuter un basculement de superviseur. Le TAC recommande que ceci soit fait pendant une fenêtre de maintenance, comme unforseen des questions peut se produire. La commande d'exécuter le Basculement au standby sera « system switchover ».
4. Le basculement devrait se produire très rapidement et le nouveau standby commencera la réinitialisation. Pendant ce temps vous voudrez ajouter n'importe quelle configuration manquante de nouveau au nouvel active. Ceci peut être fait en copiant la configuration du serveur TFTP (ou partout où elle a été enregistrée précédemment) ou en ajoutant simplement manuellement la configuration dans le CLI. Dans la plupart des exemples les configurations manquantes sont très courtes et l'option CLI sera la plus faisable.
5. Après une certaine heure le nouveau superviseur de réserve peut revenir en ligne dans un état de « ha-standby », mais ce qui se produit normalement est qu'il est bloqué dans un état « actionné- ». L'état peut être visualisé utilisant la commande de « show module » et se rapporter à la colonne de « état » à côté du module.
Si le nouveau standby est soulevé dans un état « actionné- », vous devrez le rapporter manuellement en ligne. Ceci peut être fait en émettant les commandes suivantes, où « x » est le module de réserve coincé dans un état « actionné- » :
(config) # module hors service X
(config) # aucun poweroff module X
6. Une fois que le standby est de retour en ligne dans un état de « ha-standby », vous devrez alors exécuter l'outil de reprise pour s'assurer que la reprise est complète. L'outil peut être téléchargé au lien suivant :
Une fois que vous avez téléchargé l'outil, avez défait la fermeture éclair lui, et lui avez téléchargé au bootflash de la case, vous devrez exécuter la commande suivante de commencer la reprise :
# chargement bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
L'outil commencera l'exécution et détectera les disques déconnectés et la tentative à la resync ils avec le volume RAID.
Vous pouvez vérifier l'état de reprise avec :
# fichier interne /proc/mdstat de show system
Vérifiez que reprise se poursuit, elle peut prendre plusieurs minutes pour réparer entièrement tous les disques à l'état a [UU]. Un exemple des aspects en fonction d'une reprise comme suit :
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>
Après que la reprise soit de finition elle devrait regarder comme suit :
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>
Après tout les disques sont dedans [UU], le volume RAID est sauvegardent entièrement avec le synchronization'd de les deux disques.
Scénario G (0 échoue sur l'Active, 2 échoue en état d'alerte)
0 échoue sur l'Active, 2 en état d'alerte
Scénario de reprise :
0 échoue sur l'Active
2 échoue en état d'alerte
Étapes à la résolution :
Avec 0 les pannes sur l'active et 2 sur le superviseur de réserve, une reprise non-l'affectant est possible.
La procédure de récupération sera d'exécuter une recharge du standby.
1. Il est généralement - vu dans les superviseurs avec une double défaillance de mémoire Flash qu'un logiciel le « reload module X » peut seulement partiellement réparer le RAID ou le faire être bloqué actionné- sur la réinitialisation.
Par conséquent, il est recommandé à ou réinsèrent physiquement le superviseur avec la double défaillance de mémoire Flash entièrement de couper et réappliquer l'alimentation au module, ou vous pouvez exécuter le suivant (x pour l'emplacement de réserve #) :
# module hors service X
# aucun poweroff module X
Si vous voyez que le standby maintient être bloqué dans l'état actionné- et garde finalement le cycle d'alimentation après les étapes ci-dessus, c'est vraisemblablement dû à l'active rechargeant le standby pour ne pas monter à temps.
Ceci peut être dû au standby initialisant tentant de réinitialiser son bootflash/RAID, qui peut prendre à 10 minutes, mais il continue à être remise à l'état initial par l'active avant qu'il puisse accomplir.
Pour résoudre ceci, configurez le suivant utilisant « x » pour l'emplacement de réserve # collé dans actionné- :
(config) # démarrage manuel de standby de système
(config) # force-dnld du reload module X
Ce qui précède le fera ainsi l'active ne remet pas à l'état initial automatiquement le standby, et puis recharge le standby et le force au sync son image de l'active.
Attendez 10-15 minutes pour voir si le standby peut finalement obtenir à l'état de ha-standby. Après qu'il soit dans l'état de ha-standby, réactivez les réinitialisations automatiques du standby avec :
(config) # système aucun démarrage manuel de réserve
6. Une fois que le standby est de retour en ligne dans un état de « ha-standby », vous devrez alors exécuter l'outil de reprise pour s'assurer que la reprise est complète. L'outil peut être téléchargé au lien suivant :
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>
Après que la reprise soit de finition elle devrait regarder comme suit :
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>
Après tout les disques sont dedans [UU], le volume RAID est sauvegardent entièrement avec le synchronization'd de les deux disques.
Scénario H (2 échoue sur l'Active, 1 en état d'alerte)
2 échoue sur l'Active, 1 en état d'alerte
Scénario de reprise :
2 échoue sur l'Active
1 échoue en état d'alerte
Étapes à la résolution :
Avec 2 pannes sur l'active et 1 sur le superviseur de réserve, une reprise non-l'affectant est possible, selon quelle quantité de configuration courante a été ajoutée depuis que le standby ne pouvait pas au sync son running-config avec l'active.
La procédure de récupération sera sauvegarde la configuration en cours d'exécution du superviseur actif, Basculement au superviseur de réserve en bonne santé, copient la configuration en cours manquante sur le nouvel active, mettent manuellement en ligne actif précédent, exécutent alors l'outil de reprise.
1. Sauvegarde toute la configuration en cours extérieurement avec le « tftp de copy running-config : volts continu-tout ». Veuillez noter que dans l'occurrence de la double défaillance de mémoire Flash, des modifications de configuration puisque le système remonté sur à en lecture seule ne sont pas présent sur la configuration de démarrage. Vous pouvez passer en revue « l'incursion interne de show system » pour que le module affecté détermine quand le deuxième disque a manqué qui est où le système disparaît en lecture seule. Là de vous peut passer en revue le « show accounting log » pour que chaque volts continu détermine quelles modifications ont été apportées puisque la double défaillance de mémoire Flash ainsi vous saura quoi ajouter si la configuration de démarrage persiste sur la recharge.
Veuillez noter qu'il est possible que la configuration de startup est nettoyée sur la recharge d'un superviseur avec la double défaillance de mémoire Flash, qui est pourquoi la configuration doit être sauvegardée extérieurement.
2. Une fois que la configuration courante a été copiée hors fonction du superviseur actif, ce sera une bonne idée de la comparer à la configuration de démarrage pour voir ce qui a changé puisque la dernière sauvegarde. Ceci peut être vu avec le « startup-configuration d'exposition ». Les différences naturellement dépendront complètement de l'environnement, mais il est bon de se rendre compte de ce qui peut manquer quand le standby est livré en ligne comme active. C'est également une bonne idée pour avoir les différences déjà copiées dans un Notepad de sorte qu'elles puissent être rapidement ajoutées au nouveau superviseur actif après le basculement.
3. Après que les différences aient été évaluées, vous devrez exécuter un basculement de superviseur. Le TAC recommande que ceci soit fait pendant une fenêtre de maintenance, comme unforseen des questions peut se produire. La commande d'exécuter le Basculement au standby sera « system switchover ».
4. Le basculement devrait se produire très rapidement et le nouveau standby commencera la réinitialisation. Pendant ce temps vous voudrez ajouter n'importe quelle configuration manquante de nouveau au nouvel active. Ceci peut être fait en copiant la configuration du serveur TFTP (ou partout où elle a été enregistrée précédemment) ou en ajoutant simplement manuellement la configuration dans le CLI, ne copient pas directement d'abord, et puis du tftp sur la configuration courante, copie sur le bootflash sur la configuration en cours. Dans la plupart des exemples les configurations manquantes sont très courtes et l'option CLI sera la plus faisable.
5. Après une certaine heure le nouveau superviseur de réserve peut revenir en ligne dans un état de « ha-standby », mais ce qui se produit normalement est qu'il est bloqué dans un état « actionné- ». L'état peut être visualisé utilisant la commande de « show module » et se rapporter à la colonne de « état » à côté du module.
Si le nouveau standby est soulevé dans un état « actionné- », vous devrez le rapporter manuellement en ligne. Ceci peut être fait en émettant les commandes suivantes, où « x » est le module de réserve coincé dans un état « actionné- » :
(config) # module hors service
(config) # aucun poweroff module X
Si vous voyez que le standby maintient être bloqué dans l'état actionné- et garde finalement le cycle d'alimentation après les étapes ci-dessus, c'est vraisemblablement dû à l'active rechargeant le standby pour ne pas monter à temps.
Ceci peut être dû au standby initialisant tentant de réinitialiser son bootflash/RAID, qui peut prendre à 10 minutes, mais il continue à être remise à l'état initial par l'active avant qu'il puisse accomplir.
Pour résoudre ceci, configurez le suivant utilisant « x » pour l'emplacement de réserve # collé dans actionné- :
(config) # démarrage manuel de standby de système
(config) # force-dnld du reload module X
Ce qui précède le fera ainsi l'active ne remet pas à l'état initial automatiquement le standby, et puis recharge le standby et le force au sync son image de l'active.
Attendez 10-15 minutes pour voir si le standby peut finalement obtenir à l'état de ha-standby. Après qu'il soit dans l'état de ha-standby, réactivez les réinitialisations automatiques du standby avec :
(config) # système aucun démarrage manuel de réserve
6. Une fois que le standby est de retour en ligne dans un état de « ha-standby », vous devrez alors exécuter l'outil de reprise pour s'assurer que la reprise est complète et pour réparer la panne de disque simple sur l'active. L'outil peut être téléchargé au lien suivant :
Après que la reprise soit de finition elle devrait regarder comme suit :
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>
Après tout les disques sont dedans [UU], le volume RAID est sauvegardent entièrement avec le synchronization'd de les deux disques.
Si l'active de courant avec une panne simple n'est pas récupéré par l'outil de reprise, tentez un autre « system switchover » assurant votre standby en cours est dans état de « ha-standby ». Si non réussi contactez toujours s'il vous plaît Cisco TAC
Scénario I (1 échouer sur l'Active, 2 échoue en état d'alerte)
Scénario de reprise :
1 échouer sur l'Active
2 échoue en état d'alerte
Étapes à la résolution :
Dans un double scénario de superviseur avec 1 panne sur l'active et 2 pannes sur le superviseur de réserve une reprise non-l'affectant peut être possible, mais dans de nombreux cas une recharge peut être nécessaire.
Le processus sera à d'abord sauvegardent tous les configuratoins courants, puis les tentent de récupérer le compact flash défectueux sur l'usingt actif il outil de reprise, puis, si réussi, vous rechargerez manuellement le standby et exécuterez l'outil de reprise de nouveau. Si la tentative initiale de reprise ne peut pas récupérer l'éclair défectueux sur l'active, le TAC doit être engagé pour tenter une reprise manuelle utilisant le module d'extension de débogage.
Une fois que vous avez téléchargé l'outil, avez défait la fermeture éclair lui, et lui avez téléchargé au bootflash de la case, vous devrez exécuter la commande suivante de commencer la reprise :
# chargement bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
L'outil commencera l'exécution et détectera les disques déconnectés et la tentative à la resync ils avec le volume RAID.
Vous pouvez vérifier l'état de reprise avec :
# fichier interne /proc/mdstat de show system
Vérifiez que reprise se poursuit, elle peut prendre plusieurs minutes pour réparer entièrement tous les disques à l'état a [UU]. Un exemple des aspects en fonction d'une reprise comme suit :
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>
Après que la reprise soit de finition elle devrait regarder comme suit :
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>
Après tout les disques sont dedans [UU], le volume RAID est sauvegardent entièrement avec le synchronization'd de les deux disques.
3. Si, après avoir exécuté l'outil de reprise dans l'étape 2, vous ne pouvez pas récupérer le compact flash défectueux sur le superviseur actif, vous devez entrer en contact avec le TAC pour tenter une reprise manuelle utilisant le Linux mettez au point le module d'extension.
4. Après avoir vérifié que les deux flashes affichent en tant que « [UU] » sur l'active, vous pouvez continuer de redémarrer manuellement le superviseur de réserve. Ceci peut être fait en émettant les commandes suivantes, où « x » est le module de réserve coincé dans un état « actionné- » :
(config) # module hors service X
(config) # aucun poweroff module X
Ceci devrait amener le superviseur de réserve de nouveau dans un état de « ha-standby » (ceci est vérifié en visualisant la colonne d'état dans le « show module » sorti). Si c'est réussi passez à l'étape 6, sinon, essayez la procédure tracée les grandes lignes dans l'étape 5.
5. Si vous voyez que le standby maintient être bloqué dans l'état actionné- et garde finalement le cycle d'alimentation après les étapes ci-dessus, c'est vraisemblablement dû à l'active rechargeant le standby pour ne pas monter à temps. Ceci peut être dû au standby initialisant tentant de réinitialiser son bootflash/RAID, qui peut prendre à 10 minutes, mais il continue à être remise à l'état initial par l'active avant qu'il puisse accomplir. Pour résoudre ceci, configurez le suivant utilisant « x » pour l'emplacement de réserve # collé dans actionné- :
(config) # démarrage manuel de standby de système
(config) # force-dnld du reload module X
Ce qui précède le fera ainsi l'active ne remet pas à l'état initial automatiquement le standby, et puis recharge le standby et le force au sync son image de l'active.
Attendez 10-15 minutes pour voir si le standby peut finalement obtenir à l'état de ha-standby. Après qu'il soit dans l'état de ha-standby, réactivez les réinitialisations automatiques du standby avec :
(config) # système aucun démarrage manuel de réserve
6. Une fois que le standby est de retour en ligne dans un état de « ha-standby », vous devrez alors exécuter l'outil de reprise pour s'assurer que la reprise est complète. Vous pouvez exécuter le même outil que vous avez sur l'active pour cette étape, aucun téléchargement supplémentaire est nécessaire comme passages d'outil de reprise en l'active et l'état d'alerte.
Scénario J (2 échoue sur l'Active, 2 échoue en état d'alerte)
Scénario de reprise :
2 échoue sur l'Active
2 échoue en état d'alerte
Étapes à la résolution :
Résumé
Foires aux questions
Y a-t-il une solution permanente à cette question ?
Voyez la section à long terme de solutions ci-dessous.
Pourquoi n'est-il pas possible de récupérer un double Basculement sur l'active et le standby en rechargeant le superviseur de réserve et en basculant ?
La raison que ce n'est pas possible est parce qu'afin de permettre au superviseur de réserve pour monter dans un état de « ha-standby », le superviseur actif doit écrire plusieurs choses à son compact flash (les informations SNMP, etc.), qu'il ne peut pas faire s'il a une double défaillance de mémoire Flash lui-même.
Que se produit si l'outil instantané de reprise ne peut pas remonter sur le compact flash ?
Contactez Cisco TAC pour des options dans ce scénario.
Cette bogue affecte-t-elle également le Nexus 7700 Sup2E ?
Il y a un défaut distinct pour le N7700 Sup2E - CSCuv64056. L'outil de reprise ne fonctionnera pas pour le N7700.
L'outil de reprise fonctionne-t-il pour des images NPE ?
L'outil de reprise ne fonctionne pas pour des images NPE.
Est-ce qu'ISSU à une version résolue de code résoudra ce problème ?
Non. Un ISSU utilisera un basculement de superviseur, qui peut ne pas exécuter correctement en raison de la panne de compact flash.
Nous avons remis à l'état initial le panneau affecté. L'état d'incursion imprime 0xF0, mais les tests d'OR échoue-t-ils toujours ?
Les bits d'état RAID obtient la remise après le panneau remis à l'état initial après application de la reprise automatique.
Néanmoins non toutes les conditions de panne peuvent être récupérées automatiquement.
Si les bits d'état RAID ne sont pas imprimés comme [2/2] [UU], la reprise est inachevée.
Suivez les étapes de reprise répertoriées
La défaillance de mémoire Flash a-t-elle une incidence d'exécution ?
Non, mais le système peut ne pas démarrer sauvegardent sur une panne d'alimentation. Des configs de démarrage seront aussi bien perdus.
Qu'est recommandé pour le système courant sain du point de vue de client en termes de surveillance et reprise ?
Vérifiez l'état du test de contrat d'OR pour toutes les pannes et tentez la reprise dès que la première partie instantanée échouera.
Est-ce que je peux réparer une défaillance de mémoire Flash défectueuse d'eusb en faisant un ISSU du code affecté à la version corrigée ?
ISSU ne réparera pas l'eUSB défectueux. La meilleure option est d'exécuter l'outil de reprise pour la panne simple d'eusb sur la petite gorgée ou de recharger la petite gorgée en cas de double panne d'eusb.
Une fois que la question est corrigée alors faites la mise à jour. La difficulté pour les aides CSCus22805 corrige la panne simple d'eusb SEULEMENT et elle fait ainsi par en balayant le système à l'intervalle régulier et des tentatives de ranimer l'eUSB inaccessible ou en lecture seule utilisant le script.
Il est rare de voir que les deux la défaillance de mémoire Flash d'eusb sur le superviseur se produisant simultanément par conséquent ce contournement sera efficace.
Combien de temps prend-il pour que la question réapparaisse-t-elle si vous réparez les défaillances de mémoire Flash utilisant le module d'extension ou la recharge ?
Généralement il est vu par une plus longue disponibilité. Ceci n'est pas exactement mesuré et peut s'étendre d'une année ou plus long. La ligne inférieure est que plus l'effort sur l'éclair d'eusb en termes de lu écrit, plus la probabilité de l'exécution de système dans ce scénario est élevée.
L'incursion interne de show system affiche l'état instantané deux fois dans différentes sections. Également ces sections ne sont pas cohérentes
La première section affiche que l'état actuel et la deuxième section affiche l'état de démarrage.
L'état actuel est ce qui importe et il devrait toujours afficher comme UU.
Solutions à long terme
Ce défaut a un contournement en 6.2(14), mais la difficulté de micrologiciel a été ajoutée à 6.2(16) et à 7.2(x) et plus tard.
Il est recommandé d'améliorer à une release avec la difficulté de micrologiciel pour résoudre complètement ce problème.
Si vous ne pouvez pas améliorer à une version corrigée de NXOS il y a deux solutions possibles.
La solution 1 est d'exécuter l'outil instantané de reprise proactivement chaque semaine utilisant le programmateur. Le configuratoin suivant de programmateur avec l'outil instantané de reprise dans le bootflash :
feature scheduler
nom de JOB de programmateur Flash_Job
bootflash de la copie bootflash:/n7000-s2-flash-recovery-tool.10.0.2.gbin : /flash_recovery_tool_copy
bootflash de chargement : /flash_recovery_tool_copy
sortie
nom Flash_Recovery de programme de programmateur
nom de JOB Flash_Job
temps 7 hebdomadaires
Notes :
- La reprise instantanée doit avoir le même nom et être dans le bootflash.
- Les 7 dans la « configuration hebdomadaire du temps 7" représente un jour de la semaine, samedi dans ce cas.
- La fréquence maximum que Cisco recommande exécuter l'outil instantané de reprise est une fois par semaine.
CommentairesLaissez-nous vous aider
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)