Proxmox VE Cluster & HA

단일 노드는 테스트용 — 프로덕션이면 클러스터와 HA가 기본임

📌 이 글의 목적

단일 노드 Proxmox는 하드웨어 장애 시 모든 VM/CT가 중단됨. 클러스터와 HA(High Availability)는 이 문제를 해결함.

이 글을 읽고 나면:

Proxmox 클러스터의 아키텍처(Corosync, pmxcfs)를 이해할 수 있음
쿼럼의 개념과 노드 수 설계를 할 수 있음
HA Manager로 자동 페일오버를 구성할 수 있음
펜싱(Fencing)의 필요성과 설정 방법을 알 수 있음

1. 클러스터 아키텍처

1.1 구성 요소

컴포넌트	역할
Corosync	노드 간 통신, 멤버십 관리, 쿼럼 투표
pmxcfs	클러스터 파일시스템 — `/etc/pve/`를 전 노드에 동기화
HA Manager	VM/CT 상태 감시, 장애 시 자동 재시작/마이그레이션
Watchdog	노드 자체 감시, 응답 없으면 강제 리부팅 (펜싱)

1.2 Corosync

Corosync는 클러스터의 심장임. 모든 노드가 서로 "살아있다"는 것을 확인하는 하트비트 프로토콜.

Corosync 설정 파일:

cat /etc/pve/corosync.conf

# 주요 설정
totem {
    version: 2
    cluster_name: proxmox-cluster
    transport: knet              # 기본 전송 프로토콜
    
    interface {
        linknumber: 0
    }
}

nodelist {
    node {
        name: pve1
        nodeid: 1
        ring0_addr: 192.168.1.101
    }
    node {
        name: pve2
        nodeid: 2
        ring0_addr: 192.168.1.102
    }
    node {
        name: pve3
        nodeid: 3
        ring0_addr: 192.168.1.103
    }
}

quorum {
    provider: corosync_votequorum
}

1.3 pmxcfs (Proxmox Cluster File System)

/etc/pve/에 마운트되는 가상 파일시스템. 모든 클러스터 설정을 전 노드에 실시간 동기화함.

경로	내용
`/etc/pve/corosync.conf`	클러스터 설정
`/etc/pve/storage.cfg`	스토리지 설정
`/etc/pve/user.cfg`	사용자/권한
`/etc/pve/firewall/`	방화벽 규칙
`/etc/pve/nodes/<node>/qemu-server/`	VM 설정
`/etc/pve/nodes/<node>/lxc/`	CT 설정
`/etc/pve/ha/`	HA 설정

💡 Node 1에서 VM 설정을 바꾸면 Node 2, 3에서도 즉시 반영됨. 별도의 동기화 작업 불필요.

2. 쿼럼 (Quorum)

2.1 쿼럼이란

쿼럼 = 클러스터 의사결정을 위한 최소 투표 수. 과반수 노드가 살아있어야 클러스터가 동작함.

2.2 노드 수별 쿼럼

총 노드	쿼럼 (과반수)	허용 장애	비고
1	1	0	클러스터 아님
2	2	0	⚠️ HA 의미 없음
3	2	1	✅ 최소 HA
4	3	1	3노드와 동일한 장애 허용
5	3	2	✅ 좋음
7	4	3	대규모

⚠️ 짝수 노드는 비효율적임. 4노드와 3노드의 장애 허용 수가 같음(1대). 홀수가 효율적: 3, 5, 7.

2.3 2노드 클러스터 — QDevice

2노드만 있으면 1대 장애 시 쿼럼을 잃음. QDevice로 해결 가능:

QDevice는 리소스가 거의 필요 없는 외부 서버(Raspberry Pi도 가능)에 설치함.

# QDevice 서버 (외부 Debian/Ubuntu)
apt install corosync-qnetd -y
systemctl enable --now corosync-qnetd

# Proxmox 노드에서 QDevice 추가
apt install corosync-qdevice -y
pvecm qdevice setup <qdevice-server-ip>

# 상태 확인
pvecm status

3. 클러스터 구성

3.1 사전 요구사항

요구사항	설명
동일 Proxmox 버전	모든 노드 동일 메이저 버전
DNS/호스트명 해석	각 노드가 서로의 호스트명을 해석 가능
네트워크 연결	노드 간 UDP 5405 통신 가능
시간 동기화	NTP로 시간 일치 (수 초 이내)
SSH root 접근	클러스터 구성 시 필요
빈 클러스터 설정	기존 클러스터에 속하지 않은 상태

⚠️ VM이 있는 노드를 클러스터에 추가할 때 VMID 충돌에 주의. 가능하면 빈 노드를 추가하는 것이 안전함.

3.2 클러스터 생성

# === Node 1 (첫 번째 노드) ===

# 클러스터 생성
pvecm create my-cluster

# 상태 확인
pvecm status

# === Node 2 (추가 노드) ===

# 클러스터 조인
pvecm add 192.168.1.101
# Node 1의 root 비밀번호 입력
# SSH fingerprint 확인

# === Node 3 (추가 노드) ===
pvecm add 192.168.1.101

조인 과정:

3.3 클러스터 상태 확인

# 클러스터 상태 요약
pvecm status

# 출력 예시:
# Cluster information
# -------------------
# Name:             my-cluster
# Config Version:   3
# Transport:        knet
# Secure auth:      on
#
# Quorum information
# ------------------
# Date:             Thu Feb 26 15:00:00 2026
# Quorum provider:  corosync_votequorum
# Nodes:            3
# Node ID:          1
# Ring ID:          1.15
# Quorate:          Yes
#
# Votequorum information
# ----------------------
# Expected votes:   3
# Highest expected: 3
# Total votes:      3
# Quorum:           2
# Flags:            Quorate

# 노드 목록
pvecm nodes

# Corosync 상태
corosync-quorumtool -s

# 상세 멤버십
corosync-cmapctl | grep members

3.4 Corosync 네트워크 분리

Corosync 전용 네트워크를 분리하면 안정성이 높아짐.

# 클러스터 생성 시 Corosync 전용 링크 지정
pvecm create my-cluster --link0 10.10.50.101

# 이중화 링크 (Primary + Backup)
pvecm create my-cluster \
    --link0 10.10.50.101 \
    --link1 192.168.1.101

# 조인 시에도 링크 지정
pvecm add 10.10.50.101 --link0 10.10.50.102 --link1 192.168.1.102

💡 Corosync 네트워크 분리가 중요한 이유: VM 트래픽이 폭주해도 Corosync 하트비트에 영향을 주지 않음. Corosync가 불안정하면 쿼럼을 잃어 전체 클러스터가 중단될 수 있음.

4. HA (High Availability)

4.1 HA 동작 원리

HA Manager는 VM/CT를 감시하다가, 노드 장애 시 다른 노드에서 자동으로 재시작함.

4.2 HA 요구사항

요구사항	이유
최소 3노드 클러스터	쿼럼 확보
공유 스토리지	다른 노드에서 VM 디스크 접근
펜싱 메커니즘	장애 노드 확실히 격리
HA 리소스 등록	감시할 VM/CT 지정

⚠️ 공유 스토리지 없이는 HA가 동작하지 않음. 로컬 스토리지에 있는 VM은 다른 노드에서 시작할 수 없음. Ceph, NFS, iSCSI 같은 공유 스토리지가 필수.

4.3 HA 리소스 등록

# VM을 HA 리소스로 등록
ha-manager add vm:100 --state started --group ha-group1 --max_restart 3 --max_relocate 2

# CT를 HA 리소스로 등록
ha-manager add ct:200 --state started

# HA 리소스 목록
ha-manager status

# HA 리소스 수정
ha-manager set vm:100 --state started --max_restart 5

# HA 리소스 제거
ha-manager remove vm:100

HA 상태:

상태	설명
`started`	항상 실행 상태 유지 (기본)
`stopped`	항상 중지 상태 유지
`ignored`	HA 감시하지 않음
`disabled`	HA 비활성화 (수동 관리)

4.4 HA 그룹

특정 VM을 특정 노드에서 우선 실행하도록 설정함.

# HA 그룹 생성
ha-manager groupadd ha-group1 --nodes pve1,pve2,pve3 --nofailback 0

# 특정 노드 우선 (priority)
ha-manager groupadd web-group --nodes pve1:2,pve2:1 --nofailback 0
# pve1 우선순위 2 (높음), pve2 우선순위 1

# VM을 그룹에 할당
ha-manager set vm:100 --group web-group

옵션	설명
`--nodes`	실행 가능 노드 목록 (priority 지정 가능)
`--nofailback`	0: 원래 노드 복구 시 되돌아감, 1: 현재 노드 유지
`--restricted`	1: 지정 노드에서만 실행 가능

4.5 HA 복구 정책

파라미터	기본값	설명
`max_restart`	1	같은 노드에서 재시작 시도 횟수
`max_relocate`	1	다른 노드로 이동 시도 횟수

5. 펜싱 (Fencing)

5.1 왜 펜싱이 필요한가

노드가 "정말 죽었는지" 확인하지 않고 VM을 다른 노드에서 시작하면, 두 노드에서 동시에 같은 VM이 실행될 수 있음 (Split-Brain). 이는 데이터 손상으로 이어짐.

5.2 펜싱 방법

방법	설명	추천
Software Watchdog	호스트 내부 watchdog 타이머	✅ 기본 (홈랩)
IPMI/iDRAC/iLO	원격 관리 인터페이스로 전원 제어	✅ 프로덕션
PDU	네트워크 PDU로 전원 차단	엔터프라이즈
SBD	Shared Block Device	Ceph/iSCSI 환경

Software Watchdog (기본):

Proxmox에서 기본으로 활성화되어 있음. HA Manager가 노드 응답을 확인할 수 없으면, 해당 노드의 watchdog이 타임아웃되어 자동으로 리부팅됨.

# Watchdog 상태 확인
cat /etc/default/pve-ha-manager
# WATCHDOG_MODULE=softdog

# Watchdog 디바이스 확인
ls -la /dev/watchdog*

# HA Manager 로그
journalctl -u pve-ha-lrm
journalctl -u pve-ha-crm

IPMI 펜싱 (프로덕션):

# fence-agents 설치
apt install fence-agents-all -y

# IPMI 테스트
ipmitool -H 10.10.99.101 -U admin -P password power status
ipmitool -H 10.10.99.101 -U admin -P password power off

# Proxmox HA에서 IPMI 펜싱 설정
# /etc/pve/ha/fence.cfg

6. 클러스터 운영

6.1 노드 추가/제거

# 노드 추가
# (새 노드에서)
pvecm add <기존노드IP>

# 노드 제거 (제거할 노드의 VM을 먼저 마이그레이션)
# (남아있는 노드에서)
pvecm delnode <노드이름>

# 제거 후 정리 (제거된 노드에서)
systemctl stop pve-cluster corosync
pmxcfs -l
rm -rf /etc/corosync/*
rm -rf /etc/pve/corosync.conf
killall pmxcfs
systemctl start pve-cluster

⚠️ 노드 제거 전 해당 노드의 모든 VM/CT를 마이그레이션하고, HA 리소스를 해제해야 함.

6.2 유지보수 모드

노드를 유지보수(업데이트, 하드웨어 교체)할 때:

# 1. HA 리소스를 다른 노드로 마이그레이션
ha-manager migrate vm:100 pve2

# 2. 또는 노드의 모든 VM을 마이그레이션
# 웹 UI → Node → Bulk Migrate

# 3. 노드에 VM이 없는 것을 확인 후 유지보수 진행
apt update && apt full-upgrade -y
reboot

6.3 모니터링 명령어

# 클러스터 상태
pvecm status
pvecm nodes
pvecm expected 3   # 예상 노드 수 확인/설정

# HA 상태
ha-manager status

# Corosync 상세
corosync-quorumtool -s
corosync-cfgtool -s     # 링크 상태

# HA 로그
journalctl -u pve-ha-crm --since "1 hour ago"
journalctl -u pve-ha-lrm --since "1 hour ago"

# 클러스터 리소스 사용량
pvesh get /cluster/resources --type vm

7. 실전 클러스터 설계

7.1 홈랩 3노드

항목	설정
노드	3 × Mini PC (Intel NUC 급)
Corosync	관리 네트워크 공유 (별도 분리 불필요)
스토리지	Ceph 3-way replica (각 노드 NVMe)
HA	Software Watchdog
네트워크	1GbE (충분)

7.2 프로덕션 소규모

항목	설정
노드	3 × 서버 (Dell/HP/Supermicro)
Corosync	전용 VLAN 또는 전용 NIC
스토리지	Ceph + 10GbE 또는 외부 NFS/iSCSI
HA	IPMI 펜싱
네트워크	10GbE + Bonding

7.3 프로덕션 대규모

항목	설정
노드	5~10+ 서버
Corosync	전용 NIC (이중화)
스토리지	Ceph (전용 OSD 노드 분리 가능)
HA	IPMI + SBD 이중 펜싱
네트워크	25GbE+, SDN
백업	PBS 전용 서버

8. 트러블슈팅

Q: "Not enough quorum votes" — 쿼럼 상실

# 상태 확인
pvecm status
corosync-quorumtool -s

# 긴급: 쿼럼 강제 설정 (⚠️ Split-Brain 위험!)
pvecm expected 1

# 원인 해결 후 정상 쿼럼 복구
pvecm expected 3

Q: 노드 조인 실패

# SSH 연결 확인
ssh root@<기존노드IP>

# 시간 동기화 확인 (양쪽 노드)
chronyc tracking

# 방화벽 확인 (UDP 5405)
ss -ulnp | grep 5405

# DNS/hosts 확인
cat /etc/hosts
ping <노드호스트명>

Q: HA가 VM을 재시작하지 않음

# HA 상태 확인
ha-manager status

# HA 리소스 확인
ha-manager config

# 공유 스토리지 확인 (VM 디스크가 공유 스토리지에 있는지)
qm config 100 | grep scsi0

# HA 로그 확인
journalctl -u pve-ha-crm --since "30 min ago"

Q: Split-Brain 발생

# ⚠️ Split-Brain = 두 노드가 서로 상대가 죽었다고 판단
# 데이터 손상 방지를 위해 하나를 즉시 중지

# 1. 상황 파악
pvecm status  # 각 노드에서 실행

# 2. 정상 노드 판별 (더 많은 VM이 있는 노드)

# 3. 비정상 노드 강제 종료 (IPMI 또는 물리적)
ipmitool -H <비정상노드IPMI> -U admin -P pass power off

# 4. 정상 노드에서 클러스터 복구
pvecm expected 2  # 살아있는 노드 수로 설정

10. VMware HA/DRS/FT 비교

대응 구조

VMware	Proxmox	비고
vCenter Cluster	Proxmox Cluster
vSphere HA	HA Manager	동작 방식 다름 (아래 상세)
DRS	❌ (수동 마이그레이션)	자동 부하 분산 없음
FT	❌ (앱 레벨 이중화)	VM 실시간 복제 지원 안 함
vMotion	`qm migrate --online`	Pre-copy 알고리즘 동일
Storage vMotion	`qm migrate --with-local-disks`
Admission Control	max_restart / max_relocate
Host Profiles	pmxcfs 동기화	설정 자동 동기화
Heartbeat Network	Corosync Network
STONITH	Fencing (Watchdog, IPMI)
DPM	❌	저부하 시 호스트 절전 기능 없음

핵심 차이점

HA 동작 방식 — VMware HA는 Master/Slave 선출 후 Master가 모든 호스트를 모니터링하고, 장애 시 VM을 재시작함. Proxmox HA는 Corosync 쿼럼 기반으로 CRM(Cluster Resource Manager)이 리소스 상태를 관리하고, LRM(Local Resource Manager)이 로컬 작업을 수행함. 동작 결과는 유사하지만 내부 구조가 다름.

DRS 부재 — VMware DRS는 클러스터 내 호스트 간 CPU/메모리 사용률을 모니터링하고, 불균형 시 vMotion을 자동 실행하여 VM을 재배치함. Proxmox에는 이 기능이 없음. 수동 마이그레이션이나 외부 스크립트로 보완해야 함.

FT 부재 — VMware FT는 Primary/Secondary VM을 실시간 동기화하여 호스트 장애 시 다운타임 없이 페일오버함. Proxmox/KVM에는 이 기능이 없음. 애플리케이션 레벨 클러스터링(DB Replication, 로드밸런서)으로 대체하는 것이 일반적임.

마이그레이션 — 둘 다 Pre-copy 알고리즘 사용. VMware는 Cross-vCenter vMotion(vSphere 7+)으로 vCenter간 마이그레이션이 가능한 점이 차별점. Proxmox는 클러스터 내에서만 가능.

정리

클러스터 & HA의 핵심 원칙:

HA 최소 3노드 — 2노드는 QDevice로 보완 가능하지만, 3노드가 표준
홀수 노드 — 3, 5, 7 노드가 효율적
공유 스토리지 필수 — Ceph, NFS, iSCSI
Corosync 네트워크를 보호 — 가능하면 전용 NIC/VLAN
펜싱은 HA의 전제 조건 — 없으면 Split-Brain → 데이터 손상
테스트 — 운영 전 반드시 장애 시뮬레이션

→ Backup & Restore — PBS, 백업 스케줄링, 복원 전략, 재해 복구

🔗 관련 문서

Proxmox VE Overview — 아키텍처
Network Configuration — Corosync 네트워크
Storage Configuration — Ceph, 공유 스토리지
Proxmox VE Series Index — 시리즈 목차

Proxmox VE Cluster & HA

📌 이 글의 목적

1. 클러스터 아키텍처

1.1 구성 요소

1.2 Corosync

1.3 pmxcfs (Proxmox Cluster File System)

2. 쿼럼 (Quorum)

2.1 쿼럼이란

2.2 노드 수별 쿼럼

2.3 2노드 클러스터 — QDevice

3. 클러스터 구성

3.1 사전 요구사항

3.2 클러스터 생성

3.3 클러스터 상태 확인

3.4 Corosync 네트워크 분리

4. HA (High Availability)

4.1 HA 동작 원리

4.2 HA 요구사항

4.3 HA 리소스 등록

4.4 HA 그룹

4.5 HA 복구 정책

5. 펜싱 (Fencing)

5.1 왜 펜싱이 필요한가

5.2 펜싱 방법

6. 클러스터 운영

6.1 노드 추가/제거

6.2 유지보수 모드

6.3 모니터링 명령어

7. 실전 클러스터 설계

7.1 홈랩 3노드

7.2 프로덕션 소규모

7.3 프로덕션 대규모

8. 트러블슈팅

10. VMware HA/DRS/FT 비교

대응 구조

핵심 차이점

정리

다음 글

🔗 관련 문서

📝 참고 자료

📌 이 글의 목적​

1. 클러스터 아키텍처​

1.1 구성 요소​

1.2 Corosync​

1.3 pmxcfs (Proxmox Cluster File System)​

2. 쿼럼 (Quorum)​

2.1 쿼럼이란​

2.2 노드 수별 쿼럼​

2.3 2노드 클러스터 — QDevice​

3. 클러스터 구성​

3.1 사전 요구사항​

3.2 클러스터 생성​

3.3 클러스터 상태 확인​

3.4 Corosync 네트워크 분리​

4. HA (High Availability)​

4.1 HA 동작 원리​

4.2 HA 요구사항​

4.3 HA 리소스 등록​

4.4 HA 그룹​

4.5 HA 복구 정책​

5. 펜싱 (Fencing)​

5.1 왜 펜싱이 필요한가​

5.2 펜싱 방법​

6. 클러스터 운영​

6.1 노드 추가/제거​

6.2 유지보수 모드​

6.3 모니터링 명령어​

7. 실전 클러스터 설계​

7.1 홈랩 3노드​

7.2 프로덕션 소규모​

7.3 프로덕션 대규모​

8. 트러블슈팅​

10. VMware HA/DRS/FT 비교​

대응 구조​

핵심 차이점​

정리​

다음 글​

🔗 관련 문서​

📝 참고 자료​

📌 이 글의 목적

1. 클러스터 아키텍처

1.1 구성 요소

1.2 Corosync

1.3 pmxcfs (Proxmox Cluster File System)

2. 쿼럼 (Quorum)

2.1 쿼럼이란

2.2 노드 수별 쿼럼

2.3 2노드 클러스터 — QDevice

3. 클러스터 구성

3.1 사전 요구사항

3.2 클러스터 생성

3.3 클러스터 상태 확인

3.4 Corosync 네트워크 분리

4. HA (High Availability)

4.1 HA 동작 원리

4.2 HA 요구사항

4.3 HA 리소스 등록

4.4 HA 그룹

4.5 HA 복구 정책

5. 펜싱 (Fencing)

5.1 왜 펜싱이 필요한가

5.2 펜싱 방법

6. 클러스터 운영

6.1 노드 추가/제거

6.2 유지보수 모드

6.3 모니터링 명령어

7. 실전 클러스터 설계

7.1 홈랩 3노드

7.2 프로덕션 소규모

7.3 프로덕션 대규모

8. 트러블슈팅

10. VMware HA/DRS/FT 비교

대응 구조

핵심 차이점

정리

다음 글

🔗 관련 문서

📝 참고 자료