현장 상황: EOS 뜬 클러스터, 그리고 멈춰버린 30%의 늪
얼마 전 고객사 사이트에서 EOS(End of Support) 만료가 임박한 클러스터 업그레이드 작업을 진행했습니다. 사전 필수 작업으로 PCVM(Prism Central VM) 업그레이드를 먼저 태웠죠. 무난하게 넘어갈 줄 알았던 프로세스가 정확히 30% 구간에서 숨을 거두듯 멈춰버렸습니다. 로그를 뒤져봐도 마땅한 우회로가 보이지 않는 답답한 상황이었습니다. 현장에서 땀 흘려본 엔지니어라면 이럴 때 빠른 결단이 필요하다는 걸 알 겁니다.
"클러스터 업그레이드 중 PCVM이 30% 구간에서 영문 없이 멈췄다면, 의미 없는 로그 분석으로 밤새지 말고 과감히 PC를 날려버리는 게 정신 건강에 이롭다."
현장 선배들이 입버릇처럼 하던 말이죠. 고민 끝에 꼬여버린 PC를 과감히 삭제하고 완전 재구성을 타는 승부수를 던졌습니다. 인터넷이 열린 환경이라면 바로 배포 버튼을 눌러 새 생명을 불어넣으면 되니까요. 하지만 진짜 문제는 새 PC를 올린 뒤, 기존 PE(Prism Element)를 갖다 붙이려고 할 때 터져 나왔습니다. 껍데기만 날아갔지, 두 시스템은 서로를 놓아주지 않고 있었거든요.
 |
| 업그레이드 실패한 PCVM |
트러블슈팅 1단계: 껍데기뿐인 기존 연결 고리 끊어내기
PE를 새로운 PC에 붙이려면 이전에 맺어둔 등록 정보부터 깔끔하게 날려야 합니다. 그저 UI에서 삭제 버튼을 누르는 것으로는 턱없이 부족하죠. 작업을 시작하기 전, 다음 두 가지 상태를 먼저 체크해야 헛수고를 줄일 수 있습니다.
- PC와 PE 간 통신 포트(9440) 방화벽이 여전히 열려있는가?
- PE CVM의 메모리나 CPU가 비정상적으로 튀고 있지 않은가?
위 조건이 충족되었다면 PE CVM에 SSH로 직접 뚫고 들어가서 쉘(Shell) 레벨에서 강제 해제 명령을 밀어 넣는 게 정석적인 첫 단추입니다. 아래 명령어는 기존 PC의 IP와 어드민 계정 정보를 인자로 받아 강제로 연결 고리를 끊어내는 역할을 수행합니다.
ncli multicluster remove-from-multicluster external-ip-address-or-svm-ips=<PCVM IP> username=admin password=<PC_비밀번호> force=true
이 명령어를 칠 때 주니어 엔지니어들이 정말 많이 하는 치명적인 실수가 하나 있습니다. 바로 패스워드 특수문자 파싱 문제입니다. 지정된 비밀번호 안에 샵(#)이나 달러($) 기호가 포함되어 있다면 리눅스 쉘이 이를 엉뚱한 환경 변수로 착각해버립니다. 명령어 실행 시 비밀번호 전체를 반드시 큰따옴표(" ")로 묶어주어야 안전하게 값이 넘어갑니다.
1-1. 통신 단절 시: 우회 타격으로 내부 DB만 삭제
그런데 현장에서는 항상 변수가 터집니다. 만약 이미 통신이 아예 끊어져서 위
명령어조차 먹히지 않고 타임아웃을 뱉는다면 어떻게 할까요? 무리하게 재시도하며
시간을 버릴 필요 없습니다. 이때는 PE 내부 DB에 억지로 남아있는 등록 정보만
직접 타격해서 지워야 합니다. 이를 위해 ncli 유틸리티를 사용하여
클러스터 UUID 기반으로 상태 값을 날려버리는 우회 타격을 진행합니다.
ncli multicluster delete-cluster-state cluster-id=<PC_CLUSTER_UUID>
통신 에러가 났을 때 PE 내부의 데이터베이스 맵핑 정보만 강제로 삭제하는
명령어입니다. 여기서 요구하는 PC의 UUID 값은 해당 PCVM 콘솔에서
ncli cluster info를 치면 바로 확인하실 수 있습니다. 1차적인 연을
끊어낸 셈이죠.
1-2. 양방향 클렌징: PC VM에서 PE 흔적 지우기
PE에서 PC 정보를 지웠다면, 반대로 PC 명부에서도 PE의 흔적을 지워줘야 논리적인 양방향 연결 고리가 완전히 끊어집니다. 한쪽만 지우면 나중에 좀비 프로세스처럼 오류를 뿜어내며 동기화 실패를 일으킵니다. PC VM 쉘에 접속해서 동일하게 UUID만 싹 바꿔서 아래 명령어를 날려주세요. 이게 기본 클렌징 작업의 마무리입니다.
ncli multicluster delete-cluster-state cluster-id=<PE_Cluster_UUID>
이제 PC 명부에 남아있던 낡은 PE 클러스터 정보가 논리적으로 제거되었습니다. 표면적인 서류 정리는 끝난 셈입니다.
공식 문서에는 없는 OOO 꿀팁: 메타데이터 잔적 청소법
현장에서는 DB 상태값만 지웠다고 안심하면 큰코다칩니다. 눈에 보이지 않는 메타데이터 잔적들이 시스템 깊숙한 곳에 거머리처럼 붙어있기 때문이죠. UI 상에서는 지워진 것처럼 보여도 백그라운드 데몬들은 여전히 과거의 연결을 기억하고 있습니다. 이럴 때 Nutanix 엔지니어들이 몰래 숨겨둔 파이썬 클린업 스크립트를 꺼내 들 시간입니다. 이 녀석은 단순한 상태값 변경을 넘어 깊숙이 박힌 클러스터 메타데이터 찌꺼기를 도려내는 수술용 메스 같은 역할을 합니다.
python /home/nutanix/bin/unregistration_cleanup.py <PE_Cluster_UUID>
한쪽에서만 스크립트를 돌리면 반쪽짜리 수술이 됩니다. 반드시 PE와 PC 양쪽 CVM에 각각 붙어서, 서로의 UUID를 타겟으로 스크립트를 두 번 실행해 주어야 합니다. 한 치의 찌꺼기도 남기지 않겠다는 생각으로 작업하세요. 양방향으로 싹 밀어버리는 게 핵심입니다.
원인 분석: 대체 왜 멀쩡한 클러스터가 블랙리스트에 올랐을까?
양쪽에서 스크립트 청소까지 다 하고 부푼 마음으로 재연결을 눌렀는데 화면에 "The cluster is blacklisted on prism central" 이라는 붉은 글씨가 뜨면 멘탈이 나갑니다. 잘못한 게 없는데 블랙리스트라니 억울할 수 있죠. 이유는 PC 2024.1 (AOS 6.8 이상) 버전부터 적용된 깐깐한 Decommission(폐기) 정책에 있습니다.
| 기존 방식 (단순 삭제) | 최신 버전 정책 (블랙리스트화) |
|---|---|
| DB의 단순 맵핑 데이터만 지움. 언제든 재등록 가능. | 보안 인증(Trust) 레이어에서 해당 UUID를 '위험군'으로 박아버림. |
| 명령어 실행 후 UI에서 바로 연결 성공. | 명시적으로 Zookeeper 단의 블랙리스트를 제거하기 전까지 재등록 무조건 거부. |
Nutanix 입장에서는 보안을 위해 고아(Orphan) 상태가 된 클러스터를 쳐내는 게
맞습니다. cleanup_only=true 옵션을 주더라도 신뢰성 레이어에서는
이 녀석을 스텔스나 악성 노드로 오해하고 차단 명단에 올려버립니다. 우리가 이
오해를 직접 주키퍼(Zookeeper) 밑바닥까지 내려가서 풀어줘야만 지긋지긋한 에러가
종료됩니다. 참, 복작하네요 에휴.
트러블슈팅 2단계: Zookeeper(주키퍼)로 블랙리스트 강제 철거하기
이제 진짜 밑바닥 작업입니다. 주키퍼 노드를 직접 건드려 차단 명단을 찢어버릴
겁니다. 주키퍼는 클러스터의 두뇌 역할을 하는 분산 코디네이터입니다. 이곳에
찌꺼기가 남아있으면 아무리 겉에서 재등록을 시도해봐야 헛수고입니다. 먼저 PE
CVM 쉘에 붙으세요. 주의할 점은 PE와 PC의 블랙리스트 저장 경로 이름이 미묘하게
다르다는 겁니다. PE는 blacklisted 이고, PC는
blacklist 입니다. 이 오타 하나 때문에 30분을 허비하는 주니어들을
정말 많이 봤습니다.
zkcat /appliance/physical/blacklisted | strings
zkrm /appliance/physical/blacklisted
zkcat 명령어를 때려보면 뭔가 텍스트가 와르르 쏟아지거나 Nodata
값이 보일 겁니다. 이게 바로 재등록을 막고 있던 족쇄입니다. 망설이지 말고
zkrm 명령어로 해당 경로의 노드 자체를 날려버리세요. 삭제 후 다시
zkcat을 쳤을 때 "Zookeeper error: no node"라는 에러 메시지가
나와야 완벽하게 삭제된 겁니다. 이 화면에서 노드가 없다고 뜨는 게 정상입니다.
2-1. PCVM 주키퍼 블랙리스트 명단 삭제
PE 쪽 족쇄를 풀었다면 이제 PCVM으로 넘어와서 동일하게 작업할 차례입니다. PCVM
쉘에서 아래의 zkcat 명령어를 쳐보면 아까 우리가 애타게 지우려
했던 PE의 UUID가 보일 겁니다. 게다가 친절하게도
AOS_DECOMMISION 사유로 박제되어 있는 게 두 눈으로 확인되죠.
정확히 범인을 찾은 겁니다. 망설이지 말고 zkrm으로 이 명단도
시원하게 날려버리세요. 주키퍼 데이터를 건드리는 것은 OS의 심장을 만지는 것과
같으니 오타가 나지 않도록 심호흡 한 번 하고 엔터를 치시기 바랍니다.
nutanix@NTNX-PCVM:~$ zkcat /appliance/physical/blacklist
[ {
"clusterUuid" : "000443be-305f-233a4-0000-00000000a242",
"unregistrationCause" : "AOS_DECOMMISION"
} ]
zkrm /appliance/physical/blacklist
이것으로 PE와 PC 양쪽 심장부에 박혀있던 블랙리스트 기록을 완벽하게 소각했습니다. 이제 연결을 방해하는 논리적인 장애물은 모두 사라졌습니다.
※ 해당 명령어는 상황에 따라 달라질 수 있으니, 적절한 절차를 수행 하시기 바라며, 공식적으로 지원하는 명령어가 아님을 밝히며, 재설치를 수행하거나 Poc를 진행하는 장비에만 사용하시기 바랍니다.
실무에서 주의할 점: 제네시스(Genesis) 서비스 재시작 타이밍
블랙리스트 명단을 다 태웠다고 신나서 바로 UI에서 연결 버튼을 누르면 절대 안 붙습니다. 램(RAM)에 상주하고 있는 데몬들은 아직 주키퍼 명단이 지워진 걸 모르고 있거든요. 서비스를 살짝 껐다 켜서 뇌를 비워주는 리프레시 작업이 필수입니다. CVM 한 대에서 아래 명령어를 쳐서 Prism 관련 프로세스(제네시스)를 재시작해 줍니다. 전체 클러스터가 셧다운되는 게 아니니 운영 중인 환경이라도 안심하고 실행해도 됩니다.
genesis stop prism; cluster start
명령어를 쳤다고 바로 작업 창을 열지 마세요.
"데몬을 재시작했다면 담배 한 대 피우거나 커피 한 잔 마시면서 딱 5분만 기다려라."
클러스터 백그라운드 서비스들이 모두 안정적으로 구동되고 포트 통신(9440 등)이 정상화되는 데 필요한 최소한의 물리적 시간입니다. 5분 뒤 PC UI에서 재등록을 시도해보면, 언제 에러를 뱉었냐는 듯 부드럽게 붙어가는 진행률 바를 보실 수 있을 겁니다. 이렇게 해서 죽어가던 현장을 살려내고 퇴근에 성공했습니다.
저의 경험 상 PCVM는 2202.xx 버전에는 업그레이드 버그가 많으니 삭제 후 재설치 구성이 더 빨랐다는 걸 알려 드립니다. 상황에 따라 적절한 방법을 선택하여 진행해 보세요.
0 댓글