갑자기 떨어진 VM 전원, 그리고 끝없는 부팅 실패의 늪
최근 고객사 인프라 점검 작업을 하다가 정말 등골이 서늘해지는 경험을 했습니다. 멀쩡하게 잘 돌고 있던 AHV 가상 머신(VM)에 볼륨 그룹(VG)을 직접 연결(Direct Attach)하는 작업을 걸었을 뿐인데, 1분도 채 지나지 않아 약 55초 만에 켜져 있던 VM이 픽 하고 예기치 않게 종료되어 버렸습니다.
황급히 다시 전원을 올려봤지만 OS 부팅은커녕 야속한 화면만 뿜어내더군요. ㅎ
 |
| 예기치 않은 부팅 |
보통 부팅 영역이 깨졌을 때 흔히 보는 이 화면이 떴을 때, 처음엔 단순한 윈도우나 리눅스 부트스트랩 꼬임인 줄 알았습니다. 하지만 자세히 보시면 아시겠지만 이건 디스크 자체를 아예 마운트하지 못해서 BIOS단에서 멈춰버린 증상입니다. 당황해서 Prism 콘솔의 작업 창을 뚫어지게 쳐다보니 'Restore VM Locality' 태스크만 쉴 새 없이 빙글빙글 돌면서 시스템이 혼자 발버둥을 치고 있더라고요. 식은땀을 닦으며 본격적인 트러블슈팅에 들어갔고 파고들어 보니 이건 단순한 OS 단의 오류가 아니었습니다.
범인은 누구? PC와 PE의 기묘한 엇박자
현장 상황을 하나씩 조각내어 복기해 봤습니다. 이번 셧다운 장애의 핵심 트리거는 바로 'Prism Central(PC)과 Prism Element(PE) 간의 로드 밸런스 설정 충돌'에 있었습니다.
보통 재해 복구(DR) 모의 훈련을 하거나 복구 스크립트로 자동화 작업을 돌릴 때
아주 흔하게 밟게 되는 지뢰인데요. 처음에 PC에서 VG를 생성하고 로드 밸런스(Load
Balance) 기능을 켜둔 상태였습니다. 그런데 복구 테스트 스크립트가 돌아가면서 PE
클러스터 단에서
acli
명령어로 VG의
load_balance_vm_attachments
속성을 건드려버린 겁니다. 그 상태에서 엔지니어가 다시 PC UI 화면으로 넘어와
로드 밸런스 옵션을 '체크 해제'하고 VM에 붙이려고 하니 시스템 로직이 완전히
꼬여버린 거죠.
여기서 백그라운드 원리를 조금 더 깊게 들어가 볼게요. 볼륨 그룹을 붙이려 할 때, PC가 쥐고 있는 설정 정보와 밑단의 실제 vDisk가 쥐고 있는 속성 값이 다르면 스토리지 컨트롤러는 심각한 불일치로 판단해버립니다. 타겟의 로드 밸런스 속성이 중간에 바뀌어버리니 CVM(Controller VM) 입장에서는 '안전하지 않은 연결'로 간주하고 강제로 iSCSI 세션을 걷어차버리는 겁니다. 이게 정확히 VG를 붙인 지 55초 뒤에 스토리지 타임아웃이 터지면서 VM이 셧다운을 때리는 근본적인 메커니즘입니다.
Stargate 로그 분석: 원인을 잡아 끌어내기
이런 애매한 스토리지 연결 장애 상황에서는 무조건 로그를 뒤져봐야 합니다. CVM에 SSH로 접속해서 스토리지 I/O를 총괄하는 Stargate 프로세스의 속내를 들여다보기 위해 아래 명령어를 날려줍니다.
nutanix@cvm$ cssh "grep 'Not adding session since the load balance property for the target has changed' ~/data/logs/stargate.INFO" | tail
장애 원인을 정확히 짚어내려면 CVM에 들어가서 저렇게 Stargate 로그를 직접
까봐야 합니다. 위 명령어에 쓰인
cssh는 클러스터 내에 있는 모든 CVM에 동일한 명령어를 동시에 날려주는 아주 효자
같은 툴이에요. 따옴표 안의
grep
명령어는 타겟의 로드 밸런스 속성이 변경되어서 세션을 추가하지 못한다는
구체적인 에러 문구만을
stargate.INFO
로그 파일에서 샅샅이 뒤져서 뽑아냅니다. 마지막에 파이프라인으로 연결한
tail은 수없이 쏟아지는 로그 중에서도 가장 최근에 발생한 핵심 로그 10줄만 깔끔하게
추려내서 보여주기 때문에, 1분 1초가 급박한 장애 상황에서 터미널 화면 스크롤
압박을 확 줄여주는 필수 파라미터라고 보시면 됩니다. 이 명령어를 때렸을 때 저
에러 메시지가 시간대별로 주르륵 올라온다면 시간을 끌 필요 없이 PC와 PE 간의 VG
설정이 엇갈린 그 징글징글한 버그라고 확신하시면 됩니다.
실무에서 주의할 점: 꼬인 매듭은 무조건 PC UI에서 푼다
문제를 눈으로 확인했으니 당장 서비스를 살려내야죠. 밑단의 vDisk 속성이 이미 꼬여버린 상태이기 때문에 터미널에서 acli로 억지로 뭘 더 쑤셔보려고 하면 시스템을 더 깊은 구렁텅이에 빠뜨리기 십상입니다. 가장 빠르고 확실한 워크어라운드(Workaround)는 Prism Central UI를 통해 로드 밸런싱 설정을 아주 깨끗하게 한 번 덮어씌워 주는 겁니다.
| 복구 단계 | 상세 작업 내용 (Prism Central UI 기준) |
|---|---|
| 1단계: 식별 및 업데이트 | 인프라 > 볼륨 그룹 메뉴로 이동하여 문제의 VM에 붙였던 VG를 찾아 'Update'를 누릅니다. |
| 2단계: 연결 완전 해제 | 'Connect Clients' 단계에서 현재 연결된 VM들을 모두 분리(Detach)한 후 업데이트 과정을 끝까지 완료합니다. |
| 3단계: 옵션 강제 재적용 | 다시 해당 VG의 'Update'로 들어갑니다. VM을 선택하고, 이번에는 'Load Balance Volume Group' 옵션을 반드시 체크한 채로 연결합니다. |
| 4단계: 부팅 확인 | 설정을 저장한 뒤 VM의 전원을 켜서 정상적으로 OS가 올라오는지 모니터링합니다. |
 |
| Load Balance Volume Group 활성화 |
글로만 보면 헷갈릴 수 있는데, 위 화면처럼 3단계에서 반드시 'Load Balance Volume Group' 옵션을 명시적으로 체크해 주셔야 합니다. 이렇게 해야 PC가 하위 PE 클러스터로 최신 설정값을 강제 푸시하면서 꼬여있던 vDisk 속성을 덮어버리거든요. 2단계에서 기존 VM들을 먼저 한 번 완전히 떼어내는(Detach) 과정도 절대 생략하시면 안 됩니다. 기존에 남아있던 좀비 같은 세션 정보를 메모리에서 완전히 날려버린 뒤에 새롭게 iSCSI 세션을 맺어줘야 충돌이 발생하지 않기 때문입니다.
💡 실무 꿀팁
현장에서 DR 스크립트를 짜다 보면 나도 모르게 PE의 acli 명령어와 PC의 REST API를 기분 내키는 대로 섞어 쓰는 경우가 정말 많습니다. 적어도 볼륨 그룹의 로드 밸런싱 설정만큼은 무조건 제어 주체를 하나로 꽉 묶어서 통일하세요. PC 환경에서 관리하기로 마음먹었다면 자동화 스크립트에서도 가급적 PC API를 호출하도록 구조를 잡아야 나중에 새벽에 알람 받고 깨는 일이 없습니다.
픽스 패치를 기다리며
제가 현장에서 확인한 바로는 이 무시무시한 이슈는 PC 7.3.x, AOS 7.x 및 6.10.x 버전대에서 꽤 광범위하게 나타나고 있습니다. 다행히 뉴타닉스 본사 엔지니어링 팀에서도 이 버그를 인지하고 KB-20280으로 등록해 둔 상태이며, 조만간 릴리즈될 마이너 버전에서 근본적인 패치가 될 예정이라고 하네요. 패치가 올라오기 전까지는 오늘 제가 알려드린 UI 우회 방법을 잘 숙지하고 계시면 혹시 모를 비슷한 셧다운 장애콜이 떨어졌을 때 당황하지 않고 5분 컷으로 멋지게 해결하실 수 있을 겁니다.
항상 대비를 하고 있지만, 유독 Nutanix는 버그가 많은것 같습니다. 소프트웨어 기반의 솔루션들의 특징이라고 할까요? 그래도 버그를 꾸준히 잡아준다는 점은 지속적인 관리가 되다는 뜻이니 긍정적으로 볼수 있겠죠? 아무튼 오늘 이야기는 여기서 마무리 하고 엔지니어분들에게 조금이나마 도움이 되었으면 합니다.
0 댓글