지난 글(05. PBS 백업 연동과 HA 구성)에서 복제·백업·HA의 세 겹 안전망을 모두 설정했습니다. 하지만 그 글 끝에서 강조했듯, “설정했다”와 “실제로 동작한다”는 다릅니다. 이번 글에서는 이 안전망이 정말 작동하는지 직접 시험합니다. VM을 무중단으로 옮기는 라이브 마이그레이션의 실측 다운타임을 재고, 노드를 강제로 차단해 HA 자동 복구를 확인합니다. 그리고 그 과정에서 운영 전에 미리 발견하고 해결한 실제 함정들을 공유합니다. 이 시리즈에서 가장 중요한 편입니다.
왜 검증이 가장 중요한가
인프라 구축에서 가장 위험한 순간은 “다 됐다”고 믿고 운영을 시작했는데, 정작 진짜 장애가 났을 때 안전망이 작동하지 않는 경우입니다. HA를 켰지만 실제로 노드를 꺼본 적이 없다면, 그건 “HA를 설정한 것”이지 “HA가 동작하는 것”이 아닙니다.
그래서 운영을 시작하기 전에, 장애를 일부러 일으켜서 안전망이 작동하는지 확인해야 합니다. 이 과정에서 발견되는 문제들은 운영 중에 만나면 사고지만, 검증 중에 만나면 그냥 해결 과제일 뿐입니다.
검증 1 — 라이브 마이그레이션
라이브 마이그레이션은 켜져 있는 VM을 멈추지 않고 다른 노드로 옮기는 기능입니다. 하드웨어 점검이나 노드 재부팅이 필요할 때, 서비스를 내리지 않고 VM을 다른 노드로 피신시킬 수 있습니다.
테스트 VM을 하나 만들어 pve11에서 pve12로 옮겨봅니다. 웹 UI에서 VM 우클릭 → Migrate로도 되고, CLI로도 됩니다.
qm migrate 100 pve12 --online--online이 핵심입니다. VM을 끄지 않고 메모리 상태까지 통째로 옮깁니다. 실제 측정 결과는 이랬습니다.
duration: 약 1분 40초
전송된 데이터: 990 MiB (VM 메모리 2 GiB 중)
평균 속도: 약 23 MiB/s
downtime: 23 ms ← 핵심downtime 23ms. VM이 완전히 멈춘 시간이 23밀리초라는 뜻입니다. 사람이 인지할 수 없는 수준이고, SSH 세션도 ping도 끊기지 않습니다. 메모리 2GiB짜리 VM인데 990MiB만 전송된 건, QEMU가 변경된 메모리 페이지(dirty page)만 추려서 보내기 때문입니다. 이게 라이브 마이그레이션이 무중단인 원리입니다.
VM 디스크는 따로 옮기지 않는다는 점도 중요합니다. 디스크는 04번에서 만든 Ceph 공유 스토리지에 있으므로, 옮길 필요 없이 목적지 노드가 그대로 이어받습니다. 메모리 상태만 네트워크로 전송하면 끝입니다. 공유 스토리지가 없었다면 디스크 수십 GB를 통째로 복사해야 했을 겁니다.
발견한 함정 ① — 마이그레이션이 1G 관리망을 타고 있었다
여기서 첫 번째 함정을 발견했습니다. 전송 속도가 23 MiB/s로 유독 느렸습니다. 10G 망이라면 1000 MiB/s 가까이 나와야 하는데 말이죠.
원인은 Proxmox의 라이브 마이그레이션이 기본적으로 관리망(Corosync link0)을 사용하기 때문이었습니다. 이 구축에서 관리망은 1G(eno4)라, 마이그레이션 트래픽이 1G에 묶여 있던 것입니다. 10G Ceph망(ens2f0)은 마이그레이션에 쓰이지 않고 놀고 있었습니다.
해결책은 마이그레이션 전용망을 지정하는 것입니다. /etc/pve/datacenter.cfg에 한 줄 추가합니다.
migration: secure,network=10.10.10.0/24이러면 마이그레이션이 10G망을 타고 훨씬 빨라집니다. 다만 Ceph 트래픽과 같은 망을 공유하게 되므로, 마이그레이션이 빈번하면 Ceph I/O에 영향을 줄 수 있습니다. 마이그레이션 빈도가 낮다면 이대로도 충분하고, 잦다면 별도 망을 두는 게 좋습니다. 이건 운영 패턴에 따른 트레이드오프입니다.
검증 2 — HA 자동 복구 (노드 장애 시뮬레이션)
이제 진짜 중요한 검증입니다. 노드 한 대를 죽였을 때 VM이 다른 노드에서 자동으로 살아나는가. 이게 이 시리즈 전체가 목표로 한 것입니다.
먼저 테스트 VM을 HA 리소스로 등록합니다.
ha-manager add vm:100 --group default-ha --state started
ha-manager status # service vm:100 라인이 보이면 등록됨함정 ② — “노드를 어떻게 죽일 것인가”가 문제였다
장애 시뮬레이션의 정석은 “VM이 떠 있는 노드의 전원을 강제로 내리는 것”입니다. poweroff -f나 물리 전원 차단이죠. 그런데 여기서 현실적인 벽에 부딪혔습니다.
이 환경은 iLO/IPMI 원격 전원 제어가 준비돼 있지 않았습니다. 즉, 노드를 poweroff로 완전히 꺼버리면, 다시 켜기 위해 데이터센터에 직접 가야 합니다. 검증 한 번 하자고 치르기엔 너무 큰 비용입니다.
그래서 전원을 내리지 않고 HA가 “노드가 죽었다”고 판단하게 만드는 방법을 썼습니다. 해당 노드에서 클러스터 관련 서비스만 정지시키는 것입니다.
# VM이 떠 있는 노드에서 — 클러스터 서비스만 정지
systemctl stop pve-ha-lrm pve-ha-crm corosync pve-cluster이러면 다른 노드들이 보기엔 이 노드가 클러스터에서 사라진 것처럼 보입니다. 노드 본체는 살아 있어서, 검증이 끝나면 서비스를 다시 켜는 것만으로 클러스터에 복귀할 수 있습니다. 데이터센터에 갈 필요가 없습니다.
watchdog 메커니즘 짚기. HA가 노드를 fence(격리)하기로 결정하면, 그 노드는 watchdog 타이머에 의해 스스로 재부팅합니다(약 60초 후). 클러스터에서 떨어진 노드가 혼자 VM을 계속 돌려 데이터가 충돌하는 것(split-brain)을 막기 위한 안전장치입니다. 그래서 서비스만 정지시켜도, 노드는 잠시 후 자동으로 재부팅되어 깨끗한 상태로 복귀합니다.
복구 과정
서비스를 정지시킨 뒤, 다른 노드에서 HA 상태를 지켜봤습니다.
watch -n 1 ha-manager status흐름은 이랬습니다. 클러스터가 해당 노드의 하트비트 상실을 감지하고(쿼럼은 남은 2노드로 유지됨) → 죽은 것으로 판정 → VM 100을 남은 노드 중 하나에서 자동으로 다시 부팅. 약 1~2분 안에 VM이 다른 노드에서 살아났습니다.
여기서 03번의 쿼럼과 04번의 공유 스토리지가 실제로 어떻게 맞물리는지가 드러납니다. 남은 2노드가 쿼럼(과반)을 유지했기에 클러스터가 “저 노드는 죽었다”고 안전하게 판단할 수 있었고, VM 디스크가 Ceph에 있었기에 다른 노드가 그대로 이어받아 부팅할 수 있었습니다.
함정 ③ — 노드 복귀 시 nofailback 동작 확인
정지시킨 서비스를 다시 켜자(또는 watchdog 재부팅 후) 노드가 클러스터에 복귀했습니다. 이때 05번에서 nofailback을 켜둔 효과가 확인됐습니다 — 복귀한 노드로 VM이 자동으로 되돌아가지 않았습니다. VM은 피신한 노드에서 계속 안정적으로 돌고, 원래 노드로 옮길지는 관리자가 판단하면 됩니다. 복귀 직후의 불필요한 출렁임이 방지된 것입니다.
Ceph도 확인했습니다. 노드가 빠진 동안 OSD 6개가 down 상태가 되어 일시적으로 HEALTH_WARN이 떴지만, 노드 복귀 후 자동으로 리밸런싱되어 HEALTH_OK로 돌아왔습니다. 다운된 동안 변경된 데이터가 적어 복구는 빠르게 끝났습니다.
검증이 드러낸 가장 큰 함정 — snippets와 HA의 충돌
검증 과정에서 가장 값진 발견이 이것이었습니다. 처음에는 VM을 만들 때 cloud-init의 cicustom(snippet 파일)으로 초기 설정(비밀번호, SSH 설정, swap 등)을 처리하고 있었는데, 이 방식이 HA·마이그레이션과 정면으로 충돌했습니다.
문제의 핵심은 snippet 파일의 위치였습니다. snippet은 각 노드의 로컬 디렉터리(/var/lib/vz/snippets/)에 저장됩니다. 그런데 Ceph 공유 스토리지에 있는 건 VM 디스크일 뿐, 이 snippet 파일은 공유되지 않습니다. 그래서 이런 일이 벌어졌습니다.
- VM이 다른 노드로 마이그레이션되면, 그 노드에는 snippet 파일이 없어 참조가 깨짐
- HA로 VM이 다른 노드에서 자동 복구될 때도 같은 이유로 실패할 수 있음
즉, snippet에 의존하는 한 HA와 자유로운 마이그레이션이 보장되지 않았습니다. 운영을 시작한 뒤 진짜 장애 때 이걸 만났다면 큰 사고였을 겁니다.
해결 — 템플릿(Golden Image) 방식으로 전환
해결책은 snippet 의존을 아예 없애는 것이었습니다. 초기 설정을 매번 cloud-init snippet으로 주입하는 대신, 필요한 설정(swap, qemu-guest-agent, 기본 패키지 등)을 미리 다 넣은 템플릿 VM을 한 번 만들어두고, 신규 VM은 그 템플릿을 복제(clone)해서 만드는 방식입니다.
이렇게 바꾸자 여러 문제가 한꺼번에 풀렸습니다.
| 항목 | snippet(cicustom) 방식 | 템플릿(clone) 방식 |
|---|---|---|
| VM 생성 시간 | 5~10분 (cloud-init 전체 실행) | 1~2분 (clone만) |
| HA 자동 복구 | snippet 없으면 실패 위험 | 깔끔하게 성공 |
| 다른 노드 마이그레이션 | snippet 파일 의존 | 자유롭게 이동 |
| 운영 표준화 | 어려움 | 쉬움 |
전환 후 다시 검증했을 때, 템플릿 기반으로 만든 VM의 라이브 마이그레이션 다운타임은 44ms로 여전히 무중단 수준이었고, HA·마이그레이션이 snippet 걱정 없이 깔끔하게 동작했습니다. 이 템플릿 기반 VM 생성 방식을 이후 운영 표준으로 삼았습니다.
운영 전 남겨둔 보완 과제
검증을 통과했다고 100점은 아닙니다. 검증 과정에서 “지금 당장은 아니지만 운영하며 보완할” 과제들도 함께 정리했습니다. 솔직하게 남겨두는 게 이 기록의 가치라고 생각합니다.
- IPMI/iLO Fence Agent 등록 — 지금은 watchdog 기반 fence만 동작합니다. iLO를 fence agent로 등록하면 더 확실한 격리가 가능해, HA 복구 신뢰도가 올라갑니다. (이번엔 iLO 미구성이라 서비스 정지 방식으로 검증)
- 마이그레이션 전용망 — 위에서 본 1G 경유 문제. 10G망 지정으로 개선 가능하나 Ceph와의 공유 트레이드오프 고려 필요.
- 백업 실제 복원 테스트 — 백업이 받아지는 것까지는 확인했지만, 실제로 한 번 복원까지 해봐야 진짜 안전망입니다.
- 모니터링 추가 — Prometheus + Grafana 등으로 Ceph·노드 상태를 상시 관찰.
마무리
이번 글에서는 안전망을 실제로 시험했습니다. 라이브 마이그레이션은 다운타임 23~44ms로 무중단을 확인했고, 노드 장애 시뮬레이션으로 HA 자동 복구와 nofailback 동작을 검증했습니다. 무엇보다 운영 전에 snippets·마이그레이션 경로 같은 함정들을 미리 만나 해결한 것이 가장 큰 수확이었습니다. “설정했다”가 “동작한다”로 바뀐 셈입니다.
여기까지가 이 시리즈의 여정이었습니다. Proxmox가 무엇이고 누구에게 어울리는지(00번)에서 출발해, 단일 노드 설치(01번)·네트워크 망분리(02번)·3노드 클러스터(03번)·Ceph 분산 스토리지(04번)·PBS 백업과 HA(05번)를 거쳐, 이번 글에서 그 안전망이 실제로 동작함을 검증했습니다. 복제·백업·고가용성의 세 겹 안전망을 갖춘 개인 클라우드가 완성된 것입니다. 직접 구축을 고민하는 분들께 이 기록이 실전 지도가 되기를 바랍니다.
00. Proxmox란? 누구에게 어울리나
01. Proxmox 단일 노드 설치
02. Proxmox 네트워크 망분리 설계
03. Proxmox 3노드 클러스터 구성
04. Ceph 분산 스토리지 구축
05. PBS 백업 연동과 HA 구성
06. 라이브 마이그레이션과 장애 복구 검증 ← 현재 글
