Module 5: High Availability & Cluster Orchestration¶
학습 목표¶
이 모듈을 완료하면 다음을 이해할 수 있습니다:
- Proxmox VE 클러스터의 통신 메커니즘 (Corosync)
- Quorum 알고리즘과 split-brain 방지 원리
- HA 스택의 구성 요소와 동작 원리
- Fencing 메커니즘과 Watchdog 타이머
- 장애 시나리오별 복구 절차
https://noblog.nodove.com/#/blog/2025/AnimalsMind
1. 클러스터 아키텍처 개요¶
1.1 왜 클러스터인가?¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ 단일 노드 vs 클러스터 환경 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [Single Node] [Cluster (3+ Nodes)] │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Node 1 │ │ Node 1 │◄────┐ │
│ │ VM 100 │ │ VM 100 │ │ │
│ │ VM 101 │ │ VM 101 │ │ │
│ │ VM 102 │ └──────┬──────┘ │ │
│ └─────────────┘ │ │ │
│ │ │ Corosync │ │
│ ▼ │ Ring │ │
│ 노드 장애 시: ┌──────▼──────┐ │ │
│ → 모든 VM 중단 │ Node 2 │ │ │
│ → 수동 복구 필요 │ VM 103 │◄────┤ │
│ → 긴 다운타임 │ VM 104 │ │ │
│ └──────┬──────┘ │ │
│ │ │ │
│ ┌──────▼──────┐ │ │
│ │ Node 3 │ │ │
│ │ VM 105 │◄────┘ │
│ │ (Standby) │ │
│ └─────────────┘ │
│ │
│ 노드 장애 시: │
│ → HA가 자동 감지 │
│ → VM을 다른 노드로 마이그레이션 │
│ → 최소 다운타임 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
1.2 Proxmox VE 클러스터 스택¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ Proxmox VE Cluster Stack │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Application Layer │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ pve-ha-crm pve-ha-lrm pvedaemon pveproxy pvestatd │ │
│ │ (HA CRM) (HA LRM) (API) (Web) (Stats) │ │
│ └───────────────────────────────┬─────────────────────────────────────┘ │
│ │ │
│ Configuration Layer │ │
│ ┌───────────────────────────────▼─────────────────────────────────────┐ │
│ │ pmxcfs │ │
│ │ (Proxmox Cluster File System) │ │
│ │ /etc/pve/ - 클러스터 전체 동기화 │ │
│ └───────────────────────────────┬─────────────────────────────────────┘ │
│ │ │
│ Cluster Communication │ │
│ ┌───────────────────────────────▼─────────────────────────────────────┐ │
│ │ Corosync │ │
│ │ Cluster Engine + Kronosnet │ │
│ │ UDP 5405-5412 (멀티캐스트/유니캐스트) │ │
│ └───────────────────────────────┬─────────────────────────────────────┘ │
│ │ │
│ Network Layer │ │
│ ┌───────────────────────────────▼─────────────────────────────────────┐ │
│ │ Physical Network │ │
│ │ (전용 클러스터 네트워크 권장) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
2. Corosync 클러스터 통신¶
2.1 Corosync 개요¶
Corosync는 클러스터 노드 간의 신뢰할 수 있는 메시징을 제공하는 클러스터 엔진입니다.
주요 기능:
- 노드 멤버십 관리
- 그룹 통신 (Totem 프로토콜)
- Quorum 계산
- 설정 동기화
┌─────────────────────────────────────────────────────────────────────────────┐
│ Corosync 통신 구조 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────┐ │
│ │ Node 1 │ │
│ │ 10.10.10.1 │ │
│ │ (ring0) │ │
│ │ 10.20.20.1 │ │
│ │ (ring1) │ │
│ └───────┬───────┘ │
│ │ │
│ ┌────────────┼────────────┐ │
│ │ │ │ │
│ ┌─────────▼───┐ │ ┌────▼────────┐ │
│ │ Node 2 │ │ │ Node 3 │ │
│ │ 10.10.10.2 │◄──────┴──────►│ 10.10.10.3 │ │
│ │ (ring0) │ Heartbeat │ (ring0) │ │
│ │ 10.20.20.2 │ (UDP 5405) │ 10.20.20.3 │ │
│ │ (ring1) │ │ (ring1) │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ Kronosnet (knet): │
│ - 다중 링크 지원 (최대 8개) │
│ - 자동 페일오버 │
│ - 암호화 지원 │
│ - 압축 지원 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
2.2 Corosync 설정 파일¶
logging {
debug: off
to_syslog: yes
}
nodelist {
node {
name: node1
nodeid: 1
quorum_votes: 1
ring0_addr: 10.10.10.1
ring1_addr: 10.20.20.1
}
node {
name: node2
nodeid: 2
quorum_votes: 1
ring0_addr: 10.10.10.2
ring1_addr: 10.20.20.2
}
node {
name: node3
nodeid: 3
quorum_votes: 1
ring0_addr: 10.10.10.3
ring1_addr: 10.20.20.3
}
}
quorum {
provider: corosync_votequorum
}
totem {
cluster_name: proxmox-cluster
config_version: 3
interface {
linknumber: 0
}
interface {
linknumber: 1
}
ip_version: ipv4-6
link_mode: passive
secauth: on
version: 2
}
2.3 클러스터 상태 확인¶
# 클러스터 상태 전체 확인
$ pvecm status
Cluster information
-------------------
Name: proxmox-cluster
Config Version: 3
Transport: knet
Secure auth: on
Quorum information
------------------
Date: Thu Jan 10 10:00:00 2025
Quorum provider: corosync_votequorum
Nodes: 3
Node ID: 0x00000001
Ring ID: 1.abc123
Quorate: Yes
Votequorum information
----------------------
Expected votes: 3
Highest expected: 3
Total votes: 3
Quorum: 2
Flags: Quorate
Membership information
----------------------
Nodeid Votes Name
0x00000001 1 node1 (local)
0x00000002 1 node2
0x00000003 1 node3
# 노드 목록 확인
$ pvecm nodes
Membership information
----------------------
Nodeid Votes Name
1 1 node1 (local)
2 1 node2
3 1 node3
# Corosync 링 상태
$ corosync-cfgtool -s
Local node ID 1, transport knet
LINK ID 0 udp
addr = 10.10.10.1
status:
nodeid: 1: localhost
nodeid: 2: connected
nodeid: 3: connected
LINK ID 1 udp
addr = 10.20.20.1
status:
nodeid: 1: localhost
nodeid: 2: connected
nodeid: 3: connected
3. Quorum 알고리즘¶
3.1 Quorum이란?¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ Quorum 개념 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Quorum = 클러스터가 정상 작동하기 위해 필요한 최소 투표 수 │
│ │
│ 공식: Quorum = (Total Votes / 2) + 1 │
│ │
│ 예시 (3노드 클러스터): │
│ - Total Votes: 3 │
│ - Quorum: (3/2) + 1 = 2 │
│ - 즉, 최소 2개 노드가 통신 가능해야 함 │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Split-Brain 방지 │ │
│ ├─────────────────────────────────────────────────────────────────────┤ │
│ │ │ │
│ │ 네트워크 분리 시: │ │
│ │ │ │
│ │ [Partition A] [Partition B] │ │
│ │ Node1 + Node2 Node3 │ │
│ │ Votes: 2 Votes: 1 │ │
│ │ 2 >= 2 (Quorum) 1 < 2 (No Quorum) │ │
│ │ → 정상 운영 → Read-only, HA 중지 │ │
│ │ │ │
│ │ 결과: 하나의 파티션만 클러스터 운영 → Split-Brain 방지 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
3.2 노드 수에 따른 장애 허용¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ 노드 수별 장애 허용 테이블 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 노드 수 총 투표 Quorum 허용 장애 노드 권장 여부 │
│ ──────────────────────────────────────────────────────────── │
│ 2 2 2 0 ❌ 비권장 │
│ 3 3 2 1 ✓ 최소 권장 │
│ 4 4 3 1 △ 3노드와 동일 │
│ 5 5 3 2 ✓ 권장 │
│ 6 6 4 2 △ 5노드와 동일 │
│ 7 7 4 3 ✓ 대규모 권장 │
│ │
│ ⚠️ 2노드 클러스터 문제: │
│ - Quorum = 2, 장애 허용 = 0 │
│ - 한 노드라도 실패하면 전체 클러스터 중단 │
│ - 해결책: QDevice 추가 (아래 참조) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
3.3 QDevice (외부 투표 장치)¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ QDevice를 이용한 2노드 클러스터 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ │
│ │ QDevice │ │
│ │ (외부 서버) │ │
│ │ Vote: 1 │ │
│ └────────┬────────┘ │
│ │ │
│ ┌──────────────┴──────────────┐ │
│ │ │ │
│ ┌──────▼──────┐ ┌───────▼─────┐ │
│ │ Node 1 │ │ Node 2 │ │
│ │ Vote: 1 │◄────────────►│ Vote: 1 │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ Total Votes: 3 (Node1 + Node2 + QDevice) │
│ Quorum: 2 │
│ │
│ 시나리오: │
│ - Node2 장애: Node1(1) + QDevice(1) = 2 >= 2 ✓ │
│ - Node1 장애: Node2(1) + QDevice(1) = 2 >= 2 ✓ │
│ - 네트워크 분리: QDevice가 더 "건강한" 쪽에 투표 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
# QDevice 설정 (외부 서버에서)
$ apt install corosync-qdevice corosync-qnetd
$ pcs qdevice net setup
# 클러스터에 QDevice 추가
$ pvecm qdevice setup <qdevice-ip>
# QDevice 상태 확인
$ pvecm qdevice status
4. HA (High Availability) 스택¶
4.1 HA 아키텍처¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ Proxmox VE HA Stack │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ /etc/pve/ha/ │ │
│ │ resources.cfg (HA 리소스 정의) groups.cfg (노드 그룹) │ │
│ │ manager_status (CRM 상태) <node>/lrm_status (LRM 상태) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────┴─────────────┐ │
│ │ │ │
│ ┌──────▼──────┐ ┌──────▼──────┐ │
│ │ pve-ha-crm │ │ pve-ha-lrm │ │
│ │ (CRM) │ │ (LRM) │ │
│ │ │ │ │ │
│ │ Cluster │ │ Local │ │
│ │ Resource │ │ Resource │ │
│ │ Manager │ │ Manager │ │
│ │ │ │ │ │
│ │ - Master │ │ - 각 노드 │ │
│ │ 선출 │────────────►│ 에서 실행 │ │
│ │ - 전역 │ 명령 전달 │ - 로컬 VM │ │
│ │ 결정 │ │ 제어 │ │
│ │ - Fencing │ │ - Watchdog │ │
│ │ 조율 │ │ 관리 │ │
│ └─────────────┘ └──────┬──────┘ │
│ │ │
│ ┌──────▼──────┐ │
│ │ Watchdog │ │
│ │ Timer │ │
│ │ (softdog/ │ │
│ │ hardware) │ │
│ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
4.2 CRM (Cluster Resource Manager)¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ pve-ha-crm 동작 흐름 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [시작] │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Manager Lock 획득 │◄──── 클러스터에서 하나의 노드만 획득 가능 │
│ │ 시도 │ │
│ └──────────┬──────────┘ │
│ │ │
│ ┌───────┴───────┐ │
│ │ │ │
│ [성공] [실패] │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────┐ ┌─────────────────┐ │
│ │ Master │ │ Standby 상태 │ │
│ │ 역할 │ │ (Lock 대기) │ │
│ └────┬────┘ └─────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Master CRM 역할 │ │
│ ├─────────────────────────────────────────────────────────────┤ │
│ │ 1. 리소스 상태 모니터링 │ │
│ │ - /etc/pve/ha/manager_status 관리 │ │
│ │ - 각 노드의 lrm_status 수집 │ │
│ │ │ │
│ │ 2. 서비스 상태 결정 │ │
│ │ - started/stopped/migrate/fence/recovery 등 │ │
│ │ │ │
│ │ 3. LRM에 명령 전달 │ │
│ │ - 시작/정지/마이그레이션 명령 │ │
│ │ │ │
│ │ 4. Fencing 조율 │ │
│ │ - 장애 노드 감지 시 fencing 결정 │ │
│ │ - 서비스 복구 조율 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
4.3 LRM (Local Resource Manager)¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ pve-ha-lrm 동작 흐름 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [각 노드에서 실행] │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ pve-ha-lrm │ │
│ ├─────────────────────────────────────────────────────────────┤ │
│ │ │ │
│ │ 1. Agent Lock 획득 │ │
│ │ - 노드별 고유 lock │ │
│ │ - Lock 유지 = 노드 정상 │ │
│ │ │ │
│ │ 2. Watchdog 활성화 │ │
│ │ - /dev/watchdog 열기 │ │
│ │ - 주기적 heartbeat (keepalive) │ │
│ │ - 60초 timeout │ │
│ │ │ │
│ │ 3. CRM 명령 수신 및 실행 │ │
│ │ - manager_status 읽기 │ │
│ │ - 로컬 VM/CT 시작/정지/마이그레이션 │ │
│ │ - 결과를 lrm_status에 기록 │ │
│ │ │ │
│ │ 4. 상태 보고 │ │
│ │ - /etc/pve/nodes/<node>/lrm_status 업데이트 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ ⚠️ Lock 상실 시: │
│ - Quorum 상실 감지 │
│ - Watchdog keepalive 중지 │
│ - 60초 후 자동 리부팅 (self-fencing) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
4.4 서비스 상태 (Service States)¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ HA 서비스 상태 전이도 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ │
│ │ queued │◄─── 새로 추가된 서비스 │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────┐ │
│ │ started │◄─── 정상 실행 중 │
│ └──────────────┬──────────────┘ │
│ │ │
│ ┌───────────────────────┼───────────────────────┐ │
│ │ │ │ │
│ [사용자 요청] [노드 장애] [서비스 실패] │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ request_stop│ │ fence │ │ recovery │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ stopping │ │ (fencing │ │ (다른 노드 │ │
│ └──────┬──────┘ │ 진행) │ │ 에서 시작)│ │
│ │ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ ▼ └───────────────────────┘ │
│ ┌─────────────┐ │ │
│ │ stopped │ │ │
│ └─────────────┘ │ │
│ │ ▼ │
│ │ ┌─────────────┐ │
│ │ │ started │ │
│ │ └─────────────┘ │
│ │ │
│ │ [실패 반복] │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ error │◄─── 수동 개입 필요 │
│ └─────────────┘ │
│ │
│ 기타 상태: │
│ - migrate: 라이브 마이그레이션 중 │
│ - freeze: 노드 리부팅 중 (상태 변경 금지) │
│ - ignored: HA 관리에서 일시 제외 │
│ - disabled: 정지 상태, 장애 시 복구 안 함 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
5. Fencing 메커니즘¶
5.1 Fencing이란?¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ Fencing 개념 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Fencing = 장애 노드를 클러스터에서 "확실하게" 격리하는 것 │
│ │
│ 왜 필요한가? │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 상황: Node2가 응답이 없음 (네트워크 문제? 정지? 느림?) │ │
│ │ │ │
│ │ Fencing 없이 VM을 다른 노드에서 시작하면: │ │
│ │ - Node2가 실제로 살아있으면 동일 VM이 2곳에서 실행 │ │
│ │ - 데이터 손상 (특히 공유 스토리지) │ │
│ │ - Split-Brain 상태 │ │
│ │ │ │
│ │ Fencing으로 Node2를 확실히 죽인 후 VM 재시작: │ │
│ │ - 데이터 무결성 보장 │ │
│ │ - 안전한 서비스 복구 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
5.2 Fencing 방식¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ Proxmox VE Fencing 방식 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [1] Self-Fencing (Watchdog) - 기본값 │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌──────────┐ keepalive ┌──────────┐ │ │
│ │ │ LRM │─────────────────►│ Watchdog │ │ │
│ │ │ Daemon │ (매 초마다) │ Timer │ │ │
│ │ └──────────┘ └────┬─────┘ │ │
│ │ │ │ │
│ │ Quorum 상실 시: │ 60초 timeout │ │
│ │ - LRM이 lock 획득 불가 │ │ │
│ │ - keepalive 중지 ▼ │ │
│ │ - Watchdog timeout → 강제 리부팅 [REBOOT] │ │
│ │ │ │
│ │ 장점: 추가 하드웨어 불필요 │ │
│ │ 단점: ~60초 fencing 시간 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ [2] Hardware Fencing (IPMI, iLO, DRAC 등) │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌──────────┐ fence 명령 ┌──────────┐ │ │
│ │ │ CRM │─────────────────►│ IPMI │───► [Power Off] │ │
│ │ │ (Master) │ │ Agent │ │ │
│ │ └──────────┘ └──────────┘ │ │
│ │ │ │
│ │ 장점: 빠른 fencing (수 초) │ │
│ │ 단점: 하드웨어 필요, 설정 복잡 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
5.3 Watchdog 설정¶
# Watchdog 상태 확인
$ wdctl
Device: /dev/watchdog
Identity: Software Watchdog [version 0]
Timeout: 60 seconds
Pre-timeout: 0 seconds
Flag: KEEPALIVEPING
MAGICCLOSE
# HA manager에서 사용 중인 watchdog 확인
$ cat /etc/default/pve-ha-manager
# WATCHDOG_MODULE=softdog
# 또는 하드웨어: WATCHDOG_MODULE=iTCO_wdt
# watchdog-mux 상태
$ systemctl status watchdog-mux
# Watchdog 테스트 (주의: 시스템 리부팅됨!)
# echo V > /dev/watchdog # 안전 종료
6. 장애 시나리오 시뮬레이션¶
6.1 3노드 클러스터 장애 시나리오¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ 시나리오: Node2 갑작스런 전원 차단 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 초기 상태: │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Node1 │ │ Node2 │ │ Node3 │ │
│ │ (CRM) │◄──►│ VM 100 │◄──►│ VM 101 │ │
│ │ VM 102 │ │ VM 103 │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ Timeline: │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ T+0s Node2 전원 차단 │
│ │ │
│ T+5s │ Corosync: Node2 heartbeat 누락 감지 시작 │
│ │ │
│ T+10s │ Corosync: Node2를 "suspected" 상태로 표시 │
│ │ │
│ T+15s │ Corosync: Node2 멤버십에서 제외 │
│ │ - Quorum 재계산: 2/3 = 2 (유지) │
│ │ - Node1, Node3는 quorate 상태 유지 │
│ │ │
│ T+15s │ CRM (Node1): Node2 장애 감지 │
│ │ - VM 100, VM 103 상태를 "fence"로 변경 │
│ │ │
│ T+15s │ CRM: Node2의 LRM lock 획득 시도 │
│ │ (Node2가 죽었으므로 lock 해제됨) │
│ │ │
│ T+20s │ CRM: Node2 lock 획득 성공 = Fencing 완료 │
│ │ - VM 100, VM 103 상태를 "recovery"로 변경 │
│ │ │
│ T+25s │ CRM: 복구 노드 선택 │
│ │ - VM 100 → Node3로 배정 │
│ │ - VM 103 → Node1로 배정 │
│ │ │
│ T+30s │ LRM (Node3): VM 100 시작 │
│ │ LRM (Node1): VM 103 시작 │
│ │ │
│ T+60s │ VM 100, VM 103: 부팅 완료, 서비스 복구 │
│ │ │
│ ───────────────────────────────────────────────────────────────────── │
│ 총 복구 시간: ~60초 (VM 부팅 시간 포함) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
6.2 Quorum 상실 시나리오¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ 시나리오: 2개 노드 동시 장애 (Quorum 상실) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 초기 상태 (3노드): │
│ - Total votes: 3 │
│ - Quorum: 2 │
│ │
│ Node2, Node3 동시 장애 발생: │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Node1 │ │ Node2 │ │ Node3 │ │
│ │ Online │ │ ❌ Down │ │ ❌ Down │ │
│ │ Votes: 1 │ │ │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ Node1 상태: │
│ - Votes: 1 < Quorum(2) → NOT QUORATE │
│ - /etc/pve/ 읽기 전용 │
│ - CRM/LRM 작업 중지 │
│ - 기존 실행 중인 VM은 계속 실행 (새 작업 불가) │
│ │
│ ⚠️ 이 상태에서 관리자가 해야 할 일: │
│ │
│ 1. 상황 확인: │
│ $ pvecm status │
│ Quorate: No │
│ Flags: Inquorate │
│ │
│ 2. 옵션 A - 장애 노드 복구 대기 │
│ - Node2 또는 Node3이 복구되면 자동으로 quorum 회복 │
│ │
│ 3. 옵션 B - 강제 quorum 설정 (긴급) │
│ $ pvecm expected 1 │
│ ⚠️ 주의: 다른 노드가 독립적으로 동작할 위험 │
│ │
│ 4. 옵션 C - 장애 노드 제거 (영구) │
│ $ pvecm delnode node2 │
│ $ pvecm delnode node3 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
7. HA 관리 명령어¶
7.1 ha-manager 명령어¶
# HA에 리소스 추가
$ ha-manager add vm:100
$ ha-manager add vm:100 --state started --group mygroup
# HA 리소스 설정 변경
$ ha-manager set vm:100 --state stopped
$ ha-manager set vm:100 --state started
$ ha-manager set vm:100 --max_restart 3 --max_relocate 2
# HA에서 리소스 제거
$ ha-manager remove vm:100
# HA 상태 확인
$ ha-manager status
quorum OK
master node1 (active, Thu Jan 10 10:00:00 2025)
lrm node1 (active, Thu Jan 10 09:59:55 2025)
lrm node2 (active, Thu Jan 10 09:59:57 2025)
lrm node3 (active, Thu Jan 10 09:59:56 2025)
service vm:100 (node2, started)
service vm:101 (node3, started)
service vm:102 (node1, stopped)
# HA 설정 확인
$ ha-manager config
vm:100
state started
max_restart 1
max_relocate 1
# 리소스 마이그레이션 (온라인)
$ ha-manager migrate vm:100 node3
# 리소스 재배치 (오프라인)
$ ha-manager relocate vm:100 node3
7.2 pvecm 명령어 (클러스터 관리)¶
# 클러스터 생성
$ pvecm create my-cluster
# 클러스터 참가
$ pvecm add <existing-node-ip>
# 클러스터 상태
$ pvecm status
# 노드 목록
$ pvecm nodes
# 노드 제거
$ pvecm delnode <nodename>
# Expected votes 강제 설정 (긴급 상황)
$ pvecm expected 1
# ⚠️ 주의: 임시 조치, 정상화 후 원복 필요
# QDevice 설정
$ pvecm qdevice setup <qdevice-ip>
$ pvecm qdevice remove
7.3 디버깅 및 로그¶
# HA 로그 확인
$ journalctl -u pve-ha-lrm -f
$ journalctl -u pve-ha-crm -f
# 상세 로그
$ journalctl -u pve-ha-lrm --since "1 hour ago" --no-pager
# Corosync 로그
$ journalctl -u corosync -f
# 클러스터 파일시스템 로그
$ journalctl -u pve-cluster -f
# 전체 시스템 상태
$ pveperf # 성능 테스트
$ pvesh get /cluster/status
$ pvesh get /cluster/ha/status/current
8. HA 설정 파일¶
8.1 리소스 설정 (/etc/pve/ha/resources.cfg)¶
vm: 100
state started
max_restart 3
max_relocate 2
comment Production Web Server
vm: 101
state started
group production-group
max_restart 2
ct: 200
state started
max_restart 1
max_relocate 1
8.2 그룹 설정 (/etc/pve/ha/groups.cfg)¶
group: production-group
nodes node1,node2
nofailback 0
restricted 1
comment Production nodes only
group: all-nodes
nodes node1,node2,node3
nofailback 1
그룹 옵션:
| 옵션 | 설명 |
|---|---|
| nodes | 이 그룹에 속한 노드 목록 (우선순위 순) |
| restricted | 1이면 그룹 외 노드에서 실행 불가 |
| nofailback | 1이면 원래 노드 복구 시 자동 마이그레이션 안 함 |
9. 복구 절차¶
9.1 에러 상태 복구¶
# 서비스가 error 상태일 때
$ ha-manager status
service vm:100 (node1, error)
# 원인 분석
$ journalctl -u pve-ha-lrm -n 50 --no-pager
# 수동 복구 절차:
# 1. HA에서 비활성화
$ ha-manager set vm:100 --state disabled
# 2. 문제 해결 (수동으로 VM 확인/복구)
$ qm status 100
$ qm start 100 # 또는 문제 해결
# 3. HA 재활성화
$ ha-manager set vm:100 --state started
9.2 Quorum 복구¶
# 상황: 클러스터가 quorum을 잃음
$ pvecm status
Quorate: No
# 옵션 1: 장애 노드 복구 대기
# - 네트워크 복구, 노드 재시작 등
# 옵션 2: 강제 quorum (긴급)
$ pvecm expected 1
# 이제 단일 노드로 운영 가능
# ⚠️ 다른 노드가 독립적으로 실행될 위험!
# 옵션 3: 장애 노드 영구 제거
$ pvecm delnode problematic-node
# 새 노드 추가로 클러스터 재구성
# Quorum 복구 확인
$ pvecm status
Quorate: Yes
9.3 Split-Brain 복구¶
# Split-brain 발생 시 (두 파티션이 독립 운영)
# ⚠️ 매우 위험한 상황
# 1. 한쪽 파티션 완전 중지
# (더 적은 노드/오래된 데이터 쪽)
$ systemctl stop pve-cluster corosync
# 2. 데이터 동기화 확인
# /etc/pve/ 내용 비교
# 3. 중지된 노드 재참가
$ systemctl start corosync pve-cluster
$ pvecm updatecerts --force
10. 모범 사례¶
10.1 클러스터 설계¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ HA 클러스터 설계 체크리스트 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [노드 구성] │
│ ✓ 최소 3노드 (quorum을 위해) │
│ ✓ 홀수 개 노드 권장 (3, 5, 7) │
│ ✓ 동일/유사 하드웨어 스펙 │
│ ✓ 2노드 시 QDevice 필수 │
│ │
│ [네트워크] │
│ ✓ 전용 클러스터 네트워크 (Corosync) │
│ ✓ 최소 2개 링크 (이중화) │
│ ✓ 10Gbps 이상 권장 (마이그레이션 속도) │
│ ✓ 스토리지/VM 트래픽과 분리 │
│ │
│ [스토리지] │
│ ✓ 공유 스토리지 필수 (Ceph, NFS, iSCSI) │
│ ✓ 스토리지 이중화 │
│ ✓ 적절한 캐시/성능 설정 │
│ │
│ [HA 설정] │
│ ✓ 중요 VM만 HA 등록 │
│ ✓ 적절한 restart/relocate 제한 │
│ ✓ 그룹으로 노드 친화성 설정 │
│ │
│ [모니터링] │
│ ✓ 클러스터 상태 모니터링 │
│ ✓ Fencing 이벤트 알림 설정 │
│ ✓ 정기적 장애 복구 테스트 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
10.2 주의사항¶
┌─────────────────────────────────────────────────────────────────────────────┐
│ ⚠️ 주의사항 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [절대 하지 말 것] │
│ ✗ Quorum 없이 클러스터 운영 │
│ ✗ 공유 스토리지 없이 HA 설정 │
│ ✗ Watchdog 비활성화 │
│ ✗ 테스트 없이 프로덕션에 HA 적용 │
│ ✗ Split-brain 상태에서 양쪽 모두 운영 │
│ │
│ [주의해서 할 것] │
│ △ pvecm expected 명령 (긴급 상황만) │
│ △ 노드 제거 (데이터 백업 후) │
│ △ Corosync 설정 변경 (클러스터 전체 영향) │
│ △ 펌웨어 업데이트 (순차적, 한 노드씩) │
│ │
│ [권장 사항] │
│ ✓ 정기적 백업 (vzdump) │
│ ✓ 장애 복구 절차 문서화 │
│ ✓ 정기적 장애 시뮬레이션 │
│ ✓ HA 시뮬레이터로 테스트 (pve-ha-simulator) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
11. 주요 명령어 요약¶
11.1 클러스터 관리 (pvecm)¶
| 명령어 | 설명 |
|---|---|
pvecm create <name> |
클러스터 생성 |
pvecm add <ip> |
노드 추가 |
pvecm delnode <node> |
노드 제거 |
pvecm status |
클러스터 상태 |
pvecm nodes |
노드 목록 |
pvecm expected <votes> |
강제 quorum 설정 |
pvecm qdevice setup <ip> |
QDevice 설정 |
11.2 HA 관리 (ha-manager)¶
| 명령어 | 설명 |
|---|---|
ha-manager add <sid> |
HA 리소스 추가 |
ha-manager remove <sid> |
HA 리소스 제거 |
ha-manager set <sid> --state <state> |
상태 변경 |
ha-manager status |
HA 상태 확인 |
ha-manager config |
HA 설정 확인 |
ha-manager migrate <sid> <node> |
온라인 마이그레이션 |
ha-manager relocate <sid> <node> |
오프라인 재배치 |
11.3 디버깅¶
| 명령어 | 설명 |
|---|---|
journalctl -u pve-ha-crm |
CRM 로그 |
journalctl -u pve-ha-lrm |
LRM 로그 |
journalctl -u corosync |
Corosync 로그 |
corosync-cfgtool -s |
링크 상태 |
corosync-quorumtool |
Quorum 정보 |
12. 마무리¶
학습 요약¶
- 클러스터 통신: Corosync가 Kronosnet을 통해 노드 간 통신을 담당
- Quorum: Split-brain 방지를 위한 최소 투표 수 개념
- HA 스택: CRM(전역 결정) + LRM(로컬 실행) 구조
- Fencing: Watchdog을 통한 self-fencing으로 안전한 서비스 복구
- 복구 절차: 상황별 적절한 복구 방법 선택
추가 학습 자료¶
- Proxmox VE 공식 문서: https://pve.proxmox.com/wiki/High_Availability
- Corosync 문서: https://corosync.github.io/corosync/
- pve-ha-simulator: 실제 클러스터 없이 HA 테스트 가능
문서 버전: 1.0 최종 업데이트: 2025년 1월 Proxmox VE 8.x 기준