13년차의 서버실

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

[태그:] 홈랩 스토리지

  • [Nas] TrueNAS SCALE 1년 사용 후기: 홈랩 운영 교훈과 팁

    [Nas] TrueNAS SCALE 1년 사용 후기: 홈랩 운영 교훈과 팁

    TrueNAS SCALE 1년 사용 후기: 홈랩 운영 교훈과 팁

    홈랩을 오래 굴리다 보면 결국 한 번은 스토리지 구조를 다시 보게 되더라고요. VM(가상머신), 컨테이너, 백업, 미디어 라이브러리까지 한 장비에 몰리기 시작하면 작은 설정 실수 하나가 꽤 크게 돌아옵니다. 그래서 오늘은 제가 직접 굴려본 TrueNAS SCALE 사용 후기를 정리해보려고 합니다. 단순히 좋다, 나쁘다 수준이 아니라, TrueNAS SCALE 홈랩 환경에서 1년 정도 운영하면서 어떤 점이 편했고, 어디서 삽질했는지, 그리고 지금 다시 세팅한다면 무엇부터 다르게 할지를 중심으로 적어보겠습니다.

    특히 NAS 운영체제 선택 때문에 고민하시는 분들, ZFS(제트에프에스, 데이터 무결성과 스냅샷에 강한 파일시스템)를 실제 운영 관점에서 보고 싶은 분들께 도움이 될 겁니다. 저도 처음엔 기능표만 보고 골랐었는데, 실제로 써보니까 체크해야 할 포인트가 완전히 다르더라고요.

    홈랩에서 NAS, 백업 장비, 미디어 서버, 가상화 호스트가 어떻게 연결되는지 한눈에 보여주는 아키텍처 이미지입니다.

    왜 TrueNAS SCALE 사용 후기가 중요한가

    쉽게 말해 홈랩의 스토리지는 모든 서비스의 바닥입니다. 애플리케이션이야 다시 띄우면 되는데, 데이터가 꼬이면 복구 비용이 훨씬 커지거든요. 제가 TrueNAS SCALE을 선택한 이유도 여기 있었습니다. Linux(리눅스) 기반의 운영 경험을 살리면서도, ZFS의 장점을 활용해 데이터 무결성, 스냅샷, 복제 같은 기본기를 챙기고 싶었어요.

    다만 여기서 중요한 포인트가 있습니다. TrueNAS SCALE이 만능은 아닙니다. UI(사용자 인터페이스)가 있다고 해서 설계 고민이 없어지는 건 아니고, 오히려 디스크 구성, 공유 방식, 앱 배치, 백업 전략을 더 분명하게 정해야 하더라고요. 이걸 안 하면 초반엔 편한데 몇 달 뒤부터 복잡성이 확 올라갑니다.

    TrueNAS SCALE 홈랩에서 이해해야 할 핵심 개념

    ZFS와 풀(Pool) 개념부터 잡아야 합니다

    처음엔 저도 디스크를 그냥 묶으면 되는 줄 알았어요. 근데 ZFS는 생각보다 철학이 분명합니다. 파일 하나하나보다 풀(Pool)과 데이터셋(Dataset) 단위로 운영 감각을 가져가야 편합니다.

    • Pool(풀): 물리 디스크 집합입니다. 저장소의 큰 그릇이라고 보면 됩니다.
    • Dataset(데이터셋): 폴더처럼 보이지만, 압축, 스냅샷, 권한 정책을 따로 줄 수 있는 논리 단위입니다.
    • Snapshot(스냅샷): 특정 시점 상태를 잡아두는 기능입니다. 삭제 실수나 설정 꼬임 복구에 정말 유용합니다.
    • Scrub(스크럽): 데이터 무결성을 주기적으로 검사하는 작업입니다.
    • Replication(복제): 다른 시스템이나 다른 풀로 스냅샷 기반 복사를 하는 방식입니다.

    제가 실제로 써보니까, 폴더 구조를 먼저 만드는 것보다 데이터 성격별로 데이터셋을 쪼개는 설계가 훨씬 중요했습니다. 예를 들어 백업, 미디어, 문서, 컨테이너 볼륨을 한 군데 섞어두면 나중에 스냅샷 주기와 권한 정책을 맞추기가 너무 힘들어집니다.

    NAS 운영체제 관점에서 봤을 때 차이점

    항목 TrueNAS SCALE 일반적인 단순 파일서버 구성
    파일시스템 운영 ZFS 기반으로 스냅샷과 무결성 관리에 강함 구성에 따라 기능 편차가 큼
    관리 방식 웹 UI 중심, 일부는 CLI(명령줄 인터페이스) 병행 직접 수동 관리 비중이 높음
    백업 전략 스냅샷/복제 설계가 쉬운 편 별도 스크립트나 도구 의존도가 높음
    초기 진입장벽 개념 이해가 필요함 단순 구성은 빠르지만 확장 시 복잡해짐

    그래서 TrueNAS SCALE 사용 후기를 한 줄로 줄이면 이렇습니다. 초반엔 학습 비용이 있지만, 운영이 길어질수록 그 비용을 회수하게 됩니다.

    제가 실제로 구성한 방식과 단계별 세팅 흐름

    아래는 제가 홈랩에서 정착한 기본 흐름입니다. 특정 하드웨어 모델이나 버전 숫자보다, 운영 원칙 자체가 더 중요해서 그 부분 위주로 적겠습니다.

    1. 디스크 역할을 먼저 정합니다. 운영 데이터와 백업 데이터를 논리적으로 분리합니다.
    2. ZFS 풀을 만들고, 용도별 데이터셋을 나눕니다.
    3. SMB(에스엠비, 윈도우 파일 공유)나 NFS(엔에프에스, 유닉스 계열 네트워크 파일 공유) 공유를 목적에 맞게 나눕니다.
    4. 스냅샷 주기를 데이터 중요도별로 다르게 잡습니다.
    5. 외부 백업 또는 다른 장비로 복제를 붙입니다.
    6. 앱 데이터와 일반 파일 데이터를 같은 정책으로 다루지 않습니다.

    1. 데이터셋 구조를 먼저 설계했습니다

    처음엔 그냥 tank/data 하나로 밀어붙였었는데요, 몇 달 지나니까 스냅샷 관리가 너무 지저분해졌습니다. 그래서 아래처럼 다시 나눴어요.

    # 예시 구조
    /home
      /tank
        /backup
        /media
        /documents
        /apps
        /vmdata

    실제 명령은 UI로 해도 되지만, 개념은 이렇게 이해하면 편합니다. 핵심은 백업 데이터셋과 앱 데이터셋을 분리하는 겁니다. 앱 쪽은 변경이 잦고, 미디어는 상대적으로 정적이거든요.

    2. 스냅샷 정책은 동일하게 주지 않았습니다

    이 부분에서 삽질 좀 했습니다 ㅎㅎ 처음엔 전부 같은 주기로 스냅샷을 잡았는데, 공간 사용 패턴이 완전히 다르더라고요. 지금은 대략 이런 식으로 생각해요.

    데이터 유형 권장 접근 이유
    문서/설정 짧은 주기 스냅샷 실수 복구 가치가 큼
    미디어 파일 긴 주기 또는 최소화 변경 빈도가 낮음
    앱 볼륨 업데이트 전 스냅샷 롤백이 필요할 수 있음
    백업 저장소 중복 정책 주의 백업 위에 또 과한 스냅샷은 비효율적일 수 있음

    3. 공유 서비스는 목적별로 나눴습니다

    Windows PC가 많으면 SMB가 편하고, 리눅스 호스트나 하이퍼바이저와 붙일 땐 NFS가 더 자연스러울 때가 있어요. 저는 처음에 다 SMB로 밀었다가 권한과 마운트 습관 때문에 다시 정리했습니다.

    # Linux 클라이언트에서 NFS 마운트 예시
    sudo mkdir -p /mnt/homelab-media
    sudo mount -t nfs truenas.local:/mnt/tank/media /mnt/homelab-media

    이런 식으로 용도를 분명히 나누면 클라이언트 쪽도 덜 꼬입니다. 특히 Proxmox 같은 가상화 호스트나 Docker 호스트와 연동할 때 체감이 크더라고요.

    TrueNAS SCALE 홈랩의 스토리지 풀과 데이터셋 구성 이미지

    스토리지 풀 생성부터 데이터셋 분리, SMB/NFS 공유까지 연결되는 흐름을 보여주는 구성 이미지입니다.

    4. 백업은 NAS 안에서 끝내지 않았습니다

    여기 정말 중요합니다. 많은 분들이 NAS를 넣으면 백업이 끝났다고 생각하시는데, 사실은 그때부터가 시작이거든요. NAS는 저장소이고, 백업은 별도 전략입니다. 저도 처음엔 풀 하나만 믿고 갔었는데, 그건 그냥 단일 장애 지점을 조금 덜 불편하게 만든 수준이었어요.

    그래서 지금은 최소한 아래 원칙으로 갑니다.

    • 중요 데이터는 스냅샷을 유지합니다.
    • 가능하면 다른 장비나 외부 저장소로 복제합니다.
    • 복구 테스트를 실제로 해봅니다.
    # rsync 기반 외부 백업 예시
    rsync -avh --delete /mnt/tank/documents/ /backup-target/documents/

    물론 환경에 따라 ZFS 복제를 쓰는 게 더 자연스러울 수 있습니다. 중요한 건 도구가 아니라 복구 경로가 실제로 있느냐입니다.

    ⚠️ 1년 동안 겪었던 문제와 해결 과정

    문제 1. 스냅샷은 많은데 정리가 안 됐습니다

    처음엔 스냅샷이 많으면 무조건 좋은 줄 알았어요. 근데 오래 가동해보니, 남기는 정책보다 언제 지울지가 더 중요하더라고요. 복구 지점은 많아졌는데, 운영자가 이해하지 못하는 스냅샷 체계는 결국 사고를 부립니다.

    • 해결: 데이터 성격별 보존 정책을 다시 분리했습니다.
    • 교훈: 스냅샷은 보험이지만, 보험 증권이 정리 안 되면 사고 때 더 헷갈립니다.

    문제 2. 앱 데이터와 일반 파일 데이터를 섞었습니다

    이건 제가 제일 크게 후회한 부분입니다. 컨테이너 볼륨, 다운로드 폴더, 미디어 라이브러리를 한쪽에 섞어두니까 권한도 꼬이고, 성격이 다른 데이터를 한 정책으로 다뤄야 했어요. 처음엔 간단해서 좋았는데 나중엔 유지보수가 훨씬 어려웠습니다.

    • 해결: 앱 전용 데이터셋을 따로 만들고, 일반 공유 데이터와 분리했습니다.
    • 교훈: 운영 데이터는 목적별 분리가 기본입니다.

    문제 3. 디스크 확장 계획을 너무 늦게 생각했습니다

    홈랩은 늘 그렇죠. 처음엔 충분해 보입니다. 근데 VM 이미지, 백업, 미디어가 쌓이기 시작하면 생각보다 금방 차더라고요. 여기서 중요한 건 단순 총용량이 아니라, 어떤 방식으로 확장할 건지를 미리 생각해야 한다는 점입니다.

    • 해결: 데이터 성장 패턴을 보고, 정적 데이터와 변동 데이터의 저장 위치를 분리했습니다.
    • 교훈: 용량 계획은 숫자보다 구조입니다.

    문제 4. UI만 믿고 내부 동작을 대충 넘겼습니다

    솔직히 웹 UI가 있으니까 너무 편했습니다. 근데 문제 생기면 결국 로그, 권한, 마운트 구조, 네트워크 흐름을 봐야 하더라고요. 저도 처음엔 이게 뭔가 싶었는데, 몇 번 장애를 겪고 나니까 UI는 입구일 뿐이고, 운영 이해는 따로 챙겨야 한다는 걸 배웠습니다.

    검증: 1년 운영 후 남은 것들

    그럼 결과적으로 만족했냐고 물으시면, 제 대답은 예, 다만 설계를 해가면서 만족도가 올라가는 타입입니다. 처음 세 달은 적응기였고, 중간에 구조를 한 번 갈아엎고 나서야 훨씬 편해졌어요.

    • ✅ 데이터셋 분리 이후 스냅샷 관리가 훨씬 쉬워졌습니다.
    • ✅ 공유 목적이 분명해져서 클라이언트 마운트 문제도 줄었습니다.
    • ✅ 백업 관점을 따로 가져가니 심리적으로도 훨씬 안정적이었습니다.
    • ⚠️ 반대로, 설계 없이 시작하면 나중에 구조조정 비용이 꽤 큽니다.

    특히 TrueNAS SCALE 사용 후기를 찾는 분들께 말씀드리고 싶은 건, 이 제품이 마법처럼 문제를 없애주지는 않는다는 점입니다. 대신 스토리지를 제대로 운영하게 만드는 압력은 분명히 있습니다. 저는 그 점이 오히려 좋았습니다.

    TrueNAS SCALE 사용 후기의 운영 결과를 보여주는 대시보드 이미지

    스냅샷 주기, 저장소 사용량, 백업 상태가 안정적으로 관리되는 모습을 보여주는 대시보드형 이미지입니다.

    홈랩에서 바로 써먹는 팁 정리

    스토리지 교훈 5가지

    1. 폴더보다 데이터셋부터 생각하세요. ZFS의 장점은 여기서 살아납니다.
    2. 스냅샷은 많이보다 적절하게. 보존 정책이 핵심입니다.
    3. NAS와 백업을 같은 개념으로 보면 안 됩니다. 이건 진짜 중요합니다.
    4. 앱 데이터는 일반 공유와 분리하세요. 나중에 반드시 편해집니다.
    5. 복구 테스트를 실제로 해보세요. 백업 성공 메시지보다 복구 성공이 더 중요합니다.

    이런 분들께 특히 잘 맞습니다

    • 홈랩에서 VM, 컨테이너, 파일 공유를 함께 운영하는 분
    • ZFS 기반으로 스토리지 운영 습관을 제대로 잡고 싶은 분
    • 장기적으로 정리된 NAS 운영체제를 원하는 분

    반대로, 아주 단순한 파일 저장만 필요하고 학습 비용을 최소화하고 싶다면 조금 무겁게 느껴질 수도 있어요. 이건 솔직히 사용 목적에 따라 갈리는 부분입니다.

    자주 묻는 질문

    Q1. TrueNAS SCALE 홈랩 용도로 시작해도 괜찮을까요?

    괜찮습니다. 다만 처음부터 완벽하게 하려 하지 마시고, 데이터셋 분리와 백업 구조만 먼저 잡으세요. 나머지는 운영하면서 다듬는 편이 현실적입니다.

    Q2. ZFS는 왜 그렇게 많이 언급되나요?

    데이터 무결성, 스냅샷, 복제 같은 운영 핵심 기능을 한 흐름으로 가져가기 좋기 때문입니다. 쉽게 말해, 나중에 후회할 가능성을 줄여주는 설계 철학이 있습니다.

    Q3. TrueNAS SCALE 사용 후기에서 가장 큰 교훈 하나만 꼽는다면요?

    설계 없는 편의성은 오래 못 간다는 점입니다. 처음 며칠보다 6개월 뒤를 기준으로 구조를 잡으셔야 합니다.

    TrueNAS SCALE 사용 후기와 스토리지 교훈 요약 인포그래픽

    도입 난이도, 운영 편의성, 백업 전략, 확장성 관점에서 핵심 교훈을 정리한 요약 인포그래픽입니다.

    마무리: 1년 써보고 나서 남은 생각

    정리해보면, 이번 TrueNAS SCALE 사용 후기의 핵심은 제품 자체보다 운영 태도에 더 가깝습니다. 좋은 NAS 운영체제는 버튼이 많은 시스템이 아니라, 데이터를 함부로 다루지 않게 만드는 시스템이더라고요. 제가 직접 해보니 편한 점도 분명히 많았고, 동시에 대충 설계하면 그 대가도 분명했습니다.

    혹시 지금 홈랩 스토리지를 새로 짜고 계신가요? 그렇다면 디스크 용량표부터 보지 마시고, 어떤 데이터를 얼마나 오래, 어떤 방식으로 복구할 건지부터 적어보세요. 거기서 절반은 이미 끝납니다. 다음 글에서는 스냅샷 보존 정책과 백업 분리 전략을 좀 더 실전적으로 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 네트워크 분리 내용과 같이 보시면 훨씬 이해가 잘 되실 겁니다. 🎉

  • [Proxmox] Proxmox Ceph 스토리지 1년 실사용 후기: 장점, 단점, 비용 분석

    [Proxmox] Proxmox Ceph 스토리지 1년 실사용 후기: 장점, 단점, 비용 분석

    Proxmox Ceph 스토리지 1년 실사용 후기: 장점, 단점, 비용 분석

    안녕하세요, 13년차 서버실 지킴이입니다. 13년차 인프라 엔지니어로 홈랩을 운영하면서 가장 크게 느꼈던 부분 중 하나가 바로 스토리지거든요. 처음엔 NAS(Network Attached Storage) 하나로 버텨봤는데, VM(Virtual Machine)도 늘어나고 데이터도 중요해지면서 단일 스토리지의 한계에 부딪히더라고요.

    Proxmox VE(Virtual Environment)를 쓰면서 여러 노드를 묶는 건 좋았는데, 각 노드에 붙은 로컬 스토리지(Local Storage)만으로는 VM 마이그레이션(Live Migration)이나 고가용성(High Availability, HA)을 구현하기가 애매했어요. 그래서 결국 분산 스토리지(Distributed Storage), 그중에서도 Ceph를 선택하게 됐고, Proxmox와 Ceph의 조합이 꽤 괜찮다는 이야기를 듣고 직접 구축해서 1년 넘게 써봤습니다. 그 솔직한 후기를 여러분께 공유해볼까 합니다. 저의 삽질 경험과 해결 과정이 여러분의 홈랩 구축에 도움이 되기를 바랍니다!

    Proxmox와 Ceph를 활용한 홈랩 분산 스토리지의 일반적인 아키텍처 다이어그램입니다. 여러 노드가 Ceph 클러스터를 구성하고 Proxmox가 이를 스토리지로 활용하는 구조를 보여줍니다.

    개념 설명: Proxmox Ceph, 도대체 뭘까요?

    Ceph(세프)는 오픈소스 기반의 분산 스토리지 시스템(Distributed Storage System)이거든요. 쉽게 말해, 여러 대의 서버에 있는 하드디스크나 SSD(Solid State Drive)를 마치 하나의 거대한 저장 공간처럼 묶어서 쓸 수 있게 해주는 기술입니다. 이게 단순히 파일 공유를 넘어, 블록 스토리지(Block Storage)나 객체 스토리지(Object Storage)까지 다양한 인터페이스를 제공해서 VM 디스크나 컨테이너 볼륨으로 쓰기에 아주 적합하더라고요.

    Proxmox VE는 가상화 플랫폼인데, Ceph 클러스터를 직접 구성하고 관리할 수 있는 기능이 내장돼 있어요. 덕분에 별도의 스토리지 서버를 구축하지 않고도 기존 Proxmox 노드를 활용해서 분산 스토리지를 만들 수 있죠. 이게 바로 제가 Ceph를 선택한 결정적인 이유 중 하나입니다. 고가용성(High Availability)이나 실시간 마이그레이션(Live Migration) 같은 기능들을 Ceph 스토리지와 함께 쓰면 더욱 강력해지는 걸 경험할 수 있거든요.

    1년 실사용 후기: 장점은 확실하네요!

    제가 1년 동안 Proxmox Ceph를 쓰면서 가장 만족스러웠던 점들을 꼽아보자면 이렇습니다.

    • ✅ 데이터 안전성 및 고가용성(HA): Ceph는 데이터를 여러 노드에 복제(replication)해서 저장하거든요. 예를 들어, 제가 3개의 노드에 Ceph를 구성하고 복제본 3개(replica 3)로 설정했었는데, 어느 날 노드 하나가 갑자기 다운되어도 VM들은 아무 문제 없이 잘 돌아가는 걸 보고 감탄했습니다. 이게 바로 HA의 위력이죠. 데이터 손실 걱정 없이 안정적으로 서비스를 운영할 수 있다는 점이 가장 든든했어요.

    • ✅ 쉬운 확장성(Scalability): 스토리지 용량이 부족하면 그냥 새로운 노드를 추가하거나, 기존 노드에 디스크를 더 달아서 Ceph OSD(Object Storage Daemon)로 추가하면 돼요. Proxmox 웹 UI(User Interface)에서 몇 번 클릭만 해주면 Ceph 클러스터가 자동으로 재조정되면서 용량이 늘어나더군요. 이 확장성 덕분에 홈랩을 운영하면서 스토리지 용량 걱정을 덜었습니다. SSD 몇 개 더 달아서 Ceph OSD로 추가하면 끝! 정말 편하더라고요.

    • ✅ 준수한 성능(Performance): 제 홈랩에서는 SATA SSD와 HDD를 섞어 썼는데, SSD로 구성된 OSD에서는 VM 성능이 꽤 만족스러웠어요. 여러 OSD에 데이터가 분산되어 저장되니 병렬 처리 효과도 있어서 단일 디스크보다 빠릿한 느낌이었습니다. 물론 엔터프라이즈급 장비만큼은 아니지만, 홈랩에서는 차고 넘치는 성능이었어요.

    • ✅ Proxmox와의 긴밀한 통합 관리: Proxmox 웹 인터페이스에서 Ceph 클러스터의 상태를 한눈에 볼 수 있고, OSD 추가/삭제, 풀(Pool) 관리까지 대부분의 작업을 처리할 수 있어서 관리 편의성이 정말 좋았습니다. 처음엔 Ceph 명령어를 일일이 쳐야 하나 걱정했는데, 통합 관리(Integrated Management) 덕분에 삽질을 많이 줄일 수 있었죠. 이거 진짜 편하더라고요.

    Proxmox 웹 UI Ceph 클러스터 상태 대시보드 화면

    Proxmox 웹 UI에서 Ceph 클러스터의 전반적인 상태를 보여주는 대시보드 화면입니다. OSD 상태, Health, 용량 정보 등을 한눈에 확인할 수 있습니다.

    아쉬웠던 점: 단점과 삽질 경험

    물론 장점만 있었겠습니까? 1년 동안 쓰면서 아쉬웠던 점이나 삽질했던 경험들도 꽤 됩니다. 처음엔 이게 뭔가 싶었는데, 해결하고 나니 다 피가 되고 살이 되더군요. ㅎㅎ

    • ⚠️ 초기 설정 및 트러블슈팅의 복잡성: Proxmox UI가 많이 도와주긴 하지만, Ceph 클러스터의 기본적인 아키텍처(Mon, OSD, Mgr 등)를 이해하지 못하면 문제 발생 시 해결하기가 쉽지 않더라고요. 저는 처음에 Ceph Monitor(모니터)를 3개로 구성해야 안정적이라는 걸 모르고 1개로 시작했다가, 노드 하나가 다운되니 클러스터 헬스가 엉망이 되는 경험을 했습니다. 이럴 때 ceph status 명령어로 클러스터 상태를 확인해볼 수 있어요.

      ceph status

      이 명령어를 통해 Mon(모니터), OSD(오브젝트 스토리지 데몬) 등의 상태를 확인하고 문제점을 파악할 수 있었죠. 결국 Mon을 추가하고 안정화시키는 데 삽질 좀 했습니다.

    • ⚠️ 생각보다 높은 자원 소모: Ceph는 분산 스토리지다 보니 각 노드에서 OSD 프로세스가 계속 돌아갑니다. 특히 디스크 I/O가 많아지면 CPU 사용량도 꽤 올라가고, RAM도 OSD 하나당 최소 2~4GB 정도는 필요하다고 느껴졌어요. 홈랩에서 저사양 장비로 구성하려다 보니, VM 몇 개 돌리기도 전에 Ceph 자체가 자원을 너무 많이 먹어서 VM 성능이 저하되는 경험도 했었네요. 자원 계획(Resource Planning)이 정말 중요합니다. 이거 진짜 간과하기 쉬운 포인트예요!

    • ⚠️ 네트워크 대역폭의 중요성: Ceph는 노드 간에 데이터를 주고받는 통신이 매우 활발합니다. 처음엔 1GbE(기가비트 이더넷) 네트워크로 구성했다가 VM 성능이 영 시원찮아서 고생했어요. 데이터를 복제하고 재배치하는 과정에서 네트워크가 병목(bottleneck)이 되더군요. 결국 10GbE(텐 기가비트 이더넷) NIC(Network Interface Card)를 추가하고 스위치도 바꾸면서 해결했는데, 이 비용도 만만치 않았습니다. Ceph를 제대로 쓰려면 최소 10GbE 네트워크는 필수라고 생각해요.

    • ⚠️ 성능 튜닝의 어려움: Ceph의 성능을 최적화하려면 OSD 디스크의 종류(SSD vs HDD), 저널링(Journaling) 방식, 네트워크 구성, 풀(Pool) 설정 등 고려할 요소가 너무 많아요. 저도 여러 자료를 찾아보면서 이것저것 튜닝해봤지만, ‘이게 최적이다!’라고 딱 말하기가 어렵더라고요. 이 부분은 여전히 저에게 숙제로 남아있습니다.

    비용 분석: 홈랩에서 Ceph, 합리적일까요?

    그럼 이제 가장 궁금해하실 부분 중 하나, 비용 분석을 해볼 차례입니다. 홈랩에서 Proxmox Ceph를 구축하는 게 과연 합리적일까요? 저의 경우를 예로 들어볼게요. (대략적인 비용이며, 실제 제품명/가격은 언급하지 않습니다.)

    • 서버: 저는 기존에 가지고 있던 미니 PC 3대를 활용했습니다. (약 30만원 x 3대 = 90만원 상당)

    • 디스크: Ceph OSD용으로 SATA SSD 2TB 3개, HDD 4TB 3개를 추가 구매했습니다. (SSD 약 15만원 x 3개 = 45만원, HDD 약 10만원 x 3개 = 30만원)

    • 네트워크 장비: 10GbE NIC 3개와 10GbE 지원 스위치 1대를 구매했습니다. (NIC 약 8만원 x 3개 = 24만원, 스위치 약 20만원 = 20만원)

    • 전기 요금: 3대의 서버가 24시간 돌아가니 한 달에 대략 3~5만원 정도 추가 요금이 발생하더군요. (연간 36~60만원)

    초기 하드웨어 투자 비용만 대략 200만원 정도 들었습니다. 여기에 전기 요금까지 고려하면 꽤 부담될 수 있는 금액이죠. 하지만 이 비용으로 얻는 데이터 안전성, 고가용성, 확장성을 생각하면 충분히 가치 있는 투자라고 생각해요. 특히 소프트웨어 라이선스 비용이 없다는 점은 큰 장점입니다. 엔터프라이즈급 SDS(Software Defined Storage) 솔루션에 비하면 훨씬 저렴하게 동일한 수준의 분산 스토리지를 구축할 수 있거든요.

    하지만 삽질 비용(시간과 노력)은 계산하기 어렵습니다. 저처럼 직접 구성하고 문제를 해결하는 과정을 즐기는 분들에게는 더없이 좋은 경험이 되겠지만, 단순히 ‘편리한 스토리지’만을 원한다면 초기 진입 장벽이 높다고 느낄 수도 있어요. 이 부분은 스스로에게 질문을 던져봐야 합니다!

    Proxmox Ceph 스토리지 구축 및 운영 비용 분석 차트

    Proxmox Ceph 스토리지 구축 및 운영에 필요한 주요 비용 요소를 시각적으로 보여주는 원형 차트입니다. 하드웨어, 전기 요금, 소프트웨어(오픈소스), 그리고 시간/노력의 비율을 나타냅니다.

    결론: Proxmox Ceph, 당신에게 어울릴까요?

    자, 이제 1년 동안 Proxmox Ceph를 써본 저의 최종 결론을 말씀드릴 시간입니다.

    Proxmox Ceph 스토리지, 이런 분들께 강력 추천합니다!

    • 💡 고가용성(HA)과 데이터 안전성을 중요하게 생각하는 홈랩 사용자: 중요한 VM 데이터가 있다면 Ceph의 복제 기능은 정말 든든한 보험입니다.

    • 💡 분산 스토리지 기술을 깊이 있게 경험하고 싶은 인프라 엔지니어: 실제 환경에서 Ceph를 구축하고 운영해보는 것만큼 좋은 학습은 없어요. 저도 이 과정을 통해 많은 것을 배웠습니다.

    • 💡 확장성 있는 스토리지가 필요한 분: 나중에 용량이 부족해질까 걱정 없이, 필요할 때마다 노드나 디스크를 추가하여 유연하게 확장하고 싶은 분들께 아주 좋습니다.

    하지만 이런 분들께는 좀 더 고민해보시라고 말씀드리고 싶어요.

    • ❌ 단순히 저렴하고 빠른 스토리지만을 원하는 분: 초기 설정의 복잡성이나 자원 소모를 감당하기 어려울 수 있어요. 이 경우엔 그냥 단일 NAS나 로컬 SSD를 쓰는 게 더 나을 수도 있습니다.

    • ❌ 기술적인 삽질(?)을 즐기지 않는 분: 안정적인 운영을 위해서는 Ceph에 대한 기본적인 이해와 트러블슈팅 능력이 필요합니다. 그냥 설치만 하면 끝나는 게 아니거든요!

    Proxmox Ceph 스토리지 장점, 단점 및 추천 대상 요약 인포그래픽

    Proxmox Ceph 스토리지의 주요 장점과 단점을 요약하고, 어떤 사용자에게 적합한지 추천 대상을 시각적으로 정리한 인포그래픽입니다.

    마무리: 다음 여정은?

    1년 동안 Proxmox Ceph와 함께 하면서 정말 많은 것을 느끼고 배웠어요. 초반에는 삽질의 연속이었지만, 결국 안정적인 분산 스토리지를 구축하고 운영하게 되면서 인프라 엔지니어로서 한 단계 더 성장한 것 같습니다. 드디어 됐다! 하는 성취감도 있었고요.

    다음번에는 CephFS(Ceph File System)를 활용해서 여러 VM에서 공유 스토리지를 쓰는 방법에 대해서도 다뤄볼까 합니다. 아니면 Ceph 오브젝트 스토리지(Object Storage)를 연동해서 S3 호환 스토리지를 구축하는 이야기도 재미있겠네요. 이전 글에서 다뤘던 Proxmox 초기 설정 관련 내용도 함께 참고하시면 좋을 것 같아요.

    혹시 여러분도 Proxmox Ceph를 사용 중이시거나, 구축을 고민하고 계시다면 어떤 점이 가장 궁금하신가요? 댓글로 자유롭게 의견 남겨주세요! 저의 경험이 여러분의 홈랩 구축에 조금이나마 도움이 되었기를 바랍니다. 🎉

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