지난 글(04. Ceph 분산 스토리지 구축)에서 세 노드가 공유하는 분산 스토리지를 완성했습니다. 이제 HA를 올릴 토대가 갖춰졌습니다. 이번 글에서는 두 가지를 마무리합니다. 먼저 01번에서 설치해둔 PBS(Proxmox Backup Server)를 클러스터와 연동해 자동 백업 체계를 만들고, 그다음 드디어 HA 그룹을 구성해 “노드가 죽으면 VM이 다른 노드에서 자동으로 살아나는” 상태를 완성합니다.
왜 백업을 HA보다 먼저 붙이나
순서에 이유가 있습니다. HA는 “노드 장애” 같은 하드웨어 사고를 막아주지만, 실수로 삭제한 VM, 잘못된 설정 변경, 랜섬웨어 같은 사고는 막지 못합니다. 오히려 그런 사고는 Ceph가 충실히 3벌 복제해버리므로, 복제만으로는 되돌릴 수 없습니다. 그래서 본격적으로 워크로드를 올리기 전에 백업을 먼저 붙여두는 게 안전합니다. 작업 중 사고가 나도 복구할 수 있는 안전망을 먼저 까는 셈입니다.
복제(Ceph)와 백업(PBS)은 역할이 다릅니다. 복제는 “지금 이 순간의 데이터를 여러 곳에 둔다”이고, 백업은 “과거 특정 시점의 데이터를 따로 보관한다”입니다. 둘 다 있어야 진짜 안전합니다.
PBS 연동 (Part 1)
이 시리즈의 PBS는 운영 클러스터와 별도 물리 서버에 있습니다(01번에서 설치). 운영 클러스터가 통째로 문제가 생겨도 백업은 살아 있어야 하기 때문입니다. 연동은 PBS 쪽에서 백업 계정·권한·토큰을 만들고, PVE 쪽에서 그 정보로 스토리지를 등록하는 순서입니다.
1. PBS — 백업 전용 사용자와 토큰 생성
root를 직접 쓰지 않고 백업 전용 계정을 만듭니다. PBS 웹 UI(https://PBS_IP:8007)에서 진행합니다.
사용자 생성 — Configuration → Access Control → User Management → Add
- User name:
pveuser - Realm:
Proxmox Backup authentication server (pbs) - 비밀번호 설정
데이터스토어 권한 부여 — Datastore → (본인 데이터스토어) → Permissions → Add User Permission
- User:
pveuser@pbs - Role:
DatastoreBackup(백업/복원에 필요한 권한 묶음)
API 토큰 생성 — Configuration → Access Control → API Token → Add
- User:
pveuser@pbs - Token Name:
pve01 - Privilege Separation 체크 해제 (해제하면 사용자 권한을 그대로 상속해 더 간단합니다)
- 생성 직후 표시되는 Secret 값을 즉시 복사 — 이 값은 한 번만 보여줍니다
최종 토큰 ID는 pveuser@pbs!pve01 형식이 됩니다.
2. PBS — 서버 지문(Fingerprint) 확인
PVE가 PBS를 신뢰하도록 SHA-256 지문을 확인합니다. PBS 웹 UI의 Dashboard나 Certificates 페이지에서 볼 수 있고, CLI로도 됩니다.
# PBS 서버에서
proxmox-backup-manager cert info | grep -i fingerprintAB:CD:EF:... 형식의 값을 복사해둡니다.
3. PVE — PBS 스토리지 등록
이제 PVE 클러스터에 PBS를 등록합니다. 클러스터에서는 Datacenter 레벨에 한 번만 등록하면 세 노드가 모두 사용합니다. Datacenter → Storage → Add → Proxmox Backup Server.
| 항목 | 값 |
|---|---|
| ID | pbs-main |
| Server | PBS 서버 IP |
| Username | pveuser@pbs!pve01 (사용자!토큰명 형식) |
| Password | 위에서 복사한 Secret |
| Datastore | PBS의 데이터스토어 이름 |
| Fingerprint | 위에서 복사한 SHA-256 지문 |
저장 후 Summary 탭에 PBS 용량·상태가 정상 표시되면 연동 성공입니다.
암호화(Encryption) 옵션은 일단 끄고 시작해도 됩니다. 켤 경우 암호화 키를 별도로 안전하게 보관해야 하며, 키를 분실하면 백업도 함께 잃습니다. 키 관리 체계가 준비된 뒤에 켜는 걸 권장합니다.
4. 백업 스케줄과 보존 정책
Datacenter → Backup → Add에서 백업 작업을 만듭니다.
| 항목 | 값 | 의미 |
|---|---|---|
| Node | All | 어느 노드에 있든 백업 |
| Storage | pbs-main | 위에서 등록한 PBS |
| Schedule | daily 03:00 | 매일 새벽 3시 |
| Selection mode | All | 모든 VM/CT 자동 포함 |
| Mode | Snapshot | 다운타임 없이 백업 |
보존 정책(Retention/Prune)으로 오래된 백업을 자동 정리합니다. 예: 최근 며칠치는 매일, 몇 주치는 주간, 몇 달치는 월간 단위로 남기는 식으로 설정합니다. PBS는 증분 백업 + 중복 제거가 매우 효율적이라, 넉넉히 보존해도 용량 부담이 작습니다.
선택 모드를 All로 두면, 앞으로 새로 만드는 VM도 자동으로 백업 대상에 포함됩니다. VM이 어느 노드에 있든, HA로 노드를 옮겨다녀도 Datacenter 레벨에서 잡히므로 백업 연속성이 끊기지 않습니다.
5. 백업 검증 (Verify)
백업은 “받아두는 것”보다 “복원되는 것”이 중요합니다. PBS의 Verify Job을 주기적으로(예: 주 1회) 돌려 백업 파일의 체크섬을 검증하도록 설정해두면, 정작 복원할 때 백업이 깨져 있는 사고를 예방할 수 있습니다. 추가로 GC(가비지 컬렉션)도 주기적으로 돌려 중복 제거로 비워진 공간을 회수합니다.
HA 구성 (Part 2)
이제 이 시리즈가 처음부터 목표로 한 고가용성을 켭니다. 04번에서 Ceph 공유 스토리지를 만들었기 때문에, 이제 어느 노드에서든 같은 VM 디스크에 접근할 수 있습니다. HA가 동작할 조건이 갖춰진 것입니다.
HA가 동작하는 원리
HA는 이렇게 작동합니다. 클러스터는 Corosync 하트비트(02·03번)로 각 노드의 생존을 감시합니다. HA 리소스로 등록된 VM이 떠 있던 노드가 죽으면, 클러스터가 이를 감지하고 그 VM을 남은 노드 중 하나에서 자동으로 다시 부팅합니다. VM의 디스크는 Ceph 공유 스토리지에 있으므로, 다른 노드가 그대로 이어받아 켤 수 있습니다.
여기서 03번의 쿼럼과 04번의 공유 스토리지가 하나로 연결됩니다. 쿼럼이 있어야 “어느 노드가 죽었는지” 클러스터가 안전하게 판단하고, 공유 스토리지가 있어야 “다른 노드가 그 VM을 이어받아” 켤 수 있습니다. 둘 중 하나라도 없으면 HA는 성립하지 않습니다.
1. HA 그룹 생성
먼저 HA 대상 노드들을 묶는 그룹을 만듭니다. Datacenter → HA → Groups → Create.
| 항목 | 값 | 의미 |
|---|---|---|
| ID | default-ha | 그룹 이름 |
| Nodes | pve11, pve12, pve13 | HA가 VM을 배치할 수 있는 노드 |
| restricted | 미체크 | 장애 시 어느 노드로든 이동 허용 |
| nofailback | 체크 | 죽었던 노드가 복귀해도 VM을 자동 회귀시키지 않음 |
nofailback을 켜는 이유. 이걸 끄면, 장애가 났던 노드가 복귀하는 순간 VM이 원래 노드로 자동으로 돌아갑니다. 그런데 노드가 복귀했다고 바로 안정적인 건 아닙니다(디스크 리밸런싱 중일 수 있음). 자동 회귀가 또 한 번의 마이그레이션을 일으켜 불필요한 출렁임을 만들 수 있으므로, 복귀 시점은 관리자가 직접 판단하도록 nofailback을 켜는 게 안전합니다.
2. HA 리소스 등록
이제 보호할 VM을 HA 리소스로 등록합니다. Datacenter → HA → Resources → Add.
| 항목 | 값 |
|---|---|
| VM/CT | 보호할 VM ID 선택 |
| Group | default-ha |
| State | started (항상 켜져 있도록) |
| Max Restart / Max Relocate | 기본값 |
등록하면 그 VM은 HA의 보호를 받습니다. 노드가 죽으면 약 1~2분 내에 다른 노드에서 자동으로 부팅됩니다.
모든 VM을 HA에 넣을 필요는 없습니다. “멈추면 안 되는” VM만 등록하면 됩니다. 테스트용이나 잠깐 쓰는 VM까지 HA에 넣으면, 관리할 게 늘고 노드 여유분(00번에서 계산한 HA 여유 메모리)도 더 많이 잡아먹습니다.
여기까지의 상태
이번 글을 마치면 인프라가 이런 상태가 됩니다.
- 모든 VM이 매일 자동으로 PBS에 백업되고, 백업은 별도 서버에 안전하게 보관됨
- “멈추면 안 되는” VM은 HA로 등록되어, 노드 한 대가 죽어도 다른 노드에서 자동으로 살아남
- 복제(Ceph) + 백업(PBS) + 고가용성(HA)이라는 세 겹의 안전망 완성
겉보기로는 구축이 끝난 것 같습니다. 하지만 여기서 멈추면 안 됩니다. “설정했다”와 “실제로 동작한다”는 다릅니다. 노드를 정말로 꺼봤을 때 VM이 정말 다른 노드에서 살아나는지, 라이브 마이그레이션이 정말 무중단인지는 직접 시험해봐야 압니다.
마무리 & 다음 글
이번 글에서는 PBS를 클러스터에 연동해 매일 자동 백업 체계를 만들고, HA 그룹·리소스를 구성해 고가용성을 켰습니다. 이로써 복제·백업·HA의 세 겹 안전망이 모두 설정됐습니다.
다음 글(06. 라이브 마이그레이션과 장애 복구 검증)에서는 이 안전망이 실제로 동작하는지 직접 시험합니다. VM을 무중단으로 다른 노드로 옮기는 라이브 마이그레이션의 실측 다운타임을 재고, 노드를 강제로 차단해 HA 자동 복구를 시뮬레이션합니다. 그 과정에서 운영 전에 미리 발견하고 해결한 실제 함정들도 공유합니다. 이 시리즈에서 가장 중요한 편입니다.
00. Proxmox란? 누구에게 어울리나
01. Proxmox 단일 노드 설치
02. Proxmox 네트워크 망분리 설계
03. Proxmox 3노드 클러스터 구성
04. Ceph 분산 스토리지 구축
05. PBS 백업 연동과 HA 구성 ← 현재 글
06. 라이브 마이그레이션과 장애 복구 검증 ← 다음 글
