초보자를 위한 ZFS

 (ikrima.dev)
2P by GN⁺ | ★ favorite | 댓글 1개
  • FreeNAS의 ZFS 장애를 계기로 문제 해결, 새 볼륨 구성, 백업 전략까지 정리한 입문 가이드로, ZFS를 처음 운영할 때 필요한 구조와 명령을 한 흐름으로 다룸
  • ZFS는 파일시스템과 논리 볼륨 관리자를 함께 제공하며, Sun Microsystems에서 시작된 뒤 Linux와 FreeBSD 등에서는 주로 OpenZFS 코드가 사용됨
  • 기본 구조는 물리 디스크를 묶는 vdev, 이를 모은 pool, 파일시스템 역할의 dataset, 블록 디바이스 형태의 volume으로 나뉘며 RAIDZ-1/2/3는 각각 1개, 2개, 3개 디스크 장애를 견딤
  • 실무 명령은 zpool create/status/list/import/export/destroy/scrub와 zfs create/mount/list/get/set/snapshot/diff/rollback/send/recv/destroy가 중심이고, 장치명 변경 문제를 피하려면 device UUID 사용이 선호됨
  • snapshot은 특정 시점 상태를 가볍게 보호하고 zfs send/recv로 다른 pool이나 시스템에 복제할 수 있지만, snapshot만으로는 백업이나 DR을 대체하기 어려움

ZFS의 기본 개념

  • ZFS는 ext4, NTFS, exFAT 같은 로컬 파일시스템이면서 Linux의 LVM 같은 논리 볼륨 관리자 역할도 함께 수행함
  • Sun Microsystems가 만들었고, ZFS 소스 코드는 Oracle이 Sun을 인수하기 전까지 오픈소스 라이선스로 공개되어 있었음
  • 이미 공개된 코드가 여러 OS로 포팅되어 있었기 때문에 이후 OpenZFS 프로젝트가 만들어졌고, Linux와 FreeBSD 등 대부분의 Unix 계열 시스템에서 이 코드가 사용됨
  • ZFS를 처음 접하는 사람이 구조와 운영 명령을 이해할 수 있도록 초보자 관점으로 정리되어 있음

ZFS 구성 요소

  • vdev는 하나 이상의 물리 드라이브로 구성되며, 하드드라이브 외에 파일도 포함할 수 있음
    • mirror나 RAIDZ 형태로 조합 가능함
    • hot spare, L2ARC, ZIL 같은 중요한 vdev 유형을 포함해 7가지 vdev 유형이 있음
  • pool은 하나 이상의 vdev로 구성되며, 보통 pool 안에 volume이나 dataset을 생성함
    • zpool 명령으로 pool을 만들 때 vdev를 함께 정의함
    • 여러 vdev 유형을 섞어 RAIDZ 수준을 구성할 수 있음
  • dataset은 ZFS에서 파일시스템에 해당하는 구성 요소임
    • 사용자 접근, quota, 압축, snapshot 등을 설정할 수 있음
  • volume은 dataset과 비슷하지만 블록 디바이스 표현을 제공함
    • dataset 기능 중 일부만 제공함
    • ZFS 위에서 다른 파일시스템을 실행하거나 iSCSI extent를 내보낼 때 유용함

RAIDZ 유형

  • Dynamic/Simple Stripe, 즉 RAID0은 parity 없이 데이터를 분산하며, 장치 하나를 잃으면 전체 데이터를 잃음
  • MIRROR, 즉 RAID1은 디스크를 미러링하며 2~4개 또는 그 이상의 디스크와 함께 사용됨
  • RAIDZ-1, 즉 RAID5는 데이터와 함께 parity를 분산하고, RAID 장애 전까지 물리 드라이브 1개 손실을 견딜 수 있음
    • RAIDZ에는 최소 3개 디스크가 필요함
  • RAIDZ-2, 즉 RAID6는 물리 드라이브 최대 2개 손실을 견딜 수 있음
    • RAIDZ-2에는 최소 4개 디스크가 필요함
  • RAIDZ-3는 물리 드라이브 최대 3개 손실을 견딤
    • 최소 4개 디스크가 필요하지만, 5개 미만으로는 사용하지 않는 편이 좋음

pool 생성과 상태 확인

  • ZFS pool은 zpool create [pool] [devices] 형식으로 생성함
    • 단일 디스크 pool 예시: zpool create tank /dev/sdb
    • 3개 디스크 stripe 예시: zpool create tank /dev/sdb /dev/sdc /dev/sdd
    • 2개 디스크 mirror 예시: zpool create tank mirror sdb sdc
    • RAIDZ pool 예시: zpool create tank raidz sdb sdc sdd
    • RAIDZ2/3는 zpool create [pool name] raidz[1,2,3] [devices] 형식으로 만들 수 있음
  • pool 생성 시 -m 플래그로 기본 mount point를 지정할 수 있음
    • 예시: zpool create tank -m /mnt/tank mirror sdb sdc
  • 예시에서는 /dev/sdx 형태의 장치 이름을 쓰지만, 장치 이름 변경으로 인한 부팅 문제를 피하려면 device UUID 사용이 선호됨
  • zpool status는 pool 상태를 확인하는 기본 명령임
    • state는 pool이 온라인인지 나타냄
    • status는 pool에 대한 추가 정보를 표시함
    • action은 필요한 후속 작업을 보여줌
    • scan은 scrub 진행 상황이나 마지막 scrub 상태를 표시함
    • errors는 pool 문제 여부를 나타냄
  • zpool list는 pool의 크기, 할당량, 여유 공간, fragmentation, capacity, dedup, health 같은 세부 정보를 보여줌
  • zpool history는 pool 생성 이후 구성 변경에 사용된 명령 이력을 표시함

pool 가져오기, 내보내기, 삭제, scrub

  • pool은 생성 후 보통 자동으로 import되고 mount되지만, 문제 해결이나 시스템 재이미징 이후에는 수동 import가 필요할 수 있음
  • zpool import를 pool 이름 없이 실행하면 import 가능한 pool 목록을 보여줌
    • import 가능한 pool이 없으면 no pools available to import가 표시됨
    • pool 이름을 지정하면 해당 pool을 import하며, import 명령은 pool mount도 수행함
    • zpool import -a는 import 가능한 모든 pool을 가져옴
  • zpool import -R /mnt/tank2 tank처럼 -R을 쓰면 alternate root 위치에 mount함
    • 이는 pool 자체의 mount path가 아니라 대체 root 폴더임
  • zpool export [pool name]는 import의 반대 작업으로, pool 안의 mounted filesystem을 unmount한 뒤 export를 시도함
    • filesystem unmount가 실패하면 -f로 강제 unmount할 수 있음
    • 사용 중인 ZFS volume이 있으면 -f를 써도 export가 실패함
  • zpool destroy는 pool과 그 하위 dataset 또는 volume을 삭제함
    • 모든 데이터와 snapshot까지 삭제되므로 주의가 필요함
  • ZFS scrub은 pool의 모든 block을 알려진 checksum과 비교해 데이터 유효성을 확인함
    • parity가 있는 vdev에서는 정상 디스크의 데이터를 사용해 손상 데이터를 복구함
    • 시스템 상태를 유지하려면 scrub을 일정에 따라 실행해야 함
    • 시작: zpool scrub [pool]
    • 상태 확인: zpool status의 scan 영역 확인
    • 중지: zpool scrub -s [pool]

dataset 생성과 mount

  • zfs create는 새 filesystem 또는 volume을 생성하는 명령이며, 여기서는 volume보다 dataset을 중심으로 다룸
  • zfs create tank/dataset1은 tank 아래에 dataset1을 생성함
    • tank dataset은 zpool create 때 자동 생성됨
  • zfs create -p는 mkdir -p처럼 없는 상위 dataset까지 함께 생성함
    • 상위 dataset이 없으면 일반 zfs create는 실패함
  • zfs mount를 인자 없이 실행하면 현재 mount된 ZFS filesystem과 mount point를 표시함
    • 이 출력에는 child dataset이 포함되지 않음
  • zfs mount [pool|dataset]은 지정한 filesystem을 mount함
    • zfs mount -a는 모든 filesystem을 mount함
  • child dataset은 parent dataset 없이도 mount할 수 있음
    • 이 경우 OS filesystem에 필요한 경로가 생성됨
    • 나중에 parent dataset을 mount하려고 하면 생성된 디렉터리 때문에 directory is not empty 오류가 날 수 있음
  • zfs unmount [dataset]은 지정한 dataset을 unmount함

dataset 조회와 속성 설정

  • zfs list [dataset name]은 지정한 dataset 정보를 보여줌
    • dataset 이름 대신 mount point를 인자로 줄 수도 있음
  • zfs list를 dataset 이름 없이 실행하면 시스템의 모든 dataset을 재귀적으로 표시함
  • dataset 이름을 지정할 때 -r 플래그를 쓰면 해당 dataset 아래를 재귀적으로 표시할 수 있음
  • ZFS property는 filesystem, volume, snapshot, clone의 동작을 제어함
    • mount option과 비슷하게 보일 수 있음
  • zfs get all [dataset]은 dataset의 모든 property를 표시함
  • 특정 property 값은 zfs get compression tank처럼 확인함
  • property 설정은 zfs set을 사용함
    • 예시: zfs set compression=lz4 tank
    • 설정 후 zfs get compression tank로 compression 값이 lz4로 바뀐 것을 확인할 수 있음

snapshot의 동작과 활용

  • snapshot은 filesystem의 특정 시점 상태를 저장하지만 파일을 복사하지 않음
  • snapshot은 기존 데이터를 read-only로 표시하고, 이후 새 데이터가 filesystem에 추가되어도 snapshot이 보호하는 기존 data block에는 영향을 주지 않음
  • 예시 흐름은 다음과 같음
    • 기존 데이터 Data A가 있는 filesystem에서 snapshot 1을 생성함
    • 이후 Data B를 추가하고 snapshot 2를 생성함
    • 이후 Data C를 추가함
    • snapshot 1은 Data A를 보호하고, snapshot 2는 Data A와 Data B를 보호함
    • snapshot 1을 삭제해도 Data A는 snapshot 2에 의해 계속 보호됨
  • snapshot이 사용하는 데이터량은 매우 작음
    • 파일을 복사하는 대신 snapshot에 속한다는 filesystem 최상위 metadata block을 기록하기 때문임
  • snapshot은 소프트웨어 개발 테스트나 업그레이드 전 failsafe를 만드는 데 유용함
  • snapshot만으로는 backup 또는 DR 솔루션으로 간주하면 안 됨

snapshot 명령

  • snapshot 생성은 zfs snapshot [pool/dataset@snapshot_name] 형식을 사용함
    • 예시: zfs snapshot tank/dataset1@snapshot1
  • snapshot 목록은 zfs list -t snapshot으로 확인함
  • child dataset이 여러 개 있으면 top-level dataset에 snapshot을 만들거나 -r 플래그로 recursive snapshot을 만들 수 있음
    • 일반 snapshot 예시: zfs snapshot tank@snapshot-master
    • recursive snapshot 예시: zfs snapshot -r tank@recursive
  • zfs diff [older snapshot] [newer snapshot]은 snapshot 사이의 차이를 비교함
    • 출력에서 추가 파일과 수정된 경로를 확인할 수 있음
  • snapshot 복원은 zfs rollback [pool/dataset@snapshot_name]으로 수행함
    • rollback하면 snapshot 이후 생성된 파일이 삭제됨
    • 더 최신 snapshot도 삭제되며, 이 경우 -r 옵션 사용을 요구받을 수 있음

ZFS send/recv와 복제

  • ZFS send는 snapshot을 데이터 stream으로 보낼 수 있는 기능임
  • snapshot과 dataset을 파일, 다른 pool, 또는 SSH를 통한 다른 시스템으로 복제할 수 있음
  • 예시는 tank와 backup이라는 두 pool을 사용함
    • tank/Movies dataset에 1.50G 데이터가 있음
    • 전송 전 zfs snapshot tank/Movies@$(date '+%Y-%m-%d_%H-%M')로 snapshot을 생성함
    • zfs send tank/Movies@2020-11-03_15-29 | zfs recv backup/Movies로 snapshot을 backup pool에 전송함
  • 전송 후 zfs list에서 backup/Movies와 tank/Movies가 모두 보이고, zfs list -t snapshot에서도 양쪽 snapshot을 확인할 수 있음
  • zfs send는 다양한 옵션과 사용 사례를 살펴볼 만한 기능이며, RAIDZ와 snapshot과 함께 사용하면 filesystem을 더 견고하게 만들 수 있음

dataset과 snapshot 삭제

  • dataset 삭제는 zfs destroy [pool/dataset] 형식을 사용함
    • -r 플래그도 사용할 수 있음
  • snapshot 삭제도 zfs destroy [pool/dataset@snapshot_name]을 사용함
    • snapshot 삭제에도 -r 플래그를 사용할 수 있음
  • ZFS는 더 많은 기능을 제공하지만, 이 자료는 기본 개념과 명령을 익히는 출발점에 가까움

참고 자료

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이제 막 ZFS를 시작했는데, 생각보다 학습 곡선이 가파름. 흔한 사용 사례를 아주 단순하게 만들어 주는 쉬운 래퍼가 있으면 좋겠음
    예를 들어 풀 생성은 ashift=12, lz4 압축, xattr=sa, acltype=posixacl, atime=off 같은 합리적 기본값을 그냥 쓰고, 암호화는 여러 옵션 대신 켜기/끄기만 있으면 좋겠음
    암호화 키를 생성해 주고, 부팅 시 풀을 복호화하는 systemd 서비스를 설정해 주며, 키 백업을 안내해 주면 좋겠음. zfs list는 데이터셋의 마운트 여부, 암호화 여부, 키 로드 여부를 보여줘야 함
    재귀 데이터셋은 없애고 {pool}/{dataset} 대신 {pool}:{dataset}으로 풀과 데이터셋을 명확히 구분했으면 함. 풀이나 스냅샷 이름도 직접 짓지 않게 {hostname}-[A-Z], {pool name}_{datetime created} 같은 규칙과 숫자 단축명을 자동으로 붙이면 좋겠음
    풀 생성 때 디스크 ID를 직접 입력하지 않게 하고, /dev/sda, /dev/sdb로 만든 뒤 드라이브 순서를 바꿔도 헷갈리지 않도록 디스크에 메타데이터를 저장했으면 함
    진행 상황은 항상 pv로 보여주고, 주간 스크럽과 시간별/일별/주별/월별 스냅샷 및 정리를 자동 설정했으면 함
    풀이 없는 디스크로 전송하면 확인을 받은 뒤 송신 풀과 같은 설정의 단일 디스크 풀을 만들어 주고, zpool과 zfs는 하나의 명령으로 합치면 좋겠음
    암호화 데이터셋 전송 시 --raw를 자동 사용하고, 전송 기본값은 --replicate로 두며, 가능하면 -I를 쓰면 좋겠음. 스냅샷 파일시스템을 숨은 디렉터리에 감추지 말고 스냅샷 데이터셋을 쉽게 마운트하고 탐색하는 방법도 필요함

    • 합리적인 제안과 매우 강한 취향이 섞여 있음. ashift=12 기본값이나 {pool}:{dataset} 문법은 이해되지만, 이미 늦게 바꾸기는 어려워 보이고, 일부 제안은 모르는 사용 사례를 깨뜨릴 수 있음
      호스트 이름으로 풀을 짓는 방식은 여러 호스트에서 가져올 수 있는 SAN 풀에는 맞지 않음
      주간 스크럽, 주기적 스냅샷, 주기적 정리는 운영체제 스케줄러가 맡을 일이라고 봄. zpool과 zfs를 합치는 것도 가능은 하겠지만, 결국 zfs -pool XXXX, zfs -volume XXXX 같은 식이 될 텐데 왜 필요한지 모르겠음
      재귀 데이터셋은 실제로 유용한 경우가 있음. 반면 zfs list가 마운트 여부, 암호화 여부, 키 로드 여부를 보여줘야 한다는 데는 전적으로 동의함
      디스크 ID를 입력하지 말라는 부분은 애매함. ID, WWN, 라벨, sdX 등 여러 방식으로 지정할 수 있지만 어떤 디스크를 쓸지는 어쨌든 알려줘야 함
      디스크에 메타데이터를 저장해 순서를 바꿔도 찾게 하는 기능은 이미 있음. 드라이브를 몇 개 바꿔 꽂고 풀을 가져와도 찾아냄
      일부 제안은 기본값으로 괜찮지만, 몇몇은 자기 사용 패턴과 필요 바깥을 충분히 고려하지 않은 듯함. ZFS는 훨씬 더 많은 사용자를 대상으로 함
    • /dev/sda, /dev/sdb로 풀을 만들고 ZFS가 헷갈린다는 건 솔직히 ZFS 문제가 아니라 시대에 맞게 쓰지 않은 사용자 문제에 가까움
      Linux에는 꽤 오래전부터 /dev/disk/by-id/ata-$manufactuer-$serial-$whatever 같은 완전한 참조가 있음. 풀을 만들 때는 이런 경로를 써야 함
    • 많은 제안이 강하게 취향을 타는데, 그 자체가 나쁜 건 아니지만 기존 관례를 굳이 흔드는 것처럼 보임. 예를 들어 왜 {pool}:{dataset}이어야 하는지 모르겠음
      스냅샷 이름을 직접 짓기 싫다면 내가 만든 작은 도구 https://github.com/rollcat/zfs-autosnap이 맞을 수 있음
      zfs-autosnap snap을 cron에 시간별로 넣고, zfs-autosnap gc를 일별로 넣으면 보존 정책에 맞춰 스냅샷 기록을 굴려 줌
      간단한 ZFS 명령 래퍼를 쓰는 건 어렵지 않으니, 내 코드를 가져가서 자기 도구를 만들어도 됨
    • 대장장이 견습의 마지막 과제 중 하나가 실제 대장장이가 쓸 모든 도구, 즉 모루, 망치, 집게 등을 직접 만드는 일이라고 읽은 적이 있음
      직장에서도 그날 상정한 배포 형태에 맞춰 ZFS 배열을 만드는 스크립트를 여러 개 작성했음. 그 안에는 zvol을 올릴 LUKS 암호화 볼륨 생성, 이름 규칙 표준화, ashift=12, lz4 압축 같은 기본값 설정이 포함됐음
      이건 ZFS 자체 암호화가 들어가기 훨씬 전 일이었고, 지금 방식으로도 문제가 없어서 ZFS 암호화를 지원하도록 스크립트를 갱신하지는 않았음
      지금은 많은 플래그를 기억하지 못하지만 스크립트가 문서 역할을 해 주고, 팀의 다른 사람들은 make-zfs-big-mirror나 make-big-zfs-undundant-raid0만 실행하면 됨
      언젠가 1년에 20번 넘게 시스템을 프로비저닝할 일이 생기면 그마저도 프로비저닝으로 자동화될 수 있음
    • 이미 다른 사람들이 말했듯이 매우 취향 강한 제안들임. 의견을 갖는 건 괜찮지만, 많은 항목이 “내가 Linux에서 익숙한 방식이 아니다”에서 실제로 문제 있는 제안까지 걸쳐 있음
      풀 이름을 짓지 말자는 건 말이 안 됨. 풀을 그렇게 자주 만들지 않으니 그냥 이름을 지으면 됨
      스냅샷 이름을 짓기 싫다면 httm과 zfs allow를 쓸 수 있음. 예를 들어 httm -S .는 rpool/ROOT/ubuntu_tiebek@snap_2022-12-14-12:31:41_httmSnapFileMount 같은 스냅샷을 만듦
      zfs와 zpool은 각각 여러 하위 명령을 가진 훌륭한 Unix 명령임. ZFS 설계자들이 더 복잡한 단일 관리 명령을 만들지 않은 건 아주 똑똑한 결정이었다고 봄
      스냅샷 데이터셋을 명확히 마운트하고 탐색하는 것도 zfs mount로 쉽게 가능함. 다만 안정적인 가상 인터페이스가 모든 파일 버전을 검색하기 쉽게 해 주며, 이건 btrfs 등에서는 훨씬 어렵다는 점도 믿어 줬으면 함. httm도 참고할 만함
      [0]: https://kimono-koans.github.io/opinionated-guide/#dynamic-sn...
      [1]: https://github.com/kimono-koans/httm

  • ZFS에서 유용한 것들이 더 있음. zpool-attach(8)와 zpool-replace(8)의 차이를 알아두면 좋고, zfs list -t all -o space는 공간이 어디에 쓰이는지 보여줌
    큰 변경이나 업그레이드 전 운영체제를 보호하는 데는 ZFS Boot Environments가 최고의 기능임. 시작점으로 https://is.gd/BECTL가 유용할 수 있음
    zpool history poolname은 풀 구성과 변경 이력을 모두 보여줌. 예를 들어 zpool create, autotrim=on, atime=off, compression=zstd, recordsize=1m 같은 변경이 기록됨
    가이드에서 빠진 중요한 정보도 있음. 3-way 미러는 디스크 3개 중 2개가 고장 나도 데이터가 남고, 4-way 미러는 4개 중 3개가 고장 나도 남으며, N-way 미러는 N개 중 N-1개가 고장 나도 데이터가 보존됨
    데이터가 가장 중요하지만 슬롯이나 디스크가 많지 않을 때 유용함

    • N-way 미러는 ZFS가 읽기를 여러 디스크에 나눠 처리할 수 있다는 특성도 있음. 입출력 작업 수가 제한되던 회전식 디스크에서는 이 점이 꽤 중요했음

  • 수년째 대용량 다중 TB PostgreSQL 데이터베이스를 ZFS에서 운영하고 있음. ZFS 덕분에 백업, 과거 스냅샷 기반 테스트 환경 생성, 내장 압축을 통한 디스크 절약이 아주 쉬워짐
    관심이 있다면 경험을 https://lackofimagination.org/2022/04/our-experience-with-po...에서 읽을 수 있음

  • ZFS를 시작할 때 가장 도움이 된 건 FreeBSD의 ZFS Handbook과 Aaron Toponce의 글이었음
    [0] https://docs.freebsd.org/en/books/handbook/zfs/
    [1] https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux...

    • FreeBSD 문서를 좋아함
      굴러다니던 ECC RAM 1GB짜리 오래된 HP Microserver에 FreeBSD를 설치했고, 오래된 500GB 하드디스크 5개도 있어서 FreeBSD Handbook을 보며 5x 미러로 구성했음. FreeBSD는 처음이었는데 아주 수월했음

  • 최근에 주로 LAMP 서버로 된 인프라를 많이 재구축하면서 효율적인 백업 복제와 암호화를 위해 모두 Linux의 ZFS 기반으로 두기로 했음
    오래전부터 백업에 ZFS와 rsync를 함께 써서 꽤 익숙했고 결과적으로 잘 됐지만, 제대로 하려다 보니 예상보다 훨씬 큰 시간 소모가 있었음. 특히 데이터베이스와 복제 관련해서 웹에 잘못된 조언이 많았음
    데이터베이스는 최소한 블록 크기 정렬 같은 기본 튜닝을 해야 함. mariadb/InnoDB에 관해서는 Let's Encrypt 쪽 자료 https://github.com/letsencrypt/openzfs-nvme-databases가 압도적으로 좋았음. 모든 항목에 이유를 대고 여러 출처를 인용해서 가치가 큼
    웹을 더 찾아보면 불완전하고 근거 없는 이론을 곁들인 모순된 조언, 일화, 신화가 끝없이 나옴. 결국 직접 테스트하고, 조정하는 항목을 이해해야 하며, 조정하지 않기로 결정하는 것도 괜찮음
    복제는 정말로 매뉴얼 페이지를 추천함. ZFS는 견고한 복제 도구를 제공하지만 너무 범용적이라 Git의 하위 배관 명령처럼 느껴짐. SSH로 쓸 거라고 가정하지 않기 때문에 직접 이어 붙여야 하고, 자동화하려면 경계 조건까지 생각해야 해서 처음엔 무섭게 느껴짐
    그래서 다들 syncoid 같은 도구로 가지만, syncoid류 복제 스크립트에는 끔찍한 점이 있었음. ZFS의 send --replication 모드를 쓰지 않고, 더 유연하다는 이유로 Perl로 불완전하게 다시 구현함
    처음 테스트하면서 새로 복원했더니 모든 암호화 루트가 깨지고, 데이터셋 속성이 모두 자동 동기화되지 않는 걸 보면 미칠 노릇임. 내장 재귀 복제 옵션만 쓰면 ZFS가 이걸 처리해 줌
    마음먹고 직접 스크립트를 짜면 어렵지 않음. 단순하게 유지하고 syncoid처럼 불필요한 것들을 파이프라인에 잔뜩 넣지 않으면 됨. 실제 테스트하면 그런 것들이 속도를 늦추기도 함. 진행률은 pv로 보고 그냥 밀면 빠르게 동작함
    언젠가 내 복제 스크립트를 공개할지도 모름. 기본을 다루면서도 복제를 엉망으로 재구현하지 않는 좋은 참고 스크립트가 거의 없다고 느껴짐

    • 그 자료는 io_capacity와 io_capacity_max 튜닝을 언급하지만, MySQL 문서를 눌러 실제 매개변수 역할을 보면 아쉽게도 그다지 유용하지 않음
      이 값들은 변경 버퍼 병합 같은 백그라운드 입출력을 제어하고, 실제 작업이 필요한 주 프로세스에서 입출력을 빼앗을 수 있음
      꽤 바쁜 120K QPS MySQL DB를 운영해 본 경험상 둘 다 건드릴 필요가 없었음. 필요하다고 느낀다면 redo log가 차는 시간과 버퍼 풀의 더티 페이지 비율을 먼저 모니터링해야 함. 아마 다른 매개변수를 조정하는 편이 나을 것임
      [0] https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.ht...
    • 데이터베이스에서 블록 크기 정렬 같은 기본 튜닝을 할 때 의외로 확인할 점이 있음. 보통은 레코드 크기를 맞추라고 하고, 실제로는 데이터를 담는 ZFS 파일시스템의 레코드 크기를 줄이는 쪽으로 이어짐
      어떤 수준에서는 더 효율적일 수 있겠지만, 경험적으로는 압축률을 크게 떨어뜨림
      재미있는 2차 효과로, 워크로드에 따라 다르지만 디스크 대역폭이 병목이면 처리량이 오히려 나빠질 수 있음. 압축 덕분에 물리 디스크가 감당하는 것보다 빠르게 읽고 쓸 수 있는데, 압축을 망치면 읽기/쓰기 대역폭에 악영향이 생길 수 있음

  • 몇 년 전부터 Linux에서 ZFS를 쓰기 시작했고 전반적으로 순조로웠음
    유일하게 놀란 건 volblocksize 기본값이 대부분의 RAIDZ 구성에 꽤 나쁘다는 점임. 원시 디스크 공간의 50%를 잃지 않으려면 값을 키워야 함
    관련 글은 다음과 같음
    https://jro.io/nas/#overhead
    https://openzfs.github.io/openzfs-docs/Basic%20Concepts/RAID...
    https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i...
    결국 ZFS 관련 스프레드시트 중 하나까지 보게 됨
    ZFS overhead calc.xlsx
    https://docs.google.com/spreadsheets/d/1tf4qx1aMJp8Lo_R6gpT6...
    RAID-Z parity cost
    https://docs.google.com/spreadsheets/d/1pdu_X2tR4ztF6_HLtJ-D...

    • 개인적으로 미러 vdev의 50% 효율은 단순성과 크게 좋아지는 성능을 생각하면 공정한 대가라고 봄. 지금은 RAIDZ 풀도 확장할 수 있지만, 여전히 훨씬 복잡하고 성능도 그만큼 좋지 않음

  • 어릴 때 더 어리석었을 때, 열성 팬들이 오픈소스 NAS OS, 아마 FreeNAS와 ZFS가 얼마나 대단한지 많이 쓴 글을 읽었음. eBay에서 사양이 아주 낮은 중고 HP 마이크로 서버를 사고, 뭘 하는지도 제대로 모른 채 뛰어들었음
    커뮤니티 포럼에 질문을 몇 개 했지만 대부분의 답은 “문서는 읽었나요?”, “RAM은 충분한가요?”였음
    그 문서라는 건 읽기 어려운 스타일의 PowerPoint 발표자료였고, 약간 전도사 같은 문체에, 지식 전제가 많고, 정기적으로 갱신되지도 않았음. 필요한 RAM 양도 모호했고, 그냥 가능한 한 많이 넣으라는 데 초점이 있었음
    결국 기술, 과장된 분위기, 내 지식 수준에 대한 모든 위험 신호를 무시했고 데이터를 많이 잃었음. 배운 게 많았음

    • 대략 얼마나 오래전인지 기억나는지 궁금함. ZFS는 2000년대 초부터 있었고 FreeNAS는 2005년에 시작한 걸로 기억함
      파일시스템은 훨씬 안정적이 되었고, 문서도 더 명확해졌다고 봄
      그래도 ext3 같은 전통적인 저널링 파일시스템보다 더 강력하고 고급인 만큼, 스스로 발등을 찍을 방법도 더 많아짐

  • 나중을 위해 몇 가지를 더 남기자면, ZFS의 모든 중복성은 vdev 계층에 들어 있음. zpool은 하나 이상의 vdev로 만들어지고, 어떤 경우든 zpool 안의 vdev 하나라도 잃으면 zpool은 영구적으로 파괴됨
    역사적으로 RAIDZ, 즉 패리티 RAID는 디스크를 추가해서 확장할 수 없었음. RAIDZ를 키우는 유일한 방법은 배열의 각 디스크를 하나씩 더 큰 디스크로 교체하는 것이고, 재구축 중 디스크가 고장 나지 않길 바라야 함
    매우 아마추어적인 판단으로는 RAIDZ2나 RAIDZ3처럼 디스크 수가 많은 경우에만 RAIDZ를 고려하겠음. n<=6이고 예산이 허락한다면 여러 개의 미러 vdev를 쓰겠음. 운영 환경에서는 여러 RAID의 읽기/쓰기 성능 지표를 더 조사해야 함

    • 미러 풀이 보통 더 안전한 방식이 맞음
      단, 현장 전체 백업이 있고 자신의 능력과 모니터링을 꽤 신뢰할 수 있을 때에만 RAIDZ1을 권할 수 있음
      내 경우 3x3 드라이브 풀이 있고, 스냅샷을 랙의 몇 U 아래에 있는 백업 대상으로 보냄. 그 백업 대상은 매일 깨어나고 3x4 드라이브 풀을 갖고 있으며 역시 RAIDZ1임
      NAS에서 드라이브 고장이 나면 즉시 백업을 시작해 스냅샷을 받아들인 뒤 드라이브를 교체할 계획임. 그러면 재실버링 중 두 번째 드라이브 고장으로 데이터가 날아갈 가능성을 최소화할 수 있음
      정말 중요한 데이터는 물론 외부에도 둠

  • 이해하지 못한 ZFS 문제를 겪고 있음. 어떤 zpool에서 zpool status가 감지된 오류 목록을 출력하는데, 파일에는 없고 항상 스냅샷, 그리고 아마 삭제된 스냅샷으로 보이는 16진수 항목에만 나타남
    오류로 표시된 스냅샷을 삭제하고 zpool scrub을 두 번 돌리면 오류가 사라지고 스크럽도 오류를 찾지 못함. zpool status는 어떤 장치에도 오류를 표시한 적이 없음
    파일에는 오류가 없고, 장치에도 오류가 없고, 스크럽에서도 오류가 감지되지 않는데 실행 중에는 하루에 새 “오류”가 12개씩 zpool status에 나타남. 어떻게 이런 일이 생기는지 모르겠음

    • 정말 좋은 질문임. 지금 직접 중복 이슈를 찾아볼 시간은 없지만 메일링 리스트 https://zfsonlinux.topicbox.com/groups/zfs-discuss와 GitHub 이슈 https://github.com/openzfs/zfs/issues를 찾아보거나 질문할 수 있음
      전자는 이상해 보이지만 메일링 리스트의 정상적인 웹 프런트엔드임
    • 같은 문제를 겪고 있음. 가끔 파일이 스냅샷뿐 아니라 현재 파일 버전에서도 손상된 것처럼 보임
      이동하거나 수정할 수 없고 삭제만 가능함. 왜 이런 파일들이 손상되는지 아무 단서가 없음. 다행히 전부 큰 Linux ISO라서 치명적이지는 않았음
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.