IP 변경 전 멘탈 잡기: 왜 이 작업이 헬파티일까?
Nutanix 클러스터는 각 노드의 CVM이 서로 끊임없이 하트비트를 주고받으며 하나의 거대한 스토리지 풀을 유지합니다. IP가 바뀌는 순간 이 내부 통신이 단절됩니다. ZooKeeper 쿼럼이 깨지고 클러스터가 멈추는 상황을 막으려면 반드시 제조사가 권장하는 내장 스크립트를 통해 '동시에', '안전하게' 변경을 때려야 합니다. 리눅스 좀 다룬다고 수동으로 vi /etc/sysconfig/network-scripts/ifcfg-eth0 파일을 건드리는 것은 절대 금물입니다.
작업 전 기존 환경과 변경 대상 비교표
작업 전 엑셀이나 메모장에 현재 상태와 타겟 상태를 명확히 매핑해두는 것이 살길입니다. 아래 표처럼 구조화해두면 야간 작업 중 쏟아지는 졸음 속에서도 혼선을 막을 수 있습니다.
| 네트워크 구분 | 기존 환경 (Old IP) | 변경 대상 환경 (New IP) | 실무 체크포인트 |
|---|---|---|---|
| CVM IP | 192.168.10.X 대역 | 10.10.50.X 대역 | 스토리지 컨트롤러 간 통신 핵심 (가장 중요) |
| AHV IP | 192.168.10.Y 대역 | 10.10.50.Y 대역 | 하이퍼바이저 관리용, vSwitch 업링크 확인 |
| Subnet / GW | 255.255.255.0 / 192.168.10.1 | 255.255.255.0 / 10.10.50.1 | 신규 게이트웨이 라우팅 경로 사전 개통 필수 |
| IPMI / iLO | 대역 변경 없음 | 대역 변경 없음 | 장애 시 유일한 생명줄, 접속 가능 여부 미리 테스트 |
실전 작업 1단계: Cluster Stop으로 안전 확보하기
제일 먼저 할 일은 구동 중인 사용자 VM을 다른 여유 클러스터로 이관하거나, 사전에 공지한 다운타임에 맞춰 안전하게 Guest OS를 종료하는 것입니다. 이후 특정 CVM에 SSH로 접속하여 전체 클러스터 서비스를 깔끔하게 내려야 합니다. 이 단계를 건너뛰고 냅다 네트워크 설정을 돌리면 데이터 오염(Corruption)이 발생할 수 있습니다.
클러스터의 모든 스토리지 서비스를 안전하게 중지하기 위해 CVM 명령줄에서 아래의 명령어를 입력합니다.
nutanix@cvm$ cluster stop이 명령어를 엔터 치면 화면에 Stopping state... 메시지가 주르륵 올라오면서 각 노드의 서비스(Zeus, Medusa 등)가 하나씩 내려가는 과정을 볼 수 있습니다. 보통 3노드 기준으로 5분에서 길게는 10분 정도 소요됩니다. 모든 노드의 상태가 down으로 떨어질 때까지 커피 한 잔 마시며 차분히 기다리셔야 합니다. 성급하게 다음 단계로 넘어가면 프로세스가 꼬입니다.
실전 작업 2단계: 외부 IP 재설정 스크립 구동 (핵심)
클러스터가 완벽하게 정지된 것을 두 눈으로 확인했다면, 이제 본격적으로 새 IP를 덮어씌울 차례입니다. Nutanix는 친절하게도 이 위험한 작업을 자동화해주는 파이썬 스크립트를 내장하고 있습니다.
변경할 IP 대역의 서브넷 마스크와 게이트웨이 정보를 스크립트 파라미터로 넘겨주기 위해 다음 명령어를 띄어쓰기에 주의하여 실행합니다.
nutanix@cvm$ external_ip_reconfig --netmask=255.255.255.0 --gateway=10.10.50.1명령어가 실행되면 터미널에 인터랙티브 프롬프트가 뜹니다. 현재 노드들의 IP 리스트가 화면에 쭉 출력되고, 변경할 새 IP를 노드별로 하나씩 타이핑하라는 안내가 나옵니다. 오타가 나지 않도록 사전에 준비한 IP 테이블을 보면서 신중하게 입력하세요. 모든 입력을 마치면 스크립트가 백그라운드에서 각 노드의 AHV와 CVM 네트워크 설정 파일을 일괄적으로 뜯어고치고 네트워크 데몬을 재시작합니다.
정상화 검증: Genesis 데몬과 클러스터 상태 확인
네트워크 대역이 바뀌었으므로 기존 SSH 세션은 당연히 튕기면서 끊어집니다. 당황하지 마시고 방금 새롭게 부여한 CVM IP로 다시 SSH 접속을 맺어보세요. 접속에 성공했다면 최소한 물리적인 통신은 뚫렸다는 뜻입니다. 이제 멈춰둔 클러스터를 다시 깨워야 합니다.
클러스터 서비스를 올리기 전, 모든 노드의 백그라운드 프로세스 매니저인 Genesis를 깔끔하게 재기동하기 위해 다음 명령어를 때려줍니다.
nutanix@cvm$ allssh "genesis restart"각 노드별로 Genesis 데몬이 재시작되었다는 Success 메시지가 출력될 것입니다. 이 과정은 꼬여있을지 모르는 파이썬 캐시를 날려버리고 서비스를 올릴 준비를 하는 일종의 환기 작업입니다.
이제 진짜로 클러스터를 기동하기 위해 다음 명령어를 입력합니다.
nutanix@cvm$ cluster start
nutanix@cvm$ cluster statuscluster start를 날린 뒤 바로 서비스가 올라오지 않습니다. ZooKeeper 리더가 새로 선출되고 Cassandra 데이터베이스 링이 다시 묶이는 시간이 필요합니다. 5분 정도 뒤에 cluster status를 쳐봤을 때 화면에 출력되는 모든 서비스 프로세스 ID 옆에 UP이라는 녹색 글자가 보인다면 작업은 대성공입니다. 단 하나라도 DOWN 상태라면 해당 노드의 네트워크 스위치 연결 상태나 핑(Ping) 테스트를 다시 해보셔야 합니다.
현업 엔지니어가 알려주는 실무 주의사항
IP를 변경하기 전에 타겟 스위치 포트의 VLAN 맵핑이 제대로 되어 있는지 네트워크 팀과 세 번, 네 번 크로스체크 하세요. 예전에 주말 새벽 작업 때 서버 쪽 IP는 다 바꿔놨는데, 정작 상단 L3 스위치 쪽에 VLAN 태깅이 안 들어가 있어서 2시간 동안 CVM끼리 핑이 안 나가는 원인을 찾느라 진땀을 뺀 적이 있습니다.
또 하나 놓치기 쉬운 꿀팁이 있습니다. 사내 DNS나 NTP 서버 IP도 이번 망분리 때 같이 바뀌었다면, Prism Web UI에 들어가서 해당 설정(Name Server, Time Server)들도 반드시 새 IP로 업데이트해 주셔야 합니다. 이거 까먹고 철수하면 나중에 라이선스 갱신이 안 되거나 장애 얼럿 메일이 발송되지 않아서 욕을 바가지로 먹게 됩니다.
항상 작업 빨리 끝내고 갈 생각보다는 차분히 다음 문제가 생길 가능성을 두고 작업 마무리 하시길 바랍니다.
0 댓글