야간 작업 중 Nutanix IPMI IP 변경? 이거 모르면 밤샙니다

하드웨어 관리 콘솔인 IPMI tool은  저희한테는 꼭 필요한 기능입니다. 원격작업 뿐만 아니라, 작업 및 모니터링까지  많은 정보를 전달해 줍니다.  IPMI 설정방법에 대해 알아보도록 하겠습니다. 

서버실의 귀를 찢는 듯한 팬 소음, 그리고 창백한 모니터 불빛. 야간 작업 중 데이터센터 차가운 바람 맞고 있으면 머리가 멍해지기 마련이죠. 그런데 옆에서 팔짱 낀 고객은 "언제 끝나요?"라는 눈빛을 쏘아대고 있고, IPMI IP는 당장 어떻게든 바꿔야만 합니다. Nutanix 장비 다룰 때 IPMI 설정은 단순히 빈칸에 IP 숫자 몇 개 넣는다고 끝나는 만만한 작업이 아니에요. 자칫하면 클러스터가 노드를 못 찾아서 야간 작업이 익일 오전 대형 장애 대응으로 바뀌는 대참사가 일어날 수도 있습니다.

IP만 바꾸고 퇴근? 내일 아침 전화통 불납니다

현장에서 가장 많이 하는, 진짜 소름 돋는 실수가 뭔지 아세요? 웹 인터페이스 들어가서 IP 숫자 딱딱 입력하고 'Save' 눌렀다고 홀가분하게 짐 싸는 겁니다.

저장 버튼 누르면 화면이 뱅글뱅글 돌다가 브라우저 접속이 탁 끊기죠? 그럼 우리는 무의식적으로 "오, IP가 바뀌어서 내 접속 세션이 끊겼구나. 적용 완벽하네!" 하고 착각하기 딱 좋습니다. 하지만 진짜 생명줄은 Genesis(제네시스) 재시작에 달려있어요. IPMI 하드웨어 자체의 IP는 바뀌었을지 몰라도, CVM(Controller VM)에서 돌고 있는 Genesis 프로세스가 이 사실을 모르면 클러스터는 바뀐 IPMI 주소로 영영 통신을 못 합니다. 다음 날 아침 출근길에 "노드 상태가 통신 두절로 뜹니다"라는 고객사 전화 받고 등골이 서늘해지면서 택시 돌려야 하는 거죠. 초기 구축이라면 클러스터 싹 다 체크해야 합니다.

"IP 세팅 -> 저장 완료 -> CVM SSH 접속 -> genesis restart" 이 기계적인 루틴을 손가락에 박아두세요.

상황별로 골라 쓰는 3가지 생존법 

현장 상황은 늘 우리 예상대로 예쁘게 흘러가지 않습니다. 운 좋게 방화벽 뚫려서 따뜻한 자리에 앉아 노트북으로 웹 접속할 수 있을 때가 있고, 네트워크가 죽어버려서 무거운 KVM 콘솔 카트 질질 끌고 서버 앞까지 가야 할 때도 있죠. 엔지니어라면 무기를 여러 개 들고 있어야 살아남습니다.ㅋ

• 웹 인터페이스 (가장 평화로움): 네트워크가 살아있다면 땡큐입니다. 브라우저로 접속해서 [Configuration > Network] 메뉴로 갑니다. IPv4 설정에서 수동으로 정적(Static) IP 박은 뒤 저장하면 끝. 변경되는 순간 접속 튕기는 거 잊지 마시고요.
• 명령줄(CLI) (폭풍 타이핑): 하이퍼바이저(AHV, ESXi 등)에 SSH로 붙어서 ipmitool을 휘두르는 방식입니다. ipmitool -U ADMIN -P ADMIN lan set 1 ipaddr [IP주소]. 어두운 터미널 창에서 숫자 하나 삐끗하면 그대로 미궁 속에 빠지니까 타이핑할 때 숨 참으세요.
• BIOS (최후의 보루): 원격 접속도 안 되고 SSH도 먹통일 때. 직접 모니터랑 키보드 들고 서버 앞에 쭈그리고 앉아야 합니다. 노드 재부팅하면서 'Delete' 키 미친듯이 연타해서 BIOS 진입하세요. [IPMI 탭 > BMC Network Configuration]에서 화살표 키로 움직이며 입력하는 진짜 '아날로그' 방식입니다.

BIOS에서 IPMI 설정하는 모습

이 경험을 통해 알게 된 IPMI 변경 꿀팁 (실패하지 않는 법)

야간 작업에서 삽질을 제로로 만드는, 선배들의 피와 땀으로 쓴 체크리스트입니다. 당장 복사해서 바탕화면 메모장에 띄워두세요.

• 서브넷/게이트웨이 오타의 저주: IP는 긴장해서 잘 넣는데, 의외로 서브넷 마스크(255.255.252.000 등)나 게이트웨이에서 끝자리 하나 틀려서 통신 안 되는 경우 현장에서 하루에 한 번씩 터집니다. 메모장에 적어두고 복붙하는 게 생명입니다.
• Genesis 재시작의 징표 확인: CVM에서 nutanix@cvm$ genesis restart 명령어를 쳤을 때 대충 엔터 치고 넘어가지 마세요. 화면에 Genesis pids 중지 [1933...] 메시지가 뜨고, 이어서 Genesis started on pids [...]라며 새로운 프로세스 번호가 부여되는지 두 눈으로 똑똑히 확인해야 발 뻗고 잡니다.
• 핑(Ping) 칠 때까지 퇴근 금지: IP 변경 후 내 PC에서 새 주소로 핑(Ping)이 정상적으로 가는지, 브라우저 열어서 IPMI 로그인 창이 새로 뜨는지 확인하기 전까지는 절대 콘솔 케이블 안 뽑습니다.
• 제조사별 미묘한 차이: 껍데기는 Nutanix 블록이지만 내부 보드는 벤더마다 다를 수 있습니다. CLI에서 ipmitool 옵션이 안 먹힌다면 당황하지 말고 해당 제조업체 매뉴얼부터 뒤지세요.

하이퍼바이저별 명령어 한 끗 차이 (이거 모르면 식은땀)

어제 AHV 장비 다루다가 오늘 ESXi 장비 들어가서 똑같이 명령어 쳤는데 "Command not found"를 뱉습니다. 순간 뇌 정지 오면서 식은땀 쫙 흐르죠? 별거 아닙니다. 경로와 도구의 차이일 뿐이에요.

vSphere(ESXi)에서는 /ipmitool 처럼 앞에 슬래시를 붙여 절대 경로를 잡거나 특정 바이너리 위치를 직접 지정해야 할 때가 잦습니다. 반면 AHV는 깡통 상태에서도 그냥 ipmitool 치면 찰떡같이 알아먹죠. Hyper-V 호스트라면 ipmiutil이라는 아예 다른 이름의 툴을 써야 할 수도 있습니다. ipmiutil lan -e -I [IP] -G [게이트웨이] 식으로 들어가는 옵션 플래그도 싹 다르니, 작업 전 스크립트 준비는 선택이 아닌 필수입니다.

마더보드 교체라는 특수 상황

장애 나서 서버 마더보드 통째로 갈았을 때는 얘기가 좀 다릅니다. 딱 그 교체한 노드만 신경 쓰면 돼요. 멀쩡히 서비스 잘 돌고 있는 클러스터 전체의 Genesis를 다 흔들어서 긁어 부스럼 만들 필요는 없습니다. 해당 노드의 CVM에서만 Genesis 재시작 때려주세요. 다만, 보드를 갓 바꾼 직후라 노드의 새 하드웨어 주소나 IPMI 정보가 기존 클러스터 설정과 꼬이지 않았는지 크로스 체크하는 과정은 목숨 걸고 해야 합니다.

몸은 천근만근 무겁고 당장 집에 가고 싶겠지만, 이 작은 IP 주소 하나가 전체 인프라의 관제 통로를 열고 닫는 열쇠라는 책임감을 가지셔야 해요. 나중에 치명적인 장애 터졌을 때 IPMI 원격 접속조차 안 되면, KTX 타고 지방 데이터센터까지 직접 내려가야 하는 진짜 지옥문이 열립니다. 자, 지금 이 글을 다 읽으셨다면 멍때리지 말고 한 번 더 바뀐 IP 주소로 핑 쏴보세요.

상황이 항상  내가 원하는 방향으로 진행되지는 않습니다. 작업 시 여러가지 대안을 가지고 작업을 하시기 바랍니다.