이 시리즈는 물리 서버 3대로 고가용성(HA) 가상화 클러스터를 직접 구축한 과정을 시간 순서대로 기록한 글입니다. 단일 노드 설치부터 네트워크 망분리, 3노드 클러스터, Ceph 분산 스토리지, 백업, 장애 복구 검증, 운영 자동화까지 다룹니다. 그 첫 글로, 본격적인 설치에 들어가기 전에 “Proxmox가 무엇이고, 이런 구성이 누구에게 어울리며, 실제로 VM을 몇 대나 올릴 수 있는지”를 먼저 정리합니다.
Proxmox VE란?
Proxmox VE(Virtual Environment)는 Debian Linux 기반의 오픈소스 가상화 플랫폼입니다. 물리 서버 한 대 위에 여러 개의 가상 머신(VM)과 컨테이너(LXC)를 올려서 자원을 효율적으로 나눠 쓰게 해주는 도구인데, 단순한 하이퍼바이저를 넘어 클러스터, 분산 스토리지, 백업, 고가용성까지 하나의 웹 UI 안에서 통합 관리할 수 있다는 점이 핵심입니다.
가상화 엔진으로는 두 가지를 함께 씁니다. 완전 가상화가 필요한 워크로드에는 KVM/QEMU 기반의 VM을 쓰고, 가볍게 격리만 하면 되는 워크로드에는 리눅스 컨테이너(LXC)를 씁니다. 같은 호스트에서 무거운 VM과 가벼운 컨테이너를 섞어 운영할 수 있어, 자원 활용도가 높습니다.
상용 가상화 솔루션과 비교하면 성격이 분명합니다.
| 구분 | Proxmox VE | VMware vSphere | 비고 |
|---|---|---|---|
| 라이선스 | 오픈소스 (무료, 유료 구독 선택) | 상용 (코어 단위 과금) | Proxmox는 구독 없이도 전 기능 사용 가능 |
| 분산 스토리지 | Ceph 내장 | vSAN 별도 | Proxmox는 UI에서 바로 Ceph 구성 |
| 백업 | PBS(전용 백업 서버) 무료 | 별도 솔루션 필요 | 증분·중복제거 백업 기본 제공 |
| 컨테이너 | LXC 내장 | 제한적 | VM·컨테이너 통합 관리 |
| 종속성 | 없음 (Debian 기반) | 벤더 종속 | 하드웨어 선택 자유 |
쉽게 말하면, 돈을 들이지 않고도 기업용 가상화 인프라에서 기대하는 것(클러스터·HA·분산 스토리지·백업)을 거의 다 갖출 수 있는 플랫폼입니다. 그래서 비용 부담 없이 온프레미스 프라이빗 클라우드를 만들고 싶을 때 가장 먼저 후보에 오릅니다.
왜 1노드가 아니라 3노드인가
Proxmox는 서버 한 대로도 충분히 돌아갑니다. 그런데도 이 시리즈가 굳이 3노드로 가는 이유는 고가용성(HA) 때문입니다.
서버가 한 대뿐이면, 그 서버가 멈추는 순간 그 위의 모든 서비스가 같이 멈춥니다. 점검을 위해 재부팅 한 번 하려 해도 서비스를 내려야 하죠. 노드가 3대가 되면 이야기가 완전히 달라집니다.
- 한 대가 죽어도 서비스는 산다 — VM이 떠 있던 노드가 다운되면, 남은 두 노드 중 하나에서 자동으로 다시 부팅됩니다(HA).
- 무중단 점검이 된다 — 하드웨어 점검·펌웨어 업데이트 시 VM을 다른 노드로 라이브 마이그레이션하고 작업할 수 있습니다. 사용자는 끊김을 거의 못 느낍니다.
- 데이터가 분산된다 — Ceph 분산 스토리지로 데이터를 3중 복제하면, 노드 한 대의 디스크가 통째로 날아가도 데이터는 살아남습니다.
그런데 왜 하필 3대일까요? 2대가 아니라요. 클러스터는 “과반수(쿼럼, quorum)”로 정상 상태를 판단하는데, 2노드 구성에서는 한 대가 죽으면 남은 한 대가 “내가 정상인지, 아니면 상대가 정상이고 내가 고립된 건지” 스스로 판단할 수 없습니다(split-brain). 3노드는 한 대가 죽어도 남은 두 대가 과반(2/3)을 유지하기 때문에 클러스터가 정상적으로 의사결정을 계속할 수 있습니다. 그래서 HA 클러스터의 사실상 최소 단위가 3노드입니다.
누구에게 어울리나
3노드 Proxmox 클러스터는 다음과 같은 경우에 특히 잘 맞습니다.
중소기업·스타트업의 자체 인프라. 퍼블릭 클라우드 비용이 부담스럽거나, 데이터를 외부에 두기 어려운 사정(보안·규제·내부 정책)이 있는 조직에 적합합니다. 이미 보유한 물리 서버를 활용하면 초기 비용 없이 시작할 수 있습니다.
개발·검증·운영 환경을 분리해야 하는 팀. 변경 사항을 운영에 바로 반영하지 않고, 하위 환경에서 먼저 검증하는 안전한 배포 흐름을 만들 수 있습니다. (이 시리즈의 실제 구축도 개발·검증·운영 3개 환경을 동일 스펙으로 분리해 운영합니다.)
Kubernetes나 VM 워크로드를 온프레미스에 올리려는 조직. 쿠버네티스 노드를 VM으로 올리고, 컨테이너화에 안 맞는 레거시 애플리케이션은 일반 VM으로 함께 운영하는 혼합 구성이 가능합니다.
홈랩·학습 목적의 개인. 비용 없이 클러스터·HA·분산 스토리지 같은 엔터프라이즈 개념을 실제로 만져보며 익힐 수 있습니다. 다만 Ceph는 하드웨어(특히 네트워크)를 꽤 타기 때문에, 개인 학습이라면 사양을 현실적으로 잡는 게 좋습니다.
반대로, 트래픽이 적은 웹사이트 한두 개만 돌리면 되는 상황이라면 3노드 클러스터는 과합니다. 그럴 땐 단일 노드 Proxmox나 가벼운 VPS가 더 합리적입니다. “멈추면 안 되는 서비스”가 있고, 그걸 내 손으로 통제하고 싶을 때 3노드 구성의 가치가 살아납니다.
이 시리즈의 하드웨어 사양
앞으로 이 시리즈에서 다룰 클러스터의 노드 한 대 사양은 다음과 같습니다. 3대가 모두 동일합니다.
| 항목 | 사양 |
|---|---|
| CPU | Intel Xeon E5-2683 v4 @ 2.10GHz × 2소켓 = 64 스레드 |
| 메모리 | 188 GiB |
| OS 디스크 | SAS 300GB × 2 (ZFS RAID1 미러) |
| 데이터 디스크 | SAS 2TB × 6 (Ceph OSD) |
| 플랫폼 | Proxmox VE 8.4 / Ceph Squid 19.2.3 |
3노드를 합치면 물리 코어(스레드) 192개, 메모리 약 566 GiB, Ceph OSD 18개(약 32.75 TiB raw) 규모가 됩니다. Ceph를 3중 복제(replica 3)로 구성하면 실제 가용 용량은 약 11.1 TiB입니다.
Ceph는 데이터를 3벌씩 복제해 보관하기 때문에, raw 용량의 1/3 정도가 실사용 가능 용량이 됩니다. 그 대신 노드 한 대가 통째로 죽어도 데이터가 살아남습니다. “용량을 일부 포기하고 안전을 사는” 구조입니다.
그래서 VM을 몇 대나 올릴 수 있나
가장 궁금해할 부분입니다. 결론부터 말하면 “몇 대”는 VM 한 대당 사양에 따라 달라지므로, 자원 총량을 기준으로 추산해야 합니다. 보통 메모리가 가장 먼저 바닥나기 때문에, 메모리를 기준으로 보는 게 현실적입니다.
먼저 가용 자원을 정리합니다. 3노드 합산 메모리는 약 566 GiB지만, 전부 VM에 줄 수는 없습니다. Ceph와 Proxmox 자체가 노드당 상당량을 먹습니다.
- Ceph 오버헤드: OSD당 약 4~5 GiB. 노드당 OSD 6개면 약 24~30 GiB가 Ceph 전용으로 빠집니다.
- PVE 호스트 오버헤드: 노드당 약 2~4 GiB.
- HA 여유분: 노드 한 대가 죽어도 그 위의 VM이 남은 노드로 옮겨가야 하므로, 노드 1대분(약 188 GiB)은 비워둬야 HA가 실제로 동작합니다. 이게 가장 크게 빠지는 부분입니다.
이를 반영해 보수적으로 계산하면 대략 이렇습니다.
| 구분 | 메모리 |
|---|---|
| 3노드 물리 메모리 합계 | 약 566 GiB |
| Ceph 오버헤드 (3노드) | -약 80 GiB |
| 호스트 오버헤드 (3노드) | -약 10 GiB |
| HA 여유분 (노드 1대분) | -약 188 GiB |
| VM 할당 가능 (실질) | 약 290 GiB |
이 290 GiB를 기준으로, VM 한 대당 메모리를 어떻게 잡느냐에 따라 대수가 나옵니다.
| VM 유형 | VM당 메모리 | 올릴 수 있는 대수(대략) |
|---|---|---|
| 경량 (리눅스, 웹/API 서버) | 2 GiB | 약 140대 |
| 일반 (앱 서버, 중간 규모 서비스) | 4 GiB | 약 70대 |
| 중량 (DB, K8s 워커 노드) | 8 GiB | 약 35대 |
| 대형 (대형 DB, 빌드 서버) | 16 GiB | 약 18대 |
실제로는 여러 유형이 섞이므로, 일반적인 혼합 워크로드 기준으로 40~60대 정도의 VM을 HA 보호 아래 안정적으로 운영할 수 있는 규모라고 보면 됩니다. CPU는 64코어 × 3노드 = 192스레드라 메모리보다 여유가 있고(가상화에서는 CPU를 초과 할당, 오버커밋하는 게 일반적입니다), 스토리지는 11.1 TiB 가용이라 VM당 평균 50~100 GiB를 쓴다고 가정하면 100대 이상도 담깁니다.
정리하면, 이 3노드 구성의 실질적인 병목은 메모리이고, HA 여유분을 남긴 안전 운영 기준으로 VM 40~60대가 현실적인 수용 규모입니다. HA를 포기하고 노드를 꽉 채우면 더 많이 올릴 수 있지만, 그러면 한 대가 죽었을 때 옮겨갈 자리가 없어 HA의 의미가 사라집니다. “몇 대를 올릴 수 있는가”보다 “한 대가 죽어도 버틸 여유를 남겼는가”가 더 중요한 질문입니다.
다음 글에서는
다음 글(01. Proxmox 단일 노드 설치)부터 본격적인 구축에 들어갑니다. 3노드 클러스터도 결국 단일 노드 설치에서 시작하므로, PVE 8.4 설치와 초기 설정(저장소 변경, 업데이트), 그리고 별도 백업 서버인 PBS 설치까지를 먼저 다룹니다.
이 시리즈는 다음 순서로 이어집니다.
00. Proxmox란? 누구에게 어울리나 ← 현재 글
01. Proxmox 단일 노드 설치
02. Proxmox 네트워크 망분리 설계
03. Proxmox 3노드 클러스터 구성
04. Ceph 분산 스토리지 구축
05. PBS 백업 연동과 HA 구성
06. 라이브 마이그레이션과 장애 복구 검증
