목차

문제 설명:

영향을 받는 하드웨어:

UCSB-MRAID12G RAID 컨트롤러가 있는 서버:

영향을 받는 펌웨어:

영향을 받는 OS:

원인:

문제 발생 방지 방법

서버에서 이 문제가 발생한 경우 복구하는 방법

관련 버그: CSCvr11972

문제 설명:

RAID 컨트롤러를 교체한 후 외부 컨피그레이션 가져오기 중에 VD의 NAA ID가 변경되었으며 데이터 저장소 마운트가 실패하게 되었습니다.

영향을 받는 하드웨어:

UCSB-MRAID12G

UCSC-MRAID12G

UCSB-MRAID12G RAID 컨트롤러가 있는 서버:

UCS B200 M4

UCS B200 M5

UCS B480 M5

UCS B420 M4

UCS C220 M4

UCS C240 M4

영향을 받는 펌웨어:

RAID 컨트롤러 펌웨어:  24.5.x.x 및 24.6.x.x

예 #

***mrsasctlr.24.5.0-0043_6.19.05.0_NA.bin

24.5.x.x 컨트롤러 펌웨어는 3.2 이전 모든 UCSM 릴리스에서 확인됨*

3.1 #의 릴리스 정보

https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/release/notes/CiscoUCSManager-RB-3-1.htmlhttps://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/release/notes/CiscoUCSManager-RB-3-1.html

영향을 받는 OS:

VMware ESXi

원인:

이전 펌웨어 릴리스의 경우 DDF(Device Data Format) 작업 영역 버전이 일치하지 않는 경우 컨트롤러 FW는 외부 가져오기 중에 DDF에서 NAA ID를 복원할 수 없습니다.

MR 6.4에는 DDF_WORK_SPACE 버전 1이 있는 반면 MR 6.10에는 DDF_WORK_SPACE 버전 3이 있습니다. FW 포스트 MR 6.4의 이후 릴리스에서는 DDF 작업 공간 불일치가 발견되더라도 컨트롤러 FW가 DDF에서 NA ID를 복원할 수 있도록 수정되었습니다. 교체 컨트롤러 펌웨어가 오래된 경우 NAA ID를 올바르게 분석할 수 없습니다(예:24.5.x 및 24.6.x). 그러나 24.12.x 버전은 NAA ID를 올바르게 구문 분석할 수 있습니다.

교체 전:

서버 2/2:

장비 제품 이름:Cisco UCS B200 M5 2 소켓 블레이드 서버

장비 PID:UCSB-B200-M5

장착형 VID:V06

장착형 직렬(SN):FCH22973K5

슬롯 상태:장착됨

접수된 제품 이름:Cisco UCS B200 M5 2 소켓 블레이드 서버

확인된 PID:UCSB-B200-M5

확인된 VID:V06

접수된 직렬(SN):FCH22973K5

확인된 메모리(MB):524288

확인된 유효 메모리(MB):524288

확인된 코어:28

확인된 어댑터:1

가상 드라이브 0:

유형:RAID 1 미러링

블록 크기:512

블록:1560545280

운영 가능성:작동 가능

현재 상태:장착됨

크기:761985

주기:할당

드라이브 상태:최적

스트립 크기(KB):64

액세스 정책:읽기 쓰기

읽기 정책:보통

구성된 쓰기 캐시 정책:쓰기 통과

실제 쓰기 캐시 정책:쓰기 통과

IO 정책:직접

드라이브 캐시:변경 없음

부팅 가능:참

고유 식별자:bcc0dd21-2006-4189-86c1-132017ad0958

판매업체 고유 식별자:618e7283-72eb-6460-240f-d02c0bbd9310 <<<<<<<<<<<<<<<<<<<<<<<<<<

교체 후:

서버 2/2:

장비 제품 이름:Cisco UCS B200 M5 2 소켓 블레이드 서버

장비 PID:UCSB-B200-M5

장착형 VID:V06

장착형 직렬(SN):FCH22973K5

슬롯 상태:장착됨

접수된 제품 이름:Cisco UCS B200 M5 2 소켓 블레이드 서버

확인된 PID:UCSB-B200-M5

확인된 VID:V06

접수된 직렬(SN):FCH22973K5

확인된 메모리(MB):524288

확인된 유효 메모리(MB):524288

확인된 코어:28

확인된 어댑터:1

가상 드라이브 0:

유형:RAID 1 미러링

블록 크기:512

블록:1560545280

운영 가능성:작동 가능

현재 상태:장착됨

크기:761985

주기:할당

드라이브 상태:최적

스트립 크기(KB):64

액세스 정책:읽기 쓰기

읽기 정책:보통

구성된 쓰기 캐시 정책:쓰기 통과

실제 쓰기 캐시 정책:쓰기 통과

IO 정책:직접

드라이브 캐시:변경 없음

부팅 가능:참

고유 식별자:7a894b44-721a-41ae-a3bf-380102b9e64e

판매업체 고유 식별자:618e7283-72ea-3f20-ff00-005a0574b04b <<<<<<<<<<<<<<<<<<<<<<<<<<

이 경우 서버 2/2의 [Vendor Unique Identifier] id가 [618e7283-72eb-6460-240f-d02c0bbd9310]에서 [618e7283-72ea-3f200-0005a505a005a04id0로 변경되었습니다. 2004b]

문제 발생 방지 방법

이 문제는 VD/디스크를 삽입하기 전에 교체 컨트롤러의 펌웨어를 업데이트하여 방지할 수 있습니다.

자세한 단계:

1. 서버 종료

2. 모든 디스크를 하나씩 분리하고 디스크가 완전히 삽입되지 않도록 같은 슬롯을 그대로 두므로 배치 순서가 중단되지 않습니다(슬롯에서 완전히 제거되는 경우 드라이브가 동일한 슬롯에 다시 배치되어야 하므로 슬롯을 기록해 두십시오).

3. 디스크를 삽입하지 않고 교체할 새 RAID 컨트롤러를 설치합니다.

4. 서버에서 새 RAID 컨트롤러를 인식합니다.

5. RAID 컨트롤러의 펌웨어를 업데이트합니다.

6. 펌웨어 업그레이드 후 서버의 전원을 끄고 서버에 디스크를 넣으십시오.

7. 서버 전원 켜기

서버에서 이 문제가 발생한 경우 복구하는 방법

자세한 단계:

=================

데이터 저장소를 복원하는 절차

=================

1 vSphere Client에 로그인하고 인벤토리 패널에서 서버를 선택합니다.

2 구성 탭을 클릭하고 하드웨어 패널에서 스토리지 를 클릭합니다.

3 스토리지 추가를 클릭합니다.

4 디스크/LUN 스토리지 유형을 선택하고 다음 을 클릭합니다.

5 LUN 목록에서 VMFS Label(VMFS 레이블) 열에 데이터 저장소 이름이 표시된 LUN을 선택하고 Next(다음)를 클릭합니다.

메모:VMFS 레이블 열에 있는 이름은 LUN이 기존 VMFS 데이터 저장소의 복제본을 포함하는 복제본임을 나타냅니다.

6 마운트 옵션 아래에서 다음 옵션이 표시됩니다.

기존 서명 유지:LUN을 영구적으로 마운트(예: 재부팅 시 LUN 마운트)

새 서명 할당:LUN 재서명

디스크 포맷:LUN 다시 포맷

참고: 디스크 포맷LUN의 기존 데이터를 삭제합니다.재서명을 시도하기 전에 다른 호스트에서 해당 VMFS 볼륨에서 실행 중인 가상 시스템이 없는지 확인합니다. 가상 시스템은 vCenter Server 인벤토리에서 유효하지 않게 되고 해당 호스트에 다시 등록됩니다.

Assign a New Signature(새 서명 할당)를 선택하고 Next(다음)를 클릭합니다.

7 볼륨에 대해 원하는 옵션을 선택합니다.

8 Ready to Complete(완료 준비) 페이지에서 데이터 저장소 컨피그레이션 정보를 검토하고 Finish(마침)를 클릭합니다.

=================

다음 작업

====================

사임 후 다음을 수행해야 할 수도 있습니다.

1 vSphere 클라이언트에 로그인 ,UInventory List(인벤토리 목록) > Datastore(데이터 저장소)를 클릭합니다.

2 데이터 저장소를 마우스 오른쪽 버튼으로 클릭하고 "Browse Datastore"를 클릭합니다.

3 왼쪽 창에서 VM 폴더를 클릭하여 오른쪽 창에 내용을 표시합니다.

4 오른쪽 창에서 .vmx 파일을 마우스 오른쪽 버튼으로 클릭하고 "Add to Inventory(인벤토리에 추가)"를 선택합니다.

5 ESXi 호스트에 VM 추가를 완료하려면 "인벤토리에 추가" 마법사 연습

6 나머지 모든 VM에 대해 단계를 반복합니다.

7 모든 VM을 다시 등록했으면 각 VM을 마우스 오른쪽 버튼으로 클릭하고 "Remove from Inventory(인벤토리에서 제거)"를 선택하여 인벤토리에서 액세스할 수 없는 모든 VM을 제거합니다.

각 VM의 전원을 켜서 작동 및 액세스 가능한지 확인

참고:VM의 전원을 켜기 전에 ESXi 호스트를 재부팅하고, ESXi 호스트가 다시 온라인 상태가 되어 vSphere 클라이언트를 통해 액세스할 수 있게 된 후 VM이 여전히 표시되고 "액세스할 수 없음" 상태가 아닌지 확인합니다.

관련 버그: CSCvr11972

CSCvr11972 MRAID12G 교체 후 공급업체 고유 식별자가 변경되었습니다.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr11972