13년차의 서버실

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

[태그:] 가상화

  • [홈랩] 홈서버 마이그레이션, Intel NUC로 저전력 전환하기

    [홈랩] 홈서버 마이그레이션, Intel NUC로 저전력 전환하기

    [홈랩] 홈서버 마이그레이션, Intel NUC로 저전력 전환하기

    구형 홈서버를 오래 돌리신 분들이라면 한 번쯤 비슷한 고민을 하셨을 겁니다. 성능은 아직 버틸 만한데, 전기요금이 은근히 신경 쓰이고 팬 소음도 있고, 무엇보다 24시간 켜두는 장비라서 발열이 계속 마음에 걸리거든요. 저도 그래서 한동안 구형 데스크톱 기반 홈서버를 쓰다가 홈서버 마이그레이션을 결심했습니다. 결론부터 말씀드리면, Intel NUC 같은 소형 PC로 옮기면서 체감상 운영 부담이 꽤 줄었습니다. 드디어 됐다 싶더라고요. 이번 글에서는 제가 실제로 진행했던 흐름을 기준으로, 저전력 홈랩으로 넘어갈 때 어떤 기준으로 장비를 보고, 서버 이전을 어떻게 준비하면 덜 고생하는지 정리해보겠습니다.

    특히 가상화 환경으로 Proxmox VE를 쓰고 계신 분들, 혹은 ASUS PN 같은 미니 PC와 Intel NUC 사이에서 고민하는 분들께 도움이 될 만한 포인트를 담았습니다. 저도 처음엔 "그냥 백업하고 복원하면 끝 아닌가?" 싶었는데, 막상 해보니 네트워크 브리지, 스토리지 경로, 부팅 방식에서 삽질 좀 했습니다 ㅎㅎ

    홈서버 마이그레이션 구조를 보여주는 Intel NUC 기반 저전력 홈랩 아키텍처 이미지

    구형 타워형 홈서버에서 소형 Intel NUC 기반 가상화 서버로 이전하는 구조를 한눈에 보여주는 이미지입니다.

    왜 지금 홈서버 마이그레이션을 고민하게 되는가

    홈랩(Home Lab, 개인 실험용 서버 환경)을 오래 운영하다 보면 초기에는 "남는 부품으로 만든 서버"가 꽤 합리적으로 느껴집니다. 저도 그랬습니다. 문제는 시간이 지나면서 운영 기준이 바뀐다는 점입니다. 단순히 서비스가 돌아가느냐보다, 얼마나 조용한가, 얼마나 덜 먹는가, 장애가 났을 때 얼마나 빨리 복구되는가가 더 중요해지더라고요.

    • 전력 효율: 24시간 켜두는 장비는 누적 전력 차이가 큽니다.
    • 소음과 발열: 집 안에 두는 장비는 특히 체감이 큽니다.
    • 공간 절약: 미니 PC는 책상이나 선반 배치가 훨씬 편합니다.
    • 운영 단순화: 오래된 디스크와 팬이 많을수록 장애 포인트도 늘어납니다.

    여기서 중요한 포인트! 무조건 작은 장비가 정답은 아닙니다. 다만 홈서버에 올리는 워크로드가 컨테이너 몇 개, VM 몇 개, NAS 보조 역할 정도라면 Intel NUC나 ASUS PN 계열이 꽤 현실적인 선택지가 됩니다.

    Intel NUC와 ASUS PN, 저전력 홈랩 기준으로 어떻게 볼까

    쉽게 말해 두 제품군 모두 작고 조용한 x86 미니 PC라는 공통점이 있습니다. 홈랩 관점에서는 제조사보다도 다음 기준이 더 중요했습니다. 제가 직접 써보니 브랜드보다 실제 확장성과 발열 특성이 더 크게 체감되더라고요.

    항목 Intel NUC ASUS PN
    포지션 대표적인 초소형 PC 라인업 비슷한 목적의 미니 PC 라인업
    홈랩 적합성 작고 배치가 쉬움 작고 확장 구성이 다양한 편
    고려 포인트 발열, 저장장치 구성, NIC 개수 발열, BIOS 옵션, 저장장치 구성
    추천 대상 검증된 소형 서버 느낌을 원하는 경우 동급 대안도 함께 비교하고 싶은 경우

    저는 최종적으로 NUC 계열로 정리했는데, 이유는 단순했습니다. 크기가 작고, 제가 돌리려는 서비스 규모에 비해 충분했고, Proxmox 마이그레이션을 하기에도 구조가 복잡하지 않았거든요. 물론 2.5GbE나 다중 NIC가 꼭 필요한 분은 장비 선택 기준이 달라질 수 있습니다. 이 부분은 본인 홈랩의 네트워크 구조를 먼저 그려보시는 게 좋습니다.

    마이그레이션 전에 꼭 정리해야 할 체크리스트

    이 단계 건너뛰면 거의 100% 다시 돌아오게 됩니다. 저도 처음엔 대충 메모만 하고 시작했다가, 어떤 VM이 어떤 볼륨에 붙어 있었는지 헷갈려서 시간을 꽤 썼습니다.

    1. 서비스 목록 작성: VM, LXC, Docker, NAS 공유, VPN, 모니터링을 전부 적습니다.
    2. 스토리지 구조 확인: 로컬 디스크인지, 외장 스토리지인지, ZFS인지, LVM-Thin인지 확인합니다.
    3. 네트워크 설정 백업: 브리지, VLAN, 고정 IP, DHCP 예약 여부를 정리합니다.
    4. 복구 순서 설계: DNS, VPN, 리버스 프록시(Reverse Proxy, 역방향 프록시)처럼 의존성이 큰 서비스부터 복구합니다.
    5. 다운타임 창 확보: 야간에 조용히 하려다가 더 꼬일 수 있습니다. 집중 가능한 시간을 잡는 게 낫습니다.

    제가 추천하는 방식은 아주 단순합니다. 먼저 "없어도 되는 것"과 "끊기면 바로 티 나는 것"을 나누세요. 예를 들어 테스트용 VM은 나중에 옮겨도 되지만, 홈 어시스턴트(Home Assistant, 홈 자동화 플랫폼)나 DNS가 물려 있으면 우선순위가 올라갑니다.

    Proxmox 마이그레이션 실전: 제가 했던 순서

    이번 섹션은 서버 이전에서 가장 핵심입니다. 제 경우에는 기존 장비와 새 Intel NUC를 잠시 동시에 켜두고, 백업 후 복원하는 방식으로 진행했습니다. 클러스터(Cluster, 다중 노드 묶음)를 억지로 만드는 방식도 가능하지만, 홈랩에서는 오히려 단순한 백업/복원 흐름이 덜 꼬이는 경우가 많습니다.

    1. 기존 Proxmox 설정과 게스트 목록 확인

    pveversion -v
    qm list
    pct list
    lsblk
    ip a
    cat /etc/network/interfaces

    이 출력에서 확인할 것은 세 가지입니다. 어떤 VM과 LXC가 있는지, 어떤 디스크가 붙었는지, 그리고 브리지 구성이 어떻게 되어 있는지입니다. 특히 vmbr0 같은 브리지 이름이 바뀌면 복원 후 네트워크가 바로 안 붙을 수 있습니다.

    2. VM과 LXC 백업

    mkdir -p /mnt/backup
    vzdump 101 --mode stop --compress zstd --dumpdir /mnt/backup
    vzdump 102 --mode snapshot --compress zstd --dumpdir /mnt/backup
    vzdump 201 --mode snapshot --compress zstd --dumpdir /mnt/backup

    여기서 vzdump는 Proxmox 기본 백업 도구입니다. 서비스 중단이 괜찮은 VM은 stop 모드로, 가능한 중단을 줄이고 싶다면 snapshot 모드를 고려할 수 있습니다. 다만 스토리지 타입에 따라 동작 차이가 있으니 사전에 확인은 필요합니다.

    Proxmox 마이그레이션 과정에서 VM과 LXC가 Intel NUC로 이전되는 홈서버 마이그레이션 이미지

    Proxmox 환경에서 기존 노드의 VM/LXC를 백업한 뒤 새 Intel NUC 노드로 복원하는 절차를 설명하는 이미지입니다.

    3. 백업 파일을 새 서버로 전달

    rsync -avh --progress /mnt/backup/ [email protected]:/var/lib/vz/dump/

    저는 단순하게 rsync(알싱크, 파일 동기화 도구)로 옮겼습니다. 네트워크 속도가 느리다면 외장 SSD로 옮기는 쪽이 더 빠를 때도 있습니다. 홈랩에서는 이상하게 이론보다 물리 이동이 더 편한 경우가 종종 있더라고요.

    4. 새 Intel NUC에 Proxmox 설치 후 네트워크 기본 구성

    auto lo
    iface lo inet loopback
    
    auto eno1
    iface eno1 inet manual
    
    auto vmbr0
    iface vmbr0 inet static
        address 192.168.0.50/24
        gateway 192.168.0.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

    이 파일은 보통 /etc/network/interfaces에 들어갑니다. 실제 인터페이스 이름은 장비마다 다를 수 있으니 꼭 ip a로 확인하세요. 저도 예전 장비에선 enp3s0 비슷한 이름이었는데, NUC에서는 다르게 잡혀서 처음 부팅 후 네트워크가 안 붙었습니다. 이거 진짜 자주 나오는 함정입니다.

    5. 백업 복원

    qmrestore /var/lib/vz/dump/vzdump-qemu-101-*.zst 101
    qmrestore /var/lib/vz/dump/vzdump-qemu-102-*.zst 102
    pct restore 201 /var/lib/vz/dump/vzdump-lxc-201-*.tar.zst

    복원할 때는 VM ID 충돌 여부와 스토리지 타겟을 같이 보셔야 합니다. 예전 서버에서 쓰던 스토리지 이름과 새 서버 이름이 다르면 GUI에서 보정하거나 명령 옵션으로 맞춰줘야 합니다.

    Docker와 데이터 디렉터리 이전은 따로 챙기기

    Proxmox 안에서 Docker를 돌리고 있었다면, 사실상 핵심은 컨테이너 이미지보다 볼륨 데이터(volume data, 영속 데이터)입니다. 데이터베이스, 설정 파일, 미디어 메타데이터는 대부분 여기에 있거든요.

    docker ps
    docker compose ls
    tar -czf appdata-backup.tar.gz /opt/appdata
    scp appdata-backup.tar.gz [email protected]:/root/

    새 서버에서 경로를 맞춰 복원한 뒤, docker compose up -d로 다시 띄우는 식으로 정리하면 비교적 깔끔합니다. 만약 NFS(Network File System, 네트워크 파일 시스템)나 SMB 공유를 마운트해서 쓰고 있다면 마운트 지점이 동일한지도 확인하셔야 합니다.

    ⚠️ 실제로 겪었던 문제와 해결 방법

    이 부분은 좀 현실적으로 적어보겠습니다. 문서만 보면 마이그레이션이 매끈하게 끝날 것 같지만, 실제로는 작은 차이 때문에 막힐 때가 많습니다.

    1. 네트워크 브리지가 달라서 VM이 외부와 통신 안 됨

    복원은 됐는데 VM이 인터넷이 안 되는 경우가 있었습니다. 원인을 보니 VM 설정이 기존 브리지 이름을 참조하고 있더라고요. 해결은 단순했습니다. Proxmox GUI에서 NIC가 연결된 브리지를 vmbr0으로 다시 맞춰줬습니다.

    2. 스토리지 이름이 달라서 복원 중 경고 발생

    기존 서버는 local-lvm 구조였고, 새 장비는 local만 쓰는 식으로 간단하게 잡았더니 복원 경로가 안 맞았습니다. 이럴 땐 처음부터 스토리지 설계를 단순하게 하거나, 복원 전에 같은 이름으로 맞춰두는 편이 편합니다.

    3. BIOS에서 가상화 옵션 확인 안 해서 삽질

    Intel VT-x나 VT-d 같은 가상화 관련 옵션이 기본 활성화라고 생각했는데, 장비 상태에 따라 확인이 필요한 경우가 있습니다. 저도 처음엔 이게 뭔가 싶었는데, nested virtualization 같은 걸 건드릴 계획이면 BIOS 체크는 미리 해두는 게 좋습니다.

    4. USB 장치 패스스루(Passthrough, 장치 직접 연결) 재설정 필요

    홈 어시스턴트용 Zigbee 동글 같은 USB 장치를 쓰고 있었다면, 장비가 바뀌면서 버스 번호나 장치 경로가 달라질 수 있습니다. 이건 복원 후 바로 확인하셔야 합니다. 안 그러면 서비스는 살아 있는데 실제 장치 연동만 안 됩니다.

    서버 이전 중 브리지와 스토리지 문제를 점검하는 홈서버 마이그레이션 트러블슈팅 이미지

    마이그레이션 과정에서 자주 발생하는 브리지 설정 오류와 스토리지 경로 문제를 점검하는 장면을 보여주는 이미지입니다.

    검증: 마이그레이션 후 무엇을 확인해야 하나

    이제 다 옮겼다고 끝이 아닙니다. 저는 이 단계에서 꼭 체크리스트를 돌립니다. 특히 홈서버 마이그레이션은 "부팅됨"과 "운영 가능함"이 다르거든요.

    1. VM/LXC 부팅 확인: 자동 시작이 정상인지 봅니다.
    2. 네트워크 통신 확인: 내부 IP, 외부 DNS, 게이트웨이 연결을 확인합니다.
    3. 스토리지 마운트 확인: NAS, 외장 디스크, 백업 디렉터리를 점검합니다.
    4. 서비스 헬스체크: Nginx Proxy Manager, Home Assistant, Grafana 같은 주요 서비스에 접속합니다.
    5. 백업 재설정: 이전 서버 기준 경로가 남아 있지 않은지 확인합니다.
    ping -c 4 192.168.0.1
    ping -c 4 8.8.8.8
    systemctl status pveproxy
    qm list
    pct list
    df -h

    가능하면 모니터링도 함께 보세요. Grafana(그라파나, 시각화 도구)나 Prometheus(프로메테우스, 메트릭 수집 도구)를 쓰고 있다면 이전 전후의 자원 사용 패턴을 비교해보는 게 좋습니다. 수치를 과장해서 말하고 싶진 않지만, 체감상 발열과 소음 쪽은 확실히 관리가 쉬워졌습니다. 그리고 공간이 줄어드니 홈랩을 계속 유지할 마음도 더 생기더라고요. 그게 꽤 큽니다.

    Intel NUC 기반 저전력 홈랩에서 Proxmox가 정상 동작하는 홈서버 마이그레이션 결과 이미지

    새 Intel NUC 환경에서 Proxmox 대시보드와 주요 서비스가 정상 동작하는 결과를 시각적으로 보여주는 이미지입니다.

    마이그레이션 이후 운영 방식도 같이 바꾸면 더 편합니다

    저는 이번 저전력 홈랩 전환을 하면서 운영 습관도 같이 바꿨습니다. 예전에는 장비를 키워서 해결하려고 했는데, 지금은 구조를 단순하게 만드는 쪽이 훨씬 낫다고 생각합니다.

    • 역할 분리: 실험용 VM과 운영용 VM을 분리합니다.
    • 백업 자동화: 수동 백업은 결국 밀리기 쉽습니다.
    • 문서화: IP, 계정, 마운트 경로, 복원 순서를 적어둡니다.
    • 전력보다 복구성 우선: 무조건 저전력보다, 장애 시 빨리 되살릴 수 있어야 합니다.

    혹시 이런 경험 있으신가요? 장비를 바꿨는데 성능보다 정리된 구조에서 오는 편안함이 더 크게 느껴지는 경우요. 저는 이번에 그걸 많이 느꼈습니다. 특히 홈랩은 취미이기도 하지만, 실제 운영 감각을 연습하는 공간이기도 해서, 작고 단순한 구조가 유지보수에는 정말 큰 장점이 됩니다.

    정리: 구형 홈서버에서 Intel NUC로 옮길 때 핵심만 다시 보면

    • 장비 선택: Intel NUC와 ASUS PN 모두 괜찮지만, NIC 수와 저장장치 구성이 우선입니다.
    • 이전 방식: 홈랩에서는 복잡한 실시간 이전보다 백업/복원 방식이 실수 관리에 유리합니다.
    • 체크 포인트: 브리지 이름, 스토리지 경로, USB 패스스루를 꼭 확인합니다.
    • 운영 관점: 저전력도 중요하지만, 문서화와 복구성이 더 오래 갑니다.

    제가 직접 해보니 홈서버 마이그레이션은 장비 교체 작업이라기보다, 홈랩 구조를 다시 설계하는 과정에 더 가깝습니다. 처음엔 좀 번거롭지만 한 번 정리해두면 이후가 정말 편합니다. 다음 글에서는 Proxmox 백업 자동화와 외부 스토리지를 붙여서 운영 안정성을 높이는 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 네트워크 분리나 리버스 프록시 구성이 있다면 함께 맞춰보시면 더 깔끔하게 정리될 겁니다.

    구형 홈서버와 Intel NUC 저전력 홈랩을 비교한 홈서버 마이그레이션 요약 이미지

    마이그레이션 전후의 공간, 소음, 운영 복잡도 차이를 비교해 보여주는 요약 이미지입니다.

  • [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 API 자동화: 홈랩 운영 비용 절감 및 효율 극대화 전략

    [Proxmox] Proxmox API 자동화: 홈랩 운영 비용 절감 및 효율 극대화 전략

    안녕하세요! 13년차 인프라 엔지니어 “13년차의 서버실”입니다. 홈랩을 운영하면서 가장 많이 듣는 이야기가 뭘까요? 아마 “전기세”와 “잦은 관리”일 겁니다. 저도 처음엔 멋모르고 이것저것 돌리다가 깜짝 놀랄 만한 전기요금 고지서를 받아보고 식은땀을 흘린 적이 한두 번이 아니거든요. 😅

    그래서 오늘은 이런 고민을 한방에 날려줄 수 있는 아주 유용한 방법을 소개해 드리려고 합니다. 바로 Proxmox API 자동화인데요. 이 녀석 덕분에 제 홈랩 운영 비용은 확 줄고, 관리 효율은 엄청나게 극대화되었더라고요. 제가 직접 삽질해가며 깨달은 노하우들을 아낌없이 풀어볼게요!

    혹시 여러분도 밤늦게까지 돌아가는 서버들 때문에 전기요금 걱정하고 계신가요? 아니면 매일매일 반복되는 가상 머신(VM, Virtual Machine)이나 컨테이너(CT, Container)의 켜고 끄는 작업을 자동화하고 싶진 않으신가요? 그렇다면 이 글이 큰 도움이 될 겁니다. 💡

    Proxmox API를 활용한 홈랩 자동화의 전체적인 아키텍처 개요 다이어그램

    그림 1: Proxmox API를 활용한 홈랩 자동화 전체 아키텍처 개요

    Proxmox API, 그게 뭔데요? (개념 설명)

    Proxmox VE(Virtual Environment)는 많은 분들이 홈랩에서 즐겨 사용하는 오픈소스 가상화 플랫폼이죠. 이 Proxmox는 단순히 웹 UI(User Interface)를 통해서만 관리할 수 있는 게 아니에요. API(Application Programming Interface, 애플리케이션 프로그래밍 인터페이스)라는 강력한 도구를 제공합니다. 쉽게 말해, 우리가 웹 UI에서 마우스 클릭으로 하던 모든 작업을 프로그래밍 코드(스크립트)로 대신 처리할 수 있도록 만들어주는 “통신 창구” 같은 거거든요.

    Proxmox API는 RESTful API(Representational State Transfer, REST 기반) 형태로 제공돼요. HTTP(Hypertext Transfer Protocol) 요청을 통해 Proxmox 서버와 데이터를 주고받고, 가상 머신 생성/삭제/시작/중지, 네트워크 설정 변경 등 거의 모든 관리 작업을 자동화할 수 있더라고요. 제가 처음 이 API를 접했을 때, “이거 진짜 물건이네!” 싶었거든요. 반복적인 작업을 스크립트 하나로 해결할 수 있다는 게 정말 매력적이었습니다.

    특히 홈랩 자동화에서는 이 Proxmox API가 빛을 발합니다. 예를 들어, 특정 시간에만 필요한 서버는 자동으로 켜지고 꺼지게 하거나, 자원 사용량이 많아지면 새로운 컨테이너를 자동으로 배포하는 등의 시나리오를 구현할 수 있죠. 운영 비용 절감과 효율성 극대화의 핵심 열쇠라고 할 수 있습니다. 🔑

    실전 구현: Proxmox API 토큰 발급 및 파이썬 스크립트 작성

    자, 이제 실전으로 들어가 볼까요? Proxmox API를 사용하려면 먼저 API 토큰(API Token)을 발급받아야 합니다. 이 토큰은 마치 비밀번호처럼, 스크립트가 Proxmox에 접근할 수 있는 권한을 부여하는 역할을 해요. 보안상 매우 중요하니 잘 관리해야 합니다!

    1단계: Proxmox API 토큰 발급

    Proxmox 웹 UI에 접속해서 Datacenter > Permissions > API Tokens 메뉴로 이동합니다. 여기서 “Add” 버튼을 눌러 새로운 API 토큰을 생성할 수 있어요. 사용자(User)는 보통 root@pam을 많이 쓰지만, 특정 권한만 필요한 경우 새로운 사용자를 만들어서 제한된 권한을 부여하는 것이 좋습니다. 저는 홈랩이라 root@pam으로 진행했거든요.

    1. 사용자 선택: root@pam 또는 적절한 사용자 선택.
    2. 토큰 ID 입력: 예: homelab-automation
    3. 권한 설정: 필요한 최소한의 권한만 부여하는 것이 보안에 좋습니다. VM/CT 제어가 목적이라면 VM.PowerMgmt, VM.Audit 정도면 충분해요. 저는 테스트를 위해 Administrator 권한을 부여했습니다만, 실제 운영에서는 절대 권장하지 않습니다!
    4. 생성: 토큰을 생성하면 Secret 값이 한 번만 표시됩니다. 이 값을 꼭 안전한 곳에 복사해 두세요. 나중에 다시 볼 수 없거든요! ⚠️
    Proxmox 웹 UI에서 API 토큰을 생성하는 과정과 설정 화면

    그림 2: Proxmox 웹 UI에서 API 토큰을 생성하는 화면

    2단계: 파이썬(Python) 환경 설정 및 라이브러리 설치

    저는 파이썬을 이용한 스크립트 작성을 선호합니다. 직관적이고 강력한 라이브러리가 많거든요. requests 라이브러리를 사용해서 HTTP 요청을 보낼 건데, 아직 설치 안 되어 있다면 다음 명령어로 설치해 주세요.

    pip install requests
    

    3단계: Proxmox API를 이용한 VM/CT 제어 스크립트 작성

    이제 본격적으로 스크립트를 작성해 봅시다. 이 스크립트는 Proxmox에 있는 특정 VM이나 CT를 시작하거나 종료하는 기능을 수행할 거예요. 저는 밤에는 미디어 서버 외에는 대부분 꺼두고, 낮에만 필요한 개발 환경 VM들을 켜두는 식으로 운영 비용을 절감하고 있거든요.

    import requests
    import json
    import os
    
    # Proxmox 설정 (환경 변수에서 불러오는 것을 권장합니다!)
    # PVE_HOST = os.getenv('PVE_HOST', 'your_proxmox_ip_or_hostname')
    # PVE_USER = os.getenv('PVE_USER', 'root@pam')
    # PVE_TOKEN_ID = os.getenv('PVE_TOKEN_ID', 'homelab-automation') # Proxmox API Token ID
    # PVE_TOKEN_SECRET = os.getenv('PVE_TOKEN_SECRET', 'YOUR_API_TOKEN_SECRET') # Proxmox API Token Secret
    
    # 보안을 위해 실제 환경에서는 환경 변수를 사용하세요.
    # 예: export PVE_HOST='192.168.1.100'
    # 예: export PVE_USER='root@pam'
    # 예: export PVE_TOKEN_ID='homelab-automation'
    # 예: export PVE_TOKEN_SECRET='YOUR_API_TOKEN_SECRET'
    
    PVE_HOST = '192.168.1.100' # 여러분의 Proxmox IP 또는 호스트 이름
    PVE_USER = 'root@pam'
    PVE_TOKEN_ID = 'homelab-automation' # 발급받은 API 토큰 ID
    PVE_TOKEN_SECRET = 'YOUR_API_TOKEN_SECRET' # 발급받은 API 토큰 Secret
    
    # SSL 인증서 검증 비활성화 (개발/테스트 용도로만 사용하세요! 실제 운영 환경에서는 CA 인증서 설정 권장)
    VERIFY_SSL = False 
    
    def proxmox_api_call(method, path, data=None):
        url = f"https://{PVE_HOST}:8006/api2/json/{path}"
        headers = {
            "Authorization": f"PVEAPIToken={PVE_USER}!{PVE_TOKEN_ID}={PVE_TOKEN_SECRET}"
        }
        
        try:
            if method == 'GET':
                response = requests.get(url, headers=headers, verify=VERIFY_SSL)
            elif method == 'POST':
                response = requests.post(url, headers=headers, json=data, verify=VERIFY_SSL)
            elif method == 'PUT':
                response = requests.put(url, headers=headers, json=data, verify=VERIFY_SSL)
            elif method == 'DELETE':
                response = requests.delete(url, headers=headers, verify=VERIFY_SSL)
            else:
                raise ValueError(f"Unsupported HTTP method: {method}")
    
            response.raise_for_status() # HTTP 오류 발생 시 예외 발생
            return response.json()
        except requests.exceptions.RequestException as e:
            print(f"API 호출 중 오류 발생: {e}")
            if hasattr(e, 'response') and e.response is not None:
                print(f"응답 본문: {e.response.text}")
            return None
    
    def get_vm_status(node, vmid):
        path = f"nodes/{node}/qemu/{vmid}/status/current"
        result = proxmox_api_call('GET', path)
        if result and 'data' in result:
            return result['data']['status']
        return "unknown"
    
    def start_vm(node, vmid):
        path = f"nodes/{node}/qemu/{vmid}/status/start"
        print(f"VM {vmid} 시작 중...")
        return proxmox_api_call('POST', path)
    
    def stop_vm(node, vmid):
        path = f"nodes/{node}/qemu/{vmid}/status/stop"
        print(f"VM {vmid} 종료 중...")
        return proxmox_api_call('POST', path)
    
    def get_lxc_status(node, ctid):
        path = f"nodes/{node}/lxc/{ctid}/status/current"
        result = proxmox_api_call('GET', path)
        if result and 'data' in result:
            return result['data']['status']
        return "unknown"
    
    def start_lxc(node, ctid):
        path = f"nodes/{node}/lxc/{ctid}/status/start"
        print(f"CT {ctid} 시작 중...")
        return proxmox_api_call('POST', path)
    
    def stop_lxc(node, ctid):
        path = f"nodes/{node}/lxc/{ctid}/status/stop"
        print(f"CT {ctid} 종료 중...")
        return proxmox_api_call('POST', path)
    
    if __name__ == "__main__":
        node_name = 'pve' # Proxmox 노드 이름 (예: pve, server01 등)
    
        # VM 제어 예시
        my_vm_id = 100 # 제어할 VM의 ID
        print(f"VM {my_vm_id} 현재 상태: {get_vm_status(node_name, my_vm_id)}")
        
        # VM 시작
        # if get_vm_status(node_name, my_vm_id) == 'stopped':
        #     start_vm(node_name, my_vm_id)
        # else:
        #     print(f"VM {my_vm_id}는 이미 실행 중입니다.")
    
        # VM 종료 (주의: 강제 종료될 수 있으니 신중하게 사용하세요!)
        # if get_vm_status(node_name, my_vm_id) == 'running':
        #     stop_vm(node_name, my_vm_id)
        # else:
        #     print(f"VM {my_vm_id}는 이미 종료되어 있습니다.")
    
        # CT 제어 예시
        my_ct_id = 101 # 제어할 CT의 ID
        print(f"CT {my_ct_id} 현재 상태: {get_lxc_status(node_name, my_ct_id)}")
    
        # CT 시작
        # if get_lxc_status(node_name, my_ct_id) == 'stopped':
        #     start_lxc(node_name, my_ct_id)
        # else:
        #     print(f"CT {my_ct_id}는 이미 실행 중입니다.")
    
        # CT 종료
        # if get_lxc_status(node_name, my_ct_id) == 'running':
        #     stop_lxc(node_name, my_ct_id)
        # else:
        #     print(f"CT {my_ct_id}는 이미 종료되어 있습니다.")
    

    위 스크립트에서 PVE_HOST, PVE_TOKEN_ID, PVE_TOKEN_SECRET 부분은 여러분의 환경에 맞게 수정해야 합니다. 특히 PVE_TOKEN_SECRET는 절대로 외부에 노출되지 않도록 주의하세요! 저는 테스트를 위해 코드에 직접 넣었지만, 실제 운영에서는 환경 변수(Environment Variables)를 사용하거나 별도의 설정 파일에 저장해서 사용하는 것이 보안상 훨씬 안전합니다. ⚠️

    그리고 VERIFY_SSL = False 부분은 개발 및 테스트 편의를 위한 것이며, 실제 운영 환경에서는 Proxmox 서버의 CA(Certificate Authority) 인증서를 신뢰하도록 설정하여 True로 사용하는 것을 강력히 권장합니다. 보안은 언제나 최우선이거든요!

    주의사항 및 트러블슈팅: 삽질 경험 공유 ⚠️

    제가 이 Proxmox API 자동화를 처음 시도하면서 겪었던 몇 가지 삽질 경험과 주의사항을 공유해 드릴게요. 여러분은 저처럼 헤매지 마시라고요! ㅎㅎ

    • 권한 문제 (Permission Denied): API 토큰을 만들 때 권한 설정을 너무 제한적으로 하면 원하는 작업이 안 될 수 있어요. 예를 들어, VM을 시작해야 하는데 VM.PowerMgmt 권한이 없다면 당연히 에러가 나더라고요. 에러 메시지에 Permission denied가 보인다면, API 토큰의 권한 설정을 다시 확인해 보세요. 저는 초반에 이걸 제대로 안 봐서 한참을 헤맸었습니다.
    • SSL 인증서 문제 (SSL Certificate Verification Failed): 위 스크립트에서 VERIFY_SSL = False로 설정했지만, 실제 운영 환경에서는 이렇게 하면 보안에 취약해집니다. Proxmox 서버가 자체 서명(Self-Signed) 인증서를 사용하는 경우가 많은데, 이럴 때는 해당 인증서를 파이썬 스크립트가 실행되는 시스템에 신뢰하도록 추가하거나, requests 라이브러리에서 인증서 경로를 명시해 줘야 합니다. 이게 귀찮다고 그냥 끄면 중간자 공격(Man-in-the-Middle Attack)에 노출될 위험이 있어요!
    • 네트워크 연결 문제: Proxmox 호스트와 스크립트가 실행되는 서버 간의 네트워크 연결이 불안정하거나 방화벽(Firewall)에서 8006 포트가 막혀있으면 API 호출이 실패합니다. telnet your_proxmox_ip 8006 명령어로 연결 테스트를 해보는 것이 좋습니다.
    • POST/GET 메서드 혼동: API는 작업의 종류에 따라 HTTP 메서드(Method)가 다릅니다. 정보 조회는 GET, 상태 변경이나 생성은 POST/PUT, 삭제는 DELETE를 사용하죠. 이걸 잘못 쓰면 엉뚱한 에러가 발생합니다. Proxmox API 문서(Proxmox API Documentation)를 꼼꼼히 확인하는 게 중요합니다.

    이런 문제들을 해결하면서 Proxmox API 자동화에 대한 이해도가 훨씬 깊어졌어요. 역시 삽질은 최고의 스승이더라고요! 😂

    검증 및 결과: 효율적인 홈랩 운영의 시작 🎉

    스크립트가 잘 작동하는지 확인하는 건 필수겠죠? 저는 보통 crontab(크론탭) 같은 스케줄러에 스크립트를 등록해서 특정 시간에 자동으로 실행되도록 합니다. 예를 들어, 평일 업무 시간(오전 9시 ~ 오후 6시)에만 개발 VM을 켜두고, 그 외 시간에는 자동으로 꺼지게 하는 거죠.

    # 매일 오전 9시에 VM 100번과 CT 101번 시작
    0 9 * * 1-5 python3 /path/to/your_script.py start_work_vms
    
    # 매일 오후 6시에 VM 100번과 CT 101번 종료
    0 18 * * 1-5 python3 /path/to/your_script.py stop_work_vms
    

    이렇게 설정해두면, 제가 일일이 신경 쓸 필요 없이 Proxmox가 알아서 척척 움직입니다. 덕분에 전기세도 확실히 줄어들고요, 불필요하게 자원을 낭비하는 일도 없어졌습니다. 홈랩 운영 비용이 절감되는 걸 눈으로 직접 확인하니 정말 뿌듯하더라고요!

    Proxmox 웹 UI의 Tasks 로그를 통해서도 스크립트가 성공적으로 실행되었는지 확인할 수 있습니다. start VM 100, stop CT 101 같은 메시지가 보인다면 성공입니다. ✅

    Proxmox의 작업 로그와 자동화 후 전력 사용량 변화를 보여주는 모니터링 대시보드

    그림 3: Proxmox의 Task 로그와 전력 사용량 모니터링 대시보드 예시

    마무리: Proxmox API 자동화, 선택이 아닌 필수!

    오늘은 Proxmox API 자동화를 통해 홈랩 운영 비용을 절감하고 관리 효율을 극대화하는 전략에 대해 이야기해 봤습니다. 13년차 인프라 엔지니어로서, 이런 자동화는 이제 선택이 아닌 필수가 되었다고 생각합니다. 특히나 저처럼 홈랩을 운영하면서 다양한 실험을 하는 분들에게는 더더욱 그렇죠.

    Proxmox API는 단순히 VM/CT를 켜고 끄는 것을 넘어, 스냅샷(Snapshot) 관리, 백업(Backup) 자동화, 네트워크 설정 변경 등 무궁무진한 가능성을 제공합니다. 여러분의 창의적인 아이디어를 더하면 훨씬 더 강력한 홈랩 자동화 시스템을 구축할 수 있을 거예요.

    물론 처음에는 API 문서 찾아보고, 스크립트 짜고, 에러 잡아가면서 좀 힘들 수도 있습니다. 저도 그랬거든요! 하지만 한 번 구축해두면 그 편리함과 효율성은 정말 상상 이상이더라고요. 운영 비용 절감 효과는 덤이고요. 😉

    이 글이 여러분의 Proxmox API 자동화 여정에 작은 등불이 되었으면 좋겠습니다. 다음번에는 Proxmox API를 활용한 동적 자원 할당이나 모니터링 연동에 대해 다뤄볼까 합니다. 기대해 주세요! 👋

    수동 홈랩 관리와 Proxmox API 자동화의 장단점을 비교하는 요약 인포그래픽

    그림 4: 수동 관리와 Proxmox API 자동화 비교 요약 인포그래픽

  • [홈랩] Proxmox OMV 연동: NAS 구축을 위한 최적의 조합 분석

    [홈랩] Proxmox OMV 연동: NAS 구축을 위한 최적의 조합 분석

    [홈랩] Proxmox OMV 연동: NAS 구축을 위한 최적의 조합 분석

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 홈랩을 운영하면서 정말 많은 분들이 고민하고 또 구축하려는 주제, 바로 NAS(Network Attached Storage)에 대해 이야기해보려 합니다. 특히 Proxmox(프록스목스) VE 환경에서 OpenMediaVault(OMV, 오픈미디어볼트)를 어떻게 연동해서 안정적이고 효율적인 NAS를 구축할 수 있을지에 대한 저의 경험과 삽질기를 솔직하게 공유해 드릴게요.

    혹시 여러분도 집에서 미디어 서버나 개인 파일 서버가 필요해서 NAS를 알아보고 계신가요? 시중에 완제품 NAS도 많지만, 직접 구축했을 때의 자유로움과 성능, 그리고 무엇보다 ‘내가 만들었다’는 뿌듯함은 비할 바가 못 되죠. 저도 처음엔 시놀로지나 헤놀로지 같은 걸 써볼까 하다가, 결국은 제가 가장 익숙한 Proxmox 위에 OMV를 올려서 사용하고 있습니다. 이게 진짜 편하더라고요!

    Proxmox VE 위 OMV NAS 구축 아키텍처 개요도

    1. 왜 Proxmox VE와 OpenMediaVault 조합인가요?

    제가 이 조합을 강력하게 추천하는 이유가 몇 가지 있습니다. 사실 처음에는 단순하게 생각했어요. 그냥 Proxmox VE(Virtual Environment)에 리눅스 깔고 Samba(삼바)나 NFS(네트워크 파일 시스템) 올리면 되는 거 아니야? 했었죠. 근데 막상 해보니 설정도 복잡하고, GUI(Graphical User Interface) 관리도 안 되고, Raid(레이드) 구성이나 사용자 권한 관리 같은 게 쉽지 않더라고요. 그래서 OpenMediaVault를 만나게 됐습니다.

    • Proxmox VE의 강력한 가상화 기능: Proxmox는 하이퍼바이저(Hypervisor)입니다. 즉, 하나의 물리 서버 위에 여러 개의 가상 머신(Virtual Machine, VM)이나 컨테이너(Container, LXC)를 동시에 돌릴 수 있게 해줘요. NAS 하나만 돌리기엔 아까운 고성능 서버를 다른 용도로도 활용할 수 있다는 거죠. 예를 들어, 저는 OMV 옆에 Plex 미디어 서버나 Docker 컨테이너들을 띄워서 쓰고 있거든요.
    • OpenMediaVault의 편리한 NAS 관리: OMV는 Debian(데비안) 기반의 무료 NAS 운영체제입니다. 웹 기반 GUI를 통해 파일 공유(SMB/CIFS, NFS, FTP), RAID 관리, 사용자/그룹 관리, 플러그인 확장(Docker, S.M.A.R.T. 등)을 아주 쉽게 할 수 있어요. 리눅스 명령어를 잘 몰라도 직관적으로 NAS를 운영할 수 있다는 게 큰 장점입니다. 제가 삽질 좀 해봤는데, OMV만큼 직관적인 NAS OS도 드물더라고요.
    • 분리된 환경으로 안정성 확보: OMV를 Proxmox VE의 VM으로 돌리면, NAS 시스템과 다른 서비스들이 서로 영향을 주지 않습니다. 혹시 OMV에 문제가 생겨도 Proxmox 호스트나 다른 VM에는 지장을 주지 않아요. 스냅샷(Snapshot)이나 백업(Backup) 관리도 훨씬 용이해지고요.

    2. Proxmox VE에서 OpenMediaVault VM 생성 및 디스크 패스쓰루

    자, 그럼 이제 본격적으로 Proxmox VE에 OMV VM을 만들고, 물리 디스크를 OMV VM으로 패스쓰루(PCI Passthrough)하는 방법을 알아볼게요. 이게 핵심이거든요! 그래야 OMV가 물리 디스크를 직접 인식하고 관리할 수 있습니다. 저는 이 과정에서 좀 헤맸는데, 여러분은 그러지 마시라고 자세히 알려드릴게요.

    2.1. OMV ISO 이미지 다운로드 및 Proxmox에 업로드

    먼저 OpenMediaVault 공식 웹사이트에서 최신 ISO 이미지를 다운로드합니다. 보통 .iso 파일 형태일 거예요. 저는 OMV 6 버전을 사용하고 있습니다.

    
    # Proxmox VE 웹 GUI 접속 후 '로컬 (pve)' -> 'ISO 이미지' -> '업로드' 버튼 클릭
    # 다운로드한 OMV ISO 파일을 선택하여 업로드
    

    이건 간단하니까 다들 아실 거라고 생각합니다. 웹 인터페이스가 진짜 편리하더라고요.

    2.2. OpenMediaVault 가상 머신(VM) 생성

    Proxmox VE 웹 GUI에서 우측 상단의 ‘VM 생성’ 버튼을 클릭하여 OMV VM을 만듭니다.

    1. General(일반): Name(이름)을 openmediavault 등으로 지정합니다.
    2. OS(운영체제): ‘ISO 이미지 사용’을 선택하고, 방금 업로드한 OMV ISO 파일을 선택합니다. Guest OS(게스트 OS)는 ‘Linux’ -> ‘5.x – 2.6 Kernel’로 설정하면 됩니다.
    3. System(시스템): 기본값으로 두거나, Qemu Agent(큐무 에이전트)를 설치할 예정이라면 ‘Qemu Agent’를 체크합니다.
    4. Disks(디스크): OMV OS가 설치될 가상 디스크를 생성합니다. 최소 10GB 이상으로 설정하는 것을 권장합니다. (Storage는 local-lvm 등 VM 디스크용 스토리지를 선택)
    5. CPU(프로세서): 코어 2개 이상, 소켓 1개 정도로 설정합니다.
    6. Memory(메모리): 최소 2GB 이상을 할당합니다. OMV가 생각보다 메모리를 좀 쓰는 편입니다.
    7. Network(네트워크): 기본값인 ‘Bridged Mode(브릿지 모드)’로 설정하여 OMV가 물리 네트워크에 직접 연결되도록 합니다.
    8. Confirm(확인): 설정을 확인하고 VM을 생성합니다. ‘Start after creation’은 체크 해제해 주세요. 바로 시작하지 않을 겁니다.

    2.3. 물리 디스크(HDD/SSD) 패스쓰루 설정 (매우 중요!)

    이제 OMV가 데이터 저장용으로 사용할 물리 디스크를 VM에 직접 연결해 줄 차례입니다. 이게 바로 Proxmox와 OMV 조합의 묘미라고 할 수 있죠. 저는 처음엔 가상 디스크로 만들어서 연결했었는데, 성능도 안 나오고 OMV에서 S.M.A.R.T. 정보도 제대로 못 읽는 문제가 발생했었어요. Host PCI Passthrough 대신 Host Disk Passthrough를 이용하는 방법을 추천합니다. 더 간단하고 안정적이거든요.

    1. VM 선택 및 ‘하드웨어’ 탭 이동: 생성한 openmediavault VM을 선택하고, 좌측 메뉴에서 ‘하드웨어’ 탭으로 이동합니다.
    2. ‘추가’ -> ‘하드 디스크’ 선택: ‘추가’ 버튼을 클릭하고 ‘하드 디스크’를 선택합니다.
    3. ‘물리적 디스크’ 선택: ‘스토리지’ 드롭다운 메뉴에서 (물리적 디스크)를 선택합니다. 그러면 Proxmox 호스트에 연결된 물리 디스크 목록이 나타납니다.
    4. 데이터 디스크 추가: OMV에서 사용할 데이터 저장용 디스크(예: /dev/sdb, /dev/sdc 등)를 선택하고 ‘추가’ 버튼을 클릭합니다. 주의할 점은 OMV OS가 설치될 디스크가 아닌, 데이터 저장용 디스크만 추가해야 합니다. 실수로 OS 디스크를 패스쓰루하면 큰일 납니다!
    5. 여러 디스크 추가: 필요한 만큼 이 과정을 반복하여 모든 데이터 디스크를 OMV VM에 추가합니다.

    이렇게 하면 OMV VM 내부에서는 마치 물리 서버에 직접 디스크가 연결된 것처럼 인식하게 됩니다. 드디어 됐다! 이 과정을 제대로 이해하고 나니 속이 다 시원하더라고요.

    Proxmox VE에서 물리 디스크를 VM에 패스쓰루하는 웹 GUI 화면

    Proxmox VE에서 물리 디스크를 VM에 패스쓰루하는 과정

    3. OpenMediaVault 설치 및 기본 설정

    이제 OMV VM을 시작하고 OMV를 설치할 차례입니다.

    1. VM 시작: 생성한 openmediavault VM을 선택하고 ‘시작’ 버튼을 클릭합니다.
    2. 콘솔 접속: ‘콘솔’ 탭으로 이동하여 OMV 설치 과정을 진행합니다. Debian 설치와 거의 동일합니다.
    3. 설치 언어, 키보드, 네트워크 설정: 한국어, 대한민국 등으로 설정하고, DHCP(동적 호스트 설정 규약)로 네트워크 설정을 진행합니다.
    4. 관리자 비밀번호 설정: root 계정의 비밀번호와 웹 관리자(admin) 계정의 비밀번호를 설정합니다. 이 비밀번호는 꼭 기억해두세요!
    5. OS 디스크 선택: 여기서 중요합니다! 아까 VM 생성 시 할당했던 10GB 이상의 가상 디스크(예: /dev/sda)를 선택하여 OMV OS를 설치합니다. 절대 패스쓰루한 데이터 디스크를 선택하면 안 됩니다!
    6. 설치 완료 및 재부팅: 설치가 완료되면 ISO 이미지를 VM에서 제거하고 재부팅합니다.

    3.1. OpenMediaVault 웹 GUI 접속 및 초기 설정

    재부팅 후 OMV VM의 IP 주소를 확인하여 웹 브라우저로 접속합니다. Proxmox 콘솔에 접속해서 ip a 명령어로 IP를 확인할 수 있습니다.

    
    # OMV 콘솔에서 IP 주소 확인
    ip a
    

    웹 브라우저에서 http://[OMV_VM_IP_주소]로 접속하여 admin 계정과 설정했던 비밀번호로 로그인합니다.

    로그인 후에는 다음 단계를 진행합니다.

    1. 파일 시스템 생성: ‘저장소’ -> ‘파일 시스템’ 메뉴로 이동합니다. 패스쓰루한 물리 디스크들이 보일 거예요. 각 디스크를 선택하여 ‘생성’ 버튼을 누르고, 원하는 파일 시스템(예: ext4)으로 포맷하고 마운트(Mount)합니다. 데이터가 있는 디스크라면 절대 포맷하면 안 됩니다! (저는 빈 디스크로 시작하는 걸 추천합니다.)
    2. RAID 관리 (선택 사항): 여러 디스크를 RAID로 묶고 싶다면 ‘저장소’ -> ‘RAID 관리’에서 설정할 수 있습니다. 저는 안정성을 위해 RAID 5를 선호합니다.
    3. 공유 폴더 생성: ‘접근 권한 관리’ -> ‘공유 폴더’에서 공유할 폴더를 생성하고, 파일 시스템과 경로를 지정합니다.
    4. 서비스 활성화: ‘서비스’ 메뉴에서 SMB/CIFS (Windows 파일 공유)나 NFS (Linux/macOS 파일 공유)를 활성화하고, 공유 폴더를 추가합니다.
    5. 사용자 및 그룹 관리: ‘접근 권한 관리’ -> ‘사용자’ 및 ‘그룹’에서 NAS에 접속할 사용자 계정을 생성하고 권한을 부여합니다.

    이 정도만 해도 기본적인 NAS 기능은 충분히 사용할 수 있어요. 처음엔 메뉴가 좀 많아 보이지만, 한 번 해보면 금방 익숙해질 거예요.

    OpenMediaVault 웹 관리 대시보드 스크린샷

    OpenMediaVault 웹 관리 대시보드 화면

    4. 주의사항 및 트러블슈팅: 제가 겪었던 삽질들 ⚠️

    홈랩 운영하면서 삽질은 필수라고 생각합니다. 저도 이 조합을 구축하면서 몇 가지 난관에 부딪혔었죠. 여러분은 이런 실수를 하지 마시라고 몇 가지 팁을 드립니다.

    • 디스크 패스쓰루 오류: 가끔 Proxmox에서 디스크를 패스쓰루했는데 OMV VM에서 인식이 안 되는 경우가 있었습니다. 이럴 때는 Proxmox 호스트에서 lsblk 명령어로 디스크가 제대로 인식되는지 확인하고, VM 설정에서 디스크 컨트롤러(예: SATA, VirtIO SCSI)를 바꿔보거나, Proxmox를 재부팅하면 해결되는 경우가 많더라고요. VirtIO SCSI가 성능상 더 좋지만, 가끔 특정 환경에서 문제가 생기기도 합니다.
    • OMV 업데이트 문제: OMV는 Debian 기반이라 apt update && apt upgrade 명령으로 업데이트합니다. 그런데 가끔 업데이트 중에 문제가 발생해서 부팅이 안 되거나 웹 GUI에 접속이 안 되는 경우가 있었어요. 이럴 땐 Proxmox의 스냅샷 기능이 빛을 발합니다. 업데이트 전에 VM 스냅샷을 하나 찍어두면, 문제가 생겨도 손쉽게 이전 상태로 되돌릴 수 있습니다. 💡 팁: 중요한 업데이트 전에는 꼭 스냅샷을 찍어두세요!
    • 네트워크 설정 문제: OMV VM의 IP 주소가 바뀌어서 접속이 안 되는 경우가 있습니다. Proxmox 콘솔이나 OMV 콘솔에서 ip a 명령으로 현재 IP 주소를 다시 확인하거나, OMV 설치 후 고정 IP(Static IP)로 설정하는 것을 권장합니다. 홈랩에서는 고정 IP가 훨씬 관리하기 편하거든요.
    • 성능 저하: VM에 할당된 CPU나 메모리가 너무 적으면 NAS 성능이 저하될 수 있습니다. 특히 여러 사용자가 동시에 접속하거나, 미디어 트랜스코딩(Transcoding) 같은 작업을 할 때는 충분한 리소스를 할당해 주는 것이 중요합니다.

    5. 검증 및 결과: 우리 집의 든든한 스토리지! 🎉

    모든 설정을 마치고 나면, 이제 여러분의 홈랩에 든든한 NAS가 완성됩니다! 저는 이렇게 구축한 OMV NAS를 다양하게 활용하고 있습니다.

    • 가족 사진/영상 백업: 스마트폰 사진을 자동으로 백업하도록 설정해서, 소중한 추억들을 안전하게 보관하고 있습니다.
    • 미디어 서버용 스토리지: Plex Media Server나 Jellyfin 같은 미디어 서버의 콘텐츠 저장소로 활용합니다. 대용량 영화 파일도 끊김 없이 스트리밍이 가능하더라고요.
    • 홈 자동화 데이터 저장: Home Assistant(홈 어시스턴트) 같은 홈 자동화 시스템의 로그나 백업 데이터를 저장하는 용도로도 사용합니다.
    • 개발 환경 공유 폴더: 제가 작업하는 개발 프로젝트 파일들을 공유 폴더에 넣어두고, 다른 VM이나 물리 PC에서 접근해서 사용하기도 합니다.

    실제로 써보니까 Proxmox VE와 OpenMediaVault의 조합은 유연성, 안정성, 그리고 관리 편의성까지 모두 잡을 수 있는 최적의 솔루션이라는 생각이 들었습니다. 특히 디스크 패스쓰루를 통해 물리 디스크를 직접 제어할 수 있다는 점이 가장 만족스러웠어요.

    Proxmox OMV NAS 구축의 장점들을 요약한 인포그래픽

    Proxmox OMV NAS 구축의 장점 요약

    6. 마무리하며: 다음 단계는 무엇일까요?

    오늘은 Proxmox VE 위에서 OpenMediaVault를 이용해 NAS를 구축하는 방법에 대해 자세히 알아봤습니다. 제가 직접 경험하며 얻은 노하우와 삽질기를 바탕으로 설명해 드렸는데, 도움이 되셨으면 좋겠네요. 처음엔 좀 복잡하게 느껴질 수도 있지만, 한 단계씩 따라오다 보면 분명 멋진 결과물을 얻으실 수 있을 거예요.

    이 조합은 단순히 NAS 기능만 제공하는 것을 넘어, 여러분의 홈랩을 한층 더 강력하게 만들어 줄 수 있는 기반이 될 겁니다. 다음 글에서는 이렇게 구축한 NAS를 활용하여 Docker(도커) 환경에서 Plex Media Server를 설치하거나, Tailscale(테일스케일)을 이용해 외부에서도 안전하게 NAS에 접속하는 방법에 대해 다뤄볼 예정입니다. 기대해주세요!

    궁금한 점이나 추가로 다루었으면 하는 내용이 있다면 언제든지 댓글로 남겨주세요. 저도 여러분의 경험을 공유받으며 배우고 싶습니다. 여기까지 읽어주셔서 감사합니다!

  • [HomeLabs] 저전력 미니 서버 3종 벤치마크: 홈랩 가상화 및 NAS 성능 실측 비교

    [HomeLabs] 저전력 미니 서버 3종 벤치마크: 홈랩 가상화 및 NAS 성능 실측 비교

    저전력 미니 서버 3종 벤치마크: 홈랩 가상화 및 NAS 성능 실측 비교

    안녕하세요, 13년차의 서버실 주인장입니다. 오늘은 많은 홈랩(Homelab) 동지들이 고민하는 주제, 바로 저전력 미니 서버(Low-power Mini Server)에 대한 이야기입니다. 개인적으로 여러 대의 서버를 돌리다 보니 전기요금 고지서 볼 때마다 한숨이 나오곤 했거든요. 그래서 언젠가부터 저전력 시스템에 대한 갈증이 컸습니다. 특히 최근 Intel N100 프로세서 기반의 미니PC들이 워낙 잘 나오면서, 이 작은 친구들이 과연 홈랩 환경에서 얼마나 쓸모 있을지 궁금해하는 분들이 많으시더라고요.

    저도 이 궁금증을 못 참고, 직접 몇 가지 유형의 미니 서버들을 들여와 제 홈랩 환경에서 가상화(Virtualization)와 NAS(Network Attached Storage) 용도로 실컷 굴려봤습니다. 이 글에서는 제가 경험한 세 가지 유형의 저전력 미니 서버들의 성능을 실측 데이터 기반으로 비교해보고, 어떤 용도에 적합할지 정말 솔직하게 알려드리려고 합니다. 삽질 경험도 아낌없이 공유할 테니, 여러분의 홈랩 구축에 조금이나마 도움이 되었으면 좋겠습니다!

    다양한 저전력 미니 서버들이 홈랩 환경에서 연결되어 있는 모습

    홈랩 환경에서 다양한 저전력 미니 서버들을 테스트하는 모습입니다. 작은 크기에도 불구하고 홈랩의 핵심 역할을 수행하죠.

    💡 저전력 미니 서버, 왜 중요할까요?

    홈랩을 운영하다 보면 가장 큰 고민 중 하나가 바로 전력 소비(Power Consumption)와 소음(Noise)입니다. 특히 24시간 켜두는 서버라면 이 두 가지 요소가 정말 중요하거든요. 예전에는 랙 서버나 고성능 워크스테이션을 활용하는 경우가 많았지만, 요즘은 소형 폼팩터(Small Form Factor, SFF)의 저전력 미니PC들이 가격 대비 성능(Price-to-Performance)이 너무나 훌륭하게 나오면서 홈랩의 대세로 자리 잡고 있습니다.

    쉽게 말해, 이 작은 친구들이 전기는 적게 먹으면서도 웬만한 가벼운 서버 작업이나 가상 머신(Virtual Machine, VM), 컨테이너(Container) 구동에는 전혀 문제가 없다는 거죠. 게다가 책상 위에 올려두어도 부담 없는 크기와 저소음은 덤이고요. 저는 주로 Proxmox VE 같은 하이퍼바이저(Hypervisor)를 올려 여러 서비스를 가상화하거나, TrueNAS Scale 같은 솔루션으로 NAS를 구축해서 데이터를 관리하고 있습니다.

    비교 대상 미니 서버 유형

    이번 벤치마크에서는 특정 모델명을 언급하기보다는, 현재 시장에서 인기가 많거나 홈랩에서 많이 사용되는 세 가지 유형의 저전력 미니 서버를 기준으로 제 경험을 공유하겠습니다. 실제 사용 가능한 제품들만 다루기 위한 저만의 원칙이거든요. 대신 각 유형의 특징과 성능을 명확히 알려드릴 테니까요.

    1. 최신 저전력 가성비 챔피언: Intel N100 기반 미니PC
      최근 홈랩 커뮤니티에서 가장 뜨거운 프로세서 중 하나죠. 4코어 4스레드(Core, Thread) 구성에 저전력으로 동작하며, 기본적인 가상화나 컨테이너 환경, 가벼운 NAS에 충분한 성능을 제공합니다. TDP(Thermal Design Power, 열 설계 전력)가 낮아 발열과 소음 면에서도 유리하더라고요.
    2. 기존 홈랩 강자: Intel J4125/J5005 등 구형 저전력 미니PC
      몇 년 전까지만 해도 홈랩 가성비의 대명사였습니다. N100보다는 성능이 한두 세대 뒤처지지만, 여전히 저렴한 가격과 충분한 확장성(SATA 포트 등)으로 NAS용으로 사랑받는 모델들이 많아요.
    3. 성능과 전력의 타협점: Intel Core i3/i5 저전력 버전 미니PC (11세대 이상)
      N100으로는 조금 부족하고, 그렇다고 풀스펙 데스크탑 CPU를 쓰자니 전력 소모가 부담스러운 분들을 위한 선택지예요. 저전력으로 설계된 모바일(Mobile) 또는 저전력(Low-power) 버전의 Core i3/i5 프로세서를 탑재한 미니PC들은 N100보다 확실히 높은 성능을 제공하면서도, 여전히 저전력을 유지하려는 노력이 돋보입니다.

    🛠️ 실전 벤치마크 환경 구축 및 테스트 과정

    저는 각 유형의 미니 서버에 Proxmox VE를 설치하고, 그 위에 다양한 가상 머신(VM)과 컨테이너(LXC)를 올려 실제 홈랩 환경을 최대한 모사했습니다. 테스트를 위해 Ubuntu Server VM을 여러 개 생성하고, 다음과 같은 방식으로 성능을 측정했어요.

    • CPU 성능 측정: sysbench, stress-ng, 그리고 Docker 환경에서 여러 개의 웹 서버(Nginx, Apache) 컨테이너를 동시에 구동하며 부하 테스트. 동영상 트랜스코딩(Transcoding) 시나리오도 돌려봤습니다.
    • 메모리(RAM) 성능 측정: memtester, 여러 VM에 메모리를 할당했을 때의 스와핑(Swapping) 발생 여부 및 응답 속도.
    • 저장장치(Storage) I/O 성능 측정: fio (Flexible I/O Tester)를 이용해 NVMe SSD와 SATA SSD/HDD의 읽기/쓰기 속도, IOPS(Input/Output Operations Per Second) 측정. NAS 용도로 사용할 경우 네트워크를 통한 파일 전송 속도도 iperf3로 측정했습니다.
    • 네트워크 성능 측정: iperf3를 이용해 1GbE/2.5GbE LAN 포트의 최대 전송 속도 및 안정성 테스트.
    • 전력 소비 측정: 스마트 플러그(Smart Plug)를 이용해 유휴 상태(Idle) 및 최대 부하(Full Load) 시의 실제 전력 소비량을 측정했습니다.

    특히 Proxmox VE 같은 하이퍼바이저 환경에서는 호스트 OS(Host OS) 자체의 오버헤드(Overhead)도 고려해야 합니다. 제가 직접 경험해보니, N100은 최대 4개의 가벼운 VM이나 10개 내외의 컨테이너를 돌리는 데는 무리가 없더라고요. 하지만 그 이상으로 부하가 걸리거나, 메모리 사용량이 많은 애플리케이션을 돌리면 확실히 버벅거리는 느낌이 들었습니다.

    # CPU 성능 테스트 (예시: sysbench 소수 계산)
    sudo apt update
    sudo apt install sysbench -y
    sysbench cpu --cpu-max-prime=20000 run
    
    # 디스크 I/O 테스트 (예시: fio 랜덤 쓰기)
    sudo apt install fio -y
    fio --name=randwrite --ioengine=libaio --iodepth=16 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=1 --runtime=60 --group_reporting
    
    Proxmox VE 대시보드에서 가상화 환경의 리소스 사용률을 모니터링하는 화면

    Proxmox VE 환경에서 다양한 가상 머신과 컨테이너의 리소스 사용량을 모니터링하는 대시보드입니다.

    ⚠️ 삽질 경험: 주의사항 및 트러블슈팅

    이런 벤치마크를 진행하면서 저도 몇 번의 삽질을 피할 수 없었습니다. 😅 여러분은 저 같은 실수를 하지 않으시길 바라며 몇 가지 팁을 공유합니다.

    • RAM 호환성 문제: 일부 미니PC는 특정 브랜드나 속도의 RAM 모듈과 호환성 문제가 있더라고요. 특히 저전력 모델들은 SODIMM(Small Outline Dual In-line Memory Module)을 사용하는데, 제조사 QVL(Qualified Vendor List)을 확인하거나, 아니면 널리 사용되는 삼성/하이닉스 제품을 선택하는 게 안전합니다. 제가 예전에 어떤 미니PC에서 DDR4 3200MHz RAM을 꽂았다가 부팅이 안 돼서 한참 헤맨 적이 있었거든요. 결국 클럭을 낮춰서 쓰거나 다른 RAM으로 교체해야 했습니다.
    • NVMe SSD 발열 관리: 작은 폼팩터에 고성능 NVMe SSD를 장착하면 발열이 심해질 수 있어요. 특히 연속적인 읽기/쓰기 작업이 많은 NAS 용도로 사용한다면 방열판(Heatsink)을 꼭 달아주는 것이 좋습니다. 방열판 없이 쓰다가 스로틀링(Throttling)이 걸려 성능이 저하되는 경험을 해봤거든요.
    • 네트워크 드라이버 이슈: 저가형 미니PC 중에는 리얼텍(Realtek) NIC(Network Interface Card)을 사용하는 경우가 종종 있습니다. 리눅스(Linux) 기반 OS에서는 드라이버 호환성 문제가 발생하기도 하니, 가능하면 인텔(Intel) NIC이 장착된 모델을 고르시는 게 좋아요. 특히 2.5GbE NIC에서 이런 문제가 불거지는 경우가 많더라고요.
    • BIOS(바이오스) 설정: 가상화 기능을 사용하려면 BIOS에서 VT-x (Virtualization Technology for x86) 또는 SVM(Secure Virtual Machine) 기능을 활성화해야 합니다. 이걸 깜빡하고 “왜 가상화가 안 되지?” 하며 시간을 보낸 적도 있네요. 😅

    📊 저전력 미니 서버 성능 실측 결과 및 비교

    이제 가장 중요한 벤치마크 결과입니다. 제가 측정한 데이터를 바탕으로 각 유형의 저전력 미니 서버가 어떤 성능 특성을 보였는지 정리해봤습니다. (수치 자체는 제가 직접 여러 번 테스트하고 종합한 경험적 데이터이므로, 절대적인 값이라기보다는 상대적인 성능 비교에 중점을 두었습니다.)

    구분 Intel N100 기반 Intel J4125/J5005 기반 Intel Core i3/i5 (저전력) 기반
    주요 특징 최신 아키텍처, 뛰어난 전성비, 저렴한 가격 오랜 기간 검증된 저전력, SATA 확장성 우수, 저렴 N100 대비 월등한 성능, 여전히 낮은 전력 소비
    CPU 성능 (상대적) ⭐⭐⭐ (가벼운 VM/컨테이너, 웹서버, DNS 등) ⭐⭐ (기본적인 NAS, 라우터, 모니터링) ⭐⭐⭐⭐⭐ (다수 VM, 미디어 서버, 개발 환경)
    RAM 확장성 최대 16GB (대부분 1개 슬롯) 최대 8GB (대부분 1개 슬롯) 최대 32GB/64GB (2개 슬롯)
    저장장치 확장성 NVMe 1개, SATA 1개 (일부 모델 2개) NVMe 1개, SATA 2~4개 (NAS용 강점) NVMe 1~2개, SATA 1~2개
    네트워크 1GbE 또는 2.5GbE (1~2개) 1GbE (1~2개) 2.5GbE (2개 이상)
    유휴 전력 소비 (W) 약 5~10W 약 8~15W 약 10~20W
    최대 부하 전력 소비 (W) 약 20~30W 약 25~35W 약 40~60W
    적합한 용도 가벼운 홈랩 서버, DNS, VPN, 웹 서버, Docker 호스트 저전력 NAS, pfSense/OpenWrt 라우터, CCTV NVR 고성능 NAS, 미디어 서버(Plex), 개발/테스트 VM, 다수 서비스 호스팅

    제 경험으로는 Intel N100은 정말 기대 이상이었어요. 가벼운 웹 서버 몇 개, PostgreSQL 같은 데이터베이스, 그리고 Pi-hole 같은 DNS 서버를 Docker 컨테이너로 돌리는데 전혀 문제가 없었거든요. 심지어 Plex 미디어 서버에서 가벼운 트랜스코딩 작업(720p~1080p SDR)도 무리 없이 처리하더라고요. 전성비(Performance per Watt)는 단연 최고였습니다. 하지만 동시에 여러 개의 VM을 돌리거나, 4K 트랜스코딩 같은 고부하 작업에는 한계가 명확했습니다.

    구형 J4125/J5005 기반 시스템들은 NAS 용도로는 여전히 매력적이에요. 특히 SATA 포트가 넉넉하게 제공되는 모델들이 많아서 여러 개의 HDD를 연결하기 좋거든요. 하지만 CPU 성능은 N100보다 확실히 밀리는 감이 있어서, 가상화보다는 단순 파일 서버나 라우터(Router) 같은 단일 목적 서버에 더 적합하다고 느꼈습니다.

    마지막으로 저전력 Core i3/i5 기반 미니PC는 말 그대로 “성능이 필요한데 전력도 포기 못 하는” 분들을 위한 완벽한 대안이었어요. N100으로는 부족했던 고사양 VM이나 복잡한 개발 환경, 여러 명이 동시에 접속하는 Plex 서버 등에는 이쪽이 훨씬 쾌적했거든요. 물론 N100보다는 전기를 더 먹지만, 데스크탑 CPU에 비하면 여전히 착한 수준이었습니다.

    저전력 미니 서버 3가지 유형의 성능, 전력, 확장성, 용도를 비교한 인포그래픽

    세 가지 유형의 저전력 미니 서버를 성능, 전력, 확장성, 적합한 용도 측면에서 비교한 요약 인포그래픽입니다.

    🎉 마무리: 나에게 맞는 저전력 미니 서버는?

    결론적으로, 저전력 미니 서버는 홈랩 환경에서 전력 소비와 소음 문제를 해결해 줄 수 있는 아주 훌륭한 대안입니다. 어떤 것을 선택할지는 여러분의 주요 사용 목적과 예산에 달려 있어요.

    • 가성비를 최우선으로, 가벼운 서비스 위주로 홈랩을 운영하고 싶다면?
      ✅ Intel N100 기반 미니PC를 강력 추천합니다. 대부분의 기본적인 홈랩 서비스(DNS, VPN, 웹서버, Docker 컨테이너)는 충분히 소화해낼 거예요.
    • 데이터 저장 공간을 최우선으로, 안정적인 NAS 구축이 필요하다면?
      ✅ SATA 포트 확장성이 좋은 구형 J4125/J5005 기반 저전력 미니PC나, 혹은 최근 N100 중에서도 SATA 포트가 여유로운 모델을 찾아보는 것도 좋은 방법입니다.
    • N100으로는 부족한 고성능 VM, 미디어 트랜스코딩, 개발 환경 등 다목적 활용이 필요하다면?
      ✅ 조금 더 예산을 투자해서 Intel Core i3/i5 저전력 버전 미니PC를 고려해 보세요. 만족도가 훨씬 높을 겁니다.

    저도 처음엔 “이 작은 게 얼마나 하겠어?” 싶었는데, 실제로 써보니까 요즘 미니PC들이 정말 똑똑하게 잘 나온다는 것을 느꼈어요. 여러분도 자신의 워크로드(Workload)를 잘 파악해서 현명한 선택을 하시길 바랍니다. 다음 글에서는 특정 미니 서버에 TrueNAS Scale을 설치하고 최적화하는 과정에 대해 더 자세히 다뤄보도록 하겠습니다. 기대해주세요! 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 제가 아는 선에서 성심성의껏 답변해 드리겠습니다. 😊

  • [Proxmox] ZFS vs Btrfs 비교: Proxmox 홈랩에서의 실측 성능과 데이터 무결성 분석

    [Proxmox] ZFS vs Btrfs 비교: Proxmox 홈랩에서의 실측 성능과 데이터 무결성 분석

    안녕하세요! 13년차 인프라 엔지니어, ’13년차의 서버실’ 주인장입니다.

    홈랩을 운영하다 보면 늘 새로운 기술에 대한 갈증과 함께 ‘어떻게 하면 더 효율적이고 안정적으로 운영할 수 있을까?’ 하는 고민에 빠지게 됩니다. 특히 스토리지 선택은 홈랩의 심장이나 다름없죠. Proxmox VE(Virtual Environment)를 사용하시는 분들이라면 한 번쯤은 ZFS와 Btrfs 사이에서 깊은 고민에 빠져보셨을 겁니다. 저도 처음엔 뭐가 뭔지 복잡하고, 어떤 게 제 홈랩 환경에 최적일지 갈피를 잡기 어려웠거든요. 스펙 시트만 봐서는 답이 안 나오더라고요.

    그래서 오늘은 제가 직접 Proxmox 홈랩에서 ZFS와 Btrfs 스토리지를 구성하고 사용해보면서 겪었던 경험과 함께, 실측 성능 (물론 ‘실측’이라는 게 제 개인적인 체감과 간단한 테스트 기준입니다만) 그리고 데이터 무결성 측면에서 두 파일 시스템을 꼼꼼하게 비교 분석해 보려고 합니다. 이 글이 여러분의 홈랩 스토리지 성능 고민과 ZFS, Btrfs 선택에 작은 이정표가 되었으면 좋겠네요. 삽질 끝에 얻은 저의 인사이트를 솔직하게 공유해 드릴게요! 🎉

    ZFS와 Btrfs는 Copy-on-Write(CoW) 개념을 기반으로 하는 최신 파일 시스템입니다. 이미지에서는 두 파일 시스템의 주요 특징과 구조를 시각적으로 비교하여 보여줍니다.

    ZFS와 Btrfs, 대체 뭐가 다른가요? (핵심 개념 파헤치기)

    본격적인 비교에 앞서, 두 파일 시스템의 핵심 개념을 먼저 짚고 넘어가야겠죠? 쉽게 말해 ZFS와 Btrfs 모두 ‘차세대 파일 시스템’으로 불리며, 기존 ext4 같은 파일 시스템보다 훨씬 강력한 기능들을 제공합니다.

    • Copy-on-Write (CoW, 카피 온 라이트): 이게 두 파일 시스템의 가장 중요한 공통점입니다. 데이터를 덮어쓰지 않고, 변경 사항이 생기면 새로운 블록에 쓰고 메타데이터만 업데이트하는 방식이죠. 덕분에 스냅샷(Snapshot) 생성이나 데이터 손상 복구에 아주 유리합니다.
    • 데이터 무결성 (Data Integrity): CoW 덕분에 데이터가 손상될 위험이 훨씬 적습니다. 체크섬(Checksum)을 사용해서 데이터가 올바른지 지속적으로 검증하거든요.

    ZFS(Zettabyte File System): 엔터프라이즈급 안정성의 대명사

    ZFS는 Oracle Solaris에서 시작되어 현재는 OpenZFS 프로젝트로 활발히 개발되고 있는 파일 시스템입니다. ‘강력한 데이터 무결성’이라는 키워드가 가장 잘 어울립니다. 제가 써보니 이 친구는 정말 든든하더라고요. 주요 특징은 다음과 같습니다.

    • 트랜잭션 기반 (Transactional): 모든 쓰기 작업이 트랜잭션으로 처리되어 데이터 손실 위험이 거의 없습니다.
    • 풀 관리 (Pool Management): 여러 디스크를 묶어 스토리지 풀(Storage Pool)을 구성하고, 그 위에 파일 시스템을 생성합니다. RAID-Z (RAID-Z1, RAID-Z2, RAID-Z3)와 같은 소프트웨어 RAID 기능이 내장되어 있어 별도의 하드웨어 RAID 컨트롤러 없이도 강력한 데이터 보호 기능을 제공합니다.
    • 자가 복구 (Self-Healing): 데이터 손상이 감지되면 체크섬을 통해 자동으로 복구하려고 시도합니다. 이게 진짜 매력적이죠.
    • 스냅샷 (Snapshot) 및 클론 (Clone): 거의 즉각적으로 스냅샷을 생성하고 관리할 수 있습니다. 백업이나 테스트 환경 구성에 아주 유용하죠.
    • 압축 (Compression) 및 중복 제거 (Deduplication): 데이터를 압축하여 공간을 절약하고, 중복되는 데이터를 제거하여 효율성을 높일 수 있습니다. 다만, 중복 제거는 RAM을 많이 사용해서 홈랩에서는 신중하게 접근해야 합니다.

    Btrfs (B-tree File System): 리눅스 친화적인 유연성

    Btrfs는 Linux 커널에 통합되어 개발된 파일 시스템으로, ZFS와 유사한 CoW 기반의 고급 기능을 제공하면서도 좀 더 리눅스 친화적인 면모를 보입니다. 제가 처음 Btrfs를 접했을 땐 ‘오, ZFS만큼 강력한데 더 가볍고 유연하네?’ 싶었거든요.

    • 서브볼륨 (Subvolume): 파티션처럼 작동하지만 훨씬 유연하게 생성하고 관리할 수 있습니다. 스냅샷의 기반이 되기도 하고요.
    • 파일 시스템 수준 RAID (File System Level RAID): ZFS의 RAID-Z처럼 디스크 여러 개를 묶어 RAID0, RAID1, RAID10 등을 구성할 수 있습니다. 다만, RAID5/6은 아직 안정성 문제로 권장되지 않는 경우가 많습니다. 제가 한 번 써봤는데, 썩 만족스럽지 못했죠. ⚠️
    • 스냅샷 (Snapshot): ZFS와 마찬가지로 빠르고 효율적인 스냅샷 기능을 제공합니다. 서브볼륨 기반이라 관리도 편리하고요.
    • 데이터 및 메타데이터 체크섬 (Data and Metadata Checksum): ZFS와 유사하게 데이터 무결성을 검증합니다.
    • 온라인 리사이징 (Online Resizing): 파일 시스템 크기를 온라인 상태에서 유연하게 조절할 수 있습니다.

    두 파일 시스템의 주요 특징을 표로 비교해볼까요?

    특징 ZFS Btrfs
    개발 주체 Oracle Solaris (현재 OpenZFS) Linux 커널
    기반 기술 Copy-on-Write (CoW) Copy-on-Write (CoW)
    데이터 무결성 매우 강력 (체크섬, 자가 복구, 트랜잭션) 강력 (체크섬)
    RAID 기능 내장 (RAID-Z1/2/3) 내장 (RAID0/1/10, 5/6은 주의 필요)
    스냅샷 매우 효율적, 클론 가능 매우 효율적, 서브볼륨 기반
    중복 제거 지원 (RAM 소모 큼) 지원 (RAM 소모 큼)
    압축 지원 지원
    메모리 요구량 높음 (ARC 캐시) 상대적으로 낮음
    주요 사용처 NAS, 서버, 엔터프라이즈 스토리지 데스크톱, 홈랩, 경량 서버

    Proxmox에서 ZFS, Btrfs 스토리지 구성하기 (실전 구현)

    이제 Proxmox 환경에서 실제로 두 스토리지를 어떻게 구성할 수 있는지 알아볼 시간입니다. 제가 직접 해보니 Proxmox 설치 시 ZFS 루트 파일 시스템을 선택하는 게 가장 편하더라고요. 설치 단계에서 바로 ZFS 풀을 구성할 수 있거든요. 하지만 이미 설치된 Proxmox에 추가하거나 Btrfs를 사용하려면 몇 가지 수동 설정이 필요합니다.

    ZFS 스토리지 구성 예시 (Proxmox 설치 후 추가)

    Proxmox에 새로운 디스크로 ZFS 풀을 추가하는 과정입니다.

    1. 디스크 확인: 먼저 사용할 디스크의 경로를 확인합니다.
    2. lsblk

      예를 들어 /dev/sdb, /dev/sdc를 사용할 경우입니다.

    3. ZFS 풀 생성: RAID-Z1 (패리티 디스크 1개)으로 풀을 생성합니다.
    4. zpool create -f myzfsraidz1 raidz1 /dev/sdb /dev/sdc /dev/sdd

      여기서 myzfsraidz1은 제가 임의로 정한 풀 이름입니다. 실제 환경에서는 디스크 개수와 보호 수준에 맞춰 RAID-Z2 등을 선택할 수 있습니다.

    5. Proxmox에 ZFS 스토리지 추가: Proxmox Web UI에 접속하여 데이터센터 > 스토리지 > 추가 > ZFS를 선택하고, 생성한 myzfsraidz1 풀을 연결해 줍니다. 콘텐츠 타입(Content type)은 VM 디스크 이미지, 컨테이너, 백업 등 필요한 것을 선택하면 됩니다.

    Btrfs 스토리지 구성 예시 (Proxmox 설치 후 추가)

    Btrfs는 Proxmox의 기본 스토리지 타입으로 직접 지원하지 않아, 일반 디렉토리 스토리지로 활용해야 합니다. 이 부분이 Btrfs를 홈랩에서 쓰려는 분들께는 첫 번째 삽질 포인트가 되더라고요. ⚠️

    1. 디스크 확인 및 Btrfs 파일 시스템 생성:
    2. lsblk
      mkfs.btrfs -f /dev/sde

      /dev/sde는 예시 디스크입니다. 여러 디스크를 Btrfs RAID로 묶으려면 mkfs.btrfs -d raid1 -m raid1 /dev/sde /dev/sdf 와 같이 명령어를 사용합니다.

    3. 마운트 포인트 생성 및 마운트:
    4. mkdir /mnt/mybtrfs
      mount /dev/sde /mnt/mybtrfs
    5. fstab에 등록 (재부팅 시 자동 마운트): UUID를 사용해 등록하는 것이 좋습니다.
    6. echo "UUID=$(blkid -s UUID -o value /dev/sde) /mnt/mybtrfs btrfs defaults 0 0" >> /etc/fstab
    7. Proxmox에 디렉토리 스토리지 추가: Proxmox Web UI에서 데이터센터 > 스토리지 > 추가 > 디렉토리를 선택하고, 경로를 /mnt/mybtrfs로 지정합니다. 콘텐츠 타입은 ZFS와 마찬가지로 필요에 따라 선택합니다.
    Proxmox 웹 인터페이스에서 새로운 ZFS 또는 Btrfs 기반 디렉토리 스토리지를 추가하는 설정 화면입니다.

    Proxmox 웹 인터페이스에서 새로운 스토리지를 추가하는 화면입니다. ZFS 풀이나 Btrfs 서브볼륨을 Proxmox에 연결하는 과정을 보여줍니다.

    삽질 경험: 성능과 데이터 무결성 사이의 고민

    솔직히 말씀드리면, 처음엔 Btrfs의 유연성과 서브볼륨 기능에 혹했었습니다. ‘오, 이거 하나로 다 되겠네!’ 싶었거든요. 그런데 막상 홈랩 환경에서 여러 VM과 컨테이너를 돌려보니, 생각보다 여러 부분에서 차이를 느끼게 되더라고요.

    ZFS는 메모리 사용량(ARC, Adaptive Replacement Cache)이 높은 편입니다. 그래서 Proxmox 호스트의 RAM이 충분하지 않으면 성능 저하가 올 수 있다는 경고를 많이 봤었죠. 제 홈랩 서버는 RAM이 넉넉한 편이라 크게 문제는 없었습니다만, 만약 8GB 같은 최소 사양으로 Proxmox를 운영한다면 ZFS는 조금 부담스러울 수 있습니다. 반면 Btrfs는 상대적으로 메모리 요구량이 낮아 경량 환경에 더 적합할 수 있습니다. 하지만 이게 다가 아니더라고요.

    특히 랜덤 I/O 성능에서 ZFS가 강점을 보였습니다. VM 부팅이나 데이터베이스 작업처럼 작은 파일들이 불규칙하게 읽고 쓰이는 작업에서는 ZFS가 확실히 더 빠릿빠릿한 체감을 줬습니다. SSD 환경에서는 그 차이가 더 두드러지더라고요. Btrfs는 스냅샷 관리나 서브볼륨의 유연성에서는 좋았지만, 특정 I/O 패턴에서는 ZFS만큼의 안정적인 성능을 보여주지는 못했습니다. 특히 Btrfs에서 RAID5/6은 아직 프로덕션 환경에서는 조심해야 한다는 이야기가 많죠? 저도 홈랩에서 시도했다가 데이터 날릴 뻔했습니다. ⚠️ 그래서 Btrfs로 RAID를 구성할 때는 RAID1이나 RAID10을 권장하는 편입니다.

    홈랩 환경에서의 실측 성능 분석 (결과 검증)

    구체적인 벤치마크 수치를 나열하는 것은 의미가 없다고 생각합니다. 왜냐하면 제 홈랩 환경과 여러분의 환경은 디스크 종류, CPU, RAM, 워크로드 등 모든 것이 다르기 때문이죠. 하지만 제가 ‘체감’하고 ‘관찰’한 바는 명확합니다.

    • VM/컨테이너 I/O 성능:
      • ZFS: SSD 환경에서 VM의 부팅 속도나 디스크 집약적인 애플리케이션(예: 데이터베이스, CI/CD 빌드 에이전트) 실행 시, 더 안정적이고 예측 가능한 성능을 보여줬습니다. 특히 ARC 캐시가 활성화되면 읽기 성능이 매우 뛰어났습니다.
      • Btrfs: 일반적인 VM 운영에는 무리가 없었지만, 고부하 랜덤 I/O 상황에서는 ZFS 대비 미세하게 느리거나 불안정한 모습을 보일 때가 있었습니다. 하지만 스냅샷 생성 및 복구는 ZFS보다 빠르고 가벼운 느낌을 줬습니다.
    • 데이터 무결성 및 복구:
      • ZFS: 이건 정말 ‘철옹성’ 같다는 느낌을 받았습니다. 한 번은 불안정한 전원 공급으로 인해 시스템이 갑자기 꺼진 적이 있었는데, ZFS 풀은 아무 문제 없이 잘 복구되더라고요. 체크섬 기반의 자가 복구 기능 덕분인 것 같습니다. zpool scrub 명령어로 주기적으로 풀 상태를 확인하면 마음이 편안해집니다.
      • Btrfs: Btrfs 역시 체크섬을 사용하기 때문에 데이터 무결성이 우수합니다. 하지만 ZFS만큼 ‘강력하다’는 인상은 받지 못했습니다. 커뮤니티에서도 ZFS가 데이터 손상 방지 및 복구 측면에서 좀 더 검증된 안정성을 가지고 있다고 평가하는 분위기입니다.

    결론적으로, 제 홈랩 환경(주로 VM 여러 개와 컨테이너, 그리고 미디어 서버)에서는 SSD를 기반으로 한 ZFS가 전반적인 성능과 안정성, 그리고 무엇보다 ‘데이터 무결성’ 측면에서 더 높은 만족도를 줬습니다. Btrfs는 스냅샷을 자주 사용하고, 유연한 볼륨 관리가 필요하며, RAM 사용량에 민감한 특정 워크로드에서 진가를 발휘할 수 있을 것 같더라고요.

    Proxmox 가상 머신의 디스크 읽기 및 쓰기 I/O 성능를 시간대별로 보여주는 모니터링 그래프입니다.

    Proxmox 가상 머신의 디스크 I/O 성능 모니터링 그래프입니다. ZFS와 Btrfs 스토리지에서 각각 운영되는 VM의 I/O 처리량을 시각적으로 비교할 수 있습니다.

    그래서, 어떤 걸 선택해야 할까요? (결론 및 제안)

    제 경험을 바탕으로 여러분의 홈랩 스토리지 선택에 대한 가이드를 드려볼게요. 정답은 없지만, 어떤 상황에 더 적합한지는 분명히 있습니다.

    • ZFS를 추천하는 경우:
      • ✅ 데이터 무결성과 안정성을 최우선으로 생각한다면 ZFS가 최고의 선택입니다.
      • ✅ Proxmox 호스트의 RAM이 충분하다면 (최소 16GB 이상, 많을수록 좋습니다).
      • ✅ 하드웨어 RAID 컨트롤러 없이 소프트웨어 RAID (RAID-Z)로 강력한 데이터 보호를 원한다면.
      • ✅ VM 디스크 I/O 성능이 중요한 워크로드(데이터베이스, 개발 환경 등)를 운영한다면.
    • Btrfs를 고려할 수 있는 경우:
      • ✅ 유연한 스냅샷 관리와 서브볼륨 기능을 적극적으로 활용하고 싶다면.
      • ✅ Proxmox 호스트의 RAM이 상대적으로 부족한 환경에서 CoW 기반 파일 시스템을 쓰고 싶다면.
      • ✅ 특정 실험적인 워크로드나, 파일 시스템 수준의 RAID1/10을 구성하려 한다면 (단, RAID5/6은 아직 주의).
      • ✅ 스토리지를 자주 확장하거나 축소하는 등 유연한 볼륨 관리가 필요하다면.

    결론적으로, 저는 안정성과 강력한 데이터 무결성 때문에 Proxmox 루트 파일 시스템은 ZFS로, 그리고 특정 실험용 VM이나 컨테이너 스토리지로는 Btrfs를 별도로 구성하는 하이브리드 방식을 선호하게 되더라고요. 이렇게 하면 두 파일 시스템의 장점을 모두 활용할 수 있습니다. 💡

    ZFS와 Btrfs 파일 시스템의 주요 장점과 단점을 직관적으로 비교하는 인포그래픽입니다.

    ZFS와 Btrfs 파일 시스템의 주요 장점과 단점을 한눈에 비교할 수 있는 인포그래픽입니다. 홈랩 환경에서의 스토리지 성택에 도움을 줄 수 있는 핵심 정보를 담고 있습니다.

    마무리하며: 나의 홈랩, 나의 스토리지

    오늘 글을 통해 Proxmox 환경에서 ZFS와 Btrfs 비교를 해봤습니다. 저의 13년차 인프라 엔지니어의 경험과 홈랩에서의 삽질(?)을 바탕으로 이야기했지만, 결국 여러분의 환경과 목적에 맞는 최적의 선택을 하는 것이 가장 중요합니다. 어떤 파일 시스템을 선택하시든, 스냅샷과 백업은 선택이 아닌 필수라는 점, 잊지 마세요!

    이 글이 여러분의 홈랩 스토리지 성능과 데이터 무결성 고민에 작은 도움이 되었으면 좋겠습니다. 혹시 더 궁금한 점이나 여러분의 경험이 있다면 댓글로 공유해 주세요! 다음에는 ZFS ARC 캐싱 최적화에 대해 좀 더 깊이 다뤄볼 예정이니 기대해 주세요!

  • [Proxmox] Proxmox VE 클러스터 고가용성(HA) 구축: 실패 사례 분석 및 교훈

    [Proxmox] Proxmox VE 클러스터 고가용성(HA) 구축: 실패 사례 분석 및 교훈

    [Proxmox VE] 클러스터 HA 구축 실패 사례 분석 및 교훈

    안녕하세요, 13년차의 서버실입니다. 오늘은 제가 홈랩에서 Proxmox VE(Virtual Environment) 클러스터로 고가용성(High Availability, HA) 환경을 구축하다가 겪었던 삽질 경험을 솔직하게 풀어보려고 합니다. 사실 처음엔 ‘Proxmox HA 클러스터? 별거 아니겠지!’ 하고 덤볐다가 제대로 혼쭐이 났거든요. 여러분은 저처럼 뼈아픈 실패를 겪지 않으시길 바라는 마음에서, 저의 삽질 과정과 해결책을 공유해 드립니다.

    Proxmox VE HA 클러스터의 이상적인 구성 다이어그램입니다. 이렇게만 되면 얼마나 좋을까요? 😅

    Proxmox HA 클러스터, 왜 필요할까요?

    Proxmox VE 클러스터는 여러 Proxmox 노드를 하나로 묶어서 관리하고, 특히 HA 기능을 활용하면 특정 노드에 장애가 발생했을 때 그 노드에서 실행 중이던 가상 머신(Virtual Machine, VM)이나 컨테이너(Container, LXC)가 자동으로 다른 정상 노드로 옮겨가서 서비스 연속성을 유지해 줍니다. 쉽게 말해, 서버 한 대가 고장 나도 서비스는 계속 돌아가게 해주는 아주 고마운 기능이죠. 이 HA를 가능하게 하는 핵심 기술 중 하나가 바로 Corosync(코로싱크)라는 분산 합의 프로토콜입니다. Corosync는 클러스터 내의 모든 노드가 서로의 상태를 감시하고, 클러스터의 ‘상태’에 대해 합의를 이룰 수 있도록 돕는 역할을 해요. 모든 노드가 같은 정보를 보고 있다는 확신이 있어야만, 안전하게 HA 결정을 내릴 수 있거든요.

    홈랩에 Proxmox 클러스터 구축하기 (feat. 2노드의 함정)

    처음에는 Proxmox 클러스터 구성 자체는 어렵지 않았어요. 각 노드에 Proxmox VE를 설치하고, 터미널에서 pvecm create 명령으로 클러스터를 만들고, 다른 노드에서 pvecm add 명령으로 합류시키면 끝! 정말 간단하더라고요. 홈랩이니 일단 물리 서버 두 대로 시작했습니다. (나중에 이게 문제의 씨앗이 될 줄은 몰랐죠 😂)

    # 첫 번째 노드에서 클러스터 생성
    pvecm create my-ha-cluster
    
    # 두 번째 노드에서 클러스터 합류 (첫 번째 노드의 IP 입력)
    pvecm add 192.168.1.10 --ring0_addr 192.168.1.11 # 192.168.1.10은 첫 번째 노드, 192.168.1.11은 두 번째 노드의 Corosync 통신용 IP
    

    이렇게 두 노드를 클러스터로 묶고, 공유 스토리지를 NFS(Network File System)로 연결했어요. VM 디스크를 이 NFS에 저장하고, 몇몇 VM에 HA 설정을 활성화했습니다. ‘이제 한 대 꺼져도 문제없겠지?’ 하는 생각에 뿌듯했죠. 그러나 현실은… 달랐습니다.

    Proxmox VE 웹 UI의 HA 설정 화면

    Proxmox VE 웹 UI에서 HA 설정을 활성화하는 화면입니다. 저도 처음엔 이 옵션만 믿었죠.

    ⚠️ 스플릿 브레인(Split-Brain) 발생과 삽질 해결 과정

    문제는 바로 여기서 발생했습니다. 제가 한 노드의 전원을 강제로 내려봤어요. HA가 잘 작동하는지 보려고요. 그런데 VM이 다른 노드로 넘어가지 않는 겁니다! 😱 아니, 이게 무슨 일인가 싶어서 Proxmox 웹 UI를 확인해보니, 꺼진 노드는 ‘offline’ 상태인데, VM은 여전히 ‘stopped’ 상태로 남아있는 거예요. 심지어 나중에 다시 켜보니, 양쪽 노드에서 같은 VM이 켜져 있는 기괴한 상황까지 벌어졌습니다. 네, 바로 Split-Brain(스플릿 브레인) 현상이었죠.

    Split-Brain(스플릿 브레인)은 분산 시스템에서 클러스터 노드들이 서로 통신하지 못하게 되어, 각 노드가 클러스터의 ‘일부’가 마치 전체 클러스터인 것처럼 독자적인 결정을 내리는 상황을 말합니다. 이 경우, 두 노드가 같은 자원(예: 같은 VM)을 동시에 점유하려 들면서 데이터 손상이나 서비스 중단 같은 심각한 문제가 발생할 수 있어요. Proxmox 클러스터에서는 Corosync가 노드 간의 합의를 담당하는데, 통신 장애가 생기면 이 합의가 깨지면서 스플릿 브레인이 발생할 수 있는 거죠.

    원인을 찾아보니, 제 클러스터는 노드가 2개였습니다. Corosync는 클러스터의 ‘쿼럼(Quorum)’이라는 개념을 사용해서 합의를 이룹니다. 쿼럼(Quorum)은 클러스터가 정상적으로 작동하기 위해 필요한 최소한의 투표 수(votes)를 의미해요. 보통 클러스터 노드 수의 과반수(N/2 + 1)를 요구합니다. 2개 노드 클러스터에서는 쿼럼이 2가 됩니다. 즉, 두 노드가 모두 살아있어야만 쿼럼이 충족되는 거죠. 한 노드가 죽으면 쿼럼이 깨지면서 클러스터 전체가 멈춰버리는 겁니다. HA가 작동할 리가 없죠.

    이게 바로 ‘2노드 클러스터의 딜레마’였습니다. 그래서 Proxmox 문서나 여러 커뮤니티를 찾아보니, 최소 3개 노드를 권장하더라고요. 3개 노드 클러스터라면 쿼럼은 2가 됩니다. 한 노드가 죽어도 나머지 두 노드가 살아있으면 쿼럼이 유지되므로 HA 기능을 정상적으로 사용할 수 있습니다. ‘아, 그래서 다들 3노드, 5노드 하는구나!’ 하고 무릎을 탁 쳤습니다. 홈랩에 놀고 있는 미니 PC 한 대를 추가해서 3노드 클러스터로 재구성하기로 결정했어요.

    # (예시) 기존 2노드 클러스터에서 한 노드를 제거하고 3노드 클러스터로 재구성하는 과정
    # 1. HA 서비스 비활성화 (모든 VM/LXC)
    # 2. 클러스터 노드에서 VM/LXC 모두 다른 노드로 마이그레이션 또는 종료
    # 3. 제거할 노드에서 클러스터 탈퇴 (pvecm delnode [노드이름])
    # 4. 새로 추가할 노드에 Proxmox 설치 후 pvecm add [기존 노드 IP]
    # 5. HA 설정 재활성화 및 테스트
    

    실제로 이렇게 3노드 클러스터로 재구성하고 다시 테스트해보니, 드디어 HA가 제대로 작동하더라고요! 한 노드의 전원을 강제로 내려도, 다른 노드에서 VM이 정상적으로 기동되는 것을 확인했습니다. 🎉

    3노드 Proxmox VE 클러스터 대시보드와 HA 작동 결과

    드디어 3노드 클러스터에서 HA가 정상 작동하는 모습입니다. 노드 중 하나가 오프라인이 되어도 VM이 다른 노드에서 잘 살아났어요!

    검증 및 결과: 이제야 안심이 되네요

    3노드 클러스터로 재구성한 후, 여러 시나리오로 HA 기능을 검증해봤습니다.

    • 노드 강제 종료: 특정 노드의 전원을 뽑아보니, 약 1~2분 내에 해당 노드에 할당된 HA VM들이 다른 정상 노드에서 자동으로 시작되었습니다.
    • 네트워크 단절: Corosync 네트워크 케이블을 뽑아보니, 역시 쿼럼이 깨지지 않는 상황에서는 HA가 정상적으로 작동했습니다. (물론 모든 네트워크가 단절되면 답이 없지만요 😅)
    • 스토리지 장애 시나리오: 공유 NFS 스토리지가 끊겼을 때는 HA가 작동하지 않았습니다. 이건 당연한 결과죠. VM 디스크를 읽을 수 없으니 다른 노드로 넘어가도 소용이 없거든요. 그래서 공유 스토리지의 고가용성도 중요합니다. (다음 글에서 다룰 예정입니다!)

    이렇게 직접 테스트하고 나서야 비로소 ‘아, 이게 진짜 고가용성이구나!’ 하고 안심할 수 있었죠. 단순히 설정 몇 개 한다고 되는 게 아니더라고요.

    Proxmox HA 2노드 vs 3노드 클러스터 비교 인포그래픽

    2노드와 3노드 Proxmox HA 클러스터의 쿼럼 및 장애 허용 개수 비교입니다. 숫자의 중요성을 다시 한번 깨닫습니다.

    마무리하며 얻은 교훈

    이번 Proxmox HA 클러스터 구축 삽질을 통해 저는 중요한 교훈을 얻었습니다.

    1. 쿼럼의 중요성: 분산 시스템, 특히 HA 클러스터에서는 쿼럼(Quorum)이라는 개념을 반드시 이해하고 있어야 합니다. 노드 수에 따라 쿼럼이 어떻게 변하는지, 그리고 쿼럼이 깨졌을 때 어떤 문제가 발생하는지 정확히 알아야 해요.
    2. 최소 3개 노드: Proxmox VE HA 클러스터를 구성할 때는 스플릿 브레인을 방지하고 안정적인 HA를 위해 최소 3개 이상의 노드로 시작하는 것이 좋습니다. 2노드 클러스터는 한 노드 장애 시 쿼럼 손실로 클러스터 전체가 멈출 가능성이 매우 높습니다.
    3. 실제 테스트의 중요성: ‘말로는 쉽지’라는 말을 많이 하지만, 실제로 직접 장애 상황을 만들어서 테스트해보지 않으면 예상치 못한 문제에 직면할 수 있습니다. 저처럼요. 😅

    물론 2노드 클러스터에서도 쿼럼 디바이스(QDevice) 같은 것을 활용하여 쿼럼을 유지하는 방법이 있긴 합니다만, 복잡도가 올라가고 추가적인 리소스가 필요해서 홈랩에서는 3개 노드가 가장 심플하고 안정적인 구성이라고 생각합니다.

    여러분도 혹시 Proxmox HA 클러스터를 구축할 계획이 있으시다면, 저의 삽질 경험을 참고하셔서 안정적인 환경을 만드시길 바랍니다. 다음 글에서는 Proxmox 클러스터와 함께 사용할 수 있는 고가용성 공유 스토리지 구성에 대해 다뤄보겠습니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요! 😊

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      pvecm create  --ring0_addr 

      예시:

      pvecm create my-ha-cluster --ring0_addr 10.10.10.10

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

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

      pvecm add  --ring0_addr 

      예시:

      pvecm add 10.10.10.10 --ring0_addr 10.10.10.11

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

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

      pvecm status

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

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

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

    2.3 공유 스토리지 설정

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

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

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

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

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

    2.4 HA (고가용성) 설정

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

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

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

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

      예시:

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

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

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

      ha-manager status

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

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

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

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

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

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

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

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

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

    4. 결과 확인 및 검증 🎉

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

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

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

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

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

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

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

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

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

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

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

  • [Proxmox] Proxmox LXC 컨테이너 vs VM: 홈랩 환경 최적화 비교 분석

    [Proxmox] Proxmox LXC 컨테이너 vs VM: 홈랩 환경 최적화 비교 분석

    [Proxmox] Proxmox LXC 컨테이너 vs VM: 홈랩 환경 최적화 비교 분석

    안녕하세요, 13년차의 서버실 주인장입니다. 홈랩을 운영하면서 가장 많이 고민하는 부분 중 하나가 바로 가상화 환경 최적화일 겁니다. 특히 Proxmox VE를 사용하시는 분들이라면, LXC 컨테이너 (Linux Container)를 써야 할지, 아니면 전통적인 가상머신 (VM, Virtual Machine)을 써야 할지 많이들 헷갈리실 텐데요. 저도 처음엔 Proxmox LXC 컨테이너가 뭔지 제대로 몰라서 이것저것 다 깔아보고 삽질 좀 했습니다. 😅

    이번 글에서는 제가 직접 써보고 경험했던 Proxmox LXC 컨테이너와 VM의 차이점, 장단점, 그리고 어떤 상황에서 무엇을 선택해야 할지 자세히 비교 분석해 드릴게요. 홈랩 자원을 효율적으로 사용하고 싶은 분들에게 멘토처럼 길잡이가 되어드리겠습니다!

    Proxmox VE 환경에서 LXC 컨테이너와 VM이 동작하는 방식을 시각적으로 나타낸 다이어그램입니다.

    Proxmox VE, VM, LXC 컨테이너: 기본 개념 잡기

    본격적인 비교에 앞서, 핵심 개념들을 간단하게 짚고 넘어갈게요. 이미 잘 아시는 분들도 있겠지만, 혹시나 헷갈리실 분들을 위해 쉽게 설명해 드리겠습니다.

    • Proxmox VE (Virtual Environment): 쉽게 말해 서버 한 대를 마치 여러 대의 컴퓨터처럼 쪼개서 쓸 수 있게 해주는 운영체제입니다. KVM(Kernel-based Virtual Machine)과 LXC(Linux Containers) 기술을 기반으로 Proxmox LXC 컨테이너와 가상화 환경을 통합 관리할 수 있게 도와주죠. 웹 인터페이스가 정말 편하더라고요!

    • 가상머신 (VM, Virtual Machine): 물리적인 컴퓨터 위에 완전히 독립적인 또 다른 가상 컴퓨터를 만드는 방식입니다. 운영체제(OS)부터 커널(Kernel)까지 모두 독립적으로 가집니다. 마치 서버 안에 또 다른 서버를 통째로 심는다고 생각하시면 됩니다. 오버헤드 (Overhead)가 좀 있지만, 완벽한 격리(Isolation)와 유연성을 제공합니다.

    • LXC 컨테이너 (Linux Container): VM과 달리 호스트 운영체제의 커널을 공유합니다. 운영체제를 통째로 가상화하는 것이 아니라, 애플리케이션 실행에 필요한 환경만 격리하여 제공하는 방식이죠. Proxmox LXC 컨테이너는 VM보다 훨씬 가볍고 빠르게 시작하며, 리소스 사용 효율이 뛰어나다는 장점이 있습니다. Docker 컨테이너와 비슷하지만, LXC는 좀 더 시스템 레벨의 가상화에 가깝습니다.

    LXC 컨테이너 vs VM: 핵심 차이점 비교

    이제 두 가상화 기술의 핵심 차이점을 표로 정리해서 한눈에 비교해볼까요? 제가 홈랩에서 Proxmox LXC 컨테이너와 VM을 직접 써보면서 느꼈던 점들을 바탕으로 정리해봤습니다.

    특징 LXC 컨테이너 (Linux Container) 가상머신 (VM, Virtual Machine)
    커널 공유 여부 호스트 OS 커널 공유 독립적인 커널 사용
    자원 오버헤드 매우 낮음 (경량) 상대적으로 높음 (무겁고 완전한 가상화)
    부팅 속도 매우 빠름 (초 단위) 느림 (OS 부팅 시간 필요)
    격리 수준 낮음 (호스트 커널 공유로 인한 잠재적 보안 이슈) 높음 (완전한 격리, 보안성 우수)
    운영체제 유연성 Linux 기반 OS만 가능 (호스트와 동일한 커널) Windows, macOS, Linux 등 모든 OS 가능
    스냅샷/백업 빠르고 가벼움 상대적으로 느리고 무거움
    하드웨어 패스스루 제한적 (GPU 등) 우수 (GPU, USB 등 다양한 장치)
    사용 사례 Docker 호스팅, 웹 서버, DB, 특정 서비스 (자원 효율 중시) Windows 게스트, 복잡한 네트워크, 보안 중요 서비스, GPU 활용

    실전 구현: Proxmox에서 LXC 컨테이너 만들기

    이제 실제로 Proxmox에서 LXC 컨테이너를 한번 만들어볼까요? 웹 UI에서도 쉽게 할 수 있지만, CLI (Command Line Interface)로 하는 것도 알아두면 좋습니다. 저는 개인적으로 CLI로 Proxmox LXC 컨테이너를 익숙해지는 걸 추천합니다. 자동화할 때 훨씬 편하거든요. 💡

    1. 템플릿 다운로드: LXC는 미리 만들어진 템플릿(Template)을 사용합니다. Ubuntu 22.04 LTS 템플릿을 받아볼게요.

      pveam update
      pveam available --section system
      pveam download local ubuntu-22.04-standard_22.04-1_amd64.tar.zst

      local은 저장소 이름입니다. 여러분의 Proxmox 저장소 이름에 맞게 변경해주세요.

    2. 컨테이너 생성: 이제 다운로드한 템플릿으로 Proxmox LXC 컨테이너를 생성합니다. CT ID는 고유한 번호입니다. 저는 101번으로 지정했어요.

      pct create 101 local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst \
        --hostname my-lxc-server \
        --rootfs local-lvm:8 \
        --memory 1024 --swap 512 \
        --cores 2 \
        --net0 name=eth0,bridge=vmbr0,ip=192.168.1.101/24,gw=192.168.1.1 \
        --unprivileged 1 --onboot 1 \
        --password your_secure_password
      • local-lvm:8: local-lvm 저장소에 8GB 디스크 할당
      • vmbr0: Proxmox 기본 브릿지 네트워크
      • --unprivileged 1: 비특권 컨테이너로 생성 (보안에 유리, 강력 추천!)
    3. 컨테이너 시작: 생성 후 바로 시작합니다.

      pct start 101
    4. 컨테이너 접속: SSH나 Proxmox 콘솔로 접속해서 설정하면 됩니다.

      ssh [email protected]

    Proxmox 웹 인터페이스에서 LXC 컨테이너가 성공적으로 생성되고 실행 중인 모습을 보여주는 화면입니다.

    실전 구현: Proxmox에서 가상머신 (VM) 만들기

    이번에는 VM을 만들어볼까요? VM은 OS 이미지 (ISO 파일)를 직접 설치해야 해서 LXC 컨테이너보다 손이 좀 더 갑니다. 그래도 그만큼 유연하죠.

    1. ISO 이미지 업로드: Ubuntu Server 22.04 LTS ISO 파일을 Proxmox ISO 저장소에 업로드합니다. 웹 UI의 데이터센터 > 저장소 > local > ISO 이미지에서 할 수 있습니다.

    2. VM 생성: CLI로도 가능하지만, VM은 웹 UI에서 생성하는 게 훨씬 직관적입니다. 생성 (Create VM) 버튼을 클릭해서 아래와 같이 설정해줍니다.

      • 일반 (General): 노드, VM ID (예: 201), 이름 (예: my-vm-server)
      • OS: 아까 업로드한 Ubuntu Server 22.04 LTS ISO 선택
      • 시스템 (System): 그래픽 카드 (기본값), SCSI 컨트롤러 (VirtIO SCSI 추천)
      • 하드 디스크 (Hard Disk): 저장소, 디스크 크기 (예: 32GB), 캐시 (Write-back 추천)
      • CPU: 코어 수 (예: 4), 소켓 수 (예: 1), 타입 (host 추천)
      • 메모리 (Memory): RAM (예: 4096MB)
      • 네트워크 (Network): 브릿지 (vmbr0), 모델 (VirtIO 추천)
    3. OS 설치: 생성된 VM을 시작하고, Proxmox 콘솔에 접속해서 일반적인 OS 설치 과정처럼 Ubuntu Server를 설치합니다. 이 과정은 일반적인 물리 서버에 OS를 설치하는 것과 동일합니다.

    ⚠️ 주의사항/트러블슈팅: 삽질 기록! (네트워크 설정, 자원 관리)

    제가 홈랩에서 가장 많이 겪었던 삽질 중 하나가 바로 네트워크 설정과 자원 관리였습니다. 특히 Proxmox LXC 컨테이너에서요.

    • LXC 컨테이너 내부 Docker 문제: 처음엔 Proxmox LXC 컨테이너 안에 Docker를 설치해서 사용하려고 했어요. 근데 이게 웬걸, systemctl start docker를 하면 자꾸 에러가 나는 겁니다. 찾아보니 비특권 컨테이너 (Unprivileged Container)에서 Docker를 제대로 사용하려면 nesting 옵션을 활성화해야 하더라고요. 아니면 cgroup v2 관련 문제일 수도 있고요. 이 부분에서 꽤 많은 시간을 보냈습니다. 해결책은 컨테이너 설정 파일(/etc/pve/lxc/101.conf)에 lxc.apparmor.profile: unconfined와 lxc.cgroup.devices.allow: a *:* rwm, 그리고 features: nesting=1을 추가하는 방법이 있었습니다. 물론 보안상 권장되는 방법은 아니니 신중하게 접근해야 합니다. ✅

      # /etc/pve/lxc/101.conf 예시
      arch: amd64
      cores: 2
      hostname: my-lxc-server
      memory: 1024
      net0: name=eth0,bridge=vmbr0,ip=192.168.1.101/24,gw=192.168.1.1,type=veth
      rootfs: local-lvm:8
      swap: 512
      mp0: /dev/sdb,mp=/mnt/data,size=10G # 추가적인 마운트 포인트 예시
      # Docker in LXC를 위한 설정 (주의해서 사용)
      features: nesting=1
      # lxc.apparmor.profile: unconfined # 비특권 컨테이너에는 보통 필요 없음. 특권 컨테이너에서 사용
      # lxc.cgroup.devices.allow: a *:* rwm # 특정 시나리오에서 필요
    • 네트워크 브릿지 오설정: Proxmox의 vmbr0 같은 네트워크 브릿지를 잘못 설정하면 외부 통신이 안 되거나, LXC 컨테이너나 VM끼리 통신이 안 되는 경우가 많습니다. 특히 홈랩에서 여러 VLAN을 사용하거나, 특정 네트워크 인터페이스를 VM에 직통으로 연결(패스스루)할 때 헷갈리곤 합니다. 항상 /etc/network/interfaces 파일을 꼼꼼히 확인하고, 변경 후에는 systemctl restart networking 또는 Proxmox 호스트 재부팅을 해줘야 합니다.

    • 자원 오버커밋 (Overcommit): Proxmox LXC 컨테이너는 자원을 유연하게 쓸 수 있어서 오버커밋하기 쉽습니다. 예를 들어, 물리 RAM이 16GB인데 LXC 컨테이너들에 총 20GB를 할당하는 식이죠. 짧게는 문제가 없지만, 모든 컨테이너가 동시에 많은 자원을 사용하면 Proxmox 호스트 전체가 느려지거나 멈출 수도 있습니다. 항상 실제 사용량을 모니터링하면서 적절히 할당하는 것이 중요합니다.

    성능 및 리소스 사용량 검증

    컨테이너와 VM을 만들었다면, 실제로 얼마나 리소스를 사용하는지 확인해봐야겠죠? 저는 주로 Proxmox 웹 UI의 그래프나 SSH로 접속해서 htop, free -h, df -h 같은 명령어로 확인합니다.

    제 경험상, 동일한 워크로드(예: 웹 서버 하나)를 Proxmox LXC 컨테이너와 VM에 올려보면, LXC 컨테이너가 훨씬 적은 RAM과 CPU를 사용하더라고요. 부팅 시간은 비교할 수 없을 정도로 LXC가 압도적이고요. 이 덕분에 저는 홈랩에서 대부분의 서비스를 LXC 컨테이너로 돌리고 있습니다. 자원 효율성 정말 최고예요! 🎉

    Proxmox VE 대시보드에서 LXC 컨테이너와 VM의 CPU 및 RAM 사용량을 비교하는 시각화된 그래프입니다.

    어떤 것을 선택해야 할까? (결론 및 제언)

    자, 그럼 이제 여러분의 홈랩 환경에 어떤 가상화 기술이 더 적합할지 정리해볼 시간입니다. 제가 13년 동안 삽질하며 내린 결론은 이렇습니다.

    • Proxmox LXC 컨테이너 (추천):

      • 자원 효율성이 최우선일 때: RAM, CPU가 제한적인 홈랩 환경에서 많은 서비스를 돌리고 싶다면 LXC 컨테이너가 정답입니다.
      • 리눅스 기반 서비스 위주: 웹 서버(Nginx, Apache), 데이터베이스(MySQL, PostgreSQL), Docker 호스팅, 파이썬 스크립트 실행 등 리눅스 기반의 애플리케이션을 돌릴 때 Proxmox LXC 컨테이너는 매우 효과적입니다.
      • 빠른 배포 및 테스트 환경: 새로운 서비스를 빠르게 띄우고 테스트하고 싶을 때 LXC 컨테이너만큼 좋은 게 없더라고요.
    • 가상머신 (VM) (추천):

      • 운영체제 유연성 필요: Windows나 다른 리눅스 배포판 (Proxmox 호스트와 다른 커널 버전)이 필요한 경우.
      • 높은 보안/격리 수준 요구: 중요 서비스나 외부와 직접 통신해야 하는 서비스처럼 완벽한 격리가 필요할 때 VM이 더 안전합니다.
      • 하드웨어 패스스루: GPU, USB 컨트롤러 등 특정 물리 하드웨어를 VM에 직접 연결해야 할 때 (예: 미디어 서버, 게임 서버).
      • 레거시 시스템: 오래된 OS나 특정 하드웨어에 의존하는 시스템을 돌려야 할 때 VM이 유일한 선택일 수 있습니다.

    제 홈랩에서는 대부분의 서비스는 Proxmox LXC 컨테이너로 돌리고, Windows나 특별한 하드웨어 패스스루가 필요한 경우에만 VM을 사용합니다. 예를 들어, 저는 Plex 미디어 서버는 VM으로 돌려서 GPU 트랜스코딩을 패스스루하고, Pi-hole이나 Home Assistant 같은 서비스는 LXC 컨테이너로 돌려서 자원을 아끼고 있습니다. 이렇게 섞어서 쓰는 게 가장 효율적이더라고요! 💡

    Proxmox 환경에서 LXC와 VM을 어떤 시나리오에서 선택하는 것이 좋은지 시각적으로 요약한 인포그래픽입니다.

    마무리: 배운 점 정리 및 다음 단계 제안

    오늘은 Proxmox VE 환경에서 LXC 컨테이너와 가상머신 (VM)을 비교 분석하고, 각각의 실전 구현 방법과 제가 겪었던 삽질 경험까지 솔직하게 공유해드렸습니다. 핵심은 각 기술의 장단점을 이해하고, 여러분의 홈랩 목적과 자원 상황에 맞춰 Proxmox LXC 컨테이너와 VM을 적절히 선택하는 것입니다.

    Proxmox LXC 컨테이너는 가볍고 빠르며 자원 효율성이 뛰어나 홈랩에 최적화된 선택지가 될 수 있습니다. 반면 VM은 높은 격리 수준과 운영체제 유연성을 제공하여 특정 목적에 더욱 강력한 대안이 됩니다. 여러분의 홈랩이 더욱 강력하고 효율적으로 운영되기를 바랍니다!

    다음 글에서는 Proxmox에서 ZFS 파일 시스템을 활용하여 스냅샷과 데이터 무결성을 어떻게 관리하는지 자세히 다뤄볼 예정입니다. 기대해주세요! 😄

    Proxmox VE 로고와 함께 LXC 컨테이너 및 VM 아이콘이 조화롭게 배치된 마무리 이미지입니다.

  • [Proxmox] Proxmox GPU 패스스루 완벽 가이드: 가상머신에서 그래픽카드 활용하기

    [Proxmox] Proxmox GPU 패스스루 완벽 가이드: 가상머신에서 그래픽카드 활용하기

    Proxmox GPU 패스스루 완벽 가이드: 가상머신에서 그래픽카드 활용하기

    안녕하세요, 13년차 서버실 지킴이 ’13년차의 서버실’입니다. 오늘은 많은 분들이 홈랩에서 꿈꾸는 로망 중 하나인 Proxmox GPU 패스스루에 대한 이야기를 해볼까 합니다. 하나의 강력한 서버로 여러 가상머신(VM)을 돌리면서, 특정 가상머신에 고성능 그래픽카드(GPU)를 통째로 할당해주는 기술이죠. 저도 처음엔 ‘이게 가능하다고?’ 싶었는데, 실제로 해보니 그 활용도가 무궁무진하더라고요. 게이밍 VM부터 AI/딥러닝 워크스테이션, 그리고 미디어 트랜스코딩 서버까지, 여러분의 상상력을 현실로 만들어줄 마법 같은 기술입니다. 저도 수많은 삽질 끝에 성공했고, 그 과정에서 얻은 소중한 경험과 팁들을 오늘 이 자리에서 아낌없이 풀어놓으려 합니다.

    혹시 여러분도 저처럼 비싼 장비 여러 대를 들이지 않고, 하나의 서버로 모든 것을 해결하고 싶은 꿈을 꾸고 계신가요? 그렇다면 이 글이 여러분의 길잡이가 되어줄 겁니다. 제가 직접 해보니 얻는 게 정말 많더라고요. 그럼, 함께 Proxmox GPU 패스스루의 세계로 떠나볼까요?

    Proxmox VE 환경에서 호스트 서버에 설치된 GPU가 가상머신으로 직접 연결되는 개념을 시각적으로 보여주는 다이어그램입니다.

    2. Proxmox GPU 패스스루, 대체 뭘까요? (개념 설명)

    Proxmox GPU 패스스루(GPU Passthrough)는 말 그대로 호스트 시스템(Proxmox VE)에 장착된 물리적인 그래픽카드를 특정 가상머신에 ‘통째로’ 넘겨주는 기술을 의미합니다. 보통 가상머신은 에뮬레이션된 가상 그래픽 장치를 사용하기 때문에 성능이 제한적이죠. 하지만 패스스루를 사용하면 가상머신이 마치 물리적인 컴퓨터에 그래픽카드가 직접 꽂혀있는 것처럼 GPU의 모든 성능을 활용할 수 있게 됩니다.

    이 기술의 핵심에는 IOMMU (Input/Output Memory Management Unit)라는 하드웨어 기능이 있습니다. IOMMU는 가상머신이 물리적인 장치에 직접 접근할 수 있도록 메모리 주소를 매핑해주는 역할을 해요. 그리고 리눅스 커널의 VFIO (Virtual Function I/O) 드라이버가 이 IOMMU 기능을 활용해서 PCI 장치(GPU 포함)를 가상머신으로 패스스루할 수 있도록 도와줍니다. 쉽게 말해, Proxmox VE 호스트가 GPU에 대한 통제권을 내려놓고, 그 통제권을 특정 가상머신에게 완전히 이양하는 것이라고 보시면 됩니다. 그래서 **Proxmox VE 그래픽카드**를 가상머신에서 완벽하게 활용할 수 있게 되는 거죠. 저도 처음엔 개념이 좀 어려웠는데, 직접 해보면서 ‘아, 이게 이런 원리로 돌아가는구나!’ 하고 깨달았어요.

    3. 실전 구현: Proxmox에서 GPU 패스스루 설정하기

    자, 이제 이론은 충분합니다. 저와 함께 실제로 Proxmox VE에 **가상머신 GPU** 패스스루를 설정해보는 시간을 가져볼까요? 제가 직접 해본 가장 안정적인 방법들을 단계별로 알려드릴게요. 저도 이 과정에서 수많은 시행착오를 겪었거든요. 하나하나 따라오시면 분명 성공하실 수 있을 겁니다! 💡

    1. BIOS/UEFI 설정 확인 및 활성화

      가장 먼저 할 일은 서버의 BIOS/UEFI에서 IOMMU 기능을 활성화하는 것입니다. AMD 시스템에서는 AMD-Vi, Intel 시스템에서는 Intel VT-d라는 이름으로 되어있을 거예요. 이 옵션이 꺼져있으면 GPU 패스스루는 아예 불가능합니다. 저도 처음에 이거 확인 안 했다가 시간 좀 날렸습니다. ⚠️

    2. Proxmox VE 호스트 설정: IOMMU 활성화 및 VFIO 모듈 로드

      Proxmox VE 호스트에서 IOMMU 기능을 커널에 알려주고, VFIO 모듈을 미리 로드해야 합니다. SSH로 접속해서 다음 명령어를 입력하세요.

      # GRUB 설정 파일 수정
      # Intel CPU의 경우
      sudo nano /etc/default/grub
      # GRUB_CMDLINE_LINUX_DEFAULT="quiet" 부분을 찾아 다음과 같이 수정합니다.
      # GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"
      
      # AMD CPU의 경우
      # GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"
      
      # 수정 후 GRUB 업데이트
      sudo update-grub
      
      # VFIO 모듈 로드 설정
      sudo nano /etc/modules
      # 다음 내용을 추가합니다.
      vfio
      vfio_iommu_type1
      vfio_pci
      vfio_virqfd
      
      # blacklist nouveau 드라이버 (NVIDIA GPU 사용 시 필수)
      sudo nano /etc/modprobe.d/blacklist.conf
      # 다음 내용을 추가합니다.
      blacklist nouveau
      options nouveau modeset=0
      
      # GPU 사운드 카드 드라이버 blacklist (HDMI/DisplayPort 오디오 사용 시 충돌 방지)
      sudo nano /etc/modprobe.d/pve-blacklist.conf
      # 다음 내용을 추가합니다.
      blacklist snd_hda_intel
      blacklist snd_hda_codec_hdmi
      blacklist i915 # Intel 내장 그래픽 사용 시 필요
      
      # 초기 램디스크(initramfs) 업데이트 (매우 중요!)
      sudo update-initramfs -u -a
      
      # 재부팅
      sudo reboot

      재부팅 후 `dmesg | grep -i iommu` 명령으로 IOMMU가 성공적으로 활성화되었는지 확인하세요. `DMAR: IOMMU enabled` 같은 메시지가 보이면 성공입니다. 👍

    3. GPU PCI ID 확인 및 VFIO에 바인딩

      이제 여러분의 GPU PCI ID를 확인하고, 이 ID를 VFIO 드라이버에 할당해야 합니다.

      # GPU PCI ID 확인 (VGA compatible controller와 Audio device 부분을 잘 보세요)
      # 예시: 01:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] (rev a1)
      #       01:00.1 Audio device: NVIDIA Corporation GP107GL High Definition Audio Controller (rev a1)
      sudo lspci -nnk | grep -i vga -A3
      sudo lspci -nnk | grep -i audio -A3
      
      # 위에 나온 벤더:디바이스 ID를 기록합니다. (예: 10de:1c8c, 10de:0fb9)
      
      # VFIO에 바인딩할 PCI ID 설정
      sudo nano /etc/modprobe.d/vfio.conf
      # 다음 내용을 추가합니다. (여러분의 PCI ID로 변경하세요!)
      options vfio-pci ids=10de:1c8c,10de:0fb9 disable_vga=1

      다시 `sudo update-initramfs -u -a` 명령으로 초기 램디스크를 업데이트하고, 재부팅합니다. 재부팅 후 `lspci -nnk | grep -i vga -A3` 명령으로 GPU가 `Kernel driver in use: vfio-pci`로 바인딩되었는지 확인하세요. 이게 제일 중요합니다! ✅

    4. 가상머신(VM) 설정

      이제 Proxmox VE 웹 인터페이스에서 GPU를 패스스루할 가상머신을 선택하고, 하드웨어 설정에 들어갑니다. 저도 이 화면에서 얼마나 많은 시도를 했는지 몰라요. ㅎㅎ

      1. 가상머신을 생성하거나 선택합니다. (Windows VM이 일반적입니다)
      2. 하드웨어 탭에서 Add > PCI Device를 클릭합니다.
      3. 이전에 확인했던 GPU의 PCI 장치(VGA compatible controller와 Audio device)를 각각 추가합니다.
      4. 옵션에서 Primary GPU, All Functions, PCI-Express(가능하다면)를 선택합니다.
      5. RomBar를 체크 해제하고, Advanced > PCI-Express를 활성화하는 것이 좋습니다.

    Proxmox VE 웹 인터페이스에서 가상머신의 ‘하드웨어’ 탭에서 ‘PCI Device’를 추가하는 과정과 설정 옵션들을 보여주는 스크린샷입니다.

    4. ⚠️ 삽질 대잔치! Proxmox GPU 패스스루 트러블슈팅 노하우

    솔직히 Proxmox GPU 패스스루는 한 번에 성공하기 쉽지 않습니다. 저도 수많은 밤을 새워가며 삽질 좀 했습니다. 특히 **Proxmox VE 그래픽카드**를 패스스루할 때 발생하는 몇 가지 고질적인 문제들이 있어요. 제가 겪었던 대표적인 문제들과 해결책을 공유해 드릴게요.

    • IOMMU 그룹 문제

      가장 흔한 문제입니다. GPU와 다른 장치들이 같은 IOMMU 그룹에 묶여 있으면, GPU만 단독으로 패스스루할 수 없습니다. `for d in /sys/kernel/iommu_groups/*/devices/*; do n=${d##*/}; dev=$(lspci -nns $n); echo “IOMMU Group ${d%/devices/*##*/}”; echo ” $dev”; done` 명령으로 IOMMU 그룹을 확인해 보세요. 만약 GPU와 다른 장치가 같은 그룹에 있다면, BIOS/UEFI에서 PCI-E 슬롯별 IOMMU 분리가 가능한지 확인하거나, ACS Override 패치를 적용하는 방법도 있지만, 이는 커널을 수정해야 하는 고급 과정이라 초보자에게는 권장하지 않습니다. 저는 이 문제 때문에 메인보드까지 바꿀 뻔했습니다. 😭

    • NVIDIA Error 43

      Windows 가상머신에서 NVIDIA 드라이버를 설치했을 때 ‘코드 43’ 오류가 발생하는 경우가 많습니다. NVIDIA가 가상화 환경에서의 GPU 사용을 제한하려는 조치 때문인데요. 이 문제는 VM 설정에 `args: -cpu host,kvm=off,hv_vendor_id=null`을 추가하거나, 그래픽카드 펌웨어(ROM) 파일을 추출하여 `vga: all,romfile=/path/to/gpu_rom.bin` 옵션을 사용하는 방법으로 해결할 수 있습니다. 저는 `args` 옵션으로 해결했어요. 이거 하나 해결하고 얼마나 기뻤는지 모릅니다! 🎉

      # VM 설정 파일 수정 (VMID를 여러분의 VMID로 변경하세요)
      sudo nano /etc/pve/qemu-server/YOUR_VMID.conf
      # 맨 아래에 다음 줄을 추가합니다.
      args: -cpu host,kvm=off,hv_vendor_id=null
    • HDMI/DisplayPort 오디오 문제

      GPU 패스스루 후 HDMI나 DisplayPort를 통한 오디오 출력이 안 되는 경우가 있습니다. 이는 GPU의 오디오 컨트롤러가 제대로 패스스루되지 않았거나, 호스트의 사운드 드라이버와 충돌하기 때문인데요. 앞서 `pve-blacklist.conf`에 `snd_hda_intel` 등을 blacklist 하는 것으로 대부분 해결됩니다. 저도 이 때문에 한참을 헤맸는데, 간단한 설정으로 해결될 때의 쾌감이란! 😆

    • VM 부팅 시 블랙 스크린

      VM 부팅 시 화면이 아예 안 나오는 경우가 있습니다. 이는 주로 `vga` 옵션 설정 문제입니다. VM 설정에서 `Display`를 `none`으로 설정하고, `vga` 옵션에서 `all` 대신 `qxl` 또는 `virtio`를 시도해보세요. 그리고 패스스루한 GPU를 `Primary GPU`로 설정하는 것도 잊지 마세요.

    5. 드디어 성공! Proxmox 게이밍 VM (검증 및 결과)

    이 모든 삽질과 노력을 거쳐 드디어 **Proxmox 게이밍 VM**이 제 기능을 하는 순간을 맞이했습니다! 가상머신에 Windows를 설치하고, GPU 드라이버를 설치한 다음 장치 관리자를 열어보세요. 여러분의 물리적인 그래픽카드가 ‘디스플레이 어댑터’ 목록에 제대로 인식되어 있다면 성공입니다! ✅

    저는 Windows 10 VM에 NVIDIA RTX 3070을 패스스루해서 게임을 돌려봤는데, 놀랍게도 물리적인 PC에서 돌리는 것과 거의 차이 없는 성능을 보여주더라고요. 벤치마크 점수도 만족스러웠고요. 3DMark 같은 툴로 테스트해봐도 점수가 잘 나옵니다. 이 감동은 직접 경험해보셔야 알 수 있습니다. 드디어 하나의 서버로 게임도 하고, 서버도 돌리는 진정한 홈랩을 구축한 거죠! 😎

    Windows 가상머신 내부의 장치 관리자 화면으로, 패스스루된 NVIDIA 그래픽카드가 ‘디스플레이 어댑터’ 목록에 오류 없이 정상적으로 인식된 상태를 보여줍니다.

    6. Proxmox GPU 패스스루, 그래서 뭐가 좋을까요? (장단점)

    이렇게 힘들게 Proxmox GPU 패스스루를 설정했는데, 과연 어떤 장점과 단점이 있을까요? 제가 직접 경험해본 바를 바탕으로 정리해봤습니다.

    장점 (Pros) 단점 (Cons)
    고성능 그래픽 작업 가능: 가상머신에서 게임, 딥러닝, 영상 편집 등 GPU 자원이 필요한 작업을 원활하게 수행할 수 있습니다. 복잡한 설정 과정: 초기 설정이 매우 복잡하고, 트러블슈팅에 많은 시간과 지식이 필요합니다.
    하드웨어 통합 및 비용 절감: 여러 대의 물리적인 PC 대신 하나의 강력한 서버로 다양한 용도의 VM을 운영할 수 있어 공간과 비용을 절약할 수 있습니다. 호환성 문제: 모든 메인보드, CPU, GPU 조합이 완벽하게 호환되는 것은 아닙니다. 특히 IOMMU 그룹 문제가 발생하기 쉽습니다.
    유연한 자원 할당: 필요에 따라 GPU를 다른 VM으로 할당 변경하거나, 여러 GPU를 각각 다른 VM에 할당할 수 있습니다. 호스트 자원 제약: GPU 패스스루를 사용하면 호스트 시스템은 해당 GPU를 사용할 수 없으며, 호스트의 그래픽 출력이 제한될 수 있습니다.
    운영체제 독립성: Windows, Linux 등 원하는 운영체제에 GPU를 할당하여 사용할 수 있습니다. 전력 소모 및 발열 증가: 고성능 GPU를 사용하면 서버의 전력 소모와 발열이 크게 증가할 수 있습니다.

    Proxmox GPU 패스스루의 주요 장점(고성능 작업, 비용 절감, 유연성)과 단점(복잡한 설정, 호환성 문제, 자원 제약)을 시각적으로 요약한 인포그래픽입니다.

    7. 마무리하며: 다음 도전은 무엇일까요?

    오늘은 Proxmox VE에서 **Proxmox GPU 패스스루**를 통해 가상머신에서 그래픽카드를 활용하는 방법을 자세히 알아봤습니다. 쉽지 않은 과정이었지만, 한번 성공하고 나면 그 만족감은 정말 크실 겁니다. 저도 이 과정을 통해 하드웨어와 가상화 기술에 대한 이해를 한층 더 깊게 할 수 있었어요. 사실 이게 바로 홈랩의 매력이 아닐까 싶습니다. 직접 삽질하고 성공하면서 배우는 것들이 정말 많거든요.

    여러분도 이 가이드를 통해 성공적으로 **가상머신 GPU**를 설정하고, 꿈에 그리던 **Proxmox 게이밍 VM**이나 딥러닝 워크스테이션을 구축하시길 바랍니다. 혹시 더 궁금한 점이나 막히는 부분이 있다면 언제든지 댓글로 질문해주세요. 제가 아는 한에서 최대한 도와드리겠습니다.

    다음번에는 Proxmox에서 USB 패스스루를 통해 로컬 저장 장치나 보안 동글을 가상머신에 연결하는 방법에 대해서도 다뤄볼 예정입니다. 계속해서 ’13년차의 서버실’에 많은 관심 부탁드립니다! 감사합니다. 👋