13년차의 서버실

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

[태그:] Proxmox VE

  • [Proxmox] Proxmox 네트워크 설정: 브릿지, VLAN, 본딩 완벽 가이드

    [Proxmox] Proxmox 네트워크 설정: 브릿지, VLAN, 본딩 완벽 가이드

    안녕하세요, 13년차의 서버실 주인장입니다. 홈랩을 운영하면서 다양한 가상화 환경을 구축하고 테스트해보곤 하는데요. 그중에서도 Proxmox VE(Virtual Environment)는 제가 가장 즐겨 사용하는 하이퍼바이저(Hypervisor) 중 하나입니다.

    Proxmox VE는 뛰어난 성능과 유연성으로 많은 서버실 엔지니어들의 사랑을 받고 있죠. 하지만 Proxmox VE를 처음 접하는 분들이 가장 어려워하는 부분이 바로 네트워크 설정이 아닐까 싶습니다. 브릿지(Bridge)는 또 뭐고, VLAN(Virtual Local Area Network)은 어떻게 적용하며, 본딩(Bonding)은 왜 필요한지… 저도 처음엔 이게 뭔가 싶어서 꽤 삽질했었거든요. ㅎㅎ

    오늘은 제가 지난 13년간 인프라 엔지니어로서 쌓아온 경험과 홈랩에서 직접 Proxmox VE를 만지면서 얻은 노하우를 바탕으로, Proxmox 네트워크 설정의 핵심인 브릿지, VLAN, 본딩을 완벽하게 마스터할 수 있는 가이드를 준비했습니다. 이 글을 통해 여러분의 Proxmox VE 환경이 더욱 안정적이고 효율적으로 변모할 수 있기를 바랍니다!

    Proxmox VE 네트워크의 핵심 구성 요소들을 한눈에 볼 수 있는 다이어그램입니다. 브릿지, VLAN, 본딩이 물리 네트워크와 어떻게 연결되는지 시각적으로 보여줍니다.

    Proxmox 네트워크 설정, 왜 이렇게 복잡해 보일까요? (브릿지, VLAN, 본딩 개념 이해)

    본격적인 설정에 앞서, 우리가 다룰 세 가지 핵심 개념을 먼저 명확히 이해하고 넘어가는 것이 중요합니다. 이 개념들을 잘 알아두면 나중에 트러블슈팅할 때도 훨씬 수월할 거예요.

    1. 브릿지(Bridge): 가상 스위치의 시작

    Proxmox VE에서 브릿지(Bridge)는 물리 네트워크 인터페이스와 가상 머신(VM) 및 컨테이너(LXC)를 연결해주는 가상의 스위치(Switch) 역할을 합니다. 쉽게 말해, 물리 서버 안에 소프트웨어적으로 스위치를 하나 더 만들어서 여러 가상 머신들이 그 스위치에 연결되도록 하는 거죠.

    • vmbr0: Proxmox VE를 설치하면 기본적으로 생성되는 브릿지입니다. 보통 물리 이더넷 카드(예: eno1)와 연결되어 외부 네트워크와 통신하는 역할을 합니다.
    • 역할: 여러 가상 머신들이 하나의 물리 네트워크 인터페이스를 공유하며, 마치 같은 물리 스위치에 연결된 것처럼 서로 통신할 수 있게 해줍니다.

    2. VLAN(Virtual Local Area Network): 네트워크 분리의 마법

    VLAN(Virtual Local Area Network, 가상 근거리 통신망)은 하나의 물리 네트워크 스위치를 여러 개의 논리적인 네트워크로 분리하는 기술입니다. 보안, 성능, 관리 효율성 등 여러 이유로 네트워크를 분리하고 싶을 때 사용하죠. Proxmox VE에서는 가상 머신이나 컨테이너에 특정 VLAN ID를 할당하여 해당 VLAN에 속한 네트워크 트래픽만 주고받도록 설정할 수 있습니다.

    • 태깅(Tagging): 이더넷 프레임에 VLAN ID를 추가하여 어떤 VLAN에 속하는 트래픽인지 식별합니다. IEEE 802.1Q 표준을 따릅니다.
    • 활용: 웹 서버용 VLAN, DB 서버용 VLAN, 관리용 VLAN 등 용도에 따라 네트워크를 분리하여 보안을 강화하고 트래픽 혼잡을 줄일 수 있습니다.

    3. 본딩(Bonding) 또는 티밍(Teaming): 안정성과 성능 두 마리 토끼

    본딩(Bonding)은 여러 개의 물리 네트워크 인터페이스를 하나의 논리적인 인터페이스로 묶는 기술입니다. 윈도우 서버에서는 티밍(Teaming)이라고도 부르죠. 이 기술을 사용하면 두 가지 주요 이점을 얻을 수 있습니다.

    • 고가용성(High Availability, HA): 하나의 물리 NIC(Network Interface Card)에 장애가 발생하더라도 다른 NIC를 통해 네트워크 연결이 유지됩니다. (Failover)
    • 성능 향상: 여러 NIC의 대역폭을 합쳐 더 높은 처리량을 얻을 수 있습니다. (Load Balancing)

    본딩 모드에는 Active-Backup, LACP(Link Aggregation Control Protocol) 등 여러 가지가 있는데, 이 부분은 실전 가이드에서 자세히 다뤄볼게요. 저도 처음엔 아무 모드나 쓰면 되는 줄 알았는데, 스위치 설정과 연동이 안 돼서 한참 헤매던 기억이 있네요. 😅

    Proxmox 네트워크 설정 실전 가이드: 한 단계씩 따라 해봐요!

    이제 개념을 알았으니 직접 Proxmox VE에 네트워크 설정을 해볼 시간입니다. 저는 주로 CLI(Command Line Interface)를 선호하지만, Proxmox 웹 UI(User Interface)도 함께 보여드리면서 설명해 드릴게요. 여러분의 환경에 맞춰 선택하시면 됩니다.

    1단계: 네트워크 인터페이스 확인

    가장 먼저 현재 Proxmox 서버에 어떤 물리 네트워크 인터페이스가 있는지 확인해야 합니다. SSH로 Proxmox 서버에 접속하여 다음 명령어를 입력해 보세요.

    ip a

    보통 eno1, enpXsY, eth0 등과 같은 이름으로 표시될 겁니다. 제 홈랩 서버에는 eno1과 eno2 두 개의 기가비트 이더넷 포트가 있네요. 여러분의 서버에 맞는 인터페이스 이름을 확인해 두세요.

    2단계: 브릿지(Bridge) 설정하기

    기본적으로 Proxmox는 vmbr0이라는 브릿지를 하나 가지고 있습니다. 여기에 추가로 브릿지를 생성하거나, 기존 브릿지에 물리 NIC를 연결해볼게요.

    웹 UI를 이용한 설정

    1. Proxmox 웹 UI에 접속합니다. (https://[Proxmox_IP]:8006)
    2. 왼쪽 메뉴에서 Datacenter -> [노드 이름] -> System -> Network로 이동합니다.
    3. ‘Create’ -> ‘Linux Bridge’를 선택합니다.

    4. 설정 창에서 다음을 입력합니다:

      • Name: vmbr1 (새로운 브릿지 이름. vmbr0은 기본이니 vmbr1부터 시작하는 게 좋습니다.)
      • IPv4/CIDR: 비워둠 (브릿지에 직접 IP를 할당하지 않고, 가상 머신에서 IP를 받도록 할 경우) 또는 192.168.100.1/24 (브릿지에 IP를 할당하여 호스트에서 직접 해당 네트워크에 접근할 경우)
      • Bridge ports: eno2 (브릿지에 연결할 물리 네트워크 인터페이스 이름. 여러 개라면 공백으로 구분)
      • VLAN aware: ✅ 체크 (VLAN 기능을 사용할 예정이라면 반드시 체크해야 합니다!)
    5. ‘Create’ 버튼을 클릭하고, 상단의 ‘Apply Configuration’을 클릭하여 변경 사항을 적용합니다.

    CLI를 이용한 설정

    /etc/network/interfaces 파일을 직접 편집하여 설정할 수 있습니다. 저는 이 방법이 더 익숙하더라고요.

    sudo nano /etc/network/interfaces

    파일 내용은 대략 다음과 같을 겁니다. 기존 vmbr0 설정 아래에 vmbr1을 추가해볼게요.

    auto lo
iface lo inet loopback

iface eno1 inet manual
# Proxmox 관리용 브릿지 (기본)
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
    bridge-vlan-aware yes # VLAN 사용 시 필수!
    #bridge-vids 20-30 # 특정 VLAN ID 범위 허용 (옵션)

iface eno2 inet manual
# 추가적인 브릿지 (데이터용 또는 VLAN 분리용)
auto vmbr1
iface vmbr1 inet manual # vmbr1 자체에는 IP를 할당하지 않고, VM이 직접 IP를 가져가도록
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes # VLAN 사용 시 필수!
    #bridge-vids 100-200 # 특정 VLAN ID 범위 허용 (옵션)

    변경 후에는 네트워크 서비스를 재시작해야 하지만, Proxmox는 시스템 재부팅을 권장합니다. 특히 중요한 서버라면 Proxmox 웹 UI에서 ‘Apply Configuration’ 버튼을 누르거나, reboot 명령어를 사용하는 것이 가장 안전합니다.

    Proxmox 웹 UI에서 브릿지, VLAN, 본딩 설정을 마치고 ‘Apply Configuration’을 누르기 전의 화면입니다. 설정된 내용들을 한눈에 확인할 수 있습니다.

    3단계: VLAN(Virtual Local Area Network) 설정하기

    이제 vmbr1에 VLAN-aware 옵션을 활성화했으니, 이 브릿지를 사용하는 가상 머신에 VLAN ID를 할당해볼게요.

    가상 머신에 VLAN ID 할당 (웹 UI)

    1. 네트워크 설정을 적용할 가상 머신(VM) 또는 컨테이너(LXC)를 선택합니다.
    2. ‘Hardware’ 탭으로 이동합니다.
    3. 네트워크 장치(예: Network Device (net0))를 더블클릭합니다.

    4. 설정 창에서 다음을 확인/입력합니다:

      • Bridge: vmbr1 (앞서 생성한 VLAN-aware 브릿지)
      • VLAN Tag: 100 (할당하고 싶은 VLAN ID)
    5. ‘OK’를 클릭하고 VM을 재시작합니다.

    이렇게 설정하면 해당 VM은 vmbr1 브릿지를 통해 물리 NIC eno2로 나가되, 트래픽에 VLAN ID 100이 태깅되어 나갑니다. 물론, 이 VLAN 100을 인식하고 라우팅해줄 상위 네트워크 스위치도 그에 맞게 설정되어 있어야겠죠!

    4단계: 본딩(Bonding) 설정으로 안정성 확보하기

    여러 개의 물리 NIC를 묶어 본딩을 구성해볼게요. 저는 eno1과 eno2를 묶어 bond0을 만들고, 이 bond0을 vmbr0에 연결하여 Proxmox 관리 네트워크의 안정성을 높여보겠습니다.

    CLI를 이용한 본딩 설정

    sudo nano /etc/network/interfaces

    기존 eno1, eno2, vmbr0 설정을 수정하고 bond0을 추가합니다.

    auto lo
iface lo inet loopback

# 물리 NIC들은 manual로 설정하고 bond0에 포함시킵니다.
iface eno1 inet manual
iface eno2 inet manual

# bond0 인터페이스 설정
auto bond0
iface bond0 inet manual
    bond-slaves eno1 eno2
    bond-miimon 100
    bond-mode active-backup # 가장 일반적이고 안정적인 모드 (Failover)
    # bond-mode 802.3ad # LACP (스위치에서 Link Aggregation 설정 필수)
    # bond-xmit-hash-policy layer2+3 # LACP 사용 시 권장
    
# vmbr0 브릿지를 bond0에 연결합니다.
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports bond0 # 물리 NIC 대신 bond0을 연결
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes

    여기서 bond-mode가 중요한데요. 저는 주로 active-backup 모드를 사용합니다. 하나의 NIC가 Active로 작동하고, 다른 NIC는 Passive로 대기하다가 Active NIC에 문제가 생기면 자동으로 Passive NIC가 Active로 전환되는 방식이죠. 스위치 설정 변경 없이 Proxmox 서버 단독으로 구성할 수 있어 홈랩 환경에서 매우 편리합니다.

    만약 더 높은 성능을 원하고 스위치에서 LACP(Link Aggregation Control Protocol)를 지원한다면, 802.3ad 모드를 사용하고 스위치에서도 해당 포트들을 LACP 그룹으로 묶어줘야 합니다. 이 경우 bond-xmit-hash-policy 설정도 중요하구요. 이 부분에서 스위치 설정과 Proxmox 본딩 모드가 일치하지 않아 통신이 안 되는 삽질을 꽤 많이 했었습니다. ⚠️

    설정 변경 후에는 마찬가지로 Proxmox 웹 UI에서 ‘Apply Configuration’을 누르거나, 서버를 재부팅하여 변경 사항을 적용합니다.

    ⚠️ 삽질 대잔치! Proxmox 네트워크 설정 시 제가 겪었던 문제들

    네트워크 설정은 한 글자만 틀려도 통신이 안 되는 경우가 많아서 정말 골치 아프죠. 저도 수많은 삽질을 통해 깨달은 것들이 많습니다. 여러분은 저 같은 실수를 겪지 않으시길 바라며, 몇 가지 주의사항과 트러블슈팅 팁을 공유합니다.

    1. 잘못된 IP 설정으로 관리 인터페이스 접근 불가

    Proxmox 웹 UI에 접속하는 IP 주소(보통 vmbr0에 할당된 IP)를 잘못 설정하거나, 네트워크 서비스를 재시작했는데 IP가 적용이 안 되는 경우가 있습니다. 이럴 땐 정말 등골이 오싹해지죠. 😱

    • 해결책: 물리 서버에 직접 모니터와 키보드를 연결하여 콘솔에 접속합니다. ip a 명령어로 현재 IP 주소를 확인하고, /etc/network/interfaces 파일을 다시 확인하여 수정합니다. 변경 후에는 systemctl restart networking 명령어를 시도하거나, 안전하게 reboot 합니다.

    2. VLAN 태그 누락 또는 오설정

    분명 VLAN ID를 넣었는데 가상 머신에서 통신이 안 된다면 다음을 확인해 보세요.

    • Proxmox 브릿지에 bridge-vlan-aware yes 설정이 되어 있는지? 이 옵션이 없으면 VLAN 태그를 무시합니다.
    • 가상 머신 네트워크 설정에 VLAN Tag가 정확히 입력되었는지?
    • 물리 스위치 포트 설정: Proxmox 서버가 연결된 스위치 포트가 트렁크(Trunk) 모드로 설정되어 있고, 필요한 VLAN ID들이 모두 허용(Permit)되어 있는지 확인해야 합니다. 제가 초보 때 가장 많이 놓쳤던 부분입니다. 스위치 설정과 Proxmox 설정이 일치해야만 VLAN이 정상 작동합니다.

    3. 본딩 모드 선택의 중요성

    본딩 모드(bond-mode)를 잘못 선택하면 성능 저하는 물론, 아예 통신이 안 될 수도 있습니다.

    • active-backup: 가장 안전한 모드. 스위치 설정이 필요 없습니다. 단순 이중화 목적이라면 이 모드를 추천합니다.
    • 802.3ad (LACP): 성능 향상과 이중화를 동시에 얻을 수 있지만, 반드시 스위치에서도 해당 포트들을 LACP 그룹으로 묶어줘야 합니다. 스위치 설정이 없다면 통신이 안 되거나 불안정해질 수 있습니다. 스위치 매뉴얼을 꼼꼼히 확인하세요.

    4. 스위치 설정과의 연동

    가장 중요하면서도 간과하기 쉬운 부분입니다. Proxmox 서버의 네트워크 설정은 단독으로 작동하는 것이 아니라, 연결된 물리 스위치와 유기적으로 연동되어야 합니다. 특히 VLAN이나 LACP 본딩을 사용할 때는 스위치의 포트 설정(Access/Trunk 모드, 허용 VLAN, LACP 그룹)이 Proxmox 설정과 정확히 일치하는지 반드시 확인해야 합니다. 저는 이 부분 때문에 밤을 새워가며 삽질했던 경험이 정말 많습니다. 😅

    설정 완료! 제대로 작동하는지 확인해볼까요?

    모든 설정을 마치셨다면, 이제 정상적으로 작동하는지 확인해볼 차례입니다. “드디어 됐다!” 하는 희열을 느낄 수 있는 순간이죠. 🎉

    1. Proxmox 웹 UI 확인: Datacenter -> [노드 이름] -> System -> Network 탭에서 설정한 브릿지, 본딩 인터페이스가 정상적으로 올라와 있는지 확인합니다. 상태가 ‘active’여야 합니다.
    2. 가상 머신 통신 테스트: VLAN을 할당한 가상 머신에서 해당 VLAN의 게이트웨이나 다른 서버로 ping 테스트를 해봅니다.
    3. 본딩 Failover 테스트 (Active-Backup 모드): 본딩된 물리 NIC 중 하나를 케이블에서 뽑아봅니다. 잠시 후에도 Proxmox 서버가 네트워크에 연결되어 있고, 가상 머신 통신도 정상이라면 본딩이 잘 작동하는 것입니다. 물론 테스트 후에는 다시 케이블을 연결해야겠죠! 💡

    Proxmox 가상 머신에 VLAN을 설정하고, 해당 VLAN 네트워크 내에서 성공적으로 핑 테스트를 수행한 결과 화면입니다. 네트워크가 정상적으로 작동함을 보여줍니다.

    13년차 서버실의 마무리: Proxmox 네트워크 설정, 이제 두렵지 않아요!

    오늘은 Proxmox VE의 핵심인 브릿지, VLAN, 본딩에 대해 깊이 있게 다뤄봤습니다. 개념부터 실전 설정, 그리고 제가 직접 겪었던 삽질 경험과 해결책까지 솔직하게 공유해 드렸는데요.

    처음에는 복잡하게 느껴질 수 있지만, 몇 번 직접 해보고 트러블슈팅을 겪다 보면 금방 익숙해지실 겁니다. 특히 네트워크는 이론만으로는 부족하고, 직접 만져보고 겪어봐야 진짜 내 것이 되더라고요.

    Proxmox VE의 네트워크 설정은 여러분의 가상화 환경을 더욱 유연하고 안정적으로 만들어줄 것입니다. 이 글이 Proxmox VE를 사용하시는 모든 분들께 좋은 멘토가 되었으면 좋겠습니다. 다음번에는 Proxmox VE의 스토리지 설정이나 고가용성 클러스터 구축에 대한 경험담도 풀어볼까 합니다. 기대해 주세요!

    Proxmox 네트워크의 브릿지, VLAN, 본딩 개념과 주요 특징, 설정 팁을 요약하여 시각적으로 보여주는 인포그래픽입니다.

  • [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와 함께 쓰면 정말 강력한 홈랩 환경이 만들어집니다. 기대해 주세요!

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

  • [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 스토리지 구축에 대한 이야기를 들고 오겠습니다. 그때까지 모두 안정적인 서버실 되시길! 감사합니다. 👋

  • [HomeLabs] 홈서버 OS 비교: Proxmox VE, TrueNAS SCALE, Unraid, OMV 완벽 분석

    [HomeLabs] 홈서버 OS 비교: Proxmox VE, TrueNAS SCALE, Unraid, OMV 완벽 분석

    목차

    홈서버 OS 비교: Proxmox VE, TrueNAS SCALE, Unraid, OMV 완벽 분석

    💡 홈서버 OS, 이젠 선택이 아니라 필수! 무슨 기준으로 고르면 될까요?

    안녕하세요! 13년차 인프라 엔지니어, ’13년차의 서버실’ 블로그 주인장입니다. 요즘 홈서버에 대한 관심이 정말 뜨겁더라고요. 저도 퇴근하고 집에 오면 홈랩에서 이런저런 실험하는 재미로 살고 있거든요. 그런데 막상 홈서버를 구축하려고 하면 가장 먼저 부딪히는 벽이 바로 홈서버 OS(Operating System) 선택이 아닐까 싶어요. 저도 처음엔 Proxmox VE, TrueNAS, Unraid, OMV… 이름만 들어도 머리가 지끈거리고, ‘대체 뭘 써야 나한테 맞을까?’ 고민이 정말 많았거든요.

    혹시 이런 경험 있으신가요? ⚠️ ‘이거 좋다고 해서 깔아봤는데, 내 목적이랑은 안 맞네…’ 하고 다시 밀어버리는 삽질 말이죠. 저도 셀 수 없이 많이 해봤습니다. ㅎㅎ 그래서 오늘은 저처럼 시행착오를 겪고 있는 분들을 위해, 제가 직접 써보고 느꼈던 경험을 바탕으로 대표적인 홈서버 OS 4가지, Proxmox VE, TrueNAS SCALE, Unraid, OpenMediaVault (OMV)를 완벽하게 비교 분석해 드리려고 합니다. 이 글을 보시면 여러분의 홈서버에 딱 맞는 OS를 찾는 데 큰 도움이 되실 거예요!

    홈서버 OS 선택의 복잡성을 보여주는 다양한 구성 요소 연결 다이어그램

    다양한 홈서버 OS 중에서 나에게 맞는 것을 고르는 과정은 마치 미로를 탐험하는 것과 같습니다.

    개념 정리: 홈서버 OS, 왜 이렇게 다양할까요?

    본격적인 비교에 앞서, 각 OS가 추구하는 핵심 개념을 잠깐 짚고 넘어갈게요. 이걸 알아야 나에게 맞는 OS를 고르는 기준이 명확해지거든요.

    • 하이퍼바이저(Hypervisor): 한 대의 물리 서버 위에 여러 개의 가상 머신(VM, Virtual Machine)을 올릴 수 있게 해주는 소프트웨어예요. 서버 하드웨어를 효율적으로 나눠 쓰는 데 특화되어 있죠. Proxmox VE가 대표적입니다.
    • NAS OS: 네트워크 결합 스토리지(NAS, Network Attached Storage) 기능을 제공하는 OS예요. 여러 저장 장치를 묶어 파일 공유, 미디어 서버 등을 구축하는 데 최적화되어 있죠. TrueNAS SCALE, Unraid, OpenMediaVault가 이 범주에 속합니다.
    • 컨테이너(Container): VM보다 훨씬 가볍게 애플리케이션을 격리해서 실행하는 기술입니다. Docker(도커)나 Kubernetes(쿠버네티스)가 여기에 해당하죠. 요즘 홈랩에서는 VM과 함께 컨테이너 활용이 대세가 되고 있어요.

    이런 개념들을 머리에 넣고 각 OS의 특징을 살펴보면 훨씬 이해하기 쉬울 거예요. 그럼 이제 하나씩 자세히 들여다볼까요?

    Proxmox VE (프로목스 VE): 홈랩 가상화의 제왕

    ✅ 특징 및 저의 경험

    Proxmox VE는 KVM(Kernel-based Virtual Machine) 기반의 오픈소스 하이퍼바이저예요. 쉽게 말해, 윈도우나 리눅스 같은 다양한 OS를 가상 머신으로 여러 개 띄워서 쓸 수 있게 해주는 OS라고 보시면 돼요. 여기에 LXC(Linux Containers)라는 컨테이너 기능까지 지원해서, VM과 컨테이너를 한 곳에서 통합 관리할 수 있다는 게 정말 큰 장점이거든요.

    제가 처음 Proxmox를 접했을 때 ‘와, 이걸로 내 홈서버 하나에 윈도우 서버도 돌리고, NAS도 VM으로 올리고, 우분투 서버도 만들 수 있겠네?’ 하고 감탄했던 기억이 나네요. 웹 기반의 관리 GUI(Graphical User Interface)가 정말 잘 되어 있어서, 복잡한 설정도 마우스 클릭 몇 번으로 해결할 수 있더라고요. 엔터프라이즈급 기능들을 홈랩에서 무료로 써볼 수 있다는 점이 매력적이었어요.

    👍 장점

    • 강력한 가상화 기능: KVM과 LXC를 이용해 다양한 OS를 효율적으로 운영할 수 있습니다.
    • 웹 기반 GUI: 직관적인 웹 인터페이스로 VM, 컨테이너, 네트워크, 스토리지를 쉽게 관리할 수 있어요.
    • 오픈소스 및 활발한 커뮤니티: 무료로 사용할 수 있고, 문제가 생겼을 때 정보를 찾기 쉽습니다.
    • 리소스 효율성: 하드웨어 리소스를 여러 VM/컨테이너에 유연하게 배분하여 활용도를 극대화할 수 있습니다.

    👎 단점 및 ⚠️ 주의사항

    • 스토리지 관리 기능: 자체적인 NAS 기능은 없어요. TrueNAS나 OMV를 VM으로 올려서 사용하는 경우가 많습니다.
    • ZFS 구성의 복잡성: Proxmox에서도 ZFS를 지원하지만, 초기 구성이나 관리가 초보자에게는 다소 어렵게 느껴질 수 있어요.
    • 초기 학습 곡선: 가상화 개념이 익숙하지 않다면 처음엔 좀 헤맬 수 있습니다.
    Proxmox VE 웹 인터페이스 대시보드 스크린샷

    Proxmox VE의 직관적인 웹 대시보드. 여러 가상 머신과 컨테이너의 상태를 한눈에 확인할 수 있습니다.

    TrueNAS SCALE (트루NAS 스케일): 스토리지와 컨테이너의 완벽한 조화

    ✅ 특징 및 저의 경험

    TrueNAS SCALE은 강력한 ZFS(Zettabyte File System) 기반의 NAS OS예요. 데이터의 무결성과 안정성을 최우선으로 생각하는 분들에게는 거의 표준처럼 여겨지죠. 기존의 FreeBSD 기반 TrueNAS CORE와 달리, Debian Linux를 기반으로 만들어져 KVM 가상화와 Docker/Kubernetes(Apps)를 기본으로 지원한다는 점이 핵심입니다.

    제가 TrueNAS SCALE을 써보면서 가장 놀랐던 건 ZFS의 강력함이었어요. 스냅샷(Snapshot), 데이터 중복 제거(Deduplication), 자가 복구(Self-healing) 같은 기능들은 정말 ‘내 데이터는 안전하겠구나!’ 하는 안도감을 주더라고요. 그리고 Docker 컨테이너를 ‘Apps’라는 이름으로 웹 GUI에서 쉽게 설치하고 관리할 수 있어서, Plex Media Server, Home Assistant 같은 다양한 서비스들을 정말 편하게 올릴 수 있었습니다. NAS 기능과 앱 활용을 동시에 잡고 싶은 분들에게 정말 좋은 선택지라고 생각했어요.

    👍 장점

    • 최강의 데이터 보호: ZFS를 통해 데이터 무결성과 안정성을 보장해요. 스냅샷 기능은 랜섬웨어 방어에도 효과적하죠.
    • 컨테이너 앱 통합: Docker/Kubernetes 기반의 ‘Apps’ 기능을 통해 다양한 서비스를 쉽게 배포하고 관리할 수 있습니다.
    • 쉬운 웹 GUI: 직관적인 웹 인터페이스로 스토리지, 네트워크, 앱 등을 편리하게 관리할 수 있어요.
    • KVM 가상화 지원: NAS 기능과 함께 가상 머신도 운영할 수 있어 활용도가 높습니다.

    👎 단점 및 ⚠️ 주의사항

    • 높은 메모리 요구량: ZFS는 RAM을 많이 사용해요. 최소 16GB, 안정적인 운영을 위해서는 32GB 이상을 권장합니다.
    • 하드웨어 제약: ZFS 특성상 드라이브 추가/교체가 Unraid처럼 유연하지 않습니다. 처음 구성 시 신중해야 해요.
    • 업데이트 시 주의: 아직 비교적 신생 OS라 업데이트 시 버그가 발생할 가능성이 있어요. 항상 백업 후 진행하는 것이 좋습니다.

    Unraid (언레이드): 유연한 스토리지와 도커의 천국

    ✅ 특징 및 저의 경험

    Unraid는 다른 NAS OS와는 조금 다른 독특한 스토리지 방식을 채택하고 있어요. 패리티 드라이브(Parity Drive)를 사용해서 데이터 보호를 하면서도, 드라이브 용량과 종류에 상관없이 유연하게 스토리지를 확장할 수 있다는 점이 가장 큰 매력이거든요. 여기에 Docker(도커)와 KVM 기반의 VM 기능을 아주 강력하게 지원해서, 홈랩 사용자들 사이에서 인기가 많죠.

    제가 Unraid를 써보면서 가장 감탄했던 부분은 바로 ‘유연성’이었어요. 굴러다니는 하드디스크가 있으면 그냥 끼워서 확장하면 끝이거든요. 굳이 같은 용량의 드라이브를 여러 개 맞춰 살 필요가 없다는 게 정말 편했어요. 게다가 Community Applications라는 플러그인을 통해 Docker 컨테이너를 설치하는 과정은 정말 ‘신세계’였습니다. 클릭 몇 번으로 원하는 앱을 바로 설치할 수 있으니, 삽질할 시간이 확 줄어들더라고요. 유료 OS이긴 하지만, 그만한 가치를 한다고 느꼈어요.

    👍 장점

    • 뛰어난 스토리지 유연성: 다양한 용량/종류의 드라이브를 섞어 쓸 수 있고, 확장이 매우 쉬워요.
    • 최강의 Docker 지원: Community Applications를 통해 수많은 Docker 컨테이너를 쉽고 빠르게 설치, 관리할 수 있습니다.
    • 쉬운 VM 관리: KVM 기반으로 가상 머신도 손쉽게 운영할 수 있어요.
    • 낮은 전력 소비: 사용하지 않는 드라이브는 스핀 다운(Spin Down) 시켜 전력 소모를 줄일 수 있습니다.

    👎 단점 및 ⚠️ 주의사항

    • 유료 라이선스: 무료가 아니에요. 하지만 한 번 구매하면 영구적으로 사용할 수 있습니다.
    • ZFS 같은 데이터 무결성 보장은 아님: 패리티 드라이브 기반이라 ZFS처럼 완벽한 데이터 무결성을 보장하지는 않아요.
    • 쓰기 성능: 단일 드라이브에 쓰기 때문에 쓰기 성능이 드라이브 하나 속도에 제약됩니다. 읽기 성능은 병렬로 이루어져 빨라요.
    • USB 부팅 필수: OS가 USB 메모리에 설치되어 부팅 시 필요합니다.

    OpenMediaVault (OMV, 오픈미디어볼트): 가볍고 확장성 좋은 무료 NAS

    ✅ 특징 및 저의 경험

    OpenMediaVault (OMV)는 Debian Linux를 기반으로 하는 오픈소스 NAS OS예요. 가볍고 안정적이며, 다양한 플러그인을 통해 기능을 확장할 수 있다는 점이 큰 장점이거든요. 저사양 시스템에서도 잘 작동하기 때문에, 남는 PC나 라즈베리 파이 같은 SBC(Single Board Computer)로 NAS를 구축하려는 분들에게 인기가 많아요.

    제가 OMV를 써봤을 때 가장 인상 깊었던 건 ‘가벼움’이었어요. 오래된 노트북에 설치해봤는데도 전혀 버벅거림 없이 NAS 기능을 잘 수행하더라고요. Docker 플러그인을 설치하면 컨테이너도 쉽게 운영할 수 있어서, 기본적인 NAS 기능에다 Plex 같은 미디어 서버나 파일 동기화 서비스 등을 추가하기에 정말 좋았습니다. 복잡한 가상화나 ZFS 같은 고급 기능보다는, 안정적인 파일 저장과 공유, 그리고 몇 가지 앱만 돌리고 싶은 분들에게 강력 추천해요!

    👍 장점

    • 무료 및 오픈소스: 비용 부담 없이 강력한 NAS 기능을 사용할 수 있어요.
    • 가볍고 안정적: 저사양 하드웨어에서도 쾌적하게 작동하며, Debian 기반이라 안정성이 뛰어나요.
    • 다양한 플러그인: Docker, Rsync, S.M.A.R.T. 등 다양한 플러그인을 통해 기능을 확장할 수 있습니다.
    • 쉬운 설치 및 관리: 웹 GUI를 통해 기본적인 설정과 관리가 용이해요.

    👎 단점 및 ⚠️ 주의사항

    • 제한적인 고급 기능: ZFS 같은 강력한 데이터 보호 기능이나, Proxmox/TrueNAS SCALE/Unraid처럼 통합된 가상화 기능은 없어요 (플러그인으로 Docker만 지원).
    • 상대적으로 부족한 GUI 기능: 다른 OS에 비해 GUI에서 제공하는 기능이 다소 제한적일 수 있습니다.
    • 커뮤니티 지원: TrueNAS나 Proxmox만큼 거대하지는 않지만, 충분히 활성화되어 있어요.

    4가지 홈서버 OS, 한눈에 비교하기!

    이제까지 살펴본 4가지 홈서버 OS의 주요 특징들을 표로 정리해봤어요. 어떤 OS가 여러분의 상황에 가장 적합한지 판단하는 데 도움이 되셨으면 좋겠네요.

    구분 Proxmox VE TrueNAS SCALE Unraid OpenMediaVault (OMV)
    주요 기능 가상화(VM), 컨테이너(LXC) NAS(ZFS), 컨테이너(Docker/K8s), 가상화(KVM) NAS(유연한 스토리지), 컨테이너(Docker), 가상화(KVM) NAS(Debian 기반), 컨테이너(Docker 플러그인)
    기반 OS Debian Linux Debian Linux Slackware Linux (커스텀) Debian Linux
    스토리지 특징 다양한 스토리지 지원 (ZFS, LVM, Ceph 등) ZFS (강력한 데이터 보호) 패리티 드라이브 (유연한 확장) EXT4, XFS 등 (기본 리눅스 파일시스템)
    가상화 지원 KVM (매우 강력) KVM (통합 지원) KVM (통합 지원) 제한적 (Docker만 공식 지원)
    컨테이너 지원 LXC (매우 강력) Docker/Kubernetes (Apps) Docker (Community Apps) Docker (플러그인)
    가격 무료 (유료 서브스크립션 옵션) 무료 유료 (영구 라이선스) 무료
    권장 사용자 복수의 VM/컨테이너 운영, 하드웨어 활용 극대화 데이터 안전성 최우선, NAS와 앱/VM 통합 스토리지 유연성, Docker 앱 위주, 다양한 하드웨어 가볍고 안정적인 NAS, 저사양 시스템, 리눅스 친화적
    난이도 중상 중 중하 하

    홈서버 OS 4가지의 주요 특징을 한눈에 비교해볼 수 있는 요약표입니다.

    Proxmox VE, TrueNAS SCALE, Unraid, OMV 4가지 홈서버 OS 주요 특징 비교 인포그래픽

    Proxmox VE, TrueNAS SCALE, Unraid, OMV의 핵심 기능을 시각적으로 비교한 인포그래픽. 각 OS의 강점과 약점을 한눈에 파악할 수 있어요.

    그래서, 어떤 OS를 고르면 될까요? (저의 삽질 경험 기반 추천)

    자, 이제 가장 중요한 질문이죠. ‘그래서 뭘 써야 하냐고?!’ 제 경험을 바탕으로 간단하게 정리해 드릴게요.

    • 나는 정말 다양한 OS를 VM으로 돌리고 싶고, 하드웨어 리소스를 끝까지 뽑아내고 싶다! ➡️ Proxmox VE가 정답입니다. 여기에 NAS는 TrueNAS SCALE이나 OMV를 VM으로 올려서 쓰는 구성이 일반적이에요. 저도 처음엔 Proxmox로 시작해서 리눅스, 윈도우 서버 다 돌려봤었죠.
    • 데이터 안전성이 최우선이고, NAS 기능과 함께 컨테이너 앱도 안정적으로 쓰고 싶다! ➡️ TrueNAS SCALE을 추천해요. ZFS의 강력함은 정말 경험해봐야 알 수 있거든요. 다만, 메모리 투자를 좀 하셔야 합니다.
    • 집에 굴러다니는 하드디스크가 많고, 유연하게 스토리지를 확장하면서 Docker 위주로 홈랩을 꾸미고 싶다! ➡️ Unraid가 최고의 선택일 수 있어요. 유료라는 점만 감수한다면 정말 ‘삶의 질’이 달라지는 경험을 하실 거예요. 저도 한동안 Unraid의 매력에 푹 빠져 있었거든요.
    • 저사양 PC나 라즈베리 파이로 가볍게 NAS를 구축하고 싶고, 파일 공유와 몇 가지 앱만 돌리면 충분하다! ➡️ OpenMediaVault (OMV)가 가장 합리적인 선택이에요. 무료이면서도 필요한 기능은 다 가지고 있거든요.

    결국 ‘자신의 주 목적’이 무엇인지 파악하는 것이 가장 중요해요. 저도 처음엔 이게 뭔가 싶어서 Proxmox로 시작했다가 NAS 기능 때문에 TrueNAS도 써보고, Unraid의 유연성에 혹하기도 했거든요. 여러 OS를 설치하고 지우는 삽질 끝에 깨달은 건, ‘완벽한 OS는 없고, 내게 가장 잘 맞는 OS가 최고다’라는 사실이었습니다. 여러분도 이 글을 참고하셔서 자신에게 딱 맞는 홈서버 OS를 찾으시길 바랄게요! 💡

    홈서버 OS 선택 가이드를 위한 결정 트리 플로우차트

    당신의 홈서버 목적에 따라 최적의 OS를 선택할 수 있도록 돕는 결정 트리 다이어그램입니다.

    🎉 마무리: 나만의 홈랩, 즐거운 삽질의 시작!

    오늘은 Proxmox VE, TrueNAS SCALE, Unraid, OpenMediaVault까지, 대표적인 홈서버 OS 4가지를 비교 분석해봤어요. 각 OS마다 장단점이 명확하죠? 어떤 OS를 고르시든, 홈랩 구축은 정말 즐거운 경험이 될 거라고 확신합니다. 때로는 예상치 못한 문제에 부딪혀 ‘삽질’을 할 수도 있지만, 그 과정에서 배우는 것이 정말 많거든요.

    홈랩은 말 그대로 ‘나만의 실험실’이잖아요? 여러분의 아이디어와 상상력을 마음껏 펼쳐보세요. 궁금한 점이 있다면 언제든지 댓글로 남겨주시고요! 다음번에는 제가 Proxmox VE에 TrueNAS SCALE을 VM으로 설치해서 쓰는 방법에 대해 자세히 다뤄볼까 합니다. 기대해주세요! 😄

  • [Proxmox] Proxmox VE 설치 후 필수 초기 설정: 8단계 완벽 가이드

    목차

    Proxmox VE 설치, 그 다음이 진짜 시작입니다

    Proxmox VE를 처음 설치하고 나서 웹 UI에 접속했을 때 느낌, 기억하시나요? 저는 처음에 “오, 뭔가 있어 보이는데?” 하면서 신나게 로그인했다가… 뭘 해야 할지 몰라서 한참 멍하니 화면만 바라봤었거든요. ㅎㅎ

    사실 Proxmox VE 설치 자체는 그렇게 어렵지 않아요. ISO 받아서 부팅하고, 몇 가지 옵션 선택하면 끝이니까요. 근데 설치 직후 초기 설정을 제대로 안 하면 나중에 진짜 고생합니다. 보안 구멍이 생기거나, 업데이트가 안 되거나, 스토리지 설정이 엉켜서 VM 하나 만들 때마다 삽질하게 되거든요.

    13년 동안 인프라 엔지니어로 일하면서, 그리고 집에서 홈랩을 운영하면서 겪은 경험을 바탕으로 Proxmox VE 설치 후 반드시 해야 할 필수 초기 설정을 정리해봤습니다. 초보자분들도 따라할 수 있도록 최대한 쉽게 설명할게요.

    ▲ Proxmox VE 설치 후 초기 설정 전체 흐름 — 순서대로 따라가면 됩니다

    Proxmox VE가 뭔지 잠깐만요 — 처음 들어보시는 분을 위해

    혹시 Proxmox VE가 처음이신 분도 계실 것 같아서 간단히 설명하고 넘어갈게요.

    Proxmox VE(Virtual Environment)는 오픈소스 기반의 하이퍼바이저(Hypervisor, 가상화 플랫폼)입니다. 쉽게 말해, 컴퓨터 한 대 위에서 여러 개의 가상 컴퓨터(VM)를 돌릴 수 있게 해주는 소프트웨어예요. VMware ESXi와 비슷한 역할을 하는데, 무료에 웹 UI가 꽤 잘 만들어져 있어서 홈랩이나 소규모 인프라에서 많이 씁니다.

    • KVM(Kernel-based Virtual Machine): 완전 가상화 VM을 돌릴 때 사용
    • LXC(Linux Containers): 컨테이너 방식으로 더 가볍게 리눅스 환경 구성
    • Ceph, ZFS: 스토리지 클러스터링 지원
    • 웹 기반 관리 UI: 브라우저로 모든 걸 관리

    자, 이제 본론으로 들어가겠습니다. Proxmox VE 설치는 됐다고 가정하고, 필수 초기 설정을 시작할게요!

    1단계: 무료 리포지토리 설정 — 업데이트 받기

    여기서 많은 분들이 처음에 당황하시는 부분이에요. Proxmox VE를 설치하면 기본적으로 엔터프라이즈 리포지토리(Enterprise Repository)로 설정이 되어 있거든요. 근데 이건 유료 구독을 해야 쓸 수 있어서, 구독 없이 업데이트 시도하면 인증 오류가 떠버립니다.

    홈랩이나 개인 서버에서 쓰신다면 무료 버전인 no-subscription 리포지토리로 바꿔주셔야 해요. 프로덕션 환경에서는 유료 구독을 권장하지만, 개인 용도라면 충분합니다.

    SSH로 Proxmox 서버에 접속하거나, 웹 UI의 Shell을 열어서 아래 명령어를 실행하세요.

    엔터프라이즈 리포지토리 비활성화

    # 엔터프라이즈 리포지토리 파일 비활성화
echo "# disabled enterprise repo" > /etc/apt/sources.list.d/pve-enterprise.list

# Ceph 엔터프라이즈 리포지토리도 비활성화 (있는 경우)
echo "# disabled" > /etc/apt/sources.list.d/ceph.list

    무료 리포지토리 추가

    # Proxmox VE no-subscription 리포지토리 추가
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list

# 패키지 목록 업데이트 및 시스템 업그레이드
apt update && apt dist-upgrade -y

    💡 Tip: Proxmox VE 8.x 버전은 Debian 12(Bookworm) 기반입니다. 버전에 따라 코드명이 다르니, 설치된 버전을 먼저 확인하세요. pveversion 명령어로 확인할 수 있어요.

    업데이트가 다 끝나면 재부팅 한 번 해주는 게 좋아요. 커널 업데이트가 포함될 수 있거든요.

    reboot

    2단계: 로그인 화면 구독 알림 제거 (선택사항)

    이건 기능에는 전혀 영향이 없는데, 웹 UI 로그인할 때마다 “유효한 구독이 없습니다”라는 팝업이 뜨거든요. 매번 확인 누르는 게 은근히 귀찮아서 저도 처음 설정할 때 바로 없애버렸습니다.

    # Proxmox VE 8.x 기준
sed -i.bak "s/data.status.toLowerCase() !== 'active'/false/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js

# 웹 서비스 재시작
systemctl restart pveproxy

    ⚠️ 주의: 이 수정은 Proxmox 업데이트 후에 원복될 수 있어요. 업데이트 후에 다시 팝업이 뜨면 같은 명령어를 다시 실행하면 됩니다.

    3단계: 네트워크 브릿지 확인 및 설정

    가상화 서버 구축에서 네트워크 설정은 정말 중요한 부분이에요. 처음에 이 부분에서 삽질을 꽤 많이 했습니다. VM들이 외부 네트워크와 통신하려면 리눅스 브릿지(Linux Bridge)가 제대로 설정되어 있어야 하거든요.

    Proxmox는 설치 시 기본적으로 vmbr0라는 브릿지를 만들어줘요. 웹 UI에서 확인하는 방법은 이렇습니다:

    1. 웹 UI 좌측 트리에서 서버 노드 선택
    2. System(시스템) → Network(네트워크) 클릭
    3. vmbr0 브릿지와 IP 설정 확인

    설정 파일을 직접 확인하고 싶다면:

    cat /etc/network/interfaces

    정상적인 설정이라면 이런 형태가 나와야 해요:

    auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.100/24
        gateway 192.168.1.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

    여기서 bridge-ports에 실제 물리 NIC 이름이 잘 들어가 있는지 확인하세요. 서버마다 NIC 이름이 다를 수 있어요 (eth0, eno1, enp3s0 등).

    ▲ Proxmox VE 웹 UI의 네트워크 설정 화면 — vmbr0 브릿지 구성을 확인하세요

    4단계: 스토리지 설정 최적화

    기본 설치 후 스토리지 설정이 좀 아쉬운 부분이 있어요. 특히 local-lvm 파티션 관련해서 처음에 헷갈리는 분들이 많더라고요.

    기본 스토리지 구성 이해하기

    스토리지 이름 타입 용도 저장 위치
    local Directory ISO 이미지, 백업, CT 템플릿 /var/lib/vz
    local-lvm LVM-Thin VM 디스크, CT 볼륨 LVM Thin Pool

    근데 여기서 local 스토리지에 VM 디스크 이미지를 저장하고 싶다면 추가 설정이 필요해요. 기본적으로 local은 VM 디스크(qcow2, raw)를 저장할 수 없도록 제한되어 있거든요.

    웹 UI에서 변경하는 방법:

    1. Datacenter(데이터센터) → Storage(스토리지) 클릭
    2. local 선택 후 Edit(편집)
    3. Content(콘텐츠)에서 Disk image(디스크 이미지) 항목 체크
    4. OK 클릭

    또는 CLI로 직접:

    # local 스토리지에 VM 디스크 이미지 저장 허용
pvesm set local --content iso,vztmpl,backup,images,rootdir

    ZFS를 사용하는 경우 — 추가 최적화

    설치 시 ZFS를 선택하셨다면, ARC(Adaptive Replacement Cache, ZFS 캐시) 메모리 설정을 해주는 게 좋아요. 기본값으로 두면 ZFS가 RAM을 꽤 많이 잡아먹거든요.

    # ZFS ARC 최대 메모리 제한 (예: 4GB로 제한)
echo "options zfs zfs_arc_max=4294967296" >> /etc/modprobe.d/zfs.conf
update-initramfs -u

    5단계: 보안 강화 — 이거 꼭 해주세요 ⚠️

    이 부분이 진짜 중요한데 의외로 그냥 넘어가는 분들이 많아요. 특히 외부에서 접근 가능한 환경이라면 더더욱 신경 써야 합니다.

    SSH 보안 설정

    # SSH 설정 파일 편집
nano /etc/ssh/sshd_config

    아래 항목들을 확인하고 설정하세요:

    # root 직접 로그인 비활성화 (키 인증만 허용하거나 완전 비활성화)
PermitRootLogin prohibit-password

# 비밀번호 인증 비활성화 (SSH 키 설정 후 적용)
# PasswordAuthentication no

# SSH 포트 변경 (기본 22에서 변경 권장)
Port 2222
    # SSH 서비스 재시작
systemctl restart sshd

    ⚠️ 경고: SSH 포트를 바꾸거나 비밀번호 인증을 끄기 전에, 반드시 SSH 키 로그인이 정상 동작하는지 먼저 확인하세요. 잘못하면 서버에 접속을 못하게 될 수 있어요. 저도 한 번 이렇게 자폭한 적이 있습니다… ㅎㅎ

    Proxmox 웹 UI 포트 방화벽 설정

    Proxmox는 기본적으로 8006 포트로 웹 UI에 접근합니다. Proxmox 내장 방화벽을 활성화하고 필요한 포트만 열어두세요.

    웹 UI에서 설정하는 방법:

    1. Datacenter(데이터센터) → Firewall(방화벽) → Options(옵션)
    2. Firewall: Yes로 변경
    3. 노드 레벨 방화벽도 동일하게 활성화
    4. 필요한 포트(8006, SSH 포트, 마이그레이션 포트 등) 규칙 추가

    강력한 비밀번호 설정 확인

    # root 비밀번호 변경
passwd root

    웹 UI에서 별도 사용자를 만들어 root 직접 사용을 줄이는 것도 좋은 방법이에요. Datacenter → Permissions → Users에서 관리자 계정을 별도로 만들 수 있습니다.

    6단계: 시간 동기화 설정 확인

    이거 별거 아닌 것 같아도 나중에 로그 분석하거나 클러스터 구성할 때 시간이 맞지 않으면 진짜 골치 아파요. 꼭 확인하세요.

    # 현재 시간 동기화 상태 확인
timedatectl status

# systemd-timesyncd 서비스 상태 확인
systemctl status systemd-timesyncd

    타임존 설정이 잘못되어 있다면:

    # 타임존을 서울로 설정
timedatectl set-timezone Asia/Seoul

# 동기화 확인
timedatectl show-timesync --all

    NTP 서버를 커스텀으로 지정하고 싶다면 /etc/systemd/timesyncd.conf를 편집하세요:

    [Time]
NTP=time.bora.net 0.pool.ntp.org 1.pool.ntp.org
FallbackNTP=2.pool.ntp.org
    systemctl restart systemd-timesyncd

    7단계: 백업 정책 설정 — 미래의 나를 위해

    “백업은 나중에 해야지” 하다가 VM 날려먹은 경험… 저만 있는 건 아니겠죠? ㅎㅎ Proxmox는 기본적으로 꽤 쓸 만한 백업 기능을 내장하고 있어요. 처음부터 스케줄 잡아두는 걸 강력 추천합니다.

    백업 스케줄 설정 (웹 UI)

    1. Datacenter(데이터센터) → Backup(백업) 클릭
    2. Add(추가) 버튼 클릭
    3. 스케줄, 저장소, 대상 VM, 보존 정책 설정
    4. Create(생성) 클릭

    주요 설정 항목:

    • Storage(저장소): 백업 파일을 저장할 위치
    • Schedule(스케줄): cron 형식으로 지정 (예: 매일 새벽 2시 → 02:00)
    • Mode(모드): Snapshot(스냅샷), Suspend(일시정지), Stop(중지) 중 선택
    • Max Backups(최대 백업 수): 보존할 백업 개수 (스토리지 용량 고려)

    💡 Tip: VM이 중요하다면 Snapshot 모드를 권장해요. 서비스 중단 없이 백업이 가능하거든요. 단, 게스트 OS에 QEMU 에이전트가 설치되어 있어야 완전한 일관성이 보장됩니다.

    8단계: QEMU Guest Agent 설정

    VM을 만들 때 꼭 챙겨야 하는 설정인데, 기본 가이드에서 빠져있는 경우가 많아요. QEMU Guest Agent(게스트 에이전트)는 호스트(Proxmox)와 게스트(VM) 사이의 통신 채널을 제공해줘요.

    이게 있으면:

    • VM의 IP 주소를 Proxmox UI에서 바로 확인 가능
    • 정상적인 셧다운/재시작 명령 전달
    • 백업 시 파일시스템 동기화(freeze/thaw) 지원
    • 메모리 사용량 등 상세 정보 수집

    VM 설정에서 Guest Agent 활성화

    1. VM 선택 → Options(옵션)
    2. QEMU Guest Agent 항목 더블클릭
    3. Enabled(활성화) 체크 → OK

    게스트 OS에 에이전트 설치

    # Ubuntu/Debian 게스트에서
apt install qemu-guest-agent -y
systemctl enable qemu-guest-agent
systemctl start qemu-guest-agent
    # CentOS/RHEL/Rocky Linux 게스트에서
dnf install qemu-guest-agent -y
systemctl enable qemu-guest-agent
systemctl start qemu-guest-agent

    ▲ QEMU Guest Agent가 정상 동작하면 VM의 IP 주소와 상세 정보가 대시보드에 표시됩니다

    ⚠️ 자주 겪는 문제와 해결법

    문제 1: 웹 UI 접속이 안 돼요

    설치 직후 https://서버IP:8006으로 접속이 안 된다면, 브라우저에서 HTTP가 아닌 HTTPS로 접속하고 있는지 확인하세요. Proxmox는 기본적으로 자체 서명 인증서(Self-signed certificate)를 사용하기 때문에 브라우저에서 보안 경고가 뜨는 건 정상이에요. “고급” 클릭 후 “계속 진행”하면 됩니다.

    # pveproxy 서비스 상태 확인
systemctl status pveproxy

# 서비스 재시작
systemctl restart pveproxy

    문제 2: apt update 시 인증 오류

    “401 Unauthorized” 오류가 나온다면 엔터프라이즈 리포지토리가 아직 활성화되어 있는 거예요. 1단계로 돌아가서 리포지토리 설정을 다시 확인하세요.

    문제 3: VM 생성 시 스토리지 선택이 안 됨

    VM 디스크를 저장할 스토리지가 보이지 않는다면, 해당 스토리지의 Content(콘텐츠) 설정에 Disk image가 포함되어 있는지 확인하세요. 4단계 스토리지 설정 부분을 다시 참고해주세요.

    문제 4: 네트워크 설정 변경 후 연결이 끊김

    이건 진짜 당황스럽죠… 웹 UI에서 네트워크 설정 변경 시 Apply Configuration(설정 적용) 버튼을 누르기 전에 설정을 꼭 다시 검토하세요. 잘못된 IP나 게이트웨이를 입력하면 연결이 끊길 수 있어요. 이럴 때를 대비해 물리적 접근(KVM 콘솔, IPMI 등)이나 직접 모니터+키보드 연결 방법을 미리 확보해두는 게 좋습니다.

    설정 완료 후 확인 체크리스트 ✅

    모든 설정을 마쳤다면 아래 체크리스트로 한 번 더 확인해보세요.

    ▲ Proxmox VE 초기 설정 완료 체크리스트 — 하나씩 확인해보세요

    • ✅ no-subscription 리포지토리로 변경 완료
    • ✅ apt update && apt dist-upgrade 실행 완료
    • ✅ 네트워크 브릿지(vmbr0) 정상 동작 확인
    • ✅ 스토리지 설정 및 콘텐츠 타입 확인
    • ✅ SSH 보안 설정 완료
    • ✅ 방화벽 기본 규칙 설정
    • ✅ 시간 동기화(NTP) 정상 동작 확인
    • ✅ 백업 스케줄 설정 완료
    • ✅ 테스트 VM 생성 및 QEMU Guest Agent 동작 확인

    마무리: 이제 진짜 가상화 서버 구축의 시작입니다 🎉

    여기까지 따라오셨다면 이제 Proxmox VE 기반의 안정적인 가상화 서버 구축을 위한 기초가 완성된 거예요. 처음에는 설정할 게 많아 보여도, 한 번 제대로 해두면 나중에 진짜 편해집니다.

    저도 처음 홈랩에 Proxmox를 올렸을 때는 이런 가이드가 없어서 여기저기 찾아다니며 조각조각 맞추느라 꽤 오래 걸렸어요. 이 글이 처음 시작하시는 분들께 조금이나마 도움이 됐으면 좋겠네요.

    다음 단계로 추천하는 것들:

    • 🖥️ 첫 번째 VM 만들어보기 (Ubuntu Server, Rocky Linux 등)
    • 📦 LXC 컨테이너로 가벼운 서비스 돌려보기
    • 🔗 Let’s Encrypt 인증서로 웹 UI HTTPS 설정하기
    • 💾 외부 NAS 스토리지 연동 (NFS, SMB)
    • 🔄 Proxmox 클러스터 구성 (서버가 여러 대라면)

    다음 글에서는 Proxmox VE에서 첫 번째 VM 만들기를 다뤄볼 예정이에요. Ubuntu Server를 설치하고 기본 설정까지 하는 과정을 처음부터 끝까지 보여드릴게요. 기대해주세요!

    궁금한 점이나 제가 놓친 부분이 있으면 댓글로 남겨주세요. 같이 삽질하며 배우는 게 제일 재미있으니까요 😄

  • [HomeLabs] 저전력 미니PC 홈서버 구축 가이드: 하드웨어 선택부터 Proxmox VE 설치까지

    [HomeLabs] 저전력 미니PC 홈서버 구축 가이드: 하드웨어 선택부터 Proxmox VE 설치까지

    목차

    안녕하세요, 저는 13년차 인프라 엔지니어입니다!

    오늘은 제가 홈랩(Homelab)을 운영하면서 정말 유용하게 쓰고 있는 저전력 미니PC 홈서버 구축 경험을 공유해 드리려고 합니다. 13년 동안 데이터센터를 지키면서 수많은 서버를 다뤄봤지만, 집에서 나만의 서버를 24시간 돌리는 경험은 정말 다르더라고요. 무엇보다 전기 요금 걱정 없이 운영할 수 있는 저전력 홈서버는 인프라 엔지니어의 로망이라고 봅니다.

    처음엔 복잡하게만 느껴졌는데, 막상 직접 해보니 생각보다 진입 장벽이 낮더라고요. 이 글을 통해 여러분도 나만의 홈서버를 구축하고 다양한 기술을 실험할 수 있길 바랍니다. 특히 요즘 핫한 N100 미니PC를 활용한 가이드를 준비했으니, 차근차근 따라오시면 분명 성공하실 거예요! 🎉

    저전력 미니PC, 왜 홈서버로 딱일까요?

    홈서버를 구축할 때 가장 먼저 고민하게 되는 부분이 바로 ‘어떤 하드웨어를 쓸까?’ 하는 점일 겁니다. 과거에는 남는 데스크톱 PC를 활용하거나, 서버용 부품을 사서 조립하는 경우도 많았죠. 하지만 이런 방식들은 몇 가지 단점이 있었어요.

    • 높은 전력 소비량: PC 부품은 아무래도 서버용보다 전력 효율이 떨어지는 경우가 많습니다. 24시간 켜두면 전기 요금이 상당하더라고요.
    • 소음과 발열: 일반 PC는 서버실처럼 냉각이 잘 되는 환경이 아니면 소음과 발열이 만만치 않습니다.
    • 부피: 크고 무거워서 공간을 많이 차지하고, 미관상으로도 좋지 않을 수 있습니다.

    이런 단점들을 한 번에 해결해주는 게 바로 미니PC, 그중에서도 최근에 각광받고 있는 인텔 N100 프로세서 기반의 미니PC입니다. N100은 저전력에 고성능을 겸비한 CPU로, 홈서버에 정말 최적화되어 있어요. 제가 직접 써보니 전력 소비량은 스마트폰 충전기 수준인데, 웬만한 작업은 다 소화해 내더라고요. 진짜 물건입니다 이거!

    ▲ 저전력 미니PC 홈서버의 일반적인 구성 다이어그램입니다. 작은 본체 하나로 다양한 서비스를 돌릴 수 있죠.

    하드웨어 선택 가이드: N100 미니PC, 이것만 보세요!

    이제 본격적으로 미니PC 추천 및 선택 기준을 말씀드릴게요. N100 미니PC는 다양한 제조사에서 나오고 있지만, 홈서버로 활용할 때는 몇 가지 포인트를 꼭 확인하셔야 합니다.

    1. RAM (메모리): 최소 8GB, 가능하다면 16GB를 추천합니다. 가상머신(VM)이나 컨테이너(Container)를 여러 개 돌리려면 램 용량이 충분해야 해요. 제가 처음에 8GB로 시작했다가 몇 달 못 가서 16GB로 업그레이드했거든요. 😅
    2. Storage (저장 공간): NVMe SSD 슬롯이 있는 모델을 고르는 게 좋습니다. OS용으로 NVMe SSD 250GB~500GB를 장착하고, 데이터 저장용으로는 SATA 방식의 2.5인치 SSD나 HDD를 추가할 수 있는지 확인하세요. NVMe는 압도적인 속도를 제공합니다.
    3. Network (네트워크 인터페이스): 듀얼 LAN 포트(Dual NIC)가 있는 모델을 강력히 추천합니다! 하나는 외부망 연결, 다른 하나는 내부망(DMZ나 관리망)용으로 분리하면 보안에도 좋고, 네트워크 구성의 유연성이 훨씬 높아집니다. 나중에 방화벽(Firewall)이나 라우터(Router)로 활용할 때도 필수적이죠.
    4. Cooling (냉각): 팬(Fan)이 있는 모델과 팬리스(Fanless) 모델이 있는데, 팬리스는 소음이 전혀 없지만 발열 관리가 중요합니다. 팬이 있는 모델도 저전력 CPU라 조용하지만, 그래도 아주 미세한 소음은 있을 수 있습니다. 저는 개인적으로 안정성을 위해 팬이 있는 모델을 선호하는 편입니다.

    대부분의 N100 미니PC는 비슷한 성능을 내주기 때문에, 위 네 가지 기준을 만족하는 선에서 예산에 맞춰 고르시면 됩니다. 저도 여러 모델을 비교해보고 최종적으로 듀얼 LAN 포트를 가진 모델을 선택했습니다.

    홈서버 OS, 어떤 걸 설치해야 할까요?

    하드웨어를 정했다면 이제 홈서버의 ‘뇌’가 될 운영체제(Operating System, OS)를 선택해야 합니다. 선택지는 크게 세 가지로 나눌 수 있어요.

    OS 종류 특징 장점 단점 추천 용도
    Proxmox VE (Virtual Environment) 가상화 전용 OS (하이퍼바이저) VM, 컨테이너(LXC) 관리 용이, 웹 UI 편리 초기 설정이 다소 복잡할 수 있음 다양한 서비스 운영, 홈랩의 중추
    TrueNAS SCALE NAS(네트워크 저장장치) 및 컨테이너 플랫폼 강력한 ZFS 파일 시스템, 컨테이너(Docker, K3s) 지원 RAM 요구량이 높고, NAS 기능이 주력 대용량 파일 서버, 미디어 서버
    Ubuntu Server/Debian 범용 리눅스 서버 OS 가볍고 안정적, 광범위한 자료, 높은 자유도 모든 것을 직접 설정해야 함 (CLI 위주) 특정 서비스 단독 운영, CLI에 익숙한 사용자

    저는 다양한 가상 환경을 구축하고 싶어서 Proxmox VE를 선택했습니다. 웹 인터페이스가 직관적이라 VM이나 컨테이너를 생성하고 관리하는 게 정말 편하거든요. 처음엔 CLI만 쓰는 게 좀 부담스러웠는데, Proxmox 덕분에 GUI로 편리하게 관리하고 있습니다. 홈랩 OS 설치를 처음 해보시는 분들께 강력히 추천드려요!

    ▲ Proxmox VE 설치 과정 중 네트워크 설정 화면입니다. 듀얼 NIC가 있다면 여기서부터 설정을 잘 해줘야 하죠.

    Proxmox VE 설치, 저랑 같이 해봐요!

    이제 제가 직접 Proxmox VE를 설치했던 과정을 단계별로 설명해 드릴게요. 어렵지 않으니 천천히 따라오세요!

    1. 설치 미디어 준비

    1. Proxmox VE 공식 홈페이지에서 ISO 파일을 다운로드합니다. (반드시 최신 안정화 버전을 받으세요!)
    2. Rufus나 Ventoy 같은 툴을 사용해서 USB 드라이브에 ISO 파일을 구워(Burn) 부팅 가능한 USB를 만듭니다.

    2. 미니PC BIOS 설정

    1. 미니PC에 부팅 가능한 USB를 꽂고 전원을 켭니다.
    2. 부팅 시 DEL, F2, F7, F10, F12 등 제조사별로 다른 키를 눌러 BIOS(Basic Input/Output System) 설정 화면으로 진입합니다.
    3. Boot Order(부팅 순서)에서 USB 드라이브를 최상위로 설정하거나, Boot Override(강제 부팅) 메뉴에서 USB를 선택해 부팅합니다.
    4. UEFI 부팅이 가능한지 확인하고, 가능하다면 UEFI 모드로 설치하는 것을 권장합니다.

    3. Proxmox VE 설치 진행

    1. 부팅이 완료되면 Proxmox VE 설치 화면이 나타납니다. Install Proxmox VE를 선택하고 Enter를 누릅니다.
    2. EULA (End User License Agreement)에 동의합니다.
    3. 설치할 디스크를 선택합니다. NVMe SSD를 OS용으로 선택하는 것이 좋습니다. 여러 디스크가 있다면 헷갈리지 않게 잘 확인하세요!
    4. 국가, 시간대, 키보드 레이아웃을 설정합니다.
    5. 관리자(root) 비밀번호를 설정하고 이메일 주소를 입력합니다.
    6. 네트워크 설정을 합니다. 중요한 부분이죠!
      • Hostname (호스트 이름): 원하는 이름을 입력합니다 (예: homelab-pve).
      • IP Address (IP 주소): 고정 IP를 설정하는 것이 좋습니다 (예: 192.168.1.100/24).
      • Gateway (게이트웨이): 보통 공유기 IP 주소입니다 (예: 192.168.1.1).
      • DNS Server (DNS 서버): 게이트웨이 IP나 공용 DNS (8.8.8.8 등)를 입력합니다.
      • Management Interface (관리 인터페이스): 듀얼 LAN 포트라면 어떤 포트를 관리용으로 쓸지 선택합니다. 저는 보통 첫 번째 포트(enp1s0 같은)를 사용합니다.
    7. 설정 요약을 확인하고 Install 버튼을 눌러 설치를 시작합니다.
    8. 설치가 완료되면 USB를 제거하고 재부팅합니다.

    4. 초기 설정 (선택 사항)

    재부팅 후 웹 브라우저에서 설정한 IP 주소(예: https://192.168.1.100:8006)로 접속하면 Proxmox VE 웹 인터페이스를 만날 수 있습니다. 로그인 후 몇 가지 초기 설정을 해두면 좋습니다.

    # 엔터프라이즈 저장소 비활성화
sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list

# 무료 저장소 활성화
cat > /etc/apt/sources.list.d/pve-no-subscription.list << 'EOF'
deb http://ftp.debian.org/debian bookworm main contrib
deb http://ftp.debian.org/debian bookworm-updates main contrib
deb http://security.debian.org debian-security bookworm-security main contrib
deb http://ftp.proxmox.com/debian/pve bookworm pve-no-subscription
EOF

# 시스템 업데이트
apt update
apt upgrade -y

    저는 유료 구독 알림이 뜨는 게 싫어서 위 명령어로 저장소를 변경해줬습니다. 이렇게 하면 무료 버전에서도 업데이트를 원활하게 받을 수 있어요.

    ⚠️ 삽질 대잔치! 흔히 겪는 문제와 해결 팁

    제가 홈랩 OS 설치를 하면서 겪었던 대표적인 삽질 경험과 해결 방법을 공유해 드릴게요. 여러분은 저처럼 밤새지 마시라고요! 😅

    • UEFI 부팅 vs Legacy 부팅 문제: 일부 미니PC는 기본적으로 Legacy 모드로 설정되어 있거나, UEFI 부팅 옵션이 숨겨져 있는 경우가 있습니다. Proxmox는 UEFI 부팅을 권장하는데, Legacy로 설치하면 나중에 부팅 문제가 생길 수 있어요. BIOS에서 UEFI 모드를 활성화하고 Secure Boot(보안 부팅)는 끄는 것이 좋습니다.
    • 네트워크 드라이버 미인식: 특히 Realtek사의 네트워크 칩셋을 사용하는 저가형 미니PC에서 Proxmox가 드라이버를 제대로 인식하지 못하는 경우가 종종 있었습니다. 이럴 때는 설치 시 네트워크 설정을 건너뛰고, 설치 완료 후 다른 PC에서 드라이버 파일을 다운받아 USB 등으로 옮겨서 수동으로 설치하거나, Proxmox 포럼에서 관련 해결책을 찾아야 합니다. 다행히 N100 미니PC는 대부분 Intel 칩셋을 써서 이런 문제는 덜하더라고요. 휴~
    • 저장 공간 인식 문제: NVMe SSD가 BIOS에서는 보이는데 Proxmox 설치 시 선택 목록에 나타나지 않는 경우가 있습니다. 보통 SATA Mode가 AHCI로 설정되어 있는지 확인하고, BIOS 업데이트를 해보는 것이 해결책이 될 수 있습니다.

    혹시 이런 경험 있으신가요? 저도 처음엔 이게 뭔가 싶었는데, 결국엔 다 해결되더라고요. 삽질은 인프라 엔지니어의 숙명이죠! ㅎㅎ

    ▲ Proxmox VE 웹 인터페이스 대시보드입니다. 한눈에 서버의 상태와 가상머신들을 확인할 수 있어서 정말 편리합니다.

    드디어 완성! 우리만의 저전력 홈서버

    자, 이제 여러분의 저전력 미니PC 홈서버가 성공적으로 구축되었습니다! 🎉 웹 브라우저에서 Proxmox VE 관리자 페이지에 접속해 보세요. 로그인하면 서버의 CPU, RAM, 스토리지 사용량을 한눈에 볼 수 있는 대시보드가 나타날 겁니다. 이곳에서 가상머신(VM)을 만들고, 컨테이너(LXC)를 배포하며 여러분만의 서비스를 운영할 수 있습니다.

    제가 실제로 N100 미니PC 기반의 홈서버를 운영해 보니, 전력 소비량이 정말 인상적이었어요. 아이들(Idle) 상태에는 10W 미만, VM 몇 개 돌려도 20W를 넘기기 어렵더라고요. 이 정도면 24시간 켜둬도 전기 요금 걱정은 거의 없다고 봅니다. 소음도 거의 없어서 거실 한켠에 두어도 전혀 신경 쓰이지 않고요.

    이 작은 미니PC 하나로 다음과 같은 다양한 일들을 할 수 있습니다.

    • 개인 NAS (Nextcloud, PLEX 등)
    • 도커(Docker) 컨테이너 서비스 (홈 어시스턴트, 워드프레스, 각종 웹 서비스)
    • VPN 서버 (WireGuard, OpenVPN)
    • 개인용 백업 서버
    • 개발/테스트용 가상 환경

    마무리하며: 홈랩, 이제 시작입니다!

    오늘은 저전력 미니PC 홈서버 구축 가이드를 통해 하드웨어 선택부터 Proxmox VE OS 설치까지 제 경험을 바탕으로 자세히 알려드렸습니다. N100 미니PC는 저렴한 가격, 낮은 전력 소비량, 그리고 충분한 성능으로 홈서버를 시작하기에 정말 완벽한 선택이라고 생각합니다.

    물론 처음엔 시행착오도 겪고, 밤샘 삽질도 할 수 있습니다. 저도 그랬거든요! 하지만 그 과정에서 얻는 지식과 문제 해결 능력은 여러분의 인프라 엔지니어 역량을 한 단계 더 높여줄 거예요. 드디어 됐다! 하고 성공했을 때의 그 짜릿함은 해본 사람만이 알 수 있죠. 🤩

    이제 여러분의 미니PC 홈서버는 무궁무진한 가능성을 품고 있습니다. 다음 글에서는 이렇게 구축한 홈서버 위에 도커(Docker)를 설치하고 다양한 서비스를 배포하는 방법에 대해 다뤄볼 예정이니 기대해주세요! 여러분의 멋진 홈랩 라이프를 응원합니다!

    ▲ 미니PC 홈서버로 구현할 수 있는 다양한 활용 예시들을 시각화한 인포그래픽입니다.

  • [Proxmox] Proxmox 백업 자동화 완벽 가이드: PBS 및 스케줄 백업 활용

    목차

    백업 없이 운영하다가 날린 VM, 그 뼈아픈 경험 이야기

    솔직하게 고백하자면, 저도 한 번 날린 적 있습니다. 홈랩에서 열심히 세팅해 둔 VM(가상 머신) 하나가 스토리지 장애로 그냥 사라져버렸거든요. 백업? 당연히 없었죠. ‘홈랩인데 뭐 어때’ 라고 생각했던 게 화근이었습니다. 그 이후로 저는 Proxmox 백업 자동화를 진지하게 구축하기 시작했고, 지금은 매일 밤 자동으로 백업이 돌아가는 걸 보면서 마음이 편안해지는 사람이 됐습니다 ㅎㅎ.

    이 글은 Proxmox VE(Virtual Environment)를 운영하면서 Proxmox 백업 자동화를 아직 제대로 구성하지 못하신 분들을 위한 실전 가이드입니다. PBS(Proxmox Backup Server)를 활용한 자동화 방법부터, 스케줄 백업 설정, 그리고 실제 운영에서 겪은 삽질까지 전부 공유해 드릴게요.

    ▲ Proxmox VE와 PBS(Proxmox Backup Server)가 연동된 전체 백업 아키텍처 구성도. VM과 CT(컨테이너)가 PBS로 자동 백업되는 흐름을 보여줍니다.

    Proxmox 백업의 두 가지 방식: 어떤 걸 써야 할까?

    Proxmox VE에서 백업을 설정할 때 처음에 헷갈리는 게 바로 이 부분이에요. 백업 저장소를 어디로 잡느냐에 따라 Proxmox 백업 자동화 방식이 완전히 달라지거든요.

    구분 로컬/NFS/CIFS 백업 PBS(Proxmox Backup Server) 백업
    저장 방식 전체 이미지 파일 (.vma) 증분 백업 (변경분만 저장)
    중복 제거 ❌ 없음 ✅ 청크 기반 중복 제거
    암호화 제한적 ✅ 클라이언트 사이드 암호화 지원
    복원 속도 보통 빠름 (증분 복원 가능)
    스토리지 효율 낮음 매우 높음
    구축 난이도 쉬움 중간 (별도 서버 필요)

    쉽게 말해서, 로컬 백업은 간단하지만 디스크를 많이 잡아먹고, PBS는 증분 백업과 중복 제거 덕분에 같은 공간에 훨씬 많은 백업 포인트를 유지할 수 있어요. 홈랩이라 스토리지가 넉넉하지 않다면 PBS가 훨씬 유리합니다.

    저는 처음에 NFS 공유 폴더에 그냥 백업했다가, 한 달도 안 돼서 디스크가 꽉 차는 걸 경험했거든요. 그 이후로 Proxmox Backup Server로 갈아탔고, 같은 공간에 훨씬 오래된 백업 포인트를 유지할 수 있게 됐습니다.

    PBS(Proxmox Backup Server) 설치 및 초기 설정

    PBS는 Proxmox VE와는 별도의 소프트웨어입니다. 전용 ISO를 받아서 별도 머신(물리 서버든, VM이든)에 설치하는 게 기본이에요. 저는 홈랩에서 오래된 미니 PC 한 대를 PBS 전용으로 쓰고 있습니다.

    1단계: PBS 설치

    Proxmox 공식 사이트(proxmox.com)에서 PBS ISO를 다운받아서 설치하면 됩니다. 설치 과정은 Proxmox VE와 거의 동일해서 어렵지 않아요. 설치 후 웹 UI는 기본적으로 https://[PBS-IP]:8007로 접속합니다.

    2단계: 데이터스토어(Datastore) 생성

    PBS에서 백업이 실제로 저장되는 공간을 데이터스토어라고 부릅니다. 웹 UI에서 만들 수도 있고, CLI로도 만들 수 있어요.

    # PBS 서버에서 실행
# /mnt/backup-pool 디렉토리를 데이터스토어로 생성
proxmox-backup-manager datastore create main /mnt/backup-pool

# 생성된 데이터스토어 목록 확인
proxmox-backup-manager datastore list

    3단계: 사용자 및 토큰 생성 (API Token)

    Proxmox VE가 PBS에 접속할 때 사용할 API 토큰을 만들어야 합니다. 보안상 root 계정 대신 전용 사용자를 만드는 걸 권장해요.

    # PBS 서버에서 실행
# 백업 전용 사용자 생성
proxmox-backup-manager user create backup-user@pbs --password 'YourSecurePassword'

# 데이터스토어에 대한 권한 부여 (DatastoreBackup 역할)
proxmox-backup-manager acl update /datastore/main --auth-id 'backup-user@pbs' --role DatastoreBackup

# API 토큰 생성
proxmox-backup-manager user generate-token backup-user@pbs mytoken

    ⚠️ 중요! 토큰 값은 생성 시 한 번만 표시되니까 반드시 메모해 두세요. 저도 처음에 그냥 닫았다가 다시 만들었거든요 ㅎㅎ.

    Proxmox VE에 PBS 스토리지 연결하기

    이제 Proxmox VE 쪽에서 PBS를 백업 저장소로 등록해야 합니다.

    웹 UI로 연결하는 방법

    1. Proxmox VE 웹 UI 접속 → Datacenter 선택
    2. 왼쪽 메뉴에서 Storage 클릭
    3. Add 버튼 → Proxmox Backup Server 선택
    4. PBS 서버 IP, 포트(8007), 앞서 만든 사용자명과 토큰 값 입력
    5. 데이터스토어 이름 입력 후 저장

    CLI로 연결하는 방법

    # Proxmox VE 노드에서 실행
# PBS 스토리지를 /etc/pve/storage.cfg에 추가
pvesm add pbs pbs-backup \
  --server 192.168.1.100 \
  --datastore main \
  --username backup-user@pbs \
  --token mytoken \
  --tokenid 'backup-user@pbs!mytoken'

# 연결 확인
pvesm status

    연결이 성공하면 Proxmox VE 스토리지 목록에 PBS가 표시됩니다. 여기서 핑거프린트(Fingerprint) 불일치 오류가 나는 경우가 있는데, 이건 아래 트러블슈팅 섹션에서 다룰게요.

    ▲ Proxmox VE 웹 UI에서 PBS 스토리지를 연결하고 백업 작업을 설정하는 화면. Storage 메뉴에서 Proxmox Backup Server 타입을 선택해 연동합니다.

    Proxmox 스케줄 백업 설정: 자동화의 핵심

    이제 진짜 핵심입니다. 수동으로 백업 버튼 누르는 건 언젠가 반드시 까먹게 되어 있어요. Proxmox 스케줄 백업을 설정해두면 정해진 시간에 알아서 백업이 돌아갑니다.

    백업 작업(Backup Job) 생성

    Proxmox VE 웹 UI에서 Datacenter → Backup 메뉴로 이동하면 백업 작업을 만들 수 있어요.

    1. Add 버튼 클릭
    2. 노드(Node), 스토리지(Storage, 아까 연결한 PBS 선택), VM 선택
    3. 스케줄(Schedule) 설정
    4. 백업 모드(Mode) 선택
    5. 보존 정책(Retention) 설정

    스케줄 문법 이해하기

    Proxmox의 스케줄은 systemd 타이머 문법을 사용합니다. 처음엔 낯설 수 있는데, 익숙해지면 굉장히 직관적이에요.

    # 자주 쓰는 스케줄 예시
daily          # 매일 00:00
daily 02:00    # 매일 새벽 2시
weekly         # 매주 월요일 00:00
monthly        # 매월 1일 00:00
sat 03:00      # 매주 토요일 새벽 3시
*/2:00         # 2시간마다

# CLI로 백업 작업 생성 예시
pvesh create /cluster/backup \
  --storage pbs-backup \
  --schedule 'daily 02:00' \
  --mode snapshot \
  --vmid 100,101,102 \
  --mailnotification always \
  --mailto '[email protected]'

    백업 모드(Mode) 선택 기준

    • Snapshot 모드: VM이 실행 중인 상태에서 백업. 서비스 중단 없음. 가장 많이 씀.
    • Suspend 모드: 백업 중 VM을 일시 정지. 데이터 일관성이 높지만 잠깐 서비스 중단.
    • Stop 모드: VM을 완전히 끄고 백업. 가장 안전하지만 다운타임 발생.

    💡 팁: 데이터베이스가 돌아가는 VM이라면 Snapshot 모드만으로는 데이터 일관성이 보장되지 않을 수 있어요. 이 경우 QEMU Guest Agent를 설치하면 스냅샷 전에 파일시스템을 freeze(동결)해줘서 훨씬 안전합니다.

    보존 정책(Retention Policy) 설정

    백업을 얼마나 오래 보관할지 정하는 게 보존 정책입니다. PBS에서는 굉장히 세밀하게 설정할 수 있어요.

    # PBS 데이터스토어에 보존 정책 설정
proxmox-backup-manager datastore update main \
  --keep-last 3 \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 3

# 위 설정의 의미:
# keep-last 3   : 최신 백업 3개는 무조건 보관
# keep-daily 7  : 일별 백업을 7일치 보관
# keep-weekly 4 : 주별 백업을 4주치 보관
# keep-monthly 3: 월별 백업을 3개월치 보관

    이 설정 덕분에 같은 스토리지 공간으로 훨씬 오랜 기간의 백업 히스토리를 유지할 수 있습니다. 증분 백업 + 중복 제거 + 보존 정책, 이 세 가지가 Proxmox Backup Server의 핵심 강점이에요.

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

    이론은 이론이고, 실제로 설정하다 보면 별의별 문제가 다 생기더라고요. 제가 겪은 것들을 공유합니다.

    문제 1: 핑거프린트(Fingerprint) 불일치 오류

    PBS 스토리지를 추가할 때 이런 오류가 나는 경우가 있어요.

    TASK ERROR: fingerprint 'XX:XX:...' does not match

    PBS 서버에서 핑거프린트를 직접 확인해서 Proxmox VE 설정에 넣어주면 해결됩니다.

    # PBS 서버에서 실행
proxmox-backup-manager cert info | grep Fingerprint

# 출력된 핑거프린트를 복사해서
# Proxmox VE의 스토리지 설정에 fingerprint 항목에 붙여넣기

    문제 2: 백업 중 ‘lock timeout’ 오류

    VM 여러 개를 동시에 백업할 때 간혹 발생합니다. 기본적으로 Proxmox는 VM당 하나의 백업만 허용하는데, 이전 백업이 비정상 종료되면 락(Lock) 파일이 남아있을 수 있어요.

    # 특정 VM의 락 파일 확인 (VM ID 100 예시)
ls /run/lock/qemu-server/lock-100.conf

# 락 파일 제거 (백업이 실제로 안 돌아가고 있을 때만!)
rm /run/lock/qemu-server/lock-100.conf

    문제 3: 스냅샷 백업 시 디스크 공간 부족

    Snapshot 모드로 백업할 때 임시 스냅샷을 위한 여유 공간이 필요합니다. 스토리지가 꽉 차있으면 백업이 실패해요. 저장소에 최소 20% 정도 여유 공간을 확보해 두는 게 좋습니다.

    문제 4: PBS 가비지 컬렉션 미실행으로 인한 공간 낭비

    PBS에서 오래된 백업을 삭제해도 실제 디스크 공간이 바로 회수되지 않아요. 가비지 컬렉션(Garbage Collection)을 주기적으로 실행해야 합니다.

    # PBS 서버에서 가비지 컬렉션 수동 실행
proxmox-backup-manager garbage-collection start main

# 스케줄 설정 (매주 일요일 새벽 4시)
proxmox-backup-manager datastore update main \
  --gc-schedule 'sun 04:00'

    저도 이걸 몰라서 한동안 PBS 디스크가 예상보다 빨리 차는 걸 보고 의아했었는데, 가비지 컬렉션 설정하고 나서 해결됐습니다.

    ▲ PBS 웹 대시보드에서 백업 작업 현황, 스토리지 사용량, 보존 정책 적용 결과를 한눈에 확인할 수 있습니다.

    백업 검증: 백업했다고 끝이 아닙니다

    이게 진짜 중요한데 많이들 놓치는 부분이에요. 백업은 복원이 되어야 의미가 있습니다. 백업 파일이 존재한다는 것과, 그 백업으로 실제로 복원이 된다는 건 다른 얘기거든요.

    백업 무결성 검증 (Verify)

    PBS는 백업 데이터의 무결성을 검증하는 기능을 내장하고 있습니다.

    # PBS 서버에서 특정 데이터스토어 검증
proxmox-backup-manager verify-job create \
  --store main \
  --schedule 'weekly' \
  --ignore-verified true \
  --outdated-after 30

# 수동 검증 실행
proxmox-backup-manager verify-job run verify-job-id

    복원 테스트

    저는 분기에 한 번씩은 실제로 VM을 복원해보는 테스트를 합니다. Proxmox VE 웹 UI에서는 간단하게 할 수 있어요.

    1. Proxmox VE 웹 UI → 해당 노드 → PBS 스토리지 선택
    2. 복원하고 싶은 백업 포인트 선택
    3. Restore 버튼 클릭
    4. 복원할 VM ID와 스토리지 지정 후 실행

    CLI로도 복원할 수 있습니다.

    # VM 백업 복원 (VM ID 100, 새 VM ID 200으로 복원)
qmrestore pbs-backup:vm/100/2024-01-15T02:00:00Z 200 \
  --storage local-lvm \
  --force

# CT(LXC 컨테이너) 백업 복원
pct restore 201 pbs-backup:ct/101/2024-01-15T02:00:00Z \
  --storage local-lvm \
  --force

    VM 백업 전략: 어떻게 구성하면 좋을까?

    마지막으로 제가 실제로 운영 중인 VM 백업 전략을 공유할게요. 홈랩 기준이지만 소규모 운영 환경에도 참고하실 수 있을 거예요.

    ▲ VM 중요도에 따라 차등화된 백업 전략 인포그래픽. 중요 서비스는 매일, 개발/테스트 VM은 주 단위로 백업 주기를 다르게 설정합니다.

    제가 쓰는 3-2-1 백업 전략

    • 3: 데이터 복사본 3개 유지
    • 2: 2가지 다른 미디어/스토리지에 저장
    • 1: 1개는 오프사이트(다른 물리적 위치)에 보관

    홈랩에서 완전한 3-2-1을 구현하기 어렵다면, 최소한 PBS 백업 + 외장 하드 또는 클라우드 스토리지(B2, S3 등)에 추가 백업을 유지하는 것을 권장합니다.

    VM 중요도별 백업 주기

    • 중요 서비스 VM (홈서버, NAS 등): 매일 새벽 2시, 7일치 보관
    • 일반 서비스 VM: 매일 새벽 3시, 3일치 보관
    • 개발/테스트 VM: 주 1회, 2주치 보관

    마무리: 백업은 습관입니다

    여기까지 따라오셨다면, 이제 Proxmox 백업 자동화의 기본 틀은 완성됐습니다. 🎉

    정리하자면:

    • ✅ PBS를 설치하고 Proxmox VE와 연동했습니다
    • ✅ 증분 백업과 중복 제거로 스토리지를 효율적으로 사용합니다
    • ✅ 스케줄 백업으로 매일 자동으로 백업이 돌아갑니다
    • ✅ 보존 정책으로 오래된 백업을 자동 정리합니다
    • ✅ 검증과 복원 테스트로 백업의 신뢰성을 확인합니다

    백업은 한 번 설정했다고 끝이 아니에요. 주기적으로 백업이 제대로 돌아가고 있는지, 복원은 실제로 되는지 확인하는 습관이 중요합니다. 저도 매월 PBS 대시보드를 한 번씩 들여다보고, 분기에 한 번은 복원 테스트를 하고 있어요.

    다음 글에서는 Proxmox VE 클러스터 구성과 고가용성(HA) 설정에 대해 다룰 예정입니다. PBS 백업이 잘 되어 있으면 클러스터 구성도 훨씬 마음 편하게 할 수 있거든요. 기대해주세요!

    혹시 설정하다가 막히는 부분이 있으시면 댓글로 남겨주세요. 같이 해결해봐요 😊

    자주 묻는 질문 (FAQ)

    Q. PBS 서버는 반드시 별도 물리 서버여야 하나요?

    꼭 그렇지는 않습니다. Proxmox VE 위에 VM으로 PBS를 올릴 수도 있어요. 다만 해당 노드가 장애가 나면 백업 서버도 같이 다운된다는 단점이 있어서, 가능하면 별도 머신을 추천합니다.

    Q. 백업 중 VM 성능이 저하되나요?

    Snapshot 모드는 백업 중 성능 영향이 거의 없습니다. 다만 스토리지 I/O는 백업 중 증가할 수 있어요. 그래서 새벽 시간대에 스케줄을 잡는 게 좋습니다.

    Q. PBS 없이 로컬 백업만으로 충분하지 않나요?

    단순한 환경이라면 로컬 백업도 괜찮습니다. 하지만 VM이 5개 이상이거나, 스토리지 공간이 넉넉하지 않다면 Proxmox Backup Server의 증분 백업과 중복 제거 기능이 확실히 유리합니다.

  • [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 기본 클러스터 구성 글도 참고하시면 이번 내용이 더 잘 이해되실 겁니다.

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

  • [HomeLabs] 저전력 미니 서버 구축: N100/N305 미니PC 홈서버 완벽 가이드

    [HomeLabs] 저전력 미니 서버 구축: N100/N305 미니PC 홈서버 완벽 가이드

    목차

    전기세 걱정 없는 홈서버, N100/N305 미니PC로 시작하기

    홈서버 구축을 처음 고민할 때 가장 많이 받는 질문이 있어요. “전기세 얼마나 나와요?” 저도 처음에 타워형 서버로 홈랩을 시작했다가 한 달 전기세 고지서 보고 잠깐 멘붕이 왔었거든요. 그때부터 저전력 미니 서버 쪽으로 눈을 돌리기 시작했습니다.

    요즘 홈랩 커뮤니티에서 가장 핫한 조합이 바로 인텔 N100, N305 칩셋을 탑재한 미니PC예요. 가격도 합리적이고, 전력 소비는 놀라울 정도로 낮고, 성능은 웬만한 홈랩 워크로드를 충분히 소화해내거든요. 오늘은 제가 직접 구축하고 운영해온 경험을 바탕으로 N100/N305 미니PC 홈서버 구축 완벽 가이드를 정리해봤습니다.

    N100 N305 미니PC 홈서버 전체 구성도 및 홈랩 아키텍처 다이어그램

    ▲ N100/N305 기반 저전력 홈랩의 전체 구성도 — 미니PC 본체부터 네트워크 스위치, NAS 연결까지 한눈에 볼 수 있는 레이아웃입니다.

    N100과 N305, 뭐가 다른가요?

    처음 보시는 분들은 “N100이랑 N305가 뭔데요?” 하실 수 있어요. 쉽게 말해서, 인텔이 저전력 소형 기기용으로 내놓은 Alder Lake-N 시리즈 프로세서입니다. 기존 Celeron/Pentium 라인을 대체하는 포지션이라고 보시면 돼요.

    N100 vs N305 핵심 차이점

    항목 Intel N100 Intel N305
    코어 구성 4코어 (E-core) 8코어 (E-core)
    TDP (열설계전력) 6W 15W
    최대 부스트 클럭 3.4GHz 3.8GHz
    ECC 메모리 지원 미지원 지원 (일부 보드)
    적합한 용도 단독 서비스, 가벼운 컨테이너 다수 VM, 복잡한 워크로드
    대략적 가격대 상대적으로 저렴 N100 대비 높음

    제 경험상 처음 홈서버를 시작하는 분이라면 N100으로도 충분합니다. Docker 컨테이너 10~20개 정도는 거뜬히 돌아가요. 반면에 Proxmox VE(프록스목스, 오픈소스 가상화 플랫폼)로 여러 개의 VM을 동시에 굴리거나, 미디어 트랜스코딩(실시간 영상 변환)을 함께 할 계획이라면 N305 쪽이 더 여유롭습니다.

    💡 팁: N100/N305 모두 Intel Quick Sync(퀵 싱크, 하드웨어 가속 영상 처리) 기능을 지원합니다. Plex나 Jellyfin(젤리핀, 미디어 서버) 트랜스코딩에 이걸 활용하면 CPU 부하가 확 줄어들어요.

    하드웨어 선택 가이드 — 뭘 사야 하나요?

    미니PC 시장에는 정말 다양한 제품이 있는데, 처음엔 어떤 걸 골라야 할지 막막하더라고요. 제가 실제로 고려했던 체크리스트를 공유할게요.

    미니PC 선택 시 핵심 체크리스트

    • LAN 포트 개수: 홈서버용이라면 2.5GbE(2.5기가비트 이더넷) 포트가 2개 이상인 게 좋아요. 하나는 업스트림, 하나는 관리용이나 추가 네트워크 분리에 씁니다.
    • RAM 확장성: 최소 16GB는 되어야 해요. 처음엔 8GB로 버티다가 결국 업그레이드했는데, 처음부터 넉넉하게 가는 게 낫더라고요.
    • 스토리지 슬롯: M.2 NVMe 슬롯이 2개 이상이면 OS용 + 데이터용으로 분리 운영이 가능해서 편합니다.
    • USB 포트: USB 3.0 이상 포트가 넉넉한지 확인. 외장 스토리지 연결할 때 필요해요.
    • 팬리스 vs 쿨링팬 여부: 24시간 돌아가는 서버라면 팬 소음이 생각보다 거슬릴 수 있어요.
    • Wake-on-LAN (WoL) 지원: 원격으로 전원을 켤 수 있는 기능. 홈서버에선 거의 필수입니다.

    시중에 N100 탑재 미니PC는 여러 브랜드에서 다양한 모델로 출시되어 있어요. 구매 전에 커뮤니티 리뷰와 실제 사용자 후기를 꼭 확인하시는 걸 추천드려요. 특히 바이오스(BIOS) 업데이트 지원이 잘 되는지, 리눅스 드라이버 호환성은 어떤지가 중요하거든요.

    OS 설치 — Proxmox VE로 홈랩 기반 다지기

    저는 홈서버 OS로 Proxmox VE(프록스목스 버추얼 인바이런먼트)를 강력 추천합니다. 오픈소스 하이퍼바이저(가상화 플랫폼)인데, 웹 UI로 VM과 LXC 컨테이너를 쉽게 관리할 수 있어서 홈랩에 딱이거든요.

    Proxmox VE 설치 순서

    1. Proxmox 공식 사이트에서 ISO 이미지 다운로드
    2. Rufus 또는 Balena Etcher로 USB 부팅 디스크 생성
    3. 미니PC에 USB 꽂고 부팅, BIOS에서 USB 부팅 우선순위 설정
    4. 설치 마법사 진행 — IP 주소, 게이트웨이, DNS 설정
    5. 설치 완료 후 웹 브라우저에서 https://[IP주소]:8006 접속

    설치 자체는 어렵지 않아요. 근데 여기서 한 가지 꼭 챙겨야 할 게 있습니다.

    ⚠️ 주의: Proxmox 기본 설치 후 엔터프라이즈 저장소(Enterprise Repository)가 활성화되어 있어서, 라이선스 없이 apt update를 하면 오류가 납니다. 아래 설정으로 무료 커뮤니티 저장소로 바꿔주세요. 

    # Proxmox 엔터프라이즈 저장소 비활성화
echo "# deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise" > /etc/apt/sources.list.d/pve-enterprise.list

# 무료 커뮤니티 저장소 추가
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list

# 패키지 업데이트
apt update && apt upgrade -y

    저도 처음에 이거 모르고 한참 헤맸습니다 ㅎㅎ. 설치 직후에 꼭 해주세요.

    N100/N305에서 Intel GPU 패스스루 설정

    미디어 서버를 돌릴 계획이라면 내장 GPU를 LXC 컨테이너나 VM에 넘겨주는 GPU 패스스루(Pass-through) 설정이 중요합니다.

    # LXC 컨테이너 설정 파일 예시 (/etc/pve/lxc/[CTID].conf)
# i915 드라이버를 통한 Intel Quick Sync 공유 방식 설정

lxc.cgroup2.devices.allow: c 226:0 rwm
lxc.cgroup2.devices.allow: c 226:128 rwm
lxc.cgroup2.devices.allow: c 29:0 rwm
lxc.mount.entry: /dev/fb0 dev/fb0 none bind,optional,create=file
lxc.mount.entry: /dev/dri dev/dri none bind,optional,create=dir
lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file

    이렇게 하면 Jellyfin 같은 미디어 서버 컨테이너에서 Intel Quick Sync 하드웨어 가속을 바로 쓸 수 있어요. 체감 차이가 꽤 큽니다.

    Proxmox VE 웹 대시보드에서 N100 미니PC 홈서버 노드와 컨테이너 관리 화면

    ▲ Proxmox VE 웹 대시보드 — CPU 사용률, 메모리, 스토리지 현황을 한눈에 파악할 수 있어요. N100 기반임에도 여러 컨테이너가 여유롭게 돌아가고 있습니다.

    Docker로 핵심 서비스 올리기

    Proxmox 위에 Debian LXC 컨테이너를 만들고, 그 안에 Docker를 설치하는 방식을 저는 선호합니다. VM보다 오버헤드가 적고, 그렇다고 호스트를 직접 건드리지 않아도 되거든요.

    Docker + Docker Compose 설치

    # 기존 구버전 Docker 제거
apt remove docker docker-engine docker.io containerd runc

# 필수 패키지 설치
apt update
apt install -y ca-certificates curl gnupg lsb-release

# Docker 공식 GPG 키 추가
mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Docker 저장소 추가
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
  $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null

# Docker 엔진 설치
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

    홈랩 필수 서비스 Docker Compose 예시

    제가 실제로 돌리고 있는 스택의 일부를 공유할게요. Traefik(트래픽, 리버스 프록시)을 앞단에 두고, 각 서비스를 뒤에 배치하는 구조입니다.

    version: '3.8'

services:
  traefik:
    image: traefik:v2.10
    container_name: traefik
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"  # Traefik 대시보드
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./traefik/traefik.yml:/traefik.yml:ro
      - ./traefik/acme.json:/acme.json  # Let's Encrypt 인증서
    networks:
      - proxy

  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.portainer.rule=Host(`portainer.homelab.local`)"
    networks:
      - proxy

  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    restart: unless-stopped
    devices:
      - /dev/dri:/dev/dri  # Intel Quick Sync GPU 패스스루
    volumes:
      - ./jellyfin/config:/config
      - /mnt/media:/media:ro
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.jellyfin.rule=Host(`jellyfin.homelab.local`)"
    networks:
      - proxy

volumes:
  portainer_data:

networks:
  proxy:
    external: true

    Traefik을 쓰면 각 서비스마다 포트 번호를 외울 필요 없이 도메인 이름으로 접근할 수 있어서 진짜 편해요. 처음엔 설정이 좀 복잡해 보이는데, 한 번 익히면 계속 쓰게 됩니다.

    홈랩에서 자주 쓰는 서비스 목록

    • Portainer(포테이너): Docker 컨테이너 웹 UI 관리
    • Jellyfin(젤리핀): 오픈소스 미디어 서버
    • Home Assistant(홈 어시스턴트): 스마트홈 허브
    • Pi-hole(파이홀): 네트워크 광고 차단 DNS
    • Uptime Kuma(업타임 쿠마): 서비스 모니터링
    • Vaultwarden(볼트워든): 셀프호스팅 비밀번호 관리자 (Bitwarden 호환)
    • Nextcloud(넥스트클라우드): 셀프호스팅 클라우드 스토리지

    ⚠️ 삽질 포인트 — 이것만 주의하면 됩니다

    13년 경력이라고 해도 새로운 환경에서는 삽질을 합니다 ㅎㅎ. 제가 N100 미니PC 홈서버 세팅하면서 걸렸던 포인트들을 정리해봤어요.

    문제 1: 절전 모드로 인한 서버 다운

    처음에 며칠 잘 돌다가 갑자기 서버가 응답을 안 하는 거예요. 가서 보면 켜져 있는데 핑이 안 되더라고요. 알고 보니 BIOS의 절전 설정이 문제였습니다.

    # Linux에서 절전 모드 비활성화
# /etc/systemd/sleep.conf 수정

[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no

    BIOS에서도 S3 Sleep State를 비활성화하거나, AC 전원 연결 시 자동 부팅 옵션을 켜두세요. 정전 후 자동 복구에도 필요합니다.

    문제 2: NTP 시간 동기화 오류로 인한 인증서 오류

    LXC 컨테이너에서 HTTPS 인증서 관련 오류가 간헐적으로 났었는데, 원인이 시간 동기화 문제였어요. 컨테이너 내부 시간이 호스트와 달라지는 경우가 있거든요.

    # 호스트 시간대 설정
timedatectl set-timezone Asia/Seoul

# systemd-timesyncd 활성화
systemctl enable systemd-timesyncd
systemctl start systemd-timesyncd

# 동기화 상태 확인
timedatectl status

    문제 3: 저장 공간 부족 — /var/lib/docker 폭탄

    Docker를 쓰다 보면 사용하지 않는 이미지, 볼륨, 네트워크가 쌓여서 디스크를 잡아먹습니다. 주기적으로 정리해줘야 해요.

    # 사용하지 않는 Docker 리소스 전체 정리
docker system prune -a --volumes

# 또는 개별 정리
docker image prune -a    # 미사용 이미지 삭제
docker volume prune      # 미사용 볼륨 삭제
docker network prune     # 미사용 네트워크 삭제

# 현재 디스크 사용량 확인
docker system df

    저는 이걸 cron(크론, 리눅스 작업 스케줄러)으로 매주 한 번씩 자동 실행되도록 해뒀습니다.

    전력 소비 모니터링 — 진짜 얼마나 아낄 수 있나요?

    홈서버 구축할 때 가장 궁금한 게 “전기세 얼마나 나오냐”잖아요. N100 미니PC는 아이들(idle, 대기 상태) 시 소비 전력이 매우 낮습니다. 물론 실제 수치는 구체적인 모델과 구성에 따라 다르지만, 일반적으로 구형 타워 서버나 데스크탑 대비 전력 소비가 크게 낮은 편이에요.

    Proxmox에서 전력 관련 상태를 간단히 확인하는 방법이에요.

    # CPU 현재 주파수 및 거버너 확인
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# powertop 설치 및 실행 (전력 소비 분석 툴)
apt install powertop -y
powertop

# CPU 절전 모드 활성화 (powertop 자동 튜닝)
powertop --auto-tune

    💡 팁: powertop --auto-tune을 /etc/rc.local에 추가해두면 부팅 시 자동으로 전력 최적화가 적용됩니다. 체감상 아이들 소비 전력이 더 낮아지더라고요.

    홈서버 Grafana 모니터링 대시보드에서 저전력 미니PC 전력 소비 및 컨테이너 현황 확인

    ▲ Grafana(그라파나) + Prometheus(프로메테우스)로 구성한 홈서버 모니터링 대시보드 — CPU, 메모리, 네트워크, 전력 소비까지 실시간으로 확인할 수 있어요.

    자주 묻는 질문 (FAQ)

    Q. N100 미니PC로 NAS(나스, 네트워크 연결 스토리지)도 되나요?

    됩니다! USB 3.0으로 외장 HDD를 연결하거나, M.2 슬롯에 NVMe를 꽂아서 TrueNAS Scale이나 OpenMediaVault를 올릴 수 있어요. 다만 대용량 HDD를 여러 개 연결하고 싶다면 SATA 포트가 없는 모델이 많아서, 이 경우엔 USB 3.0 허브나 별도 NAS를 따로 두는 걸 추천합니다.

    Q. N100으로 쿠버네티스(Kubernetes) 운영 가능한가요?

    가능하긴 한데, 단일 노드라면 K3s(케이쓰리에스, 경량 쿠버네티스)를 추천합니다. 풀 쿠버네티스보다 리소스를 훨씬 적게 먹거든요. 저도 다음 글에서 K3s 홈랩 구축 과정을 다룰 예정이에요.

    Q. 외부에서 접속하려면 어떻게 해야 하나요?

    가장 안전한 방법은 Tailscale(테일스케일, 메시 VPN 서비스) 또는 WireGuard(와이어가드, 오픈소스 VPN)를 사용하는 거예요. 포트 포워딩으로 직접 노출하는 건 보안상 권장하지 않습니다.

    Q. 처음 시작할 때 예산은 얼마나 잡아야 하나요?

    N100 미니PC 본체, RAM, NVMe SSD를 합쳐서 구성할 수 있어요. 중고 시장도 잘 활용하면 더 절약할 수 있고요. 정확한 가격은 시기와 판매처에 따라 다르니 구매 시점에 직접 비교해보시는 게 좋습니다.

    마무리 — 저전력 홈서버, 이제 시작해보세요

    N100 N305 미니PC 홈서버 구축 단계별 로드맵 요약 인포그래픽

    ▲ N100/N305 미니PC 홈서버 구축 로드맵 요약 — OS 설치부터 서비스 배포까지의 단계를 한눈에 정리한 인포그래픽입니다.

    저전력 미니 서버는 홈랩 입문자에게도, 기존 서버 전기세에 지친 분들에게도 정말 매력적인 선택지입니다. N100/N305 기반 미니PC는 낮은 전력 소비, 조용한 운영, 합리적인 가격이라는 세 가지 장점을 동시에 갖추고 있거든요.

    오늘 다룬 내용을 정리하면:

    • ✅ N100(4코어, 6W)은 입문용, N305(8코어, 15W)는 더 무거운 워크로드에 적합
    • ✅ Proxmox VE로 가상화 기반을 구축하면 확장성이 뛰어남
    • ✅ Docker + Traefik 조합으로 다양한 셀프호스팅 서비스를 깔끔하게 관리
    • ✅ 절전 모드, 시간 동기화, 디스크 정리는 초기에 꼭 챙겨야 할 포인트
    • ✅ Intel Quick Sync 활용으로 미디어 트랜스코딩 효율 극대화 가능

    다음 글에서는 이 환경 위에 K3s 경량 쿠버네티스 클러스터를 구축하는 방법을 다룰 예정입니다. 미니PC 여러 대를 묶어서 클러스터를 만드는 건데, 생각보다 훨씬 재미있는 경험이거든요. 기대해주세요!

    궁금한 점이나 다른 삽질 경험이 있으시면 댓글로 남겨주세요. 같이 해결해봐요 🎉

  • [Proxmox] Proxmox VE ZFS 스토리지 최적화: 성능과 안정성 동시 확보 가이드

    [Proxmox] Proxmox VE ZFS 스토리지 최적화: 성능과 안정성 동시 확보 가이드

    목차

    ZFS를 Proxmox에 올리면 생기는 일

    홈랩을 운영하다 보면 어느 순간 이런 생각이 드시죠. “스토리지 관리 좀 제대로 해보고 싶다.” 저도 그랬거든요. 처음엔 그냥 ext4 파티션에 LVM(논리 볼륨 관리자) 얹어서 쓰다가, 어느 날 디스크 하나가 조용히 세상을 떠나면서 VM 이미지를 통째로 날린 경험이 있습니다. 그날 이후로 ZFS(Zettabyte File System)를 진지하게 공부하기 시작했어요.

    Proxmox VE ZFS 조합은 사실 홈랩 커뮤니티에서 꽤 오래된 조합입니다. Proxmox VE가 ZFS를 기본 지원하기 시작한 이후로, 별도의 커널 모듈 컴파일 없이도 ZFS를 바로 쓸 수 있게 됐거든요. 근데 막상 써보면 “설치는 쉬운데, 최적화는 어디서부터 시작해야 하지?” 하는 막막함이 있더라고요. 오늘은 그 막막함을 같이 해소해 보겠습니다.

    Proxmox VE ZFS 스토리지 아키텍처 전체 계층 구조 다이어그램

    ▲ Proxmox VE + ZFS 스토리지 구성 전체 아키텍처 — VM/CT 레이어부터 ZFS 풀(Pool), 물리 디스크까지의 계층 구조를 보여줍니다.

    ZFS가 뭔지 먼저 짚고 가겠습니다

    쉽게 말해서 ZFS는 “똑똑한 파일 시스템”입니다

    일반 파일 시스템과 ZFS의 가장 큰 차이점은, ZFS가 파일 시스템과 볼륨 관리자를 동시에 담당한다는 점이에요. 기존에는 파티션 → LVM → 파일 시스템 이렇게 레이어가 쌓였다면, ZFS는 이걸 하나로 통합해서 관리합니다.

    핵심 기능만 짚어볼게요:

    • Copy-on-Write(CoW, 쓰기 시 복사): 데이터를 덮어쓰지 않고 항상 새 블록에 씁니다. 시스템이 갑자기 꺼져도 데이터가 깨지지 않아요.
    • Checksum(체크섬, 데이터 무결성 검증): 모든 블록에 체크섬이 붙어 있어서, 읽을 때마다 데이터가 정상인지 자동으로 확인합니다. Silent Data Corruption(무음 데이터 손상)을 잡아내는 거죠.
    • Snapshot(스냅샷): 순간적으로 파일 시스템 상태를 저장합니다. Proxmox에서 VM 백업할 때 이게 핵심이에요.
    • RAID-Z(레이드-Z): 소프트웨어 RAID를 ZFS 레벨에서 처리합니다. 하드웨어 RAID 컨트롤러 없이도 충분한 안정성을 확보할 수 있어요.
    • ARC(Adaptive Replacement Cache, 적응형 교체 캐시): RAM을 읽기 캐시로 활용합니다. 메모리가 많을수록 성능이 올라가요.

    Proxmox VE에서 ZFS 스토리지를 쓰면 좋은 이유

    솔직히 말하면, Proxmox + ZFS 조합의 가장 큰 장점은 스냅샷 기반 백업이 기가 막히게 편하다는 겁니다. VM을 백업할 때 ZFS 스냅샷을 찍으면 거의 순간적으로 완료되거든요. 100GB짜리 VM이라도 스냅샷 자체는 1초도 안 걸립니다. 실제 데이터 복사가 아니라 메타데이터만 기록하는 방식이라서요.

    항목 기존 LVM + ext4 ZFS
    데이터 무결성 파일 시스템 레벨만 블록 레벨 체크섬
    스냅샷 속도 데이터 크기에 비례 거의 즉각적
    RAID 관리 별도 mdadm 필요 ZFS 내장
    압축 지원 안 함 투명 압축 지원
    RAM 요구량 낮음 높음 (ARC 때문에)
    설정 복잡도 낮음 중간~높음

    Proxmox VE ZFS 풀(Pool) 구성하기

    1단계: ZFS 풀 생성 전 디스크 확인

    먼저 사용할 디스크들을 확인합니다. 중요한 건 ZFS는 반드시 디스크 전체를 넘겨줘야 한다는 거예요. 파티션 위에 ZFS를 올리는 것도 기술적으로는 가능하지만, 권장하지 않습니다. 저도 처음에 파티션 위에 올렸다가 나중에 풀 교체하는 데 고생했거든요.

    # 현재 연결된 디스크 목록 확인
lsblk -d -o NAME,SIZE,MODEL,SERIAL

# 디스크 상태 확인 (스마트 정보)
smartctl -a /dev/sdb

# ZFS에서 사용할 디스크 ID 확인 (권장: ID 방식으로 지정)
ls -la /dev/disk/by-id/ | grep -v part

    💡 팁: ZFS 풀 생성 시 /dev/sdb 같은 경로 대신 /dev/disk/by-id/ 아래의 ID를 사용하세요. 재부팅 후 디스크 순서가 바뀌어도 안전합니다.

    2단계: ZFS 풀 생성

    Proxmox에서 ZFS 풀을 만드는 방법은 두 가지입니다. GUI로 하거나 CLI로 하거나. 저는 CLI를 선호해요. 정확히 뭘 하는지 눈에 보이니까요.

    # 미러(Mirror, RAID-1과 유사) 풀 생성 예시 — 디스크 2개
zpool create -o ashift=12 \
  -O compression=lz4 \
  -O atime=off \
  -O xattr=sa \
  -O dnodesize=auto \
  rpool mirror \
  /dev/disk/by-id/ata-디스크1_시리얼 \
  /dev/disk/by-id/ata-디스크2_시리얼

# RAID-Z1 풀 생성 예시 — 디스크 3개 이상
zpool create -o ashift=12 \
  -O compression=lz4 \
  -O atime=off \
  -O xattr=sa \
  -O dnodesize=auto \
  datapool raidz1 \
  /dev/disk/by-id/ata-디스크1_시리얼 \
  /dev/disk/by-id/ata-디스크2_시리얼 \
  /dev/disk/by-id/ata-디스크3_시리얼

    여기서 각 옵션이 뭔지 짚어볼게요:

    • ashift=12: 4KB 섹터 디스크에 맞는 설정. 요즘 HDD/SSD 대부분이 4KB 섹터 또는 그 이상이라서 거의 필수입니다. 풀 생성 후 변경 불가니까 처음에 꼭 확인하세요.
    • compression=lz4: LZ4 압축 활성화. CPU 부하가 거의 없으면서 10~30% 정도 공간을 아낄 수 있어요.
    • atime=off: 파일 접근 시간 기록 비활성화. I/O 성능 향상에 도움이 됩니다.
    • xattr=sa: 확장 속성을 inode에 저장. 성능 향상에 기여해요.
    • dnodesize=auto: dnode 크기 자동 조정. 대용량 파일 시스템에 유리합니다.

    3단계: Proxmox에 ZFS 스토리지 등록

    풀을 만들었으면 Proxmox가 이걸 스토리지로 인식하게 해줘야 합니다.

    # /etc/pve/storage.cfg 에 추가하거나
# Proxmox GUI: Datacenter > Storage > Add > ZFS 선택

# CLI로 추가하는 방법
pvesm add zfspool datapool-storage \
  --pool datapool \
  --content images,rootdir \
  --sparse 1

    GUI에서 하시면 Datacenter → Storage → Add → ZFS 선택하고 풀 이름 입력하면 됩니다. 훨씬 직관적이에요.

    Proxmox VE 웹 GUI ZFS 스토리지 추가 설정 화면

    ▲ Proxmox VE 관리 콘솔에서 ZFS 풀을 스토리지로 등록하는 화면 — 풀 이름, Content 타입, Sparse 옵션 등을 설정합니다.

    ZFS 성능 최적화 핵심 설정

    ARC 메모리 설정 — 제일 중요합니다

    ZFS의 ARC(Adaptive Replacement Cache)는 기본적으로 사용 가능한 RAM의 절반 정도까지 사용하려고 합니다. 홈랩이나 소규모 서버에서는 이게 VM들이 쓸 메모리를 잡아먹는 문제가 생겨요. 저도 처음에 이 설정 안 하고 쓰다가 “왜 VM이 이렇게 느리지?” 하면서 한참 삽질했습니다.

    # 현재 ARC 사용량 확인
cat /proc/spl/kstat/zfs/arcstats | grep -E '^(size|c_max|c_min|hits|misses)'

# ARC 최대 크기 제한 설정 (예: 8GB로 제한)
# /etc/modprobe.d/zfs.conf 파일 생성/편집
cat > /etc/modprobe.d/zfs.conf << 'EOF'
options zfs zfs_arc_max=8589934592
EOF

# 즉시 적용 (재부팅 없이)
echo 8589934592 > /sys/module/zfs/parameters/zfs_arc_max

# 변경 확인
cat /sys/module/zfs/parameters/zfs_arc_max

    ⚠️ 주의: ARC를 너무 작게 설정하면 ZFS 성능이 크게 떨어집니다. 일반적으로 전체 RAM의 20~25% 정도는 ARC에 남겨두는 걸 권장해요. 16GB RAM이면 최소 4GB는 ARC에 할당하는 게 좋습니다.

    L2ARC와 ZIL/SLOG 설정 — SSD 있으면 써먹어야죠

    SSD가 여분으로 있다면 L2ARC(Level 2 ARC, 2차 읽기 캐시)와 SLOG(Separate Intent Log, 분리 의도 로그)로 활용할 수 있습니다.

    # L2ARC 추가 (읽기 캐시, SSD 권장)
zpool add datapool cache /dev/disk/by-id/ssd-캐시디스크_시리얼

# SLOG/ZIL 추가 (쓰기 캐시, 저지연 SSD 권장)
# 미러 구성을 강력히 권장 (SLOG 손실 시 데이터 손실 위험)
zpool add datapool log mirror \
  /dev/disk/by-id/ssd-slog1_시리얼 \
  /dev/disk/by-id/ssd-slog2_시리얼

# 현재 풀 구성 확인
zpool status datapool

    💡 팁: SLOG는 반드시 미러로 구성하세요. SLOG 디스크가 고장나면 최근 쓰기 데이터가 날아갈 수 있거든요. 비용이 두 배가 되더라도 미러가 맞습니다.

    ZFS 데이터셋 최적화 설정

    Proxmox에서 VM 이미지를 저장하는 데이터셋은 별도로 최적화해 주는 게 좋아요. VM 워크로드 특성에 맞게요.

    # VM 이미지용 데이터셋 최적화
# recordsize를 VM 디스크 블록 크기에 맞게 조정
zfs set recordsize=64K datapool/images

# 또는 데이터베이스 VM이 많다면
zfs set recordsize=16K datapool/images

# 압축 설정 (lz4가 성능/압축률 균형이 좋음)
zfs set compression=lz4 datapool

# 현재 데이터셋 속성 확인
zfs get all datapool | grep -E '(compression|recordsize|atime|sync)'

# sync 설정 (주의: disabled는 데이터 손실 위험 있음)
# VM이 많고 성능이 중요하다면 standard 유지 권장
zfs set sync=standard datapool/images

    Scrub(스크럽, 데이터 무결성 검사) 자동화

    ZFS의 핵심 기능 중 하나가 스크럽이에요. 모든 데이터 블록을 읽어서 체크섬을 검증하는 작업인데, 주기적으로 해줘야 Silent Data Corruption을 조기에 발견할 수 있습니다.

    # 수동으로 스크럽 실행
zpool scrub datapool

# 스크럽 진행 상황 확인
zpool status datapool

# 자동 스크럽 설정 (Proxmox는 기본적으로 월 1회 cron 설정됨)
# /etc/cron.d/zfsutils-linux 확인
cat /etc/cron.d/zfsutils-linux

# 직접 cron 설정 (매월 1일 새벽 2시)
crontab -e
# 아래 내용 추가:
# 0 2 1 * * /sbin/zpool scrub datapool

    ⚠️ 실제로 겪은 문제들과 해결법

    문제 1: VM 성능이 생각보다 안 나온다

    ZFS를 처음 올렸을 때 “왜 이렇게 느리지?” 하는 경험을 많이들 하세요. 저도 그랬는데, 원인이 몇 가지 있더라고요.

    원인 및 해결책:

    1. ashift 설정 오류: zpool status -v로 확인. 이미 풀이 생성됐다면 재생성 외에는 방법이 없어요. 처음부터 ashift=12를 꼭 넣어주세요.
    2. ARC 부족: arcstat 명령으로 hit ratio 확인. 70% 이하면 ARC가 부족한 겁니다.
    3. recordsize 불일치: VM 워크로드에 따라 recordsize를 조정하세요. 랜덤 I/O가 많은 DB 워크로드는 작은 recordsize가 유리합니다.
    # ARC 히트율 확인
arcstat 1 5

# ZFS I/O 통계 모니터링
zpool iostat -v datapool 2

# 상세 ZFS 통계
zfs-stats -a

    문제 2: 디스크 오류 발견 시 대응

    어느 날 아침에 zpool status를 실행했더니 DEGRADED 상태가 뜨는 경험을 한 적이 있습니다. 심장이 쿵 내려앉더라고요. 근데 ZFS가 있으니까 침착하게 대응할 수 있었어요.

    # 풀 상태 확인
zpool status -v datapool

# 오류 난 디스크 교체 후 resilvering(데이터 재동기화) 시작
# 1. 오류 디스크 오프라인 처리
zpool offline datapool /dev/disk/by-id/문제디스크_시리얼

# 2. 물리적으로 디스크 교체 후 새 디스크 지정
zpool replace datapool \
  /dev/disk/by-id/문제디스크_시리얼 \
  /dev/disk/by-id/새디스크_시리얼

# 3. resilvering 진행 상황 확인
zpool status datapool

    문제 3: 스냅샷이 쌓여서 공간이 부족해진다

    Proxmox 자동 백업 설정해 놓으면 스냅샷이 계속 쌓입니다. 어느 순간 “왜 공간이 이렇게 없지?” 하고 보면 스냅샷이 수십 개 쌓여 있는 경우가 있어요.

    # 스냅샷 목록 확인
zfs list -t snapshot -o name,used,creation | sort -k3

# 오래된 스냅샷 삭제
zfs destroy datapool/images/vm-100-disk-0@2024-01-01

# 특정 패턴의 스냅샷 일괄 삭제 (주의해서 사용!)
zfs list -t snapshot -H -o name | grep 'vm-100' | xargs -n1 zfs destroy

# Proxmox 백업 보존 정책 설정 (GUI 권장)
# Datacenter > Backup > 해당 작업 편집 > Keep 설정
    ZFS ARC 히트율 및 스토리지 I/O 성능 모니터링 대시보드

    ▲ ZFS ARC 히트율과 풀 I/O 성능 모니터링 — arcstat 및 zpool iostat 출력 결과를 시각화한 예시입니다. 히트율 80% 이상을 목표로 합니다.

    ZFS 스토리지 상태 검증하기

    일상적인 헬스체크 루틴

    이 명령어들은 저도 주기적으로 확인하는 것들이에요. 습관처럼 만들어 두면 정말 든든합니다.

    # 전체 풀 상태 한눈에 보기
zpool status

# 풀 사용량 확인
zpool list

# 데이터셋별 사용량 (스냅샷 포함)
zfs list -t all -o name,used,avail,refer,mountpoint

# 압축 효율 확인
zfs get compressratio datapool

# 전체 ZFS 이벤트 로그 확인
zpool events -v | tail -50

    성능 벤치마크 기준점 잡기

    최적화 전후를 비교하려면 기준점이 있어야 하죠. fio(Flexible I/O Tester)로 간단히 측정해 볼 수 있습니다.

    # fio 설치
apt install fio

# 순차 쓰기 테스트
fio --name=seqwrite \
  --filename=/datapool/testfile \
  --rw=write \
  --bs=1M \
  --size=4G \
  --numjobs=1 \
  --ioengine=libaio \
  --direct=1 \
  --group_reporting

# 랜덤 읽기 테스트 (4K 블록)
fio --name=randread \
  --filename=/datapool/testfile \
  --rw=randread \
  --bs=4K \
  --size=4G \
  --numjobs=4 \
  --ioengine=libaio \
  --direct=1 \
  --group_reporting

# 테스트 파일 정리
rm /datapool/testfile

    정리: ZFS 최적화 체크리스트

    Proxmox VE ZFS 최적화 핵심 설정 체크리스트 요약 인포그래픽

    ▲ Proxmox VE ZFS 최적화 핵심 설정 요약 — 풀 생성부터 ARC 튜닝, 스크럽 자동화까지 단계별 체크리스트입니다.

    지금까지 다룬 내용을 정리해 보겠습니다. 처음엔 복잡해 보여도, 하나씩 따라가면 충분히 할 수 있어요.

    필수 설정 체크리스트

    • ✅ ashift=12 — 풀 생성 시 반드시 지정
    • ✅ compression=lz4 — 성능 영향 없이 공간 절약
    • ✅ atime=off — 불필요한 I/O 제거
    • ✅ ARC 크기 제한 — VM 메모리와 균형 맞추기
    • ✅ 정기 스크럽 — 월 1회 이상 실행
    • ✅ 디스크 ID 방식 사용 — 재부팅 후 안정성 확보
    • ✅ 스냅샷 보존 정책 — 디스크 공간 관리
    • ✅ SLOG 미러 구성 — SLOG 사용 시 필수

    자주 묻는 질문 (FAQ)

    Q. ZFS는 ECC 메모리가 없으면 위험한가요?
    A. ECC 메모리가 없어도 ZFS를 쓸 수 있습니다. 다만 메모리 오류로 인한 데이터 손상 가능성이 이론적으로 존재해요. 홈랩 수준에서는 크게 걱정 안 해도 되지만, 프로덕션 환경이라면 ECC를 권장합니다.

    Q. ZFS 풀 크기를 나중에 늘릴 수 있나요?
    A. 네, 가능합니다. 미러 풀은 동일한 크기의 디스크 쌍을 추가해서 확장할 수 있어요. RAID-Z는 같은 VDEV(가상 디바이스) 내에서 디스크 추가가 어렵고, 새 VDEV를 추가하는 방식으로 확장합니다.

    Q. 압축을 켜면 CPU 사용률이 많이 올라가나요?
    A. lz4 압축은 CPU 영향이 매우 적습니다. 요즘 프로세서에서는 거의 체감이 안 될 정도예요. 오히려 I/O 양이 줄어서 전체 성능이 올라가는 경우도 있어요.

    마무리하며

    Proxmox VE ZFS 조합은 한번 제대로 세팅해 두면 정말 든든합니다. 디스크 하나가 죽어도 침착하게 교체하고 resilvering 기다리면 되고, 실수로 VM 날려도 스냅샷에서 복구하면 되고. 처음 세팅이 좀 복잡해 보이지만, 그 이후의 편안함은 진짜 다르더라고요.

    물론 ZFS가 만능은 아닙니다. 메모리를 많이 먹고, 설정이 복잡하고, 한번 만든 풀 구조를 바꾸기 어렵다는 단점도 있어요. 그래도 데이터 안정성과 스냅샷 편의성을 생각하면, 홈랩에서 ZFS를 선택하지 않을 이유가 없다고 생각합니다.

    다음 글에서는 Proxmox VE의 백업 자동화와 원격 ZFS 복제(Replication)를 다뤄볼 예정이에요. 오늘 설정한 ZFS 풀을 활용해서 다른 서버로 데이터를 자동으로 복제하는 방법인데, 이것도 꽤 유용하더라고요. 기대해 주세요!

    궁금한 점이나 다른 삽질 경험이 있으시면 댓글로 공유해 주세요. 같이 해결해 봐요!