Nexus 7000 Supervisor 2/2E compacte Flash-fout herstel
Inhoud
Inleiding
Dit document beschrijft de Nexus 7000 Supervisor 2/2E compacte flitsfout die in softwarestornis CSCus22805 wordt gedocumenteerd, alle mogelijke mislukkingsscenario's, en terugwinningsstappen.
Achtergrond
Elke N7K supervisor 2/2E is uitgerust met 2 eUSB-flitsapparaten in RAID1-configuratie, één primaire en één spiegel. Samen bieden ze niet-vluchtige repositories voor opstartbeelden, opstartconfiguratie en permanente toepassingsgegevens.
Wat er kan gebeuren is dat een van deze apparaten gedurende een periode van maanden of jaren in dienst wordt losgekoppeld van de USB-bus, waardoor de RAID-software het apparaat uit de configuratie laat vallen. Het apparaat kan nog steeds normaal functioneren met 1/2 apparaten. Echter, wanneer het tweede apparaat uit de array valt, wordt de bootflash opnieuw gemonteerd als alleen-lezen, wat betekent dat u geen configuratie of bestanden kunt opslaan op de bootflash, of de stand-by toestaan om te synchroniseren met de actieve in het geval het wordt herladen.
Er is geen operationele impact op systemen die draaien in een dubbele flitser mislukking staat, maar een herladen van de getroffen supervisor is nodig om te herstellen van deze staat. Bovendien zullen eventuele wijzigingen in de configuratie niet worden weerspiegeld in het opstarten en verloren gaan in het geval van een stroomuitval.
Symptomen
Deze symptomen zijn waargenomen:
- Compacte flash-diagnostische fout
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--------------------------> .
- Kan geen 'run start kopie' uitvoeren
dcd02.ptfrnyfs# copy running-config startup-config
[########################################] 100%
Configuration update aborted: request was aborted
- eUSB wordt alleen-lezen of reageert niet
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-storingen, meestal bij failover naar de standby supervisor
Diagnose
Om de huidige status van de compacte flitskaarten te diagnosticeren moet u deze interne opdrachten gebruiken. Merk op dat het commando niet zal ontleden en dat het volledig getypt moet worden:
switch# toont systeem interne overval | grep -A 1 "Huidige RAID status info"
switch# toont systeem intern bestand /proc/mdstat
Als er twee supervisors in het chassis zijn, zult u de status van de standby supervisor moeten controleren om te bepalen welk mislukkingsscenario u onder ogen ziet. Controleer dit door de opdracht vooraf te laten gaan met het sleutelwoord "sleuf x", waarbij "x" het sleufnummer is van de standby supervisor. Hierdoor kunt u de opdracht op afstand uitvoeren in de stand-by modus.
switch# sleuf 2 toont systeem interne raid | grep -A 1 "Huidige RAID status info"
switch# sleuf 2 toont systeem intern bestand /proc/mdstat
Deze opdrachten geven veel RAID-statistieken en -gebeurtenissen, maar u bent alleen bezig met de huidige RAID-informatie.
In de regel "RAID data from CMOS", wilt u kijken naar de hex-waarde na 0xa5. Hierin wordt aangegeven hoeveel knipperingen er op dit moment mogelijk zijn.
Voorbeeld:
switch# show system internal raid | grep -A 1 "Current RAID status info"
Current RAID status info:
RAID data from CMOS = 0xa5 0xc3
Van deze output wilt u het aantal naast 0xa5 bekijken die 0xc3 is. U kunt deze toetsen gebruiken om te bepalen of de primaire of secundaire compacte flitser is mislukt, of beide. De bovenstaande uitvoer toont 0xc3 wat ons vertelt dat zowel de primaire als de secundaire compacte flitsen hebben gefaald.
| 0,00 | Geen storingen gemeld |
| 0x1 | Primaire flitser is mislukt |
| 0xd2. | Alternatieve (of spiegel) flitser is mislukt |
| 0xc3 | Primair en Alternatief mislukt |
Zorg er in de uitvoer "/proc/mdstat" voor dat alle disks worden weergegeven als "U", wat "U" vertegenwoordigt:
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]
In dit scenario ziet u dat de primaire compacte flitser niet omhoog [_U] is. Een gezonde output toont alle blokken als [UU].
Scenario's
Om te bepalen met welk scenario u wordt geconfronteerd, zult u de bovengenoemde bevelen in de "Diagnose"sectie moeten gebruiken om met een hieronder Brief van het Scenario te correleren. Gebruik de kolommen om het aantal mislukte compacte flitsen op elke supervisor aan te passen.
Bijvoorbeeld, als u zag dat de code 0xe1 op de Actieve supervisor en 0xd2 op de Standby is, zou dit "1 Fail"op Actief en "1 Fail"op de Standby zijn die scenariobrief "D"is.
Enkelvoudige supervisor:
| Scenario-brief | Actieve supervisor | Active Supervisor-code |
| A | 1 mislukt | 0x1 of 0xd2 |
| B | 2 fouten | 0xc3 |
Dubbele toezichthouders:
| Scenario-brief | Actieve supervisor | Standby supervisor | Active Supervisor-code | Standby Supervisor Code |
| C | 0 mislukt | 1 mislukt | 0,00 | 0x1 of 0xd2 |
| D | 1 mislukt | 0 mislukt | 0x1 of 0xd2 | 0,00 |
| E | 1 mislukt | 1 mislukt | 0x1 of 0xd2 | 0x1 of 0xd2 |
| F | 2 fouten | 0 mislukt | 0xc3 | 0,00 |
| G | 0 mislukt | 2 fouten | 0,00 | 0xc3 |
| H | 2 fouten | 1 mislukt | 0xc3 | 0x1 of 0xd2 |
| I | 1 mislukt | 2 mislukt | 0x1 of 0xd2 | 0xc3 |
| J | 2 fouten | 2 fouten | 0xc3 | 0xc3 |
Invorderingsprocedure voor elk scenario
Single Supervisor failliet scenario's
Scenario A (1 fout op de actieve versie)
Herstelscenario:
1 Fout bij actief
Stappen tot resolutie:
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>
Scenario B (2 fouten op de actieve versie)
Herstelscenario:
2 Fouten in het actieve systeem
Stappen tot resolutie:
Scenario’s met dubbele supervisor-fout
Scenario C (0 mislukt op de actieve versie, 1 fout op de standby-modus)
Foutscenario:
0 fouten op het actieve
1 Fout in standby
Stappen tot resolutie:
In het scenario van een dubbele supervisor-opstelling, zonder flitsmislukkingen op de actieve en één enkele mislukking op de standby, kan een niet beïnvloedend herstel worden uitgevoerd.
1. Aangezien het actieve systeem geen storingen heeft en de stand-by slechts één storing heeft, kan de Flash Recovery Tool worden geladen op het actieve en uitgevoerde. Nadat het gereedschap is uitgevoerd, zal het zichzelf automatisch kopiëren naar de stand-by en proberen de array te resynchrone. De hersteltool kan hier worden gedownload:
Zodra u het gereedschap hebt gedownload, uitgelijnd en geüpload naar de bootflash van het vak, zult u de volgende opdracht moeten uitvoeren om te beginnen met het herstel:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
De tool begint te draaien en detecteert losgekoppelde schijven en probeert deze opnieuw te synchroniseren met de RAID-array.
U kunt de herstelstatus controleren met:
# systeem interne bestand /proc/mdstat tonen
Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:
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>
Na het herstel moet het als volgt zijn:
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>
Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.
2. Als de Flash Recovery Tool niet succesvol is, omdat de actieve twee schijven omhoog heeft, moet de stand-by met succes kunnen synchroniseren met de actieve herlading.
Daarom, in een gepland venster, voer een "out-of-service module x"voor de standby supervisor uit, wordt het aanbevolen om consoletoegang tot de stand-by te hebben om het laarsproces te observeren in het geval dat onverwachte problemen zich voordoen. Wacht een paar seconden nadat de supervisor is uitgeschakeld en voer vervolgens "no power off module x" uit voor de standby. Wacht totdat de stand-by volledig wordt opgestart in de "ha-standby"-status.
Nadat de stand-by back-up is, controleer de RAID met "slot x toon systeem interne raid" en "slot x toon systeem interne bestand /proc/mdstat".
Als beide schijven niet volledig back-up na herladen zijn, voert u het herstelprogramma opnieuw uit.
3. Als de herladen en herstel tool niet succesvol zijn, zou het worden aanbevolen om te proberen fysiek opnieuw te starten van de stand-by module in het venster om te proberen en de conditie te wissen. Als de fysieke herstart niet succesvol is, probeer dan een "Init System" uit te voeren vanuit de switch-opstartmodus door de wachtwoordherstelstappen te volgen om tijdens het opstarten in deze modus te breken. Neem contact op met TAC om handmatig herstel te proberen, indien nog steeds niet geslaagd.
Scenario D (1 fout bij actief, 0 fout bij standby)
Herstelscenario:
1 Fout bij actief
0 Fout bij standby
Stappen tot resolutie:
In het scenario van een dubbele supervisor-instelling, met 1 flitsmislukking op de actieve en geen mislukkingen op de standby, kan een niet-beïnvloedend herstel worden uitgevoerd door gebruik te maken van de Flash Recovery Tool.
1. Aangezien de stand-by geen storingen heeft en de actieve slechts één storing heeft, kan de Flash Recovery Tool worden geladen op de actieve en uitgevoerde. Nadat het gereedschap is uitgevoerd, zal het zichzelf automatisch kopiëren naar de stand-by en proberen de array te resynchrone. De hersteltool kan hier worden gedownload:
Zodra u het hulpmiddel hebt gedownload, het uitgepakt, en geüpload het naar de bootflash van de actieve, zult u de volgende opdracht moeten uitvoeren om te beginnen met het herstel:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
De tool begint te draaien en detecteert losgekoppelde schijven en probeert deze opnieuw te synchroniseren met de RAID-array.
U kunt de herstelstatus controleren met:
# systeem interne bestand /proc/mdstat tonen
Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:
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>
Na het herstel moet het als volgt zijn:
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>
Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.
2. Als de Flash Recovery Tool niet succesvol is, zou de volgende stap zijn om een "systeem switchover" uit te voeren om de supervisor modules in een onderhoudsvenster te overschakelen.
Daarom, in een gepland venster, voer een "systeem switchover"uit, wordt aanbevolen om console toegang te hebben om het bootproces waar te nemen in het geval dat onverwachte problemen zich voordoen. Wacht totdat de stand-by volledig wordt opgestart in de "ha-standby"-status.
Nadat de stand-by back-up is, controleer de RAID met "slot x toon systeem interne raid" en "slot x toon systeem interne bestand /proc/mdstat".
Als beide schijven niet volledig back-up na herladen zijn, voert u het herstelprogramma opnieuw uit.
3. Als de herladen en herstel tool niet succesvol zijn, zou het worden aanbevolen om te proberen fysiek opnieuw te starten van de stand-by module in het venster om te proberen en de conditie te wissen. Als de fysieke herstart niet succesvol is, probeer dan een "Init System" uit te voeren vanuit de switch-opstartmodus door de wachtwoordherstelstappen te volgen om tijdens het opstarten in deze modus te breken. Neem contact op met TAC om handmatig herstel te proberen, indien nog steeds niet geslaagd.
Scenario E (1 fout bij actief, 1 fout bij standby)
Herstelscenario:
1 Fout bij actief
1 Fout in standby
Stappen tot resolutie:
In het geval van één enkele flitsmislukking op zowel de actieve als stand-by, kan een niet beïnvloedende tijdelijke oplossing nog worden verwezenlijkt.
1. Aangezien geen supervisor in een read-only staat is, is de eerste stap te proberen met behulp van de Flash Recovery Tool.
De hersteltool kan hier worden gedownload:
Zodra u het hulpmiddel hebt gedownload, het uitgepakt, en geüpload het naar de bootflash van de actieve, zult u de volgende opdracht moeten uitvoeren om te beginnen met het herstel:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
Het zal automatisch detecteren losgekoppelde schijven op de actieve en proberen reparatie, evenals automatisch kopiëren naar stand-by en detecteren en corrigeren van fouten daar.
U kunt de herstelstatus controleren met:
# systeem interne bestand /proc/mdstat tonen
Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:
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>
Na het herstel moet het als volgt zijn:
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>
Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.
Als beide toezichthouders herstellen in de status [UU], dan is herstel voltooid. Als het herstel gedeeltelijk is of niet is geslaagd, gaat u naar Stap 2.
2. Indien de hersteltool niet is geslaagd, de huidige stand van de RAID op de modules aangeven. Als er nog steeds een enkele flitsfout op beide is, probeer dan een "system switchover" die de huidige actieve stroom zal herladen en de stand-by zal dwingen naar de actieve rol.
Nadat de vorige actieve stof opnieuw is geladen in "ha-standby", controleert u de RAID-status zoals deze moet worden hersteld tijdens het opnieuw laden.
Als de supervisor na de overschakeling met succes herstelt, kunt u proberen om de flash recovery tool opnieuw uit te voeren om te proberen en te repareren de single disk fout op de huidige actieve supervisor, of een andere "systeem switchover" om de huidige actieve en kracht de vorige actieve en huidige stand die werd hersteld terug naar de actieve rol. Controleer de herladen supervisor heeft beide schijven opnieuw gerepareerd, herstart de hersteltool indien nodig.
3. Als tijdens dit proces de overschakeling niet de RAID bevestigt, voer dan een "out-of-service module x" uit voor de standby en vervolgens "no power off module x" om de module volledig te verwijderen en opnieuw aan te drijven.
Als het buiten dienst stellen niet succesvol is, probeer dan een fysieke herhaling van de stand-by functie.
Als na het uitvoeren van de hersteltool de ene supervisor zijn RAID herstelt en de andere nog steeds een storing heeft, dwingt u de supervisor met de enkele fout om stand-by te staan met een "systeemswitchover" indien nodig. Als de supervisor met één enkele mislukking is
reeds stand-by, doe een "out-of-service module x" voor de standby- en "no power off module x" om de voeding van de module volledig te verwijderen en opnieuw toe te passen. Als de unit nog steeds niet herstelt, probeer dan een fysieke herhaling van de module. Indien een herhaling niet vaststaat,
breken in de switch boot prompt met behulp van de wachtwoordherstel procedure en doe een "init systeem" om de bootflash te reinitialiseren. Als dit nog steeds niet succesvol is, TAC poging handmatig herstel.
scenario F (2 fouten in het actieve circuit, 0 fouten in de stand-by modus)
Herstelscenario:
2 Fouten in het actieve systeem
0 Fout bij standby
Stappen tot resolutie:
Met 2 mislukkingen op de actieve en 0 op de standby supervisor is een niet-beïnvloedend herstel mogelijk, afhankelijk van hoeveel van de in bedrijf zijnde configuratie is toegevoegd sinds de stand-by niet in staat was om zijn in bedrijf zijnde-configuratie met de actieve te synchroniseren.
De herstelprocedure zal zijn om de huidige lopende configuratie te kopiëren van de actieve supervisor, failover naar de gezonde stand-by supervisor, de ontbrekende lopende configuratie te kopiëren naar de nieuwe actieve, handmatig brengen van de vorige actieve online, dan het herstel tool.
2. Zodra de in werking stellen-configuratie van de actieve supervisor is gekopieerd, zal het een goed idee zijn om het bij de startconfiguratie te vergelijken om te zien wat sinds laatste sparen is veranderd. Dit is te zien bij "show startup-configuratie". De verschillen zijn natuurlijk volledig afhankelijk van het milieu, maar het is goed om te weten wat er mis kan gaan als de stand-by online komt als de actieve. Het is ook een goed idee om de verschillen al gekopieerd in een blocnote te hebben zodat zij snel aan de nieuwe actieve supervisor na de omschakeling kunnen worden toegevoegd.
3. Nadat de verschillen zijn geëvalueerd, zult u een supervisor switchover moeten uitvoeren. TAC raadt aan dit te doen tijdens een onderhoudsvenster, omdat zich onverwachte problemen kunnen voordoen. De opdracht voor het uitvoeren van de failover naar de standby is "system switchover".
4. De overschakeling zou zeer snel moeten plaatsvinden en de nieuwe stand-by zal beginnen met het opstarten. Tijdens deze tijd zult u om het even welke ontbrekende configuratie terug aan nieuw actief willen toevoegen. Dit kan worden gedaan door de configuratie te kopiëren van de TFTP-server (of waar deze eerder is opgeslagen) of door de configuratie in de CLI eenvoudig handmatig toe te voegen. In de meeste gevallen zijn de ontbrekende configuraties zeer kort en de CLI optie zal het meest haalbaar zijn.
5. Na enige tijd kan de nieuwe standby-supervisor weer online komen in een "ha-standby"-staat, maar wat normaal gesproken gebeurt is dat het vastloopt in een "aangedreven" staat. De staat kan worden bekeken met behulp van de "show module" opdracht en verwijzen naar de "Status" kolom naast de module.
Als de nieuwe stand-by in een "aangedreven-up" staat komt, moet u het handmatig weer online brengen. Dit kan door het uitgeven van de volgende bevelen worden gedaan, waar "x"de standby module is die in een "aangedreven-omhoog"staat wordt geplakt:
(configuratie)# buiten-servicemodule x
(configuratie)# geen uitschakelmodule x
6. Zodra de stand-by weer online is in een "ha-standby"-staat, moet u de hersteltool uitvoeren om ervoor te zorgen dat het herstel is voltooid. U kunt de tool downloaden via de volgende link:
Zodra u het gereedschap hebt gedownload, uitgelijnd en geüpload naar de bootflash van het vak, zult u de volgende opdracht moeten uitvoeren om te beginnen met het herstel:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
De tool begint te draaien en detecteert losgekoppelde schijven en probeert deze opnieuw te synchroniseren met de RAID-array.
U kunt de herstelstatus controleren met:
# systeem interne bestand /proc/mdstat tonen
Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:
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>
Na het herstel moet het als volgt zijn:
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>
Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.
Scenario G (0 mislukt op de actieve versie, 2 mislukt op de standby-modus)
0 fouten op het actieve scherm, 2 fouten op de stand-by
Herstelscenario:
0 fouten op het actieve
2 Kan niet in standby
Stappen tot resolutie:
Met 0 storingen op de actieve en 2 op de standby supervisor is een niet-beïnvloedend herstel mogelijk.
De herstelprocedure bestaat erin de stand-by opnieuw te laden.
1. In supervisor met een dubbele flitsmislukking wordt algemeen gezien dat een software "herlaad module x" slechts gedeeltelijk de INVAL kan herstellen of het geplakt opgewekt bij reboot krijgen.
Daarom is het raadzaam om ofwel fysiek opnieuw te plaatsen de supervisor met dubbele flitsmislukking om volledig te verwijderen en opnieuw toe te passen macht op de module, of u kunt het volgende (x voor standby slot #) uitvoeren:
# buiten dienst gestelde module x
# geen uitschakelmodule x
Als u ziet dat de stand-by blijft vastzitten in de power-up staat en uiteindelijk de power cycling houdt na de stappen hierboven, is dit waarschijnlijk te wijten aan de actieve herladen van de stand voor niet op tijd komen.
Dit kan te wijten zijn aan de opstartstand die probeert om zijn bootflash/RAID opnieuw te initialiseren, die tot 10 minuten kan duren, maar het blijft worden gereset door de actieve voordat het kan bereiken.
Om dit op te lossen, het volgende te configureren met behulp van 'x' voor de standby-sleuf # vastgezet in power-up:
(configuratie)# systeem stand-by handmatige start
(config)# herlastmodule x force-dnld
Het bovenstaande maakt de stand-by modus zo actief dat de stand-by niet automatisch wordt gereset, en herlaadt de stand-by modus en dwingt deze om de afbeelding te synchroniseren met de actieve modus.
Wacht 10-15 minuten om te zien of de stand-by eindelijk in staat is om de ha-standby status te bereiken. Nadat de stand-by status is bereikt, schakelt u de automatische herstart van de stand-by opnieuw in met:
(configuratie)# systeem geen stand-by handmatige start
6. Zodra de stand-by weer online is in een "ha-standby"-staat, moet u de hersteltool uitvoeren om ervoor te zorgen dat het herstel is voltooid. U kunt de tool downloaden via de volgende link:
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>
Na het herstel moet het als volgt zijn:
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>
Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.
Scenario H (2 fouten op het actieve systeem, 1 fout in de standby-modus)
2 fouten op de actieve versie, 1 fout op de stand-by
Herstelscenario:
2 Fouten in het actieve systeem
1 Kan niet in standby
Stappen tot resolutie:
Met 2 mislukkingen op de actieve en 1 op de standby supervisor is een niet-beïnvloedend herstel mogelijk, afhankelijk van hoeveel van de in bedrijf zijnde configuratie is toegevoegd sinds de stand-by niet in staat was om zijn in bedrijf zijnde-configuratie met de actieve te synchroniseren.
De herstelprocedure zal zijn om back-up van de huidige lopende configuratie van de actieve supervisor, failover naar de gezonde standby supervisor, kopieer de ontbrekende lopende configuratie naar de nieuwe actieve, handmatig brengen van de vorige actieve online, en voer vervolgens de hersteltool uit.
1. Back-up van alle lopende configuratie extern met "kopie in werking stellen-configuratie tftp: VDC-all". Houd er rekening mee dat in het geval van een dubbele flitsfout, configuratie veranderingen aangezien het systeem opnieuw gemonteerd op alleen-lezen niet aanwezig zijn op de opstartconfiguratie. U kunt "Toon systeem interne overval" voor de getroffen module om te bepalen wanneer de tweede schijf ontbrak die is waar het systeem gaat read-only. Van daaruit kunt u "show accounting log" voor elke VDC bekijken om te bepalen welke wijzigingen zijn aangebracht sinds de dubbele flitsfout, zodat u weet wat toe te voegen als de opstartconfiguratie bij herladen blijft.
Houd er rekening mee dat het mogelijk is dat de opstartconfiguratie wordt afgeveegd bij het opnieuw laden van een supervisor met dubbele flitsfout. Daarom moet van de configuratie extern een back-up worden gemaakt.
2. Zodra de in werking stellen-configuratie van de actieve supervisor is gekopieerd, zal het een goed idee zijn om het bij de startconfiguratie te vergelijken om te zien wat sinds laatste sparen is veranderd. Dit kan worden gezien met "show startup-configuratie". De verschillen zijn natuurlijk volledig afhankelijk van het milieu, maar het is goed om te weten wat er mis kan gaan als de stand-by online komt als de actieve. Het is ook een goed idee om de verschillen al gekopieerd in een blocnote te hebben zodat zij snel aan de nieuwe actieve supervisor na de omschakeling kunnen worden toegevoegd.
3. Nadat de verschillen zijn geëvalueerd, zult u een supervisor switchover moeten uitvoeren. TAC raadt aan dit te doen tijdens een onderhoudsvenster, omdat zich onverwachte problemen kunnen voordoen. De opdracht voor het uitvoeren van de failover naar de standby is "system switchover".
4. De overschakeling zou zeer snel moeten plaatsvinden en de nieuwe stand-by zal beginnen met het opstarten. Tijdens deze tijd zult u om het even welke ontbrekende configuratie terug aan nieuw actief willen toevoegen. Dit kan worden gedaan door de configuratie te kopiëren van de TFTP server (of waar het eerder werd opgeslagen) of door de configuratie in de CLI simpelweg handmatig toe te voegen, niet direct van tftp naar running-configuratie te kopiëren, eerst naar bootflash te kopiëren, en dan naar lopende configuratie. In de meeste gevallen zijn de ontbrekende configuraties zeer kort en de CLI optie zal het meest haalbaar zijn.
5. Na enige tijd kan de nieuwe standby-supervisor weer online komen in een "ha-standby"-staat, maar wat normaal gesproken gebeurt is dat het vastloopt in een "aangedreven" staat. De staat kan worden bekeken met behulp van de "show module" opdracht en verwijzen naar de "Status" kolom naast de module.
Als de nieuwe stand-by in een "aangedreven-up" staat komt, moet u het handmatig weer online brengen. Dit kan door het uitgeven van de volgende bevelen worden gedaan, waar "x"de standby module is die in een "aangedreven-omhoog"staat wordt geplakt:
(configuratie) #out-of-service module
(configuratie)# geen uitschakelmodule x
Als u ziet dat de stand-by blijft vastzitten in de power-up staat en uiteindelijk de power cycling houdt na de stappen hierboven, is dit waarschijnlijk te wijten aan de actieve herladen van de stand voor niet op tijd komen.
Dit kan te wijten zijn aan de opstartstand die probeert om zijn bootflash/RAID opnieuw te initialiseren, die tot 10 minuten kan duren, maar het blijft worden gereset door de actieve voordat het kan bereiken.
Om dit op te lossen, het volgende te configureren met behulp van 'x' voor de standby-sleuf # vastgezet in power-up:
(configuratie)# systeem stand-by handmatige start
(config)# herlastmodule x force-dnld
Het bovenstaande maakt de stand-by modus zo actief dat de stand-by niet automatisch wordt gereset, en herlaadt de stand-by modus en dwingt deze om de afbeelding te synchroniseren met de actieve modus.
Wacht 10-15 minuten om te zien of de stand-by eindelijk in staat is om de ha-standby status te bereiken. Nadat de stand-by status is bereikt, schakelt u de automatische herstart van de stand-by opnieuw in met:
(configuratie)# systeem geen stand-by handmatige start
6. Zodra de stand-by weer online is in een "ha-standby"-staat, moet u de hersteltool uitvoeren om ervoor te zorgen dat de herstel is voltooid en om de single disk fout op de actieve schijf te repareren. U kunt de tool downloaden via de volgende link:
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>
Na het herstel moet het als volgt zijn:
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>
Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.
Als de huidige actieve met een enkele fout niet wordt hersteld door de hersteltool, probeer dan een andere "system switchover" om ervoor te zorgen dat uw huidige stand-by status "ha-standby" is. Als dit nog niet is gelukt, neem dan contact op met Cisco TAC
Scenario I (1 fout bij actief, 2 fouten bij standby)
Herstelscenario:
1 Fout bij actief
2 Kan niet in standby
Stappen tot resolutie:
In een dubbel supervisor scenario met 1 mislukking op de actieve en 2 mislukkingen op de standby supervisor kan een niet-beïnvloedend herstel mogelijk zijn, maar in veel gevallen kan een herlading noodzakelijk zijn.
Het proces zal aan eerste back-up alle lopende configuraties zijn, dan proberen om de mislukte compacte flits op de actieve met behulp van het herstel hulpmiddel terug te krijgen, dan, als succesvol, zal u handmatig opnieuw laden van de stand-by en het herstel gereedschap opnieuw uitvoeren. Als de eerste herstelpoging niet in staat is om de mislukte flitser op het actieve bestand te herstellen, moet TAC worden ingeschakeld om een handmatig herstel te proberen met behulp van de debug plugin.
Zodra u het gereedschap hebt gedownload, uitgelijnd en geüpload naar de bootflash van het vak, zult u de volgende opdracht moeten uitvoeren om te beginnen met het herstel:
# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin
De tool begint te draaien en detecteert losgekoppelde schijven en probeert deze opnieuw te synchroniseren met de RAID-array.
U kunt de herstelstatus controleren met:
# systeem interne bestand /proc/mdstat tonen
Controleer of het herstel doorgaat. Het kan enkele minuten duren voordat alle disks volledig zijn gerepareerd in de status [UU]. Een voorbeeld van een nuttige toepassing in werking ziet er als volgt uit:
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>
Na het herstel moet het als volgt zijn:
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>
Nadat alle schijven zijn in [UU], is de RAID-array volledig back-up met beide schijven sync'd.
3. Als u, na het uitvoeren van de Recovery Tool in stap 2, niet in staat bent om de mislukte compacte flitser op de actieve supervisor te herstellen, moet u contact opnemen met TAC om een handmatig herstel te proberen met behulp van de linux debug plugin.
4. Na te hebben gecontroleerd dat beide knipperingen worden weergegeven als "[U]" op de actieve, kunt u doorgaan met het handmatig opnieuw opstarten van de standby supervisor. Dit kan door het uitgeven van de volgende bevelen worden gedaan, waar "x"de standby module is die in een "aangedreven-omhoog"staat wordt geplakt:
(configuratie)# buiten-servicemodule x
(configuratie)# geen uitschakelmodule x
Dit zou de standby supervisor terug in een "ha-standby"staat moeten brengen (dit wordt gecontroleerd door de kolom van de Status in de "show module"output te bekijken). Als dit geslaagd is, gaat u verder naar stap 6 en als dit niet het geval is, probeert u de procedure die in stap 5 is beschreven.
5. Als u ziet dat de stand-by blijft vastzitten in de power-up staat en uiteindelijk de power cycling houdt na de stappen hierboven, is dit waarschijnlijk te wijten aan de actieve herladen van de stand voor niet op tijd komen. Dit kan te wijten zijn aan de opstartstand die probeert om zijn bootflash/RAID opnieuw te initialiseren, die tot 10 minuten kan duren, maar het blijft worden gereset door de actieve voordat het kan bereiken. Om dit op te lossen, het volgende te configureren met behulp van 'x' voor de standby-sleuf # vastgezet in power-up:
(configuratie)# systeem stand-by handmatige start
(config) #reload module x force-dnld
Het bovenstaande maakt de stand-by modus zo actief dat de stand-by niet automatisch wordt gereset, en herlaadt de stand-by modus en dwingt deze om de afbeelding te synchroniseren met de actieve modus.
Wacht 10-15 minuten om te zien of de stand-by eindelijk in staat is om de ha-standby status te bereiken. Nadat de stand-by status is bereikt, schakelt u de automatische herstart van de stand-by opnieuw in met:
(configuratie)# systeem geen stand-by handmatige start
6. Zodra de stand-by weer online is in een "ha-standby"-staat, moet u de hersteltool uitvoeren om ervoor te zorgen dat het herstel is voltooid. U kunt hetzelfde gereedschap uitvoeren dat u hebt op de actieve voor deze stap, geen extra download is nodig als de hersteltool draait op de actieve en de stand-by.
scenario J (2 fouten in actief, 2 fouten in standby)
Herstelscenario:
2 Fouten in het actieve systeem
2 Kan niet in standby
Stappen tot resolutie:
Samenvatting
Veelgestelde vragen
Is er een permanente oplossing voor deze kwestie?
Zie het gedeelte over langetermijnoplossingen hieronder.
Waarom is het niet mogelijk om een dubbele failover op de actieve en stand-by te herstellen door de standby supervisor te herladen en failover?
De reden dat dit niet mogelijk is is omdat om de standby supervisor toe te staan om in een "ha-standby"staat omhoog te komen, de actieve supervisor verscheidene dingen aan zijn compacte flits (SNMP info, enz.) moet schrijven, die het niet kan doen als het een dubbele flitsmislukking zelf heeft.
Wat gebeurt er als de Flash Recovery Tool niet in staat is om de compacte flitser te hertellen?
Neem contact op met Cisco TAC voor opties in dit scenario.
Heeft deze bug ook invloed op de Nexus 7700 Sup2E?
De N7700 Sup2E - CSCuv64056 heeft een eigen defect. De hersteltool werkt niet voor de N7700.
Werkt de hersteltool voor NPE-afbeeldingen?
De hersteltool werkt niet voor NPE-afbeeldingen.
Zal een kwestie aan een opgeloste versie van code deze kwestie oplossen?
Nee. Een ISSU zal gebruik maken van een supervisor switchover, die mogelijk niet correct presteert vanwege de compacte flitsstoring.
We reset het betreffende bord. Raid status drukt 0xF0, maar GOLD testen nog steeds niet?
RAID status bits worden gereset nadat board reset na toepassing van auto herstel.
Niet alle foutcondities kunnen echter automatisch worden hersteld.
Als de RAID-statusbits niet zijn afgedrukt als [2/2] [UU], is het herstel onvolledig.
Volg de genoemde herstelstappen
Zal de flitsstoring enige invloed hebben op de werking?
Nee, maar het systeem start mogelijk niet op bij een stroomuitval. Startup configuraties zullen ook verloren gaan.
Wat wordt aanbevolen voor een gezond, actief systeem vanuit het perspectief van de klant in termen van bewaking en herstel?
Controleer de GOLD compacte teststatus voor eventuele storingen en probeer herstel zodra het eerste flitsonderdeel mislukt.
Kan ik een mislukte eusb-flitsstoring oplossen door een ISSU uit de code te doen die is aangetast naar de vaste release?
ISSU zal mislukte eUSB niet repareren. De beste optie is om de hersteltool uit te voeren voor een enkele eusb fout op de sup of herladen van de sup geval van dubbele eusb falen.
Voer de upgrade uit als het probleem is opgelost. De oplossing voor CSCus22805 helpt alleen enkele sabfout te corrigeren en doet dit door het systeem met regelmatige tussenpozen te scannen en probeert ontoegankelijke of alleen-lezen eUSB opnieuw te activeren met behulp van het script.
Het is zeldzaam om te zien dat beide eusb flash-uitval op de supervisor tegelijkertijd voorkomen, vandaar dat deze tijdelijke oplossing zal effectief zijn.
Hoe lang duurt het voordat het probleem opnieuw verschijnt als u de flitsstoringen oplost met behulp van plugin of herladen?
Over het algemeen wordt het gezien door een langere uptime. Dit is niet precies gekwantificeerd en kan variëren van een jaar of langer. Het komt er op neer dat hoe meer stress op de USB-flitser in termen van lees schrijft, hoe groter de waarschijnlijkheid dat het systeem dit scenario tegenkomt.
Toon systeem interne overval toont de flitsstatus tweemaal in verschillende secties. Ook deze punten zijn niet consistent
De eerste sectie toont de huidige status en de tweede sectie toont de bootup status.
De huidige status is wat er toe doet en moet altijd als UU worden getoond.
Langetermijnoplossingen
Dit defect heeft een tijdelijke oplossing in 6.2(14), maar de firmware fix werd toegevoegd aan 6.2(16) en 7.2(x) en later.
Het is aan te raden om te upgraden naar een release met de firmware fix om dit probleem volledig op te lossen.
Als u niet kunt upgraden naar een vaste versie van NXOS, zijn er twee mogelijke oplossingen.
Oplossing 1 moet de flash recovery tool proactief elke week met behulp van de planner. De volgende plannerconfiguratie met de flash recovery tool in de bootflash:
functieplanner
naam planner-taak Flash_Job
copy bootflash:/n7000-s2-flash-recovery-tool.10.0.2.gbin bootflash:/flash_recovery_tool_copy
load bootflash:/flash_recovery_tool_copy
uitgang
Planner Schema naam Flash_Recovery
Taaknaam Flash_Job
wekelijkse tijd 7
Opmerkingen:
- Het flash herstel moet dezelfde naam en in de bootflash.
- De 7 in de "tijd week 7"-configuratie staat voor een dag van de week, in dit geval zaterdag.
- De maximale frequentie die Cisco aanbeveelt voor het gebruik van de flash recovery tool is eenmaal per week.
Oplossing 2 is gedocumenteerd via de volgende technologielink
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)