13년차의 서버실

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

[카테고리:] proxmox

  • [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 Backup Server (PBS) vs. 스크립트 백업: 홈랩 비용 효율성 비교

    [Proxmox] Proxmox Backup Server (PBS) vs. 스크립트 백업: 홈랩 비용 효율성 비교

    홈랩 백업, 정말 고민되시죠? Proxmox Backup Server (PBS) vs. 스크립트 백업 비용 효율성 비교

    안녕하세요, 13년차의 서버실 주인장입니다. 홈랩을 운영하면서 가장 중요하게 생각하는 것 중 하나가 바로 백업(Backup)입니다. 아니, 중요하게 생각해야만 하는 것이죠. 처음엔 저도 ‘설마 내 데이터가 날아가겠어?’ 하는 안일한 생각으로 버텼습니다. 그러다 한 번 크게 데이터 유실(Data Loss)을 겪고 나서야 정신을 차렸죠. 그 이후로 백업은 제 홈랩 운영의 제1원칙이 되어 버렸습니다.

    특히 Proxmox VE(Virtual Environment)를 사용하시는 분들이라면, 가상 머신(VM)이나 컨테이너(LXC) 백업에 대한 고민이 많으실 거예요. 스냅샷(Snapshot)만 믿고 계신 건 아니겠죠? 스냅샷은 편리하지만, 물리적 저장 장치에 문제가 생기면 함께 날아간다는 치명적인 단점이 있습니다. 그래서 별도의 백업 솔루션이 필수적인데, 여기서 많은 분들이 Proxmox Backup Server (PBS)를 쓸지, 아니면 스크립트 기반의 백업을 직접 구현할지 고민하시더라고요. 저도 그랬거든요!

    오늘은 13년차 인프라 엔지니어의 경험을 바탕으로 이 두 가지 Proxmox 백업 전략의 비용 효율성(Cost Efficiency)을 비교 분석해보고, 홈랩 환경에서 어떤 선택이 더 현명할지 함께 이야기해보려 합니다. 특히 Proxmox Backup Server 비용에 대한 오해도 풀어드릴게요!

    Proxmox Backup Server와 스크립트 백업 아키텍처 비교 다이어그램

    Proxmox Backup Server와 기존 스크립트 백업 솔루션을 비교하는 개략적인 아키텍처 다이어그램입니다. 각 방식의 데이터 흐름과 구성 요소를 시각적으로 보여줍니다.

    Proxmox Backup Server (PBS)와 스크립트 백업, 뭐가 다를까요?

    우선 두 가지 방식의 핵심 개념부터 간단히 짚고 넘어가겠습니다. 쉽게 말해 이렇습니다.

    • Proxmox Backup Server (PBS): Proxmox 개발사에서 공식적으로 제공하는 전용 백업 솔루션이죠. Proxmox VE와 완벽하게 통합되어 VM, LXC 백업 및 복원을 쉽고 효율적으로 처리할 수 있도록 설계되었습니다.
    • 스크립트 백업 (Script Backup): rsync, dd, tar 같은 리눅스 명령어나 Proxmox VE 자체의 vzdump 명령어를 활용하여 직접 스크립트를 짜서 백업을 수행하는 방식입니다. 특정 백업 스토리지를 마운트해서 데이터를 밀어 넣는 형태가 되겠죠.

    PBS의 가장 큰 장점은 바로 중복 제거(Deduplication)와 증분 백업(Incremental Backup)입니다. 예를 들어, 제가 Ubuntu VM을 여러 개 돌리고 있는데, 얘네들이 대부분 비슷한 OS 파일을 가지고 있잖아요? PBS는 이 중복되는 블록을 한 번만 저장하고, 변경된 부분만 추가로 저장해서 저장 공간을 엄청나게 절약해줍니다. 그리고 백업 데이터의 무결성 검사(Data Integrity Check) 기능도 강력해서, 백업 데이터가 손상되지 않았는지 주기적으로 확인해주는 점도 정말 마음이 놓이더라고요.

    반면 스크립트 백업은 모든 것을 직접 제어할 수 있다는 장점이 있습니다. 원하는 대로 커스터마이징(Customizing)이 가능하고, 이미 있는 리소스(Resource)를 활용해서 추가적인 소프트웨어 설치 없이 바로 사용할 수 있거든요. 하지만 중복 제거 같은 고급 기능은 직접 구현하기 어렵고, 백업 데이터의 관리가 번거로울 수 있습니다.

    PBS, 직접 써보니 이렇더라고요! (실전 구현)

    제가 PBS를 처음 써봤을 때 느꼈던 감정은 ‘와, 이거 진짜 편하네!’ 였습니다. 사실 처음엔 PBS를 위한 별도의 서버나 VM을 구성해야 한다는 생각에 약간의 진입 장벽을 느꼈거든요. ‘그냥 vzdump로 NAS에 밀어 넣으면 안 되나?’ 싶었죠. 근데 PBS를 설치하고 Proxmox VE에 백업 스토리지로 연결해보니, 그 편리함에 금세 빠져들었습니다.

    설치 자체는 Proxmox VE와 마찬가지로 ISO 이미지를 통해 쉽게 할 수 있습니다. 혹은 기존 리눅스 서버에 패키지로 설치하는 것도 가능하더라고요. 저는 홈랩에서 쓰지 않는 미니 PC에 PBS를 설치하거나, Proxmox VE 위에 하나의 VM으로 올려서 사용하기도 했습니다. (물론 이 경우 백업 대상 VM과 동일한 물리 서버에 있으면 안 되겠죠?)

    # PBS 설치 후 Proxmox VE에서 백업 스토리지 추가하는 예시
    # Datacenter -> Storage -> Add -> Proxmox Backup Server 선택
    # ID: pbs-backup
    # Server: [PBS 서버 IP 또는 도메인]
    # Port: 8007 (기본값)
    # Username: root@pam
    # Password: [PBS root 비밀번호]
    # Datastore: [PBS 데이터스토어 이름, 예: mybackup]
    

    이렇게 PBS 스토리지를 Proxmox VE에 연결하고 나면, 백업 스케줄(Backup Schedule)을 설정하는 게 정말 간단해집니다. 웹 UI에서 몇 번의 클릭만으로 특정 VM이나 모든 VM을 원하는 주기로 백업하도록 설정할 수 있어요. 압축(Compression) 알고리즘 선택부터 보존 정책(Retention Policy) 설정까지 GUI(Graphical User Interface)로 모든 걸 처리할 수 있다는 게 가장 큰 장점이죠. 백업이 성공적으로 완료되면 Proxmox VE 로그에도 잘 남고요. ✅

    Proxmox Backup Server 웹 인터페이스 백업 스케줄 설정

    Proxmox Backup Server의 웹 인터페이스에서 백업 스케줄을 설정하는 화면입니다. 직관적인 GUI를 통해 쉽게 백업 정책을 관리할 수 있습니다.

    스크립트 백업, 장단점 명확합니다 (실전 구현)

    PBS가 나오기 전, 그리고 지금도 많은 분들이 스크립트 백업을 사용하고 계십니다. 저 역시 PBS를 알기 전에는 주로 vzdump 명령어를 활용한 스크립트 백업을 애용했었죠. 다음은 간단한 스크립트 백업 예시입니다.

    #!/bin/bash
    
    # 백업 대상 VM/LXC ID
    VM_IDS="100 101 102"
    
    # 백업 저장 경로 (NFS 또는 SMB 마운트된 디렉토리)
    BACKUP_DIR="/mnt/pve/nas_backup/vzdump"
    
    # 백업 파일 보존 일수
    RETENTION_DAYS=7
    
    # 백업 실행
    for VM_ID in $VM_IDS;
    do
      echo "$(date '+%Y-%m-%d %H:%M:%S') - Starting backup for VM/LXC $VM_ID..."
      vzdump $VM_ID --mode snapshot --compress zstd --storage local-lvm --dumpdir $BACKUP_DIR
      if [ $? -eq 0 ]; then
        echo "$(date '+%Y-%m-%d %H:%M:%S') - Backup for VM/LXC $VM_ID completed successfully."
      else
        echo "$(date '+%Y-%m-%d %H:%M:%S') - Backup for VM/LXC $VM_ID failed!" >&2
      fi
    done
    
    # 오래된 백업 파일 삭제 (보존 정책)
    echo "$(date '+%Y-%m-%d %H:%M:%S') - Cleaning up old backup files..."
    find $BACKUP_DIR -type f -name "vzdump-*.vma.zst" -mtime +$RETENTION_DAYS -delete
    
    echo "$(date '+%Y-%m-%d %H:%M:%S') - Backup script finished."
    

    이 스크립트를 cron에 등록해서 주기적으로 실행하면, 원하는 VM들을 백업할 수 있습니다. 장점은 명확해요. 자유로운 커스터마이징이 가능하고, 별도의 소프트웨어 설치 없이 Proxmox VE에 내장된 기능만으로 백업을 구현할 수 있다는 점이죠. 기존에 가지고 있던 NAS나 여분의 하드디스크를 마운트해서 백업 저장소로 활용하기도 좋습니다.

    하지만 단점도 있습니다. ⚠️

    • 중복 제거 기능 부재: VM이 많아질수록 백업 공간을 비효율적으로 사용하게 됩니다.
    • 수동 관리의 번거로움: 스크립트 오류, 저장 공간 부족, 백업 성공 여부 확인 등을 직접 관리하고 모니터링해야 합니다.
    • 복원 과정의 복잡성: PBS처럼 웹 UI에서 클릭 몇 번으로 복원하는 것이 아니라, 명령어를 사용해야 합니다.
    • 데이터 무결성 검사 부재: 백업 파일이 손상되었는지 주기적으로 확인하는 기능이 없습니다.

    특히 중복 제거 기능이 없다는 것은 Proxmox Backup Server 비용 측면에서 간과할 수 없는 부분입니다. 백업 데이터가 늘어나면 늘어날수록 더 많은 저장 장치(Storage)를 구매해야 할 수도 있거든요.

    스크립트 기반 백업 구성도 및 데이터 흐름

    스크립트 기반 백업의 구성도와 데이터 흐름을 보여주는 다이어그램입니다. Proxmox VE에서 백업 스크립트가 실행되어 외부 저장소로 데이터를 전송하는 과정을 나타냅니다.

    비용 효율성, 과연 어떤 선택이 현명할까요?

    자, 그럼 가장 중요한 비용 효율성 측면에서 PBS와 스크립트 백업을 비교해볼까요? 여기서 말하는 ‘비용’은 단순히 하드웨어 구매 비용뿐만 아니라, 시간(Time)과 노력(Effort)까지 포함한 개념입니다. 홈랩에서는 이 ‘시간’ 비용이 생각보다 훨씬 중요하거든요. 제 경험상 삽질하는 시간은 곧 기회비용입니다.

    기준 Proxmox Backup Server (PBS) 스크립트 백업
    초기 설정 시간 별도 서버/VM 구성 필요, Proxmox VE와 연동 용이 (중간) 스크립트 작성 및 테스트 필요 (중간~높음)
    운영 및 관리 시간 웹 UI 기반, 자동화된 스케줄, 모니터링 기능 (낮음) 스크립트 유지보수, 수동 모니터링 필요 (높음)
    저장 공간 효율성 강력한 중복 제거, 증분 백업으로 공간 절약 (매우 높음) 일반적인 압축만 가능, 중복 제거 부재 (낮음)
    하드웨어 비용 별도의 서버/VM 필요 (낮은 사양으로도 충분) (중간) 기존 저장 장치 활용 가능 (낮음)
    데이터 무결성 정기적인 무결성 검사 기능 내장 (매우 높음) 수동 검증 필요, 오류 시 발견 어려움 (낮음)
    복구 편의성 웹 UI에서 쉽고 빠르게 복원 가능 (매우 높음) 명령어 기반, 복잡할 수 있음 (낮음)

    결론부터 말씀드리면, 장기적인 관점에서 Proxmox Backup Server 비용은 스크립트 백업보다 더 효율적일 가능성이 높습니다.

    • 저장 공간 절약: PBS의 중복 제거 기능은 시간이 지남에 따라 엄청난 저장 공간을 절약해줍니다. 이는 곧 추가적인 하드디스크 구매 비용을 줄여준다는 의미입니다. 홈랩에서 데이터가 늘어나는 속도는 상상 이상이더라고요.
    • 시간 절약: 백업 스케줄 설정, 모니터링, 복원 과정의 편리함은 제 소중한 시간을 아껴줍니다. 이 시간을 새로운 기술을 배우거나, 다른 홈랩 프로젝트에 투자할 수 있죠. 삽질 경험을 줄여주는 것이 진정한 비용 절감입니다!
    • 안정성: 데이터 무결성 검사와 쉬운 복구는 만약의 사태에 대비한 훌륭한 보험입니다. 데이터 유실로 인한 정신적, 시간적 손실을 생각하면 PBS의 가치는 더욱 빛을 발합니다.

    물론 PBS를 위한 최소한의 하드웨어(저전력 미니 PC나 라즈베리 파이 같은 SBC에 외장 HDD 연결)는 필요합니다. 하지만 이 초기 투자는 위에서 언급한 장점들로 충분히 상쇄된다고 저는 확신합니다. 특히 홈랩 백업 솔루션을 고민하고 계시다면, PBS는 정말 훌륭한 선택지입니다. 💡

    Proxmox Backup Server와 스크립트 백업의 핵심 장단점 및 장기적인 비용 효율성을 비교하는 인포그래픽입니다.

    삽질 피하기! 제가 겪은 트러블슈팅 경험

    제가 PBS와 스크립트 백업을 사용하면서 겪었던 몇 가지 삽질 경험과 그 해결책을 공유해드릴게요. ⚠️

    1. 스크립트 백업의 저장 공간 부족 알림 부재: 처음 스크립트 백업을 쓸 때는 공간이 부족해지는 걸 모르고 있다가 백업이 실패하는 경우가 많았습니다. 해결책은 간단하더라고요. 디스크 사용량을 체크하는 스크립트를 추가하고, 특정 임계치(Threshold)를 넘으면 제게 이메일이나 메신저로 알림을 보내도록 설정했습니다.
    2. PBS 데이터스토어 용량 부족: PBS는 중복 제거가 강력하지만, 그래도 물리적인 용량은 한계가 있습니다. 특히 백업 데이터를 장기간 보존(Long-term Retention)하다 보면 용량이 차오르죠. PBS 웹 UI에서 데이터스토어 용량을 주기적으로 확인하고, 필요 없는 오래된 백업 스냅샷을 Prune(가지치기) 작업으로 정리해줘야 합니다.
    3. 네트워크 대역폭 문제: 백업은 생각보다 네트워크 자원을 많이 사용합니다. 특히 무거운 VM을 백업할 때, 홈랩 네트워크가 느려지거나 다른 서비스에 영향을 주는 경우가 있었어요. 백업 스케줄을 사용량이 적은 새벽 시간대로 조절하거나, PBS 서버와 Proxmox VE 간의 네트워크를 분리(Dedicate)하는 방법을 사용했습니다.
    4. 권한 문제: 스크립트 백업 시 vzdump 명령어가 특정 디렉토리에 접근하지 못하거나, 마운트된 NAS에 쓰기 권한이 없는 경우가 있었습니다. sudo 권한이나 파일 시스템 권한(chmod, chown)을 꼼꼼하게 확인하는 것이 중요합니다. PBS는 Proxmox VE와의 통합이 잘 되어있어서 이런 권한 문제는 거의 발생하지 않더라고요.

    이런 삽질들을 겪으면서 느낀 건, 결국 자동화되고 안정적인 시스템이 장기적으로 훨씬 이득이라는 점입니다. PBS는 이런 면에서 훌륭한 해결책을 제공해주더군요.

    Proxmox Backup Server 대시보드: 백업 성공률 및 데이터스토어 상태

    Proxmox Backup Server 대시보드에서 백업 성공률과 데이터스토어 상태를 한눈에 확인할 수 있는 스크린샷입니다.

    마무리: 나에게 맞는 백업 전략 찾기

    지금까지 Proxmox Backup Server (PBS)와 스크립트 백업의 장단점, 그리고 비용 효율성을 제 경험을 바탕으로 비교해봤습니다. 어떤 방식이 ‘절대적으로 좋다’고 단정하기는 어렵습니다. 홈랩 환경은 저마다 다르니까요.

    • 나는 최소한의 비용으로 바로 백업을 시작하고 싶다!
      : 기존에 여분의 저장 장치나 NAS가 있고, 스크립트 작성 및 관리에 익숙하시다면 스크립트 백업도 좋은 시작이 될 수 있습니다. 하지만 장기적인 관리 비용과 데이터 무결성에는 더 많은 노력을 기울여야 할 거예요.
    • 나는 백업에 시간을 많이 쓰고 싶지 않다. 안정적이고 효율적인 솔루션을 원한다!
      : PBS는 초기 설치에 약간의 리소스가 필요하지만, 일단 구축하고 나면 백업 관리의 대부분을 자동화해주고, 저장 공간을 효율적으로 사용하며, 강력한 데이터 무결성 검사 기능을 제공합니다. 장기적인 관점에서 Proxmox Backup Server 비용은 시간과 노력 측면에서 훨씬 합리적입니다.

    결론적으로 저는 PBS를 강력하게 추천합니다. 특히 홈랩에서 여러 VM과 LXC를 운영하며 VM 백업의 중요성을 느끼고 계시다면, PBS는 여러분의 소중한 데이터를 지켜주는 든든한 파트너가 될 것입니다. 🎉

    다음 글에서는 PBS를 처음 설치하고 Proxmox VE와 연동하는 구체적인 방법에 대해 다뤄볼 예정입니다. 기대해주세요!

  • [Proxmox] GPU 패스스루: 가상 머신 성능 문제 디버깅하기

    [Proxmox] GPU 패스스루: 가상 머신 성능 문제 디버깅하기

    [Proxmox] GPU 패스스루: 가상 머신 성능 문제 디버깅하기

    안녕하세요! 13년차의 서버실, 인프라 엔지니어 박 사장입니다. 오늘은 제가 홈랩에서 정말 많이 삽질했던 경험 중 하나인 Proxmox GPU 패스스루(Passthrough)에 대한 이야기를 해볼까 합니다. 다들 설레는 마음으로 Proxmox에 GPU 패스스루를 세팅하고, 가상 머신(VM)을 켰는데, 웬걸? 생각보다 성능이 안 나와서 당황한 경험 있으신가요? 저도 처음엔 이게 뭔가 싶어서 밤샘 디버깅을 밥 먹듯이 했었거든요. 오늘은 그 삽질의 결과물, 즉 GPU 패스스루 시 겪을 수 있는 성능 문제와 그 해결 과정을 멘토처럼 알려드리겠습니다. ⚠️ 특히 NVIDIA Error 43 같은 골치 아픈 문제 해결 팁도 있으니 끝까지 주목해주세요!

    Proxmox에서 GPU 패스스루를 구현했을 때의 전체적인 아키텍처를 시각화한 다이어그램이에요. 호스트와 게스트 OS 간의 GPU 자원 전달 과정이 어떻게 흘러가는지 한눈에 볼 수 있습니다.

    💡 Proxmox GPU 패스스루와 VFIO, 왜 중요할까요?

    Proxmox GPU 패스스루(Passthrough)는 쉽게 말해 물리적인 서버에 꽂힌 GPU(그래픽 처리 장치)를 가상 머신(VM, Virtual Machine)에 통째로 할당해주는 기술입니다. 호스트 OS(Proxmox가 설치된 리눅스)는 해당 GPU에 대한 제어권을 내려놓고, 그 제어권을 게스트 OS(VM 내부의 Windows나 Linux)가 직접 가져가서 사용하게 하는 거죠. 이렇게 하면 가상 환경에서도 물리 GPU의 성능을 거의 그대로 활용할 수 있게 됩니다. 게임 서버, AI 학습, 미디어 트랜스코딩 등 고성능 그래픽 처리가 필요한 작업에 필수적이죠.

    이 기술의 핵심에는 VFIO (Virtual Function I/O)라는 프레임워크가 있습니다. VFIO는 호스트 OS가 특정 하드웨어 장치(여기서는 GPU)에 대한 제어권을 포기하고, 그 제어권을 게스트 OS가 직접 가져갈 수 있도록 해주는 메커니즘을 제공합니다. 덕분에 게스트 OS는 GPU를 마치 물리 머신에 직접 연결된 것처럼 사용할 수 있게 되는 겁니다. 저도 처음엔 이 VFIO 개념이 좀 헷갈렸는데, 쉽게 생각하면 ‘직통 연결 통로’를 만들어주는 거라고 보시면 돼요.

    문제는 이 과정이 생각보다 복잡하고, 작은 설정 실수 하나로 성능 저하나 오류가 발생할 수 있다는 겁니다. 특히 Proxmox GPU 패스스루를 하려는 분들이 가장 많이 겪는 문제가 바로 ‘설정은 다 했는데 왜 성능이 안 나오지?’ 하는 부분이죠.

    🛠️ 기본적인 Proxmox GPU 패스스루 설정 요약

    사실 Proxmox에서 GPU 패스스루를 위한 기본적인 설정(BIOS에서 IOMMU 활성화, vfio 모듈 활성화, 커널 매개변수 추가 등)은 다른 좋은 자료들이 많으니 여기서는 간략히 언급하고 넘어가겠습니다. 오늘은 이미 기본적인 세팅은 마쳤다는 가정하에, 성능 문제 디버깅에 집중할 거거든요.

    1. BIOS/UEFI 설정: IOMMU (Intel VT-d 또는 AMD-Vi) 기능을 반드시 활성화해야 합니다. 이게 안 되면 VFIO 자체가 작동하지 않아요.
    2. 커널 모듈 활성화: vfio, vfio_iommu_type1, vfio_pci 등의 모듈을 로드하고, 블랙리스트에 GPU 드라이버(nouveau, amdgpu, nvidia)를 추가해 호스트 OS가 GPU를 점유하지 않도록 합니다.
    3. GPU ID 확인 및 격리: lspci -nns [PCI ID] 등으로 GPU의 Vendor ID와 Device ID를 확인하고, /etc/modprobe.d/vfio.conf 파일에 해당 ID를 추가하여 VFIO 모듈이 GPU를 독점하도록 설정합니다.
    4. VM 설정 변경: Proxmox 웹 UI에서 VM 하드웨어에 PCI Device로 GPU를 추가하고, 필요한 경우 Primary GPU 옵션이나 ROM-Bar 옵션을 활성화합니다.

    여기까지 했는데도 문제가 생겼다면, 이제부터가 진짜 디버깅의 시작입니다!

    Proxmox 가상 머신에 PCI 장치(GPU) 추가 설정 화면

    Proxmox 웹 UI에서 가상 머신에 PCI 장치(GPU)를 추가하는 설정 화면이에요. 이 화면에서 어떤 GPU를 선택하고 어떤 옵션을 적용할지 결정하게 됩니다.

    ⚠️ Proxmox GPU 패스스루 성능 문제 디버깅하기

    1. NVIDIA Error 43: 가장 흔하고 짜증나는 문제!

    제가 Proxmox GPU 패스스루를 하면서 제일 많이 삽질했던 부분이 바로 이 NVIDIA Error 43입니다. Windows VM에서 장치 관리자를 열었을 때 그래픽 카드에 느낌표가 뜨면서 Code 43 오류가 발생하면 정말 미쳐버리죠. 드라이버 문제인 줄 알고 온갖 버전을 다 깔아봤는데도 안 됐었거든요.

    원인: NVIDIA 드라이버가 가상 환경에서 실행 중임을 감지하고 기능을 제한해버린다는 거예요. 일종의 ‘가상화 감지’ 보호 메커니즘이죠.

    해결책:

    1. KVM 가상화 숨기기 (VM 설정): Proxmox가 KVM이라는 하이퍼바이저를 사용하고 있다는 사실을 게스트 OS에 숨겨야 합니다. VM 설정을 통해 QEMU 인자를 추가해줍니다.
    2. 
      qm set [VMID] -args '-cpu host,kvm=off,hv_vendor_id=null'
      # 예시: qm set 100 -args '-cpu host,kvm=off,hv_vendor_id=null'
      

      여기서 [VMID]는 여러분의 가상 머신 ID예요. kvm=off는 KVM 기능을 비활성화하는 것이 아니라, KVM 하이퍼바이저가 존재한다는 사실을 게스트 OS에 알리지 않는 역할을 합니다. hv_vendor_id=null은 하이퍼바이저 벤더 ID를 숨깁니다.

    3. KVM MSR(Model Specific Register) 무시 (호스트 설정): 호스트에서 KVM 모듈에 특정 MSR을 무시하도록 지시하여 가상화 감지를 더 어렵게 만듭니다.
    4. 
      echo "options kvm ignore_msrs=1" > /etc/modprobe.d/kvm.conf
      update-initramfs -u -k all
      reboot
      

      이 설정을 추가하고 update-initramfs로 initramfs를 업데이트한 뒤 재부팅하면, 게스트 OS가 가상 환경임을 감지하기가 정말 어려워진다는 거죠. 저도 이 방법을 쓰고 나서야 드디어 Error 43에서 벗어날 수 있었어요! 🎉

    2. IOMMU 그룹 분리 문제: 장치가 제대로 격리되지 않을 때

    IOMMU (Input/Output Memory Management Unit) 그룹은 패스스루의 근간입니다. IOMMU 그룹이 제대로 분리되지 않으면, 패스스루하려는 GPU와 다른 장치들이 같은 그룹에 묶여 있어 패스스루 자체가 안 되거나, 안정성 문제가 생기거든요.

    확인 방법:

    
    find /sys/kernel/iommu_groups/ -type l
    # 또는 특정 장치의 IOMMU 그룹 확인
    lspci -nnv | grep -i "VGA compatible controller"
    

    만약 GPU와 다른 중요한 장치(예: SATA 컨트롤러)가 같은 그룹에 묶여 있다면 문제가 됩니다.

    해결책:

    • PCIe 슬롯 변경: 물리적으로 GPU를 다른 PCIe 슬롯에 꽂아보세요. 간혹 슬롯에 따라 IOMMU 그룹이 달라지는 경우가 있습니다.
    • PCIe ACS Override 패치: Proxmox 호스트의 커널에 PCIe ACS Override 패치를 적용하는 방법이 있습니다. 이 패치는 IOMMU 그룹을 강제로 분리시키는 역할을 하지만, 시스템의 안정성을 해칠 수 있으므로 ⚠️ 주의해서 사용해야 합니다. 저도 정말 최후의 수단으로 사용했던 기억이 있네요.

    3. 성능 저하 (병목 현상): 할당 리소스 점검

    Error 43은 해결했지만 막상 게임이나 AI 학습을 돌려보니 성능이 기대에 못 미친다면, 리소스 할당이나 설정 최적화를 의심해봐야 합니다.

    • PCIe 슬롯 대역폭: 혹시 GPU를 낮은 대역폭의 PCIe 슬롯(예: x16 대신 x8, x4)에 꽂은 건 아닌지 확인해보세요. 대역폭이 충분하지 않으면 GPU 성능을 100% 활용하기 어렵습니다. 메인보드 매뉴얼을 확인하는 게 가장 정확합니다.
    • CPU 코어/스레드 할당: VM에 충분한 CPU 코어와 스레드를 할당했는지 확인해야 합니다. VM에 CPU 코어를 너무 적게 주면 GPU가 아무리 좋아도 병목이 생겨요. 보통 물리 코어 수의 절반 이상을 할당하는 것이 좋습니다.
    • RAM 할당: VRAM(GPU 자체 메모리) 외에 VM에 할당된 시스템 RAM도 중요합니다. 특히 고사양 게임이나 AI 학습 시에는 충분한 RAM이 필수적입니다.
    • QEMU/KVM 최적화 옵션: VM 설정에서 QEMU 인자를 추가하여 성능을 최적화할 수 있습니다.
    • 
      qm set [VMID] -args '-cpu host,hv_time,hv_vapic,hv_spinlocks=0x1fff,hv_relaxed,hv_reset,hv_vpindex,hv_runtime,hv_synic,hv_stimer,hv_ipi,hv_eoi,pv_unhalt,kvm=off,l3-cache=on'
      

      이 옵션들은 KVM의 하이퍼바이저 기능을 최적화하여 게스트 OS의 성능을 향상시키는 데 도움을 줍니다. l3-cache=on은 L3 캐시를 활성화하여 CPU 성능에 긍정적인 영향을 줍니다.

    • Display Output (VMware/SPICE) 비활성화: Proxmox GPU 패스스루를 사용하는 경우, VM의 디스플레이 장치로 VMware나 SPICE 같은 가상 디스플레이를 켜두면 충돌하거나 불필요한 오버헤드가 생길 수 있습니다. 패스스루한 GPU를 유일한 디스플레이 장치로 설정하고, 다른 가상 디스플레이는 모두 끄는 것이 좋습니다.

    4. 사운드 장치 패스스루: HDMI 오디오도 잊지 마세요!

    대부분의 최신 그래픽 카드에는 HDMI나 DisplayPort를 통한 오디오 출력 기능이 내장되어 있습니다. Proxmox GPU 패스스루를 할 때 이 오디오 장치를 함께 패스스루하지 않으면, VM에서 소리가 안 나오거나 문제가 발생할 수 있습니다.

    확인 및 해결:

    1. lspci -nnv | grep -i audio 명령어로 GPU에 연결된 오디오 장치의 ID를 확인합니다.
    2. GPU의 비디오 장치와 오디오 장치가 같은 IOMMU 그룹에 속해 있는지 확인합니다. 대부분은 같은 그룹에 있습니다.
    3. VM 설정에서 GPU의 비디오 장치와 함께 오디오 장치도 PCI Device로 추가해줍니다. 이 두 장치를 모두 한 VM에 할당해야 정상적으로 소리가 나옵니다.

    ✅ 검증 및 결과 확인

    모든 설정을 마치고 디버깅까지 끝냈다면, 이제 Proxmox GPU 패스스루가 제대로 작동하는지 확인해볼 차례입니다. 게스트 OS에 접속해서 다음을 확인해보세요.

    • 장치 관리자 (Windows) / nvidia-smi (Linux): GPU가 정상적으로 인식되고 드라이버가 잘 설치되었는지 확인합니다. 더 이상 느낌표나 오류 코드가 없어야 합니다.
    • 벤치마크 툴: 3DMark, FurMark, Unigine Heaven/Superposition 같은 벤치마크 툴을 실행하여 GPU의 실제 성능을 측정해봅니다. 예상했던 성능 수치가 나오는지 확인하는 것이 중요합니다.
    • 실제 사용: 게임을 돌려보거나, AI 학습 스크립트를 실행해 보면서 체감 성능을 확인합니다.

    드디어 제대로 된 성능이 나오는 걸 보면 그렇게 뿌듯할 수가 없어요! 🎉 그동안의 삽질이 보상받는 느낌이랄까요? 저도 처음엔 수많은 시행착오를 겪었지만, 하나씩 문제를 해결해나가는 과정이 결국 저의 경험치를 올려주더라고요.

    Proxmox GPU 패스스루 후 게스트 OS 벤치마크 결과

    가상 머신 내부에서 실행된 벤치마크 프로그램의 결과 화면이에요. 패스스루된 GPU가 정상적으로 작동하면서 기대하던 성능을 제대로 내고 있는 모습을 볼 수 있습니다.

    마무리하며: 삽질은 경험치를 올려주는 최고의 자산!

    오늘은 Proxmox GPU 패스스루 설정 후 가상 머신에서 발생할 수 있는 성능 문제들을 디버깅하는 저의 경험을 공유해드렸습니다. 특히 NVIDIA Error 43과 같은 고질적인 문제부터 IOMMU 그룹 분리, 그리고 리소스 할당 최적화까지 다양한 관점에서 살펴봤는데요. 사실 이 모든 과정이 결코 쉽지는 않았습니다. 저도 수많은 밤을 새워가며 구글링하고, 포럼을 뒤적이며 해결책을 찾아다녔으니까요. 😅

    하지만 결국 이런 ‘삽질’들이 쌓여서 지금의 제가 될 수 있었다고 생각합니다. 단순히 기술을 적용하는 것을 넘어, 문제가 생겼을 때 스스로 해결할 수 있는 능력이 인프라 엔지니어에게는 가장 중요한 자산이거든요. 혹시 여러분도 Proxmox VFIO-PCI 설정에 어려움을 겪고 있다면, 오늘 제가 알려드린 팁들이 도움이 되었으면 좋겠습니다.

    다음번엔 오늘 다룬 Proxmox 그래픽 카드 패스스루를 활용해서 홈랩에 AI/머신러닝 작업 환경을 구축하는 방법에 대해 이야기해볼까 합니다. 그때까지 여러분의 서버실에 평화가 가득하기를 바랍니다! 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 제가 아는 선에서 최대한 도와드리겠습니다.

    Proxmox GPU 패스스루 문제 해결을 위한 디버깅 흐름도

    Proxmox GPU 패스스루 설정 시 발생할 수 있는 주요 문제점과 그 해결책을 시각적으로 정리한 흐름도예요. 디버깅 과정에서 어떤 순서로 체크해야 할지 한눈에 알 수 있게 정리했습니다.

  • [Proxmox] ZFS 스토리지 1년 운영 회고: 성능, 안정성, 그리고 후회되는 점

    [Proxmox] ZFS 스토리지 1년 운영 회고: 성능, 안정성, 그리고 후회되는 점

    [Proxmox] ZFS 스토리지 1년 운영 회고: 성능, 안정성, 그리고 후회되는 점

    안녕하세요, 13년차 서버실 주인장입니다. 오늘은 제가 홈랩에서 Proxmox VE (Virtual Environment)와 ZFS를 조합한 스토리지 시스템을 1년간 운영해본 솔직한 경험담을 풀어볼게요. 많은 분들이 홈랩 서버를 구축하거나 작은 규모의 프로덕션 환경에서 가상화를 고민할 때, 스토리지 구성이 가장 큰 고민이 되더라고요. 저 역시 그랬거든요. 특히 데이터의 안정성과 성능이라는 두 마리 토끼를 잡으려다 보면, Proxmox ZFS 스토리지 조합이 매력적인 선택지로 다가오기 마련입니다.

    13년차 인프라 엔지니어로서 직접 경험한 Proxmox ZFS 스토리지의 성능, 안정성, 그리고 솔직히 ‘아, 이건 좀 후회된다’ 싶었던 점들까지 가감 없이 공유해드리겠습니다. 제 삽질 경험이 여러분의 시행착오를 줄이는 데 조금이나마 도움이 되었으면 좋겠어요. 💡


    왜 Proxmox ZFS를 선택했을까?

    제가 Proxmox ZFS 스토리지 조합을 선택한 이유는 명확했어요. 바로 데이터 무결성(Data Integrity)과 유연한 스토리지 관리 기능 때문이었죠. ZFS는 단순한 파일 시스템을 넘어, 자체적으로 볼륨 관리 기능과 RAID 기능을 포함하고 있습니다. 특히 다음과 같은 점들이 저를 매료시켰어요.

    • Copy-on-Write (CoW): 데이터를 덮어쓰지 않고 새로운 블록에 저장하기 때문에, 데이터 손상 위험이 현저히 줄어들더라고요.
    • 스냅샷(Snapshots): 특정 시점의 파일 시스템 상태를 저장할 수 있어서, VM이나 컨테이너 백업 및 롤백이 정말 편리합니다. Proxmox와의 연동은 정말 환상적이었죠.
    • 데이터 스크러빙(Data Scrubbing): 주기적으로 데이터의 무결성을 검사하고 손상된 데이터를 자동으로 복구합니다. 이 덕분에 몇 번 안심했네요.
    • RAID-Z: 소프트웨어 RAID 기능으로, 하드웨어 RAID 컨트롤러 없이도 안정적인 다중 디스크 구성을 할 수 있어요.

    Proxmox는 이런 ZFS의 강력한 기능을 웹 UI에서 손쉽게 관리할 수 있도록 통합해놨어요. 처음엔 CLI(Command Line Interface)로만 ZFS를 다루다가, Proxmox의 간편함에 감탄했었죠.


    저의 Proxmox ZFS 스토리지 구성

    제 홈랩 서버는 인텔 i5-8500 CPU에 32GB RAM을 사용하고 있어요. 스토리지 구성은 다음과 같았습니다.

    1. 데이터 풀 (Data Pool): 4TB HDD 4개로 RAIDZ1 풀 구성
    2. L2ARC (Level 2 Adaptive Replacement Cache): 250GB SATA SSD 1개
    3. SLOG (Separate Log Device): 처음에는 없었으나, 나중에 128GB NVMe SSD 추가

    처음엔 RAIDZ1으로도 충분하다고 생각했어요. 디스크 하나가 죽어도 데이터 손실 없이 버틸 수 있으니까요. L2ARC는 저렴한 SATA SSD로 시작해서 캐싱 효과를 보려고 했고, SLOG는 VM의 쓰기 성능에 큰 영향을 준다고 해서 나중에 추가해봤습니다. 이 구성으로 1년 동안 다양한 VM (Ubuntu, Windows Server), 컨테이너 (Docker, LXC), 그리고 여러 서비스들을 운영했어요.

    제 Proxmox ZFS 홈랩 스토리지 구성 다이어그램입니다. HDD로 데이터 풀을 구성하고, SSD를 L2ARC와 SLOG로 활용했어요.


    1년 운영 후 성능 분석

    실제로 1년간 Proxmox ZFS 스토리지를 사용해보니, 예상보다 훨씬 만족스러운 부분도 있었고, 아쉬운 부분도 명확했습니다.

    ARC (Adaptive Replacement Cache) 효과

    ZFS는 시스템 RAM을 캐시로 정말 활용하는 ARC (Adaptive Replacement Cache) 덕분에 자주 접근하는 데이터는 정말 빠르게 읽을 수 있더라고요. 32GB RAM 중 상당 부분을 ARC가 사용했는데, 웹서버나 DB 서버처럼 특정 데이터를 반복적으로 요청하는 VM에서는 HDD임에도 불구하고 SSD에 버금가는 읽기 성능을 보여주더라고요. ARC hit ratio가 90% 이상을 유지할 때는 정말 쾌적했습니다. 🎉

    L2ARC (Level 2 ARC)의 활용

    RAM이 아무리 많아도 모든 데이터를 캐시할 수 없죠. 그래서 저렴한 SATA SSD를 L2ARC (Level 2 ARC)로 추가해봤는데, 생각보다 효과가 좋더라고요. 주로 사용되는 VM이나 컨테이너의 데이터가 L2ARC에 캐시되면서, 초기 로딩 시간이나 간헐적인 I/O 성능이 눈에 띄게 개선되는 걸 체감했습니다. 물론 NVMe SSD만큼은 아니지만, 비용 대비 성능 향상은 정말 분명했어요.

    SLOG (Separate Log Device)의 중요성

    가장 큰 성능 향상을 가져온 건 바로 SLOG (Separate Log Device)였습니다. 처음에는 SLOG 없이 운영했는데, VM의 동기 쓰기(Synchronous Write) 작업이 많아지자 I/O 대기 시간이 길어지는 문제가 발생하더라고요. 특히 데이터베이스나 로그를 많이 쓰는 서비스에서 체감 성능 저하가 심했습니다. 나중에 NVMe SSD를 SLOG로 추가하고 나니, 쓰기 성능이 정말 비약적으로 향상되었어요. VM I/O가 많은 경우에는 SLOG용 NVMe SSD는 거의 필수라고 생각합니다. 신세계를 경험했네요! ✨

    결론적으로, 일반적인 웹서버, 개발 환경 VM, 파일 서버 등을 돌리는 데는 Proxmox ZFS 스토리지가 충분한 성능을 제공했어요. 물론 고성능 NVMe RAID 풀에 비할 바는 아니지만, 홈랩 환경에서는 정말 차고 넘치는 수준이었죠.

    Proxmox 웹 UI ZFS 스토리지 대시보드 및 성능 모니터링 화면

    Proxmox 웹 UI에서 ZFS 스토리지의 상태와 성능을 모니터링하는 화면입니다. ARC Hit Ratio와 I/O 대역폭을 확인할 수 있어요.


    예상치 못한 안정성 경험 (그리고 삽질)

    ZFS의 가장 큰 장점 중 하나는 바로 데이터 무결성(Data Integrity)이잖아요? 실제로 1년간 운영하면서 이 부분에서 몇 번 감탄했어요.

    주기적인 Pool Scrub의 위력

    저는 한 달에 한 번씩 zpool scrub 명령어를 통해 풀 스크럽(Pool Scrub)을 돌렸습니다. 이게 정말 중요하더라고요. 한번은 스크럽 중 미세한 데이터 불일치를 감지하고 자동으로 복구하는 걸 로그를 통해 확인했어요. 만약 ZFS가 아니었다면 알지도 못하고 지나갈 뻔한 문제였죠. ⚠️

    디스크 장애와 RAIDZ1의 복구 경험

    불행인지 다행인지, 1년 사이에 4개 중 하나의 HDD가 고장 났어요. S.M.A.R.T. 경고가 뜨고, zpool status 명령어로 확인해보니 DEGRADED 상태가 되었더군요. 하지만 RAIDZ1으로 구성했기에 디스크 하나가 죽어도 데이터는 안전하게 보호되었습니다. 데이터를 잃을 걱정 없이 새 디스크를 주문할 수 있었죠.

    새 디스크가 도착하고 교체하는 과정에서 제가 삽질 좀 했습니다. 🤦‍♂️ 핫스왑(Hot-swap)이 되는 케이스가 아니라서 서버를 끄고 디스크를 교체했는데, 그 과정에서 명령어 사용이 미숙해서 잠시 헤맸어요. 정확한 zpool replace 명령어를 아는 게 정말 중요하더라고요.

    # 1. zpool status 명령어로 죽은 디스크의 경로 확인
    # 예: /dev/sdb
    root@proxmox:~# zpool status storage_pool
    
    # 2. 새 디스크를 서버에 장착 (예: /dev/sdc)
    
    # 3. 죽은 디스크를 새 디스크로 교체 시작
    root@proxmox:~# zpool replace storage_pool /dev/sdb /dev/sdc
    
    # 4. 교체 진행 상황 확인
    root@proxmox:~# zpool status storage_pool
    # reslivering이 완료되면 'ONLINE' 상태로 돌아옵니다.
    

    교체 후 리실버링(Resilvering)이 완료되고 풀이 다시 ONLINE 상태가 되었을 때의 안도감이란… 드디어 됐다! ✅ ZFS는 똑똑하지만, 관리자의 정확한 명령이 필수라는 걸 다시 한번 느꼈어요.


    후회되는 점과 개선 방향

    솔직히 1년간 Proxmox ZFS 스토리지를 운영하면서 후회되는 점도 몇 가지 있습니다.

    1. 초기 RAIDZ1 선택의 아쉬움: 처음에 RAIDZ1으로 구성한 게 살짝 아쉬워요. 디스크 하나만 더 추가해서 4TB HDD 5개로 RAIDZ2로 갔다면, 디스크 두 개가 동시에 고장 나도 버틸 수 있어 안정성이 훨씬 높았을 텐데 말이죠. 홈랩이긴 하지만, 중요한 데이터가 많아질수록 RAIDZ2의 안정성이 더 매력적으로 느껴집니다.
    2. SLOG/L2ARC 초기 계획 미흡: SLOG와 L2ARC를 처음부터 제대로 고려하지 못한 것도 후회돼요. 저렴한 SATA SSD로 시작했지만, 나중엔 고성능 NVMe SSD의 필요성을 절실히 느꼈거든요. 초기 투자 비용을 아끼려다 나중에 더 큰 비용과 시간을 들여 업그레이드했습니다.
    3. 디스크 종류 혼용: 데이터 풀은 HDD, L2ARC는 SATA SSD, SLOG는 NVMe SSD… 성능 때문에 다양한 디스크를 섞어 썼는데, 관리 복잡도가 올라가고 벤더별 드라이버 관리나 S.M.A.R.T. 모니터링이 조금 번거로워졌어요.

    다음 번에 Proxmox ZFS 스토리지를 구성한다면, 저는 다음과 같은 방향으로 개선할 생각이에요.

    • 안정성을 최우선으로 하여 RAIDZ2 또는 미러(Mirror) 구성 고려.
    • 처음부터 고성능 NVMe SSD를 SLOG 및 L2ARC로 할당하여 최대 성능 확보.
    • 가급적 동일한 벤더의 디스크를 사용하여 관리 편의성 증대.
    Proxmox ZFS 운영 문제점과 해결책 비교표

    Proxmox ZFS 운영 시 발생할 수 있는 주요 문제점과 제가 경험했던 해결책을 비교 정리한 표입니다.


    Proxmox ZFS 스토리지 운영 팁

    1년간 운영하면서 얻은 몇 가지 꿀팁을 공유해드릴게요.

    1. RAM은 많을수록 좋습니다.
      ZFS는 정말 RAM을 좋아합니다. ARC (Adaptive Replacement Cache) 효율을 높이려면 시스템 RAM을 최대한 많이 확보하세요. 최소 16GB, 가능하다면 32GB 이상을 추천합니다.
    2. SLOG는 선택 아닌 필수?
      VM I/O가 많거나 동기 쓰기(Synchronous Write)가 중요한 서비스(예: 데이터베이스)를 운영한다면 SLOG용 NVMe SSD는 꼭 고려하세요. 체감 성능이 확 달라집니다. 특히 저가형 NVMe라도 없어서는 안 될 부분이에요.
    3. 주기적인 스크럽은 생명입니다.
      데이터 무결성을 지키려면 zpool scrub 명령어를 통해 주기적으로 풀 스크럽을 해주세요. 저는 cron으로 매월 첫째 주 일요일 새벽 3시에 돌리도록 설정했어요. 자고 일어났을 때 스크럽 완료 메시지를 보면 왠지 모르게 뿌듯하더라고요. 😊
    4. # cron 설정 예시 (매월 첫째 주 일요일 새벽 3시)
      0 3 1-7 * 0 /usr/sbin/zpool scrub storage_pool
      
    5. 백업은 언제나 중요합니다.
      아무리 ZFS가 튼튼해도 백업은 필수예요. Proxmox의 내장 백업 기능을 활용하거나, zfs send/receive를 이용해 다른 곳으로 스냅샷을 보내는 방식으로 이중 백업 체계를 갖추세요. 데이터는 언제나 소중하니까요.
    ZFS 풀 스크럽 진행 과정을 보여주는 콘솔 화면

    ZFS 풀 스크럽(scrub)이 진행되는 콘솔 화면이에요. 주기적인 스크럽은 데이터 무결성을 유지하는 데 필수적입니다.


    마무리하며

    1년간 Proxmox ZFS 스토리지를 운영해보면서 성능과 안정성 모두 만족스러웠습니다. 특히 데이터 무결성에 대한 ZFS의 강력한 보장은 인프라 엔지니어로서 큰 신뢰를 줬어요. 하지만 완벽한 시스템은 없다는 것, 그리고 초기 설계의 중요성을 다시 한번 깨달았습니다. 제 삽질 경험과 팁들이 Proxmox ZFS 스토리지 구성을 고민하고 계신 여러분께 조금이나마 도움이 되었으면 좋겠어요.

    다음 글에서는 Proxmox ZFS 스냅샷과 복제(Replication) 기능을 활용한 백업 전략에 대해 더 자세히 다뤄볼 예정입니다. 기대해주세요! 👋

  • [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 Backup Server (PBS) 완벽 가이드: 설치부터 백업/복구 전략까지

    [Proxmox] Proxmox Backup Server (PBS) 완벽 가이드: 설치부터 백업/복구 전략까지

    [Proxmox] Proxmox Backup Server (PBS) 완벽 가이드: 설치부터 백업/복구 전략까지

    13년차 인프라 엔지니어의 Proxmox Backup Server (PBS) 삽질 & 활용기

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 Proxmox Backup Server (PBS), 줄여서 PBS에 대한 이야기를 해보려고 합니다. 사실 인프라 엔지니어에게 백업(Backup)은 아무리 강조해도 지나치지 않은 핵심 업무 중 하나잖아요? 저도 수많은 시스템을 운영하면서 “아차!” 싶었던 순간이 한두 번이 아니었습니다. 특히 홈랩에서 Proxmox VE(Virtual Environment)를 쓰면서 가상 머신(VM)이나 컨테이너(Container) 백업이 늘 고민이었는데, 이 PBS를 만나고 나서 드디어 마음의 평화를 찾았지 뭐예요? 🎉

    Proxmox VE를 사용하시는 분들이라면 기본적으로 제공되는 백업 기능도 꽤 유용하다는 걸 아실 거예요. 근데 이게 스케일이 커지거나, 데이터 중복 제거(Deduplication)나 증분 백업(Incremental Backup) 같은 고급 기능이 필요해지면 한계에 부딪히거든요. 그때 PBS가 진가를 발휘합니다. 오늘은 제가 직접 PBS를 설치하고, Proxmox VE와 연동해서 백업/복구 전략까지 세워본 경험을 솔직하게 공유해 드릴게요. 삽질 과정과 해결 팁도 아낌없이 풀어놓을 테니, 끝까지 함께해 주시면 분명 큰 도움이 되실 겁니다!

    Proxmox Backup Server의 전체 아키텍처는 Proxmox VE에서 PBS로 데이터를 보내고, PBS가 중복 제거 및 압축하여 백업 스토리지에 저장하는 과정을 시각적으로 보여줍니다.

    Proxmox Backup Server (PBS)란 무엇인가요?

    Proxmox Backup Server (PBS)는 Proxmox VE 환경에 최적화된 엔터프라이즈급 백업 솔루션입니다. 쉽게 말해, Proxmox VE 위에 돌아가는 수많은 VM이나 컨테이너의 데이터를 효율적으로 저장하고 관리하기 위해 태어난 녀석이라고 보시면 됩니다. 단순히 데이터를 복사해서 저장하는 것을 넘어, 여러 가지 똑똑한 기능들을 제공하죠.

    • 데이터 중복 제거 (Deduplication): 이게 PBS의 가장 강력한 기능 중 하나인데요. 동일한 데이터 블록이 여러 백업 이미지에 존재하더라도, PBS는 딱 한 번만 저장하고 나머지는 참조만 합니다. 덕분에 저장 공간을 엄청나게 절약할 수 있어요. 제가 직접 써보니, 특히 비슷한 OS 이미지로 여러 VM을 돌릴 때 그 효과가 대단하더라고요!
    • 증분 백업 (Incremental Backup): 첫 백업 이후에는 변경된 데이터 블록만 백업합니다. 이는 백업 시간을 단축시키고, 다시 한 번 저장 공간 효율성을 높여줍니다.
    • 데이터 무결성 검증 (Data Integrity Verification): 백업된 데이터가 손상되지 않았는지 정기적으로 검사할 수 있습니다. 백업은 저장하는 것만큼 ‘제대로 저장되었는지’ 확인하는 게 중요하잖아요? 이 기능 덕분에 안심하고 데이터를 맡길 수 있습니다.
    • 클라이언트-사이드 암호화 (Client-side Encryption): 백업 데이터는 클라이언트(Proxmox VE)에서 암호화되어 PBS로 전송됩니다. 덕분에 민감한 데이터도 안전하게 보관할 수 있죠.
    • 원격 동기화 (Remote Sync): 백업 데이터를 다른 PBS 서버로 동기화할 수 있어, 재해 복구(Disaster Recovery) 전략을 수립하는 데 아주 유용합니다.

    처음엔 그냥 NAS에 백업하면 되지 않나 싶었는데, PBS의 이런 기능들을 경험하고 나니 왜 전용 백업 솔루션이 필요한지 절실히 깨달았네요. 특히 중복 제거는 진짜 혁명적입니다. 💡

    Proxmox Backup Server 설치하기

    자, 그럼 이제 본격적으로 PBS를 설치해 볼까요? 저는 별도의 물리 서버나 가상 머신에 Proxmox Backup Server ISO 파일을 이용해서 설치하는 방법을 선호합니다. 안정적이고 깔끔하거든요. 여기서는 ISO를 이용한 설치 과정을 간략하게 설명해 드릴게요. (Proxmox VE 위에 컨테이너로 설치하는 방법도 있지만, 안정성을 위해 전용 OS 설치를 추천합니다.)

    1. ISO 다운로드 및 부팅: Proxmox 공식 웹사이트에서 PBS ISO 이미지를 다운로드하고, USB에 굽거나 VM에 마운트하여 부팅합니다.
    2. 설치 마법사 진행: 부팅 후 나타나는 설치 마법사를 따라 진행합니다.
      • Target Harddisk (대상 하드디스크): PBS가 설치될 디스크를 선택합니다. 저는 보통 OS용으로 작은 SSD 하나, 백업 데이터 저장용으로 큰 HDD/SSD를 따로 구성합니다.
      • Country (국가), Time zone (시간대): 대한민국, 서울을 선택해 줍니다.
      • Root Password (루트 비밀번호) & Email address (이메일 주소): 관리자 비밀번호를 설정하고, 알림을 받을 이메일 주소를 입력합니다.
      • Management Network Configuration (네트워크 설정): IP 주소, 넷마스크, 게이트웨이, DNS 서버를 설정합니다. 나중에 Proxmox VE에서 접근해야 하니, 고정 IP로 설정하는 것이 좋습니다.
    3. 설치 완료 및 재부팅: 모든 설정이 끝나면 설치가 시작되고, 완료되면 재부팅하라는 메시지가 나옵니다. 재부팅 후에는 웹 인터페이스에 접속할 수 있습니다.

    웹 인터페이스는 https://[PBS 서버 IP]:8007로 접속할 수 있습니다. 사용자 이름은 root이고, 비밀번호는 설치 시 설정한 비밀번호를 사용하면 됩니다. 처음 접속하면 왠지 모르게 뿌듯하더라고요! 🎉

    Proxmox Backup Server 웹 인터페이스에 로그인한 후의 대시보드 화면입니다. 시스템 상태와 저장소 현황을 한눈에 확인할 수 있습니다.

    Proxmox VE와 PBS 연동하기

    PBS를 설치했으니, 이제 Proxmox VE에서 이 녀석을 백업 저장소로 추가해야겠죠? 이 과정도 정말 간단합니다.

    1. Proxmox VE 웹 인터페이스 접속: 평소처럼 Proxmox VE 웹 관리 화면에 로그인합니다.
    2. 데이터센터(Datacenter) > 스토리지(Storage) 이동: 왼쪽 메뉴에서 Datacenter를 클릭하고, 그 아래의 Storage 탭으로 이동합니다.
    3. ‘추가(Add)’ 버튼 클릭 > ‘Proxmox Backup Server’ 선택: ‘Add’ 드롭다운 메뉴에서 ‘Proxmox Backup Server’를 선택합니다.
    4. 정보 입력: 다음 정보를 입력해 줍니다.
      • ID: 이 저장소의 이름을 지정합니다. (예: pbs-backup-storage)
      • Server: PBS 서버의 IP 주소 또는 도메인 이름을 입력합니다.
      • Username: root@pam (PBS의 기본 관리자 계정)
      • Password: PBS 설치 시 설정한 root 비밀번호
      • Datastore: PBS에서 생성된 데이터스토어 이름을 입력합니다. 기본값은 datastore1입니다. (PBS 웹 인터페이스의 ‘Datastore’ 메뉴에서 확인할 수 있습니다.)
      • Fingerprint (지문): PBS 서버의 SSH 지문입니다. 처음 연결할 때 자동으로 채워지거나, PBS 웹 인터페이스에서 확인할 수 있습니다. 보안을 위해 꼭 확인해 주세요.
    5. ‘추가(Add)’ 버튼 클릭: 모든 정보를 입력하고 ‘Add’ 버튼을 누르면 끝!

    제대로 연결되었다면, Proxmox VE의 스토리지 목록에 PBS가 나타나고, ‘Status’가 ‘Active’로 표시될 거예요. 이제 Proxmox VE의 VM이나 컨테이너를 백업할 때, 대상 저장소로 PBS를 선택할 수 있게 됩니다. ✅

    Proxmox VE에 Proxmox Backup Server를 스토리지로 추가하는 설정 화면입니다. Server IP, Username, Datastore 등의 정보를 입력하는 창이 보입니다.

    백업 전략 수립 및 실행

    저장소를 연결했으니, 이제 어떤 VM을 언제, 어떻게 백업할지 전략을 세울 차례입니다. Proxmox VE에서는 백업 스케줄을 아주 유연하게 설정할 수 있습니다.

    1. Datacenter > Backup (백업) 메뉴 이동: Proxmox VE 웹 인터페이스에서 ‘Datacenter’를 클릭하고 ‘Backup’ 탭으로 이동합니다.
    2. ‘Add (추가)’ 버튼 클릭: 새로운 백업 작업을 생성합니다.
    3. 백업 작업 설정:
      • Storage (저장소): 방금 추가한 PBS 저장소를 선택합니다. (예: pbs-backup-storage)
      • Schedule (스케줄): 백업이 실행될 시간을 설정합니다. 매일 새벽 2시, 매주 일요일 자정 등 원하는 대로 설정할 수 있습니다. (예: daily, weekly)
      • VMs (VM 선택): 백업할 VM이나 컨테이너를 선택합니다. ‘All’을 선택하거나 특정 VM ID를 지정할 수 있습니다.
      • Mode (모드): Snapshot을 선택하는 것이 일반적입니다. (VM이 실행 중인 상태에서 일관성 있는 백업을 생성할 수 있습니다.)
      • Compression (압축): 백업 데이터의 압축 방식을 선택합니다. 저는 보통 Zstandard (ZSTD)를 사용합니다. 빠르고 효율적이거든요.
      • Retention (보존 정책): 백업본을 얼마나 오래 보관할지 설정합니다. 예를 들어, ‘Keep last 7’로 설정하면 최근 7개의 백업본만 유지하고 오래된 것은 자동으로 삭제됩니다. 이 정책은 데이터스토어 용량 관리에도 아주 중요합니다.
      • Email notification (이메일 알림): 백업 성공/실패 여부를 이메일로 받아볼 수 있습니다. 중요한 기능이니 꼭 설정해 두세요!
    4. ‘Create (생성)’ 버튼 클릭: 백업 작업이 생성됩니다.

    이렇게 설정해두면, 정해진 시간에 PBS로 자동 백업이 진행됩니다. PBS 웹 인터페이스의 ‘Tasks’ 메뉴나 Proxmox VE의 ‘Task Log’에서 백업 진행 상황을 확인할 수 있습니다. 처음 백업이 성공했을 때의 그 쾌감이란! 💪

    데이터 복구, 이젠 걱정 마세요!

    백업은 언제나 ‘만약의 사태’를 대비하는 것이죠. 가장 중요한 건 백업된 데이터를 성공적으로 복구(Restore)할 수 있느냐입니다. PBS는 복구 과정도 직관적이고 빠릅니다.

    1. Proxmox VE 웹 인터페이스 접속: 복구할 VM이 있던 Proxmox VE 노드에 접속합니다.
    2. VM 선택 및 ‘백업(Backup)’ 탭 이동: 복구할 VM을 선택한 다음, ‘Backup’ 탭으로 이동합니다.
    3. 복구할 백업본 선택: PBS에 저장된 백업 목록이 나타납니다. 복구하고자 하는 특정 날짜와 시간의 백업본을 선택합니다.
    4. ‘복원(Restore)’ 버튼 클릭: 복원 옵션 대화 상자가 나타납니다.
      • Storage (저장소): 복원될 VM의 디스크가 저장될 Proxmox VE 스토리지(예: local-lvm)를 선택합니다.
      • VM ID: 기존 VM ID로 복원하거나, 새로운 VM ID를 지정하여 복원할 수 있습니다. 기존 VM이 손상된 경우 같은 ID로 복원하고, 테스트 목적으로 복원할 경우 새로운 ID로 복원하는 것이 일반적입니다.
      • Overwrite (덮어쓰기): 기존 VM이 있을 경우 덮어쓸지 여부를 결정합니다. 주의해서 사용해야 합니다!
    5. ‘복원(Restore)’ 버튼 클릭: 복구가 시작됩니다.

    복구 작업이 완료되면, 해당 VM이 Proxmox VE 목록에 나타나고, 정상적으로 부팅되는 것을 확인할 수 있습니다. 제가 실제로 몇 번 복구 테스트를 해봤는데, 정말 빠르고 안정적이더라고요. 특히 중복 제거 덕분에 복구 시간도 단축되는 느낌이었습니다. 👏

    ⚠️ 삽질 경험 & 트러블슈팅 팁

    제가 PBS를 사용하면서 겪었던 몇 가지 삽질 경험과 그 해결 팁을 공유해 드릴게요. 여러분은 저처럼 고생하지 마시라고요! ㅎㅎ

    • 방화벽 문제: Proxmox VE와 PBS가 서로 통신하려면 8007번 포트가 열려있어야 합니다. PBS 서버에 UFW(Uncomplicated Firewall)나 다른 방화벽이 설치되어 있다면, 꼭 8007번 포트를 허용해 주세요.
      sudo ufw allow 8007/tcp
      sudo ufw enable
      sudo ufw status
      

      저는 처음에 포트 열어주는 걸 깜빡해서 “왜 연결이 안 되지?” 하고 한참 헤맸거든요. 😅

    • Datastore(데이터스토어) 설정 오류: PBS 설치 후 Datastore를 생성하지 않거나, Proxmox VE에서 입력하는 Datastore 이름이 PBS의 Datastore 이름과 다르면 연결이 안 됩니다. PBS 웹 인터페이스에서 ‘Datastore’ 메뉴를 확인하고 정확한 이름을 입력해야 합니다. 기본값은 datastore1이지만, 직접 이름을 바꿨다면 그 이름을 써야 해요.
    • 스토리지 용량 부족: 아무리 중복 제거가 뛰어나도 백업본이 쌓이면 결국 용량이 부족해집니다. PBS 웹 인터페이스에서 ‘Datastore’ > ‘Prune & GC’ 탭을 활용하여 가지치기(Prune)와 가비지 컬렉션(Garbage Collection) 스케줄을 설정해 주세요. Prune은 오래된 백업본을 삭제하는 정책이고, GC는 삭제된 데이터 블록을 실제로 정리해서 공간을 회수하는 작업입니다. 이걸 안 해주면 삭제된 백업본이 실제 공간을 계속 차지하고 있을 수 있습니다.
    • 네트워크 대역폭 문제: 동시에 여러 VM을 백업하거나, 대용량 VM을 백업할 경우 네트워크 대역폭이 충분하지 않으면 백업 시간이 엄청나게 길어질 수 있습니다. 1Gbps 네트워크 환경이라면 큰 문제가 없지만, 가능하다면 백업 전용 네트워크를 구성하거나 10Gbps 네트워크를 고려해볼 만합니다.

    Proxmox Backup Server의 주요 기능인 데이터 중복 제거, 압축, 암호화, 데이터 무결성 검증을 시각적으로 요약한 인포그래픽입니다.

    마무리하며: PBS, 인프라 엔지니어의 든든한 동반자

    오늘은 Proxmox Backup Server (PBS)에 대해 설치부터 Proxmox VE 연동, 백업/복구 전략, 그리고 제가 겪었던 삽질 경험까지 자세히 이야기해 드렸습니다. 13년차 인프라 엔지니어로서 여러 백업 솔루션을 경험해 봤지만, Proxmox 환경에서는 PBS만큼 효율적이고 안정적인 솔루션은 찾기 힘들다고 생각합니다.

    특히 데이터 중복 제거와 증분 백업 기능은 저장 공간을 아끼는 데 큰 도움이 되었고, 직관적인 웹 인터페이스 덕분에 관리도 정말 편했습니다. 여러분도 Proxmox VE를 사용하고 계시다면, PBS 도입을 적극적으로 고려해 보시길 강력히 추천합니다. 처음엔 좀 낯설게 느껴질 수도 있지만, 한 번 세팅해두면 든든한 백업 시스템이 될 거예요. 든든한 백업 시스템 구축으로 여러분의 소중한 데이터를 지켜내시길 바랍니다!

    다음번에는 PBS의 원격 동기화(Remote Sync) 기능을 활용한 재해 복구(DR) 전략에 대해 더 깊이 다뤄볼까 합니다. 기대해 주세요! 😉

  • [Proxmox] 스토리지 관리 완벽 가이드: ZFS, LVM, NFS, iSCSI 비교 및 최적화

    Proxmox 스토리지, 처음엔 저도 뭘 써야 할지 몰랐어요

    Proxmox VE를 처음 설치하고 VM(가상 머신)을 만들려는 순간, 스토리지 선택 화면에서 멈춰본 경험 있으신가요? ZFS, LVM, NFS, iSCSI… 이름만 봐도 머리가 살짝 아파오는 그 느낌. 저도 딱 그랬거든요. 처음 홈랩에 Proxmox를 올렸을 때, 그냥 기본값인 LVM으로 쭉 써왔는데 어느 날 VM 디스크가 꽉 차는 사고가 났고, 그때부터 스토리지 구조를 제대로 파고들기 시작했습니다.

    13년 넘게 인프라를 다루면서 느낀 건데, 스토리지 선택은 처음에 잘 해야 나중에 마이그레이션 삽질을 안 한다는 거예요. 이 글에서는 Proxmox 스토리지의 핵심 옵션인 ZFS, LVM, NFS, iSCSI를 실제 사용 경험을 바탕으로 비교해드리고, 각 상황에 맞는 최적화 팁까지 정리해보겠습니다.

    ▲ Proxmox VE의 스토리지 아키텍처 개요. 각 스토리지 타입이 VM/CT와 어떻게 연결되는지 한눈에 볼 수 있습니다.

    Proxmox 스토리지 기본 개념 이해하기

    본격적인 비교 전에 Proxmox 스토리지가 어떻게 동작하는지 간단히 짚고 넘어갈게요. 쉽게 말해서, Proxmox는 스토리지를 “어디에 VM 디스크 이미지를 저장할 것인가”의 관점으로 관리합니다.

    스토리지 타입 분류

    Proxmox의 스토리지는 크게 두 가지 방식으로 나뉩니다:

    • 로컬 스토리지 (Local Storage): 해당 Proxmox 노드에 직접 연결된 디스크. ZFS, LVM, Directory 등이 여기에 해당합니다
    • 공유 스토리지 (Shared Storage): 여러 Proxmox 노드가 동시에 접근 가능한 스토리지. NFS, iSCSI, Ceph 등이 여기에 해당하며, 클러스터 환경에서 라이브 마이그레이션(Live Migration)을 하려면 필수입니다

    이 차이가 왜 중요하냐면, 단일 노드 홈랩이냐 다중 노드 클러스터냐에 따라 선택지가 확 달라지거든요.

    ZFS (Z File System): 데이터 무결성의 끝판왕

    ZFS가 뭔가요?

    ZFS는 원래 Sun Microsystems에서 개발한 파일 시스템인데, 지금은 OpenZFS 프로젝트를 통해 Linux에서도 쓸 수 있어요. Proxmox는 ZFS를 네이티브로 지원하는 몇 안 되는 하이퍼바이저 중 하나고, 이게 Proxmox를 선택하는 이유 중 하나이기도 합니다.

    ZFS의 핵심 특징을 정리하면:

    • Copy-on-Write (CoW, 쓰기 시 복사): 데이터를 덮어쓰지 않고 새 위치에 씁니다. 덕분에 데이터 손상 위험이 확 줄어요
    • 스냅샷 (Snapshot): 거의 순간적으로 스냅샷을 생성할 수 있고, 공간도 효율적으로 씁니다
    • RAID-Z: 소프트웨어 RAID를 ZFS 레벨에서 처리. RAID-Z1(패리티 1), RAID-Z2(패리티 2) 등 선택 가능합니다
    • 데이터 체크섬 (Checksum): 모든 데이터 블록에 체크섬을 달아서 조용한 데이터 손상(Silent Corruption)을 감지하고 자동 복구합니다
    • ARC (Adaptive Replacement Cache): 메모리를 캐시로 적극 활용해서 읽기 성능을 높입니다

    Proxmox에서 ZFS 설정하기

    Proxmox 설치 시 ZFS를 선택하거나, 설치 후에도 추가할 수 있어요. 설치 후 추가하는 방법입니다:

    # ZFS 풀 생성 (미러 구성, 2개 디스크)
    zpool create -f rpool mirror /dev/sdb /dev/sdc
    
    # ZFS 풀 상태 확인
    zpool status
    
    # Proxmox에서 ZFS 스토리지 추가 (Web UI 대신 CLI로)
    pvesm add zfspool local-zfs --pool rpool --content images,rootdir
    # ZFS 성능 튜닝 - ARC 최대 크기 설정 (예: 8GB)
    echo 'options zfs zfs_arc_max=8589934592' > /etc/modprobe.d/zfs.conf
    update-initramfs -u
    
    # 현재 ARC 사용량 확인
    cat /proc/spl/kstat/zfs/arcstats | grep -E '^(size|c_max|hits|misses)'

    ZFS 사용 시 주의사항

    ⚠️ ZFS는 메모리를 많이 먹습니다. 일반적으로 스토리지 1TB당 1GB RAM이라는 가이드라인이 있는데, 홈랩 환경에서는 최소 8GB 이상 RAM을 권장해요. 저도 처음에 RAM 4GB짜리 서버에 ZFS 올렸다가 OOM(Out of Memory) 킬러가 작동하는 참사를 겪었습니다 ㅎㅎ.

    ⚠️ 절대로 ZFS 풀에 하드웨어 RAID 컨트롤러를 쓰지 마세요. ZFS는 디스크를 직접 제어해야 해서, HBA(Host Bus Adapter) 모드나 IT 모드의 컨트롤러를 써야 합니다. 하드웨어 RAID 위에 ZFS를 올리면 ZFS의 자가 복구 기능이 제대로 동작하지 않아요.

    LVM (Logical Volume Manager): 검증된 클래식

    LVM이 뭔가요?

    LVM(논리 볼륨 관리자)은 Linux에서 오랫동안 사용되어 온 스토리지 관리 방식이에요. 물리 디스크를 추상화해서 유연하게 관리할 수 있게 해줍니다. Proxmox 기본 설치 옵션이기도 하고요.

    LVM의 구조는 이렇습니다:

    • PV (Physical Volume, 물리 볼륨): 실제 디스크나 파티션
    • VG (Volume Group, 볼륨 그룹): PV를 묶은 논리적 풀
    • LV (Logical Volume, 논리 볼륨): VG에서 할당받은 실제 사용 공간

    Proxmox에서는 LVM-Thin(씬 프로비저닝)을 많이 쓰는데, 이게 핵심이에요. 씬 프로비저닝이란 VM에게 100GB를 할당했어도 실제로 데이터를 쓰는 만큼만 디스크를 사용하는 방식입니다. 공간 효율이 훨씬 좋더라고요.

    Proxmox에서 LVM-Thin 설정하기

    # 새 디스크를 PV로 초기화
    pvcreate /dev/sdb
    
    # VG 생성
    vgcreate vg-data /dev/sdb
    
    # LVM-Thin 풀 생성 (VG 용량의 95% 할당)
    lvcreate -l 95%FREE --thinpool thin-pool vg-data
    
    # Proxmox에 LVM-Thin 스토리지 추가
    pvesm add lvmthin local-lvm-thin --vgname vg-data --thinpool thin-pool --content images,rootdir
    
    # 상태 확인
    lvs -a --units g

    LVM vs LVM-Thin 차이

    항목 LVM (Thick) LVM-Thin
    공간 할당 즉시 전체 할당 사용한 만큼만 할당
    스냅샷 지원 (공간 소모 큼) 효율적 스냅샷 지원
    오버프로비저닝 불가 가능 (주의 필요)
    성능 안정적 약간의 오버헤드 있음
    복잡도 낮음 중간

    ⚠️ LVM-Thin에서 오버프로비저닝할 때는 실제 사용량을 꼭 모니터링해야 해요. 풀이 꽉 차면 VM들이 I/O 오류를 뱉으면서 난리가 납니다. 저도 이걸 한 번 경험하고 나서 Grafana로 LVM-Thin 사용량 알람을 걸어뒀거든요.

    ▲ Proxmox Web UI에서 LVM-Thin 스토리지 설정 화면. 씬 풀 사용량을 실시간으로 확인할 수 있습니다.

    NFS (Network File System): 공유 스토리지의 대명사

    NFS가 뭔가요?

    NFS(네트워크 파일 시스템)는 네트워크를 통해 파일 시스템을 공유하는 프로토콜이에요. 쉽게 말해서, NAS나 별도 서버의 디렉토리를 Proxmox에 마운트해서 스토리지로 쓰는 방식입니다.

    NFS의 장점:

    • 설정이 비교적 간단해요
    • 여러 Proxmox 노드가 동시에 접근 가능 → 라이브 마이그레이션 지원
    • 기존 NAS(Synology, QNAP 등)와 쉽게 연동됩니다
    • ISO 이미지, 백업 파일 저장에 적합합니다

    NFS의 단점:

    • 네트워크 의존성이 높음 (네트워크 장애 = 스토리지 장애)
    • 레이턴시(지연시간)가 로컬 스토리지보다 높아요
    • 고성능 VM 디스크용으로는 부적합한 경우가 많습니다

    Proxmox에서 NFS 설정하기

    # NFS 클라이언트 패키지 확인
    apt install nfs-common
    
    # NFS 마운트 테스트
    mount -t nfs 192.168.1.100:/volume1/proxmox /mnt/test-nfs
    
    # Proxmox Web UI 대신 CLI로 NFS 스토리지 추가
    pvesm add nfs nas-storage \
      --server 192.168.1.100 \
      --export /volume1/proxmox \
      --content iso,backup,images \
      --options vers=4.1
    
    # 추가된 스토리지 확인
    pvesm status

    💡 팁: NFS 버전은 가능하면 NFSv4.1을 쓰세요. NFSv3보다 안정성과 성능이 향상됐고, 특히 Proxmox 클러스터 환경에서 더 안정적으로 동작합니다.

    NFS 성능 최적화 옵션

    # /etc/fstab에 NFS 마운트 옵션 최적화
    192.168.1.100:/volume1/proxmox /mnt/nas-proxmox nfs \
      vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 0 0
    
    # rsize/wsize: 읽기/쓰기 블록 크기 (1MB)
    # hard: 서버 응답 없으면 계속 재시도 (VM 안전을 위해 hard 권장)
    # timeo: 타임아웃 (1/10초 단위, 600 = 60초)

    iSCSI: 블록 스토리지를 네트워크로

    iSCSI가 뭔가요?

    iSCSI(아이스카시)는 SCSI 명령을 IP 네트워크를 통해 전달하는 프로토콜이에요. NFS가 “파일” 단위로 공유한다면, iSCSI는 “블록” 단위로 공유합니다. VM 입장에서 보면 마치 로컬 디스크가 연결된 것처럼 보여요.

    iSCSI 용어 정리:

    • Target (타깃): 스토리지를 제공하는 서버 (NAS, SAN 등)
    • Initiator (이니시에이터): 스토리지를 사용하는 클라이언트 (Proxmox 노드)
    • IQN (iSCSI Qualified Name): iSCSI 장치를 식별하는 고유 이름
    • LUN (Logical Unit Number): Target에서 제공하는 스토리지 단위

    Proxmox에서 iSCSI 설정하기

    # iSCSI initiator 패키지 설치
    apt install open-iscsi
    
    # iSCSI Target 검색 (NAS IP로)
    iscsiadm -m discovery -t sendtargets -p 192.168.1.100
    
    # 검색된 Target에 로그인
    iscsiadm -m node --login
    
    # 연결된 iSCSI 세션 확인
    iscsiadm -m session
    
    # Proxmox에 iSCSI 스토리지 추가
    pvesm add iscsi san-storage \
      --portal 192.168.1.100 \
      --target iqn.2023-01.com.example:storage \
      --content none
    
    # iSCSI 위에 LVM-Thin을 올려서 사용하는 게 일반적
    pvesm add lvmthin san-lvm-thin \
      --vgname san-vg \
      --thinpool san-thin-pool \
      --content images

    여기서 중요한 포인트! iSCSI는 단독으로는 Proxmox에서 VM 디스크로 직접 쓰기 어렵고, 보통 iSCSI로 블록 디바이스를 가져온 다음 그 위에 LVM이나 LVM-Thin을 올려서 사용해요. 저도 처음엔 이게 왜 이렇게 복잡한가 싶었는데, 블록 스토리지의 특성상 그렇게 써야 제대로 성능이 나오더라고요.

    4가지 스토리지 종합 비교

    항목 ZFS LVM-Thin NFS iSCSI+LVM
    유형 로컬 로컬 공유 (파일) 공유 (블록)
    스냅샷 ✅ 매우 효율적 ✅ 효율적 ⚠️ 제한적 ✅ LVM 스냅샷
    라이브 마이그레이션 ❌ 단일 노드 ❌ 단일 노드 ✅ 가능 ✅ 가능
    데이터 무결성 ✅ 최고 수준 ⚠️ 기본 수준 ⚠️ 네트워크 의존 ⚠️ 중간 수준
    성능 ✅ 높음 ✅ 높음 ⚠️ 네트워크 속도 의존 ✅ 높음
    설정 난이도 중간 낮음 낮음 높음
    RAM 요구량 높음 낮음 낮음 낮음
    추천 용도 단일 노드, 데이터 안전성 중시 단일 노드, 일반 VM ISO/백업, 소규모 클러스터 엔터프라이즈 클러스터

    ▲ Proxmox 스토리지 4종 비교 인포그래픽. 상황에 따라 적합한 스토리지 타입이 다릅니다.

    실제 구성 예시 및 최적화 팁

    홈랩 단일 노드 추천 구성

    제가 실제로 홈랩에서 쓰는 구성을 공유할게요:

    # /etc/pve/storage.cfg 예시 (실제 파일 위치)
    
    # 기본 로컬 디렉토리 (ISO, 백업용)
    dir: local
            path /var/lib/pve/local
            content iso,backup,snippets
    
    # ZFS 풀 (VM 디스크 메인)
    zfspool: local-zfs
            pool rpool/data
            content images,rootdir
            mountpoint /rpool/data
    
    # NFS (NAS 백업 및 ISO 라이브러리)
    nfs: nas-backup
            export /volume1/proxmox-backup
            path /mnt/pve/nas-backup
            server 192.168.1.100
            content backup,iso
            options vers=4.1

    ZFS 성능 최적화 핵심 설정

    # ZFS 레코드 크기 조정 (VM 디스크용 - 16K~64K 권장)
    zfs set recordsize=64K rpool/data
    
    # VM 특성에 따른 recordsize 조정
    # 데이터베이스 VM: 8K~16K
    # 일반 VM: 64K
    # 파일 서버 VM: 128K
    zfs set recordsize=16K rpool/data/vm-100-disk-0
    
    # 동기화 쓰기 설정 (성능과 안전성 트레이드오프)
    # sync=always: 가장 안전, 가장 느림
    # sync=standard: 기본값 (권장)
    # sync=disabled: 가장 빠름, 전원 손실시 데이터 손상 위험
    zfs set sync=standard rpool/data
    
    # 압축 활성화 (CPU 사용 약간 증가, 용량 절약)
    zfs set compression=lz4 rpool/data
    
    # 중복 제거 (dedup) - RAM 많이 필요, 신중하게 결정
    # 홈랩에선 웬만하면 끄는 걸 추천
    zfs set dedup=off rpool/data
    
    # ZFS 상태 및 통계 확인
    zpool status -v
    zfs list -t all
    zpool iostat -v 1

    iSCSI 멀티패스 (Multipath) 설정 — 고가용성 환경

    # multipath-tools 설치
    apt install multipath-tools
    
    # /etc/multipath.conf 기본 설정
    cat > /etc/multipath.conf << 'EOF'
    defaults {
        user_friendly_names yes
        find_multipaths yes
    }
    blacklist {
        devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
        devnode "^hd[a-z]"
    }
    EOF
    
    systemctl enable multipathd
    systemctl start multipathd
    multipath -ll  # 멀티패스 장치 확인

    트러블슈팅: 제가 겪은 문제들

    문제 1: ZFS 풀이 DEGRADED 상태

    # 증상 확인
    zpool status
    # 출력에서 state: DEGRADED 확인
    
    # 디스크 교체 후 복구
    zpool replace rpool /dev/old-disk /dev/new-disk
    
    # 리실버링(데이터 복구) 진행 상황 확인
    zpool status -v
    # 완료까지 기다린 후 state: ONLINE 확인

    문제 2: NFS 마운트 후 VM 시작 느림

    이건 NFS 타임아웃 설정 문제였어요. Proxmox 노드 재시작 시 NFS가 마운트되기 전에 VM이 시작하려다 보니 생기는 문제였습니다.

    # /etc/systemd/system/pve-storage-nas-backup.service.d/ 디렉토리 생성
    mkdir -p /etc/systemd/system/pve-storage-nas-backup.service.d/
    
    # NFS 마운트 의존성 추가
    cat > /etc/systemd/system/pve-storage-nas-backup.service.d/override.conf << 'EOF'
    [Unit]
    After=network-online.target
    Wants=network-online.target
    EOF
    
    systemctl daemon-reload

    문제 3: LVM-Thin 풀 오버커밋 위험

    # LVM-Thin 사용량 모니터링 스크립트
    cat > /usr/local/bin/check-thin-usage.sh << 'EOF'
    #!/bin/bash
    THRESHOLD=80
    USAGE=$(lvs --noheadings -o data_percent vg-data/thin-pool 2>/dev/null | tr -d ' ')
    USAGE_INT=${USAGE%.*}
    
    if [ "$USAGE_INT" -gt "$THRESHOLD" ]; then
        echo "WARNING: LVM-Thin pool usage is ${USAGE}%"
        # 여기에 알림 로직 추가 (메일, Slack 등)
    fi
    EOF
    chmod +x /usr/local/bin/check-thin-usage.sh
    
    # cron에 등록 (5분마다 체크)
    echo '*/5 * * * * root /usr/local/bin/check-thin-usage.sh' >> /etc/cron.d/thin-monitor

    ▲ Proxmox 스토리지 모니터링 대시보드. ZFS 풀 상태, LVM-Thin 사용량, NFS 연결 상태를 한 화면에서 확인하는 구성 예시입니다.

    상황별 Proxmox 스토리지 선택 가이드

    어떤 걸 골라야 하나요?

    결국 "뭐가 제일 좋냐"는 질문에 정답은 없어요. 상황에 따라 다르거든요. 제 추천을 정리하면:

    • 🏠 홈랩, 단일 노드, 데이터 안전성 중시 → ZFS. RAM이 충분하다면 무조건 ZFS 먼저 고려하세요
    • 💻 홈랩, 단일 노드, 심플하게 시작 → LVM-Thin. 복잡함 없이 바로 쓸 수 있어요
    • 🗄️ ISO/백업 파일 공유, 기존 NAS 연동 → NFS. 설정 쉽고 NAS랑 궁합 최고
    • 🏢 다중 노드 클러스터, 라이브 마이그레이션 필요 → iSCSI+LVM 또는 Ceph. Ceph는 다음 글에서 따로 다룰 예정이에요

    마무리: 스토리지는 처음 선택이 반입니다

    Proxmox 스토리지 설정, 생각보다 선택지가 많죠? 저도 처음엔 그냥 기본값으로 쭉 쓰다가 나중에 마이그레이션하느라 고생 많이 했어요. 지금 돌아보면 처음부터 ZFS로 시작했으면 훨씬 편했을 텐데 싶더라고요.

    정리하면:

    • ✅ ZFS: 데이터 무결성, 효율적 스냅샷, 단일 노드 최강자. RAM은 넉넉하게 준비하세요
    • ✅ LVM-Thin: 검증된 안정성, 낮은 진입장벽, 씬 프로비저닝으로 공간 효율적입니다
    • ✅ NFS: 공유 스토리지 입문, NAS 연동, ISO/백업 저장에 딱입니다
    • ✅ iSCSI: 블록 레벨 공유, 클러스터 환경, 설정 복잡하지만 성능 좋습니다

    다음 글에서는 Proxmox 클러스터 환경에서 Ceph를 활용한 분산 스토리지 구성을 다뤄볼 예정입니다. 여러 노드에 걸쳐 데이터를 분산 저장하고 고가용성을 확보하는 방법인데, 홈랩에서도 충분히 구성 가능하더라고요. 혹시 궁금한 점이나 다른 스토리지 구성 경험 있으시면 댓글로 공유해 주세요! 🎉

  • [Proxmox] LXC 컨테이너 활용 가이드: VM보다 가볍게 서비스 배포하기

    VM보다 가볍게, LXC 컨테이너로 홈서버 바꾼 이야기

    솔직히 말씀드리면, 저도 처음엔 Proxmox에서 뭘 돌리든 그냥 VM(가상 머신)만 썼거든요. 익숙하기도 했고, “VM이면 다 되잖아” 하는 안일한 생각도 있었고요. 근데 홈랩 서버에 서비스가 하나둘 늘어나다 보니까 문제가 생기기 시작했습니다. RAM이 부족해지고, 부팅 시간도 길어지고, 작은 서비스 하나 띄우는데 2GB 메모리를 쓰는 게 너무 아까운 거예요.

    그때 제대로 파고들기 시작한 게 바로 Proxmox LXC 컨테이너였습니다. 처음엔 “이게 Docker랑 뭐가 다르지?” 싶었는데, 실제로 써보니까 완전히 다른 매력이 있더라고요. 오늘은 13년간 인프라 엔지니어로 일하면서 직접 삽질해가며 터득한 Proxmox LXC 컨테이너 활용법을 공유해드리려 합니다.

    Proxmox VE 환경에서 LXC 컨테이너와 VM이 함께 운영되는 구조 — 같은 호스트에서 자원 효율성 차이가 확연합니다.

    LXC 컨테이너란? VM과 뭐가 다른가요?

    개념부터 짚고 넘어가겠습니다. 헷갈리는 분들이 많으시더라고요.

    LXC(Linux Containers, 리눅스 컨테이너)는 쉽게 말해서, 커널은 호스트와 공유하면서 독립된 사용자 공간(User Space)을 가지는 가상화 방식입니다. VM처럼 하드웨어를 통째로 에뮬레이션하지 않아요. 그래서 훨씬 가볍습니다.

    구분 VM (가상 머신) LXC 컨테이너 Docker
    커널 공유 ❌ 별도 커널 ✅ 호스트 커널 공유 ✅ 호스트 커널 공유
    격리 수준 매우 높음 높음 중간
    부팅 속도 느림 (수십 초) 빠름 (수 초) 매우 빠름 (즉시)
    메모리 오버헤드 높음 낮음 매우 낮음
    전체 OS 환경 ✅ 완전한 OS ✅ 완전한 OS 환경 ❌ 앱 중심
    systemd 사용 ✅ ✅ ❌ (기본적으로)

    LXC의 포지션이 보이시죠? VM의 완전한 OS 환경은 유지하면서, 자원 사용량은 훨씬 적은 중간 지점이에요. 실제로 제 홈랩에서 Nginx 서버 기준으로 VM은 약 512MB~1GB RAM을 먹는데, LXC 컨테이너는 50~100MB 수준에서 돌더라고요. 이 차이가 쌓이면 정말 엄청납니다.

    Proxmox에서 LXC 컨테이너 생성하기 — 단계별 가이드

    자, 이제 실전으로 들어가겠습니다. Proxmox VE(가상화 환경)에서 LXC 컨테이너를 생성하는 방법인데요. GUI와 CLI 두 가지 방법 모두 알려드릴게요.

    1단계: CT 템플릿(Container Template) 다운로드

    LXC 컨테이너를 만들려면 먼저 기반이 되는 OS 템플릿이 필요합니다. Proxmox에서는 이걸 CT 템플릿이라고 부르고요. GUI에서는 스토리지 → Templates 메뉴에서 바로 다운로드할 수 있어요.

    CLI에서는 이렇게 합니다:

    # 사용 가능한 템플릿 목록 확인
    pveam update
    pveam available --section system
    
    # Ubuntu 22.04 템플릿 다운로드 (local 스토리지에)
    pveam download local ubuntu-22.04-standard_22.04-1_amd64.tar.zst

    2단계: LXC 컨테이너 생성

    GUI에서는 우측 상단 “Create CT” 버튼 클릭 후 마법사를 따라가시면 됩니다. CLI로는 이렇게요:

    # pct create [VMID] [템플릿 경로] [옵션들]
    pct create 200 local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst \
      --hostname my-nginx \
      --memory 512 \
      --swap 512 \
      --cores 2 \
      --net0 name=eth0,bridge=vmbr0,ip=192.168.1.200/24,gw=192.168.1.1 \
      --storage local-lvm \
      --rootfs local-lvm:8 \
      --password YourSecurePassword \
      --unprivileged 1
    
    # 생성된 컨테이너 시작
    pct start 200
    
    # 컨테이너 상태 확인
    pct status 200

    여기서 --unprivileged 1 옵션이 정말 중요합니다. 비특권 컨테이너(Unprivileged Container)로 만드는 건데, 보안상 훨씬 안전해요. 특별한 이유가 없으면 항상 이 옵션을 켜두시길 권장합니다.

    3단계: 컨테이너 접속 및 초기 설정

    # 컨테이너 콘솔 접속
    pct enter 200
    
    # 또는 exec으로 명령어 실행
    pct exec 200 -- bash -c "apt update && apt upgrade -y"

    접속하면 완전한 Ubuntu 환경이 펼쳐집니다. 일반 서버처럼 쓰시면 돼요.

    Proxmox GUI의 LXC 컨테이너 생성 마법사 — 네트워크, 스토리지, 리소스를 단계별로 설정합니다.

    실전 활용 — 자주 쓰는 서비스 배포 예시

    개념만 알면 재미없죠. 제가 실제로 홈랩에서 LXC 컨테이너로 돌리고 있는 서비스 패턴을 공유해드릴게요.

    Nginx 리버스 프록시 컨테이너

    # 컨테이너 안에서
    apt update && apt install -y nginx
    
    # Nginx 설정
    cat > /etc/nginx/sites-available/myapp << 'EOF'
    server {
        listen 80;
        server_name myapp.local;
    
        location / {
            proxy_pass http://192.168.1.100:3000;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
    EOF
    
    ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
    nginx -t && systemctl reload nginx

    컨테이너 설정 파일로 관리하기

    Proxmox LXC 컨테이너는 /etc/pve/lxc/[VMID].conf 파일로 설정이 관리됩니다. 이걸 알면 나중에 설정 백업이나 복제가 훨씬 편해져요.

    # 컨테이너 200번의 설정 파일 확인
    cat /etc/pve/lxc/200.conf
    # 일반적인 LXC 컨테이너 설정 파일 예시
    arch: amd64
    cores: 2
    hostname: my-nginx
    memory: 512
    net0: name=eth0,bridge=vmbr0,gw=192.168.1.1,hwaddr=AA:BB:CC:DD:EE:FF,ip=192.168.1.200/24,type=veth
    ostype: ubuntu
    rootfs: local-lvm:vm-200-disk-0,size=8G
    swap: 512
    unprivileged: 1
    
    # 자동 시작 설정 (서버 재부팅 시 자동으로 컨테이너 시작)
    onboot: 1
    startup: order=1,up=30

    onboot: 1과 startup 옵션은 꼭 설정해두세요. 서버 재부팅 후에 컨테이너가 자동으로 올라오게 됩니다. 처음에 이거 몰라서 재부팅할 때마다 수동으로 시작했었는데... 정말 삽질이었죠 ㅎㅎ

    호스트 디렉토리 마운트 (Bind Mount)

    컨테이너에서 호스트의 특정 디렉토리를 공유해서 쓰고 싶을 때 바인드 마운트(Bind Mount)를 씁니다. 예를 들어 미디어 파일이 호스트에 있는데 컨테이너 안의 Jellyfin에서 접근해야 할 때요.

    # 컨테이너가 중지된 상태에서 마운트 추가
    pct set 200 -mp0 /mnt/data/media,mp=/media,ro=0
    
    # 또는 설정 파일 직접 편집
    # /etc/pve/lxc/200.conf에 아래 줄 추가
    # mp0: /mnt/data/media,mp=/media

    ⚠️ 주의: 비특권 컨테이너(Unprivileged)에서 바인드 마운트 시 UID/GID 매핑 문제가 생길 수 있습니다. 이 부분은 뒤에서 트러블슈팅으로 다룰게요.

    ⚠️ 주의사항과 삽질 기록 — 진짜 겪은 문제들

    이 섹션이 사실 제일 중요할 수 있어요. 공식 문서에는 잘 안 나오는 것들이거든요.

    문제 1: 비특권 컨테이너에서 파일 권한 오류

    비특권 컨테이너는 보안을 위해 UID를 매핑합니다. 컨테이너 안의 root(UID 0)가 호스트에서는 UID 100000으로 보이는 식이에요. 그래서 호스트 디렉토리를 마운트하면 권한 문제가 생깁니다.

    해결 방법:

    # 호스트에서 해당 디렉토리의 소유자를 컨테이너 UID로 변경
    # 컨테이너 안의 UID 1000 사용자 → 호스트에서는 101000
    chown -R 101000:101000 /mnt/data/media
    
    # 또는 chmod로 모든 사용자 접근 허용 (보안 주의)
    chmod -R 777 /mnt/data/media

    문제 2: 특권 기능이 필요한 서비스 (Docker-in-LXC)

    LXC 컨테이너 안에서 Docker를 돌리고 싶을 때가 있거든요. 이게 되긴 합니다만, 설정이 필요합니다.

    # /etc/pve/lxc/200.conf에 추가해야 할 내용
    # (컨테이너 중지 후 편집)
    features: keyctl=1,nesting=1

    이 경우엔 특권 컨테이너(Privileged Container)로 만들거나, nesting 기능을 활성화해야 해요. 저도 처음에 이것 때문에 한참 헤맸습니다. Docker가 계속 실패하는데 이유를 몰라서요.

    문제 3: 컨테이너 네트워크가 안 잡힐 때

    # 컨테이너 안에서 네트워크 확인
    ip addr show
    ip route show
    
    # DNS 확인
    cat /etc/resolv.conf
    
    # DNS가 없다면 추가
    echo "nameserver 8.8.8.8" >> /etc/resolv.conf
    
    # 또는 Proxmox 호스트에서 컨테이너 네트워크 재설정
    pct set 200 --net0 name=eth0,bridge=vmbr0,ip=192.168.1.200/24,gw=192.168.1.1

    문제 4: 컨테이너 스냅샷이 안 될 때

    스냅샷 기능을 쓰려면 스토리지가 스냅샷을 지원해야 합니다. local-lvm(LVM-Thin)이나 ZFS를 쓰면 되고, 일반 ext4 디렉토리 스토리지는 스냅샷이 안 돼요. 이것도 처음에 몰라서 삽질했습니다.

    # 스냅샷 생성
    pct snapshot 200 snap-before-update --description "업데이트 전 백업"
    
    # 스냅샷 목록 확인
    pct listsnapshot 200
    
    # 스냅샷으로 롤백
    pct rollback 200 snap-before-update

    💡 팁: 서비스 업데이트나 큰 변경 전에 스냅샷 찍는 습관을 들이세요. 저는 이게 몇 번이나 저를 살렸는지 모릅니다.

    LXC 컨테이너 관리 꿀팁 모음

    일상적으로 자주 쓰는 관리 명령어들을 정리해드릴게요.

    # 전체 컨테이너 목록 확인
    pct list
    
    # 컨테이너 리소스 사용량 실시간 확인
    pct monitor 200
    
    # 컨테이너 복제 (Clone)
    pct clone 200 201 --hostname my-nginx-clone --full
    
    # 컨테이너 백업
    vzbackup 200 --storage local --mode snapshot
    
    # 컨테이너 중지 및 삭제
    pct stop 200
    pct destroy 200
    
    # 실행 중인 컨테이너에 리소스 핫 변경 (재시작 불필요)
    pct set 200 --memory 1024
    pct set 200 --cores 4

    특히 리소스 핫 변경은 정말 편한 기능이에요. VM은 보통 재시작해야 메모리 변경이 되는데, LXC는 실행 중에도 바로 적용됩니다. 이거 처음 알았을 때 "아 이래서 LXC 쓰는구나" 했던 기억이 나네요.

    여러 LXC 컨테이너가 동시에 운영되는 Proxmox 환경 — 각 컨테이너의 CPU, 메모리 사용량을 실시간으로 확인할 수 있습니다.

    ✅ 결과 확인 — 실제로 얼마나 가벼워졌나?

    제 홈랩 기준으로 비교해드릴게요. 같은 Nginx + 간단한 웹 앱 기준입니다.

    항목 Ubuntu VM Ubuntu LXC 컨테이너
    부팅 시간 약 30~40초 약 3~5초
    유휴 메모리 사용 약 400~600MB 약 50~100MB
    디스크 사용 (OS 기본) 약 3~5GB 약 300~500MB
    스냅샷 생성 속도 느림 빠름
    systemd 지원 ✅ ✅

    이 차이 덕분에 저는 기존에 VM 5개로 돌리던 서비스를 LXC 컨테이너 12개로 확장했는데도 오히려 전체 메모리 사용량이 줄었습니다. 🎉 같은 하드웨어에서 더 많은 서비스를 돌릴 수 있게 된 거죠.

    경량 서비스 배포 측면에서 LXC 컨테이너는 정말 강력한 선택지입니다. Prometheus, Grafana, Gitea, Nextcloud 같은 서비스들 모두 LXC에서 잘 돌아가거든요.

    자주 묻는 질문 (FAQ)

    Q. LXC 컨테이너와 Docker 중 뭘 써야 하나요?
    A. 서비스 성격에 따라 다릅니다. 완전한 OS 환경이 필요하거나 systemd를 써야 하면 LXC, 앱 하나만 가볍게 격리할 거면 Docker가 적합해요. 저는 둘 다 쓰는데, LXC 안에 Docker를 넣기도 합니다.

    Q. Windows를 LXC 컨테이너로 돌릴 수 있나요?
    A. 안 됩니다. LXC는 Linux 커널 기반이라 Linux 배포판만 지원합니다. Windows는 반드시 VM으로 돌려야 해요.

    Q. LXC 컨테이너도 GPU 패스스루가 되나요?
    A. 됩니다! VM의 PCIe 패스스루보다 설정이 간단한 편이에요. 관련 내용은 다음 글에서 다룰 예정입니다.

    LXC 컨테이너와 VM의 특성 비교 요약 — 서비스 유형에 따른 최적 선택 가이드.

    마무리 — 언제 LXC를 쓰고 언제 VM을 써야 할까?

    13년간 인프라 일 하면서 내린 결론을 드리자면, 이렇게 판단합니다:

    • ✅ LXC 컨테이너 추천: 웹 서버, 데이터베이스, 모니터링 도구, 파일 서버, 홈 자동화 서버처럼 Linux 기반 서비스 단순 배포
    • ✅ VM 추천: Windows 환경, 커널 수준 격리가 필요한 경우, 다른 하이퍼바이저나 OS를 테스트할 때, 강한 보안 격리가 필요한 프로덕션 환경

    Proxmox의 진짜 장점은 이 두 가지를 같은 플랫폼에서 자유롭게 섞어 쓸 수 있다는 거예요. 저는 중요한 서비스는 VM에, 나머지 경량 서비스들은 모두 LXC 컨테이너로 돌리는 하이브리드 방식을 쓰고 있습니다.

    처음 LXC를 접하면 낯설 수 있는데, 한 번 익숙해지면 정말 못 돌아가요. 이거 진짜더라고요. 홈랩 운영하시는 분들이라면 꼭 한번 도전해보시길 권합니다!

    다음 글에서는 Proxmox LXC 컨테이너에서 GPU 패스스루 설정하는 방법을 다뤄볼 예정입니다. 궁금한 점은 댓글로 남겨주시면 답변드리겠습니다. 🎉