앗! 갑자기 고객사 VM 콘솔 화면이 먹통이 됐다고?
어제 고객사에서 작업하다가 등골이 서늘해지는 경험을 했어. Prism에서 평소처럼 잘만 열리던 VM 콘솔이 갑자기 에러를 뱉어내면서 튕기더라고. 화면에는 "Connection Error"라면서 인증서 문제거나 VM이 꺼져있을 수 있다는 뻔한 소리만 줄줄 나오는 상황이었어. 그 밑에 "Connection closed (error 1006)" 혹은 "Server disconnected (error 1006)" 메시지가 딱 뜨는데 진짜 당황스럽더라. 초보 엔지니어 시절에는 이런 화면 보면 덜컥 겁부터 먹고 무작정 VM부터 껐다 켜보려고 하잖아. 절대 그러면 안 돼. 시스템이 뱉어내는 에러 코드에는 다 숨겨진 이유가 있거든. 겉보기에는 브라우저 캐시나 네트워크 방화벽 문제 같지만 이럴 때는 서버 내부 통제 영역의 목소리를 먼저 들어봐야 해.
로그부터 까보자: Acropolis의 숨겨진 비명 소리 찾기
문제가 생겼을 때는 묻지도 따지지도 말고 CVM(Controller VM)으로 SSH 접속부터 하는 게 우리 엔지니어들의 기본 소양이다. Nutanix 환경에서 가상화를 담당하는 핵심 서비스가 Acropolis인데 이 녀석이 제대로 돌고 있는지 확인하는 게 최우선이야. 에러가 발생한 VM이 올라가 있는 호스트의 CVM에 접속해서 특정 로그 파일을 뒤져보는 작업부터 시작해야 함.
 |
| Acropolis.out 로그 살펴보는 장면 |
로그를 확인하기 전에 내가 왜 이 경로를 짚어주는지 원리를 잘 들어봐. Nutanix
시스템에서 거의 모든 서비스의 활동 내역과 장애 상황은
/home/nutanix/data/logs/ 디렉터리 아래에 고스란히 쌓이게 돼.
그중에서도 우리가 지금 직면한 VNC 콘솔 접속 장애는 KVM 하이퍼바이저와 통신하며
백엔드 작업을 처리하는 Acropolis 서비스와 직결되어 있거든. 그래서 수많은 로그
파일 중에서 다른 건 다 제쳐두고 acropolis.out 파일을 콕 집어서
열어봐야 하는 거야. 명령어는 단순히 전체를 훑는 tail을 써도
되지만 지나간 과거의 장애 이력까지 정확하게 훑어보기 위해 아래처럼 리눅스
파이프라인과 grep을 곁들여서 에러 메시지만 깔끔하게 필터링해 볼
거야.
nutanix@cvm$ cat /home/nutanix/data/logs/acropolis.out | grep -i "Errno 12"
위 명령어를 쳤을 때 화면에
OSError: [Errno 12] Cannot allocate memory라는 구문이 떨어졌다면
원인을 정확히 짚은 거야. 이 명령어에서 cat은 리눅스 환경에서 파일
전체 내용을 순차적으로 읽어 들이는 역할을 하고 파이프라인 기호를 통해 그
어마어마한 텍스트 결괏값을 다음 명령어인 grep으로 넘겨주게 돼.
grep에서는 대소문자 구분 없이 유연하게 매칭하기 위해
-i 옵션을 주었고 우리가 찾고자 하는 핵심 에러 코드인
Errno 12 텍스트만 필터링해서 터미널 창에 뿌려주는 방식이지.
결과가 이렇게 나왔다는 건 Acropolis 서비스가 KVM 하이퍼바이저의 OVS 브릿지
매니저(ovs_br_manager.py)나 SSH 통신 모듈 등을 실행하려고
프로세스를 띄울 때 운영체제로부터 메모리를 할당받지 못해서 그냥 뻗어버렸다는
뜻이야. 쉽게 말해 CVM 내부의 가용 메모리가 꽉 차서 더 이상 새로운 콘솔 창을
띄워줄 시스템적 여력이 없다는 소리니까 당장 리소스부터 확보해야 한다고.
원인 분석: 도대체 메모리를 어디서 다 까먹은 걸까?
로그에서 명확한 원인을 찾았으니 이제 왜 메모리가 부족한지 파헤쳐야 할 차례야. 멀쩡하게 돌아가던 클러스터에서 갑자기 메모리 할당 에러가 난다는 건 크게 두 가지 케이스로 압축해 볼 수 있어. 현장에서는 단순히 소프트웨어 버그나 꼬임 현상이라고 단정 짓기 전에 아래의 두 가지 측면을 동시에 고려하는 시야를 가져야 해.
- 소프트웨어적 리소스 고갈: CVM 자체에 할당된 메모리가 정말 턱없이 부족할 정도로 무거운 백그라운드 작업(예: 대규모 스냅샷, 타겟 복제 등)이 돌고 있었을 확률이 있어.
- 물리적 하드웨어 불량: 램(DIMM) 자체에 장애가 생겨서 실제 OS가 사용 가능한 물리적인 메모리 공간 자체가 깎여나갔을지도 몰라.
이 두 가지 가능성을 염두에 두고 다음 스텝인 NCC 체크와 하드웨어 로그 분석으로 넘어가야 무의미한 삽질을 줄일 수 있지.
실무에서 주의할 점: 묻지마 재부팅과 NCC 체크의 중요성
초보 때 제일 많이 하는 치명적인 실수가 메모리 부족하다니까 무작정 해당 CVM을 재부팅해버리는 거야. 당장 급한 불은 끌 수 있겠지만 근본적인 메모리 누수나 하드웨어 불량 원인을 파악하지 못하면 며칠 뒤에 고객사에서 노발대발하며 또 전화 올 게 뻔해. 이럴 때는 마우스를 내려놓고 숨을 크게 한 번 쉬고 Nutanix Cluster Check, 일명 NCC부터 차분하게 돌려봐야 해.
 |
| NCC 체크 확인 모습 |
NCC 체크는 클러스터 전체의 건강 상태를 진단하는 현장 엔지니어의 가장 강력한 무기야. 하지만 묻지도 따지지도 않고 CLI 창에다 아래 명령어를 덜컥 치기 전에는 잠깐 멈추고 상황을 파악해야 해.
nutanix@cvm$ ncc health_checks run_all
이 run_all 파라미터를 붙인 전체 진단 명령어는 클러스터 내의 수백
개 스크립트를 일제히 깨워서 리소스를 엄청나게 빨아먹어. 이미 CVM이 메모리를
할당받지 못해 헐떡이는 상황에서 저 명령어를 치면 어떻게 되겠어? 완전히
시스템에 막타를 치는 꼴이 되어버릴 수 있어. 위 명령어를 실행할 때는 반드시
현재 스토리지의 IOPS 워크로드가 바닥을 기는 한가한 시간대인지 확인하는 눈치가
필수야. 정말 장애 상황이 심각해서 부하를 주면 안 될 것 같을 때는
run_all 대신 --plugin_list=hardware_info_check 같은
특정 파라미터 옵션을 덧붙여서 의심되는 하드웨어 모듈만 핀셋으로 타겟팅
점검하는 게 진짜 시니어들의 현장 노하우지. 조심스럽게 점검 스크립트가 다 돌고
나면 화면에 써머리 리포트가 쭉 출력될 텐데, 거기서 빨간색 FAIL이나 노란색
WARNING이 찍혀 있는지 눈을 부릅뜨고 찾아봐야 해.
공식 문서에는 없는 선배의 하드웨어 트러블슈팅 꿀팁
공식 지식베이스인 KB-13830 문서를 보면 단순히 NCC 체크에 실패가 없는지, DIMM ECC 에러가 없는지 보라고 짧게 나와 있잖아? 현장에서는 이 짧은 문장을 구체적인 액션 플랜으로 어떻게 해석하고 적용해야 하는지 막막할 때가 많아. 내가 실무에서 직접 구르며 터득한 점검 포인트를 표로 딱 정리해 줄 테니까 머릿속에 확실히 넣어둬.
| 점검 항목 | 현장 확인 포인트 및 대처 팁 |
|---|---|
| NCC 서비스 상태 체크 | 다른 핵심 연관 서비스(예: Cassandra, Stargate)가 메모리 부족의 여파로 같이 죽어있는지 연계해서 확인해. 메모리 누수가 특정 스토리지 서비스에서 시작되었을 가능성을 항상 열어둬야 함. |
| DIMM ECC 에러 점검 | OS 레벨의 단순 1회성 보정 에러(Correctable)인지 램 모듈 자체의 지속적인 하드웨어 불량(Uncorrectable)인지 IPMI 로그나 하드웨어 벤더(Dell, Lenovo 등)의 XCC/iDRAC 로그와 크로스 체크하는 게 필수 |
| 리소스 경합 (Resource Contention) | 장애가 발생한 특정 시간에 스냅샷 백업이나 대규모 타겟 복제 작업이 돌고 있지 않았는지 고객사의 스케줄링 현황을 꼼꼼히 파악해 보는 게 문제 해결의 열쇠가 될 수 있음. |
만약 IPMI 하드웨어 로그에서 특정 메모리 슬롯(예: CPU1 DIMM A2)의 ECC 에러가 무더기로 쏟아지고 있다면 그건 백퍼센트 물리적인 메모리 모듈 불량이야. 이럴 때는 지체 없이 해당 노드에 있는 VM들을 다른 노드로 대피시키고 유지보수 모드(Maintenance Mode)로 진입한 뒤 하드웨어 벤더에 파트 교체를 즉각 요청해야 해.
장애 대응을 마치며: 숲을 보는 엔지니어가 되자
단순히 콘솔이 안 열린다는 단편적인 증상 하나로 시작해서 CVM의 내부 메모리 할당 실패 흔적을 찾고, 최종적으로 하드웨어 불량까지 꼬리에 꼬리를 무는 논리적인 분석 과정을 겪어봤어. 트러블슈팅은 이렇게 퍼즐 조각을 하나씩 논리적으로 맞춰가는 과정이야. 앞서 알려준 필수 점검 포인트에서 명확한 에러 원인이 나오면 거기에 맞는 액션을 취하면 되고 도저히 답이 안 나오는 미궁에 빠졌다면 그때 수집된 로그 묶음을 첨부해서 Nutanix Support에 케이스를 당당하게 오픈하는 거야. 무턱대고 제조사 콜센터에 전화하기 전에 우리가 할 수 있는 기술적 분석을 다 해놓으면 엔지니어로서의 몸값과 가치도 덩달아 올라간다는 사실 잊지 마. 오늘 들려준 현장 경험이 네 성장에 단단한 밑거름이 되길 바라.
"다음 포스팅에서는 더욱 생생한 현장 트러블슈팅 사례로 찾아오겠습니다. 감사합니다."
0 댓글