스위치 죽었다 살아났는데, 왜 VM 콘솔이 회색이지? (피 말리는 0%)
이전 작업 중 네트워크 스위치가 잠깐 죽었다가 올라왔다. 솔직히 말해서 스위치 하나 내려간 것쯤이야 클러스터 전반에 한바탕 폭풍이 지나가더라도 HA나 자체 복구 메커니즘 덕분에 당연히 서비스들이 알아서 원래 자리로 찾아가며 완벽하게 복구될 줄 알았어. 그런데 엄청난 착각이었지.. 완전 오만이었어.
Prism Element(PE)에 접속해 보니 VM에 IP는 예쁘게 떠 있는데 막상 핑을
때려보면 단 한 개도 안 나가는, 관리자 속이 시커맣게 타들어가는 상황이 눈앞에
펼쳐졌지. 더 환장하는 건 콘솔이라도 띄워서 OS 내부 상태를 보고 싶은데
'Launch Console' 버튼이 마치 비웃기라도 하듯 얄미운 회색으로 떡하니
비활성화되어 마우스 클릭조차 먹히지 않는다는 거다. 지푸라기라도 잡는
심정으로 브릿지 설정을 건드려보려 하니 'Inconsistent Virtual Switch State
Detected'라는 섬뜩한 에러를 확인할 수 있었어.
혹시나 해서 Prism Central로 넘어가 이미지 생성이나 VM 상태 변경 같은 기본
연동 작업을 시도해 봤지만 진행률은 0%에서 멈춘 채 요지부동인데, 그냥
클러스터 관리 기능 전체가 마비된 거다. 진짜 눈앞이 캄캄해졌여. 떨리는 손을 부여잡고 CVM에 접속해서 상태를 봤다. 제발 살아있어 달라고 빌면서
명령어
acli host.list를 쳤는데 돌아오는 건 평소의 깔끔한 노드 리스트가 아니라 절망적인
텍스트인거야. "Failed to connect to server: [Errno 111] Connection refused "
혹은 노드 리스트가 나오긴 하는데 Node state가 죄다 False로 찍혀
있다. 우리 클러스터의 핵심 중의 핵심인 아크로폴리스(Acropolis) 서비스가
완전히 맛이 간 상태를 똑똑히 보게된 거지. 범인은 로그 안에 있다: 무지성 재부팅 멈추고 CVM부터 뒤져보자
초보 관리자들이 가장 많이 하는 실수가 이럴 때 무작정 CVM 재부팅 버튼부터 누르고 보는데, 절대 안 된다. 일단 모든 CVM에 접속해서 아크로폴리스 로그 밑바닥부터 박박 긁어서 뒤져야 해.
AOS 6.8.x나 6.10.x 버전을 쓰고 있다면 지금 당장 터미널에 이 명령어를 바로
때려보자.
allssh 'grep -w CRITICAL /home/nutanix/data/logs/acropolis.out'
수백 줄의 로그가 촤르륵 올라가다가 만약 아래 두 가지 케이스 중 하나라도
붉은색으로 찍혀 나온다면, 축하한다. 당첨이다.
Case 1:
CRITICAL memory_model_manager.py:185 X > Y failed
Case 2:
CRITICAL memory_model_manager.py:83 2 == 1 failed
이게 대체 무슨 귀신 씻나락 까먹는 상황이냐고? 여러 노드의 서비스가 한 번에
셧다운됐다가 다시 올라오는 그 아수라장 같은 과정에서, 아크로폴리스 서비스가
기존에 가지고 있던 'memory_model_manager' 데이터를 완전히 잘못 읽어 들인
거다. 데이터 싱크가 안 맞으니 혼자서 어떻게든 살려보겠다고 발버둥 치며 예외
처리를 시도하다가 장렬하게 실패하고, 스스로 프로세스를 죽였다가 다시
살리기를 무한 반복하는 '크래시 루프(crash loop)'라는 늪에 제대로
빠져버린거야.
🚨 이 경험을 통해 알게 된 Nutanix 장애 해결 꿀팁
- 절대 혼자 해결하려고 구글링하며 시간 낭비하지 마라: 이 문제는 당신이 스택오버플로우를 뒤져서 커맨드 몇 줄로 로컬 DB를 수정할 수 있는 수준의 만만한 장애가 아니다.
- 치트키 스크립트는 철저하게 비공개다: 완벽한 해결을 위해서는
fix_mm_idf_table_v1.py라는 특수 파이썬 스크립트가 필요해. 이 스크립트는 Nutanix 고객 지원 포털이나 구글 어디를 뒤져도 절대 다운로드할 수 없다. 오직 글로벌 TAC(기술 지원) 엔지니어들의 툴박스 안에만 존재하는 은밀한 파일이지.- 케이스 오픈 시 3시간 단축 비법: SR(Support Request)을 열 때 방황하지 말고 방금 확인한
memory_model_manager.py로그 캡처본을 첨부해라. 그리고 코멘트로 "KB 18070 이슈와 동일한 증상으로 판단됩니다. 스크립트 지원 바랍니다"라고 쿨하게 적어라. 엔지니어가 상황을 파악하는 단계를 통째로 건너뛰어 복구 시간을 엄청나게 단축할 수 있다.
Nutanix 엔지니어가 와서 한 일 (허무하고도 마법 같은 10분)
Nutanix 쪽에 심각도 1(Severity 1)로 케이스를 오픈하면 곧바로 글로벌 SRE가 원격 세션으로 붙는데, 잘 들어봐 ~ 그들이 화면 너머로 들어와서 하는 작업은 우리가 겪은 맘고생에 비하면 생각보다 너무 허무할 정도로 간단해 ㅋㅋ 미리 준비해 온/home/nutanix/fix_mm_idf_table_v1.py 스크립트를 문제가
생긴 CVM 중 한 곳에 툭 던져넣고 실행한다. 진짜 그게 끝이야. 터미널에서
스크립트가 후루룩 돌아가면서 자기들끼리 꼬여버린 메모리 모델 데이터를 강제로
멱살 잡고 원래 자리로 맞춰줘.
살아났는지 확인하는 3단계 심폐소생 검증법
마법의 스크립트가 돌고 나면 혼수상태에 빠져있던 아크로폴리스 서비스가 드디어 안정을 되찾는데, 글로벌 SRE 엔지니어에게 "작업 다 됐습니다, 확인해 보세요"라는 말을 듣고 나서 그냥 넘어가면 너는 하수다!! 직접 두 눈으로 확실하게 살아났는지 검증해야 할 3가지 필수 명령어가 있어.
1. VM 컨트롤 데몬 확인:
acli host.list 단순히 리스트만 보는 게 아니야. 아까
우리를 멘붕에 빠뜨렸던 False나 Connection refused 같은 흉측한 상태값이 싹
지워지고, 모든 노드가 정상적으로 통신하고 있다는 증거인 'True' 상태로 쫙
올라와야 비로소 첫 번째 안도의 한숨을 쉴 수 있어.
2. 클러스터 전체 서비스 상태:
cs | grep -v UP 이 명령어는 클러스터 내 수많은
백그라운드 서비스 중 단 하나라도 뻗어있는 녀석이 있는지 색출해 내는 마법의
명령어야. 엔터를 쳤을 때 아무런 결과값도 출력되지 않는 그 '적막함'이 바로
모든 서비스가 정상이라는 뜻이지. 화면에 뭔가 줄줄이 나온다면 아직 지옥에서
덜 빠져나온 거다.
3. 카산드라 링 상태 체크:
nodetool -h 0 ring 뉴타닉스의 심장이라고 할 수 있는
카산드라 메타데이터 DB 노드들이 제대로 링을 구성하고 서로 통신하는지 보는
거다. 터미널 출력 결과에 'Up/Normal' 이 두 단어가 모든 노드에 빈틈없이 박혀
있어야 해. 이 세 가지 관문이 모두 클리어됐다면, 조심스럽게 Prism UI 창을
새로고침 해보자.
회색으로 죽어있던 Launch Console이 언제 그랬냐는 듯 활성화되어 있고,
묵묵부답이던 VM 네트워크가 다시 핑을 시원하게 뱉어내기 시작할 거다. 진짜
지옥 밑바닥까지 떨어졌다가 살아 돌아온 기분이이야. 오늘 밤은 발 뻗고 잘 수
있겠네. ㅋ
오늘도 무사히 업무를 마치고 집에 돌아가고 있나요? 그럼 당신은 에이쓰!
0 댓글