Nexus 7000 Supervisor 2/2E Compact Flash Failure Recovery

소개

이 문서에서는 소프트웨어 결함 CSCus22805에 설명된 Nexus 7000 Supervisor 2/2E 컴팩트 플래시 오류 문제, 가능한 모든 오류 시나리오 및 복구 단계에 대해 설명합니다. 

이 문제를 해결하기 전에, 물리적으로 재장착해야 하는 경우 디바이스에 물리적으로 액세스하는 것이 좋습니다.  일부 다시 로드 업그레이드의 경우 콘솔 액세스가 필요할 수 있으며 부팅 프로세스를 관찰하기 위해 항상 수퍼바이저에 대한 콘솔 액세스로 이러한 해결 방법을 수행하는 것이 좋습니다.

해결 방법 중 하나라도 실패하면 Cisco TAC에 추가 가능한 복구 옵션을 문의하십시오. 

배경

각 N7K 수퍼바이저 2/2E에는 RAID1 컨피그레이션의 eUSB 플래시 디바이스 2개, 1개의 기본 및 1개의 미러가 장착되어 있습니다. 이 두 솔루션은 부팅 이미지, 시작 컨피그레이션 및 지속적인 애플리케이션 데이터를 위한 비휘발성 저장소를 제공합니다.

몇 개월 또는 몇 년 동안 서비스를 제공하는 경우 이러한 디바이스 중 하나가 USB 버스에서 분리되면 RAID 소프트웨어가 디바이스를 컨피그레이션에서 삭제합니다. 디바이스는 1/2 디바이스로 계속 정상적으로 작동할 수 있습니다. 그러나 두 번째 디바이스가 스토리지에서 삭제되면 bootflash가 읽기 전용으로 다시 마운트됩니다. 즉, 구성 또는 파일을 bootflash에 저장할 수 없거나 다시 로드된 경우 스탠바이가 액티브와 동기화되도록 허용할 수 없습니다.

이중 플래시 장애 상태에서 실행되는 시스템에는 아무런 영향을 미치지 않지만 이 상태에서 복구하려면 영향을 받는 수퍼바이저를 다시 로드해야 합니다. 또한 실행 중인 구성에 대한 변경 사항은 시작에 반영되지 않으며 정전이 발생하더라도 손실됩니다.

증상

다음과 같은 증상이 나타났습니다.

• 컴팩트 플래시 진단 실패

 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--------------------------> .

• '복사 실행 시작'을 수행할 수 없습니다.

dcd02.ptfrnyfs# copy running-config startup-config
 [########################################] 100%
 Configuration update aborted: request was aborted 

• eUSB가 읽기 전용이 되거나 응답하지 않습니다.

switch %MODULE-4-MOD_WARNING: Module 2 (Serial number: JAF1645AHQT) reported warning
 due to The compact flash power test failed in device DEV_UNDEF (device error 0x0)

switch %DEVICE_TEST-2-COMPACT_FLASH_FAIL: Module 1 has failed test CompactFlash 20
 times on device Compact Flash due to error The compact flash power test failed

• ISSU 실패(일반적으로 대기 수퍼바이저로 장애 조치를 시도할 때)

진단

컴팩트 플래시 카드의 현재 상태를 진단하려면 다음 내부 명령을 사용해야 합니다. 이 명령은 구문 분석되지 않으며 완전히 입력해야 합니다.

switch# show system internal raid | grep -A 1 "현재 RAID 상태 정보"

switch# show system internal file /proc/mdstat

섀시에 수퍼바이저가 두 개 있는 경우 대기 수퍼바이저의 상태도 확인하여 어떤 장애 시나리오를 직면하고 있는지 확인해야 합니다. 명령을 "slot x" 키워드와 함께 추가하여 확인합니다. 여기서 "x"는 대기 수퍼바이저의 슬롯 번호입니다. 그러면 스탠바이에서 명령을 원격으로 실행할 수 있습니다.

switch# slot 2 show system internal raid | grep -A 1 "현재 RAID 상태 정보"

switch# slot 2 show system internal file /proc/mdstat

이러한 명령은 많은 RAID 통계 및 이벤트를 제공하지만 현재 RAID 정보에만 관심을 갖습니다. 

"CMOS의 RAID 데이터" 행에서 0xa5 이후의 16진수 값을 살펴볼 수 있습니다.  현재 문제가 발생한 플래시 수를 표시합니다. 

예를 들면 다음과 같습니다.

 switch# show system internal raid | grep -A 1 "Current RAID status info"
 Current RAID status info:
 RAID data from CMOS = 0xa5 0xc3

이 출력에서 당신은 0xc3인 0xa5 옆의 숫자를 보고자 한다.  그런 다음 이 키를 사용하여 기본 또는 보조 컴팩트 플래시에 장애가 발생했는지 또는 둘 다 실패했는지 확인할 수 있습니다. 위 출력에는 기본 및 보조 컴팩트 플래시 모두 실패했음을 나타내는 0xc3이 표시됩니다.

"/proc/mdstat" 출력에서 모든 디스크가 "U"를 나타내는 "U"로 표시되는지 확인합니다.

switch# slot 2 show system internal file /proc/mdstat
Personalities : [raid1]
md6 : active raid1 sdc6[0] sdb6[1]
      77888 blocks [2/1] [_U]

md5 : active raid1 sdc5[0] sdb5[1]
      78400 blocks [2/1] [_U]

md4 : active raid1 sdc4[0] sdb4[1]
      39424 blocks [2/1] [_U]

md3 : active raid1 sdc3[0] sdb3[1]
      1802240 blocks [2/1] [_U]

이 시나리오에서는 기본 컴팩트 플래시가 [_U]에 있지 않습니다. 정상 출력은 모든 블록을 [UU]로 표시합니다.

참고: 두 출력 모두 정상(0xf0 및 [UU])으로 표시되어야 수퍼바이저를 정상 상태로 진단할 수 있습니다. 따라서 CMOS 데이터에서 0xf0 출력이 표시되지만 /proc/mdstat에서 [_U]가 표시되면 상자가 비정상 상태입니다.

시나리오

어떤 시나리오에 직면했는지 확인하려면 "진단" 섹션에서 위의 명령을 사용하여 아래 시나리오 문자와 연계해야 합니다.  열을 사용하여 각 수퍼바이저의 실패한 컴팩트 플래시 수를 확인합니다. 

예를 들어, 코드가 활성 수퍼바이저의 0xe1이고 스탠바이의 0xd2인 경우, 이는 활성 수퍼바이저의 "1 Fail" 및 시나리오 문자 "D"인 스탠바이의 "1 Fail"이 됩니다.

단일 수퍼바이저:

듀얼 슈퍼바이저:

각 시나리오의 복구 절차

단일 수퍼바이저 오류 시나리오

시나리오 A(액티브 상태에서 1회 실패)

복구 시나리오:

    1 활성 상태에서 실패

해결 단계:

1. 부트 플래시를 복구하려면 플래시 복구 도구를 로드합니다. N7000 플랫폼용 유틸리티의 CCO에서 복구 도구를 다운로드하거나 아래 링크를 사용할 수 있습니다.

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

tar gz 압축 파일로 래핑되어 있습니다. 압축을 풀어서 .gbin 복구 도구와 .pdf readme 파일을 찾으십시오. Readme 파일을 검토하고 N7K의 bootflash에 .gbin 도구를 로드합니다. 이 복구는 영향을 받지 않도록 설계되었으며 실시간으로 수행할 수 있지만, TAC에서는 예기치 않은 문제가 발생할 경우 유지 관리 창에서 수행할 것을 권장합니다. 파일이 bootflash에 있으면 다음을 사용하여 복구 도구를 실행할 수 있습니다.

switch# show system internal file /proc/mdstat \
Personalities : [raid1]
md6    : active raid1 sdd6[2] sdc6[0] 
    77888 blocks [2/1] [U_]  <-- "U_" represents the broken state
        resync=DELAYED
        
md5    : active raid1 sdd5[2] sdc5[0] 
    78400 blocks [2/1] [U_]
        resync=DELAYED
        
md4    : active raid1 sdd4[2] sdc4[0] 
    39424 blocks [2/1] [U_]
        resync=DELAYED

md3    : active raid1 sdd3[2] sdc3[0] 
    1802240 blocks [2/1] [U_]

[=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
unused devices: <none>

switch# show system internal file /proc/mdstat Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0] 
    77888 blocks [2/2] [UU]  <-- "UU" represents the fixed state
    
md5 :active raid1 sdd5[1] sdc5[0] 
    78400 blocks [2/2] [UU]
    
md4 :active raid1 sdd4[1] sdc4[0] 
    39424 blocks [2/2] [UU]
    
md3 :active raid1 sdd3[1] sdc3[0] 
    1802240 blocks [2/2] [UU]
unused devices: <none>

시나리오 B(액티브 상태에서 2번 실패)

복구 시나리오:

    2 액티브 상태에서 실패

해결 단계:

참고: 이는 일반적으로 이중 플래시 오류의 경우에 나타나며, 소프트웨어를 다시 로드하면 RAID를 완전히 복구하지 못할 수 있으며 복구 도구를 실행하거나 이후 다시 로드해야 복구할 수 있습니다. 대부분의 경우 수퍼바이저 모듈의 물리적 재장착으로 해결되었습니다. 따라서 디바이스에 대한 물리적 액세스가 가능한 경우, 컨피그레이션을 외부에서 백업한 후 디바이스를 다시 로드할 준비가 되었을 때 수퍼바이저를 물리적으로 재장착하여 성공할 가능성이 가장 높은 빠른 복구를 시도할 수 있습니다. 이렇게 하면 수퍼바이저의 전원이 완전히 제거되므로 RAID에서 두 디스크를 모두 복구할 수 있습니다. 물리적 재장착 복구가 부분적으로만 진행되는 경우 3단계로 진행하고, 시스템이 완전히 부팅되지 않아 완전히 성공하지 못한 경우 4단계로 진행합니다.

듀얼 슈퍼바이저 오류 시나리오

시나리오 C(액티브 상태에서는 0개 실패, 스탠바이 상태에서는 1개 실패)

실패 시나리오:

    활성 상태에서 0이 실패함

    1 스탠바이 시 실패

해결 단계:

액티브 상태의 경우 플래시 장애가 없고 스탠바이 상태의 경우 단일 장애가 있는 이중 수퍼바이저 설정 시나리오에서는 영향을 미치지 않는 복구를 수행할 수 있습니다.


1. 액티브 에는 장애가 없고 스탠바이 에는 단일 장애가 있으므로 플래시 복구 도구를 액티브 로 로드하여 실행할 수 있습니다. 툴을 실행한 후 자동으로 스탠바이에 복사하고 스토리지 재동기화를 시도합니다.  복구 도구는 여기에서 다운로드할 수 있습니다.

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

도구를 다운로드하고 압축을 풀고 상자의 부트플래시에 업로드한 후에는 다음 명령을 실행하여 복구를 시작해야 합니다.

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

이 도구는 실행을 시작하고 연결이 끊어진 디스크를 감지하고 RAID 어레이와 다시 동기화합니다.

복구 상태를 확인하려면 다음을 수행합니다.

# 시스템 내부 파일 표시 /proc/mdstat

복구가 진행 중인지 확인합니다. 모든 디스크를 완전히 복구하려면 몇 분 정도 걸릴 수 있습니다. 복구 작업의 예는 다음과 같습니다.                                                                                                       
                                        

 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

복구가 완료되면 다음과 같이 표시됩니다.

 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>

                                                                 
모든 디스크가 [UU]에 있으면 RAID 어레이가 두 디스크 동기화로 완전히 백업됩니다.

2. Flash Recovery Tool이 실패할 경우 액티브 디스크에 두 디스크가 모두 작동하므로 다시 로드할 때 스탠바이 디스크가 액티브 디스크에 성공적으로 동기화할 수 있어야 합니다.

따라서 예약된 창에서 대기 수퍼바이저에 대해 "서비스 중단 모듈 x"를 수행합니다. 예기치 않은 문제가 발생할 경우 부팅 프로세스를 관찰하기 위해 스탠바이에 대한 콘솔 액세스 권한을 갖는 것이 좋습니다. 수퍼바이저가 중단된 후 몇 초 동안 기다린 다음 스탠바이에 대해 "no poweroff module x"를 수행합니다. 스탠바이가 완전히 부팅되어 "ha-standby" 상태가 될 때까지 기다립니다.

스탠바이가 백업된 후 "slot x show system internal raid" 및 "slot x show system internal file /proc/mdstat"로 RAID를 확인합니다.

다시 로드한 후 두 디스크 모두 완전히 백업되지 않으면 복구 도구를 다시 실행하십시오.

3. 다시 로드 및 복구 툴이 성공하지 못한 경우, 대기 모듈을 창에 물리적으로 다시 장착하여 상태를 지우려고 시도하는 것이 좋습니다.  물리적 재장착이 성공하지 못하면 비밀번호 복구 단계에 따라 스위치 부팅 모드에서 "init system"을 수행하여 부팅 중에 이 모드로 전환해 보십시오.  그래도 문제가 해결되지 않으면 TAC에 문의하여 수동 복구를 시도합니다.

시나리오 D(액티브 상태에서는 1회 실패, 스탠바이 상태에서는 0회 실패)

복구 시나리오:

    1 활성 상태에서 실패

    스탠바이 시 0개 실패

해결 단계:

액티브 상태의 경우 1개의 플래시 장애가 발생하고 스탠바이 상태의 경우 1개의 장애가 발생하지 않는 이중 수퍼바이저 설정 시나리오에서는 Flash Recovery Tool을 사용하여 영향 없는 복구를 수행할 수 있습니다.


1. 스탠바이 에는 장애가 없고 액티브 에는 단일 장애가 있으므로 Flash Recovery Tool 을 액티브 로 로드하여 실행할 수 있습니다. 툴을 실행한 후 자동으로 스탠바이에 복사하고 스토리지 재동기화를 시도합니다.  복구 도구는 여기에서 다운로드할 수 있습니다.

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

툴을 다운로드하고 압축을 푼 다음 활성 디바이스의 부트플래시에 업로드한 후에는 다음 명령을 실행하여 복구를 시작해야 합니다.

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

이 도구는 실행을 시작하고 연결이 끊어진 디스크를 감지하고 RAID 어레이와 다시 동기화합니다.

복구 상태를 확인하려면 다음을 수행합니다.

# 시스템 내부 파일 표시 /proc/mdstat

복구가 진행 중인지 확인합니다. 모든 디스크를 완전히 복구하려면 몇 분 정도 걸릴 수 있습니다. 복구 작업의 예는 다음과 같습니다.                                                                                                       
                                        

 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

복구가 완료되면 다음과 같이 표시됩니다.

 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>

                                                                
모든 디스크가 [UU]에 있으면 RAID 어레이가 두 디스크 동기화로 완전히 백업됩니다.



2. 플래시 복구 툴이 실패할 경우 다음 단계는 유지 보수 창에서 수퍼바이저 모듈을 장애 조치하기 위해 "시스템 전환"을 수행하는 것입니다.

따라서 예약된 창에서 "시스템 전환"을 수행합니다. 예기치 않은 문제가 발생할 경우 부팅 프로세스를 관찰할 수 있도록 콘솔 액세스 권한을 갖는 것이 좋습니다.  스탠바이가 완전히 부팅되어 "ha-standby" 상태가 될 때까지 기다립니다.

스탠바이가 백업된 후 "slot x show system internal raid" 및 "slot x show system internal file /proc/mdstat"로 RAID를 확인합니다.

다시 로드한 후 두 디스크 모두 완전히 백업되지 않으면 복구 도구를 다시 실행하십시오.


3. 다시 로드 및 복구 툴이 성공하지 못한 경우, 대기 모듈을 창에 물리적으로 다시 장착하여 상태를 지우려고 시도하는 것이 좋습니다.  물리적 재장착이 성공하지 못하면 비밀번호 복구 단계에 따라 스위치 부팅 모드에서 "init system"을 수행하여 부팅 중에 이 모드로 전환해 보십시오.  그래도 문제가 해결되지 않으면 TAC에 문의하여 수동 복구를 시도합니다.

시나리오 E(액티브 상태에서 1회 실패, 스탠바이 상태에서 1회 실패)

복구 시나리오:

    1 활성 상태에서 실패

    1 스탠바이 시 실패

해결 단계:

액티브 및 스탠바이 둘 다에서 단일 플래시 장애가 발생할 경우에도 영향을 미치지 않는 해결 방법을 사용할 수 있습니다.


1. 수퍼바이저가 읽기 전용 상태가 아니므로 첫 번째 단계는 플래시 복구 도구를 사용하는 것입니다.

복구 도구는 여기에서 다운로드할 수 있습니다.

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

툴을 다운로드하고 압축을 푼 다음 활성 디바이스의 부트플래시에 업로드한 후에는 다음 명령을 실행하여 복구를 시작해야 합니다.

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

또한 액티브 상태의 연결이 끊어진 디스크를 자동으로 감지하고 복구를 시도할 뿐만 아니라 자신을 스탠바이 상태로 자동으로 복사하고 해당 오류를 감지하고 수정합니다.

복구 상태를 확인하려면 다음을 수행합니다.

# 시스템 내부 파일 표시 /proc/mdstat

복구가 진행 중인지 확인합니다. 모든 디스크를 완전히 복구하려면 몇 분 정도 걸릴 수 있습니다. 복구 작업의 예는 다음과 같습니다.                

                                                                                       
 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

복구가 완료되면 다음과 같이 표시됩니다.

 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>

                                                                  
모든 디스크가 [UU]에 있으면 RAID 어레이가 두 디스크 동기화로 완전히 백업됩니다.


두 수퍼바이저가 모두 [UU] 상태로 복구되면 복구가 완료된 것입니다.  복구가 일부이거나 성공하지 못한 경우 2단계로 이동합니다.


2. 복구 툴이 성공하지 못한 경우 모듈에서 RAID의 현재 상태를 확인합니다. 둘 다에서 단일 플래시 오류가 여전히 발생하는 경우 "시스템 전환"을 시도하면 현재 액티브가 다시 로드되고 스탠바이가 액티브 역할로 강제 전환됩니다.

이전 액티브 가 다시 "ha-standby"로 로드되면 다시 로드 중에 복구해야 하므로 RAID 상태를 확인합니다.
전환 후 수퍼바이저가 성공적으로 복구되면 플래시 복구 도구를 다시 실행하여 현재 활성 수퍼바이저의 단일 디스크 오류를 복구하거나, 다른 "시스템 전환"을 사용하여 현재 활성 수퍼바이저를 다시 로드하고 복구된 이전 활성 및 현재 대기 상태를 활성 역할로 강제 복구할 수 있습니다. 다시 로드된 수퍼바이저가 두 디스크를 모두 복구했는지 확인하고 필요한 경우 복구 도구를 다시 실행하십시오.


3. 이 프로세스 중에 스위치오버가 RAID를 고정하지 않는 경우, 스탠바이에 대해 "out-of-service module x"를 수행한 다음 "no poweroff module x"를 수행하여 모듈에 전원을 완전히 제거하고 다시 적용합니다.

서비스 불능 상태가 지속되면 스탠바이의 물리적 재장착을 시도합니다.

복구 툴을 실행한 후 한 수퍼바이저가 RAID를 복구하고 다른 수퍼바이저가 여전히 장애가 있는 경우 필요한 경우 "시스템 전환"을 사용하여 단일 장애가 있는 수퍼바이저를 강제로 스탠바이 상태로 전환합니다. 단일 장애 상태의 수퍼바이저가
이미 대기 상태인 경우, 대기 모드에 대해 "out-of-service module x"를 수행하고 "no poweroff module x"를 수행하여 모듈의 전원을 완전히 제거하고 다시 공급합니다. 그래도 복구되지 않으면 모듈을 물리적으로 재장착하십시오. 재장착이 해결되지 않을 경우
비밀번호 복구 절차를 사용하여 스위치 부팅 프롬프트에 침입하고 "init system"을 수행하여 부트플래시를 다시 초기화합니다. 그래도 실패할 경우 TAC에서 수동 복구를 시도하도록 합니다.

참고: 어느 시점에서든 스탠바이가 "ha-standby"가 아닌 "powered-up" 상태로 유지되면 위의 단계를 통해 스탠바이를 완전히 가동할 수 없는 경우 섀시를 다시 로드해야 합니다.

시나리오 F(액티브 상태에서는 2개, 스탠바이 상태에서는 0개 실패)

복구 시나리오:

    2 액티브 상태에서 실패

    스탠바이 시 0개 실패

해결 단계:

액티브 수퍼바이저에서 2개의 장애가 발생하고 스탠바이 수퍼바이저에서 0개의 장애가 발생할 경우, 스탠바이가 running-config를 액티브 컨피그레이션과 동기화할 수 없었기 때문에 추가된 running-configuration의 양에 따라 영향을 받지 않는 복구가 가능합니다.

복구 절차는 활성 수퍼바이저에서 현재 실행 중인 컨피그레이션을 복사하고, 정상 대기 수퍼바이저로 장애 조치를 수행하고, 누락된 실행 중인 컨피그레이션을 새 활성 상태로 복사하고, 수동으로 이전 활성 상태를 온라인 상태로 전환한 다음 복구 도구를 실행하는 것입니다.

2 .  실행 중인 컨피그레이션을 활성 수퍼바이저에서 복사한 후에는 시작 컨피그레이션과 비교하여 마지막 저장 이후 변경된 사항을 확인하는 것이 좋습니다.  이는 "show startup-configuration"에서 확인할 수 있습니다.  그 차이는 물론 환경에 완전히 좌우될 것이지만, 스탠바이 가 액티브 상태로 온라인 상태가 되면 무엇이 누락될 수 있는지를 파악하는 것이 좋습니다.  전환 후 차이점을 새 활성 수퍼바이저에 빠르게 추가할 수 있도록 차이점을 메모장에 복사하는 것도 좋습니다.

3 .  차이를 평가한 후 수퍼바이저 전환을 수행해야 합니다.  예기치 않은 문제가 발생할 수 있으므로 TAC에서는 유지 보수 기간 중에 이를 수행할 것을 권장합니다.  스탠바이에 대한 장애 조치를 수행하는 명령은 "시스템 전환"입니다.

4.  전환은 매우 신속하게 이루어져야 하며 새로운 스탠바이가 재부팅을 시작합니다.  이 시간 동안 누락된 컨피그레이션을 새 활성 상태로 다시 추가하려고 합니다.  이는 TFTP 서버(또는 이전에 저장한 곳)에서 컨피그레이션을 복사하거나 CLI에서 수동으로 컨피그레이션을 추가하는 방법으로 수행할 수 있습니다.  대부분의 경우 누락된 컨피그레이션은 매우 짧으며 CLI 옵션이 가장 효과적입니다.

5.  잠시 후에 새 대기 수퍼바이저가 "ha-standby" 상태로 다시 온라인 상태가 될 수 있지만 일반적으로 발생하는 것은 "powered-up" 상태에 머물러 있다는 것입니다.  상태는 "show module" 명령과 모듈 옆의 "Status" 열을 사용하여 볼 수 있습니다. 

새 스탠바이가 "전원 켜짐" 상태로 작동되면 수동으로 다시 온라인 상태로 전환해야 합니다.  이 작업은 다음 명령을 실행하여 수행할 수 있습니다. 여기서 "x"는 "전원이 켜진" 상태에서 고정된 스탠바이 모듈입니다.

    (config)# out-of-service 모듈 x

    (config)# 전원 끄기 모듈 x 없음

6.  대기 상태가 "ha-standby" 상태로 돌아오면 복구 도구를 실행하여 복구가 완료되었는지 확인해야 합니다.  도구는 다음 링크에서 다운로드할 수 있습니다.

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

도구를 다운로드하고 압축을 풀고 상자의 부트플래시에 업로드한 후에는 다음 명령을 실행하여 복구를 시작해야 합니다.

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

이 도구는 실행을 시작하고 연결이 끊어진 디스크를 감지하고 RAID 어레이와 다시 동기화합니다.

복구 상태를 확인하려면 다음을 수행합니다.

# 시스템 내부 파일 표시 /proc/mdstat

복구가 진행 중인지 확인합니다. 모든 디스크를 완전히 복구하려면 몇 분 정도 걸릴 수 있습니다. 복구 작업의 예는 다음과 같습니다.                                                                                                       
                                        

 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

복구가 완료되면 다음과 같이 표시됩니다.

switch# show system internal file /proc/mdstat

Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
    77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
    
md5 :active raid1 sdd5[1] sdc5[0]
    78400 blocks [2/2] [UU]
    
md4 :active raid1 sdd4[1] sdc4[0]
    39424 blocks [2/2] [UU]
    
md3 :active raid1 sdd3[1] sdc3[0]
    1802240 blocks [2/2] [UU]
unused devices: <none>

                                                                  
모든 디스크가 [UU]에 있으면 RAID 어레이가 두 디스크 동기화로 완전히 백업됩니다.

시나리오 G(액티브 상태에서 0이 실패하고 스탠바이 상태에서 2가 실패함)

액티브 상태에서는 0이 실패하고, 스탠바이 상태에서는 2가 실패함

복구 시나리오:

    활성 상태에서 0이 실패함

    2 스탠바이 시 실패

해결 단계:

액티브 수퍼바이저에서는 장애가 0개, 스탠바이 수퍼바이저에서는 장애가 2개이므로 영향을 받지 않는 복구가 가능합니다.

복구 절차는 스탠바이 다시 로드를 수행하는 것입니다.

1. 수퍼바이저에서 일반적으로 듀얼 플래시 오류가 발생하는 경우 소프트웨어 "reload module x"가 RAID를 부분적으로만 복구하거나 재부팅 시 전원이 꺼지지 않을 수 있습니다.

따라서 듀얼 플래시 장애 시 물리적으로 수퍼바이저를 재장착하여 모듈을 완전히 분리하고 모듈에 다시 전원을 공급하는 것이 좋습니다. 또는 다음 단계를 수행할 수 있습니다(대기 슬롯 번호의 경우 x).

    # 서비스 불능 모듈 x
    # 전원 끄기 모듈 없음 x

스탠바이가 계속 전원이 켜진 상태로 유지되어 위의 단계 이후에 전원 사이클링이 지속되는 경우, 이는 스탠바이가 제때 켜지지 않도록 활성 상태로 다시 로드하기 때문일 수 있습니다.

이는 부팅 스탠바이가 bootflash/RAID를 다시 초기화하려고 시도하기 때문일 수 있습니다. 이 경우 최대 10분이 소요될 수 있지만, 완료될 때까지 액티브 상태가 계속 재설정됩니다.

이 문제를 해결하려면 전원 켜짐 상태에서 대기 슬롯 번호에 대해 'x'를 사용하여 다음을 구성합니다.

    (config)# 시스템 대기 수동 부팅
    (config)# 모듈 다시 로드 x force-dnld
    
    위의 명령을 사용하면 Active에서 Standby를 자동으로 재설정하지 않고 Standby를 다시 로드하여 Active에서 이미지를 강제로 동기화합니다.
    
    10-15분 정도 기다렸다가 대기 상태가 ha-standby 상태로 전환되는지 확인합니다. ha-standby 상태가 되면 다음을 사용하여 스탠바이의 자동 재부팅을 다시 활성화합니다.
    
    (config)# 시스템 no standby manual-boot
    

6.  대기 상태가 "ha-standby" 상태로 돌아오면 복구 도구를 실행하여 복구가 완료되었는지 확인해야 합니다.  도구는 다음 링크에서 다운로드할 수 있습니다.

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest


도구를 다운로드하고 압축을 풀고 상자의 부트플래시에 업로드한 후에는 다음 명령을 실행하여 복구를 시작해야 합니다.

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

이 도구는 실행을 시작하고 연결이 끊어진 디스크를 감지하고 RAID 어레이와 다시 동기화합니다.

복구 상태를 확인하려면 다음을 수행합니다.

# 시스템 내부 파일 표시 /proc/mdstat

복구가 진행 중인지 확인합니다. 모든 디스크를 완전히 복구하려면 몇 분 정도 걸릴 수 있습니다. 복구 작업의 예는 다음과 같습니다.                                                                                                       
                                        

 switch# show system internal file /proc/mdstat
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

복구가 완료되면 다음과 같이 표시됩니다.

  
 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>

모든 디스크가 [UU]에 있으면 RAID 어레이가 두 디스크 동기화로 완전히 백업됩니다.

시나리오 H(액티브 상태에서는 2회, 스탠바이 상태에서는 1회)

액티브 상태에서는 2번, 스탠바이 상태에서는 1번

복구 시나리오:

    2 액티브 상태에서 실패

    1 스탠바이 시 실패

해결 단계:

액티브 수퍼바이저에서 2회, 스탠바이 수퍼바이저에서 1회 장애가 발생할 경우, 스탠바이가 running-config를 액티브 컨피그레이션과 동기화할 수 없었기 때문에 추가된 running-configuration의 양에 따라 영향을 받지 않는 복구가 가능합니다.


복구 절차는 활성 수퍼바이저에서 현재 실행 중인 컨피그레이션을 백업하고, 정상 대기 수퍼바이저로 장애 조치하고, 누락된 실행 중인 컨피그레이션을 새 활성 상태로 복사하고, 수동으로 이전 활성 상태를 온라인 상태로 전환한 다음 복구 도구를 실행하는 것입니다.


1.  "copy running-config tftp: vdc-all". 이중 플래시 오류가 발생할 경우 시스템이 읽기 전용으로 다시 마운트된 이후의 컨피그레이션 변경 사항은 시작 컨피그레이션에 없습니다. 영향을 받는 모듈에 대한 "show system internal raid"를 검토하여 시스템이 읽기 전용으로 전환되는 두 번째 디스크에 장애가 발생한 시점을 확인할 수 있습니다. 여기에서 각 VDC에 대한 "show accounting log"를 검토하여 듀얼 플래시 실패 이후 어떤 변경이 이루어졌는지 확인할 수 있습니다. 그러면 다시 로드할 때 시작 컨피그레이션이 지속되는 경우 무엇을 추가해야 하는지 알 수 있습니다.

듀얼 플래시 장애가 발생한 경우 수퍼바이저를 다시 로드할 때 시작 컨피그레이션이 지워질 수 있으므로 컨피그레이션을 외부에서 백업해야 합니다.


2 .  실행 중인 컨피그레이션을 활성 수퍼바이저에서 복사한 후에는 시작 컨피그레이션과 비교하여 마지막 저장 이후 변경된 사항을 확인하는 것이 좋습니다.  이는 "show startup-configuration"으로 확인할 수 있습니다.  그 차이는 물론 환경에 완전히 좌우될 것이지만, 스탠바이 가 액티브 상태로 온라인 상태가 되면 무엇이 누락될 수 있는지를 파악하는 것이 좋습니다.  전환 후 차이점을 새 활성 수퍼바이저에 빠르게 추가할 수 있도록 차이점을 메모장에 복사하는 것도 좋습니다.


3 .  차이를 평가한 후 수퍼바이저 전환을 수행해야 합니다.  예기치 않은 문제가 발생할 수 있으므로 TAC에서는 유지 보수 기간 중에 이를 수행할 것을 권장합니다.  스탠바이에 대한 장애 조치를 수행하는 명령은 "시스템 전환"이 됩니다.


4.  전환은 매우 신속하게 이루어져야 하며 새로운 스탠바이가 재부팅을 시작합니다.  이 시간 동안 누락된 컨피그레이션을 새 활성 상태로 다시 추가하려고 합니다.  이 작업은 TFTP 서버에서(또는 이전에 저장한 모든 위치에서) 구성을 복사하거나 CLI에서 수동으로 구성을 추가하는 방법으로 수행할 수 있습니다. tftp에서 실행 중인 구성으로 직접 복사하지 말고 bootflash에 먼저 복사한 다음 실행 중인 구성으로 복사하십시오.  대부분의 경우 누락된 컨피그레이션은 매우 짧으며 CLI 옵션이 가장 효과적입니다.


5.  잠시 후에 새 대기 수퍼바이저가 "ha-standby" 상태로 다시 온라인 상태가 될 수 있지만 일반적으로 발생하는 것은 "powered-up" 상태에 머물러 있다는 것입니다.  상태는 "show module" 명령을 사용하고 모듈 옆의 "Status" 열을 참조하여 볼 수 있습니다.


새 스탠바이가 "전원 켜짐" 상태로 작동되면 수동으로 다시 온라인 상태로 전환해야 합니다.  이 작업은 다음 명령을 실행하여 수행할 수 있습니다. 여기서 "x"는 "전원이 켜진" 상태에서 고정된 스탠바이 모듈입니다.

    (config)# 서비스 불능 모듈
    (config)# 전원 끄기 모듈 x 없음        
    
    
스탠바이가 계속 전원이 켜진 상태로 유지되어 위의 단계 이후에 전원 사이클링이 지속되는 경우, 이는 스탠바이가 제때 켜지지 않도록 활성 상태로 다시 로드하기 때문일 수 있습니다.
이는 부팅 스탠바이가 bootflash/RAID를 다시 초기화하려고 시도하기 때문일 수 있습니다. 이 경우 최대 10분이 소요될 수 있지만, 완료될 때까지 액티브 상태가 계속 재설정됩니다.
이 문제를 해결하려면 전원 켜짐 상태에서 대기 슬롯 번호에 대해 'x'를 사용하여 다음을 구성합니다.

    (config)# 시스템 대기 수동 부팅
    (config)# 모듈 다시 로드 x force-dnld
    
    위의 명령을 사용하면 Active에서 Standby를 자동으로 재설정하지 않고 Standby를 다시 로드하여 Active에서 이미지를 강제로 동기화합니다.
    
    10-15분 정도 기다렸다가 대기 상태가 ha-standby 상태로 전환되는지 확인합니다. ha-standby 상태가 되면 다음을 사용하여 스탠바이의 자동 재부팅을 다시 활성화합니다.
    
    (config)# 시스템 비대기 수동 부팅
   
6.  일단 대기 상태가 "ha-standby" 상태로 돌아오면 복구 도구를 실행하여 복구가 완료되었는지 확인하고 액티브 상태의 단일 디스크 오류를 복구해야 합니다.  도구는 다음 링크에서 다운로드할 수 있습니다.

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest


도구를 다운로드하고 압축을 풀고 상자의 부트플래시에 업로드한 후에는 다음 명령을 실행하여 복구를 시작해야 합니다.

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

이 도구는 실행을 시작하고 연결이 끊어진 디스크를 감지하고 RAID 어레이와 다시 동기화합니다.

복구 상태를 확인하려면 다음을 수행합니다.

# 시스템 내부 파일 표시 /proc/mdstat

복구가 진행 중인지 확인합니다. 모든 디스크를 완전히 복구하려면 몇 분 정도 걸릴 수 있습니다. 복구 작업의 예는 다음과 같습니다.                                                                                                       

                                       
 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

복구가 완료되면 다음과 같이 표시됩니다.

 switch# show system internal file /proc/mdstat Personalities : [raid1]
 md6 :active raid1 sdd6[1] sdc6[0]
     77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
     
 md5 :active raid1 sdd5[1] sdc5[0]
     78400 blocks [2/2] [UU]
     
 md4 :active raid1 sdd4[1] sdc4[0]
     39424 blocks [2/2] [UU]
     
 md3 :active raid1 sdd3[1] sdc3[0]
     1802240 blocks [2/2] [UU]
 unused devices: <none>
  

                                                                 
모든 디스크가 [UU]에 있으면 RAID 어레이가 두 디스크 동기화로 완전히 백업됩니다.

단일 오류의 현재 액티브 상태가 복구 도구로 복구되지 않으면 현재 스탠바이가 "ha-standby" 상태인지 확인하기 위해 다른 "시스템 전환"을 시도합니다.  그래도 성공하지 못한 경우 Cisco TAC에 문의하십시오.

시나리오 I(액티브 상태에서 1회 실패, 스탠바이 상태에서 2회 실패)

복구 시나리오:

    1 활성 상태에서 실패

    2 스탠바이 시 실패

해결 단계:

액티브 수퍼바이저에서는 장애 1개, 스탠바이 수퍼바이저에서는 장애 2개로 구성된 이중 수퍼바이저 시나리오에서는 영향을 받지 않는 복구가 가능하지만, 많은 경우 다시 로드해야 할 수 있습니다.

이 프로세스에서는 먼저 실행 중인 모든 컨피그레이션을 백업한 다음 복구 도구를 사용하여 액티브 상태의 실패한 컴팩트 플래시를 복구하려고 시도한 다음, 성공하면 수동으로 대기 디바이스를 다시 로드하고 복구 도구를 다시 실행합니다.  초기 복구 시도에서 액티브 상태의 실패한 플래시를 복구할 수 없는 경우 TAC에서 디버그 플러그인을 사용하여 수동 복구를 시도해야 합니다.

1.  "copy running-config tftp: vdc-all".  TFTP 서버가 환경에 설정되지 않은 경우 running-config를 로컬 USB 스틱에 복사할 수도 있습니다.

2 .  현재 실행 중인 컨피그레이션이 백업되면 복구 도구를 실행하여 액티브 상태의 실패한 플래시의 복구를 시도해야 합니다.  도구는 다음 링크에서 다운로드할 수 있습니다.

https://software.cisco.com/download/release.html?mdfid=284472710&flowid=&softwareid=282088132&relind=AVAILABLE&rellifecycle=&reltype=latest

도구를 다운로드하고 압축을 풀고 상자의 부트플래시에 업로드한 후에는 다음 명령을 실행하여 복구를 시작해야 합니다.

# load bootflash:n7000-s2-flash-recovery-tool.10.0.2.gbin

이 도구는 실행을 시작하고 연결이 끊어진 디스크를 감지하고 RAID 어레이와 다시 동기화합니다.

복구 상태를 확인하려면 다음을 수행합니다.

# 시스템 내부 파일 표시 /proc/mdstat

복구가 진행 중인지 확인합니다. 모든 디스크를 완전히 복구하려면 몇 분 정도 걸릴 수 있습니다. 복구 작업의 예는 다음과 같습니다.                                                                                                       
                                        

 switch# show system internal file /proc/mdstat \
 Personalities : [raid1]
 md6    : active raid1 sdd6[2] sdc6[0]
     77888 blocks [2/1] [U_]    <-- "U_" represents the broken state
         resync=DELAYED
         
 md5    : active raid1 sdd5[2] sdc5[0]
     78400 blocks [2/1] [U_]
         resync=DELAYED
         
 md4    : active raid1 sdd4[2] sdc4[0]
     39424 blocks [2/1] [U_]
         resync=DELAYED

 md3    : active raid1 sdd3[2] sdc3[0]
     1802240 blocks [2/1] [U_]

 [=>...................] recovery = 8.3% (151360/1802240) finish=2.1min s peed=12613K/sec
 unused devices: <none>

복구가 완료되면 다음과 같이 표시됩니다.

switch# show system internal file /proc/mdstat

Personalities : [raid1]
md6 :active raid1 sdd6[1] sdc6[0]
    77888 blocks [2/2] [UU]    <-- "UU" represents the correct state
    
md5 :active raid1 sdd5[1] sdc5[0]
    78400 blocks [2/2] [UU]
    
md4 :active raid1 sdd4[1] sdc4[0]
    39424 blocks [2/2] [UU]
    
md3 :active raid1 sdd3[1] sdc3[0]
    1802240 blocks [2/2] [UU]
unused devices: <none>

                                                                  
모든 디스크가 [UU]에 있으면 RAID 어레이가 두 디스크 동기화로 완전히 백업됩니다.

3 .  2단계에서 복구 도구를 실행한 후 활성 수퍼바이저에서 실패한 컴팩트 플래시를 복구할 수 없는 경우 TAC에 문의하여 linux 디버그 플러그인을 사용하여 수동 복구를 시도해야 합니다.

4.  두 플래시가 활성에서 "[UU]"(으)로 표시되는지 확인한 후 대기 수퍼바이저를 수동으로 재부팅할 수 있습니다.  이 작업은 다음 명령을 실행하여 수행할 수 있습니다. 여기서 "x"는 "전원이 켜진" 상태에서 고정된 스탠바이 모듈입니다.

    (config)# out-of-service 모듈 x

    (config)# 전원 끄기 모듈 x 없음

이렇게 하면 대기 수퍼바이저가 "ha-standby" 상태가 됩니다("show module" 출력에서 Status 열을 확인하여 확인).  성공하면 6단계로 진행하고, 그렇지 않으면 5단계에 설명된 절차를 수행합니다.

5.  스탠바이가 계속 전원이 켜진 상태로 유지되어 위의 단계 이후에 전원 사이클링이 지속되는 경우, 이는 스탠바이가 제때 켜지지 않도록 활성 상태로 다시 로드하기 때문일 수 있습니다.  이는 부팅 스탠바이가 bootflash/RAID를 다시 초기화하려고 시도하기 때문일 수 있습니다. 이 경우 최대 10분이 소요될 수 있지만, 완료될 때까지 액티브 상태가 계속 재설정됩니다.  이 문제를 해결하려면 전원 켜짐 상태에서 대기 슬롯 번호에 대해 'x'를 사용하여 다음을 구성합니다.

(config)# 시스템 대기 수동 부팅
(config)# 모듈 다시 로드 x force-dnld

위의 명령을 사용하면 Active에서 Standby를 자동으로 재설정하지 않고 Standby를 다시 로드하여 Active에서 이미지를 강제로 동기화합니다.

10-15분 정도 기다렸다가 대기 상태가 ha-standby 상태로 전환되는지 확인합니다. ha-standby 상태가 되면 다음을 사용하여 스탠바이의 자동 재부팅을 다시 활성화합니다.

(config)# 시스템 no standby manual-boot

6.  대기 상태가 "ha-standby" 상태로 돌아오면 복구 도구를 실행하여 복구가 완료되었는지 확인해야 합니다.  이 단계에 대해 활성에 있는 것과 동일한 도구를 실행할 수 있습니다. 복구 도구가 활성 및 대기 모드에서 실행되므로 추가 다운로드가 필요하지 않습니다.

시나리오 J(액티브 상태에서 2개 실패, 스탠바이 상태에서 2개 실패)

복구 시나리오:

    2 액티브 상태에서 실패

    2 스탠바이 시 실패

해결 단계:

참고: 이는 일반적으로 이중 플래시 오류의 경우에 나타나며, 소프트웨어 "다시 로드"가 RAID를 완전히 복구하지 못할 수 있으며 복구 도구를 실행하거나 후속 재로드를 실행하여 복구해야 할 수 있습니다. 대부분의 경우 수퍼바이저 모듈의 물리적 재장착으로 해결되었습니다. 따라서 디바이스에 대한 물리적 액세스가 가능한 경우, 컨피그레이션을 외부에서 백업한 후 디바이스를 다시 로드할 준비가 되었을 때 수퍼바이저를 물리적으로 재장착하여 성공할 가능성이 가장 높은 빠른 복구를 시도할 수 있습니다. 이렇게 하면 수퍼바이저의 전원이 완전히 제거되므로 RAID에서 두 디스크를 모두 복구할 수 있습니다. 물리적 재장착 복구가 부분적으로만 진행되는 경우 3단계로 진행하고, 시스템이 완전히 부팅되지 않아 완전히 성공하지 못한 경우 4단계로 진행합니다.

요약

FAQ

이 문제에 대한 영구적인 해결책이 있습니까?

아래의 장기 솔루션 섹션을 참조하십시오.

스탠바이 수퍼바이저를 다시 로드하고 장애 조치를 수행하여 액티브 및 스탠바이에서 이중 장애 조치를 복구할 수 없는 이유는 무엇입니까?

이는 스탠바이 수퍼바이저가 "ha-standby" 상태로 올라오도록 하기 위해서는 액티브 수퍼바이저가 컴팩트 플래시(SNMP 정보 등)에 여러 사항을 기록해야 하는데, 듀얼 플래시 장애 자체로는 불가능하기 때문입니다.

플래시 복구 도구가 컴팩트 플래시를 다시 마운트할 수 없는 경우 어떻게 됩니까?

이 시나리오의 옵션은 Cisco TAC에 문의하십시오.

이 버그는 Nexus 7700 Sup2E에도 영향을 줍니까?

N7700 Sup2E - CSCuv64056에 별도의 결함이 있습니다.  N7700에서는 복구 도구가 작동하지 않습니다.

복구 도구는 NPE 이미지에 대해 작동합니까?

복구 도구는 NPE 이미지에 대해 작동하지 않습니다.

해결된 버전의 코드에 대한 ISSU로 이 문제가 해결됩니까?

아니요. ISSU는 수퍼바이저 스위치오버를 사용합니다. 수퍼바이저 스위치오버는 컴팩트 플래시 오류로 인해 제대로 수행되지 않을 수 있습니다.

우리는 영향을 받는 보드를 재설정합니다. RAID 상태는 0xF0을 출력하지만 GOLD 테스트는 여전히 실패합니까?

자동 복구를 적용한 후 보드 재설정 후 RAID 상태 비트가 재설정됩니다.
그러나 모든 실패 조건을 자동으로 복구할 수는 없습니다.
RAID 상태 비트가 [2/2] [UU](으)로 인쇄되지 않으면 복구가 완료되지 않습니다.
나열된 복구 단계를 수행합니다

플래시 장애가 작업에 영향을 미칩니까?

아니요. 그러나 전원 장애 시 시스템이 부팅되지 않을 수 있습니다. 시작 구성도 손실됩니다.

모니터링 및 복구 측면에서 고객의 관점에서 건강한 실행 시스템에 권장되는 사항은 무엇입니까?

GOLD Compact Test Status(GOLD 컴팩트 테스트 상태)에서 모든 오류를 확인하고 첫 번째 플래시 부품이 실패하는 즉시 복구를 시도합니다.

영향받는 코드에서 고정 릴리스로 ISSU를 수행하여 실패한 eusb 플래시 오류를 해결할 수 있습니까?

ISSU는 실패한 eUSB를 수정하지 않습니다. 최상의 옵션은 sup에서 단일 eusb 오류에 대한 복구 도구를 실행하거나 이중 eusb 오류의 경우 sup를 다시 로드하는 것입니다.
문제가 해결되면 업그레이드를 수행합니다. CSCus22805의 수정 사항은 단일 eusb 오류만 수정하는 데 도움이 되며, 정기적으로 시스템을 검사하고 스크립트를 사용하여 액세스 할 수 없거나 읽기 전용 eUSB를 다시 시작하려고 시도합니다.
수퍼바이저에서 두 eusb 플래시 장애가 동시에 발생하는 경우는 드물기 때문에 이 해결 방법이 효과적입니다.

플러그인이나 다시 로드를 사용하여 플래시 오류를 수정할 경우 문제가 다시 나타나는 데 얼마나 걸립니까?

일반적으로 가동 시간이 길어집니다. 이 값은 정확히 수량화되지 않았으며 1년 이상의 범위가 될 수 있습니다. 결론적으로 읽기 쓰기와 관련하여 eusb 플래시에 대한 스트레스가 많을수록 시스템이 이 시나리오로 실행될 가능성이 높다는 것입니다.

Show system internal raid(시스템 내부 RAID 표시)는 다른 섹션에서 플래시 상태를 두 번 표시합니다. 또한 이러한 섹션은 일관되지 않습니다
첫 번째 섹션에는 현재 상태가 표시되고 두 번째 섹션에는 부팅 상태가 표시됩니다.
현재 상황이 중요하며 항상 UU로 표시되어야 합니다.

장기 솔루션

이 결함은 6.2(14)에서 해결 방법이 있지만 6.2(16) 및 7.2(x) 이상에 펌웨어 수정이 추가되었습니다. 

이 문제를 완전히 해결하려면 펌웨어 수정이 포함된 릴리스로 업그레이드하는 것이 좋습니다.

고정 버전의 NXOS로 업그레이드할 수 없는 경우 두 가지 솔루션이 있습니다. 

해결 방법 1은 스케줄러를 사용하여 플래시 복구 도구를 매주 사전 대응적으로 실행하는 것입니다.  bootflash에서 플래시 복구 도구를 사용하는 다음 스케줄러 컨피그레이션:

기능 스케줄러
스케줄러 작업 이름 Flash_Job

  bootflash 복사:/n7000-s2-flash-recovery-tool.10.0.2.gbin bootflash:/flash_recovery_tool_copy
  bootflash 로드:/flash_recovery_tool_copy

  종료
스케줄러 일정 이름 Flash_Recovery
  작업 이름 Flash_Job
  주별 7

참고: 

• 플래시 복구는 동일한 이름과 bootflash에 있어야 합니다.
• "time weekly 7" 컨피그레이션의 7은 이 경우 토요일인 요일을 나타냅니다.
• Cisco에서 플래시 복구 도구를 실행하는 것을 권장하는 최대 빈도는 일주일에 한 번입니다.

 솔루션 2에 대한 설명은 다음 기술 링크에 나와 있습니다