펌웨어 업데이트 중 맞닥뜨린 불길한 에러 메시지
현장에서 하드웨어 유지보수를 하다 보면 언제나 변수가 도사리고 있다. 특히 Nutanix NX-G8 노드 환경에서 LCM(Life Cycle Manager)을 태워 BMC(Baseboard Management Controller) 버전을 올리는 작업은 꽤나 일상적인 업무다. 느긋하게 커피 한 잔 마시며 프로그레스 바가 올라가는 것을 지켜보고 있었다. 화면에 빨간색 엑스 표시와 함께 기분 나쁜 에러 로그가 터져 나오기 전까지는 말이다.
"Operation Failed. Reason: Update of BMCs (Redfish) failed on xx.yy.zz.190 (environment hypervisor) at stage 1 with error: [Upgrade failed, Failed to enable host interface]"
등골이 서늘해지는 화면이다. 프로그레스 바가 멈추고 에러 로그가 화면을 뒤덮는 순간, 현장에는 정적이 흐른는데, Stage 1에서부터 호스트 인터페이스를 활성화할 수 없다는 에러 텍스트를 마주하면 나의 머릿속은 하얗게 변했다. 장비가 벽돌이 된 것은 아닌지, 당장 고객사 담당자에게 뭐라고 변명해야 할지 식은땀이 흐른다. 이 에러의 핵심은 'Failed to enable host interface'라는 문장에 숨어 있다. 시스템이 업데이트 파일을 밀어 넣는 데는 성공했을지 몰라도, 업데이트 이후 새로운 펌웨어로 깨어난 BMC와 통신 채널을 다시 여는 과정에서 어긋나버린 상황이다.
IPMI는 정상인데 LCM만 실패했다고? (원인 분석)
에러 창을 닫고 무턱대고 장비의 전원 케이블을 뽑으러 달려가는 짓은 멈추고, 침착하게 현재 상황의 앞뒤가 맞는지 교차 검증을 시작해야 한다. 놀랍게도 해당 노드의 IPMI 웹페이지에 접속해 보면 화면이 버벅거리지도 않고 아주 매끄럽게 열린다. 심지어 대시보드 시스템 정보 탭에 찍혀 있는 펌웨어 버전은 방금 우리가 올리려고 했던 '08.01.09' 최신 버전으로 정상 표기되어 있을 것이다.
웹 UI가 거짓말을 하는 것일까? 상황을 명확히 파악하기 위해 현재 우리가 마주한 시스템별 인지 상태를 직관적인 표로 정리해 보았다.
| 확인 지점 | 상태 및 출력 메시지 | 실제 시스템의 의미 | 엔지니어의 판단 기준 |
|---|---|---|---|
| LCM UI | Failed to enable host interface | 정해진 시간 내 응답 없음 (타임아웃) | 소프트웨어의 타이밍 엇박자 |
| IPMI Web | 정상 접속 및 버전 08.01.09 표기 | BMC 펌웨어 업로드 및 리부팅 완료 | 하드웨어 업데이트는 정상 |
| CLI 통신 | Firmware Revision: 08.01.09 출력 | 내부 하드웨어 제어 유틸리티 정상 동작 | 장비 무결성 확보, CVM 구출 요망 |
위 표에서 보듯 시스템 간의 인지 부조화가 뚜렷하다. 터미널 창을 열어 직접 장비 깊숙한 곳의 상태를 찔러볼 차례다.
hostssh '/ipmicfg-summary | grep "BMC" -A1'
수십 대의 노드에 일일이 패스워드를 치고 들어가 버전을 확인하는 건 시간
낭비다. 클러스터 전체 노드의 펌웨어 리비전을 단번에 스캔하여 상황 파악을
끝내야 한다. 위 명령어는 hostssh라는 강력한 도구를 이용해
클러스터 내 모든 CVM(Controller VM)에 원격 접속을 시도한다. 그 후 내부
하드웨어 제어 유틸리티인 ipmicfg를 호출하여 요약 정보를
뽑아낸다. 이 방대한 텍스트의 바다에서 우리가 필요한 정보만 건져내기 위해
파이프라인(|)과 grep 명령어를 조합했다. 'BMC'라는
정확한 문자열을 찾고, -A1 옵션을 주어 매칭된 줄의 바로 아래 한
줄(버전 정보가 담긴 줄)까지 함께 화면에 뿌려주는 것이다. 결과값을 확인해
보면 업데이트가 실패했다고 징징대던 LCM의 주장과 달리 실제 하드웨어 단의
펌웨어는 완벽하게 구워져 있다.
이 기묘한 현상의 원인은 LCM 리더 CVM에 남겨진
lcm_ops.out 로그와 IPMI의 MEL(Maintenance Event Logs) 로그를
대조해 보면 명확해진다. BMC는 업데이트를 성공적으로 마치고 스스로 리셋을
돌렸다. 부팅을 완료하고 호스트 인터페이스를 짠하고 열어주기까지 약간의
딜레이가 발생했다. LCM이라는 녀석은 참을성이 부족했다. BMC가 인터페이스를
활성화하기 위해 끙끙대는 그 몇 분을 기다리지 못하고 타임아웃을 뱉어버린
것이다. 하드웨어 업데이트는 성공했지만 소프트웨어인 LCM이 타이밍을 놓쳐
오해하고 있는 전형적인 엇박자 장애다.
꼼짝 못 하는 CVM, 어떻게 구출할 것인가
오해에서 비롯된 에러라도 후폭풍은 매섭다. LCM 작업이 비정상 종료되면서 타겟이 되었던 CVM은 길을 잃고 '유지보수 모드(Maintenance Mode)'에 그대로 감금되어 버린다. 실제로 터미널에 접속해 상태를 찔러보면 참담한 결과를 마주하게 된다. 클러스터의 데이터 정합성이 깨지기 전에 이 녀석의 상태부터 확실히 눈으로 확인하자.
cs | grep -v UP
현재 클러스터의 심장 박동을 체크하고 어떤 CVM이 격리되어 있는지 직관적으로
뽑아내는 가장 깔끔한 명령어다. cs라는 짧은 단축 명령어를 던져
클러스터의 종합 상태표를 화면에 호출한다. 정상적으로 데이터 입출력을
처리하며 살아서 돌아가는 노드들은 모두 'UP'이라는 상태 값을 갖는다. 여기에
역방향 필터링인 grep -v UP을 걸어주는 센스를 발휘. 정상
노드들의 정보는 화면 출력에서 무자비하게 걸러내고 오직 문제가 있는 비정상
노드만 콘솔 창에 띄우겠다는 의도다. 이 한 줄을 날리면 눈이 빠지게 수십 줄을
읽을 필요 없이 단 1초 만에 특정 노드가 Maintenance 상태로 방치되어 있다는
사실을 잡아낼 수 있다.
노드를 구출하는 시퀀스는 정해져 있다. 먼저 노드를 유지보수 모드에서 강제로 해제해야 한다. (KB-4639 문서 참고) 만약 이 과정에서 노드가 메타데이터 링(Metadata ring)에서 튕겨져 나갔다면, CVM 서비스들이 정상적으로 올라오는 것을 확인한 직후 다시 링에 붙여주는 작업을 수행한다. (KB-9155 문서 참고) 여기까지 진행했다면 마지막 화룡점정이 남았다.
genesis restart유지보수 모드에서 노드를 억지로 빼냈더라도 클러스터 내부의 논리적인 꼬임은 아직 덜 풀린 상태다. 시스템 어딘가에는 이 노드가 여전히 종료 진행 중이라는 'Shutdown Token' HA 항목이 찌꺼기처럼 남아 있다. 이 잔재를 깔끔하게 날려버리기 위해 고립되었던 해당 CVM에 SSH로 직접 들어가 제네시스 서비스를 재시작하는 명령어다. 뒤에 거창한 파라미터나 옵션 하나 없이 단순하게 입력하지만 그 파급력은 확실하다. 이 한 줄의 실행이 클러스터 구성 요소들의 상태 값을 강제로 동기화하고 꼬여있던 인지 상태를 완벽하게 초기화해 주는 핵심 트리거 역할을 수행한다. 이 데몬이 다시 올라오면서 비로소 노드는 온전한 자유의 몸이 되는 것.
벤더사 공식 문서에는 없는 현장 실무자용 꿀팁
- 성급한 재부팅은 독이다: 펌웨어 업데이트 에러 창을 보자마자 하드웨어 장애로 오판하고 IPMI에서 강제 콜드 부트(Cold Boot)를 때리는 주니어들이 많다. 앞서 분석했듯 BMC 자체는 이미 새로운 버전으로 세팅을 끝마친 상태다. 여기서 억지로 전원을 끊어버리면 오히려 펌웨어 뱅크가 꼬이면서 진짜 메인보드를 교체해야 하는 대참사로 이어질 수 있다. 무조건 로그의 타임라인부터 교차 검증하는 습관을 들여라.
- 근본적인 원인 차단: 이 현상은 G8 노드와 구형 LCM 프레임워크가 만났을 때 발생하는 징글징글한 버그다. CVM을 정상화했다고 안심하지 마라. 다음 노드 업데이트 시 똑같은 에러를 또 뱉어낼 것이다. 노드 복구가 끝났다면 하드웨어 업데이트 메뉴를 쳐다보지도 말고, 최우선적으로 LCM 프레임워크 자체를 LCM-3.1.1 이상 버전으로 업그레이드해라. 타임아웃 대기 시간을 넉넉하게 잡아주는 패치가 적용되어 있어 이 허무한 에러를 완벽하게 회피할 수 있다.
0 댓글