12. Proxmox VE클러스터와 HA구성

Proxmox VE 클러스터·백업·HA 운영

Proxmox VE 클러스터는 여러 물리 노드를 하나의 가상화 관리 영역으로 묶어 VM과 컨테이너를 운영하는 구조입니다.

클러스터를 구성하면 여러 노드의 VM, 컨테이너, 권한, 스토리지, 백업 작업을 하나의 Web UI·CLI·API에서 관리할 수 있습니다. 또한 마이그레이션, HA, shared storage, Ceph 같은 기능을 설계할 수 있습니다.

하지만 클러스터를 만들었다고 자동으로 무중단 서비스가 구현되는 것은 아닙니다.

High Availability
├── Multiple Proxmox VE Nodes
├── Reliable Corosync Network
├── Quorum
├── Fencing / Watchdog
├── Shared or Replicated Storage
├── HA Resource Configuration
├── N+1 Capacity
├── Backup Storage
├── Restore Runbook
└── Regular Recovery Drill

실제 가용성은 hypervisor cluster뿐 아니라 storage, network, application, backup, recovery procedure를 함께 설계해야 합니다.

클러스터 구조

Proxmox VE Cluster
├── pve-01
│   ├── VM 101
│   └── VM 102
├── pve-02
│   ├── VM 201
│   └── VM 202
└── pve-03
    ├── VM 301
    └── VM 302

Proxmox VE는 dedicated manager node 하나에만 의존하지 않는 multi-master 구조입니다. 정상 cluster node 어디에 접속해도 전체 cluster를 관리할 수 있습니다.

Administrator
        │
 ┌──────┼──────┐
 ▼      ▼      ▼
pve-01 pve-02 pve-03
Web UI / API / CLI
        │
 Corosync + pmxcfs

다만 관리 UI 접근이 가능한 것과 VM이 다른 node에서 자동 재기동되는 것은 다릅니다. 자동 HA restart에는 quorum, fencing, storage accessibility, target node capacity가 모두 필요합니다.

Corosync와 pmxcfs

Corosync는 cluster node 간 communication, membership, quorum, node failure detection을 담당합니다.

pmxcfs는 Proxmox Cluster File System입니다. /etc/pve에 VM, container, storage, user, permission, firewall 같은 Proxmox 설정을 제공하고, Corosync cluster communication을 기반으로 node 간 실시간 복제를 수행합니다.

pmxcfs Configuration Database
        │
Corosync Cluster Communication
        │
Real-time Configuration Replication
        │
/etc/pve on All Cluster Nodes

주요 설정 경로는 다음과 같습니다.

/etc/pve/
├── datacenter.cfg
├── storage.cfg
├── user.cfg
├── firewall/
├── nodes/<node-name>/qemu-server/<VMID>.conf
└── nodes/<node-name>/lxc/<CTID>.conf

/etc/pve는 일반 filesystem이 아닙니다. 설정 파일을 대량 직접 수정하기보다 Web UI, CLI, REST API, Terraform, Ansible 같은 관리 경로를 사용합니다.

Corosync는 높은 bandwidth보다 낮은 latency, packet loss가 없는 안정적인 network가 중요합니다.

권장하지 않는 구조

Single Network
├── Management
├── Corosync
├── Ceph / NFS / iSCSI
├── Backup
├── Migration
└── VM Service Traffic

운영 cluster에서는 Corosync용 dedicated NIC 또는 최소 dedicated VLAN을 검토합니다. 단, VLAN은 logical separation일 뿐 physical NIC·switch·uplink 장애 domain을 완전히 분리하지는 않습니다.

Quorum과 2·3노드 설계

Quorum은 cluster가 정상적인 다수 구성원을 확보했는지 판단하는 기준입니다.

3-Node Cluster

Nodes: 3
Expected Votes: 3
Quorum: 2

3노드 중 2노드 이상이 통신하면 quorum을 유지할 수 있습니다.

Normal
├── pve-01: Online
├── pve-02: Online
└── pve-03: Online
    └── Quorate: Yes

One Node Failure
├── pve-01: Online
├── pve-02: Online
└── pve-03: Offline
    └── Quorate: Yes

Quorum은 network partition에서 양쪽이 동시에 같은 VM을 실행하는 split brain 위험을 줄입니다.

Split Brain Risk

pve-01
└── VM 401 starts

pve-02
└── VM 401 also starts

Shared Storage
└── Same VM Disk Corruption Risk

운영 HA는 일반적으로 3노드 이상을 우선 검토합니다. 3노드 구성은 한 node failure 후에도 quorum을 유지하기 쉽고 Ceph HCI의 기본 단위에도 적합합니다.

2노드 cluster는 가능하지만, node failure와 corosync network partition을 구분하기 어렵습니다. 따라서 QDevice 같은 third-party vote provider를 검토합니다.

2-Node Cluster with QDevice

pve-01 ───── pve-02
   │            │
   └── qdevice ─┘

QDevice는 quorum 판단을 보조하지만, workload node, shared storage, backup, N+1 capacity, network redundancy를 대체하지 않습니다.

Fencing과 HA

HA에서 가장 위험한 상태는 장애로 판단된 원래 node가 실제로 살아 있고, 같은 VM이 다른 node에서도 시작되는 경우입니다.

Proxmox VE HA는 fencing과 cluster-wide locking을 사용해 장애 node의 resource가 중복 실행되지 않도록 보호합니다. watchdog 기반 fencing은 failure node가 실제로 offline 상태임을 보장한 뒤 HA resource를 정상 node에서 재기동하는 데 사용됩니다.

Node Failure Detection
        │
        ▼
Fencing / Watchdog
        │
        ▼
Original Node Confirmed Offline
        │
        ▼
HA Resource Restart on Healthy Node

HA는 일반적으로 live state migration이 아니라 VM restart 방식입니다.

Node Failure
        │
Failure Detection
        │
Fencing
        │
VM Restart on Another Node
        │
Guest OS Boot
        │
Application Startup
        │
Service Available

따라서 HA는 zero downtime을 보장하지 않습니다. 실제 service recovery time은 failure detection, VM boot, database recovery, application startup, load balancer health check, DNS TTL, client retry 정책에 영향을 받습니다.

HA resource 등록 예시입니다.

ha-manager add vm:401
ha-manager status

모든 VM을 HA 대상으로 등록하면 failure 상황에서 남은 node capacity가 부족할 수 있습니다. 중요 service를 먼저 정하고, HA Group·failover policy·restart/relocate 정책·N+1 capacity를 함께 설계합니다.

N+1 capacity는 평균 resource usage가 아니라, 가장 큰 failure node의 핵심 HA workload와 storage recovery load를 남은 node가 함께 수용할 수 있는지로 산정합니다.

Migration, HA, Backup, DR

기능	목적	대표 상황
Cluster	여러 node 통합 관리	운영 단순화
Live Migration	실행 중 VM을 다른 node로 이동	계획된 유지보수
HA	node failure 후 VM·CT 재기동	물리 node 장애
Backup	과거 시점 VM·data 복구	삭제, 논리 손상, 랜섬웨어
Snapshot	단기 rollback	patch·configuration 변경
Replication	다른 node·site에 data 복제	local storage redundancy
DR	site-level recovery	rack, power, storage, datacenter 장애

Live migration 예시입니다.

qm migrate 401 pve-02 --online

migration에는 CPU compatibility, target node capacity, storage accessibility 또는 storage migration path, stable migration network가 필요합니다.

스토리지와 HA

HA restart가 가능하려면 target node가 VM disk에 접근할 수 있어야 합니다.

스토리지 구조	HA restart	특성
Local LVM only	즉시 불가	장애 node의 local disk에만 VM disk 존재
Shared NFS / iSCSI / FC	가능	여러 node가 같은 VM disk에 접근
Ceph RBD	가능	distributed replicated storage
Local ZFS + Replication	조건부 가능	asynchronous replication으로 RPO 존재

로컬 LVM·로컬 ZFS에만 VM disk가 있는 경우 node failure 후 다른 node에서 즉시 VM을 시작할 수 없습니다.

pve-01
└── local-lvm
    └── VM 401 Disk

pve-01 Failure
        │
        ▼
pve-02
└── VM 401 Disk 없음

NFS, iSCSI, FC SAN, Ceph RBD 같은 shared/distributed storage에서는 다른 node가 VM disk에 접근할 수 있어 HA restart와 migration에 유리합니다.

로컬 ZFS cluster에서는 Proxmox Storage Replication으로 VM disk를 다른 node에 주기적으로 복제할 수 있습니다. 다만 이는 asynchronous replication이므로 replication interval 이후 변경은 장애 시 유실될 수 있습니다.

Ceph는 shared storage를 구성하는 강력한 선택지지만 모든 cluster의 필수 요소는 아닙니다. Ceph는 node 수, OSD, network, replication, failure domain, backfill/rebalance, recovery time, monitoring 역량을 함께 요구합니다.

Proxmox Backup Server

Proxmox Backup Server(PBS)는 Proxmox VE VM·container backup과 restore를 위한 전용 backup platform입니다.

Proxmox VE Cluster
        │
        ▼
Proxmox Backup Server
├── Datastore
├── Deduplication
├── Incremental Backup
├── Compression
├── Encryption
├── Prune / Garbage Collection
├── Verify Job
├── Sync Job
└── Tape Backup

PBS는 가능한 한 Proxmox cluster와 별도 node, separate storage, separate power path, separate access control로 구성합니다.

Proxmox VE Cluster
        │
        ▼
Separate PBS
├── Separate Storage
├── Separate Power Path
├── Separate Access Control
└── Optional Off-site Sync

PBS encryption을 사용한다면 encryption key와 recovery key를 backup datastore와 분리된 안전한 위치에 보관합니다. key를 잃으면 encrypted backup을 복구하지 못할 수 있습니다.

보존 정책과 무결성 검증

Prune은 retention rule에 따라 backup snapshot을 정리합니다. 더 이상 참조되지 않는 chunk data는 Garbage Collection에서 회수될 수 있습니다.

keep-last: 3
keep-daily: 14
keep-weekly: 8
keep-monthly: 12
keep-yearly: 3

Verify Job은 backup data integrity를 확인하지만, application restore를 보장하지는 않습니다.

Backup Lifecycle
├── Backup
├── Prune
├── Garbage Collection
├── Verify
└── Restore Drill

PBS version별 CLI option은 다를 수 있으므로 verify 실행 전 현재 도움말을 확인합니다.

proxmox-backup-manager help verify
proxmox-backup-manager verify datastore-prod

권장 주기는 다음과 같습니다.

Daily: Backup
Weekly: Prune / Verify
Monthly: VM Restore Drill
Quarterly: Application Restore or HA Test
Yearly: DR Test

Database, GitLab, Harbor, Kubernetes etcd 같은 stateful service는 VM backup 외에도 database logical/physical backup, WAL·binlog archive, application-level restore procedure를 함께 설계합니다.

복구와 훈련

복구는 backup file을 restore하는 작업보다 넓은 절차입니다.

Restore Planning
├── Recovery Point 선택
├── New VM / CT ID
├── Target Node and Storage
├── Isolated VLAN
├── IP / Hostname Conflict Prevention
├── Application Dependency Check
├── Data Integrity Check
└── Service Cutover

VM 복구 예시입니다.

qmrestore \
  /mnt/pve/backup-nfs/dump/vzdump-qemu-401-<timestamp>.vma.zst \
  901 \
  --storage local-lvm

Container 복구 예시입니다.

pct restore \
  902 \
  /mnt/pve/backup-nfs/dump/vzdump-lxc-201-<timestamp>.tar.zst \
  --storage local-lvm

복구 후에는 운영 network에 즉시 연결하지 않습니다.

Safe Restore Procedure
├── New VM / CT ID
├── Isolated VLAN
├── IP conflict prevention
├── OS boot check
├── Filesystem check
├── Guest Agent check
├── Application / DB integrity check
└── Approval before production cutover

shared disk만 사용하는 non-HA guest는 원본 node가 완전히 fenced/offline임을 확인한 뒤 configuration file을 online node directory로 옮겨 수동 복구할 수 있습니다.

mv /etc/pve/nodes/pve-01/qemu-server/401.conf \
   /etc/pve/nodes/pve-02/qemu-server/

이 방식은 HA-managed guest에는 사용하지 않으며, 원본 node가 다시 VM을 시작할 가능성이 없어야 합니다. local disk를 사용하는 guest는 이런 방식으로 복구할 수 없고 node recovery 또는 backup restore가 필요합니다.

운영 체크리스트

일일

pvecm status에서 Quorate: Yes인지 확인
node·Corosync·HA resource 상태 확인
storage와 Ceph health 확인
backup 성공 여부와 PBS datastore 여유 공간 확인
node CPU·memory·disk I/O·hardware alert 확인
최근 task failure와 error log 확인

주간

Prune·Verify Job 결과 확인
새 VM·CT가 backup policy에 포함됐는지 확인
오래된 snapshot과 failed task 정리
package·kernel version drift 확인
Corosync RTT·packet loss와 storage growth 확인

월간·분기

sample VM·CT restore drill 수행
중요 application restore 검증
HA failover test 수행
RPO·RTO 측정
N+1 capacity 재산정
backup storage growth와 DR runbook 검토

핵심 정리

Proxmox VE cluster는 multi-master 관리 구조이지만, cluster 생성만으로 HA와 무중단 서비스가 완성되지는 않습니다.
Corosync는 cluster communication·membership·quorum을, pmxcfs는 /etc/pve configuration replication을 담당합니다.
Quorum과 fencing은 split brain과 동일 resource의 이중 실행을 방지하는 핵심 보호 장치입니다.
운영 HA는 일반적으로 3node 이상을 우선 검토하며, 2node 구성은 QDevice와 별도 failure domain 설계가 필요합니다.
Live migration은 계획된 이동, HA는 node failure 후 재기동, Backup은 과거 data 복구, DR은 site-level recovery를 위한 기능입니다.
HA restart에는 target node capacity와 VM disk accessibility가 필요합니다.
Local ZFS replication은 local storage redundancy를 제공할 수 있지만 asynchronous replication이므로 RPO가 존재합니다.
PBS는 incremental backup, deduplication, retention, verification, sync 기능을 제공하지만 Restore Drill을 대체하지 않습니다.
HA, backup, snapshot, replication, DR은 서로 다른 failure scenario를 다루므로 함께 설계해야 합니다.

참고 자료

backup cluster corosync disaster-recovery ha high-availability pbs proxmox proxmox-backup-server proxmox-ve quorum

작성일: 2026년 9월 10일 , 마지막 업데이트: 2026년 9월 10일