13년차의 서버실

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

[태그:] 스토리지 솔루션

  • [NAS] iSCSI와 S3 호환 스토리지, 홈랩 환경에서의 비용 효율성 분석

    [NAS] iSCSI와 S3 호환 스토리지, 홈랩 환경에서의 비용 효율성 분석

    [NAS] iSCSI와 S3 호환 스토리지, 홈랩 환경에서의 비용 효율성 분석

    안녕하세요, 13년차의 서버실 주인장입니다. 홈랩을 운영하다 보면 가장 큰 고민 중 하나가 바로 스토리지(Storage) 아닐까 싶어요. 데이터는 점점 불어나는데, 어디에 어떻게 저장하고 관리할지 늘 새로운 숙제가 생기거든요. 저도 처음엔 단순히 하드디스크만 늘리면 되는 줄 알았는데, 이게 또 생각보다 복잡하더라고요. 특히 비용 효율성까지 따지기 시작하면 머리가 지끈거려요. 오늘은 제가 홈랩에서 직접 겪었던 경험을 바탕으로 iSCSI와 S3 호환 스토리지 두 가지 방식의 비용 효율성을 깊이 있게 분석해보려고 합니다. 여러분의 NAS 스토리지 선택과 홈랩 비용 분석에 도움이 되길 바랍니다.

    홈랩 네트워크 아키텍처 다이어그램: iSCSI NAS와 S3 호환 스토리지 서버 구성

    홈랩 환경에서 iSCSI와 S3 호환 스토리지가 어떻게 연동되는지 보여주는 네트워크 다이어그램: 서버, NAS, S3 호환 스토리지 서버, 그리고 클라이언트들이 유선 네트워크로 연결되어 데이터가 오가는 모습을 시각화합니다.

    1. iSCSI: 블록 스토리지의 강력함과 익숙함

    먼저 iSCSI(Internet Small Computer System Interface)부터 이야기해볼까요? 쉽게 말해, 네트워크를 통해 마치 로컬 디스크처럼 스토리지를 사용하는 기술입니다. 보통 기업 환경의 SAN(Storage Area Network)에서 사용하는 블록 스토리지(Block Storage) 방식을 IP 네트워크 위에서 구현한 것이라고 보시면 돼요. 제가 처음 iSCSI를 접했을 때는 ‘아니, 네트워크로 연결된 게 내 컴퓨터 디스크처럼 보인다고?’ 싶어서 좀 신기했었죠.

    1.1. iSCSI의 장점

    • 고성능: 블록 레벨 액세스(Block-level Access)를 제공하기 때문에 파일 시스템 오버헤드가 적어, 마치 로컬 디스크를 쓰는 것처럼 빠른 성능이 나오거든요. 가상 머신(Virtual Machine)의 디스크나 데이터베이스(Database) 스토리지로 활용하기에 아주 적합합니다.
    • 유연성: 서버 입장에서는 물리적인 디스크와 동일하게 인식하므로, 운영체제(Operating System)에서 원하는 파일 시스템(File System)을 자유롭게 구성할 수 있어요. Windows 서버든 Linux 서버든 가리지 않고 쓸 수 있다는 게 큰 장점입니다.
    • 익숙함: 기존 파일 시스템 관리 방식과 크게 다르지 않아서, 엔지니어 입장에서는 익숙하게 다룰 수 있거든요.

    1.2. iSCSI의 단점

    • 관리 복잡성: LUN(Logical Unit Number) 관리, 인증(Authentication), 네트워크 설정 등 초기 설정이 좀 복잡할 수 있어요. 저도 처음엔 LUN 개념 잡는 데 좀 헤맸거든요.
    • 확장성 제한: 대규모의 분산 환경보다는 특정 서버에 고성능 스토리지를 제공하는 데 더 적합합니다. 용량을 늘리려면 LUN을 확장하거나 새로 할당해야 하는데, 이게 또 은근히 번거롭거든요.
    • 단일 연결: 기본적으로 단일 서버가 LUN을 독점적으로 사용하는 방식이라, 여러 서버에서 동시에 하나의 LUN에 접근하려면 클러스터 파일 시스템(Cluster File System) 같은 추가적인 솔루션이 필요합니다.
    # iSCSI 타겟 검색 예시 (Linux)
    sudo iscsiadm -m discovery -t st -p [iSCSI_TARGET_IP]
    
    # 검색된 타겟에 로그인
    sudo iscsiadm -m node -T [TARGET_IQN] -p [iSCSI_TARGET_IP] --login
    
    # 로그인 후 디스크 확인
    lsblk
    

    위에 보시는 것처럼 명령어를 통해 연결하고 나면, /dev/sdX와 같은 장치로 인식되어 바로 사용할 수 있어요. 처음 연결 성공했을 때의 그 쾌감이란! 🎉

    2. S3 호환 스토리지: 오브젝트 스토리지의 유연성과 확장성

    다음은 S3 호환 스토리지(S3 Compatible Storage)입니다. Amazon S3(Simple Storage Service)는 클라우드 스토리지의 대명사인데, 이를 따라 온프레미스(On-premise)나 홈랩에서 구축할 수 있는 솔루션들이 많이 나왔죠. 대표적으로 MinIO 같은 오픈소스 솔루션이 있습니다. S3 호환 스토리지는 오브젝트 스토리지(Object Storage) 방식을 사용하는데, 파일을 마치 객체처럼 다루고 HTTP API를 통해 접근하거든요. 처음엔 이런 방식이 낯설었는데, 써보니 정말 편리하더라고요.

    2.1. S3 호환 스토리지의 장점

    • 무한한 확장성: 오브젝트 스토리지의 가장 큰 장점이죠. 수십 테라바이트(TB)에서 페타바이트(PB)까지, 용량을 거의 무한하게 늘릴 수 있어요. 데이터를 추가할 때마다 버킷(Bucket)에 오브젝트를 넣으면 끝입니다!
    • API 기반 접근: RESTful API를 통해 접근하기 때문에 다양한 애플리케이션과 쉽게 연동할 수 있습니다. 백업(Backup), 아카이빙(Archiving), 웹 서비스의 정적 파일 호스팅 등 활용 범위가 정말 넓거든요.
    • 관리 용이성: 파일 시스템의 복잡한 관리가 필요 없습니다. 버킷 단위로 관리하고, 메타데이터(Metadata)를 통해 오브젝트를 찾으면 되니까요.
    • 비용 효율성 (대용량): 스토리지 노드(Node)를 추가하는 방식으로 확장하기 때문에, 대용량 데이터를 저렴하게 저장할 수 있어요.

    2.2. S3 호환 스토리지의 단점

    • 블록 스토리지 대비 성능: 블록 스토리지처럼 로컬 디스크에 직접 접근하는 방식이 아니기 때문에, 일반적으로 낮은 레이턴시(Latency)와 높은 IOPS(Input/Output Operations Per Second)가 필요한 워크로드에는 적합하지 않습니다.
    • 특정 애플리케이션 한계: 기존 파일 시스템 기반의 애플리케이션과는 직접 연동하기 어렵습니다. 예를 들어, 데이터베이스 파일을 S3 버킷에 직접 저장하는 건 불가능하죠. FUSE(Filesystem in Userspace) 기반의 툴을 사용하면 가능하긴 하지만, 성능 저하가 있을 수 있어요.
    MinIO S3 호환 스토리지 버킷 관리 콘솔 화면

    MinIO 콘솔 화면 또는 S3 버킷 생성/관리 인터페이스의 개념도: 사용자가 웹 인터페이스를 통해 버킷을 생성하고, 오브젝트를 업로드하며, 접근 권한을 설정하는 과정을 보여줍니다.

    3. 홈랩 환경에서의 실제 구현 및 선택 기준

    자, 그럼 홈랩에서는 어떤 스토리지를 선택해야 할까요? 이건 어떤 워크로드(Workload)를 돌릴지에 따라 완전히 달라집니다. 제가 경험한 바로는 이렇더라고요.

    3.1. iSCSI가 적합한 경우

    • 가상 머신(VM) 디스크: Proxmox, ESXi 같은 하이퍼바이저(Hypervisor)에서 가상 머신의 디스크 이미지(Disk Image)를 저장할 때 iSCSI가 아주 유용합니다. 빠른 응답 속도가 중요하거든요.
    • 데이터베이스(DB) 서버: 높은 IOPS와 낮은 레이턴시가 필요한 데이터베이스 서버에 iSCSI 스토리지를 연결하면 성능 병목 현상을 줄일 수 있어요.
    • 특정 애플리케이션의 고성능 스토리지: 동영상 편집용 워크스테이션이나 게임 서버처럼 빠른 디스크 I/O가 필수적인 경우에 고려해볼 만합니다.

    보통 NAS(Network Attached Storage) 장비들이 iSCSI 타겟 기능을 제공합니다. 제 홈랩에서도 Synology NAS를 이용해 iSCSI LUN을 구성해서 가상 머신 스토리지로 잘 쓰고 있거든요.

    3.2. S3 호환 스토리지가 적합한 경우

    • 백업 및 아카이빙: 중요한 데이터를 장기간 보관하거나, 주기적인 백업을 수행할 때 S3 호환 스토리지는 아주 효율적입니다. 버전 관리(Versioning) 기능도 제공해서 실수로 파일을 덮어쓰거나 삭제해도 복구가 가능하죠.
    • 미디어 파일 저장: 사진, 동영상 같은 대용량 미디어 파일을 저장하고 관리할 때 좋습니다. 웹 갤러리나 미디어 서버의 백엔드(Backend)로 활용하기에도 적합해요.
    • 개발 환경의 오브젝트 스토리지: 애플리케이션 개발 시 S3 API를 사용하는 경우가 많은데, 로컬에서 S3 호환 스토리지를 구축하면 개발 및 테스트 환경을 클라우드와 유사하게 가져갈 수 있거든요.

    저는 오래된 PC에 리눅스(Linux)를 설치하고 MinIO를 띄워서 개인용 S3 호환 스토리지를 운영 중입니다. Docker Compose로 쉽게 올릴 수 있어서 삽질 좀 했습니다만(ㅎㅎ), 한번 구축하고 나니 클라우드 비용 걱정 없이 대용량 데이터를 저장할 수 있어서 정말 편하더라고요.

    # MinIO Docker Compose 예시
    version: '3.8'
    
    services:
      minio:
        image: minio/minio
        container_name: minio
        ports:
          - "9000:9000"
          - "9001:9001"
        volumes:
          - /path/to/minio/data:/data
        environment:
          MINIO_ROOT_USER: admin
          MINIO_ROOT_PASSWORD: password
        command: server /data --console-address ":9001"
        restart: always
    

    이런 식으로 간단하게 MinIO를 구성해서 S3 호환 스토리지를 만들 수 있습니다. /path/to/minio/data 부분만 여러분의 저장 경로로 바꿔주면 돼요. 💡

    4. 비용 효율성 분석: 하드웨어, 전력, 네트워크

    이제 가장 중요한 비용 효율성 분석입니다. 홈랩에서 스토리지 비용은 크게 초기 투자 비용과 운영 비용으로 나눌 수 있어요.

    4.1. 초기 투자 비용

    • 하드웨어: iSCSI든 S3 호환 스토리지든, 결국 데이터를 저장할 물리적인 디스크(HDD/SSD)가 필요합니다. 고용량 HDD는 여전히 가격이 비싸죠. 여기에 스토리지를 호스팅할 서버(NAS, 미니 PC, 조립 PC 등)와 네트워크 카드(NIC), 케이블 등도 포함됩니다.
    • 소프트웨어: 오픈소스 솔루션(MinIO, TrueNAS 등)을 사용하면 소프트웨어 비용은 무료에 가깝지만, 상용 솔루션을 선택한다면 라이선스 비용도 고려해야 해요.

    4.2. 운영 비용

    • 전력 소모: 서버와 디스크는 24시간 돌아가야 하므로 전기 요금은 무시할 수 없습니다. 특히 디스크 개수가 많아질수록 전력 소모가 커지죠. 저도 처음엔 몰랐다가 전기 요금 고지서 보고 깜짝 놀랐던 경험이 있거든요. 😱
    • 유지보수: 디스크 고장 시 교체, 데이터 백업 전략 수립 및 실행, 소프트웨어 업데이트 등 시간과 노력이 들어갑니다.
    • 네트워크 비용 (클라우드 스토리지의 경우): 만약 클라우드 스토리지(Cloud Storage)를 이용한다면, 데이터 Ingress(인그레스, 외부 트래픽 진입점)는 대부분 무료지만, Egress(이그레스, 외부 트래픽 송출점) 비용은 발생할 수 있어요. 홈랩에서 클라우드 스토리지로 백업을 보낼 때 이그레스 비용을 간과하면 안 됩니다.

    비교 표: iSCSI vs S3 호환 스토리지 비용 효율성 (홈랩 기준)

    항목 iSCSI (온프레미스) S3 호환 (온프레미스) S3 (클라우드 서비스)
    초기 하드웨어 비용 높음 (NAS/서버, HDD/SSD) 높음 (서버, HDD/SSD) 없음
    운영 전력 비용 있음 (24/7 구동) 있음 (24/7 구동) 없음
    소프트웨어 비용 낮음 (오픈소스 NAS OS) 낮음 (MinIO 등) 서비스 비용에 포함
    확장성 비용 디스크/LUN 추가 비용 디스크/노드 추가 비용 용량 단위 과금
    네트워크 트래픽 비용 없음 (내부 네트워크) 없음 (내부 네트워크) Egress 비용 발생 가능
    관리 복잡성 중 (LUN 관리) 하 (버킷/오브젝트 관리) 하 (콘솔/API)
    최대 성능 매우 높음 중간 (API 오버헤드) 중간 (네트워크 지연)

    5. 삽질 경험담: 예상치 못한 함정들 ⚠️

    13년차 엔지니어도 삽질은 피할 수 없죠. 저도 홈랩에서 스토리지 구성하면서 여러 번 시행착오를 겪었어요.

    • iSCSI 성능 튜닝의 어려움: 처음엔 단순히 기가비트 이더넷(Gigabit Ethernet)으로 연결하면 다 되는 줄 알았습니다. 그런데 가상 머신 여러 개를 돌리니 IOPS가 제대로 안 나오더라고요. 멀티패스(Multipath) 구성이나 점보 프레임(Jumbo Frame) 설정, 10기가비트 이더넷(10 Gigabit Ethernet)으로 업그레이드하면서 성능을 끌어올렸습니다. 네트워크 장비 비용이 꽤 들더군요.
    • S3 호환 솔루션의 호환성 문제: MinIO 같은 솔루션이 S3 API를 구현하지만, 100% 모든 기능을 지원하는 건 아닙니다. 특정 클라우드 서비스에서만 제공하는 기능은 동작하지 않을 수 있어서, 사용하는 애플리케이션이 요구하는 S3 API 버전과 호환성을 미리 확인해야 했거든요.
    • 전력 소모와 소음: 여러 대의 서버와 디스크를 24시간 돌리니 전력 소모가 생각보다 컸습니다. 특히 오래된 디스크는 소음도 무시할 수 없었죠. 조용한 환경을 원한다면 저전력 부품이나 팬리스(Fanless) 솔루션에 투자하는 것도 고려해야 해요.

    이런 삽질 덕분에 많은 것을 배웠습니다. 홈랩은 결국 현실 세계의 축소판이라는 걸 깨달았죠. 😂

    6. 결론: 그래서 어떤 스토리지를 선택해야 할까?

    어떤 스토리지를 선택할지는 결국 여러분의 워크로드, 예산, 그리고 관리 역량에 달려 있어요.

    • 고성능 블록 스토리지가 필요하다면 iSCSI: 가상 머신, 데이터베이스, 고성능 애플리케이션용 스토리지가 필요하다면 iSCSI가 좋은 선택입니다. 초기 설정이 좀 복잡해도, 한번 구성해두면 안정적으로 고성능을 제공하거든요.
    • 대용량 백업, 아카이빙, 웹 서비스에 S3 호환 스토리지: 수많은 파일들을 저장하고, 백업하며, 웹 서비스에서 활용할 계획이라면 S3 호환 스토리지가 훨씬 유연하고 확장성이 뛰어납니다. MinIO 같은 오픈소스를 활용하면 클라우드 비용 없이 대용량 스토리지를 구축할 수 있어요.

    가장 이상적인 방법은 두 가지 방식을 하이브리드(Hybrid)로 사용하는 것입니다. 즉, 고성능이 필요한 워크로드에는 iSCSI를 사용하고, 대용량 백업이나 오브젝트 저장에는 S3 호환 스토리지를 활용하는 거죠. 제 홈랩도 현재 이런 방식으로 운영되고 있습니다. ✅

    홈랩 스토리지는 한번 구축하면 끝이 아니라, 계속해서 진화하고 확장시켜 나가는 과정이라고 생각합니다. 여러분도 자신만의 최적의 스토리지 솔루션을 찾아가는 재미를 느껴보시길 바랍니다! 다음번에는 홈랩 전력 효율성 분석에 대해 더 자세히 다뤄볼게요. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요!

    iSCSI와 S3 호환 스토리지의 핵심 장단점을 요약하고, 홈랩 사용자가 어떤 선택을 해야 할지 워크로드와 예산에 따라 가이드하는 인포그래픽: 빠른 속도 vs 대용량, 복잡한 설정 vs 쉬운 확장성 등의 비교점을 시각적으로 보여줍니다.

  • [k8s] Kubernetes Longhorn 스토리지: 설치부터 운영까지 완벽 가이드

    [k8s] Kubernetes Longhorn 스토리지: 설치부터 운영까지 완벽 가이드

    안녕하세요, 13년차 서버실 지킴이입니다. 🤓

    오늘은 제가 홈랩에서 Kubernetes(쿠버네티스) 클러스터를 운영하면서 겪었던 스토리지 고민과 그 해결책, 바로 Longhorn(롱혼)에 대해 이야기해보려고 합니다. 쿠버네티스에서 컨테이너 애플리케이션을 운영하다 보면, 데이터 영속성(Persistence) 확보가 정말 중요한데요. 특히 분산 스토리지(Distributed Storage)는 고가용성(High Availability)과 데이터 안정성을 위해 필수적이죠. 처음엔 로컬 스토리지를 PersistentVolume(PV)으로 직접 연결해보기도 하고, NFS(Network File System)를 써보기도 했는데, 이게 또 생각보다 관리하기가 만만치 않더라고요.

    그러다 우연히 Longhorn을 알게 되었고, 직접 설치하고 운영해보니 “아, 이거다!” 싶었습니다. 설치도 비교적 간단하고, 웹 UI로 볼륨 관리도 직관적이라 삽질 좀 덜 수 있었거든요. 오늘은 저의 경험을 바탕으로 Longhorn을 처음 접하시는 분들도 쉽게 따라할 수 있도록 설치부터 운영까지 완벽 가이드를 준비해봤습니다. 함께 시작해볼까요?

    쿠버네티스 클러스터 내 롱혼 분산 스토리지 아키텍처 개요

    이미지 캡션: 쿠버네티스 클러스터 내 롱혼 분산 스토리지 아키텍처 개요. 여러 노드에 걸쳐 데이터가 복제되고 관리되는 모습을 보여줍니다.

    💡 Longhorn, 넌 누구냐? (핵심 개념 설명)

    자, 그럼 먼저 Longhorn이 뭔지부터 알아봐야겠죠? Longhorn은 CNCF(Cloud Native Computing Foundation) 프로젝트 중 하나로, 쿠버네티스를 위한 분산 블록 스토리지 시스템입니다. 쉽게 말해, 쿠버네티스 클러스터 내의 여러 노드에 있는 디스크들을 모아서 하나의 거대한 가상 스토리지 풀을 만들고, 이 풀에서 PersistentVolume(영구 볼륨)을 생성하여 파드(Pod)에 제공해주는 역할을 해요.

    • 분산 스토리지 (Distributed Storage): 여러 노드의 저장 공간을 하나로 묶어 사용하며, 데이터가 여러 노드에 복제되어 저장되기 때문에 특정 노드에 문제가 생겨도 데이터 유실 걱정을 덜 수 있습니다.
    • CSI (Container Storage Interface, 컨테이너 스토리지 인터페이스) 호환: 쿠버네티스의 표준 스토리지 인터페이스인 CSI를 완벽하게 지원하기 때문에, 쿠버네티스에서 제공하는 StorageClass(스토리지 클래스), PersistentVolumeClaim(PVC, 영구 볼륨 클레임) 등의 기능을 문제없이 쓸 수 있습니다.
    • 스냅샷 및 백업/복구: 볼륨의 스냅샷을 찍고, S3와 같은 오브젝트 스토리지(Object Storage)나 NFS로 백업 및 복구를 쉽게 할 수 있어요. 제가 써보니 이 기능이 정말 편하더라고요!

    사실 처음엔 이런 분산 스토리지가 복잡하고 어렵게 느껴졌는데, Longhorn은 웹 UI가 워낙 직관적이라 금방 익숙해질 수 있었습니다. 덕분에 홈랩에서 여러 스테이트풀(Stateful) 애플리케이션들을 안정적으로 운영할 수 있게 되었죠. 예를 들어, 제 홈랩의 Prometheus(프로메테우스)나 Grafana(그라파나) 같은 모니터링 툴의 데이터도 Longhorn 볼륨에 저장해서 쓰고 있거든요.

    🛠️ 실전 구현: Longhorn 설치부터 PersistentVolume 사용까지

    이제 본격적으로 Longhorn을 설치하고 사용하는 방법을 알아볼 차례입니다. 저는 Helm(헬름)을 이용해서 설치하는 방법을 선호합니다. 배포가 간편하고 버전 관리가 용이하거든요. 시작하기 전에 몇 가지 준비물이 필요합니다.

    ✅ 준비물 확인

    1. Kubernetes 클러스터: 최소 3개 이상의 노드(Node)를 권장합니다. 각 노드에 충분한 여유 디스크 공간이 필요합니다.
    2. iSCSI initiator 설치: Longhorn은 iSCSI 프로토콜을 사용합니다. 각 노드에 <code>iscsi-initiator-utils (CentOS/RHEL) 또는 open-iscsi (Ubuntu/Debian) 패키지가 설치되어 있어야 합니다. 제가 처음 이걸 몰라서 삽질 좀 했습니다. 꼭 확인하세요!
      
      # CentOS/RHEL 계열
      sudo yum install -y iscsi-initiator-utils
      sudo systemctl enable --now iscsid
      
      # Ubuntu/Debian 계열
      sudo apt update
      sudo apt install -y open-iscsi
      sudo systemctl enable --now iscsid
      
    3. Helm 설치: 클러스터에 Helm이 설치되어 있어야 합니다.

    🚀 Longhorn 설치하기

    Helm을 이용하면 Longhorn 설치는 정말 간단합니다. 다음 명령어를 순서대로 실행해주세요.

    
    # 1. Longhorn Helm 레포지토리 추가
    helm repo add longhorn https://charts.longhorn.io
    helm repo update
    
    # 2. Longhorn 네임스페이스 생성 (선택 사항이지만 권장)
    kubectl create namespace longhorn-system
    
    # 3. Longhorn 설치 (기본 설정으로 충분합니다)
    helm install longhorn longhorn/longhorn --namespace longhorn-system --version 1.5.3 # 버전은 최신 안정 버전을 확인하세요!
    

    설치가 완료되면, 잠시 기다리면 모든 Longhorn 컴포넌트 파드들이 longhorn-system 네임스페이스에 배포되고 실행될 겁니다. kubectl get pods -n longhorn-system 명령으로 확인해보세요. 모든 파드가 Running 상태인지 확인하는 것이 중요합니다.

    🌐 Longhorn UI 접속하기

    Longhorn은 웹 UI를 제공해서 볼륨 상태, 노드 상태 등을 직관적으로 확인할 수 있습니다. UI에 접속하려면 보통 Ingress(인그레스, 외부 트래픽 진입점)를 설정하거나 NodePort(노드포트) 서비스를 생성하는 방법이 있습니다. 저는 간단하게 포트 포워딩(Port Forwarding)으로 접속해보겠습니다.

    
    # Longhorn UI 서비스 찾기
    kubectl get svc -n longhorn-system
    
    # UI 서비스 포트 포워딩 (예: longhorn-frontend 서비스)
    kubectl -n longhorn-system port-forward svc/longhorn-frontend 8080:80
    

    이제 웹 브라우저에서 http://localhost:8080으로 접속하면 Longhorn 대시보드를 볼 수 있습니다. 🎉 드디어 Longhorn의 세상으로 들어온 것을 환영합니다!

    롱혼 웹 UI 대시보드 화면. 클러스터 노드 스토리지 상태 및 볼륨 목록 확인

    이미지 캡션: Longhorn 웹 UI 대시보드 화면. 클러스터 내 노드들의 스토리지 상태와 생성된 볼륨 목록을 한눈에 확인할 수 있습니다.

    ⚙️ StorageClass 생성 및 PersistentVolumeClaim 사용

    Longhorn이 설치되었으니, 이제 쿠버네티스에서 스토리지를 사용할 차례입니다. Longhorn은 기본 StorageClass(스토리지 클래스)를 자동으로 생성하지만, 필요에 따라 커스터마이징할 수 있습니다. 저는 기본 StorageClass를 사용하되, 예시로 PVC를 만들어보겠습니다.

    
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: my-longhorn-pvc
    spec:
      accessModes:
        - ReadWriteOnce # 하나의 파드에서만 읽기/쓰기 가능
      storageClassName: longhorn # Longhorn이 생성한 기본 StorageClass 이름
      resources:
        requests:
          storage: 5Gi # 5GB 볼륨 요청
    

    위 YAML 파일을 pvc.yaml로 저장하고 적용합니다.

    
    kubectl apply -f pvc.yaml
    kubectl get pvc my-longhorn-pvc
    

    PVC가 Pending에서 Bound 상태로 바뀌면 성공입니다. 이제 이 PVC를 사용하는 파드를 배포해봅시다. 간단한 Nginx(엔진엑스) 파드를 예시로 들어보겠습니다.

    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-with-longhorn
    spec:
      selector:
        matchLabels:
          app: nginx
      replicas: 1
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - name: nginx
              image: nginx:latest
              ports:
                - containerPort: 80
              volumeMounts:
                - name: longhorn-volume
                  mountPath: /usr/share/nginx/html # Nginx 웹 페이지 경로
          volumes:
            - name: longhorn-volume
              persistentVolumeClaim:
                claimName: my-longhorn-pvc # 위에서 생성한 PVC 이름
    

    위 YAML 파일을 nginx-deployment.yaml로 저장하고 적용하면, Nginx 파드가 Longhorn 볼륨을 마운트하여 시작됩니다. 이제 /usr/share/nginx/html 경로에 데이터를 써보면, 파드가 재시작되거나 다른 노드로 옮겨가도 데이터가 그대로 유지되는 것을 확인할 수 있습니다. 💡

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

    제가 Longhorn을 운영하면서 겪었던 몇 가지 삽질 경험과 주의사항을 공유해드릴게요. 독자분들은 저처럼 고생하지 마시라고요! ㅎㅎ

    • iSCSI initiator 문제: 가장 흔한 문제 중 하나입니다. 노드에 iscsi-initiator-utils나 open-iscsi가 설치되어 있지 않거나, iscsid 서비스가 실행 중이 아니라서 볼륨 마운트가 실패하는 경우가 많습니다. 꼭 설치 여부와 서비스 상태를 확인해주세요!
    • 네트워크 대역폭: Longhorn은 데이터를 여러 노드에 복제하기 때문에, 노드 간 네트워크 대역폭이 충분해야 합니다. 네트워크가 느리면 볼륨 성능 저하로 이어질 수 있습니다. 특히 홈랩 환경에서는 유선 네트워크를 사용하는 것이 좋습니다.
    • 디스크 공간 관리: Longhorn은 노드의 가용 디스크 공간을 사용합니다. 볼륨을 너무 많이 생성하거나 스냅샷을 자주 찍으면 노드의 디스크 공간이 부족해질 수 있습니다. Longhorn UI에서 각 노드의 디스크 사용량을 주기적으로 확인하고, 불필요한 스냅샷이나 백업은 정리하는 습관을 들이는 것이 좋습니다.
    • 노드 드레인(Drain) 시 주의: 쿠버네티스 노드를 유지보수할 때 kubectl drain 명령을 사용하죠. Longhorn 볼륨이 마운트된 파드가 있는 노드를 드레인할 때는 Longhorn이 해당 볼륨을 다른 노드로 안전하게 옮길 수 있도록 충분한 시간을 주어야 합니다. 급하게 드레인하면 볼륨이 Faulted 상태가 될 수도 있더라고요.

    ✅ 검증 및 결과: Longhorn 볼륨 확인하기

    모든 설치와 설정이 끝났으니, 이제 제대로 작동하는지 확인해볼 차례입니다. 저는 Nginx 파드에 접속해서 간단한 HTML 파일을 만들어보고, 파드를 삭제 후 다시 생성하여 데이터 영속성을 확인하는 방법을 즐겨 씁니다.

    
    # Nginx 파드 이름 확인
    kubectl get pods -l app=nginx
    
    # Nginx 파드 내부로 접속하여 파일 생성
    kubectl exec -it <nginx-pod-name> -- bash
    echo "Hello from Longhorn!" > /usr/share/nginx/html/index.html
    exit
    
    # Nginx 서비스 포트 포워딩 (테스트용)
    kubectl port-forward svc/<nginx-service-name> 8080:80 # Nginx 서비스가 없다면 배포해야 합니다.
    
    # 웹 브라우저에서 http://localhost:8080 접속하여 내용 확인
    

    이제 Nginx 파드를 삭제했다가 다시 생성해보세요. 그리고 다시 접속해보면, 이전에 작성했던 “Hello from Longhorn!” 메시지가 그대로 남아있는 것을 확인할 수 있을 겁니다. 🎉 드디어 영구적인 스토리지를 성공적으로 구축한 거죠!

    Nginx 파드에 마운트된 Longhorn 볼륨과 데이터 영속성 확인 화면

    이미지 캡션: Nginx 파드에 성공적으로 마운트된 Longhorn 볼륨과 데이터 영속성을 확인하는 모습. 웹 브라우저를 통해 저장된 내용을 확인하고 있습니다.

    마무리: 13년차 서버실 지킴이의 한마디

    오늘은 Kubernetes Longhorn(쿠버네티스 롱혼) 스토리지의 설치부터 운영까지 제가 직접 경험한 내용을 바탕으로 자세히 설명해드렸습니다. Longhorn은 쿠버네티스 환경에서 영구 볼륨(Persistent Volume)을 안정적이고 유연하게 제공하는 훌륭한 분산 스토리지 솔루션이라고 생각합니다. 특히 홈랩이나 소규모 클러스터 환경에서는 초기 구축 비용이나 복잡성 측면에서 다른 엔터프라이즈 솔루션보다 훨씬 매력적이죠. 저는 Longhorn 덕분에 홈랩에서 다양한 스테이트풀 애플리케이션들을 걱정 없이 운영하고 있습니다. 백업과 스냅샷 기능도 정말 유용하구요!

    물론 Longhorn도 만능은 아닙니다. 대규모 엔터프라이즈 환경에서는 Ceph(세프)나 NetApp(넷앱) 같은 더욱 강력하고 복잡한 솔루션들이 필요할 수도 있습니다. 하지만 “간단하게 시작해서 점진적으로 확장하고 싶다”는 분들에게는 Longhorn이 정말 좋은 선택지가 될 거라고 확신합니다. 제 경험상, 중요한 건 어떤 툴을 쓰느냐보다, 그 툴을 얼마나 잘 이해하고 자신의 환경에 맞게 활용하느냐인 것 같아요. 저도 아직 배워야 할 게 많지만, 계속해서 새로운 기술들을 실험하고 삽질하면서 여러분께 유용한 정보를 공유해드리겠습니다.

    다음 글에서는 Longhorn의 백업 및 복구 기능에 대해 더 자세히 다뤄보거나, Longhorn 볼륨의 성능 튜닝 방법에 대해 이야기해볼까 합니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요! 다음에 또 유익한 정보로 찾아뵙겠습니다. 감사합니다! 😊

    Longhorn 주요 특징, 장단점 및 다른 쿠버네티스 스토리지 솔루션 비교 인포그래픽

    이미지 캡션: Longhorn의 주요 특징과 장단점을 요약한 인포그래픽. 쿠버네티스 스토리지 선택에 있어 Longhorn의 위치를 보여줍니다.