[Proxmox] HA 클러스터 구축 전 고려사항: 스토리지 복제 vs 공유 스토리지

목차

• 1. 왜 Proxmox HA 스토리지 비교가 중요한가
• 2. 개념부터 정리: 스토리지 복제 vs 공유 스토리지
• 스토리지 복제(Replication, 복제)란?
• 공유 스토리지(Shared Storage, 공유 저장소)란?
• 3. 어떤 환경에 뭐가 맞는지 먼저 판단해보세요
• 4. 실전 구현 1: Proxmox 클러스터 기본 구성
• 5. 실전 구현 2: 스토리지 복제 구성 예시
• 6. 실전 구현 3: 공유 스토리지 구성 예시
• 7. ⚠️ 제가 실제로 겪었던 주의사항과 트러블슈팅
• 1) 복제는 백업이 아닙니다
• 2) 공유 스토리지 하나만 믿으면 위험합니다
• 3) 쿼럼 문제는 생각보다 자주 나옵니다
• 4) 복제망과 서비스망이 섞이면 병목이 납니다
• 5) 파일시스템과 스토리지 특성을 같이 봐야 합니다
• 8. 검증 방법과 결과 확인
• 9. 정리: 어떤 선택이 덜 후회가 남는가
• 자주 묻는 질문
• Q1. Proxmox HA에서 스토리지 복제만으로 충분한가요?
• Q2. 공유 스토리지가 있으면 무조건 더 좋은가요?
• Q3. 백업과 복제는 왜 따로 봐야 하나요?
• Q4. 홈랩에서는 어떤 방식이 시작하기 좋나요?

[Proxmox] HA 클러스터 구축 전 고려사항: 스토리지 복제 vs 공유 스토리지

Proxmox HA 스토리지 비교를 제대로 안 하고 클러스터부터 묶어버리면, 나중에 장애가 났을 때 생각보다 당황하게 됩니다. 저도 처음엔 "노드만 3대면 Proxmox 고가용성은 끝난 거 아닌가?" 싶었거든요. 근데 실제로 써보니까 HA(High Availability, 고가용성)는 단순히 노드 수만으로 완성되지 않더라고요. 결국 핵심은 스토리지를 어떻게 둘 것인가였습니다. 특히 스토리지 복제와 공유 스토리지는 겉보기엔 비슷해 보여도, 장애 시 동작 방식이 꽤 다릅니다.

이번 글에서는 홈랩과 실서비스에 가까운 테스트 환경에서 제가 직접 부딪히며 정리한 기준으로, Proxmox HA 스토리지 비교를 해보겠습니다. 무엇이 더 좋다고 단정하기보다는, 어떤 상황에서 무엇이 덜 후회가 남는지 쪽으로 설명드릴게요. 혹시 클러스터 구성은 끝냈는데 스토리지 선택에서 막히셨다면, 여기서 중요한 포인트만 잡아가셔도 꽤 도움이 되실 겁니다.

3노드 Proxmox 클러스터에서 스토리지 복제와 공유 스토리지의 흐름을 한눈에 보여주는 개요 이미지입니다.

1. 왜 Proxmox HA 스토리지 비교가 중요한가

쉽게 말해 HA는 장애가 나도 서비스가 다시 올라오는 구조를 만드는 일입니다. 그런데 VM(가상머신)이나 CT(Container, 컨테이너)의 디스크가 어느 위치에 있느냐에 따라, 장애 이후의 복구 속도와 방식이 완전히 달라집니다.

• 공유 스토리지: 여러 노드가 같은 디스크 자원을 봅니다.
• 스토리지 복제: 각 노드가 자기 디스크를 갖고 있고, 데이터를 주기적으로 복제합니다.

둘 다 장애 대응이 가능하지만 결이 다릅니다. 공유 스토리지는 운영이 잘 되면 마이그레이션(Migration, 이전)이 편하고 구조가 직관적입니다. 반면 스토리지 복제는 노드별 독립성이 있어서 비용이나 확장성 면에서 매력적일 때가 있더라고요. 다만 복제 시점과 장애 시점 사이에 생기는 차이를 반드시 이해하셔야 합니다.

2. 개념부터 정리: 스토리지 복제 vs 공유 스토리지

스토리지 복제(Replication, 복제)란?

제가 처음엔 이게 백업(Backup, 백업)이랑 비슷한 줄 알았는데, 실제로는 목적이 다릅니다. Proxmox에서 많이 이야기하는 복제는 보통 ZFS Replication(제트에프에스 복제) 기반으로, 특정 VM 디스크를 다른 노드로 주기적으로 보내는 방식입니다.

즉, 원본 VM은 A 노드에서 돌고 있고, 일정 주기로 B 노드에 디스크 상태가 복제됩니다. 장애가 나면 B 노드에서 최신 복제본 기준으로 다시 시작하는 그림이죠.

• 장점: 노드마다 로컬 디스크 성능을 살리기 좋습니다.
• 장점: 별도 외부 스토리지 없이 시작하기 쉽습니다.
• 주의: 복제는 실시간 동기화와 다릅니다.
• 주의: 장애 순간 직전의 마지막 쓰기 데이터는 반영되지 않을 수 있습니다.

공유 스토리지(Shared Storage, 공유 저장소)란?

공유 스토리지는 여러 Proxmox 노드가 같은 스토리지에 접근하는 방식입니다. 대표적으로 NFS(Network File System), iSCSI, FC(Fibre Channel), Ceph 같은 구성이 여기에 들어갑니다. 다만 Ceph는 단순 외부 공유 스토리지라기보다 분산 스토리지 성격이 강해서, 설계 포인트가 조금 다르긴 합니다.

이 구조의 핵심은 디스크가 노드에 묶여 있지 않다는 점입니다. 그래서 정상 상태에서의 라이브 마이그레이션(Live Migration, 무중단 이전)이나 HA 재시작 시 흐름이 상대적으로 자연스럽습니다.

• 장점: 노드 이동이 편합니다.
• 장점: VM 디스크를 모든 노드가 바로 볼 수 있습니다.
• 주의: 스토리지 자체의 이중화가 안 되면 병목이나 단일 장애점(SPOF, Single Point of Failure)이 됩니다.
• 주의: 네트워크 설계가 부실하면 성능 문제가 바로 드러납니다.

3. 어떤 환경에 뭐가 맞는지 먼저 판단해보세요

실제로 써보니까 선택 기준은 생각보다 단순했습니다. 아래 표처럼 보시면 감이 좀 빨리 오실 거예요.

비교 항목	스토리지 복제	공유 스토리지
초기 구축 난이도	상대적으로 단순	스토리지 설계까지 필요
장애 직후 복구 방식	복제본 기준 재시작	같은 디스크로 다른 노드에서 재시작
데이터 최신성	복제 주기에 영향	공유 저장소 상태 기준
라이브 마이그레이션 편의성	제약이 있을 수 있음	대체로 유리
외부 스토리지 의존도	낮음	높음
확장성	노드별 설계에 따라 다름	스토리지 구조에 따라 크게 좌우
대표 리스크	복제 시점 차이	공유 스토리지 장애

제가 멘토링할 때 자주 드리는 기준은 이렇습니다.

1. 예산이 제한적이고 홈랩 성격이 강하다면 스토리지 복제로 시작해도 괜찮습니다.
2. 운영 편의성과 이동성이 중요하면 공유 스토리지가 더 낫습니다.
3. 장애 시 데이터 시점 일관성이 매우 중요하면 복제 주기와 애플리케이션 특성을 꼭 같이 봐야 합니다.
4. 스토리지 자체를 HA로 만들 수 있느냐가 사실상 최종 결정 포인트입니다.

4. 실전 구현 1: Proxmox 클러스터 기본 구성

여기서는 예시로 3노드 클러스터를 가정하겠습니다. 버전별 화면은 조금 다를 수 있지만 흐름은 비슷합니다. 제가 보통 테스트할 때도 먼저 쿼럼(Quorum, 정족수) 상태부터 확인합니다. 이거 안 보고 넘어가면 나중에 삽질 좀 합니다 ㅎㅎ

# 첫 번째 노드에서 클러스터 생성
pvecm create homelab-cluster

# 두 번째, 세 번째 노드에서 클러스터 참여
pvecm add 192.168.10.11

# 클러스터 상태 확인
pvecm status

여기서 확인할 건 많지 않습니다.

• 노드 수가 정상인지
• Quorate 상태인지
• 통신 네트워크가 안정적인지

특히 HA는 네트워크 품질에 꽤 민감합니다. 관리망(Management Network, 관리 네트워크)과 스토리지망을 가능하면 분리하는 편이 좋습니다. 처음엔 한 NIC(Network Interface Card, 네트워크 인터페이스 카드)로 다 몰아도 될 것 같았는데, 실제로 복제나 스토리지 IO가 겹치면 금방 티가 나더라고요.

관리망과 스토리지망을 분리한 3노드 Proxmox 클러스터 예시 구성입니다.

5. 실전 구현 2: 스토리지 복제 구성 예시

스토리지 복제를 쓰려면 로컬 ZFS 스토리지를 먼저 준비해둬야 하더라고요. Proxmox에서 복제는 VM 디스크를 대상 노드로 정기적으로 보내는 방식입니다. 아래 예시는 개념 확인용으로 보시면 됩니다.

# VM 101을 node2로 15분마다 복제
pvesr create 101 node2 --schedule "*/15"

# 복제 작업 확인
pvesr list

# ZFS 상태 확인
zpool status

제가 직접 해보니 여기서 중요한 건 복제 주기입니다. 1분으로 너무 촘촘하게 잡으면 스토리지와 네트워크에 부담이 갑니다. 반대로 너무 길게 잡으면 장애 시 복구본이 오래된 상태일 수 있죠. 결국 서비스 성격에 따라 조정해야 합니다.

HA 자원 등록은 이런 식으로 진행합니다.

# VM 101을 HA 자원으로 등록
ha-manager add vm:101

# HA 상태 확인
ha-manager status

이 구성을 쓰면 노드 장애 시 복제되어 있던 대상 노드에서 VM이 다시 시작될 수 있습니다. 다만 여기서 포인트! 공유 스토리지처럼 동일 디스크를 즉시 이어받는 개념은 아닙니다. 마지막 복제 시점 기준이라는 점, 꼭 기억하셔야 합니다.

6. 실전 구현 3: 공유 스토리지 구성 예시

공유 스토리지는 방식이 여러 가지지만, 홈랩에서는 NFS가 접근성이 좋고, 조금 더 본격적으로 가면 iSCSI나 Ceph를 고려하게 됩니다. 아래는 NFS 기반 공유 스토리지 등록 흐름 예시입니다.

# Proxmox 노드에서 NFS 저장소 추가 예시
pvesm add nfs shared-nfs \
  --server 192.168.20.10 \
  --export /srv/proxmox \
  --content images,iso,backup

# 스토리지 목록 확인
pvesm status

공유 스토리지를 올렸다면, VM 디스크를 해당 저장소에 두고 HA를 연결합니다. 이렇게 되면 특정 노드가 내려가더라도 다른 노드가 같은 디스크를 바라보며 기동할 수 있습니다.

# HA 등록 예시
ha-manager add vm:201
ha-manager status

실제로 써보니까 운영은 훨씬 편했습니다. 특히 유지보수 때문에 VM을 다른 노드로 옮길 때 체감 차이가 큽니다. 다만 스토리지 서버가 흔들리면 클러스터 전체가 동시에 영향을 받을 수 있어서, 공유 스토리지 자체의 안정성을 절대 가볍게 보면 안 됩니다.

복제 작업 구성과 공유 스토리지 등록 흐름을 비교해 보여주는 설정 예시 이미지입니다.

7. ⚠️ 제가 실제로 겪었던 주의사항과 트러블슈팅

이 섹션은 좀 현실적인 얘기입니다. 문서만 보면 금방 될 것 같은데, 막상 해보면 여기서 자주 막힙니다.

1) 복제는 백업이 아닙니다

이거 진짜 중요합니다. 스토리지 복제는 운영 편의를 위한 복제이지, 장기 보관용 백업 전략을 대체하지 않습니다. 삭제나 손상이 복제 타이밍에 따라 같이 전파될 수 있거든요. 저는 복제를 켜놓고 마음이 편했었는데, 나중에 보니 그건 착각이었습니다.

2) 공유 스토리지 하나만 믿으면 위험합니다

공유 스토리지 덕분에 HA가 깔끔해 보이지만, 그 스토리지가 사실상 단일 장애점이면 말짱 도루묵입니다. NFS 서버 한 대만 두고 HA라고 부르기엔 좀 민망하더라고요. 가능하면 이중화된 NAS, 이중 컨트롤러 SAN, 또는 분산 스토리지 구조를 고민하셔야 합니다.

3) 쿼럼 문제는 생각보다 자주 나옵니다

특히 2노드 비슷하게 운영하거나, 관리망이 불안정하면 쿼럼 이슈로 HA가 기대대로 움직이지 않을 수 있습니다. 여기서 중요한 포인트는 노드 수보다 통신 안정성입니다.

# 클러스터 상태와 쿼럼 확인
pvecm status

# HA 리소스 상태 확인
ha-manager status

4) 복제망과 서비스망이 섞이면 병목이 납니다

처음엔 그냥 한 스위치에 몰아넣고 테스트했었는데, 복제 작업이 도는 시간대에 VM 응답성이 떨어지는 걸 봤습니다. 특히 스냅샷(Snapshot, 시점 저장) 기반 작업이 겹치면 체감이 납니다. 가능하면 VLAN이나 물리 NIC 분리를 권장드립니다.

5) 파일시스템과 스토리지 특성을 같이 봐야 합니다

ZFS는 정말 강력하지만 메모리 사용 특성과 운영 습관이 맞아야 합니다. 반대로 외부 공유 스토리지는 백엔드 장비 성능이 약하면 Proxmox 노드를 늘려도 체감 개선이 안 되더라고요. 결국 병목은 가장 약한 스토리지 구간에서 생깁니다.

8. 검증 방법과 결과 확인

구성만 했다고 끝이 아닙니다. 저는 항상 테스트 장애를 일부러 만들어봅니다. 물론 운영 장비에서는 점검 창을 잡고 조심해서 해야겠죠.

1. 테스트 VM을 하나 준비합니다.
2. HA 자원으로 등록합니다.
3. 복제 또는 공유 스토리지 상태를 확인합니다.
4. 원본 노드를 재부팅하거나 격리해봅니다.
5. 다른 노드에서 VM이 어떻게 올라오는지 확인합니다.

# HA 상태 확인
ha-manager status

# 스토리지 상태 확인
pvesm status

# 복제 작업이 있다면 확인
pvesr list

스토리지 복제 방식에서는 보통 마지막 복제본 기준으로 재시작되는지를 봐야 하고, 공유 스토리지 방식에서는 디스크 접근이 끊기지 않고 다른 노드에서 정상 기동하는지를 확인하면 됩니다.

제가 테스트했을 때 체감상 차이는 이랬습니다.

• 스토리지 복제: 구조가 깔끔하고 비용 부담이 덜했지만, 장애 시점과 복제 시점 차이를 항상 의식해야 했습니다.
• 공유 스토리지: 운영은 편했지만, 스토리지 품질이 전체 경험을 좌우했습니다.

노드 장애 이후 다른 노드에서 HA 자원이 재기동된 상태를 보여주는 결과 검증 이미지입니다.

9. 정리: 어떤 선택이 덜 후회가 남는가

결론부터 말씀드리면, Proxmox HA 스토리지 비교에서 정답은 하나가 아닙니다. 대신 우선순위는 분명합니다.

• 예산과 단순한 시작이 중요하면 스토리지 복제가 현실적입니다.
• 운영 편의성과 이동성이 중요하면 공유 스토리지가 유리합니다.
• 데이터 시점 손실 허용 범위를 먼저 정해야 합니다.
• 스토리지 자체를 얼마나 신뢰할 수 있느냐가 최종 승부처입니다.

저도 처음엔 무조건 공유 스토리지가 상위 개념인 줄 알았는데, 실제로 써보니까 꼭 그렇진 않았습니다. 홈랩이나 소규모 환경에서는 스토리지 복제가 오히려 관리 포인트가 적을 때도 있었거든요. 반대로 운영 자동화와 유지보수 편의성을 끌어올리려면 공유 스토리지가 확실히 매력적입니다.

혹시 지금 Proxmox 고가용성 구성을 고민 중이시라면, 먼저 이렇게 자문해보세요. "장애가 났을 때 나는 무엇을 잃어도 되는가?" 이 질문에 답이 나오면, 스토리지 구조도 꽤 명확해집니다.

다음 글에서는 Ceph를 포함한 분산 스토리지 관점에서 Proxmox 클러스터를 어떻게 볼지 이어서 다뤄볼 예정입니다. 이전 글에서 다뤘던 백업 전략과 함께 보시면, 복제와 백업을 분리해서 이해하는 데 훨씬 도움이 되실 겁니다.

예산, 운영 편의성, 장애 대응 기준으로 두 방식을 요약한 비교 인포그래픽입니다.

자주 묻는 질문

Q1. Proxmox HA에서 스토리지 복제만으로 충분한가요?

환경에 따라 가능합니다. 다만 복제는 마지막 동기화 시점 차이가 있으니, 데이터 최신성이 중요한 서비스라면 그 부분을 먼저 검토하셔야 합니다.

Q2. 공유 스토리지가 있으면 무조건 더 좋은가요?

꼭 그렇진 않습니다. 운영은 편하지만, 공유 스토리지 자체가 약하면 전체 클러스터가 같이 흔들립니다.

Q3. 백업과 복제는 왜 따로 봐야 하나요?

복제는 가용성 향상에 가깝고, 백업은 시점 보존과 복구 전략에 가깝기 때문입니다. 둘은 목적이 다릅니다.

Q4. 홈랩에서는 어떤 방식이 시작하기 좋나요?

제 경험상 홈랩은 스토리지 복제로 개념을 익히고, 이후 공유 스토리지나 Ceph로 넘어가는 흐름이 부담이 덜했습니다. 단계적으로 가는 게 훨씬 덜 헷갈리더라고요.

📚 함께 읽으면 좋은 글

• Proxmox Backup Server 1년 후기: 홈랩 백업 전략 어떻게 달라졌나
• Proxmox GPU 패스스루: Error 43·IOMMU 문제 완벽 해결 가이드
• Ansible로 Proxmox 환경 1년 자동화 회고: 효율과 함정
• Kubernetes 스토리지: Longhorn vs Rook-Ceph 성능 벤치마크
• iSCSI와 S3 호환 스토리지, 홈랩 환경에서의 비용 효율성 분석