01. Proxmox VE 도입기
Proxmox VE 시리즈를 시작하며
가상화 플랫폼을 검토할 때는 보통 다음 질문에서 시작합니다.
- VMware 의존도를 줄이거나 대체 플랫폼을 검토할 수 있을까?
- VM과 컨테이너를 하나의 플랫폼에서 운영할 수 있을까?
- 클러스터, 백업, 고가용성, 스토리지까지 직접 설계·운영할 수 있을까?
Proxmox VE는 이런 요구사항을 검토할 수 있는 오픈소스 가상화 플랫폼입니다. Debian Linux 기반에서 KVM/QEMU 가상 머신과 LXC 컨테이너를 함께 제공하며, 클러스터, 스토리지, 백업, HA, 네트워크, 권한 관리, REST API 기반 자동화를 통합 관리합니다.
다만 Proxmox VE를 단순히 “무료 ESXi” 또는 홈랩 도구로만 보면 범위를 지나치게 좁게 이해하게 됩니다. Proxmox VE는 무료 오픈소스 소프트웨어이지만, 운영 환경에서는 구독 기반 엔터프라이즈 저장소, 기술 지원, 백업·DR, 모니터링, 장애 대응 역량까지 함께 검토해야 합니다.
이 시리즈는 설치 절차만 다루지 않습니다. 실제 운영을 전제로 가상화 플랫폼을 설계하고, 표준화하고, 자동화하는 관점에서 Proxmox VE를 정리합니다.
Proxmox VE가 적합한 환경
Linux 기반 인프라 운영 환경
Linux, 네트워크, 스토리지 운영 경험이 있다면 Proxmox VE를 비교적 자연스럽게 이해할 수 있습니다.
Proxmox VE는 Linux Bridge, VLAN, Bond, LVM, ZFS, NFS, iSCSI, Ceph 같은 Linux 인프라 구성 요소를 활용합니다. GUI로도 기본 운영은 가능하지만, 장애 분석·자동화·대규모 운영에서는 CLI와 Linux 운영 경험이 큰 강점입니다.
VMware 의존도를 낮추려는 조직
기존 VMware 환경을 운영하거나 신규 가상화 플랫폼을 검토하는 조직이라면 Proxmox VE는 현실적인 선택지 중 하나입니다.
다음 요구사항이 있다면 특히 검토할 수 있습니다.
- 개발·검증 환경의 가상화 비용과 라이선스 구조를 재검토해야 하는 경우
- Linux 기반 운영 역량을 활용하려는 경우
- VM과 컨테이너를 하나의 관리 플랫폼으로 통합하려는 경우
- 내부 프라이빗 클라우드 또는 랩 환경을 표준화하려는 경우
- 벤더 종속성을 줄이고 플랫폼 구성의 투명성을 높이려는 경우
다만 플랫폼 교체는 라이선스 비용만으로 결정하면 안 됩니다. 기존 백업, 모니터링, DR, 보안 정책, 운영 절차, 상용 솔루션 호환성, 담당자 역량, 지원 SLA까지 함께 비교해야 합니다.
홈랩과 기술 검증 환경
Proxmox VE는 홈랩과 개인 기술 실험 환경에도 적합합니다.
Kubernetes 클러스터, GitLab, Harbor, Jenkins, 모니터링, DNS 같은 구성 요소를 반복 배포·삭제하려면 VM 템플릿, Clone, Cloud-Init, 스냅샷, VLAN, 백업 기능이 유용합니다.
Proxmox VE
├── bastion / dns / monitoring
├── Kubernetes Control Plane
├── Kubernetes Worker
├── GitLab / Harbor / Jenkins
└── Backup or Registry Mirror
이런 구조는 Kubernetes, CI/CD, 이미지 레지스트리, 모니터링, 내부 DNS를 운영 환경과 유사하게 재현하는 데 도움이 됩니다.
다만 홈랩 검증 결과를 운영 환경에 그대로 적용해서는 안 됩니다. 실제 환경에서는 하드웨어 이중화, 전원·UPS, 백업, 보안, 모니터링, 변경 관리, 장애 대응과 지원 체계가 추가로 필요합니다.
폐쇄망과 제한된 네트워크 환경
폐쇄망에서는 설치와 운영에 필요한 구성 요소를 미리 설계해야 합니다.
- Proxmox VE 및 OS 패키지 반입·업데이트 절차
- ISO, VM 템플릿, 컨테이너 이미지 관리
- 사설 CA와 내부 DNS·NTP 구성
- 내부 APT 저장소와 백업 저장소
- 관리망, 서비스망, 스토리지망 분리 정책
Linux 기반 플랫폼이라는 특성상, 내부 저장소·인증서·네트워크 정책을 체계적으로 구성할 수 있습니다. 하지만 폐쇄망 운영의 핵심은 설치 성공이 아니라 패치, 장애 복구, 인증서 갱신, 이미지 반입을 지속 가능하게 만드는 것입니다.
도입 전 확인할 사항
Proxmox VE 설치 자체는 어렵지 않습니다. 하지만 운영 가능한 가상화 플랫폼을 만드는 일은 설치보다 설계가 중요합니다.
| 구분 | 확인할 사항 |
|---|---|
| 하드웨어 | CPU 가상화 지원, 메모리, 디스크 성능·이중화, NIC 수, 전원 이중화 |
| 네트워크 | 관리망, 서비스망, 스토리지망, 클러스터 통신망, VLAN, MTU 정책 |
| 스토리지 | Local-LVM, ZFS, NFS, iSCSI, Ceph 선택과 백업·확장 전략 |
| 클러스터·HA | 노드 수, Quorum, Corosync 통신, 장애 도메인, 공유 또는 복제 스토리지 |
| 백업·DR | 백업 대상, 보존 주기, 별도 저장소, RPO/RTO, 실제 복구 검증 |
| 보안·운영 | 권한 분리, TLS, 2FA, API Token, 패치·로그·모니터링·변경 관리 |
| 자동화·폐쇄망 | Cloud-Init, Ansible/API, 내부 패키지 저장소, ISO·템플릿 반입 절차 |
HA를 고려한다면 단순히 여러 노드를 클러스터로 묶는 것만으로는 충분하지 않습니다. 안정적인 Quorum을 위해 일반적으로 3개 이상의 노드가 필요하며, Corosync 통신을 위한 낮은 지연의 안정적인 네트워크와 하드웨어·스토리지·네트워크 이중화가 함께 필요합니다.
또한 ZFS 또는 Ceph를 사용할 경우 하드웨어 RAID 컨트롤러 구성은 신중히 검토해야 합니다. 일반적으로 ZFS와 Ceph는 디스크를 직접 제어할 수 있는 HBA/JBOD 구성을 선호합니다.
처음에는 단일 노드와 로컬 스토리지로 시작할 수 있습니다. 하지만 VM 수, 백업, VLAN 분리, 라이브 마이그레이션, HA 요구사항이 늘어나면 초기 구성이 제약이 될 수 있습니다.
따라서 Proxmox VE 도입은 “지금 설치 가능한가?”보다 “현재 요구사항과 향후 확장·복구·운영 역량을 감당할 수 있는가?”를 중심으로 판단해야 합니다.