Nutanix 노드 이미징 에러: NVMe RAID 컨트롤러 인식 실패 트러블슈팅

오늘은 노드 이미징 과정에 발생한 이슈에 대해 한번 이야기 해보도록 하겠습니다. 

얼마 전 고객사에서 신규 클러스터 구축을 위해 노드 이미징 작업을 하다가 식은땀이 쫙 흐르는 상황을 겪었어요. 평소처럼 매끄럽게 넘어가야 할 파운데이션(Foundation) 프로세스가 갑자기 붉은색 에러를 뱉으며 멈춰버린 거죠. 에러 로그를 뒤져보니 Exception: This node is expected to have exactly 1 NVMe RAID controller 라고 명확하게 찍혀 있었습니다.

하이퍼바이저 부팅 디스크를 담고 있는 핵심 장치인 NVMe RAID 컨트롤러를 피닉스(Phoenix) 환경이 전혀 찾지 못하고 있었습니다. 뉴타닉스(Nutanix) 환경에서 CVM과 AHV가 올라가야 할 집이 통째로 증발한 셈이죠. 현장에서 이런 로그를 만나면 정말 앞이 깜깜해지시죠? 오늘은 이 문제를 어떻게 빠르고 정확하게 트러블슈팅 하는지, 제 삽질과 현장 경험을 꾹꾹 눌러 담아 정리해 드릴게요.

왜 피닉스(Phoenix) 쉘부터 뒤져야 할까?

파운데이션 로그에서 저런 끔찍한 에러가 터졌다면 가장 먼저 해야 할 일은 정말로 장치가 안 올라오는지 팩트 체크를 해야 합니다. 소프트웨어 꼬임인지 물리적 하드웨어의 죽음인지 확실히 경계를 그어야 하거든요. 노드가 아직 피닉스 환경에 머물러 있다면, 고민하지 말고 바로 콘솔을 열고 아래 명령어를 입력해 보세요.

[root@phoenix ~]# lspci | grep -i marvell

단순해 보이는 이 한 줄의 명령어가 사실 트러블슈팅의 방향을 완벽하게 결정짓는 핵심 키입니다. lspci는 리눅스 커널이 PCI 버스를 통해 물리적으로 어떤 하드웨어들을 물고 있는지 밑바닥부터 샅샅이 스캔해서 보여주는 아주 강력한 도구예요. 여기에 파이프(|)를 연결해서 수많은 결과값 중 대소문자 구분 없이 우리가 원하는 특정 문자열만 쏙 골라내 주는 grep -i 옵션을 붙인 구조입니다. 단순히 소프트웨어가 안 띄워주는 건지, 아니면 메인보드 단에서 하드웨어 자체를 아예 밀어내고 있는지 이 명령어 하나로 1차 판독이 끝나는 셈이죠.

우리가 여기서 눈에 불을 켜고 찾는 건 바로 마벨(Marvell) 컨트롤러입니다. 시스템에 정상적으로 붙어서 숨을 쉬고 있는 녀석이라면 터미널 창에 Non-Volatile memory controller: Marvell Technology Group Ltd. 88NR2241 같은 결과가 딱 튀어나와야 해요. 아무리 엔터를 쳐도 아무런 결과가 나오지 않고 빈 줄만 껌뻑인다면? 운영체제 레벨에서 하드웨어 자체를 아예 인지조차 못하고 있다는 확실한 증거입니다.

IPMI와 BIOS 크로스 체크: 너 진짜 죽었니?

터미널에서 아무것도 못 찾았다고 냅다 부품부터 주문하긴 이릅니다. 장비 관리의 기본은 언제나 OOB(Out of Band) 매니지먼트, 바로 IPMI 접속이죠. 웹 브라우저를 열고 IPMI GUI에 로그인한 다음, 좌측 메뉴에서 System > Storage Monitoring으로 진입해 보세요. 

1) 잘못된 노드 예시

2) 잘못된 노드 예시

건강한 노드라면 브로드컴(Broadcom) 항목 바로 밑에 마벨(Marvell) 항목이 당당하게 자리 잡고 있어야 합니다. 여기서도 마벨의 흔적이 없다면 하드웨어 인식 불량을 강하게 확신할 수 있어요.

가끔 IPMI 모듈이 시스템 상태 갱신을 한 박자 늦게 처리하는 경우도 있습니다. BMC(Baseboard Management Controller) 칩셋 특성상 캐시가 꼬이거나 웹 세션이 지연되면서, 죽은 장비가 살아있는 것처럼 혹은 반대로 표시되는 고스트 현상이 종종 생기거든요. 그럴 때는 시스템을 재부팅하면서 DEL 키를 연타해 BIOS로 직접 진입하세요. Advanced 탭에 있는 Manage NVMe Controller Configuration 메뉴나 Marvell NVMe Configuration Utility를 눈으로 직접 훑어보는 겁니다. 이것도 현장에서 제가 아주 유용하게 써먹는 확실한 더블 체크 방법이에요.

BIOS를 통해 확인 과정

"뺐다 꽂아보셨어요?" 가장 확실한 물리적 처방전

현장에서 수많은 서버 장비 장애를 몸으로 때우며 뼛속 깊이 새긴 진리가 하나 있어요. 뺐다 꽂으면 절반 이상은 귀신같이 살아난다는 겁니다.

1. 잔류 전원 완벽 차단 (파워 드레인)
   단순히 운영체제 리부팅(Warm Boot)만 하지 마시고 전원 케이블을 아예 쑥 뽑아버리는 콜드 부트(Cold Boot)를 하셔야 해요. 멀티 노드 섀시를 쓰고 계신다면 깡통에서 해당 노드만 쑥 뽑아두면 됩니다. 그리고 한 5분 정도 커피 한 잔 마시면서 여유롭게 기다려 주세요. 메인보드 커패시터 곳곳에 남아 장치를 멍청하게 만들고 있는 미세한 잔류 전원(Flea Power)을 완전히 날려버리기 위한 필수 작업입니다. 생각보다 이 5분의 기다림이 하드웨어 트러블슈팅에서는 마법을 부릴 때가 많습니다.
2. 라이저 카드 물리적 재장착 (Reseat)
   전원을 빼고 기다려도 답이 없다면, 이제 십자드라이버를 쥘 시간입니다. 아, 뚜껑 열기 전에 무조건 랙 서버의 금속 부분을 만져서 접지하거나 정전기 방지 팔찌(ESD 스트랩) 착용하는 거 절대 잊지 마세요. 겨울철 건조한 IDC 센터에서는 손끝에서 튀는 미세한 정전기 한 방에 수백만 원짜리 NVMe 디스크가 그대로 즉사하는 참사가 벌어지기도 하거든요. 노드 뚜껑을 조심스럽게 열고 M.2 라이저 카드와 그 안에 꽂힌 2개의 M.2 디스크들을 완전히 분리하세요. 에어건으로 슬롯 먼지를 한 번 털어주고, 핀 배열에 맞춰 딸깍 소리가 나도록 꽉 다시 꽂아주세요. 서버 진동이나 해외 배송 과정에서 미세하게 틀어진 물리적 접촉 불량일 확률이 현장에서는 무척 높습니다.

💡"공식 문서에는 없는 현장 꿀팁" 헛고생 막는 교차 검증법

이런 눈물겨운 물리적 조치를 다 거치고 다시 켰는데도 BIOS나 IPMI에서 감감무소식이다? 이때는 정말 벤더사에 케이스를 열고 파트 교체를 청구해야 합니다. 여기서 엔지니어의 퇴근 시간을 앞당겨주는 꿀팁 하나 방출할게요.

바로 옆에 세팅 전인 동일 모델의 싱싱한 깡통 노드가 있다면, 문제의 컨트롤러를 통째로 떼서 정상 노드에 한 번 꽂아보세요. 무작정 파운데이션을 다시 돌리며 한두 시간씩 멍하니 시간 낭비할 필요도 없습니다. 단순히 IPMI나 BIOS 진입만으로 10분 만에 불량 포인트를 콕 집어낼 수 있어요.

• 컨트롤러가 정상 노드에서도 안 보인다: 범인 검거 완료. M.2 라이저 카드 자체가 죽은 겁니다. 당당하게 컨트롤러 파트 교체를 요청하세요.
• 정상 노드에서는 잘 보인다: 컨트롤러는 억울합니다. 기존 노드의 메인보드 슬롯이나 PCIe 버스가 죽은 거예요. 이럴 땐 노드나 섀시 베이스보드 전체 교체를 요청하셔야 두 번 일 안 합니다.

 

트러블슈팅 단계별 핵심 요약

장애 현장에서 당황하면 뻔히 알던 리눅스 명령어도 까먹기 마련이죠. 긴급한 상황에 스마트폰으로 쓱 띄워놓고 보시라고 핵심만 표로 정리해 뒀어요. 짜잔~

트러블슈팅 단계	확인 방법 및 위치	기대하는 정상 상태	장애 지속 시 다음 조치
1단계: OS 인식 확인	Phoenix 쉘 콘솔 (lspci 명령어)	Marvell 88NR2241 문구 출력	IPMI 및 BIOS 상태 크로스 체크
2단계: 하드웨어 체크	IPMI GUI (Storage Monitoring 탭)	Broadcom 하위에 Marvell 표시	전원 완전 차단(콜드 부트) 후 5분 대기
3단계: 물리적 재결합	서버 섀시 내부 M.2 라이저 카드	슬롯 핀에 이격 없이 완벽히 결착	여분 정상 노드에 꽂아보는 교차 검증

오늘도 새로운 장애를 만나 해결하는 과정을 정리해 보았습니다. 조금이나마 많은 분들에게 도움이 되었으면 합니다.