개요
헤놀로지(xpenology)는 가정용 NAS를 구축하려는 분들에게 가장 먼저 고려되는 OS중 하나입니다. 잘 만들어진 시놀로지 생태계를 사용할 수 있고, 사용자 친화적인 UI로 학습 곡선도 다른 NAS OS에 비해 낮은 편입니다.
그러나, 정확한 이유를 알 순 없으나, 어쩌다 파티션이 깨지고, 어쩌다 볼륨 충돌이 일어나고 하면서 제 개인적인 경험으로도 약 3~4번의 데이터 유실을 경험했습니다. SHR이라는 소프트웨어 레이드를 사용하다 보니 여기서 파일을 다시 복구해서 끄집어내는 과정도 만만치 않았습니다.
그래서 사용하지 않다가, 최근 ZFS over iSCSI를 이용해 구축해보고, 데이터 유실의 위험성을 상당히 보완할 수 있다고 느껴 포스팅하게 되었습니다.
Proxmox에서 TrueNAS에 ZFS over iSCSI를 이용한 스토리지를 구축하고 여기에 디스크 이미지를 생성해 헤놀로지에서 사용하는 방법입니다.
ZFS over iSCSI 스토리지 구축
우선 제일 먼저 Proxmox와 TrueNAS간 연동된 ZFS over iSCSI풀이 있어야 합니다. 해당 풀 구축 방법은 이미 작성한 포스트 링크로 대체하겠습니다.
이 글에서는 실제로 제가 사용하고 있는 스토리지 풀을 이용합니다.
헤놀로지(Xpenology) 설치
Proxmox에 헤놀로지를 설치하는 일반적인 과정은 검색을 통해 쉽게 접할 수 있으므로 생략하겠습니다. 설치에 쓰인 부트로더는 화정큐삼님의 xTCRP입니다.
일반적으로 Proxmox에 헤놀로지 설치 시 디스크 S.M.A.R.T. 정보를 얻기 위해 컨트롤러를 통으로 PCI Passthrough하여 설치하지만, 이번에는 만들어진 ZFS over iSCSI풀에 디스크 이미지를 생성합니다. 예시 글에서는 1TB의 이미지를 생성하지만, 필요에 따라서 더 크거나 작게 만드셔도 됩니다.
후술하겠지만, 용량 확장은 어렵지 않습니다.
구성된 VM은 아래와 같습니다.
sata0에 할당된 디스크가 ZFS over iSCSI풀에 생성된 디스크 이미지이고, ide0에 할당된 디스크는 qm importdisk 명령어로 가져온 부트로더입니다.
부팅하여 로더빌드 후 DSM부팅까지 진행해 줍니다.
부팅 이후 스토리지 풀과 볼륨까지 생성해 봅니다.
이 때, 헤놀로지 내부 스토리지 풀은 Basic으로 설정해 줍니다. 이렇게 해도 얼마든지 용량을 확대할 수 있고, 디스크 이미지들을 여러 개 추가해 소프트웨어 레이드로 묶을 필요가 전혀 없기 때문입니다.
TrueNAS에서 해당 디스크(zvol)를 확인할 수 있습니다.
설치는 끝났습니다. 이미 실사용할 수 있는 단계인거죠.
단, 구태여 이렇게 복잡하게 설치했으니, 무엇을 할 수 있는지 하단에서 더 설명해보겠습니다.
디스크 이미지 관리
파티션 확장
해당 작업을 실행하기 전 TrueNAS에서 Snapshot을 꼭 생성해 주세요.
이 방법을 통해, 헤놀로지 내에서 단일 디스크, 단일 파티션인 스토리지 풀의 용량을 자유롭게 확장할 수 있게 됩니다.
먼저 헤놀로지를 종료한 후, Proxmox UI상에서 디스크 이미지의 용량을 확장합니다. 예시에서는 1TB에서 2TB로 총 1TB만큼의 용량을 증가시키겠습니다.
작업이 완료되었으면 해당 디스크 이미지의 파티셔닝을 위해 TrueNAS에 SSH로 접속해 줍니다.
TrueNAS상에서 zvol의 절대경로는 /dev/zvol/{pool}/{dataset} 하위에 있습니다.
현재 예시글에서는 /dev/zvol/pds/proxmox가 됩니다.
따라서, 아래와 같이 입력합니다.
sudo parted /dev/zvol/pds/proxmox/vm-997-disk-0
그러면, 아래와 같은 프롬포트가 나타납니다.
p를 입력하면 zvol 내부의 파티션을 볼 수 있습니다.
Disk용량은 2199GB라고 나오는데, 데이터 영역인 3번 파티션이 1089GB만 사용하고 있으므로 이를 늘려주어야겠죠?
resizepart 3 100%를 입력하고 다시 p를 입력해 파티션 정보를 봅니다.
정상적으로 늘어났네요. q를 입력해 parted를 빠져 나옵니다. 그리고 마지막 작업을 하기 위해 헤놀로지를 부팅시킵니다. 무슨 일이 일어나고 있는지 궁금하면, Serial Console을 확인해보는 것도 좋습니다.
ZFS over iSCSI를 이용해 헤놀로지를 구성한 경우, 평범하게 헤놀로지를 구성했을 때보다 DSM 접속에 필요한 시간이 좀 더 필요합니다. 그러다가 아래처럼 디스크 마운트가 되면, DSM에 접근 가능해 집니다.
저장소 관리자에서 바로 인식 된 경우
부팅 후 저장소 관리자를 실행해 스토리지 풀을 살펴 보면, 아래와 같은 메세지를 발견할 수 있습니다.
이 경우, ‘지금 확장’을 누르면 바로 과정이 종료됩니다.
저장소 관리자에서 바로 인식되지 않은 경우
쪼오금 귀찮은 작업이 필요해집니다.
SSH로 헤놀로지에 접속한 뒤 root로 전환합니다.
cat /proc/mdstat을 입력해보면, 시리얼 콘솔에서 확인한 md2를 확인할 수 있습니다.
df -h를 입력해보면 스토리지 풀의 용량 자체는 확장 전임을 알 수 있구요.
해당 스토리지 풀의 용량을 확장해주기 위해 아래와 같이 입력합니다.
mdadm --grow /dev/md2 --size=max
재부팅 이후, 저장소 관리자를 실행한 뒤, ‘지금 확장’을 클릭하면 작업이 완료됩니다.
스냅샷을 통한 데이터 복원
테스트를 위해 ’test’라는 공유 폴더를 만들고 PDF 파일을 하나 업로드했습니다.
그리고 TrueNAS에서 현재 상태의 스냅샷을 기록합니다.
헤놀로지에서 PDF파일을 삭제하고 DSM을 종료한 후 해당 스냅샷으로 Rollback을 해보겠습니다.
롤백을 진행한 이후 다시 헤놀로지를 부팅시켜보면, 삭제했던 PDF파일이 복원되어 있는 것을 확인할 수 있습니다.
TrueNAS에서 주기적으로 스냅샷을 찍는 것을 통해, 원인 모를 헤놀로지의 오작동으로 인한 데이터 유실시에도, 손쉽게 복구할 수 있게 된 겁니다.
Clone to Dataset을 이용한 헤놀 복제
ZFS나 Btrfs는 스냅샷을 마운트한 뒤, 추가적인 용량 소비 없이 별도의 파일시스템처럼 다룰 수 있습니다. 이를 이용해 특정 시점의 데이터를 이용해 손쉽게 복제 헤놀을 생성할 수 있습니다.
예제로 위에서 찍었던 스냅샷을 먼저 Clone해보겠습니다. 파일명은 Proxmox에서 사용할 디스크 형식에 맞춰주겠습니다(안 맞춰도 됨).
zvol:vm-996-disk-0이 용량을 11kb밖에 차지하지 않는 모습
iSCSI Shares로 이동해 Extents를 수동으로 구성합니다.
Associated Targets도 구성해 줍니다. LUN ID는 목록을 보고 숫자+1을 해주면 됩니다.
그리고 Proxmox에서 996번 VM을 생성하고, 부트로더 디스크를 import하는 것까지만 진행합니다.
그리고 Proxmox에 SSH나 쉘로 접근한 뒤, /etc/pve/qemu-server경로로 이동합니다. 여기에는 아래처럼 각 VM들의 구성정보가 담겨있습니다.
맨 먼저 생성했던 헤놀로지인 997.conf파일을 살펴 보면, ZFS over iSCSI풀에 연결된 디스크를 확인할 수 있습니다.
cat /etc/pve/qemu-server/997.conf
해당 부분을 그대로 긁어서 996.conf에다가 붙여 넣어 준 뒤, vm-997-disk-0 부분만 TrueNAS에서 생성한 이름으로 수정하고 저장합니다.
nano /etc/pve/qemu-server/996.conf
Proxmox UI를 확인해보면 sata0에 디스크가 추가된 것을 확인할 수 있습니다.
VM을 부팅한 뒤, 동일 모델로 로더 빌드 과정을 거치고 나면, 똑같은 DSM으로 부팅하는 것을 보실 수 있습니다. MAC주소와 SN만 기존과 다르도록 신경쓰면 됩니다.
이 기능은 일부 파일, 일부 설정을 복원해내거나 테스트가 필요할 때 매우 용이하게 사용할 수 있습니다.
장점 및 단점
장점
- 안정적인 소프트웨어 레이드
헤놀로지를 사용하다 보면 모종의 이유로 ‘볼륨 충돌’이 발생하거나, 문제가 생긴 하드디스크를 제거하면 다른 하드디스크가 함께 인식불가가 되는 등 흔하지 않지만 발생하면 재수없는 경우가 은근히 있습니다.
그러나 RaidZ는 그런 일이 거의 없죠. 심지어 문제가 생긴 하드디스크를 교체할 때도, SHR과는 차원이 다른 속도의 리실버링을 보여줍니다.
- 손쉬운 백업 및 복원
헤놀로지에서 소프트웨어 레이드를 사용할 때 가장 불안한 것은, 업데이트 혹은 재부팅 등의 이벤트 시 부팅 불가, 무한 재설치 상황등에 빠지고, 파티션 정보에 문제가 생기는 것입니다.
그러나, 소프트웨어 레이드는 TrueNAS가 RaidZ로 수행해주고 있으니, 헤놀로지는 단순한 Basic풀만 사용하면 되죠.
거기다 스냅샷을 이용해 특정시점마다 상태를 기록하고 롤백을 통한 복원이 매우 쉽다는 장점이 있습니다. 이렇게 복원해도 헤놀로지는 무슨 일이 있었는지조차 알지 못합니다. 어느날 업데이트하다가 파티션이 박살났다? 그냥 마우스 몇 번 딸깍 거려서 스냅샷 롤백시켜 주면 끝납니다.
- 부담 없는 용량 확장, 실사용량보다 적은 용량 소모
TrueNAS의 용량이 허용하는 한, Basic으로 구성된 헤놀로지의 스토리지 풀은 위에 기술한 방법대로 무한대로 확장할 수 있습니다. 추가적인 디스크와 레이드 강제 없이요. TrueNAS에서 좀 더 용량이 큰 스토리지로 옮기려고 할 때도 큰 어려움 없이 옮길 수 있습니다.
거기다 Dataset의 압축률에 따라 다르겠지만, 실 사용량보다 zvol이 차지하는 용량이 더 적습니다. 아래 사진을 보면 헤놀로지 내부에선 약 100기가를 사용하는 것으로 표시되고, zvol은 150~160기가를 사용하는 것으로 보이지만, 실제로 zvol내에 설치된 DSM 운영체제, 패키지의 용량과 스냅샷에 소요되고 있는 용량을 모두 합친겁니다. 경제적이죠.
단점
- HDD를 직접 사용하는 것보다 느림
어쩔 수 없는 부분입니다. 네트워크를 통해 사용하는 저장소이기 때문에, HDD를 직접 이용하는 것보다는 느릴 수 밖에 없습니다. 그렇지만, 백업&복원의 편리함과 데이터 안정성을 기하급수적으로 상승시킬 수 있는 만큼, 감수할만한 단점이라고 생각합니다.
문제 해결(Trouble-Shooting)
클론 헤놀로지 Could not find lu_name 에러
해당 에러는 TrueNAS쪽에서 Extents와 Associated Targets를 구성하지 않아 발생하는 문제입니다.
보통의 경우 디스크 이미지를 생성할 때 동적으로 함께 구성되지만, clone의 경우 Proxmox에서 생성한 이미지가 아니기 때문에, 수동으로 함께 구성해 주어야 합니다.
