고객사에서 Nutanix Move로 마이그레이션 하려고 싹 다 세팅해 뒀는데, 네트워크 팀에서 IP 대역을 잘못 알려줬다며 당장 바꾸라고 연락 온 경험 다들 한 번씩 있으시죠? ㅋ 저도 어제 똑같은 상황을 겪고 식은땀을 좀 흘렸습니다. DHCP 환경이면 그냥 재부팅하고 알아서 할당받으면 그만인데, 폐쇄망이나 고정 IP를 깐깐하게 쓰는 엔터프라이즈 환경에서는 직접 어플라이언스에 들어가서 뜯어고쳐야 하거든요. 당황하지 마세요. 처음부터 템플릿을 다시 배포할 필요 없이 내부 스크립트 하나면 깔끔하게 해결됩니다. 현장에서 겪었던 과정 그대로 생생하게 전달해 드릴게요.
1. 콘솔 접근부터 루트 쉘(Root Shell) 진입까지의 여정
당장 IP가 안 맞아서 네트워크 밖에서는 핑(Ping)이 안 나가는 먹통 상태일 겁니다. 이럴 때는 어쩔 수 없이 Prism Element(PE) 웹 콘솔로 직접 치고 들어가야 해요. PE에서 VM 뷰로 이동하신 다음 문제가 발생한 Move VM 인스턴스를 찾아 다이렉트로 콘솔 창을 열어주세요. 만약 다행히 기존 IP로 SSH 접근이 가능한 상태라면 터미널 프로그램으로 바로 붙으셔도 됩니다.
# 기본 접속 계정 정보
admin / nutanix/4u
# 루트 권한 획득 명령어
rs |
| 루트 권한을 획득하는 터미널 캡처 화면 |
이 부분에서 정말 많은 주니어 엔지니어 분들이 헷갈리시는데, 일반적인 우분투나
센트OS 리눅스 환경처럼 su - 명령어나 sudo su를
냅다 치시면 절대 안 됩니다. Nutanix 기반 어플라이언스들은 자체적인 보안
통제와 서비스 관리 목적 때문에 사전에 정의된 rs라는 전용
명령어를 제공하거든요. 콘솔 화면에 admin@move on ~$ 프롬프트가
보인다면 주저하지 말고 바로 rs를 입력해 보세요. 패스워드를 한
번 더 물어볼 텐데 당황하지 마시고 동일한 초기 비밀번호(nutanix/4u)를 다시
입력하시면 됩니다. 그러면 프롬프트가 root@move로 변하면서
본격적으로 시스템 네트워크 데몬을 만질 수 있는 강력한 최고 관리자 권한을
얻게 되죠.
💡 [실무 꿀팁] 공식 문서에는 없는 도커(Docker) 서비스 재시작의 무서움
본격적인 스크립트를 돌리기 전에 제발 이것 하나만 확인해 주세요. 지금 Move에서 진행 중인 마이그레이션 작업이 있나요? 우리가 곧 실행할 IP 변경 스크립트는 단순히 리눅스의 네트워크 인터페이스(eth0)만 껐다 켜는 게 아닙니다. 내부적으로 돌고 있는 수십 개의 도커(Docker) 컨테이너 서비스들을 완전히 싹 다 내렸다가 새로운 IP 환경에 맞춰서 밑바닥부터 다시 올리거든요. 만약 액티브 상태의 마이그레이션 세션이 열심히 데이터를 넘기고 있는데 이 스크립트를 때려버리면, 마이그레이션 상태가 즉시 Failed로 떨어집니다. 진짜 대형 사고 나는 거죠. 반드시 작업 중인 세션이 없는지, 혹은 마지막 스냅샷 기반으로 안전하게 멈춰 있는지 대시보드에서 크로스 체크를 먼저 하시는 것이 살길입니다.
2. 대망의 IP 재설정 스크립트 실행과 파라미터 입력
사전 확인이 완벽하게 끝났다면 이제 숨어있는 관리용 스크립트가 있는 경로로
이동할 차례입니다. Move 어플라이언스는
/opt/xtract-vm/bin 디렉토리 아래에 인프라 관리자들을 위한 핵심
트러블슈팅 툴들을 꼼꼼하게 모아뒀습니다.
cd /opt/xtract-vm/bin
./configure-static-ip
저 경로로 이동하신 다음에 configure-static-ip 스크립트를 쉘에서
바로 실행해 주시면 대화형 프롬프트가 시작됩니다. 이 스크립트를 실행하는
이유는 단순히 /etc/network/interfaces 파일 같은 리눅스 기본
네트워크 설정 텍스트 파일 하나만 딸랑 바꾸는 게 아니기 때문이에요.
스크립트가 실행되면 내부적으로 어플라이언스 구동에 필요한 백엔드 네트워크
브리지 설정과 도커 데몬의 바인딩 IP, 내부 DB 통신 규격까지 한 번에 싹 다
다시 세팅해 주게 됩니다.
만약 여기서 넷마스크(Netmask)나 디폴트 게이트웨이(Gateway)를 한 끗 차이로
잘못 입력하시면, 어플라이언스가 라우팅 테이블을 찾지 못해 아예 네트워크
미아가 되어버립니다. 그렇게 되면 콘솔로 꾸역꾸역 다시 들어가서 처음부터 이
과정을 지루하게 반복해야 하는 끔찍한 사태가 벌어지죠. 그렇기 때문에 화면에서
대문자 Y를 눌러 설정을 시작할 때, 아래 표에 정리해 드린 각
파라미터의 의미와 포맷을 정확히 숙지하시고 오타가 나지 않도록 두 번, 세 번
크로스 체크하시는 것이 정신 건강에 아주 좋습니다. 정말이에요 ㅎ
| 입력 파라미터 | 설명 및 입력 예시 | 실무 주의사항 |
|---|---|---|
| Static IPv4 Address | 변경할 새로운 Move 어플라이언스 IP 주소 (예: 10.10.10.50) |
사내 IP 관리 대장에서 이미 사용 중인 IP와 충돌나지 않는지 반드시 핑을 미리 날려보세요. |
| Netmask | 해당 네트워크 대역의 서브넷 마스크 (예: 255.255.255.0) |
프리픽스(/24 등) 형식이 아니라 반드시 전체 숫자를 풀어서 입력해야 스크립트 에러가 안 납니다. |
| Gateway IP Address | 네트워크 대역의 디폴트 라우터 주소 (예: 10.10.10.1) |
이 값을 잘못 넣으면 같은 서브넷끼리는 통신돼도 외부망(vCenter 등)으로 절대 패킷이 못 나갑니다. |
| DNS Server 1 & 2 | 사내 구축된 내부 DNS 또는 공인 DNS (예: 8.8.8.8) |
폐쇄망이라면 반드시 사내 AD/DNS 서버 IP를 넣어야 호스트네임 기반 마이그레이션이 꼬이지 않아요. |
| Domain | 사내 도메인 주소 (예: my.dc.domain) |
특별히 도메인 환경을 구축하지 않았다면 비워두거나 localdomain 처리해도 무방합니다. |
 |
| 네트워크 변경 스크립트 실행 후 최종 확인화면 |
3. 원인 분석: 백그라운드에서는 무슨 일이 벌어질까?
도메인까지 다 적어 넣고 엔터를 치는 순간 터미널 창에 무언가 엄청난 속도로
로그가 올라가기 시작할 겁니다. 이게 바로 앞서 제가 꿀팁에서 경고해 드렸던
도커 컨테이너들의 재시작 타이밍이에요. 스크립트가 알아서
busybox ntpd 같은 시간 동기화 부트 서비스를 먼저 안전하게
중지시키고, 리눅스 본연의 네트워크 데몬을 내렸다가 우리가 방금 정성껏
집어넣은 새로운 설정값으로 네트워킹을 살려냅니다.
그리고 나면 화면에 Stopping bin_mgmtserver_1 done,
Removing bin_postgres_1 같은 섬뜩한 메시지들이 줄줄이 뜨는데요.
기존에 잘못된 IP를 물고 있던 Postgres DB 컨테이너부터 시작해서 apidocs,
srcagent 같은 무거운 코어 마이크로서비스 컨테이너들을 싹 지워버리는 지극히
정상적이고 건강한 과정입니다. 빨간 글씨가 뜬다고 쫄지 말고 커피 한 모금
하시면서 가만히 지켜보세요. 곧바로
Starting new application...이라는 반가운 메시지와 함께 방금
삭제했던 컨테이너들을 새로운 IP 대역 위에서 Creating 하면서
아주 깔끔하고 쾌적하게 올려줍니다.
4. 현장 노하우: 핑 테스트와 접속 장애 시 방화벽 체크
마지막으로 쉘 화면 제일 바닥에
Static IPv4 configuration completed successfully라는 기분 좋은
메시지가 떴다면 이제 굵직한 산은 다 넘으신 겁니다. 하지만 여기서 모니터를
끄지 마시고 쉘에서 곧바로 새로 설정한 디폴트 게이트웨이와 내부 DNS 서버
쪽으로 핑(ping)을 날려서 패킷이 제대로 뻗어 나가는지 꼭 직접 눈으로 확인해
보세요. 외부 네트워크 통신이 시원하게 뚫린 것을 확인했다면 여러분의 로컬 PC
브라우저를 열고 변경된 IP 주소로 Move 웹 대시보드에 다시 접속하시면 됩니다.
그런데 간혹 어플라이언스 쉘에서 핑은 기가 막히게 잘 나가는데, 제 로컬 브라우저에서 새 IP로 웹 UI(https) 접속이 죽어도 안 열릴 때가 있어요. 제가 예전에 이 문제 때문에 반나절을 허공에 날렸거든요. 알고 보니까 Move 어플라이언스 내부의 세팅 문제는 완벽하게 다 해결됐는데, 고객사 사내 방화벽 스위치 쪽에서 이전 IP에 대해서만 웹 포트(TCP 80, 443)와 관리 포트를 열어두고 새로 바뀐 대역의 IP는 꽉 막아둔 게 원인이었습니다. Move는 단순히 핑만 살아서 나간다고 끝나는 게 아니라 마이그레이션 소스와 타겟 환경(vCenter나 AHV 클러스터 등) 사이에 여러 가지 묵직한 API 통신 포트들이 쌍방향으로 뚫려 있어야 정상 작동하거든요.
스크립트를 정상적으로 마쳤는데도 대시보드 접근이 계속 타임아웃 나거나 호스트 연결에 실패한다면, 뻘질나게 애먼 어플라이언스만 계속 재부팅하지 마세요. 곧바로 사내 네트워크 인프라 담당자에게 찾아가서 "새로 바뀐 Move IP에 대해서도 기존과 동일한 방화벽 정책과 라우팅 테이블을 씌워 주셨나요?"라고 당당하게 따져보셔야 합니다. 그래야 우리의 아까운 야근 시간을 팍 줄일 수 있어요. 이제 바뀐 IP 환경에서 안전하게 마이그레이션 마무리 잘하시길 바랍니다!
항상 마이그레이션은 인내와 집요함으로 해결 가능합니다. 오늘도 화이팅 입니다. ^^
0 댓글