13년차의 서버실

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

[태그:] 고가용성

  • Proxmox 부팅 순서, onboot만으론 부족하다 — startup order 실전

    Proxmox 호스트를 재부팅했는데, 앱은 떴지만 그 앱이 붙어야 할 데이터베이스는 아직 안 떠서 서비스가 깨진 경험, 있으신가요? onboot=1만 켜두면 이런 일이 생깁니다. 이번 글은 부팅 자동 시작과 시작 순서(startup order) 이야기입니다 — 제 홈랩의 (아직 안 잡은) 현실과 함께요.

    1. onboot — 자동 시작의 기본

    Proxmox에서 onboot=1은 “호스트가 켜지면 이 게스트도 자동으로 시작”입니다. 제 홈랩의 주요 서비스는 전부 켜져 있습니다.

    # 컨테이너/VM 자동 시작 켜기
pct set 113 --onboot 1     # LXC
qm set 106 --onboot 1      # VM

# 현재 설정 확인
pct config 113 | grep onboot

    여기까지는 대부분 합니다. 문제는 “언제, 어떤 순서로”가 빠져 있다는 겁니다.

    2. 솔직한 고백 — 내 홈랩엔 순서가 없다

    제 홈랩을 점검해 보니 주요 서비스가 모두 onboot=1이지만 startup 순서·지연은 하나도 설정돼 있지 않았습니다. 즉 호스트가 부팅되면 다 같이 우르르 시작합니다.

    이게 왜 위험하냐면 — 예를 들어 앱 컨테이너가 DB 컨테이너보다 먼저 떠버리면, 앱이 DB에 붙지 못하고 에러를 뱉거나 죽습니다. 스토리지(NAS)에 의존하는 서비스가 NAS보다 먼저 뜨는 것도 마찬가지고요. 지금은 운 좋게 문제가 안 났지만, 의존성이 있는 서비스라면 시간문제입니다.

    3. 해결 — startup order와 지연

    Proxmox는 게스트별로 시작 순서(order)·시작 후 지연(up)·종료 대기(down)를 지정할 수 있습니다.

    # DB 먼저(order 낮을수록 먼저), 30초 뒤 다음
pct set 124 --startup order=1,up=30      # meal-db (먼저)
pct set 125 --startup order=2            # meal-app (DB 다음)

# 스토리지/NAS는 가장 먼저
pct set 100 --startup order=0,up=20      # nas-fileserver
    파라미터 의미
    order 시작 순서(작을수록 먼저, 종료는 역순)
    up 이 게스트 시작 후 다음까지 대기(초)
    down 종료 시 강제 종료 전 대기(초)

    핵심 원칙은 “의존 대상을 먼저”입니다. 스토리지 → DB → 애플리케이션 순으로 order를 매기고, 뒤 서비스가 준비될 시간을 up으로 벌어 주면 됩니다.

    4. 실전 팁

    • up 지연을 아끼지 말 것: DB가 완전히 준비되는 데 시간이 걸립니다. 10~30초 여유를 두면 경합이 사라집니다.
    • 종료는 역순: Proxmox가 order 역순으로 종료하므로, 앱이 먼저 내려가고 DB가 나중에 내려갑니다(정상).
    • order 없는 게스트는 맨 마지막: 순서를 지정하지 않으면 지정된 것들 뒤에 시작됩니다. 그래서 중요 의존성엔 반드시 order를 명시하세요.

    5. 정리

    onboot=1은 “자동 시작”일 뿐, “올바른 순서”까지 보장하지 않습니다. DB·스토리지에 의존하는 서비스가 있다면 --startup order,up으로 순서와 지연을 잡아 주세요. 저처럼 “지금까지 운 좋게 안 터진” 상태라면, 다음 재부팅에서 당하기 전에 미리 잡아두시길 권합니다. 저도 이 글을 쓰며 정리해야 할 숙제로 남겨둡니다.

  • [Proxmox] Proxmox 클러스터 1년 사용 후기: 안정성, 성능, 그리고 예상치 못한 문제들

    [Proxmox] Proxmox 클러스터 1년 사용 후기: 안정성, 성능, 그리고 예상치 못한 문제들

    목차

    Proxmox 클러스터 1년 사용 후기: 안정성, 성능, 그리고 예상치 못한 문제들

    안녕하세요! 13년차 인프라 엔지니어, ’13년차의 서버실’ 블로그 운영자입니다. 홈랩을 운영하며 쌓아온 경험을 바탕으로 오늘은 많은 분들이 관심을 가지시는 Proxmox 클러스터에 대한 솔직한 Proxmox 후기를 들려드리려고 합니다. 특히 1년이라는 시간 동안 Proxmox VE(Virtual Environment) 클러스터 환경을 직접 운영해보면서 느꼈던 점, 좋았던 점, 그리고 예상치 못했던 문제점까지 가감 없이 공유해 드릴게요. 가상화 환경 구축을 고민 중이시거나, 이미 Proxmox를 사용하고 계신 분들께 조금이나마 도움이 되기를 바랍니다.

    Proxmox 클러스터 아키텍처 개요 다이어그램

    이 가상화 클러스터는 여러 대의 Proxmox VE 서버를 하나의 논리적인 단위로 묶어 관리할 수 있게 해주는 강력한 기능입니다. 이를 통해 고가용성(High Availability)과 효율적인 자원 분배를 구현하여 서비스의 안정성과 성능을 크게 향상시킬 수 있죠. 마치 여러 대의 컴퓨터가 힘을 합쳐 하나의 거대한 컴퓨터처럼 작동하는 것과 같다고 생각하시면 이해하기 쉬우실 거예요.

    Proxmox 클러스터, 왜 선택했을까?

    제가 이 가상화 클러스터를 구축하게 된 가장 큰 이유는 바로 고가용성(High Availability, HA) 때문이었습니다. 홈랩 환경에서도 중요한 서비스들은 단일 서버 장애로 인해 중단되는 것을 원치 않았거든요. Proxmox 클러스터를 사용하면, 노드(Node, 개별 Proxmox 서버) 하나에 장애가 발생하더라도 해당 노드에서 실행 중이던 가상머신(Virtual Machine, VM)이나 컨테이너(Container, LXC)를 다른 정상 노드로 자동으로 이전(Migrate)시켜 서비스 중단을 최소화할 수 있습니다. 13년차 인프라 엔지니어로서 이런 HA 기능은 제게 있어선 선택이 아닌 필수였죠.

    또한, 여러 노드에 분산된 자원(CPU, RAM, 스토리지)을 중앙에서 통합 관리할 수 있다는 점도 매력적이었습니다. 덕분에 개별 서버의 자원 현황을 파악하고, VM을 효율적으로 배치하여 전체적인 성능을 최적화하는 데 유리했죠. 처음엔 단순히 여러 대의 서버를 묶는다고 생각했는데, 막상 사용해보니 운영의 편리성 측면에서도 큰 이점을 느낄 수 있었습니다.

    Proxmox 클러스터 구축 과정: 삽질과 극복의 기록

    Proxmox 클러스터 구축 자체는 Proxmox VE의 웹 인터페이스를 통해 비교적 쉽게 진행할 수 있었어요. 하지만 제 경험상, 완벽하게 매끄럽게만 흘러가지는 않았습니다. 특히 네트워크 설정과 스토리지 공유 설정에서 몇 가지 난관에 부딪혔었죠.

    1단계: Proxmox VE 설치 및 기본 설정

    먼저, 클러스터에 참여할 모든 서버에 Proxmox VE를 설치합니다. 저는 주로 Debian 기반으로 설치했는데, Proxmox VE ISO 이미지를 사용하면 훨씬 간편하게 설치할 수 있습니다. 설치 후에는 IP 주소, 호스트 이름(Hostname), DNS 설정 등을 기본적으로 완료해야 합니다.

    2단계: 클러스터 생성 및 노드 참여

    클러스터를 처음 생성할 노드에서 웹 인터페이스에 접속하여 Datacenter -> Cluster 메뉴로 이동합니다. 여기서 ‘Create Cluster’ 버튼을 눌러 클러스터 이름을 지정하고 생성합니다. 이후 다른 노드들을 이 클러스터에 참여시켜야 합니다. 참여시킬 노드에서 마찬가지로 웹 인터페이스에 접속하여 Datacenter -> Cluster 메뉴로 간 후, ‘Join Cluster’ 버튼을 누르고 기존 클러스터의 IP 주소와 관리자 계정 정보를 입력하면 됩니다.

    # 클러스터 생성 (첫 번째 노드에서 실행)
pvecm create <ClusterName>

# 클러스터 참여 (다른 노드에서 실행)
pvecm add <ClusterIP>

    3단계: 공유 스토리지 설정 (중요!)

    고가용성(HA) 기능을 제대로 활용하기 위해서는 VM이나 컨테이너의 디스크 이미지가 모든 노드에서 접근 가능해야 합니다. 이를 위해 공유 스토리지(Shared Storage) 설정이 필수적이죠. 저는 NFS(Network File System)를 이용하여 공유 스토리지를 구성했는데요. 각 노드에서 NFS 클라이언트를 설정하고, NFS 서버에 마운트하는 방식으로 진행했습니다. 처음엔 로컬 스토리지로 VM을 생성했다가, HA 마이그레이션이 불가능하다는 것을 깨닫고 공유 스토리지 구성에 다시 시간을 투자했던 기억이 나네요. 😅

    Proxmox VE 웹 인터페이스에서 Datacenter -> Storage 메뉴로 이동하여 NFS 스토리지 설정을 추가할 수 있습니다. 여기서 NFS 서버의 IP 주소와 마운트 경로, 그리고 ‘Nodes’ 필드에 클러스터 내 모든 노드를 선택하는 것이 중요합니다. 이렇게 해야 해당 스토리지가 모든 노드에서 인식되어 VM 디스크를 저장할 수 있게 됩니다.

    4단계: HA 설정 및 VM 구성

    클러스터와 공유 스토리지 설정이 완료되었다면, 이제 HA 설정을 진행할 차례입니다. Datacenter -> HA 메뉴에서 HA 그룹을 생성하고, 해당 그룹에 속할 노드들과 VM들을 지정합니다. HA 그룹에 속한 VM은 지정된 노드 중 하나에 장애가 발생하면 자동으로 다른 노드에서 재시작(Restart)되거나 이전(Migrate)됩니다. VM 생성 시 ‘High Availability’ 옵션을 활성화하는 것을 잊지 마세요.

    💡 팁: HA 설정을 할 때, VM의 우선순위(Priority)를 설정하여 어떤 VM을 먼저 HA 대상으로 할지 결정할 수 있습니다. 중요한 서비스 VM에는 높은 우선순위를 부여하는 것이 좋습니다.

    1년간 Proxmox 클러스터를 사용하며 느낀 장점

    1년 동안 Proxmox 클러스터를 운영하면서 여러 가지 장점을 체감했죠. 역시 가장 큰 장점은 앞서 언급한 고가용성(HA)과 중앙 집중식 관리입니다.

    • ✅ 안정적인 서비스 운영: 노드 장애 발생 시에도 서비스 중단을 최소화할 수 있어 안심하고 운영할 수 있었어요. 실제로 한 번 노드에 문제가 발생했을 때, HA 기능 덕분에 다른 노드에서 VM이 자동으로 재시작되어 서비스 영향이 거의 없었고요.
    • ✅ 효율적인 자원 관리: 여러 노드의 CPU, RAM, 스토리지 자원을 한눈에 파악하고 관리할 수 있어 효율적인 자원 배분이 가능했습니다.
    • ✅ 간편한 마이그레이션: 유지보수나 업그레이드를 위해 특정 노드의 VM을 다른 노드로 이전(Live Migration)하는 작업이 매우 간편했습니다. 서비스 중단 없이 VM을 안전하게 이동시킬 수 있다는 점이 인상 깊었습니다.
    • ✅ 강력한 기능과 유연성: Proxmox VE 자체의 강력한 기능(스냅샷, 백업, 복제 등)과 클러스터링 기능이 결합되어 매우 유연하고 강력한 가상화 환경을 구축할 수 있었습니다.

    예상치 못한 문제들과 트러블슈팅 경험

    모든 기술이 그렇듯, 이 클러스터 환경 역시 완벽하지만은 않더라고요. 1년이라는 시간 동안 몇 가지 예상치 못한 문제들과 마주했고, 이를 해결하는 과정에서 많은 것을 배울 수 있었죠.

    ⚠️ 문제 1: 네트워크 분리 (Network Partition)

    가장 골치 아팠던 문제 중 하나는 바로 네트워크 분리(Network Partition)였습니다. 특정 노드와 클러스터 코어(Corosync) 통신이 원활하지 않을 때 발생하는데요. 이 경우, 해당 노드는 자신을 클러스터의 일부로 인식하지만, 다른 노드들은 이 노드를 정상으로 인식하지 못하게 됩니다. 최악의 경우, 분리된 노드에서 VM이 중복 실행되는Split-Brain 상황까지 발생할 수 있습니다.

    해결 과정:

    1. 네트워크 연결 상태 점검: 각 노드 간의 ping 테스트, traceroute 등을 통해 네트워크 경로 및 지연 시간을 확인했습니다.
    2. Corosync 설정 확인: /etc/pve/corosync.conf 파일을 주의 깊게 검토하여 네트워크 설정, 노드 목록, 그리고 쿼럼(Quorum) 관련 설정을 재확인했습니다. 특히 2노드 클러스터의 경우 two_node: 1 설정을 통해 스플릿 브레인 방지를 고려하는 것이 중요하죠.
    3. 방화벽 규칙 점검: 각 노드 및 네트워크 장비의 방화벽에서 Corosync 통신 포트(주로 UDP 5404, 5405)가 열려 있는지 확인했습니다.

    ⚠️ 문제 2: 공유 스토리지 접근 불가

    앞서 강조했던 공유 스토리지 설정이 잘못되거나, NFS 서버에 문제가 발생하면 클러스터 전체의 VM 운영에 심각한 영향을 미칩니다. VM 생성이나 시작이 불가능해지는 것은 물론, HA 마이그레이션도 정상적으로 작동하지 않죠.

    해결 과정:

    1. NFS 서버 상태 확인: NFS 서버가 정상적으로 구동 중인지, 해당 디렉토리가 제대로 공유되고 있는지 확인했습니다.
    2. 클라이언트 노드 마운트 확인: 각 Proxmox VE 노드에서 NFS 공유가 정상적으로 마운트되었는지 mount 명령어로 확인하고, 필요시 재마운트했습니다.
    3. 권한 문제 확인: NFS 서버의 내보내기(Export) 설정에서 Proxmox VE 노드들의 IP 주소 또는 서브넷에 대한 접근 권한이 제대로 부여되었는지 확인했습니다.
    Proxmox 클러스터 로그 분석 화면

    이런 문제 발생 시, /var/log/syslog, /var/log/daemon.log, /var/log/pve/ 등 Proxmox VE 관련 로그 파일을 꼼꼼히 확인하는 것이 문제 해결의 첫걸음입니다. 때로는 Corosync의 상태를 확인하기 위해 systemctl status corosync 명령어를 사용하기도 했고요.

    💡 팁: 정기적인 백업과 스냅샷은 필수!

    아무리 안정적인 환경이라도 예기치 못한 상황은 언제든 발생할 수 있습니다. 따라서 중요한 VM은 정기적으로 백업하고, 변경 사항 적용 전에는 스냅샷을 생성하는 습관을 들이는 것이 좋습니다. Proxmox VE는 이러한 백업 및 스냅샷 기능을 매우 편리하게 제공하므로 적극 활용하시길 바랍니다.

    결론: 13년차 엔지니어의 Proxmox 클러스터 최종 평가

    1년 동안 이 Proxmox 클러스터를 사용해보면서, 이 솔루션이 제공하는 안정성, 성능, 그리고 관리 편의성은 홈랩 환경뿐만 아니라 중소규모의 프로덕션 환경에서도 충분히 매력적인 선택지가 될 수 있다고 확신하게 되었어요. 특히 오픈소스 기반으로 강력한 기능을 제공하면서도 라이선스 비용 부담이 적다는 점은 큰 장점이죠.

    물론, 저처럼 처음 클러스터 환경을 구축하거나 운영하는 경우, 네트워크 분리나 공유 스토리지 설정 등에서 다소의 학습 곡선과 삽질(?)이 필요할 수 있습니다. 하지만 Proxmox 커뮤니티의 활성화와 풍부한 온라인 자료 덕분에 대부분의 문제는 해결할 수 있었죠.

    핵심 요약:

    • 장점: 높은 안정성 (HA), 효율적인 자원 관리, 간편한 마이그레이션, 강력한 기능, 비용 효율성
    • 고려사항: 초기 설정의 복잡성 (네트워크, 스토리지), 문제 발생 시 깊이 있는 이해 필요
    Proxmox 클러스터 사용 경험 비교 테이블

    Proxmox 클러스터의 장단점을 한눈에 비교하면 다음과 같습니다.

    구분 장점 고려사항 (단점)
    안정성 고가용성(HA)으로 서비스 중단 최소화 네트워크 분리, 쿼럼 문제 발생 가능성
    성능/관리 중앙 집중식 자원 관리, 간편한 마이그레이션 초기 설정의 복잡성 (네트워크, 스토리지)
    비용 오픈소스 기반, 라이선스 비용 부담 적음 하드웨어 투자 비용 필요

    결론적으로, Proxmox 클러스터는 안정적이고 확장 가능한 가상화 환경을 구축하고자 하는 분들에게 강력 추천할 만한 솔루션입니다. 앞으로도 Proxmox VE의 새로운 기능이나 클러스터 운영 팁에 대해 꾸준히 포스팅할 예정이니, ’13년차의 서버실’ 블로그의 다른 Proxmox 관련 글들도 참고해 주세요! 혹시 Proxmox 클러스터 운영 중 겪었던 재미있는 에피소드나 꿀팁이 있다면 댓글로 공유해주세요. 함께 배우고 성장하는 ’13년차의 서버실’이 되겠습니다. 감사합니다!

  • [Proxmox] Proxmox VE & Ceph 분산 스토리지 1년 회고: 안정성, 성능, 교훈

    [Proxmox] Proxmox VE & Ceph 분산 스토리지 1년 회고: 안정성, 성능, 교훈

    목차

    Proxmox VE & Ceph 분산 스토리지 1년 회고: 안정성, 성능, 교훈

    안녕하세요, 13년차의 서버실 주인장입니다. 오랜만에 홈랩(HomeLab) 이야기를 들고 왔네요. 오늘은 제가 지난 1년간 Proxmox VE와 Ceph를 조합해서 분산 스토리지를 구축하고 운영했던 경험을 회고해보려고 합니다. Proxmox Ceph 조합은 홈랩에서 강력한 스토리지 솔루션을 구축하려는 분들께 정말 매력적인 선택지인데요, 저 역시 안정성과 성능 두 마리 토끼를 잡고 싶어서 이 조합에 도전했었죠. 결과는 어땠을까요? 기대했던 만큼의 성과를 얻었을까요, 아니면 삽질의 연속이었을까요? 솔직한 제 경험담을 지금부터 풀어보겠습니다.

    혹시 여러분도 저처럼 늘어나는 가상 머신(VM, Virtual Machine)과 컨테이너(Container) 때문에 스토리지 확장에 대한 고민이 많으셨나요? 단일 서버의 저장 공간으로는 한계가 있고, 그렇다고 비싼 네트워크 스토리지(NAS, Network Attached Storage)를 여러 대 들이자니 배보다 배꼽이 더 커지는 상황. 저도 그랬습니다. 그래서 저렴한 하드웨어로 고가용성(High Availability)과 확장성(Scalability)을 동시에 잡을 수 있는 방법을 찾다가 분산 스토리지(Distributed Storage) 솔루션인 Ceph를 Proxmox VE 클러스터 위에 얹어보기로 마음먹었죠.

    왜 Proxmox VE와 Ceph를 선택했을까요? (컨셉 설명)

    제가 Proxmox VE와 Ceph 조합에 끌렸던 가장 큰 이유는 바로 시너지 효과 때문입니다. 쉽게 말해, Proxmox VE는 강력한 가상화 플랫폼이고, Ceph는 데이터를 여러 서버에 나눠 저장하면서 안정성과 성능을 높이는 시스템이거든요. 이 둘이 만나면 어떤 일이 벌어질까요?

    • Proxmox VE (프록스목스 VE): 리눅스 기반의 오픈소스 가상화 플랫폼입니다. VM과 컨테이너를 쉽게 관리할 수 있고, 여러 Proxmox 서버를 묶어 클러스터(Cluster)를 구성하면 VM을 서버 간에 자유롭게 이동시키거나(Live Migration, 라이브 마이그레이션), 한 서버에 문제가 생겨도 다른 서버에서 자동으로 VM을 재시작하는 고가용성 기능을 구현할 수 있습니다.
    • Ceph (쎄프): 역시 오픈소스 분산 스토리지 시스템입니다. 데이터를 여러 노드에 분산해서 저장하기 때문에 한두 개의 저장 장치에 문제가 생겨도 데이터가 손실될 염려가 적고, 여러 노드의 자원을 활용해서 높은 입출력 성능(IOPS, Input/Output Operations Per Second)을 낼 수 있습니다. 오브젝트 스토리지(Object Storage), 블록 스토리지(Block Storage), 파일 시스템(File System)까지 다양한 인터페이스를 제공하죠.

    이 둘을 함께 사용하면 Proxmox VE 클러스터를 구성하는 서버들의 로컬 디스크를 묶어서 하나의 거대한 Ceph 스토리지 풀(Storage Pool)로 만들 수 있습니다. 그렇게 되면 VM 디스크 이미지를 이 Ceph 스토리지에 저장하고, 어떤 Proxmox 서버에서든 해당 VM을 실행할 수 있게 되는 거죠. 한 서버에 문제가 생겨도 다른 서버가 Ceph 스토리지에 접근해서 VM을 바로 가져다 쓸 수 있으니, 고가용성(High Availability) 측면에서 정말 매력적이었어요.

    Proxmox VE와 Ceph 분산 스토리지 클러스터의 전체 아키텍처 다이어그램

    Proxmox VE 서버 3대와 Ceph 클러스터가 통합된 홈랩 아키텍처 다이어그램입니다. 각 Proxmox 노드가 Ceph OSD를 호스팅하며, VM들이 이 분산 스토리지 위에 위치합니다.

    제 홈랩에 Ceph 클러스터 구축하기: 삽질의 시작과 과정

    솔직히 처음엔 “오픈소스니까 뭐, 설치하면 되겠지!” 하는 안일한 생각도 좀 있었습니다. 13년차 엔지니어라도 새로운 기술 앞에서는 겸손해야 한다는 걸 다시 한번 깨달았죠. 😅

    하드웨어 구성: 어떤 장비로 시작했을까?

    저는 최소 3개의 노드(Node)로 구성된 클러스터를 목표로 했습니다. Ceph는 복제(Replication)를 통해 데이터 안정성을 확보하는데, 보통 3-복제(3-replication)를 많이 쓰거든요. 그래서 3대의 미니 PC를 준비했습니다. 각 PC는 인텔 NUC 같은 저전력 모델에 16GB RAM, 그리고 데이터를 저장할 SSD를 여러 개 장착했어요. 처음에는 1GbE(기가비트 이더넷) 네트워크로 시작했지만, 나중에는 10GbE(텐 기가비트 이더넷)로 업그레이드했습니다. Ceph는 네트워크 대역폭을 정말 많이 쓰는 친구거든요!

    Proxmox VE 설치 및 클러스터 구성

    Proxmox VE 설치는 생각보다 간단합니다. ISO 이미지를 USB에 구워서 각 노드에 설치하고, 웹 UI에 접속해서 몇 번의 클릭만으로 Proxmox 클러스터를 구성할 수 있죠. 이때 쿼럼(Quorum) 유지를 위해 최소 3개 이상의 노드가 안정적이라는 점을 꼭 기억해야 합니다. (홀수 노드가 좋습니다.)

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

# 다른 노드에서 클러스터에 조인 (첫 번째 노드 IP와 패스워드 필요)
pvecm add 192.168.1.10 --token <토큰_값>

    이 과정 자체는 매끄러웠습니다. Proxmox의 클러스터 관리 기능은 정말 잘 되어 있더라고요.

    Ceph 설치 및 OSD 추가: Proxmox Ceph 통합의 시작!

    이제 대망의 Ceph 차례입니다. Proxmox VE는 Ceph 통합 기능이 워낙 잘 되어 있어서 CLI(Command Line Interface)나 웹 UI에서 몇 번의 명령으로 Ceph를 설치하고 OSD(Object Storage Device)를 추가할 수 있습니다.

    # 각 Proxmox 노드에서 Ceph 설치
pveceph install

# Ceph Monitor(모니터) 설치 (클러스터 노드 중 최소 3개에 설치 권장)
pveceph createmon

# OSD 추가 (각 노드의 사용 가능한 디스크를 OSD로 지정)
# 예: /dev/sdb 디스크를 OSD로 추가하고, NVMe SSD를 DB/WAL로 사용
pveceph createosd /dev/sdb --db-device /dev/nvme0n1 --wal-device /dev/nvme0n1

    처음에는 단순히 `pveceph createosd /dev/sdb` 이런 식으로 HDD를 OSD로 추가했는데, 성능이 영 시원찮았습니다. Ceph의 BlueStore(블루스토어) 백엔드는 메타데이터를 빠르게 처리하는 것이 중요한데, HDD만으로는 한계가 명확하더라고요. 그래서 나중에는 NVMe SSD를 DB/WAL(데이터베이스/쓰기Ahead로그) 용도로 할당해서 성능을 끌어올렸습니다. 이 부분이 Ceph 성능 튜닝의 핵심 중 하나라는 걸 몸소 깨달았죠. 💡

    Proxmox VE 웹 UI에서 활성화된 Ceph OSD 목록을 보여주는 화면

    Proxmox VE 웹 UI의 Ceph 섹션입니다. 각 노드의 OSD 목록과 상태(UP/IN)를 한눈에 확인할 수 있습니다. 저 많은 OSD들이 제 소중한 데이터를 분산해서 저장하고 있죠.

    1년간 Proxmox Ceph를 운영하며 겪은 안정성 및 성능 이야기

    1년이라는 시간은 Ceph 클러스터의 진정한 가치를 시험하기에 충분했습니다. 정말 많은 것을 배우고 느꼈네요.

    안정성 (Stability) 회고: 역시 분산 스토리지!

    Ceph의 가장 큰 장점 중 하나는 데이터 안정성(Data Durability)입니다. 저도 OSD 하나가 갑자기 죽는 경험을 몇 번 했습니다. 그때마다 심장이 덜컥 내려앉았지만, Ceph는 3-복제 덕분에 자동으로 데이터 복구(Self-healing)를 시작하더라고요. 물론 복구 시간 동안 클러스터 성능이 저하되긴 했지만, 데이터 손실 없이 무사히 복구를 완료하는 모습을 보면서 “이래서 Proxmox Ceph 조합을 쓰는구나!” 하고 감탄했습니다. 👏

    Proxmox VE의 HA (High Availability, 고가용성) 기능도 빛을 발했습니다. 특정 Proxmox 노드가 재부팅되거나 문제가 생겼을 때, 해당 노드에서 실행 중이던 VM들이 다른 노드에서 자동으로 재시작되는 것을 여러 번 확인했습니다. Ceph 스토리지 덕분에 VM 디스크에 대한 접근성이 보장되었기 때문에 가능한 일이었죠. 물론 순간적인 서비스 중단은 있었지만, 시스템 전체의 가용성을 크게 높여주었습니다.

    성능 (Performance) 회고: 기대와 현실 사이

    초기에는 HDD OSD만으로 Ceph를 구성했더니, VM의 디스크 I/O가 심하게 느려지는 문제가 있었습니다. 특히 여러 VM이 동시에 디스크 작업을 할 때는 확연히 체감될 정도였죠. 웹 서버나 데이터베이스 서버를 돌리는데 응답 속도가 느려지니 답답하더라고요.

    이 문제를 해결하기 위해 NVMe SSD를 DB/WAL 디바이스로 추가하는 튜닝을 진행했습니다. 결과는 드라마틱한 성능 향상이었습니다! 특히 작은 파일 I/O나 랜덤 읽기/쓰기 성능이 눈에 띄게 좋아졌습니다. 💡 또한, 클러스터 내부 통신(Ceph Private Network)을 10GbE 스위치로 분리하고 업그레이드하면서 네트워크 병목 현상도 크게 줄였습니다. Ceph는 데이터를 복제하고 노드 간에 통신해야 하므로, 빠른 네트워크는 필수라는 걸 다시 한번 깨달았죠.

    Ceph 클러스터의 1년 간 성능(IOPS, 처리량, 지연 시간) 및 스토리지 사용량을 보여주는 Grafana 대시보드

    지난 1년간 Ceph 클러스터의 주요 성능 지표(IOPS, 처리량, 지연 시간)와 스토리지 사용량을 보여주는 Grafana 대시보드입니다. NVMe 캐시 추가 이후 I/O 성능이 크게 개선된 것을 볼 수 있습니다.

    제가 배운 교훈과 놓치지 말아야 할 포인트들 (주의사항 및 트러블슈팅)

    1년간의 여정은 순탄치만은 않았습니다. 수많은 삽질과 시행착오를 겪으며 얻은 교훈들을 공유합니다.

    1. 네트워크의 중요성 ⚠️: Ceph는 엄청난 양의 데이터를 노드 간에 주고받습니다. 특히 데이터 복제(Replication)와 리밸런싱(Rebalancing) 시에는 네트워크 대역폭을 거의 다 써버리기도 해요. 저는 1GbE로 시작했다가 병목 현상에 시달렸고, 결국 10GbE Private Network(프라이빗 네트워크)를 구성하면서 안정적인 성능을 확보했습니다. 반드시 Ceph 전용 네트워크를 분리하고, 가능한 한 빠른 대역폭을 확보하는 것이 좋습니다.
    2. OSD 디스크 선택 및 구성: HDD만으로 OSD를 구성하면 성능 한계가 명확합니다. 가능하다면 SSD나 NVMe SSD를 DB/WAL 디바이스로 활용하여 BlueStore의 메타데이터 처리 속도를 높이세요. 저는 OSD 구성 시 디스크 성능과 용량을 신중하게 고려하지 않아서 나중에 재구성하는 삽질을 좀 했습니다.
    3. 모니터링의 생활화: Ceph 클러스터는 생각보다 복잡합니다. `ceph -s` 명령으로 클러스터 상태를 주기적으로 확인하고, Proxmox VE 자체 모니터링 외에 Prometheus와 Grafana를 연동하여 세밀한 모니터링 대시보드를 구축하는 것이 좋습니다. OSD의 상태, 네트워크 트래픽, 스토리지 사용량 등을 실시간으로 확인해야 문제 발생 시 빠르게 대응할 수 있습니다.
    4. CRUSH Map (크러시 맵) 이해: Ceph는 CRUSH Map이라는 알고리즘을 사용해서 데이터를 어디에 저장하고 어떻게 복제할지 결정합니다. 이 CRUSH Map을 이해하면 데이터가 어떻게 분산되는지, 장애 시 복구가 어떻게 이루어지는지 파악하는 데 큰 도움이 됩니다. 홈랩에서는 기본 설정으로도 충분하지만, 좀 더 최적화된 구성을 원한다면 깊이 파고들어 볼 가치가 있습니다.
    5. 업그레이드 및 패치: Proxmox VE와 Ceph는 꾸준히 업데이트됩니다. 새로운 기능과 버그 수정이 포함된 업데이트는 중요하지만, 항상 사전에 충분히 테스트하고 백업 전략을 세운 후 진행해야 합니다. 저는 한 번 업데이트 후에 특정 OSD가 Unhealthy 상태가 되어 클러스터 재시작 후 복구하는 경험도 있었습니다.
    # Ceph 클러스터 상태 확인 (가장 기본적인 명령)
ceph -s

# OSD 디스크 트리 확인 (어떤 디스크가 OSD로 사용되는지, 상태는 어떤지)
ceph osd tree

# Ceph 로그 확인
tail -f /var/log/ceph/ceph.log

    이런 명령들을 꾸준히 사용하며 클러스터의 “건강”을 체크하는 것이 중요합니다.

    결론 및 다음 단계

    Proxmox VE와 Ceph를 활용한 분산 스토리지 구축은 제 홈랩에 강력한 고가용성 스토리지를 선물해주었습니다. 물론 초기 설정의 복잡성, 그리고 10GbE 네트워크나 NVMe SSD 같은 추가적인 하드웨어 투자 비용은 무시할 수 없었지만, 그만큼 안정성과 성능이라는 큰 보상을 얻을 수 있었습니다. 특히 OSD 하나가 죽어도 데이터가 안전하고, VM이 자동으로 다른 노드에서 재시작되는 경험은 정말 든든하더라고요. 홈랩에서 중요한 서비스를 운영하거나, 미래의 스케일업(Scale-up)을 염두에 두고 있다면 Proxmox Ceph 조합은 충분히 고려해볼 만한 가치가 있습니다.

    물론 Ceph가 모든 상황에 완벽한 솔루션은 아닙니다. 작은 규모에서는 오히려 오버헤드가 더 클 수도 있고, 특정 워크로드(예: 매우 높은 단일 VM IOPS)에서는 최적화가 필요할 때도 있습니다. 하지만 저렴한 비용으로 엔터프라이즈급 스토리지의 맛을 볼 수 있다는 점은 홈랩 엔지니어에게는 정말 큰 매력이라고 생각합니다.

    다음 단계로는 현재 운영 중인 Ceph 클러스터의 성능을 좀 더 면밀히 분석하고, 특정 VM에 대한 스토리지 I/O 최적화 방안을 모색해보려고 합니다. 또한, CephFS(쎄프 파일 시스템)를 활용하여 파일 공유 시스템을 구축해보는 것도 재미있는 도전이 될 것 같네요. 혹시 여러분도 Proxmox Ceph에 대한 궁금한 점이나 공유하고 싶은 경험이 있다면 언제든지 댓글로 남겨주세요!

    Proxmox VE와 Ceph 분산 스토리지의 장점과 단점을 비교하는 인포그래픽

    Proxmox VE와 Ceph 분산 스토리지 조합의 주요 장점과 고려해야 할 단점을 요약한 인포그래픽입니다. 홈랩 환경에서의 활용 가치를 한눈에 파악할 수 있습니다.

    다음에 더 유익한 정보로 찾아뵙겠습니다. 13년차의 서버실이었습니다!

  • [Proxmox] Proxmox HA 클러스터 구축 실패 사례와 교훈: 3년차 엔지니어의 회고

    [Proxmox] Proxmox HA 클러스터 구축 실패 사례와 교훈: 3년차 엔지니어의 회고

    [Proxmox] Proxmox HA 클러스터 구축 실패 사례와 교훈: 3년차 엔지니어의 회고

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 제가 인프라 엔지니어 3년차 시절, Proxmox HA 클러스터를 구축하다가 제대로 삽질했던 아찔한 경험담을 공유해보려고 합니다. 😅 당시에는 멘붕의 연속이었지만, 지금 생각해보면 그때의 실패가 저를 더 단단하게 만들었더라고요. 혹시 여러분도 Proxmox HA 클러스터를 구축하려다 비슷한 어려움을 겪고 계시다면, 제 이야기가 작은 길잡이가 되기를 바랍니다.

    2. Proxmox HA, 그거 왜 필요한 건가요? (개념 설명)

    먼저, HA(High Availability, 고가용성)가 뭔지 간략하게 짚고 넘어갈까요? 쉽게 말해, 서비스가 죽지 않고 계속 살아있게 만드는 시스템이라고 생각하시면 돼요. 서버 한 대가 고장 나더라도 다른 서버가 그 역할을 대신해서 서비스 중단을 최소화하는 거죠. 우리 일상에서는 너무나 당연하게 느껴지지만, 이걸 직접 구현하는 건 또 다른 이야기더라고요.

    Proxmox HA 클러스터는 이런 고가용성을 가상화 환경에 적용한 거예요. Proxmox VE(Virtual Environment)는 오픈소스 가상화 플랫폼인데, 이 Proxmox 서버 여러 대를 묶어 클러스터를 만들고, 그 위에 돌아가는 가상 머신(VM)이나 컨테이너(LXC)가 특정 노드에 문제가 생기면 다른 노드로 자동으로 마이그레이션(Migration)되어 서비스를 이어가게 해준다는 거죠.

    이때 핵심적인 개념들이 몇 가지 있습니다:

    • Corosync (코로싱크): 클러스터 노드들 간에 상태 정보를 주고받고, 서로 살아있는지 확인하는 통신 프로토콜이에요. 심장 박동(Heartbeat)처럼 지속적으로 신호를 주고받는다고 생각하시면 돼요.
    • Quorum (쿼럼, 정족수): 클러스터가 정상적으로 동작하기 위해 필요한 최소한의 노드 수를 말해요. 쿼럼을 상실하면 클러스터는 자폭(Self-fencing)하거나 서비스를 멈춰서 데이터 일관성을 지키려고 해요. 이게 없으면 Split-brain (스플릿 브레인, 뇌 분열)이라는 무서운 상황이 발생할 수 있어요.
    • Split-brain (스플릿 브레인): 클러스터 노드들이 서로 통신이 끊어졌을 때, 각 노드가 자신이 클러스터의 ‘진짜’ 마스터라고 착각하고 독자적으로 동작하는 현상이에요. 이 경우 데이터가 꼬이거나 손상될 수 있어서 정말 위험해요.
    • QDevice (쿼럼 디바이스): 주로 2노드 클러스터에서 쿼럼 문제를 해결하기 위해 사용하는 보조 장치예요. 2노드 클러스터는 한 노드만 다운돼도 쿼럼을 상실하는데, QDevice가 제3의 투표권을 행사해서 쿼럼을 유지할 수 있게 도와줄 수 있어요.
    Proxmox HA 클러스터의 일반적인 구성 개요 다이어그램

    Proxmox HA 클러스터의 일반적인 구성 개요입니다. 여러 Proxmox 노드가 공유 스토리지와 Corosync 네트워크로 연결되어 고가용성을 제공하는 모습을 보여줍니다.

    3. 야심 찬 Proxmox HA 클러스터 구축기 (실전 구현 – 실패의 시작)

    제가 3년차였을 때, 회사에서 작은 프로젝트를 맡았습니다. 특정 서비스의 Proxmox 고가용성 실패를 막기 위해 HA 클러스터를 구축하는 일이었죠. 당시 저는 ‘Proxmox? HA? 뭐 별거 있겠어?’ 하는 오만함에 빠져 있었거든요. 😅

    구축 과정은 대략 이랬어요. 2대의 Proxmox 서버를 준비하고, NFS(Network File System) 기반의 공유 스토리지를 연결했었어요. 그리고 Proxmox 클러스터 기능을 이용해서 두 노드를 묶는 작업에 들어갔어요.

    Step 1: 첫 번째 Proxmox 노드에 클러스터 생성

    pvecm create my-ha-cluster # 'my-ha-cluster'는 클러스터 이름입니다.

    Step 2: 두 번째 Proxmox 노드를 클러스터에 추가

    pvecm add 192.168.1.10 # 192.168.1.10은 첫 번째 노드의 IP 주소입니다.

    여기까지는 순조로웠어요. Proxmox GUI에서 클러스터가 잘 묶이는 것을 확인하고, ‘오, 성공인가?’ 싶었죠. 공유 스토리지도 잘 마운트되고, VM을 만들어서 HA 설정을 켜는 것까지는 문제가 없었어요. VM이 공유 스토리지에 저장되니, 어느 노드에서든 접근할 수 있다는 생각에 흐뭇해했어요.

    하지만 이때부터 제가 간과했던 중요한 포인트들이 하나둘씩 수면 위로 떠오르기 시작했어요. 이것이 바로 클러스터 장애 극복이라는 목표를 향한 저의 험난한 HA 운영 노하우 습득 과정의 시작이었습니다.

    Proxmox 웹 인터페이스에서 클러스터 상태를 확인하고 VM에 HA 설정하는 화면

    Proxmox 웹 인터페이스에서 클러스터 상태를 확인하고, 특정 VM에 대해 HA 설정을 활성화하는 화면입니다.

    4. ⚠️ 삽질 대잔치! Proxmox HA 클러스터 실패 사례와 트러블슈팅

    드디어 삽질의 본론입니다. 😅 제가 겪었던 주요 실패 사례와 당시의 멘붕 과정을 공유해볼게요.

    문제 1: 불안정한 공유 스토리지(Shared Storage)

    저는 당시 NAS 장비의 NFS 공유를 단순히 연결하기만 했었어요. ‘VM 파일만 저장되면 되잖아?’ 라고 생각했죠. 하지만 HA 환경에서 공유 스토리지는 단일 장애점(Single Point of Failure)이 되면 안 돼요. 제가 겪은 문제는 이랬어요.

    • NFS 서버 단독 장애: NFS 서버 자체가 죽어버리니, 클러스터 노드들이 모두 스토리지에 접근할 수 없게 됐어요. VM은 마이그레이션할 엄두도 못 내고 그냥 멈춰버렸거든요. HA는 발동해야 하는데, VM이 그냥 멈춰버리는 거였어요.
    • 네트워크 지연: NAS와 Proxmox 노드 간의 네트워크가 불안정하거나 지연이 발생하면, VM이 I/O 작업을 제대로 수행하지 못해 버벅이거나 멈춰버렸어요. HA가 아무리 좋아도 스토리지 접근이 안 되면 무용지물이더라고요.

    💡 교훈: 공유 스토리지는 HA 클러스터의 심장과 같아요. 안정성과 성능을 최우선으로 고려해야 돼요. NFS도 좋지만, 분산 파일 시스템(Distributed File System)이나 블록 스토리지(Block Storage)를 고려했으면 좋았어요. (예: Ceph, iSCSI 기반 SAN)

    문제 2: 네트워크 이중화 미흡

    클러스터 통신(Corosync)은 네트워크에 매우 민감해요. 저는 단순히 노드 간에 네트워크 케이블 하나씩만 연결했었는데, 이게 큰 문제더라고요.

    • Corosync 패킷 유실: 네트워크 케이블이나 스위치 포트에 문제가 생기자마자, Corosync 패킷 유실이 발생했어요.
    • 클러스터 핑퐁 & Split-brain: 패킷 유실이 심해지자, 노드들이 서로 ‘상대방이 죽었나?’ 라고 생각하기 시작했어요. 결국 양쪽 노드가 자신이 클러스터의 ‘진짜’ 마스터라고 주장하는 Split-brain (스플릿 브레인)이라는 대참사가 벌어졌어요. VM이 양쪽에서 동시에 실행되려고 하면서 데이터가 완전히 꼬여버리는 경험을 했었어요. 끔찍하더라고요.

    💡 교훈: 클러스터 통신용 네트워크는 반드시 이중화(Redundancy)해야 돼요. 네트워크 본딩(Bonding)이나 별도의 물리 스위치를 사용하는 게 필수더라고요.

    문제 3: 쿼럼(Quorum) 문제와 펜싱(Fencing)의 부재

    제가 구성했던 2노드 Proxmox 클러스터는 한 노드가 다운되자마자 남은 노드가 쿼럼(Quorum)을 상실하고 모든 서비스를 멈춰버렸어요. HA를 구성했는데도 서비스가 멈춰버리는 꼴을 봐야 했었어요.

    • 2노드 쿼럼 상실: 2노드 클러스터는 노드 1개가 죽으면 쿼럼(과반수)을 채울 수 없어요. Proxmox는 데이터 일관성을 위해 쿼럼이 없으면 서비스를 중단시켜요. 저는 이 기본적인 메커니즘을 제대로 이해하지 못했었거든요.
    • QDevice (쿼럼 디바이스) 미사용: 2노드 클러스터의 쿼럼 문제를 해결하기 위해 QDevice를 사용했으면 좋았는데, 당시에는 그 존재조차 몰랐었어요. QDevice가 제3의 투표권을 행사해서 한 노드가 죽어도 쿼럼을 유지시켜 줄 수 있었거든요.
    • Fencing (펜싱) 부재: 펜싱은 문제가 생긴 노드가 클러스터 자원에 접근하지 못하도록 강제로 격리하는 메커니즘이에요. 예를 들어, 죽은 노드의 전원을 강제로 차단해서 Split-brain을 방지하는 역할을 해요. 저는 이런 펜싱 메커니즘을 전혀 고려하지 않고 있었어요.

    💡 교훈: 2노드 클러스터라면 QDevice는 선택이 아닌 필수예요. 그리고 펜싱 메커니즘(예: IPMI, iLO, DRAC 등을 활용한 전원 제어)을 반드시 고려해야 돼요. 이게 없으면 클러스터가 제 역할을 못하거나 더 큰 문제를 야기할 수 있어요.

    정상적으로 운영되는 Proxmox HA 클러스터의 대시보드 화면

    안정적으로 운영되는 Proxmox HA 클러스터의 대시보드 화면입니다. 모든 노드가 정상적으로 작동하며, VM의 HA 상태가 활성화되어 있음을 보여줍니다.

    5. 실패를 통해 배운 교훈과 안정적인 Proxmox HA 운영 노하우

    이러한 삽질들을 통해 제가 얻은 Proxmox HA 운영 노하우는 다음과 같아요.

    1. 공유 스토리지의 중요성을 인지하라: 단순 NFS보다는 Ceph(세프)나 ZFS over iSCSI/NFS, 또는 전용 SAN(Storage Area Network) 스토리지를 고려해야 돼요. 특히 Ceph는 Proxmox와 통합이 잘 되어 있어 좋은 선택지예요. 저도 나중에는 Ceph를 홈랩에 구축해서 사용해봤는데, 정말 든든하더라고요.
    2. 네트워크 이중화는 필수 중의 필수!: Corosync 통신용 네트워크는 반드시 본딩(Bonding)을 통해 이중화하고, 가능하다면 물리적으로 분리된 스위치를 사용해야 돼요. 클러스터 네트워크의 안정성이 HA의 성패를 좌우해요.
    3. 쿼럼과 QDevice를 정확히 이해하라: 2노드 클러스터라면 QDevice는 꼭 설정해야 돼요. 3노드 이상이 이상적이지만, 2노드 구성 시 QDevice는 쿼럼 상실을 막는 핵심이에요.
    4. 펜싱(Fencing) 메커니즘을 고려하라: IPMI, iLO, DRAC 같은 BMC(Baseboard Management Controller)를 활용하여 장애 노드의 전원을 강제로 차단하는 펜싱 메커니즘을 구성하는 게 Split-brain을 방지하는 가장 확실한 방법이에요.
    5. 충분한 테스트는 생명이다: 클러스터 구축 후에는 반드시 장애 시나리오 테스트를 충분히 수행해야 돼요. 노드 강제 종료, 네트워크 케이블 뽑기 등 실제 장애 상황을 시뮬레이션하며 HA가 제대로 동작하는지 확인해야 돼요. 이 과정을 통해서 예상치 못한 문제점을 발견하고 해결할 수 있어요.

    6. 마무리

    3년차 시절의 Proxmox HA 클러스터 실패는 저에게 잊을 수 없는 경험으로 남아있어요. 당시에는 좌절도 하고 밤샘 삽질도 많이 했지만, 그 과정에서 고가용성 시스템의 복잡성과 중요성, 그리고 탄탄한 기본기 없이는 어떤 기술도 제대로 활용할 수 없다는 것을 뼈저리게 느꼈어요.

    여러분은 저처럼 무작정 시도했다가 삽질하지 말고, 충분한 학습과 계획을 통해 안정적인 Proxmox HA 클러스터를 성공적으로 구축하시길 바라요. 이 글이 여러분의 클러스터 장애 극복 여정에 작은 도움이 되었으면 좋겠어요. 다음에 더 유익한 내용으로 찾아오겠습니다! 💡

    Proxmox HA 클러스터 구축 시 반드시 고려해야 할 핵심 요소 요약 인포그래픽

    Proxmox HA 클러스터 구축 시 반드시 고려해야 할 핵심 요소들을 요약한 인포그래픽입니다. 공유 스토리지, 네트워크 이중화, 쿼럼, 펜싱, 테스트의 중요성을 강조합니다.

  • [Proxmox] Proxmox HA 클러스터: 고가용성 구축 및 장애 복구 전략

    [Proxmox] Proxmox HA 클러스터: 고가용성 구축 및 장애 복구 전략

    목차

    13년차 인프라 엔지니어의 Proxmox HA 클러스터 구축 삽질기

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 Proxmox HA 클러스터(High Availability Cluster, 고가용성 클러스터) 구축 경험담을 풀어보려고 합니다. 인프라 엔지니어에게 고가용성(HA)은 마치 공기와도 같죠. 서비스가 멈추지 않고 항상 돌아가도록 하는 것, 그게 바로 저희의 숙명이잖아요?

    저도 처음에는 단순히 서버 한 대에 가상 머신(VM) 몇 개 돌리는 것으로 시작했습니다. 그런데 어느 날 갑자기 서버가 뻗는 경험을 몇 번 하고 나니, ‘아, 이러면 안 되겠다!’ 싶더라고요. 특히 홈랩(Homelab)에서 이것저것 실험하다 보면 예기치 않은 장애가 자주 발생하거든요. 그래서 장애 복구(Disaster Recovery)는 물론이고, 장애 발생 시에도 서비스가 멈추지 않도록 자동으로 복구(Automatic Failover)되는 시스템이 절실해졌습니다. 그때 제 눈에 들어온 것이 바로 Proxmox HA 클러스터였습니다.

    Proxmox VE(Virtual Environment)는 오픈소스 가상화 플랫폼으로, 클러스터(Cluster) 기능을 제공해서 여러 대의 서버를 하나로 묶을 수 있어요. 여기에 HA(High Availability) 기능을 추가하면, 특정 노드(Node)에 문제가 생겨도 그 위에서 돌아가던 가상 머신이나 컨테이너(LXC)가 다른 살아있는 노드로 자동으로 이동해서 계속 서비스를 이어나갈 수 있습니다. 이거 정말 매력적이지 않나요? 덕분에 저도 밤에 편안하게 잘 수 있게 됐습니다. 🥳

    Proxmox HA 클러스터의 기본적인 아키텍처를 보여주는 다이어그램입니다. 여러 노드가 Corosync 네트워크로 연결되어 있고, 공유 스토리지에서 VM 디스크를 사용하며, HA 매니저가 가상 머신들을 관리하는 모습을 나타냅니다.

    Proxmox HA, 그게 뭔데요? (핵심 개념 설명)

    Proxmox HA 클러스터를 이해하기 위해 몇 가지 핵심 개념을 짚고 넘어가야 합니다. 제가 처음 접했을 때 헷갈렸던 부분들이거든요.

    • Proxmox VE (PVE): Debian 기반의 오픈소스 가상화 플랫폼입니다. KVM(Kernel-based Virtual Machine)과 LXC(Linux Containers)를 지원하죠.
    • 클러스터(Cluster): 여러 대의 Proxmox 서버(노드)를 하나의 그룹으로 묶어주는 기능이거든요. 이렇게 하면 중앙 집중식으로 관리할 수 있고, 자원도 공유하며 HA 구성의 기반이 돼요.
    • HA (High Availability, 고가용성): 이게 오늘의 주인공이죠! 클러스터 내의 특정 노드에 하드웨어 장애나 소프트웨어 문제가 발생했을 때, 해당 노드에서 실행 중이던 VM이나 LXC를 자동으로 다른 정상 노드로 옮겨서 서비스 중단을 최소화하는 기능입니다.
    • Corosync (코로싱크): 클러스터 노드들이 서로 통신하게 해주는 핵심 메커니즘이거든요. 클러스터 노드 간의 상태 정보를 주고받고, 노드 실패를 감지하며, 쿼럼(Quorum)을 관리하는 역할을 합니다. 클러스터 노드들이 서로 살아있는지 확인하는 ‘심장 박동(Heartbeat)’ 같은 거죠.
    • 쿼럼(Quorum): 클러스터가 의사결정하는 방식이에요. 스플릿 브레인(Split-Brain) 현상을 방지하기 위해, 클러스터 노드 중 과반수 이상이 정상적으로 통신해야만 클러스터가 정상 작동한다고 판단합니다. 예를 들어 3노드 클러스터에서는 최소 2노드가 살아있어야 쿼럼이 유지됩니다. 💡 팁: 그래서 노드 개수는 3개, 5개처럼 홀수(Odd Number)로 구성하는 것이 일반적입니다.

    쉽게 말해, Proxmox HA는 여러 대의 Proxmox 서버를 끈끈하게 엮어서, 한 대가 쓰러져도 나머지 서버들이 재빨리 그 업무를 이어받아 서비스가 끊기지 않도록 하는 마법 같은 기능이라고 할 수 있습니다. 물론 마법을 부리려면 몇 가지 준비물이 필요하죠!

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

    자, 이제 저와 함께 Proxmox HA 클러스터를 직접 구축해봅시다. 제가 홈랩에서 삽질하며 얻은 노하우를 아낌없이 풀어드릴게요!

    1단계: Proxmox VE 노드 준비

    클러스터를 구성하려면 최소 2대 이상의 Proxmox VE가 설치된 서버가 필요합니다. 하지만 위에서 말씀드렸듯이, 안정적인 HA를 위해서는 3대 이상의 노드를 준비하는 것을 강력히 추천합니다. 모든 노드는 동일한 Proxmox VE 버전으로 설치하는 것이 좋습니다.

    • 네트워크 설정: 각 노드에는 안정적인 네트워크 연결이 필수입니다. 가능하면 Corosync 통신을 위한 별도의 네트워크 인터페이스(NIC)를 구성하는 것이 좋습니다.
    • SSH 연결: 각 노드에 SSH로 접근할 수 있는지 미리 확인해주세요.

    2단계: 클러스터 생성 및 노드 추가

    가장 먼저 클러스터를 생성하고, 다른 노드들을 여기에 추가해야 합니다. 저는 주로 CLI(Command Line Interface)를 선호하는데, 웹 UI에서도 가능합니다.

    1. 첫 번째 노드에서 클러스터 생성:
      2. pvecm create <클러스터_이름>
# 예시: pvecm create my-ha-cluster

      이 명령어를 실행하면 첫 번째 노드가 클러스터의 리더가 됩니다.

    2. 두 번째 노드부터 클러스터에 추가:

      3. 각 추가할 노드에서 다음 명령어를 실행합니다. `<첫_번째_노드_IP>`는 클러스터를 생성한 첫 번째 노드의 IP 주소입니다.

      pvecm add <첫_번째_노드_IP>
# 예시: pvecm add 192.168.1.100

      이때 첫 번째 노드의 root 비밀번호를 입력하라고 나옵니다. 성공적으로 추가되면 모든 노드가 동일한 클러스터에 속하게 됩니다.

    3. 클러스터 상태 확인:

      4. 어떤 노드에서든 다음 명령어를 실행하여 클러스터 상태를 확인합니다.

      pvecm status

      모든 노드가 ‘Online’ 상태이고, ‘Quorum’이 ‘active’로 표시되면 성공입니다! 🎉

    Proxmox 웹 UI에서 클러스터 노드와 쿼럼 상태를 확인하는 화면

    Proxmox 웹 UI에서 클러스터 노드들의 목록과 상태를 보여주는 화면입니다. 각 노드의 ‘Status’가 ‘online’으로 표시되어 있고, ‘Quorum’이 정상적으로 작동하는 것을 확인할 수 있습니다.

    3단계: 공유 스토리지 설정 (NFS 또는 Ceph)

    HA를 제대로 활용하려면 공유 스토리지(Shared Storage)가 필수입니다. 왜냐하면 노드에 장애가 발생했을 때, 다른 노드에서 장애가 난 VM의 디스크 이미지를 바로 이어서 사용할 수 있어야 하거든요. NFS(Network File System)나 Ceph(분산 스토리지)가 대표적인데요, 저는 홈랩에서 NFS를 많이 썼고, 규모가 커지면 Ceph를 고려해보는 편입니다.

    여기서는 간단하게 NFS 스토리지를 추가하는 방법을 예시로 들어볼게요. (NFS 서버는 별도로 구축되어 있다고 가정합니다.)

    1. Proxmox 웹 UI 접속:

      2. Datacenter -> Storage -> Add -> NFS 선택.

    2. NFS 설정 정보 입력:
      • ID: 스토리지 이름 (예: nfs-share)
      • Server: NFS 서버 IP 주소
      • Export: NFS 서버의 공유 경로 (예: /mnt/nfs_data)
      • Content: Disk image, Container template 등을 선택

      이렇게 설정하면 클러스터의 모든 노드가 이 NFS 스토리지를 공유하게 됩니다. 이제 VM을 생성할 때 이 공유 스토리지를 선택하면 HA 구성 준비가 거의 끝난 겁니다!

    4단계: HA 그룹 및 자원 설정

    이제 어떤 VM이나 LXC를 HA의 보호 아래 둘지 결정하고 설정해야 합니다.

    1. HA 그룹 생성 (선택 사항):

      2. Datacenter -> HA -> Groups 탭에서 HA 그룹을 만들 수 있습니다. 특정 노드에만 VM이 배치되도록 하거나, 특정 순서로 배치되도록 하는 등의 정책을 설정할 수 있어요. 저는 보통 기본 그룹을 사용하지만, 복잡한 환경에서는 유용합니다.

    2. VM/LXC에 HA 정책 적용:

      3. HA를 적용할 VM 또는 LXC를 선택하고, 왼쪽 메뉴에서 HA 탭을 클릭합니다. 여기서 Add 버튼을 눌러 HA 자원으로 추가합니다.

      • Policy (정책):
        • started: 노드가 다운되면 다른 노드에서 자동으로 시작합니다. (가장 일반적)
        • stopped: 노드가 다운되어도 자동으로 시작하지 않습니다.
        • relocatable: 수동으로 다른 노드로 옮길 수 있습니다.

        저는 대부분 started 정책을 사용합니다. 이게 바로 HA의 핵심이거든요!

      웹 UI로도 쉽게 설정할 수 있으며, Datacenter -> HA -> Resources 탭에서 현재 HA 자원들의 상태를 확인할 수 있습니다.

    ⚠️ 삽질 경험담: 쿼럼, 네트워크, 그리고 스플릿 브레인

    제가 Proxmox HA를 구축하면서 가장 많이 겪었던 문제들은 바로 쿼럼, 네트워크, 그리고 스플릿 브레인이었습니다. 독자분들은 저처럼 삽질하지 않으시길 바라며 제 경험을 공유합니다.

    쿼럼(Quorum) 깨짐 문제

    가장 흔한 문제 중 하나입니다. 예를 들어 3노드 클러스터에서 2대가 동시에 다운되면 쿼럼이 깨집니다. 쿼럼이 깨지면 클러스터는 더 이상 의사결정을 할 수 없게 되고, HA 기능도 작동하지 않습니다. VM들이 제자리에 멈춰버리는 거죠. 😱

    • 해결책:
      • 항상 노드 개수를 홀수로 유지하세요. (최소 3개, 이상적으로는 5개)
      • 노드 복구 후 pvecm status로 쿼럼 상태를 확인합니다.
      • 만약 한 노드만 영구적으로 손상되어 제거해야 한다면, pvecm delnode <노드_이름> 명령어를 사용하여 클러스터에서 안전하게 제거해야 합니다.
      • 2노드 클러스터의 경우 QDevice (큐디바이스)를 설정하여 쿼럼 안정성을 높일 수 있습니다. QDevice는 클러스터 외부에 있는 경량 프로세스로, 쿼럼 투표권을 하나 더 제공해서 2노드 클러스터에서 한 노드가 죽어도 쿼럼이 깨지지 않도록 도와줍니다.

    네트워크 이중화의 중요성

    Corosync는 네트워크를 통해 통신합니다. 만약 Corosync 네트워크에 문제가 생기면, 노드들은 서로 통신할 수 없게 되고, 살아있는 노드도 죽은 노드로 오인할 수 있습니다. 제가 실제로 겪었던 일인데, 네트워크 케이블 하나가 불량이라 클러스터가 오락가락했던 적이 있었죠… 하하.

    • 해결책:
      • 가능하다면 Corosync 통신을 위한 별도의 네트워크 인터페이스(NIC)를 구성하거나, 링크 어그리게이션(Link Aggregation, 본딩)을 통해 네트워크 이중화를 구성하는 것이 좋습니다.
      • /etc/pve/corosync.conf 파일을 수정하여 두 개의 링(Ring)을 구성할 수도 있습니다.

    스플릿 브레인(Split-Brain) 방지

    스플릿 브레인은 클러스터가 두 개 이상의 독립적인 그룹으로 나뉘어 서로 자신이 진짜라고 생각하고 동작하는 심각한 상황입니다. 예를 들어, 네트워크 문제로 노드 1과 노드 2, 3이 분리되었을 때, 노드 1이 VM을 시작하고 동시에 노드 2, 3이 또 다른 VM을 시작하려고 시도하면 데이터 손상이 발생할 수 있습니다.

    • 해결책:
      • 쿼럼 규칙이 스플릿 브레인을 방지하는 기본적인 메커니즘이지만, 완벽하지 않을 수 있습니다.
      • STONITH (Shoot The Other Node In The Head) 또는 펜싱(Fencing)이라는 개념이 있습니다. 문제가 생긴 노드의 전원을 강제로 차단하여, 해당 노드가 더 이상 클러스터 자원을 사용하지 못하게 하는 방법입니다. Proxmox 자체적으로는 QDevice를 통해 쿼럼을 강화하거나, 외부 펜싱 장비(예: IPMI를 이용한 전원 제어)를 통합하여 사용할 수 있습니다. 홈랩에서는 복잡할 수 있지만, 프로덕션 환경에서는 필수적인 요소입니다.

    제대로 동작하는지 확인해봐야죠! (장애 복구 검증)

    수고해서 클러스터를 구축했으니, 이제 정말 잘 작동하는지 확인해봐야겠죠? 저는 이 순간이 제일 두근거리더라고요. 제가 직접 해보니 가장 확실한 방법은 강제로 노드를 종료시켜보는 겁니다.

    1. HA가 설정된 VM 또는 LXC 확인:

      2. HA 정책이 ‘started’로 설정된 VM이나 LXC가 특정 노드에서 실행 중인지 확인합니다.

    2. 해당 노드 강제 종료:

      3. 해당 노드의 전원 버튼을 길게 누르거나, SSH로 접속하여 poweroff -f 명령어로 강제 종료합니다. (경고: 운영 중인 중요한 서비스에서는 절대 이렇게 하지 마세요! 테스트 환경에서만 시도해야 합니다.)

    3. HA 동작 확인:

      4. 다른 Proxmox 노드의 웹 UI나 pve-ha-manager status 명령어를 통해 해당 VM/LXC가 자동으로 다른 노드로 마이그레이션(Migration)되어 시작되는지 확인합니다. 몇 초에서 몇 분 정도 걸릴 수 있습니다.

      pve-ha-manager status

      성공적으로 다른 노드에서 VM이 ‘running’ 상태로 바뀌면 드디어 성공입니다! 🎉 이 순간의 쾌감은 이루 말할 수 없죠. 제가 밤새 삽질했던 보람을 느끼는 순간입니다.

    Proxmox HA 장애 복구 후 가상 머신이 다른 노드에서 정상 작동하는 대시보드 화면

    Proxmox 웹 UI 대시보드에서 장애가 발생했던 노드의 VM이 다른 노드로 성공적으로 마이그레이션되어 정상 작동 중인 상태를 보여주는 스크린샷입니다. VM의 ‘Status’가 ‘running’으로 표시됩니다.

    Proxmox HA 클러스터, 현명하게 사용하는 팁

    HA 클러스터를 구축했다고 해서 모든 것이 끝나는 건 아닙니다. 더 안정적이고 효율적으로 사용하기 위한 몇 가지 팁을 드릴게요.

    • 백업 전략 수립: HA는 장애 시 서비스를 유지하는 것이지, 데이터 손실을 막아주지는 않습니다. Proxmox Backup Server (PBS)를 이용하거나, 다른 백업 솔루션을 반드시 함께 운영해야 합니다. 제가 예전에 백업을 소홀히 했다가 피눈물을 흘린 적이 있거든요… 😭
    • 모니터링 시스템 구축: 클러스터의 상태, 각 노드의 자원 사용량, VM의 상태 등을 실시간으로 모니터링해야 합니다. Prometheus + Grafana 조합은 홈랩에서도 충분히 활용할 수 있는 강력한 모니터링 툴입니다.
    • 공유 스토리지의 중요성: HA의 성능과 안정성은 공유 스토리지에 크게 의존합니다. NFS 서버의 성능이 떨어지거나 네트워크 대역폭이 부족하면, VM 마이그레이션 시 병목 현상이 발생할 수 있습니다. Ceph와 같은 분산 스토리지는 더 높은 성능과 안정성을 제공하지만, 그만큼 구축과 관리가 복잡하다는 점을 염두에 두세요.
    • 정기적인 테스트: ‘설마’ 하는 마음으로 테스트를 미루다가 실제 장애가 발생했을 때 제대로 작동하지 않는 경우가 있습니다. 주기적으로 HA 기능을 테스트하여 항상 준비된 상태를 유지해야 합니다.
    Proxmox HA 클러스터의 장점과 단점을 비교한 인포그래픽

    Proxmox HA 클러스터의 주요 장점과 고려해야 할 단점들을 시각적으로 비교 정리한 인포그래픽입니다. 고가용성, 중앙 관리 등의 장점과 복잡성, 공유 스토리지 의존성 등의 단점을 간략하게 보여줍니다.

    마무리하며: 안정적인 인프라의 시작

    오늘은 Proxmox HA 클러스터 구축부터 제가 겪었던 삽질 경험, 그리고 검증 방법까지 자세히 이야기해봤습니다. 처음에는 쿼럼이니 스플릿 브레인이니 하는 개념들이 어렵게 느껴졌지만, 직접 부딪혀보고 해결하는 과정을 통해 정말 많은 것을 배웠습니다.

    Proxmox HA는 홈랩 사용자부터 중소기업 환경까지, 안정적인 인프라를 구축하고자 하는 분들에게 정말 좋은 솔루션이라고 생각합니다. 물론 완벽한 시스템은 없지만, HA를 통해 서비스 중단 시간을 최소화하고, 장애 발생 시에도 빠르게 복구할 수 있는 기반을 마련할 수 있습니다.

    여러분의 소중한 서비스, Proxmox HA 클러스터로 든든하게 지켜보시는 건 어떨까요? 이 글이 여러분의 인프라 구축 여정에 작은 도움이 되었기를 바랍니다. 다음번에는 Proxmox Backup Server나 Ceph 스토리지 구축에 대한 이야기를 들고 오겠습니다. 그때까지 모두 안정적인 서버실 되시길! 감사합니다. 👋

  • [Proxmox] Proxmox VE Ceph 클러스터 구축 및 관리 완벽 가이드

    목차

    홈랩에 엔터프라이즈급 스토리지를? Proxmox Ceph 클러스터 도전기

    솔직히 말씀드리면, 처음 Proxmox VE에서 Ceph 클러스터를 구축하려고 했을 때 겁부터 먹었습니다. “분산 스토리지”라는 단어 자체가 주는 무게감이 있잖아요. 대기업 IDC에서나 쓰는 그런 거 아닌가 싶었거든요. 근데 막상 해보니까… 생각보다 훨씬 접근하기 좋더라고요. 물론 삽질은 좀 했습니다 ㅎㅎ.

    Proxmox Ceph 클러스터는 단순히 스토리지 용량을 늘리는 게 아니에요. VM(가상 머신)이나 컨테이너가 어느 노드에서 죽더라도 데이터가 살아있는, 진짜 고가용성(High Availability) 인프라를 만드는 핵심 기술이거든요. 이걸 홈랩에 구현할 수 있다는 게 Proxmox VE의 진짜 매력이라고 생각해요. 오늘은 제가 직접 구축하면서 배운 것들을 처음부터 끝까지 다 풀어드릴게요.

    ▲ Proxmox VE 3노드 Ceph 클러스터 전체 아키텍처 — Public Network, Cluster Network, OSD 구성을 한눈에 볼 수 있습니다.

    Ceph가 뭔지부터 제대로 이해하고 시작하자

    쉽게 말해, Ceph는 어떤 녀석인가요?

    Ceph를 한 줄로 설명하면 “여러 서버의 디스크를 하나의 거대한 스토리지 풀로 묶어주는 오픈소스 분산 스토리지 시스템”입니다. 쉽게 비유하자면, 서버 3대가 있으면 각 서버의 디스크를 전부 합쳐서 하나의 큰 창고처럼 쓰는 거예요. 게다가 데이터를 여러 곳에 복사해두기 때문에 서버 한 대가 꺼져도 데이터는 안전합니다.

    Proxmox VE는 Ceph를 웹 UI에서 직접 설치하고 관리할 수 있도록 통합해놨어요. 예전에 Ceph를 별도로 구성하던 시절을 생각하면 정말 편해진 거죠.

    핵심 구성 요소 이해하기

    구축 전에 이 개념들은 꼭 알고 시작하세요. 처음엔 저도 이게 뭔가 싶었는데, 알고 나면 구성이 훨씬 명확하게 보입니다.

    • MON (Monitor): 클러스터 상태를 감시하는 감시자. 클러스터 맵(어디에 데이터가 있는지 지도)을 관리합니다. 홀수 개로 운영해야 해요 (3개 권장).
    • OSD (Object Storage Daemon): 실제 데이터를 저장하는 데몬. 디스크 하나당 OSD 하나가 대응됩니다. 클러스터의 일꾼이라고 생각하시면 돼요.
    • MGR (Manager): 클러스터 모니터링과 플러그인 관리를 담당. 대시보드, Prometheus 연동 등이 여기서 나옵니다.
    • MDS (Metadata Server): CephFS(파일 시스템)를 쓸 때만 필요한 메타데이터 서버. 오늘 구성에서는 선택사항입니다.
    • Pool (풀): 데이터를 저장하는 논리적 구획. 복제 수(Replication Factor)를 풀 단위로 설정합니다.
    • PG (Placement Group): 데이터를 OSD에 분산 배치하는 단위. 너무 많거나 적으면 성능에 영향을 줍니다.

    네트워크 구성, 이게 제일 중요합니다

    여기서 중요한 포인트! Ceph는 네트워크를 두 개로 분리하는 걸 강력히 권장합니다.

    네트워크 종류 역할 권장 대역폭 비고
    Public Network (퍼블릭 네트워크) 클라이언트 ↔ Ceph 통신, MON 통신 1Gbps 이상 VM이 스토리지에 접근하는 경로
    Cluster Network (클러스터 네트워크) OSD 간 복제 및 리밸런싱 트래픽 10Gbps 권장 분리하면 성능 대폭 향상

    홈랩에서 10Gbps 스위치가 없다면 최소한 두 개의 물리 인터페이스로 분리만 해도 효과가 있어요. 저는 처음에 네트워크를 하나로 합쳐서 썼다가 OSD 리밸런싱 때 VM 네트워크가 뚝뚝 끊기는 걸 경험했거든요 ㅠㅠ.

    구축 환경 및 사전 준비

    최소 구성 요구사항

    Ceph 클러스터는 최소 3개 노드가 필요합니다. 이건 협상이 안 되는 부분이에요. MON이 과반수 투표로 클러스터 상태를 결정하기 때문에 짝수 노드는 스플릿 브레인(Split-Brain) 위험이 있거든요.

    • ✅ 노드 수: 최소 3개 (홀수 권장)
    • ✅ OS: Proxmox VE 7.x 또는 8.x
    • ✅ OSD용 디스크: 노드당 최소 1개 (OS 디스크와 별도)
    • ✅ 네트워크: 노드 간 통신 가능한 네트워크 (가급적 2개 분리)
    • ✅ RAM: OSD 하나당 약 1~2GB 여유 RAM 필요

    제 홈랩 구성은 이렇습니다:

    • 노드 3개: pve01, pve02, pve03
    • 각 노드 OSD 디스크: 500GB SSD × 2개
    • Public Network: 192.168.10.0/24
    • Cluster Network: 192.168.20.0/24

    Proxmox 클러스터 먼저 구성하기

    Ceph를 시작하기 전에 Proxmox VE 클러스터가 먼저 구성되어 있어야 합니다. 아직 안 하셨다면 pve01에서 시작하세요.

    # pve01에서 클러스터 생성
pvecm create my-homelab-cluster

# pve02, pve03에서 클러스터 참여
pvecm add 192.168.10.101  # pve01의 IP

# 클러스터 상태 확인
pvecm status

    클러스터가 정상이면 이제 Ceph 설치로 넘어갑니다.

    Proxmox Ceph 클러스터 단계별 구축

    ▲ Proxmox VE 웹 UI에서 Ceph 설치 마법사를 통해 직관적으로 구성할 수 있습니다. GUI와 CLI 모두 지원합니다.

    1단계: Ceph 패키지 설치

    모든 노드에서 아래 작업을 수행해야 합니다. Proxmox 웹 UI에서 각 노드 → Ceph → Install을 클릭해도 되고, CLI로 해도 됩니다. 저는 CLI가 더 빠르더라고요.

    # 모든 노드(pve01, pve02, pve03)에서 실행
# Proxmox VE 8.x 기준 (Ceph Reef/Quincy 지원)
pveceph install --version reef

# 설치 완료 후 확인
ceph --version

    💡 팁: Proxmox VE 8.x에서는 Ceph Reef(18.x)를 권장합니다. 버전은 Proxmox 버전에 맞게 선택하세요.

    2단계: Ceph 초기화 (pve01에서만)

    클러스터 초기화는 한 노드에서만 합니다. 여기서 네트워크 설정이 핵심이에요.

    # pve01에서만 실행
# Public Network와 Cluster Network를 분리해서 설정
pveceph init \
  --network 192.168.10.0/24 \
  --cluster-network 192.168.20.0/24

# 초기화 확인
ceph status

    3단계: MON (Monitor) 추가

    각 노드에 MON을 추가합니다. 3개 이상의 홀수로 유지하는 게 핵심이에요.

    # pve01에서 순서대로 실행
# pve01 MON 추가
pveceph mon create pve01

# pve02 MON 추가 (pve02에서 실행하거나 pve01에서 원격 실행)
pveceph mon create pve02

# pve03 MON 추가
pveceph mon create pve03

# MON 상태 확인
ceph mon stat

    4단계: MGR (Manager) 추가

    # 각 노드에 MGR 추가 (Active/Standby 구성)
pveceph mgr create pve01
pveceph mgr create pve02
pveceph mgr create pve03

# MGR 상태 확인
ceph mgr stat

    5단계: OSD 추가 — 진짜 데이터 저장소 만들기

    이 단계가 제일 중요합니다. OSD를 추가하기 전에 대상 디스크가 완전히 초기화되어 있어야 해요. 파티션이 남아있으면 추가가 안 됩니다.

    # 디스크 초기화 (주의: 데이터 전부 날아갑니다!)
# 각 노드에서 OSD용 디스크 확인
lsblk

# 디스크에 남은 파티션/서명 제거
wipefs -a /dev/sdb
wipefs -a /dev/sdc

# OSD 추가 (pve01의 /dev/sdb, /dev/sdc)
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

# pve02에서도 동일하게
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

# pve03에서도 동일하게
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

# OSD 상태 확인
ceph osd stat
ceph osd tree

    ⚠️ 주의: wipefs 명령어는 되돌릴 수 없습니다. 반드시 올바른 디스크를 대상으로 하는지 lsblk로 두 번, 세 번 확인하세요. 저는 처음에 하마터면 OS 디스크를 날릴 뻔 했습니다 식은땀 났었어요.

    6단계: Pool (풀) 생성

    이제 실제 VM 디스크를 저장할 풀을 만들 차례입니다.

    # VM 디스크용 RBD(RADOS Block Device) 풀 생성
# size=3: 데이터를 3개 복사 (3노드에 각 1개씩)
# min_size=2: 최소 2개 복사본이 있어야 쓰기 허용
pveceph pool create vm-pool --add-storages

# 풀 상세 설정 (복제 수 조정)
ceph osd pool set vm-pool size 3
ceph osd pool set vm-pool min_size 2

# PG 수 설정 (OSD 수에 따라 조정 — OSD 6개 기준)
# 공식: (OSD 수 × 100) / 복제 수 → 가장 가까운 2의 제곱수
ceph osd pool set vm-pool pg_num 128
ceph osd pool set vm-pool pgp_num 128

# 풀 상태 확인
ceph osd pool ls detail

    💡 PG 수 계산 팁: OSD가 6개면 (6 × 100) / 3 = 200 → 2의 제곱수로 올림하면 256이 되지만, 홈랩 규모에서는 128도 충분합니다. 너무 많으면 오히려 오버헤드가 생겨요.

    7단계: Proxmox Storage에 Ceph 등록

    # Proxmox 스토리지로 등록 (이미 --add-storages 옵션으로 자동 등록됐을 수 있음)
# 웹 UI: Datacenter → Storage → Add → RBD

# CLI로 확인
pvesm status

    ⚠️ 실제로 겪은 트러블슈팅 모음

    문제 1: OSD가 계속 down/out 상태

    OSD를 추가했는데 계속 down 상태로 떠있더라고요. 원인을 찾아보니 디스크에 예전 Ceph 서명이 남아있었어요.

    # 해결 방법: 더 강력한 디스크 초기화
dd if=/dev/zero of=/dev/sdb bs=1M count=100
wipefs -a /dev/sdb

# 그래도 안 되면 sgdisk로 파티션 테이블 초기화
sgdisk --zap-all /dev/sdb

# 이후 OSD 재추가
pveceph osd create /dev/sdb

    문제 2: ceph status가 HEALTH_WARN — “too few PGs per OSD”

    PG 수가 OSD 대비 너무 적거나 많을 때 나오는 경고입니다. 이건 풀의 PG 수를 조정하면 됩니다.

    # 현재 PG 상태 확인
ceph osd pool ls detail

# PG 수 조정 (늘릴 때는 두 배씩)
ceph osd pool set vm-pool pg_num 256
ceph osd pool set vm-pool pgp_num 256

# PG 자동 조정 활성화 (Nautilus 이상)
ceph osd pool set vm-pool pg_autoscale_mode on

    문제 3: 클러스터 네트워크 쪽 OSD 통신 불량

    Cluster Network를 분리했는데 OSD 간 복제가 안 되는 경우가 있었어요. 방화벽 문제였습니다.

    # Ceph OSD 포트 허용 (6800-7300)
# pve 방화벽 설정 확인
cat /etc/pve/firewall/cluster.fw

# 임시로 방화벽 꺼서 테스트
pve-firewall stop

# 정상 확인 후 방화벽 규칙 추가
# /etc/pve/firewall/cluster.fw 에 추가:
# [RULES]
# IN ACCEPT -p tcp --dport 6800:7300 -s 192.168.20.0/24

    문제 4: VM 마이그레이션 시 느림

    Ceph 스토리지로 라이브 마이그레이션(Live Migration)을 했는데 엄청 느렸어요. 알고 보니 마이그레이션 네트워크가 Public Network를 타고 있어서였습니다. Proxmox에서 마이그레이션 전용 네트워크를 지정해주면 해결됩니다.

    # /etc/pve/datacenter.cfg 에서 마이그레이션 네트워크 설정
migration: secure
migration_unsecure: 192.168.20.0/24

    ✅ 클러스터 상태 검증 및 모니터링

    ▲ Ceph 클러스터가 정상 구성되면 HEALTH_OK 상태와 함께 OSD 트리, 풀 사용량을 실시간으로 확인할 수 있습니다.

    필수 확인 명령어

    # 전체 클러스터 상태 (이게 제일 중요)
ceph status
ceph health detail

# OSD 상태 및 트리 구조
ceph osd tree
ceph osd stat

# 풀 사용량
ceph df
ceph osd pool stats

# I/O 실시간 모니터링
ceph -w

# 성능 확인
rados bench -p vm-pool 10 write --no-cleanup
rados bench -p vm-pool 10 seq

    정상 상태 체크리스트

    • ✅ ceph status → HEALTH_OK 표시
    • ✅ MON 쿼럼(Quorum): 3/3 참여
    • ✅ OSD: all up, all in (예: 6/6 OSDs up)
    • ✅ PG: active+clean 상태
    • ✅ MGR: active 1개 + standby 2개

    Proxmox 대시보드에서도 확인

    웹 UI에서 Datacenter → Ceph 메뉴로 가면 OSD 상태, 풀 사용량, I/O 그래프를 한눈에 볼 수 있어요. 이게 진짜 편합니다. CLI로 하나씩 확인하던 시절이 생각나서 감동받았던 기억이 나네요.

    CephFS로 공유 파일시스템도 만들어보자 (보너스)

    VM 디스크(RBD) 외에도 CephFS(Ceph File System)를 구성하면 여러 VM이 동시에 마운트할 수 있는 공유 스토리지를 만들 수 있어요. Kubernetes의 PVC(Persistent Volume Claim)에도 활용할 수 있고요.

    # MDS(Metadata Server) 추가
pveceph mds create pve01
pveceph mds create pve02  # 스탠바이용

# CephFS 생성
pveceph fs create --name cephfs --add-storages

# 상태 확인
ceph fs status
ceph mds stat

    CephFS 마운트 설정은 다음 글에서 Kubernetes 연동과 함께 자세히 다룰 예정입니다!

    구성 옵션 비교 — 내 환경에 맞는 선택은?

    ▲ 환경별 Ceph 구성 전략 비교 — 홈랩, 소규모 사업장, 엔터프라이즈 환경에 따라 최적 구성이 다릅니다.

    구성 옵션 홈랩 (3노드) 소규모 프로덕션 엔터프라이즈
    복제 수 (size) 2~3 3 3+
    OSD 디스크 SATA SSD NVMe SSD NVMe + WAL 분리
    클러스터 네트워크 1Gbps 분리 10Gbps 25Gbps+
    MON 수 3 3~5 5
    BlueStore WAL/DB OSD와 동일 디스크 별도 NVMe 권장 별도 NVMe 필수

    홈랩에서는 복제 수를 2로 설정해서 실제 사용 가능 용량을 늘리는 분들도 있는데, 저는 개인적으로 3을 유지하는 걸 권장합니다. 노드 하나가 죽었을 때도 데이터 안전성이 보장되니까요.

    자주 묻는 질문 (FAQ)

    Q. Ceph는 2노드로 구성할 수 없나요?

    기술적으로 가능은 하지만 권장하지 않습니다. MON이 2개면 한 노드가 죽었을 때 쿼럼을 유지할 수 없어서 클러스터 전체가 멈춥니다. 최소 3노드를 유지하세요.

    Q. 기존 Proxmox에 Ceph를 나중에 추가해도 되나요?

    네, 됩니다! Proxmox 클러스터가 이미 구성된 상태에서 Ceph를 나중에 추가해도 전혀 문제없어요. 저도 그렇게 했거든요. 기존 VM들은 로컬 스토리지를 계속 쓰고, 새 VM부터 Ceph 풀을 지정하면 됩니다.

    Q. OSD 디스크는 HDD도 되나요?

    됩니다. 다만 HDD는 레이턴시(응답 지연)가 높아서 VM 성능에 영향을 줍니다. 가능하면 SSD를 권장하고, HDD를 써야 한다면 BlueStore의 WAL(Write-Ahead Log)과 DB를 별도 SSD에 올리는 구성을 고려해보세요.

    Q. 클러스터에 노드를 나중에 추가할 수 있나요?

    네, Ceph의 가장 큰 장점 중 하나가 바로 수평 확장(Horizontal Scaling)입니다. 노드를 추가하면 Ceph가 자동으로 데이터를 재분배(Rebalancing)합니다. 다만 리밸런싱 중에는 I/O가 좀 느려질 수 있어요.

    마무리 — Proxmox Ceph의 진짜 가치

    처음 Ceph를 공부할 때 “이게 홈랩에서 쓸 수 있는 건가?” 싶었는데, 이제는 제 인프라에서 없어서는 안 될 핵심이 됐습니다. Proxmox VE + Ceph 클러스터 조합이 주는 진짜 가치는 이거예요.

    • 🎉 진짜 고가용성: 노드 하나가 죽어도 VM이 살아있는 인프라
    • 🎉 스토리지 통합 관리: 웹 UI 하나로 모든 걸 관리
    • 🎉 무중단 확장: 서비스 중단 없이 디스크/노드 추가 가능
    • 🎉 오픈소스 무료: 엔터프라이즈급 기능을 라이선스 비용 없이

    물론 단점도 있어요. 초기 구성이 복잡하고, 리소스(특히 RAM)를 꽤 먹습니다. 그리고 문제가 생겼을 때 디버깅이 쉽지 않을 수 있고요. 하지만 한 번 제대로 구성해두면 그 안정성은 정말 믿음직스럽습니다.

    다음 글에서는 Ceph 클러스터 위에 Kubernetes를 올리고 CSI(Container Storage Interface) 드라이버로 연동하는 방법을 다룰 예정이에요. 이전에 Proxmox 기본 클러스터 구성 글도 참고하시면 이번 내용이 더 잘 이해되실 겁니다.

    궁금한 점이나 삽질 경험이 있으시면 댓글로 남겨주세요. 저도 아직 배우는 중이니까요 😄

  • [Proxmox] Proxmox 클러스터 HA 설정: 고가용성 구성 완벽 가이드 2026

    [Proxmox] Proxmox 클러스터 HA 설정: 고가용성 구성 완벽 가이드 2026

    목차

    서버가 꺼졌을 때, 그 순간을 대비해야 합니다

    몇 년 전 일이에요. 새벽 3시에 전화가 울렸습니다. 운영 중인 VM(가상머신)이 돌아가던 물리 서버 하나가 갑자기 다운됐다는 알림이었거든요. 그때 HA(High Availability, 고가용성) 설정이 없었더라면… 생각만 해도 식은땀이 납니다. 다행히 Proxmox 클러스터 HA 덕분에 VM들이 자동으로 다른 노드로 이전됐고, 서비스 중단 시간은 2분도 안 됐어요.

    이 글은 바로 그 경험을 바탕으로 씁니다. Proxmox VE 클러스터 고가용성(HA) 설정을 처음 해보시는 분들, 혹은 설정은 해봤는데 뭔가 불안한 분들을 위한 2026년 기준 실전 가이드예요. 홈랩에서도, 소규모 프로덕션 환경에서도 충분히 적용 가능한 내용으로 가득 채웠으니 끝까지 읽어보세요.

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

    ▲ Proxmox VE 3노드 클러스터 HA 전체 구성도 — 각 노드 간 Corosync 통신, 공유 스토리지, 펜싱 장치 연결 구조를 보여줍니다.

    Proxmox 클러스터 HA, 쉽게 말하면 이겁니다

    처음 Proxmox를 접하시는 분들은 클러스터니 HA니 하는 말들이 좀 낯설 수 있어요. 저도 처음엔 그랬거든요. 하나씩 풀어볼게요.

    클러스터(Cluster)란?

    쉽게 말해서, 여러 대의 물리 서버(노드)를 하나처럼 묶어서 관리하는 구성이에요. Proxmox에서는 최소 3대의 노드가 있어야 제대로 된 클러스터를 구성할 수 있어요. 2대로도 가능하긴 한데, 쿼럼(Quorum, 의사결정 정족수) 문제가 생겨서 실무에서는 권장하지 않습니다.

    HA(High Availability, 고가용성)란?

    클러스터 위에서 동작하는 기능인데요. 특정 노드가 장애가 나면 그 위에서 돌아가던 VM이나 컨테이너를 자동으로 다른 노드에서 재시작해주는 거예요. 사람이 개입하지 않아도 된다는 게 핵심이죠.

    구성 요소 역할 없으면?
    Corosync 노드 간 클러스터 통신 및 하트비트(heartbeat) 관리 노드 상태 파악 불가
    Pve-cluster (pmxcfs) 클러스터 파일시스템, 설정 동기화 설정 불일치 발생
    HA Manager VM/CT 자동 복구 로직 담당 자동 페일오버(failover) 불가
    Fencing (펜싱) 장애 노드를 강제로 격리하는 메커니즘 스플릿 브레인(split-brain) 위험
    공유 스토리지 노드 간 VM 디스크 이미지 공유 HA 적용 대상 VM 제한

    여기서 펜싱(Fencing)이 제일 중요한데, 많은 분들이 이걸 빼먹고 설정하다가 나중에 낭패를 보더라고요. 장애 노드가 실제로 죽었는지, 아니면 네트워크만 끊긴 건지 확인하고 강제로 전원을 끄거나 격리하는 장치예요. 없으면 같은 VM이 두 노드에서 동시에 실행되는 최악의 상황이 생길 수 있거든요.

    사전 준비: Proxmox 클러스터 구성 전 필수 체크사항

    본격적인 설정 전에 체크해야 할 항목들이 있어요. 이거 안 하고 넘어가면 나중에 반드시 삽질하게 됩니다. 제가 보장합니다 ㅎㅎ.

    • 노드 수: 최소 3개 (홀수 권장 — 쿼럼 계산 때문에)
    • Proxmox VE 버전: 모든 노드가 동일한 버전이어야 함 (2026년 기준 PVE 8.x)
    • 네트워크: 클러스터 통신용 전용 네트워크 분리 권장 (1Gbps 이상)
    • 시간 동기화: NTP 설정 필수 — 시간이 틀리면 Corosync가 미칩니다
    • 공유 스토리지: Ceph, NFS, iSCSI 등 — HA가 적용될 VM 디스크는 반드시 공유 스토리지에 있어야 해요
    • 호스트명/DNS: 각 노드의 호스트명이 서로 해석 가능해야 함

    저는 홈랩에서 pve-node1, pve-node2, pve-node3 이렇게 3대로 구성하고 있고, 클러스터 통신은 별도의 10.10.10.0/24 네트워크를 사용해요. 이거 분리 안 하면 VM 트래픽이랑 섞여서 하트비트 지연이 생기거든요.

    단계별 실전 구성: Proxmox 클러스터 HA 설정하기

    1단계: 클러스터 생성 (첫 번째 노드에서)

    pve-node1에서 클러스터를 생성합니다. GUI로 해도 되지만, CLI가 훨씬 빠르고 정확해요.

    # pve-node1에서 실행
pvecm create my-homelab-cluster --link0 10.10.10.1

# 클러스터 상태 확인
pvecm status

    --link0 옵션에는 클러스터 통신 전용 NIC의 IP를 넣어주세요. 메인 IP 쓰셔도 되긴 하는데, 분리하는 게 훨씬 안정적이더라고요.

    2단계: 나머지 노드 합류

    # pve-node2에서 실행
pvecm add 10.10.10.1 --link0 10.10.10.2

# pve-node3에서 실행
pvecm add 10.10.10.1 --link0 10.10.10.3

# node1에서 전체 노드 확인
pvecm nodes

    합류할 때 SSH 비밀번호 입력을 요구하는데, 이건 정상이에요. Proxmox가 SSH로 접속해서 인증서를 교환하는 과정이거든요.

    3단계: 공유 스토리지 설정 (Ceph 기준)

    저는 홈랩에서 Proxmox 내장 Ceph를 쓰는데, 설정이 생각보다 간단해졌어요. 특히 PVE 8.x부터는 GUI에서 거의 다 됩니다.

    # 각 노드에서 Ceph 패키지 설치
pveceph install --version reef

# Ceph 초기화 (node1에서)
pveceph init --network 10.10.20.0/24

# 모니터 데몬 추가 (각 노드에서)
pveceph mon create

# OSD(Object Storage Daemon) 추가 — /dev/sdb는 Ceph 전용 디스크
pveceph osd create /dev/sdb

# Ceph 풀(pool) 생성
pveceph pool create vm-pool --pg_num 128

# Proxmox 스토리지로 등록
pvesm add rbd ceph-storage --monhost 10.10.20.1,10.10.20.2,10.10.20.3 \
  --pool vm-pool --username admin --krbd 0

    Ceph 말고 NFS나 iSCSI를 쓰셔도 됩니다. 중요한 건 모든 노드에서 접근 가능한 공유 스토리지여야 한다는 거예요.

    4단계: 펜싱(Fencing) 설정

    이게 진짜 중요한데 많이들 건너뛰더라고요. 펜싱 없이 HA 쓰면 스플릿 브레인(split-brain) 상황에서 데이터 손상이 생길 수 있어요.

    가장 흔히 쓰는 방법은 IPMI/iDRAC/iLO 같은 BMC(Baseboard Management Controller, 원격 서버 관리 컨트롤러)를 이용한 펜싱이에요.

    # fence-agents 설치
apt install fence-agents

# 펜싱 테스트 (node2의 IPMI로 상태 확인)
fence_ipmilan -a 192.168.1.102 -l admin -p yourpassword -o status

    홈랩처럼 IPMI가 없는 환경이라면 WoL(Wake-on-LAN)이나 스마트 플러그를 이용한 펜싱도 가능해요. 완벽하진 않지만 없는 것보단 낫거든요.

    Proxmox HA Manager 설정 화면 및 리소스 그룹 구성

    ▲ Proxmox VE GUI의 HA Manager 화면 — 리소스 그룹 설정, VM 상태, 펜싱 구성을 한눈에 확인할 수 있습니다.

    5단계: HA 리소스 그룹 및 VM 등록

    드디어 본론이에요! HA 매니저에 VM을 등록해봅시다.

    # HA 그룹 생성 (특정 노드에 우선순위 부여)
ha-manager groupadd prod-group \
  --nodes "pve-node1:3,pve-node2:2,pve-node3:1" \
  --restricted 0 \
  --nofailback 0

# VM 100번을 HA 리소스로 등록
ha-manager add vm:100 \
  --group prod-group \
  --max_restart 3 \
  --max_relocate 2

# HA 상태 확인
ha-manager status

# 특정 VM의 HA 설정 확인
ha-manager config vm:100

    여기서 --max_restart는 같은 노드에서 재시작 시도 횟수, --max_relocate는 다른 노드로 이전 시도 횟수예요. 너무 크게 잡으면 장애 상황에서 복구가 지연될 수 있으니 적당히 설정하세요.

    GUI로 하시려면 Datacenter → HA → Add 메뉴에서 쉽게 할 수 있어요. 저도 처음 설정할 때는 GUI로 감 잡고, 이후에는 CLI로 자동화하는 편이에요.

    6단계: HA 서비스 활성화 확인

    # HA 관련 서비스 상태 확인
systemctl status pve-ha-lrm  # Local Resource Manager
systemctl status pve-ha-crm  # Cluster Resource Manager
systemctl status corosync
systemctl status pve-cluster

# 클러스터 전체 상태 한 번에 확인
pvecm status
ha-manager status

    ⚠️ 실제로 겪은 Proxmox HA 트러블슈팅 사례들

    설정하다 보면 반드시 뭔가 꼬이는 순간이 와요. 제가 겪은 것들 공유할게요.

    문제 1: 쿼럼 손실 (Quorum Lost)

    노드 하나 내렸더니 클러스터 전체가 멈춰버린 적 있었어요. 3노드 중 1개만 내렸는데도요.

    # 쿼럼 상태 확인
pvecm status | grep Quorum

# 긴급 상황에서 쿼럼 강제 설정 (절대 프로덕션에서 함부로 쓰지 마세요!)
# 이건 정말 최후의 수단입니다
pvecm expected 1

    원인은 Corosync 링크 설정이 잘못돼 있었어요. /etc/corosync/corosync.conf에서 링크 주소가 메인 IP로 잡혀있던 거였죠. 클러스터 전용 IP로 수정하고 나서 해결됐습니다.

    문제 2: VM이 HA 대상이 안 되는 경우

    VM 디스크가 로컬 스토리지에 있으면 HA 등록 자체가 안 돼요. 반드시 공유 스토리지로 이전해야 합니다.

    # VM 100의 디스크를 로컬에서 Ceph로 마이그레이션
qm move-disk 100 scsi0 ceph-storage --delete 1

# 마이그레이션 후 디스크 위치 확인
qm config 100 | grep scsi

    문제 3: 펜싱 실패로 HA가 동작 안 하는 경우

    이건 진짜 당황스러웠어요. 노드가 죽었는데 VM이 다른 노드로 안 넘어가는 거예요. 로그 확인해보니 펜싱 에이전트가 응답을 못 받아서 HA 매니저가 안전하게 대기 중인 거였어요.

    # HA 매니저 로그 확인
journalctl -u pve-ha-crm -f
journalctl -u pve-ha-lrm -f

# 펜싱 에이전트 직접 테스트
fence_ipmilan -a [IPMI_IP] -l [USER] -p [PASS] -o status

# 수동 펜싱 (테스트용)
fence_ipmilan -a [IPMI_IP] -l [USER] -p [PASS] -o reboot

    결국 IPMI 비밀번호가 변경됐던 게 문제였어요. 펜싱 설정도 업데이트해주니까 바로 해결됐습니다. 이런 거 있을 줄은… ㅎㅎ

    문제 4: 시간 동기화 문제

    # NTP 상태 확인
timedatectl status
chronyc tracking

# /etc/chrony/chrony.conf 설정
pool ntp.ubuntu.com iburst
pool time.cloudflare.com iburst

# chrony 재시작
systemctl restart chronyd

    HA 동작 검증: 실제로 노드를 꺼봤습니다

    설정만 하고 테스트 안 하면 진짜 장애 때 믿을 수 없잖아요. 저는 분기마다 한 번씩 의도적으로 노드를 내려서 HA가 제대로 동작하는지 확인해요.

    1. 테스트할 노드에서 실행 중인 HA VM 확인
    2. 해당 노드의 전원을 강제로 차단 (graceful shutdown이 아닌 hard power off)
    3. HA 매니저가 장애를 감지하고 VM을 다른 노드에서 재시작하는 시간 측정
    4. 서비스 가용성 확인
    # 다른 노드에서 HA 복구 과정 실시간 모니터링
watch -n 2 'ha-manager status; echo "---"; pvecm status'

# VM ping 테스트로 다운타임 측정
ping -i 0.5 [VM_IP] | ts '%H:%M:%.S'

# 복구 후 VM이 어느 노드에서 실행 중인지 확인
qm status 100
pct status 200
    Proxmox HA 페일오버 테스트 결과 대시보드

    ▲ HA 페일오버 테스트 결과 — 노드 장애 감지부터 VM 재시작 완료까지 약 90초 소요, ping 손실 패킷 수와 복구 타임라인을 시각화한 모니터링 화면입니다.

    제 환경에서는 보통 60~120초 안에 VM이 다른 노드에서 살아납니다. 이 시간은 fence_delay, ha-manager의 타임아웃 설정에 따라 달라지는데, 너무 짧게 잡으면 일시적인 네트워크 끊김에도 불필요한 페일오버가 발생하니 주의하세요.

    VM 백업과 HA: 같이 챙겨야 합니다

    HA가 있다고 백업을 소홀히 하면 안 돼요. HA는 하드웨어 장애에 대한 자동 복구지, 데이터 손실에 대한 보호는 아니거든요. 스토리지 자체가 날아가면 HA도 소용없습니다.

    # Proxmox Backup Server(PBS)를 이용한 자동 백업 설정
# /etc/pve/jobs.cfg에 추가되거나 GUI에서 설정 가능

# vzdump으로 VM 백업 (CLI)
vzdump 100 --storage pbs-storage --mode snapshot --compress zstd

# 백업 스케줄 확인
pvesched list

    저는 Proxmox Backup Server(PBS)를 별도 머신에 구축해서 매일 새벽 2시에 자동 백업 돌리고 있어요. VM 백업 관련해서는 별도 글로 자세히 다룰 예정이니 참고해 주세요.

    정리: Proxmox 클러스터 HA 완성 체크리스트

    Proxmox 클러스터 HA 설정 체크리스트 및 아키텍처 요약 인포그래픽

    ▲ Proxmox VE 클러스터 HA 구성 완료 체크리스트 — 클러스터 생성부터 펜싱, 공유 스토리지, HA 리소스 등록, 백업까지 단계별 요약 인포그래픽입니다.

    단계 항목 상태
    1 3개 이상 노드 준비, 동일 PVE 버전 ✅ 필수
    2 클러스터 전용 네트워크 분리 ✅ 강력 권장
    3 NTP 시간 동기화 설정 ✅ 필수
    4 공유 스토리지 구성 (Ceph/NFS/iSCSI) ✅ 필수
    5 펜싱 에이전트 설정 및 테스트 ✅ 필수
    6 HA 그룹 및 리소스 등록 ✅ 필수
    7 실제 페일오버 테스트 ✅ 필수
    8 VM 백업 스케줄 설정 ✅ 강력 권장

    마치며: 장애는 반드시 옵니다

    13년 동안 인프라 일을 하면서 배운 게 있다면, 장애는 일어나지 않는 게 아니라 언제 일어나느냐의 문제라는 거예요. Proxmox 클러스터 HA는 그 순간을 위한 보험이에요.

    처음 설정할 때는 복잡해 보이지만, 한 번 제대로 구성해두면 정말 든든합니다. 새벽 3시 전화 받고도 “어, 자동으로 넘어갔네” 하고 다시 잘 수 있거든요. 그 경험, 정말 소중하더라고요.

    궁금한 점이 있으시면 댓글로 남겨주세요. 다음 글에서는 Proxmox에서 Ceph 스토리지 세부 튜닝과 PBS(Proxmox Backup Server) 구축을 다룰 예정이에요. 이 두 가지가 HA랑 같이 있으면 진짜 완성된 인프라가 됩니다. 기대해 주세요! 🎉

    자주 묻는 질문 (FAQ)

    Q. Proxmox HA는 몇 대부터 가능한가요?

    기술적으로는 2대도 가능하지만, 쿼럼 구성을 위해 최소 3대를 강력히 권장합니다. 2대 구성은 한 노드가 죽으면 쿼럼을 잃어 클러스터가 동작을 멈춰요. QDevice(외부 쿼럼 장치)를 쓰면 2노드도 어느 정도 보완이 가능하더라고요.

    Q. 펜싱 장치가 없으면 HA를 쓰면 안 되나요?

    공식적으로는 펜싱 없이도 동작하지만, 프로덕션 환경에서는 절대 권장하지 않아요. 펜싱 없이 HA를 쓰면 스플릿 브레인 상황에서 데이터 손상이 발생할 수 있거든요. 홈랩이라면 소프트웨어 펜싱이나 스마트 플러그로라도 구성하세요.

    Q. HA VM의 라이브 마이그레이션(Live Migration)과 HA 페일오버의 차이는?

    라이브 마이그레이션은 VM이 실행 중인 상태에서 다운타임 없이 다른 노드로 이전하는 거예요. HA 페일오버는 노드 장애 시 VM을 다른 노드에서 재시작하는 거라 약간의 다운타임이 발생해요. 라이브 마이그레이션은 계획된 유지보수에, HA는 비계획 장애 대응에 쓰입니다.