13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] Proxmox 고가용성

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

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

    목차

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

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

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

    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가 겹치면 금방 티가 나더라고요.

    Proxmox 고가용성 환경에서 네트워크를 분리한 구성도

    관리망과 스토리지망을 분리한 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을 다른 노드로 옮길 때 체감 차이가 큽니다. 다만 스토리지 서버가 흔들리면 클러스터 전체가 동시에 영향을 받을 수 있어서, 공유 스토리지 자체의 안정성을 절대 가볍게 보면 안 됩니다.

    Proxmox HA 스토리지 비교를 위한 설정 화면 이미지

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

    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

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

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

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

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

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

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

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

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

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

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

    Proxmox HA 스토리지 비교 선택 기준 요약 이미지

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

    자주 묻는 질문

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

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

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

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

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

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

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

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

  • [Proxmox VE] Proxmox HA 클러스터 구축: 무중단 서비스 운영 가이드

    [Proxmox VE] Proxmox HA 클러스터 구축: 무중단 서비스 운영 가이드

    목차

    [Proxmox VE] Proxmox HA 클러스터 구축: 무중단 서비스 운영 가이드

    안녕하세요, 13년차 인프라 엔지니어 “13년차의 서버실”입니다. 오늘도 제 홈랩에서 밤새워가며 삽질했던 경험들을 솔직하게 풀어보려고 합니다. 오늘은 많은 분들이 궁금해하실 법한 주제, 바로 Proxmox VE 고가용성(HA) 클러스터 구축에 대한 이야기입니다.

    혹시 이런 경험 있으신가요? 열심히 구축해놓은 서비스가 한밤중에 서버 한 대의 문제로 뚝 끊겨버린 경험 말이죠. 저는 그런 경험이 너무 많아서 멘탈이 나갔던 적이 한두 번이 아니었습니다. 특히 홈랩처럼 혼자서 모든 걸 책임져야 하는 환경에서는 더욱 그렇죠. 그래서 저는 언젠가부터 “무중단 서비스 운영”에 대한 집착(?)이 생겼고, 그 과정에서 Proxmox HA 클러스터를 만나게 되었습니다.

    이번 글에서는 Proxmox HA 클러스터가 무엇인지부터, 실제로 어떻게 구축하고 설정하는지, 그리고 제가 겪었던 삽질과 해결 과정까지 상세하게 알려드릴게요. 저처럼 안정적인 홈랩 환경을 꿈꾸시는 분들에게 이 글이 작은 등불이 되었으면 좋겠습니다. 자, 그럼 시작해볼까요?

    Proxmox HA 클러스터의 전체 아키텍처 다이어그램

    Proxmox HA 클러스터는 여러 노드가 함께 작동하여 서비스의 무중단성을 보장하는 구조를 가집니다.

    1. Proxmox HA 클러스터, 왜 필요할까요? (개념 설명)

    Proxmox HA 클러스터(High Availability Cluster)는 쉽게 말해 여러 대의 Proxmox 서버(노드, Node)들을 하나로 묶어, 그 중 한 대에 문제가 생겨도 서비스가 멈추지 않고 다른 서버에서 자동으로 다시 시작되도록 하는 시스템입니다. 마치 백업 선수가 항상 대기하고 있다가 주전 선수가 다치면 바로 투입되는 것과 비슷하다고 생각하시면 돼요.

    • 고가용성 (High Availability, HA): 시스템이 장애 없이 지속적으로 운영될 수 있는 능력을 의미합니다. Proxmox HA는 물리 서버 한 대가 다운되더라도, 그 서버에서 실행 중이던 가상 머신(Virtual Machine, VM)이나 컨테이너(Container, CT)를 자동으로 다른 정상 노드로 옮겨 재시작함으로써 서비스 중단을 최소화합니다.
    • 클러스터링 (Clustering): 여러 대의 컴퓨터를 묶어 하나의 시스템처럼 작동하게 하는 기술입니다. Proxmox에서는 Corosync(코로싱크)라는 분산 합의 프로토콜을 사용해서 노드 간의 상태를 동기화하고, 누가 살아있는지 죽었는지를 판단합니다.
    • 쿼럼 (Quorum): 클러스터 내에서 결정을 내리기 위한 최소한의 동의 노드 수를 의미합니다. 보통 클러스터 노드 수의 과반수(N/2 + 1)를 요구하는데, 이는 네트워크 분할(Split-Brain) 상황에서 데이터 일관성을 유지하고 잘못된 결정을 내리는 것을 방지하기 위함입니다. 그래서 Proxmox 클러스터는 보통 홀수 개의 노드로 구성하는 것이 안정적이라고 알려져 있습니다.
    • 공유 스토리지 (Shared Storage): HA 클러스터를 구성하려면 모든 노드가 접근할 수 있는 공유 스토리지가 필수입니다. VM이나 CT의 디스크 이미지가 공유 스토리지에 있어야, 한 노드가 다운되었을 때 다른 노드가 그 디스크 이미지를 가져와서 VM을 재시작할 수 있거든요. 저는 보통 NFS(Network File System)나 iSCSI를 많이 활용합니다.

    이런 개념들이 처음엔 좀 어렵게 느껴질 수 있지만, 실제로 구축해보면 “아하!” 하고 무릎을 탁 치게 될 겁니다. 저도 그랬거든요.

    2. Proxmox HA 클러스터 구축 실전 가이드

    이제 본격적으로 Proxmox HA 클러스터를 구축하는 방법을 단계별로 살펴보겠습니다. 제 홈랩 기준으로 최소 2대 이상의 Proxmox VE가 설치된 서버와 공유 스토리지가 준비되어 있다고 가정할게요. (물론 안정적인 쿼럼을 위해 3대 이상을 권장합니다!)

    2.1 Proxmox VE 설치 및 네트워크 설정

    1. 각 노드에 Proxmox VE 설치: 최소 2대 이상의 물리 서버에 Proxmox VE를 설치합니다. 버전은 최신 안정 버전을 사용하는 것이 좋습니다.
    2. 네트워크 설정: 각 노드에 최소 두 개의 네트워크 인터페이스(NIC)를 준비하는 것을 권장합니다. 하나는 관리 및 일반 서비스용, 다른 하나는 클러스터 통신(Corosync) 전용으로 사용하면 더 안정적입니다.
    # 예시: /etc/network/interfaces
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

auto vmbr1 # Corosync 전용 네트워크
iface vmbr1 inet static
    address 10.10.10.10/24
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0

    저는 항상 클러스터 통신은 별도의 네트워크로 분리하는 편입니다. 그래야 클러스터의 안정성이 높아지더라고요.

    2.2 Proxmox 클러스터 생성 및 노드 추가

    이제 Proxmox 웹 인터페이스 또는 SSH로 접속하여 클러스터를 구성해볼 시간입니다. 첫 번째 노드(예: `pve-node01`)에서 클러스터를 생성하고, 다른 노드들(`pve-node02`, `pve-node03` 등)을 추가하는 방식입니다.

    1. 첫 번째 노드에서 클러스터 생성: Proxmox 웹 UI에 로그인하여 데이터센터 > 클러스터 > 클러스터 생성으로 이동하거나, SSH로 접속하여 다음 명령어를 실행합니다. 저는 보통 SSH로 작업하는 걸 선호해요.

      pvecm create  --ring0_addr

      예시:

      pvecm create my-ha-cluster --ring0_addr 10.10.10.10

      여기서 <NODE_IP_FOR_COROSYNC_NETWORK>는 Corosync 전용으로 설정한 IP 주소를 입력해야 합니다. 이게 중요합니다! 잘못 입력하면 나중에 클러스터 통신이 안 될 수 있거든요.

    2. 두 번째 노드에서 클러스터에 참여: 두 번째 노드(예: `pve-node02`)에서 SSH로 접속하여 다음 명령어를 실행합니다.

      pvecm add  --ring0_addr

      예시:

      pvecm add 10.10.10.10 --ring0_addr 10.10.10.11

      이때 첫 번째 노드의 루트 비밀번호를 요구할 수 있습니다. 정확히 입력해주세요.

    3. 클러스터 상태 확인: 모든 노드에서 다음 명령어로 클러스터 상태를 확인할 수 있습니다. 모든 노드가 `online` 상태여야 합니다.

      pvecm status

      결과에 `Quorum: 1`이 뜨면 성공입니다! 🎉

    Proxmox 웹 인터페이스의 클러스터 상태 화면

    웹 인터페이스에서 모든 노드가 클러스터에 성공적으로 추가되고 ‘온라인’ 상태임을 확인할 수 있습니다.

    2.3 공유 스토리지 설정

    Proxmox HA의 핵심은 공유 스토리지입니다. 저는 제 홈랩에서 Synology NAS를 활용해 NFS 공유 스토리지를 구성했습니다. 여러분도 NAS나 다른 서버를 이용해서 NFS 또는 iSCSI를 구성하시면 됩니다.

    1. 공유 스토리지(NFS) 추가: Proxmox 웹 UI에 로그인하여 데이터센터 > 스토리지 > 추가 > NFS를 선택합니다. 그리고 다음 정보를 입력합니다.

      • ID: `nfs-share` (원하는 이름)
      • 서버: `192.168.1.200` (NAS의 IP 주소)
      • 내보내기: `/volume1/proxmox-ha` (NAS에서 공유한 경로)
      • 콘텐츠: `디스크 이미지, 컨테이너 템플릿, ISO 이미지` (모두 선택)

      이렇게 설정하면 모든 Proxmox 노드가 이 공유 스토리지에 접근할 수 있게 됩니다.

    2. VM/CT 디스크 이동: HA 기능을 사용하려면 VM이나 CT의 디스크가 공유 스토리지에 있어야 합니다. 기존 VM이 로컬 스토리지에 있다면, 해당 VM을 종료(Stop)한 후 하드웨어 > 하드 디스크 > 디스크 동작 > 디스크 이동(Move Disk)을 통해 공유 스토리지로 옮겨주세요. 이 과정이 은근히 시간이 걸리더라고요. 인내심이 필요합니다 ㅎㅎ.

    2.4 HA (고가용성) 설정

    이제 클러스터와 공유 스토리지까지 준비되었으니, 특정 VM에 HA 정책을 적용해볼 차례입니다. Proxmox의 ha-manager를 사용합니다.

    1. HA 그룹 생성 (선택 사항): 특정 노드 그룹에만 HA를 적용하고 싶다면 HA 그룹을 생성할 수 있습니다. 저는 보통 모든 노드를 포함하는 기본 그룹을 사용합니다.

      ha-manager group add  --nodes , --restricted 0

    2. VM/CT에 HA 정책 적용: 웹 UI에서 특정 VM을 선택한 후 HA 탭으로 이동하여 추가(Add) 버튼을 누르거나, SSH로 다음 명령어를 실행합니다.

      ha-manager add vm: --group  --state started

      예시:

      ha-manager add vm:100 --group my-ha-group --state started

      --state started는 노드 장애 시 VM을 자동으로 재시작하라는 의미입니다. stopped, frozen 등의 상태도 있습니다. 저는 보통 `started`를 사용해서 무조건 살려내도록 합니다.

    3. HA 상태 확인: 웹 UI의 데이터센터 > HA 탭에서 현재 HA에 등록된 VM들의 상태와 소유 노드를 확인할 수 있습니다. 또는 SSH에서 다음 명령어를 실행합니다.

      ha-manager status

      여기서 모든 리소스가 정상적으로 `started` 상태인지 확인하는 것이 중요합니다. ✅

    Proxmox HA 정책 설정 및 리소스 할당 다이어그램

    HA 정책을 설정하는 화면에서는 각 VM/CT에 대한 고가용성 규칙과 상태를 명확히 지정할 수 있습니다.

    3. 삽질 경험과 트러블슈팅 ⚠️

    제가 Proxmox HA를 구축하면서 겪었던 몇 가지 삽질과 그 해결책을 공유합니다. 저도 처음엔 이게 뭔가 싶었는데, 결국엔 다 해결되더라고요!

    • 쿼럼(Quorum) 문제: 가장 흔한 문제입니다. 짝수 개의 노드로 클러스터를 구성하거나, 한 노드가 다운되면서 쿼럼이 깨지는 경우가 정말 많더라고요. 저는 처음에 2노드 클러스터로 시작했다가 한 노드만 죽어도 모든 게 멈춰버려서 당황했었죠. 쿼럼이 깨지면 클러스터는 더 이상 작동하지 않습니다. 그래서 3대 이상의 홀수 노드 구성이 중요합니다. 만약 2노드 클러스터밖에 안 된다면, pvecm expected 명령어로 쿼럼 투표 수를 강제로 조정할 수도 있지만, 이는 권장하지 않습니다. 정말 비상시에만 사용하세요.

      # 쿼럼이 깨졌을 때, 남아있는 노드에서 강제로 쿼럼을 설정 (비상용)
pvecm expected 1

    • Corosync 네트워크 문제: 클러스터 통신이 원활하지 않으면 노드 간의 상태 동기화가 안 돼서 HA가 제대로 작동하지 않습니다. 저는 방화벽(Firewall)에서 Corosync 포트(UDP 5405-5407)를 열어주지 않아서 한참을 헤맸습니다. ping 테스트와 함께 netcat 등으로 포트 연결을 확인해보세요. 전용 네트워크 인터페이스를 사용하는 것이 훨씬 안정적입니다.

    • 공유 스토리지 연결 실패: NFS나 iSCSI 스토리지가 제대로 마운트되지 않거나, 네트워크 문제로 접근이 안 되는 경우입니다. 이 경우 HA에 등록된 VM이 다른 노드에서 재시작되려 해도 디스크를 찾지 못해 실패합니다. showmount -e 명령어로 NFS 공유를 확인하고, 각 노드에서 스토리지가 정상적으로 마운트되어 있는지 df -h 등으로 확인해야 합니다.

    • Split-Brain (스플릿-브레인): 클러스터가 네트워크 문제로 두 개 이상의 작은 클러스터로 분리되어 각자 독립적으로 작동하려 하는 상황입니다. Proxmox는 쿼럼 개념과 STONITH (Shoot The Other Node In The Head)라는 메커니즘으로 이를 방지하려고 노력합니다. STONITH는 장애가 발생한 노드를 강제로 전원 차단하여 데이터 무결성을 지키는 방법입니다. IPMI나 PDU를 이용한 STONITH 설정을 고려해볼 수 있습니다.

    4. 결과 확인 및 검증 🎉

    모든 설정이 완료되었다면, 이제 HA가 제대로 작동하는지 확인해볼 차례입니다. 이게 제일 신나는 순간이죠!

    1. HA 등록 VM 확인: Proxmox 웹 UI에서 데이터센터 > HA 탭으로 가서 HA에 등록된 VM이 `started` 상태이고, 원하는 노드에서 실행 중인지 확인합니다.

    2. 강제 노드 다운 테스트: HA가 작동하는지 가장 확실하게 확인하는 방법은 의도적으로 한 노드를 다운시키는 겁니다. HA에 등록된 VM이 실행 중인 노드를 선택하여 전원 버튼을 꾹 눌러 강제 종료하거나, SSH에서 reboot -f 명령어를 실행해보세요. (물론 중요한 운영 환경에서는 미리 충분히 테스트해야겠죠!)

      노드가 다운되면 잠시 후 웹 UI의 데이터센터 > HA 탭에서 해당 VM이 다른 정상 노드로 옮겨져 자동으로 다시 시작되는 것을 볼 수 있을 겁니다. 저도 처음 성공했을 때 “드디어 됐다!” 하고 외쳤던 기억이 나네요. 정말 편하더라고요.

    HA 클러스터가 정상 작동할 경우, 노드 장애 시 VM이 자동으로 다른 노드에서 재시작되는 모습을 확인할 수 있습니다.

    5. 마무리하며: 무중단 서비스, 더 이상 꿈이 아닙니다!

    오늘은 Proxmox VE 고가용성(HA) 클러스터 구축에 대해 저의 경험을 바탕으로 이야기해봤습니다. 처음엔 복잡해 보일 수 있지만, 단계별로 차근차근 따라 하다 보면 충분히 구축할 수 있는 시스템입니다. 제가 직접 해보니, 한 번 구축해두면 밤에 발 뻗고 잘 수 있다는 점이 가장 큰 장점이었습니다. 혹시 여러분도 무중단 서비스 운영에 대한 갈증이 있었다면, Proxmox HA 클러스터가 아주 좋은 해결책이 될 거라고 확신합니다.

    물론 HA 클러스터가 모든 장애를 막아주는 만능 해결책은 아닙니다. 공유 스토리지 자체의 장애나 네트워크 전체 장애 같은 경우도 또 다른 고려가 필요하죠. 하지만 대부분의 단일 노드 장애 상황에서는 정말 든든한 보험 같은 역할을 해줍니다.

    이 글이 여러분의 Proxmox 홈랩 구축에 도움이 되었기를 바랍니다. 다음번에는 Proxmox 백업 전략이나 Ceph 분산 스토리지 구축 같은 더 심화된 주제로 찾아오겠습니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요!

    Proxmox HA 클러스터의 장점과 고려사항 요약 인포그래픽

    Proxmox HA 클러스터는 안정적인 서비스 운영을 위한 강력한 도구이지만, 그만큼 고려해야 할 점들도 많습니다.

  • [Proxmox] HA 클러스터 구축 및 트러블슈팅: 고가용성 완벽 가이드

    목차

    서버 한 대가 죽어도 서비스는 살아있어야 한다

    새벽 2시에 전화 받아본 적 있으신가요? “서비스가 안 된다”는 그 전화. 저는 인프라 엔지니어 생활 초반에 그 경험을 꽤 많이 했습니다. 물리 서버 한 대가 죽으면서 거기서 돌아가던 VM(가상 머신)들이 전부 같이 꺼져버리는 그 상황. 정말 식은땀 나거든요.

    그때부터 고민하기 시작했습니다. “어떻게 하면 서버 한 대가 죽어도 서비스가 자동으로 다른 서버에서 살아날 수 있을까?” 그 답이 바로 Proxmox HA(High Availability, 고가용성) 클러스터입니다.

    오늘은 제가 홈랩에서 직접 구축하면서 겪은 삽질들과 함께, Proxmox HA 클러스터를 처음부터 끝까지 완벽하게 셋업하는 방법을 공유해 드리려고 합니다. 트러블슈팅 경험도 솔직하게 담았으니 끝까지 읽어보시면 분명 도움이 될 거예요.

    ▲ Proxmox HA 클러스터의 전체 구성 아키텍처 — 3노드 구성과 쿼럼(Quorum), 공유 스토리지의 관계를 보여줍니다.

    Proxmox HA가 뭔지 먼저 제대로 알고 가자

    HA(고가용성)의 핵심 개념

    쉽게 말해서, HA는 “어떤 노드(서버)가 죽어도 거기 있던 VM이나 컨테이너가 다른 노드에서 자동으로 다시 켜지는 것”입니다. 사람이 새벽에 일어나서 수동으로 VM을 다른 서버로 옮기지 않아도 되는 거죠.

    Proxmox VE에서 HA를 구현하려면 크게 세 가지가 필요합니다.

    • 클러스터(Cluster): 여러 Proxmox 노드를 하나로 묶는 것. 최소 3개 노드 권장 (쿼럼 때문에 — 아래에서 설명)
    • 쿼럼(Quorum): 클러스터 내 다수결 투표 시스템. 과반수 노드가 살아있어야 클러스터가 정상 동작
    • 공유 스토리지(Shared Storage): 모든 노드가 같은 VM 디스크에 접근할 수 있어야 함 (Ceph, NFS, iSCSI 등)

    왜 노드가 최소 3개여야 할까?

    이게 처음엔 저도 이해가 안 됐었는데요. 노드 2개로 구성하면 한 노드가 죽었을 때 남은 노드가 “내가 살아있고 상대방이 죽은 건지, 아니면 네트워크가 끊겨서 서로 연결이 안 되는 건지” 판단을 못 합니다. 이걸 스플릿 브레인(Split-Brain) 상황이라고 하는데, 이 경우 양쪽 노드가 서로 자기가 주인이라고 착각해서 데이터 충돌이 생길 수 있거든요.

    3개 노드면 2:1로 다수결이 가능하니까 “이 노드가 죽었다”는 판단을 명확하게 할 수 있습니다. 2노드로 구성할 수는 있지만 그러면 QDevice(외부 쿼럼 장치)가 추가로 필요해요.

    구성 최소 생존 노드 장점 단점
    2노드 2개 (QDevice 필요) 비용 절감 QDevice 추가 필요, 관리 복잡
    3노드 2개 쿼럼 자체 해결, 안정적 서버 3대 필요
    5노드 3개 최고 가용성 비용 높음

    Proxmox HA 클러스터 구축 — 단계별 실전 가이드

    사전 준비 사항

    시작하기 전에 체크해야 할 것들이 있습니다. 저도 처음에 이 부분을 건너뛰었다가 나중에 다 뒤집어엎었던 기억이 있어서요. 꼭 확인하세요.

    • ✅ Proxmox VE가 설치된 서버 최소 3대
    • ✅ 모든 노드에서 시간 동기화(NTP) 설정 완료
    • ✅ 모든 노드 간 네트워크 통신 가능 (핑 테스트)
    • ✅ 각 노드의 호스트명이 고유하고 DNS/hosts 파일에 등록됨
    • ✅ 공유 스토리지 준비 (Ceph, NFS, iSCSI 중 선택)

    Step 1: /etc/hosts 파일 설정

    모든 노드에서 서로를 알아볼 수 있도록 hosts 파일을 설정합니다. DNS가 없는 환경이라면 특히 중요해요.

    # 모든 노드에서 동일하게 설정 (/etc/hosts)
192.168.1.101  pve-node1  pve-node1.local
192.168.1.102  pve-node2  pve-node2.local
192.168.1.103  pve-node3  pve-node3.local

    Step 2: 첫 번째 노드에서 클러스터 생성

    pve-node1에서 클러스터를 만들어 줍니다. 클러스터 이름은 나중에 바꾸기 어려우니 신중하게 정하세요.

    # pve-node1에서 실행
pvecm create my-ha-cluster

# 생성 확인
pvecm status

    정상적으로 생성되면 이런 출력이 나옵니다.

    Cluster information
------------------
Name:             my-ha-cluster
Config Version:   1
Transport:        knet
Secauth:          on

Quorum information
------------------
Date:             ...
Quorum provider:  corosync_votequorum
Nodes:            1
Node votes:       1
Expected votes:   1
Total votes:      1
Quorum:           1
Flags:            Quorate

    Step 3: 나머지 노드를 클러스터에 참가시키기

    pve-node2와 pve-node3에서 각각 실행합니다. 여기서 중요한 점은 기존 노드의 IP를 정확히 입력해야 한다는 거예요.

    # pve-node2에서 실행
pvecm add 192.168.1.101

# 비밀번호 입력 후 참가 완료
# pve-node3에서도 동일하게 실행
pvecm add 192.168.1.101

    참가 후 상태 확인:

    pvecm status

# 출력 예시
Quorum information
------------------
Nodes:            3
Expected votes:   3
Total votes:      3
Quorum:           2  # 이 숫자가 핵심! 과반수

    Step 4: 공유 스토리지 연결 (NFS 예시)

    Proxmox HA가 동작하려면 VM 디스크가 공유 스토리지에 있어야 합니다. 여기서는 NFS를 예시로 들겠습니다. Ceph를 사용하신다면 별도 구성이 필요한데, 이건 나중에 별도 글로 다룰 예정이에요.

    # 모든 노드에서 NFS 마운트 확인
showmount -e 192.168.1.200

# Proxmox Web UI에서도 추가 가능하지만 CLI로 하면:
# /etc/pve/storage.cfg에 추가됨 (클러스터 전체 공유)
pvesm add nfs shared-storage \
  --server 192.168.1.200 \
  --export /mnt/nfs/proxmox \
  --content images,iso,backup

    ▲ Proxmox Web UI의 HA 관리 화면 — HA 그룹 생성과 리소스 등록 과정을 보여줍니다.

    Step 5: HA 그룹(HA Group) 생성

    HA 그룹은 “이 VM들은 이 노드들에서만 돌아야 해”라는 규칙을 정의합니다. Web UI에서도 가능하지만 CLI가 더 직관적이더라고요.

    # HA 그룹 생성
ha-manager groupadd production \
  --nodes pve-node1:2,pve-node2:1,pve-node3:1 \
  --restricted 0 \
  --nofailback 0

# 그룹 확인
ha-manager groupconfig production

    여기서 숫자(2, 1, 1)는 우선순위(Priority)입니다. 숫자가 높을수록 해당 노드를 선호해요. 장애 복구 후 원래 노드로 돌아오는 Failback 기능도 설정 가능합니다.

    Step 6: VM을 HA 리소스로 등록

    이제 특정 VM을 HA 관리 대상으로 등록합니다. VM ID가 100번이라고 가정할게요.

    # VM 100번을 HA 리소스로 추가
ha-manager add vm:100 \
  --group production \
  --max_restart 3 \
  --max_relocate 3

# 등록된 리소스 확인
ha-manager status
    # 정상 등록 시 출력 예시
quorum OK
master pve-node1 (active, Wed Nov  1 10:00:00 2023)

Active HA resources:

  vm:100
           Status: started
           Node: pve-node1
           Managed: 1

    🎉 여기까지 오면 기본 HA 설정은 완료입니다! 이제 테스트를 해볼 차례예요.

    HA 동작 테스트 — 실제로 노드를 죽여보자

    페일오버(Failover) 테스트

    이 부분이 진짜 재미있습니다. 직접 노드를 강제로 다운시켜서 VM이 다른 노드로 이동하는지 확인해 보는 거거든요. 물론 프로덕션에서는 절대 이렇게 하시면 안 되고, 테스트 환경에서만요 ㅎㅎ

    # 방법 1: 노드를 maintenance 모드로 전환 (안전한 방법)
ha-manager crm-command node-maintenance enable

# 방법 2: pve-node1에서 corosync 서비스 강제 중단 (더 극단적인 테스트)
systemctl stop corosync

# 다른 노드에서 HA 상태 확인
ha-manager status
watch -n 2 ha-manager status  # 2초마다 갱신하며 모니터링

    정상적으로 동작한다면 약 1~2분 내에 VM이 다른 노드에서 기동되는 것을 확인할 수 있습니다. 처음에 드디어 이게 됐을 때 저 혼자 “오오…” 했던 기억이 나네요.

    ⚠️ 트러블슈팅: 제가 직접 겪은 문제들

    문제 1: 클러스터 참가 후 쿼럼이 잡히지 않음

    증상: pvecm status에서 Quorate: No가 표시되고, Web UI에서 “cluster not ready – no quorum” 오류가 나오는 경우입니다.

    원인 대부분은 시간 동기화 문제이거나 방화벽이 포트를 막고 있는 경우였습니다.

    # 시간 동기화 확인
timedatectl status

# NTP 서비스 재시작
systemctl restart chrony
# 또는
systemctl restart systemd-timesyncd

# Corosync가 사용하는 포트 확인 (UDP 5404, 5405)
ss -lunp | grep corosync

# 방화벽 규칙 확인 (Proxmox는 기본적으로 iptables 사용)
iptables -L -n | grep 5404

    문제 2: HA 리소스가 계속 “error” 상태

    이거 저도 한참 고생했습니다. VM이 HA로 등록됐는데 상태가 계속 error로 나오는 경우예요.

    # HA Manager 로그 확인
journalctl -u pve-ha-lrm -f
journalctl -u pve-ha-crm -f

# VM 상태 강제 리셋
ha-manager set vm:100 --state started

# HA 서비스 재시작
systemctl restart pve-ha-crm
systemctl restart pve-ha-lrm

    제 경우엔 VM 디스크가 공유 스토리지가 아닌 로컬 스토리지에 있어서 발생한 문제였습니다. HA는 반드시 공유 스토리지에 VM 디스크가 있어야 한다는 걸 다시 한번 강조하고 싶네요.

    문제 3: Fencing(펜싱)이 동작하지 않아 VM 이동이 안 됨

    Fencing이란 죽은 노드가 정말 죽었는지 확인하고, 확실하게 “격리”하는 메커니즘입니다. 이게 없으면 Proxmox HA는 안전을 위해 VM을 다른 노드로 이동시키지 않습니다.

    # Fencing 설정 확인
cat /etc/pve/datacenter.cfg

# 소프트웨어 watchdog 기반 Fencing 설정 예시
# datacenter.cfg에 추가
fencing: watchdog-dbus

# watchdog 상태 확인
ls /dev/watchdog*

# pve-ha-crm이 watchdog을 사용하는지 확인
journalctl -u pve-ha-crm | grep watchdog

    💡 팁: 홈랩 환경에서 IPMI 같은 하드웨어 펜싱 장치가 없다면, Proxmox의 소프트웨어 watchdog을 사용할 수 있습니다. 다만 프로덕션 환경에서는 하드웨어 펜싱(IPMI, iLO 등)을 강력히 권장합니다.

    문제 4: 클러스터 노드 중 하나가 “UNKNOWN” 상태

    # 클러스터 노드 상태 확인
pvecm nodes

# Corosync 링크 상태 확인
corosync-cfgtool -s

# Corosync 설정 파일 확인
cat /etc/corosync/corosync.conf

# 문제 노드에서 corosync 재시작
systemctl restart corosync pve-cluster

    ▲ HA 페일오버 테스트 결과 — 노드 장애 발생 후 VM이 다른 노드로 자동 이동된 것을 확인하는 화면입니다.

    HA 클러스터 운영 시 꼭 알아야 할 설정들

    HA 정책 세부 조정

    # VM의 HA 설정 상세 조회
ha-manager config vm:100

# max_restart: 같은 노드에서 재시작 시도 횟수
# max_relocate: 다른 노드로 이동 시도 횟수
ha-manager set vm:100 --max_restart 3 --max_relocate 2

# 특정 VM을 HA에서 제거 (삭제가 아닌 관리 해제)
ha-manager remove vm:100

    마이그레이션(Migration) 설정

    HA 환경에서 노드 간 VM 이동 시 네트워크 대역폭 제한도 설정할 수 있습니다. 프로덕션에서는 이게 꽤 중요하더라고요.

    # /etc/pve/datacenter.cfg에서 마이그레이션 설정
migration: secure
migration_unsecure: 0

# 또는 CLI로
pvesh set /cluster/options --migration type=secure

    클러스터 전체 상태 모니터링

    # 전체 클러스터 상태 한눈에 보기
pvecm status
ha-manager status
pct list  # 컨테이너 목록
qm list   # VM 목록

# 실시간 모니터링
watch -n 5 'pvecm status && echo "---" && ha-manager status'

    Proxmox HA 구축 완료 — 최종 점검 체크리스트

    설정을 모두 마쳤다면 아래 체크리스트로 최종 확인해 보세요.

    ▲ Proxmox HA 클러스터 구축 완료 체크리스트 — 운영 전 반드시 확인해야 할 항목들을 정리한 요약 인포그래픽입니다.

    ✅ 최종 확인 체크리스트

    1. pvecm status에서 Quorate: Yes 확인
    2. 모든 노드가 Web UI 좌측 트리에 표시됨
    3. 공유 스토리지가 모든 노드에서 접근 가능
    4. HA 그룹이 생성되고 VM이 리소스로 등록됨
    5. ha-manager status에서 VM 상태가 started
    6. Fencing 메커니즘 설정 완료
    7. 실제 페일오버 테스트 완료
    8. NTP 시간 동기화 모든 노드에서 정상

    자주 묻는 질문 (FAQ)

    Q. VM이 HA로 등록되면 항상 공유 스토리지에 있어야 하나요?
    A. 네, 맞습니다. 로컬 스토리지에 있는 VM은 다른 노드로 이동할 수 없기 때문에 HA의 의미가 없습니다. 반드시 공유 스토리지(NFS, Ceph, iSCSI 등)에 VM 디스크를 두어야 합니다.

    Q. Proxmox HA와 일반 Live Migration의 차이는 뭔가요?
    A. Live Migration은 관리자가 수동으로 VM을 다른 노드로 옮기는 것이고, HA Failover는 노드 장애 시 자동으로 VM을 다른 노드에서 재시작하는 것입니다. 라이브 마이그레이션은 무중단이지만, HA 페일오버는 VM이 재시작되는 시간만큼의 다운타임이 발생합니다.

    Q. 2노드 구성으로도 HA를 쓸 수 있나요?
    A. 가능하지만 QDevice(쿼럼 장치)가 추가로 필요합니다. Raspberry Pi 같은 소형 장치에 corosync-qnetd를 설치해서 쿼럼 역할을 맡길 수 있습니다.

    마무리: 서버실에서 배운 것

    Proxmox HA 클러스터를 처음 구축했을 때, 노드 하나를 강제로 죽이고 VM이 다른 노드에서 자동으로 살아나는 걸 보면서 진짜 뿌듯했습니다. 13년 동안 인프라 일하면서 이런 순간들이 있거든요. 기술이 의도한 대로 딱 작동하는 그 순간.

    물론 처음엔 쿼럼 개념도 헷갈리고, 펜싱 설정 때문에 VM이 안 옮겨가서 한참 삽질도 했습니다. 하지만 그 과정을 통해서 HA의 원리를 제대로 이해하게 된 것 같아요.

    핵심을 정리하면:

    • 최소 3노드로 구성해서 쿼럼을 확보하세요
    • VM 디스크는 반드시 공유 스토리지에
    • Fencing 설정을 빠뜨리지 마세요 — 없으면 HA가 안전 때문에 동작을 안 합니다
    • 설정 후 반드시 실제 페일오버 테스트를 해보세요

    다음 글에서는 Proxmox에서 Ceph 분산 스토리지를 구축하는 방법을 다룰 예정입니다. 공유 스토리지로 외부 NAS 없이 Proxmox 노드들 자체로 고가용성 스토리지를 만드는 내용인데요, HA와 함께 쓰면 정말 강력한 홈랩 환경이 만들어집니다. 기대해 주세요!

    질문이나 다른 삽질 경험 있으신 분들은 댓글로 공유해 주세요. 저도 아직 배우는 중이라 같이 이야기 나눠보면 좋을 것 같습니다 😊