[Proxmox] Proxmox 클러스터 HA 설정: 고가용성 구성 완벽 가이드 2026

목차

• 서버가 꺼졌을 때, 그 순간을 대비해야 합니다
• Proxmox 클러스터 HA, 쉽게 말하면 이겁니다
• 클러스터(Cluster)란?
• HA(High Availability, 고가용성)란?
• 사전 준비: Proxmox 클러스터 구성 전 필수 체크사항
• 단계별 실전 구성: Proxmox 클러스터 HA 설정하기
• 1단계: 클러스터 생성 (첫 번째 노드에서)
• 2단계: 나머지 노드 합류
• 3단계: 공유 스토리지 설정 (Ceph 기준)
• 4단계: 펜싱(Fencing) 설정
• 5단계: HA 리소스 그룹 및 VM 등록
• 6단계: HA 서비스 활성화 확인
• ⚠️ 실제로 겪은 Proxmox HA 트러블슈팅 사례들
• 문제 1: 쿼럼 손실 (Quorum Lost)
• 문제 2: VM이 HA 대상이 안 되는 경우
• 문제 3: 펜싱 실패로 HA가 동작 안 하는 경우
• 문제 4: 시간 동기화 문제
• HA 동작 검증: 실제로 노드를 꺼봤습니다
• VM 백업과 HA: 같이 챙겨야 합니다
• 정리: Proxmox 클러스터 HA 완성 체크리스트
• 마치며: 장애는 반드시 옵니다
• 자주 묻는 질문 (FAQ)
• Q. Proxmox HA는 몇 대부터 가능한가요?
• Q. 펜싱 장치가 없으면 HA를 쓰면 안 되나요?
• Q. HA VM의 라이브 마이그레이션(Live Migration)과 HA 페일오버의 차이는?

서버가 꺼졌을 때, 그 순간을 대비해야 합니다

몇 년 전 일이에요. 새벽 3시에 전화가 울렸습니다. 운영 중인 VM(가상머신)이 돌아가던 물리 서버 하나가 갑자기 다운됐다는 알림이었거든요. 그때 HA(High Availability, 고가용성) 설정이 없었더라면... 생각만 해도 식은땀이 납니다. 다행히 Proxmox 클러스터 HA 덕분에 VM들이 자동으로 다른 노드로 이전됐고, 서비스 중단 시간은 2분도 안 됐어요.

이 글은 바로 그 경험을 바탕으로 씁니다. Proxmox VE 클러스터 고가용성(HA) 설정을 처음 해보시는 분들, 혹은 설정은 해봤는데 뭔가 불안한 분들을 위한 2026년 기준 실전 가이드예요. 홈랩에서도, 소규모 프로덕션 환경에서도 충분히 적용 가능한 내용으로 가득 채웠으니 끝까지 읽어보세요.

▲ Proxmox VE 3노드 클러스터 HA 전체 구성도 — 각 노드 간 Corosync 통신, 공유 스토리지, 펜싱 장치 연결 구조를 보여줍니다.

Proxmox 클러스터 HA, 쉽게 말하면 이겁니다

처음 Proxmox를 접하시는 분들은 클러스터니 HA니 하는 말들이 좀 낯설 수 있어요. 저도 처음엔 그랬거든요. 하나씩 풀어볼게요.

클러스터(Cluster)란?

쉽게 말해서, 여러 대의 물리 서버(노드)를 하나처럼 묶어서 관리하는 구성이에요. Proxmox에서는 최소 3대의 노드가 있어야 제대로 된 클러스터를 구성할 수 있어요. 2대로도 가능하긴 한데, 쿼럼(Quorum, 의사결정 정족수) 문제가 생겨서 실무에서는 권장하지 않습니다.

HA(High Availability, 고가용성)란?

클러스터 위에서 동작하는 기능인데요. 특정 노드가 장애가 나면 그 위에서 돌아가던 VM이나 컨테이너를 자동으로 다른 노드에서 재시작해주는 거예요. 사람이 개입하지 않아도 된다는 게 핵심이죠.

구성 요소	역할	없으면?
Corosync	노드 간 클러스터 통신 및 하트비트(heartbeat) 관리	노드 상태 파악 불가
Pve-cluster (pmxcfs)	클러스터 파일시스템, 설정 동기화	설정 불일치 발생
HA Manager	VM/CT 자동 복구 로직 담당	자동 페일오버(failover) 불가
Fencing (펜싱)	장애 노드를 강제로 격리하는 메커니즘	스플릿 브레인(split-brain) 위험
공유 스토리지	노드 간 VM 디스크 이미지 공유	HA 적용 대상 VM 제한

여기서 펜싱(Fencing)이 제일 중요한데, 많은 분들이 이걸 빼먹고 설정하다가 나중에 낭패를 보더라고요. 장애 노드가 실제로 죽었는지, 아니면 네트워크만 끊긴 건지 확인하고 강제로 전원을 끄거나 격리하는 장치예요. 없으면 같은 VM이 두 노드에서 동시에 실행되는 최악의 상황이 생길 수 있거든요.

사전 준비: Proxmox 클러스터 구성 전 필수 체크사항

본격적인 설정 전에 체크해야 할 항목들이 있어요. 이거 안 하고 넘어가면 나중에 반드시 삽질하게 됩니다. 제가 보장합니다 ㅎㅎ.

• 노드 수: 최소 3개 (홀수 권장 — 쿼럼 계산 때문에)
• Proxmox VE 버전: 모든 노드가 동일한 버전이어야 함 (2026년 기준 PVE 8.x)
• 네트워크: 클러스터 통신용 전용 네트워크 분리 권장 (1Gbps 이상)
• 시간 동기화: NTP 설정 필수 — 시간이 틀리면 Corosync가 미칩니다
• 공유 스토리지: Ceph, NFS, iSCSI 등 — HA가 적용될 VM 디스크는 반드시 공유 스토리지에 있어야 해요
• 호스트명/DNS: 각 노드의 호스트명이 서로 해석 가능해야 함

저는 홈랩에서 pve-node1, pve-node2, pve-node3 이렇게 3대로 구성하고 있고, 클러스터 통신은 별도의 10.10.10.0/24 네트워크를 사용해요. 이거 분리 안 하면 VM 트래픽이랑 섞여서 하트비트 지연이 생기거든요.

단계별 실전 구성: Proxmox 클러스터 HA 설정하기

1단계: 클러스터 생성 (첫 번째 노드에서)

pve-node1에서 클러스터를 생성합니다. GUI로 해도 되지만, CLI가 훨씬 빠르고 정확해요.

# pve-node1에서 실행
pvecm create my-homelab-cluster --link0 10.10.10.1

# 클러스터 상태 확인
pvecm status

--link0 옵션에는 클러스터 통신 전용 NIC의 IP를 넣어주세요. 메인 IP 쓰셔도 되긴 하는데, 분리하는 게 훨씬 안정적이더라고요.

2단계: 나머지 노드 합류

# pve-node2에서 실행
pvecm add 10.10.10.1 --link0 10.10.10.2

# pve-node3에서 실행
pvecm add 10.10.10.1 --link0 10.10.10.3

# node1에서 전체 노드 확인
pvecm nodes

합류할 때 SSH 비밀번호 입력을 요구하는데, 이건 정상이에요. Proxmox가 SSH로 접속해서 인증서를 교환하는 과정이거든요.

3단계: 공유 스토리지 설정 (Ceph 기준)

저는 홈랩에서 Proxmox 내장 Ceph를 쓰는데, 설정이 생각보다 간단해졌어요. 특히 PVE 8.x부터는 GUI에서 거의 다 됩니다.

# 각 노드에서 Ceph 패키지 설치
pveceph install --version reef

# Ceph 초기화 (node1에서)
pveceph init --network 10.10.20.0/24

# 모니터 데몬 추가 (각 노드에서)
pveceph mon create

# OSD(Object Storage Daemon) 추가 — /dev/sdb는 Ceph 전용 디스크
pveceph osd create /dev/sdb

# Ceph 풀(pool) 생성
pveceph pool create vm-pool --pg_num 128

# Proxmox 스토리지로 등록
pvesm add rbd ceph-storage --monhost 10.10.20.1,10.10.20.2,10.10.20.3 \
  --pool vm-pool --username admin --krbd 0

Ceph 말고 NFS나 iSCSI를 쓰셔도 됩니다. 중요한 건 모든 노드에서 접근 가능한 공유 스토리지여야 한다는 거예요.

4단계: 펜싱(Fencing) 설정

이게 진짜 중요한데 많이들 건너뛰더라고요. 펜싱 없이 HA 쓰면 스플릿 브레인(split-brain) 상황에서 데이터 손상이 생길 수 있어요.

가장 흔히 쓰는 방법은 IPMI/iDRAC/iLO 같은 BMC(Baseboard Management Controller, 원격 서버 관리 컨트롤러)를 이용한 펜싱이에요.

# fence-agents 설치
apt install fence-agents

# 펜싱 테스트 (node2의 IPMI로 상태 확인)
fence_ipmilan -a 192.168.1.102 -l admin -p yourpassword -o status

홈랩처럼 IPMI가 없는 환경이라면 WoL(Wake-on-LAN)이나 스마트 플러그를 이용한 펜싱도 가능해요. 완벽하진 않지만 없는 것보단 낫거든요.

▲ Proxmox VE GUI의 HA Manager 화면 — 리소스 그룹 설정, VM 상태, 펜싱 구성을 한눈에 확인할 수 있습니다.

5단계: HA 리소스 그룹 및 VM 등록

드디어 본론이에요! HA 매니저에 VM을 등록해봅시다.

# HA 그룹 생성 (특정 노드에 우선순위 부여)
ha-manager groupadd prod-group \
  --nodes "pve-node1:3,pve-node2:2,pve-node3:1" \
  --restricted 0 \
  --nofailback 0

# VM 100번을 HA 리소스로 등록
ha-manager add vm:100 \
  --group prod-group \
  --max_restart 3 \
  --max_relocate 2

# HA 상태 확인
ha-manager status

# 특정 VM의 HA 설정 확인
ha-manager config vm:100

여기서 --max_restart는 같은 노드에서 재시작 시도 횟수, --max_relocate는 다른 노드로 이전 시도 횟수예요. 너무 크게 잡으면 장애 상황에서 복구가 지연될 수 있으니 적당히 설정하세요.

GUI로 하시려면 Datacenter → HA → Add 메뉴에서 쉽게 할 수 있어요. 저도 처음 설정할 때는 GUI로 감 잡고, 이후에는 CLI로 자동화하는 편이에요.

6단계: HA 서비스 활성화 확인

# HA 관련 서비스 상태 확인
systemctl status pve-ha-lrm  # Local Resource Manager
systemctl status pve-ha-crm  # Cluster Resource Manager
systemctl status corosync
systemctl status pve-cluster

# 클러스터 전체 상태 한 번에 확인
pvecm status
ha-manager status

⚠️ 실제로 겪은 Proxmox HA 트러블슈팅 사례들

설정하다 보면 반드시 뭔가 꼬이는 순간이 와요. 제가 겪은 것들 공유할게요.

문제 1: 쿼럼 손실 (Quorum Lost)

노드 하나 내렸더니 클러스터 전체가 멈춰버린 적 있었어요. 3노드 중 1개만 내렸는데도요.

# 쿼럼 상태 확인
pvecm status | grep Quorum

# 긴급 상황에서 쿼럼 강제 설정 (절대 프로덕션에서 함부로 쓰지 마세요!)
# 이건 정말 최후의 수단입니다
pvecm expected 1

원인은 Corosync 링크 설정이 잘못돼 있었어요. /etc/corosync/corosync.conf에서 링크 주소가 메인 IP로 잡혀있던 거였죠. 클러스터 전용 IP로 수정하고 나서 해결됐습니다.

문제 2: VM이 HA 대상이 안 되는 경우

VM 디스크가 로컬 스토리지에 있으면 HA 등록 자체가 안 돼요. 반드시 공유 스토리지로 이전해야 합니다.

# VM 100의 디스크를 로컬에서 Ceph로 마이그레이션
qm move-disk 100 scsi0 ceph-storage --delete 1

# 마이그레이션 후 디스크 위치 확인
qm config 100 | grep scsi

문제 3: 펜싱 실패로 HA가 동작 안 하는 경우

이건 진짜 당황스러웠어요. 노드가 죽었는데 VM이 다른 노드로 안 넘어가는 거예요. 로그 확인해보니 펜싱 에이전트가 응답을 못 받아서 HA 매니저가 안전하게 대기 중인 거였어요.

# HA 매니저 로그 확인
journalctl -u pve-ha-crm -f
journalctl -u pve-ha-lrm -f

# 펜싱 에이전트 직접 테스트
fence_ipmilan -a [IPMI_IP] -l [USER] -p [PASS] -o status

# 수동 펜싱 (테스트용)
fence_ipmilan -a [IPMI_IP] -l [USER] -p [PASS] -o reboot

결국 IPMI 비밀번호가 변경됐던 게 문제였어요. 펜싱 설정도 업데이트해주니까 바로 해결됐습니다. 이런 거 있을 줄은... ㅎㅎ

문제 4: 시간 동기화 문제

# NTP 상태 확인
timedatectl status
chronyc tracking

# /etc/chrony/chrony.conf 설정
pool ntp.ubuntu.com iburst
pool time.cloudflare.com iburst

# chrony 재시작
systemctl restart chronyd

HA 동작 검증: 실제로 노드를 꺼봤습니다

설정만 하고 테스트 안 하면 진짜 장애 때 믿을 수 없잖아요. 저는 분기마다 한 번씩 의도적으로 노드를 내려서 HA가 제대로 동작하는지 확인해요.

1. 테스트할 노드에서 실행 중인 HA VM 확인
2. 해당 노드의 전원을 강제로 차단 (graceful shutdown이 아닌 hard power off)
3. HA 매니저가 장애를 감지하고 VM을 다른 노드에서 재시작하는 시간 측정
4. 서비스 가용성 확인

# 다른 노드에서 HA 복구 과정 실시간 모니터링
watch -n 2 'ha-manager status; echo "---"; pvecm status'

# VM ping 테스트로 다운타임 측정
ping -i 0.5 [VM_IP] | ts '%H:%M:%.S'

# 복구 후 VM이 어느 노드에서 실행 중인지 확인
qm status 100
pct status 200

▲ HA 페일오버 테스트 결과 — 노드 장애 감지부터 VM 재시작 완료까지 약 90초 소요, ping 손실 패킷 수와 복구 타임라인을 시각화한 모니터링 화면입니다.

제 환경에서는 보통 60~120초 안에 VM이 다른 노드에서 살아납니다. 이 시간은 fence_delay, ha-manager의 타임아웃 설정에 따라 달라지는데, 너무 짧게 잡으면 일시적인 네트워크 끊김에도 불필요한 페일오버가 발생하니 주의하세요.

VM 백업과 HA: 같이 챙겨야 합니다

HA가 있다고 백업을 소홀히 하면 안 돼요. HA는 하드웨어 장애에 대한 자동 복구지, 데이터 손실에 대한 보호는 아니거든요. 스토리지 자체가 날아가면 HA도 소용없습니다.

# Proxmox Backup Server(PBS)를 이용한 자동 백업 설정
# /etc/pve/jobs.cfg에 추가되거나 GUI에서 설정 가능

# vzdump으로 VM 백업 (CLI)
vzdump 100 --storage pbs-storage --mode snapshot --compress zstd

# 백업 스케줄 확인
pvesched list

저는 Proxmox Backup Server(PBS)를 별도 머신에 구축해서 매일 새벽 2시에 자동 백업 돌리고 있어요. VM 백업 관련해서는 별도 글로 자세히 다룰 예정이니 참고해 주세요.

정리: Proxmox 클러스터 HA 완성 체크리스트

▲ Proxmox VE 클러스터 HA 구성 완료 체크리스트 — 클러스터 생성부터 펜싱, 공유 스토리지, HA 리소스 등록, 백업까지 단계별 요약 인포그래픽입니다.

단계	항목	상태
1	3개 이상 노드 준비, 동일 PVE 버전	✅ 필수
2	클러스터 전용 네트워크 분리	✅ 강력 권장
3	NTP 시간 동기화 설정	✅ 필수
4	공유 스토리지 구성 (Ceph/NFS/iSCSI)	✅ 필수
5	펜싱 에이전트 설정 및 테스트	✅ 필수
6	HA 그룹 및 리소스 등록	✅ 필수
7	실제 페일오버 테스트	✅ 필수
8	VM 백업 스케줄 설정	✅ 강력 권장

마치며: 장애는 반드시 옵니다

13년 동안 인프라 일을 하면서 배운 게 있다면, 장애는 일어나지 않는 게 아니라 언제 일어나느냐의 문제라는 거예요. Proxmox 클러스터 HA는 그 순간을 위한 보험이에요.

처음 설정할 때는 복잡해 보이지만, 한 번 제대로 구성해두면 정말 든든합니다. 새벽 3시 전화 받고도 "어, 자동으로 넘어갔네" 하고 다시 잘 수 있거든요. 그 경험, 정말 소중하더라고요.

궁금한 점이 있으시면 댓글로 남겨주세요. 다음 글에서는 Proxmox에서 Ceph 스토리지 세부 튜닝과 PBS(Proxmox Backup Server) 구축을 다룰 예정이에요. 이 두 가지가 HA랑 같이 있으면 진짜 완성된 인프라가 됩니다. 기대해 주세요! 🎉

자주 묻는 질문 (FAQ)

Q. Proxmox HA는 몇 대부터 가능한가요?

기술적으로는 2대도 가능하지만, 쿼럼 구성을 위해 최소 3대를 강력히 권장합니다. 2대 구성은 한 노드가 죽으면 쿼럼을 잃어 클러스터가 동작을 멈춰요. QDevice(외부 쿼럼 장치)를 쓰면 2노드도 어느 정도 보완이 가능하더라고요.

Q. 펜싱 장치가 없으면 HA를 쓰면 안 되나요?

공식적으로는 펜싱 없이도 동작하지만, 프로덕션 환경에서는 절대 권장하지 않아요. 펜싱 없이 HA를 쓰면 스플릿 브레인 상황에서 데이터 손상이 발생할 수 있거든요. 홈랩이라면 소프트웨어 펜싱이나 스마트 플러그로라도 구성하세요.

Q. HA VM의 라이브 마이그레이션(Live Migration)과 HA 페일오버의 차이는?

라이브 마이그레이션은 VM이 실행 중인 상태에서 다운타임 없이 다른 노드로 이전하는 거예요. HA 페일오버는 노드 장애 시 VM을 다른 노드에서 재시작하는 거라 약간의 다운타임이 발생해요. 라이브 마이그레이션은 계획된 유지보수에, HA는 비계획 장애 대응에 쓰입니다.

📚 함께 읽으면 좋은 글

• GPU 패스스루 설정 완벽 가이드: 게임 및 AI 워크로드 최적화
• 리눅스 커널 7.0 출시 현황과 6.x 최신 동향 완벽 가이드
• 커널 패닉 해결: 부팅 오류 트러블슈팅 완벽 가이드
• Proxmox 게임 서버 호스팅: 가상화로 저비용 구축하기