미리 알려 두기
이 글은 여러 개의 문서를 참고하여 정리/번역/요약한 것입니다. 제가 이해한 것을 적은 것이므로 잘못된 정보나 누락된 정보가 있을 수 있습니다.
ZFS란?
ZFS 소개
ZFS는 Zettabyte File System의 약자로 썬마이크로시스템즈에서 개발한 파일 시스템이고 솔라리스에 탑재되었습니다. 이후 썬 마이크로시스템즈가 오라클에 인수되면서 오라클이 ZFS를 클로즈드 소스로 전환하자 그에 불만을 가진 개발자들이 OpenZFS 라는 오픈소스 ZFS 프로젝트로 갈라져 나왔습니다.
ZFS는 파일 시스템과 논리 불륨 관리자가 통합되어 있고, 데이터 손상에 대한 광범위한 보호를 제공하고 높은 스토리지 용량을 지원하며, 지속적인 데이터 무결성 검사 및 자동 복구, Raid-Z 기술으로 Raid를 파일 시스템에서 네이티브로 지원합니다. 또한, 스냅샷이나 압축, 중복 제거 기능 등을 파일 시스템에서 지원하며, NFSv4 ACL을 완벽하게 지원합니다.
OpenZFS는 유닉스 계열의 시스템에서 널리 사용됩니다. 이 중 FreeBSD는 OpenZFS 를 탑재한 대표적인 OS중 하나인데, ZFS를 루트 시스템에서부터 완벽하게 지원합니다. 리눅스의 경우도 ZFS를 지원하기는 하나, 아직 불안정하고 라이센스 문제 때문에 정식으로 포팅되어 있지는 않은 상황입니다.
ZFS만의 특징
ZFS는 가희 지상 최강의 파일 시스템이라 불릴 정도로 강력한 파일 시스템입니다. 다른 파일 시스템에서는 상상도 못할 기능을 네이티브로 안정적으로 지원하여 다른 어떤 파일 시스템보다 강력한 파일 시스템이 될 수 있었죠. 그럼 어떤 특징이 있는지 자세히 알아 봅시다. 필자는 ZFS가 다른 파일 시스템과 차별화되는 점이 크게 4가지라 보고 있습니다.
- 파일 시스템과 볼륨 관리자를 통합
- 데이터 무결성
- Copy-On-Write
- 128비트 파일 시스템
파일 시스템과 논리 불륨 관리자의 통합
ZFS는 파일 시스템과 불륨 관리자가 통합되어 있습니다. 이 때문에 다른 파일 시스템과는 상당히 다른 특징과 기능을 제공합니다.
대표적인 예를 몇가지 들어 보겠습니다.
- 레이드 카드와 같은 별도의 하드웨어나, 특별한 소프트웨어 없이 Raid를 네이티브로 매우 안정적으로 지원.
- 특별한 장치 없이 캐시 드라이브 추가 가능
- 데이터 블록의 위치를 알고 있기 때문에 빠른 속도로 리실버링이 가능함
ZFS는 파일 시스템과 불륨 관리자의 역활을 겸하기 때문에 Raid를 파일 시스템에서 지원합니다. 또한 캐시 용도의 드라이브를 추가할 수 있으며, 일반적인 Raid와 달리 어떤 블록에 데이터가 저장되있는지 알기 때문에 빠른 데이터 리실버링이 가능합니다.
파일 시스템과 불륨 관리자가 통합되면서 생기는 이점은 이 말고도 dataset (후술함) 이나 zpool (후술함) 과 같은 구조적/개념적 특징도 생기지만, 일단 가장 두드러지게 나타나는 특징은 Raid를 아무런 특별한 하드웨어 없이 파일 시스템에서 지원할수 있다는 것이라 생각합니다.
데이터 무결성
다음은 데이터 무결성입니다. 어떤 파일 시스템에서 어떤 디스크에 데이터를 저장한다 할지라도 저장된 데이터는 변형되고 파괴됩니다. 사용자의 실수나 하드 디스크가 파괴되는 것 말고도 ‘OS 가 감지할 수 없는’ 데이터 파괴도 일어납니다. 원인은 다양합니다. 느슨하게 연결된 케이블일 수도 있고, 외부 진동일수도 있으며, 자연 방사선의 영향으로 비트가 뒤집히기도 합니다. 그리고 일반적인 데이터 무결성을 보장하지 않는 파일 시스템에서는 데이터가 파괴된지 전혀 알지 못합니다.
이에 반해, ZFS의 경우에는 데이터 파괴를 막을 수는 없지만, 파괴된 데이터를 자동으로 복구할수 있는 방법을 제공합니다. 그 기능이 후술할 scrup입니다.
Copy-On-Write
Copy-On-Write 트랜젝션. 이건 말 그대로 쓰기 전에 이전의 내용을 복사한다는 뜻입니다. 하지만 ZFS가 데이터를 사용하기 전에 그 데이터의 사본을 만든다는 뜻은 아닙니다.
알기 쉽게 copy-on-write 트랜젝션 모델을 사용하지 않는 다른 파일 시스템과 비교해서 설명하도록 하겠습니다.
여러분의 하드디스크에 A라는 데이터가 있다고 가정해 봅시다. 그런데 이 데이터를 B라는 데이터로 수정 (쓰기) 를 해야 한다고 생각해 봅시다. 그럼 Copy-On-Write 트랜젝션 모델을 사용하지 않는 파일 시스템에서는 A가 저장된 데이터 블록에 B라는 데이터를 ‘덮어 씌울’ 것입니다. 그런데 만약 B라는 데이터를 입력하다가 무언가 문제 (갑자기 전원이 내려갔다던가, OS의 문제로 오류가 발생했다던가) 가 발생했다면 어덯게 될까요? A라는 데이터는 파괴되고, B라는 데이터도 손실됩니다.
하지만 ZFS는 다릅니다. ZFS에서 A라는 데이터를 B라고 변경해야 한다면, A라는 데이터는 그대로 둔 채, 새로운 블록을 할당하여 B라는 데이터를 입력한 후, 쓰기 작업이 성공적으로 된 것을 확인한 후, B라는 데이터를 가리키도록 업데이트합니다. 즉, 무언가 문제가 발생했더라도 A라는 데이터는 파괴되지 않습니다.
또한 이 Copy-On-Write 트랜젝션 모델 덕분에 스냅샷이 매우 효율적으로 기능하게 됩니다. 스냅샷에 대한 것은 ‘기능 소개’ 에서 서술합니다.
128비트 파일 시스템
ZFS는 최초의 128비트 파일 시스템입니다. 그래서 거의 무한대의 용량을 지원합니다. 다른 몇 가지의 파일 시스템과 비교를 통해 알아보겠습니다.
- FAT32 는 32비트 파일 시스템입니다.
- 논리 파티션의 한계는 8Tb
- 최대 파일 크기는 4Gb
- 하나의 디렉토리에 들어갈 수 있는 최대 파일 개수 16,384개
- NTFS 는 64비트 파일 시스템입니다.
- 논리 파티션의 한계는 256Tb
- 최대 파일 크기는 16Tb
- 하나의 디렉토리에 들어갈 수 있는 최대 파일 개수는 4,294,967,295개
- ZFS는 128비트 파일 시스템입니다.
- 모든 zpool 의 한계 크기는 2560억 제비바이트 (zpool이 무엇인지는 ‘ZFS 용어 정리’ 에서 서술합니다.)
- 하나의 디렉토리에 들어갈 수 있는 최대 파일 개수는 2^48=281,474,976,710,656개
엄청난 크기의 용량 한계를 가짐을 알 수 있습니다. 거의 무한대라 보아도 될 정도입니다.
ZFS용어 정리
ZFS는 다른 파일 시스템과는 상당히 다릅니다. 그래서 용어도 생소한게 많을 것입니다. 세세한 기능을 알아 보기 전에 용어부터 먼저 정리해 보도록 하겠습니다.
vdev
vdev는 ZFS의 가장 기본 레벨으로 가상 장치라는 의미입니다. 이 vdev는 단일 디스크 또는 여러 개의 디스크로 구성됩니다.
예를 들면
- 단일 디스크
- 미러링이나 Raidz된 여러 디스크
- 다른 vdev
간단하게 하나 또는 여러개의 디스크 (또는 파티션) 가 vdev라는 가상의 장치를 구성합니다. 어떠한 vdev는 다른 모든 vdev와 독립적입니다. 그래서 vdev는 하나의 ZFS시스템 내에서 원하는 대로 설정하고 혼합할 수 있습니다.
zpool
데이터의 최상위 수준입니다. 일반 파일 시스템의 불륨과 비슷합니다만 상당히 다릅니다. 정확하게 말하자면 zpool은 파티션과 불륨 사이에 놓인 레이어 계층입니다.
zpool은 하나 이상의 vdev와 SLOG와 같은 캐시로 이루어집니다.
zpool은 라이브 상태에서 자유롭게 확장이 가능합니다. 시스템을 정지시키거나 zpool을 비활성화 시키는 등의 작업 없이도 다수의 vdev와 캐시를 추가할 수 있습니다.
zpool은 모든 vdev에 데이터를 스트라이프 해서 저장합니다. 만일 Raidz1 (Raid5)로 묶은 5개의 디스크로 구성된 vdev 2개로 이루어진 zpool이 있다면, 그 zpool은 스트라이프 된 Raidz1, 즉 Raid50이 되는 셈입니다.
정리하자면 zpool은 한개 이상의 vdev와 캐시 vdev로 이루어진 레이어 계층이라 볼 수 있습니다.
캐시 장치
ZFS는 캐시 장치를 허용하고 관리합니다. 레벨 2 캐시 장치는 단일 디스크일 수도 있고, 미러링 또는 스트라이프 된 디스크일수도 있습니다.
| 저장 위치 | 읽기 캐시 | 쓰기 캐시 | |
| 레벨 1 | 램 |
ARC |
트랜젝션 그룹 |
| 레벨 2 | 고속 디스크 | L2ARC | ZIL 또는 SLOG |
- Adaptive Replacement Cache즉 적응형 교체 캐시의 약자로서 읽기 캐시입니다. 램 디스크를 사용하기 때문에 속도가 빠르며 효율적인 캐싱을 사용하기 때문에 많이 사용할 데이터와 메타 데이터를 캐싱해 시스템 성능을 대폭 높입니다. ZFS가 램을 많이 사용하게 되는 주요 원인중 하나인데, 그 이유는 ARC는 최대한 많은 양의 램을 사용하도록 설계되어 있으며 ZFS가 최적의 성능을 발휘하기 위해선 1Tb 의 저장 공간 = 1Gb의 램 이 필요하다고 알려져 있습니다.
하지만 이는 개인 서버 레벨에서는 ARC 크기 규칙은 크게 중요하지 않은데, 그 이유는 추가 설명 – ARC 단락에서 설명합니다. - 트랜젝션 그룹은 램의 쓰기 캐시입니다. 여러 파일 시스템에 존재하는 것인데, 디스크에 데이터를 쓰기 전에 잠시 (일반적으로 5~30초 내) 머무는 캐시입니다.
- L2ARC는 Level 2 ARC 라는 뜻으로 ARC를 보조하는 용도입니다. zpool보다 빠르고 내구도가 좋은 고속 SSD가 권장되며, zpool의 일원으로 추가될 수 있습니다. 또한 ARC처럼 해당 zpool의 데이터를 효율적으로 캐싱합니다.
ZFS는 가능한 많은 데이터를 L2ARC에 저장하려 하기 때문에 L2ARC의 크기는 수십~수백 기가바이트가 넘을 수 있습니다.
L2ARC는 DB 서버와 같은 랜덤 읽기 부하가 큰 환경에서 큰 성능 향상을 내 줍니다. 반면 영상을 본다던가 하는 연속 읽기의 경우에는 L2ARC로 인한 성능 향상은 적습니다. - ZIL과 SLOG를 알기 전에 동기 쓰기와 비동기 쓰기를 먼저 알아야 합니다. 비동기 쓰기는 어떤 프로그램이 디스크에 데이터를 쓸 경우, 램에 데이터를 일시적으로 저장한 후, 디스크에 안전하게 데이터가 저장되는 것을 기다리지 않고 다음 명령을 실행합니다. 이 경우, 프로그램의 실행 속도는 빠르지만 전원 손실 등의 문제가 발생할 경우 쓰고자 한 데이터가 손상된다는 문제점이 있습니다. 반면 동기 쓰기의 경우는 디스크에 안전하게 기록되는 것을 확인한 후 다음 명령을 실행합니다. 그래서 데이터 무결성을 보장할 수 있지만, 프로그램 실행 속도가 상대적으로 느려집니다.
ZIL은 ZFS Intent Log 의 약자로써 쓰기 오류나 전원 손실 등의 문제에서 데이터를 보호하기 위해 주로 사용되며, sync=allways 옵션을 선택하였을때 동기 쓰기 캐시로서 작동합니다. ZIL은 zpool의 일부를 사용하기 때문에 속도가 느리며 디스크에 2번 기록이 된다는 문제점이 있습니다.
SLOG는 동기 쓰기 시 쓰기 캐시로 작동합니다. SLOG가 어떤 zpool의 일원일 때, zpool 에 동기 쓰기 요청이 들어올 경우 데이터는 느린 디스크 풀에 저장되는 것이 아닌 상대적으로 빠른 SLOG 에 저장된 후, 디스크에 저장됩니다. 즉, SLOG가 동기 쓰기 시 쓰기 캐시로 작동하면서 동기 쓰기가 비동기 쓰기처럼 빠르게 작동하게 됩니다. 또한 ZIL이 행해야 할 캐싱을 SLOG가 하게 됨으로서 디스크의 부하를 줄이고, 데이터를 모아서 기록한다는 캐시의 특성상 데이터 파편화를 줄이는데도 도움이 됩니다.
SLOG는 동기 쓰기가 잦은 NFS공유나 DB 서버 등을 사용할 때 성능 향상에 큰 도움을 줍니다. SLOG는 전원 손실 시 SLOG에 기록되어야 할 정보가 손실되지 않아야 하며며, 빠른 쓰기 속도가 필요하고 부하가 많이 걸린다는 특성상 내구도가 높고 속도가 빠르고 전원 손실 보호 기능이 있는 기업용 SSD를 권장합니다.
과거에는 SLOG가 손상되면 zpool 전체가 손실된다는 문제점이 있었으나, 현재는 SLOG가 손상되어도 zpool에는 영향을 미치지 않고, SLOG가 제공하던 성능 향상만이 사라집니다.
dataset
dataset은 일반 파일 시스템의 불륨에 해당합니다. 하지만 일반 파일 시스템의 불륨과는 상당히 다릅니다. dataset은 ZFS가 파일 단위로 관리하는 공간으로서 마치 디렉토리처럼 작동합니다.
dataset은 일반적인 파일 시스템의 불륨과 달리 디스크의 공간과 1:1매칭되지 않습니다. 그래서 용량의 확장과 축소가 매우 자유롭습니다. 아예 용량의 한계를 설정하지 않을 수도 있습니다.
dataset은 일반 파일 시스템의 불륨처럼 레코드 사이즈를 지정할 수 있습니다. 레코드 사이즈는 파일이 저장될 때 얼마만큼의 크기를 최소 단위로 설정하고 기록할 것인지를 설정하는 것입니다.
dataset은 압축과 중복 제거 기능을 제공합니다. 압축은 기록될 데이터를 압축해 크기를 줄이는 것이고, 중복 제거는 dataset 내의 중복되는 데이터 블록을 제거하여 용량을 줄이는 것입니다. 압축과 중복 제거는 ‘기능 설명’ 에서 더 자세하게 다룹니다.
dataset은 스냅샷을 지원합니다. 스냅샷은 어떤 파일이나 디렉토리의 상태를 보존하는 기술을 말합니다. 스냅샷에 대한 자세한 설명은 ‘기능 설명’에서 더 자세하게 다룹니다.
dataset은 트리 구조를 가집니다. 어떤 dataset안에 다른 dataset이 들어갈 수 있으며, dataset은 상위 dataset의 레코드 사이즈, 압축 등의 속성을 상속받을 수도, 그렇지 않을 수도 있습니다.
일반적인 파일 시스템의 불륨과는 상당히 다름을 알 수 있습니다. 특히 1:1매칭되지 않는다는 점과, 트리 구조를 가진다는 점은 상당히 독특한 특징입니다.
물론, dataset을 디렉토리처럼 사용할수는 있습니다.
zvol
위에서 dataset은 ZFS가 파일 단위로 관리하는 공간이라 하였습니다. 그에 반해 zvol의 경우에는 ZFS가 블럭 단위로 관리하는 공간입니다.
블록 단위로 관리되기 때문에 ZFS는 zvol안에 무슨 데이터가 들어있는지 전혀 알지 못합니다. 그래서 zvol은 ntfs나 ext4와 같은 다른 파일 시스템으로 포맷될수 있으며, iSCSI 등의 네트워크 스토리지를 구성하는데 사용될 수 있습니다.
zvol은 dataset 처럼 트리 구조를 가지지 않습니다. 하지만 zvol은 어떠한 dataset 안에 위치할 수 있습니다.
zvol은 블럭 단위로 관리되고 트리 구조를 가지지 않는다는 특성만 제외하면 dataset의 모든 특징을 가집니다. zvol은 압축될수 있고, 중복 제거 될 수 있으며, 레코드 사이즈를 정할 수 있고, 스냅샷을 찍을 수도 있습니다.
세부 기능 알아보기
앞에서 ZFS의 특징을 알아보고 용어 정리를 하였습니다. 이제 세부 기능을 알아보도록 합시다.
Scrub
앞서 데이터는 변질되고 파괴될 수 있다고 하였습니다. ZFS는 그 파괴를 복구하기 위한 기능이 있다고도 하였습니다. ZFS가 데이터 무결성을 지키기 위하여 사용하는 기능이 바로 scrub입니다.
scrub은 zpool의 모든 데이터와 메타 데이터를 검사하여 (무결성 검사) 데이터가 정상인지 확인한 후, 자동으로 복구합니다. 검사에는 SHA-256해시를 사용하고 더 강하거나 약한 다른 해시를 사용할 수도 있습니다.
scrub은 zpool의 모든 데이터와 메타데이터를 검사한다는 특징 때문에 디스크에 심한 읽기 부하와 그리 심하진 않지만 CPU에 부하를 겁니다. 그래서 20~30일에 한번, 새벽에 검사하는 것을 추천합니다.
참고로 이 scrub와 관련하여 ECC메모리에 대한 토론이 있었습니다. 그에 대해서는 ‘추가 설명’ 단락에서 다룹니다.
Raidz
Raidz또는 Raid-Z는 Raid + ZFS 라는 뜻입니다. ZFS에서 제공하는 Raid 기능이라는 뜻입니다. ZFS는 파일 시스템이자 불륨 관리자이기 때문에 파일 시스템에서 Raid를 지원하고, 미션 크리티컬 엔터프라이즈급 환경을 노리고 만든 파일 시스템이기 때문에 Raid를 특별한 하드웨어나 소프트웨어 없이도 하드웨어 레이드만큼의, 또는 그 이상의 안정성과 성능을 가집니다.
ZFS는 동적 스트라이프 넓이를 사용하고, Copy-On-Write 트랜젝션 모델 덕분에 쓰기 홀 오류가 제거됩니다. 또한, 읽기-수정-쓰기 시퀀스를 수행할 필요가 없기 때문에 기존 Raid5보다 빠릅니다.
Raid의 종류
ZFS는 5개의 레이드를 지원합니다.
- 미러링 (Raid1)
- 스트라이프 또는 Raidz0 (Riad0)
- Raidz1 (Raid5) : 하나의 패리티를 사용해 디스크 한개의 고장을 허용
- Raidz2 (Raid6) : 두개의 패리티를 사용해 디스크 두개의 고장을 허용
- Raidz3 : 세 개의 패리티를 사용해 3개의 디스크 고장을 허용. 10개 이상의 디스크를 레이드로 묶을 때 리실버링 중에 다른 디스크가 고장나도 레이드가 파괴되는 것을 방지하기 위해 사용됨.
스페어
ZFS는 다른 Raid 와 같이 스페어 디스크를 지원합니다. 스페어 디스크는 Raid를 구성하는 어떤 디스크에 문제가 생겨서 다운될 경우, 그 디스크를 대신하여 즉시 Raid의 맴버가 되어 리실버링을 수행하여 Raid 를 복구합니다. 무정지 시스템에서 자주 사용합니다.
리실버링
리실버링이라는 단어가 자주 나왔습니다. 리실버링은 배열 동기화라는 뜻으로 Raid를 구성하는 어떤 디스크에 변동 (디스크에 문제가 생겼다던가) 할 경우 변동이 있던 디스크의 데이터를 복구하여 Raid의 구성을 정상으로 되돌리는 작업을 뜻합니다.
기존 Raid의 경우는 어떤 데이터가 어떤 블록에 들어있는지 전혀 알지 못하기 때문에 디스크 전체를 복구해야 하기 때문에 시간이 오래 걸리지만, ZFS의 경우는 어떤 데이터가 어떤 블록에 들어있는지 정확히 알기 때문에 데이터가 들어 있는 블록만 복구하면 되기 때문에 시간이 크게 줄어듭니다.
만약 어떤 디스크를 10%만 사용한 상태였고, 그 디스크가 분리되고 다른 디스크가 Raid의 맴버가 되어 리실버링을 할 경우, 기존 레이드는 10%만 사용하였다 하더라도 어떤 데이터가 어디에 있는지 알지 못하므로 하드 디스크 전체를 복구합니다.
이에 반해 ZFS는 어떤 데이터가 어떤 블록에 있는 지 알고 있으므로 10%의 공간만 복구하면 되기 때문에 리실버링 속도가 기존 레이드에 비해 빠릅니다.
스냅샷
스냅샷은 어떤 데이터의 상태를 보존시킨 것을 의미합니다. 백업과는 다릅니다. 백업과의 차이점은 해당 데이터의 변화된 부분만을 저장한다는 점에서 다릅니다. 예를 들어 ABCD1234라는 데이터를 ABFF1234로 바꾸었다면 백업의 경우는 ABCD1234를 저장하고 스냅샷은 CD를 저장합니다.
ZFS는 dataset이나 zvol 단위에서 스냅샷을 찍을 수 있도록 지원하는데, 위에서 설명한 Copy-On-Write 트랜잭션 덕분에 이전 데이터가 기록된 블록을 유지할 수 있기 때문에 스냅샷이 매우 효율적으로 동작합니다.
정확히 변경된 데이터의 스냅샷을 찍기 때문에 차지하는 용량이 적고, 스냅샷을 찍는 것도 즉시, 복구도 즉시 가능합니다. 더해서 스냅샷은 복제할 수 있고, 수정할 수 있으며, 다른 스냅샷과 비교할 수 있으며 아예 다른 서버로 전송할수도 있습니다.
스냅샷은 랜섬웨어의 영향을 피하거나, 파일의 히스토리를 남겨놓기에 아주 편리하고 강력한 기능입니다. 예를 들어 개인 폴더에 하루에 한 번 스냅샷을 찍도록 설정해 놓았다면, 그 후 랜섬웨어나 개인의 실수로 파일이 손상되더라도 스냅샷을 통해 하루 전으로 돌리면 모두 복구되기 때문입니다.
암호화
ZFS는 zpool단위에서 암호화를 지원합니다.
pool을 암호화하면 하드 디스크에 암호화된 데이터만 쓰이기 때문에 나중에 디스크를 처리할 때 제로필이나 랜덤필 등의 작업을 하지 않아도 된다는 장점이 있습니다. 단점은 암호화를 하기 때문에 속도가 떨어질 수 있고, 암호화 키를 잊어버리면 데이터가 소실된다는 문제가 있습니다.
압축
ZFS는 dataset이나 zvol단위에서 압축을 지원합니다. 디스크에 기록하기 전에 압축을 한 후 기록하기 때문에 적절히 사용하면 용량 감소에 큰 도움이 됩니다. 반대로, 부적절하게 사용하면 오히려 성능에 해가 됩니다. 예시를 들어 보겠습니다.
- 텍스트 파일은 매우 압축이 잘 됩니다. 1Gb 텍스트 파일 100개, 총100Gb 정도의 데이터가 있다면 그냥 저장할 경우 100Gb지만 gzip9으로 압축한다면 9Gb 정도로 줄어듭니다.
- 영상은 압축이 되지 않거나 오히려 용량이 늘어납니다. 영화가 저장되는 dataset에 gzip압축을 걸어 둔다면 용량의 이점은 전혀 없으면서 영화를 저장하고 볼 때 마다 CPU에 부하가 걸립니다.
- 압축은 크든 작던 CPU에 부하를 겁니다. 만약 IO가 잦은 dataset서 gzip9 압축을 사용한다면 IO가 느려지고 CPU에 부하가 많이 걸리게 됩니다.
압축 설정은 압축 설정 이전의 데이터에 영향을 끼치지 않습니다. 압축을 한 dataset의 압축을 한다 하여 이전에 기록된 dataset이 압축되는 것도 아니고, 그 반대도 마찬가지입니다.
FreeNAS는 LZ4, gzip(레벨 1,6,9), zle, lzjb 압축 알고리즘을 지원합니다. 기본값은 LZ4입니다.
중복 제거
ZFS는 dataset이나 zvol 단위에서 중복 제거를 지원합니다. 중복 제거는 같은 데이터가 들어 있는 여러 개의 블록이 있다면 하나의 블록만을 남기고 나머지를 삭제한 후, 읽기 시 하나의 블록을 참조하도록 하는 방식입니다. 블록의 동일성을 검증하기 위해 SHA-256과 같은 안전한 해시를 사용하고, 더 강하거나 약한 해시 알고리즘을 선택할 수 있습니다.
중복 제거는 용량 감소에 도움이 되지만, 함부로 사용해서는 안됩니다. 이유는 아래 ‘주의점’ 에서 다룹니다.
읽기 쓰기 효율성
ZFS는 zpool의 성능을 최대화 하는 방식으로 pool을 구성하는 모든 vdev를 효율적으로 사용합니다. ZFS는 vdev의 여유 공간을 기반으로 vdev에 쓰기를 할당합니다. 예를 들어, 만약 30%사용한 vdev로 이루어진 zpool에 사용하지 않은 새 vdev를 추가한다면 zpool은 새로 추가한 vdev에 더 많은 양의 데이터를 기록합니다.
공유
NFS나, iSCSI 등의 공유 기능을 파일시스템 자체에서 지원합니다. 하지만 공유의 경우는 OS마다 지원 여부에 차이가 있는데, 예를 들어 FreeBSD 의 경우는 SMB (CIFS) 와 iSCSI 기능이 누락되어 있습니다. 하지만 외부 패키지 (예를 들어 samba) 를 이용해 이 기능을 지원할 수 있으며, 실제로 완벽히 지원됩니다.
주의점
ZFS는 강력한 기능을 지원하지만 몇가지 주의점이 있습니다. 이 중 대부분은 반드시 지켜야 하는 사항이며, 지키지 않는다면 문제가 발생할 수 있습니다.
레이드 카드 사용 금지
아주 중요한 사항입니다. ZFS는 모든 저장 장치에 원시 엑세스 권한이 있고, 하드웨어, 펌웨어, 기타 소프트웨어 디스크를 사용하여 시스템에 저장되었을 때 보다 그렇지 않을 때 더 효율적으로 데이터를 보호합니다. ZFS가 데이터가 안전하게 저장되었는지 확인하거나 데이터를 캐싱하는 등의 디스크 처리를 최적화하도록 설계된 수많은 알고리즘을 가지고 있기 때문입니다.
만약 ZFS가 디스크에 대한 원시 엑세스 권한이 없는 상태라면 (예를 들어, 하드웨어 레이드 카드를 사용한 상태라면) ZFS는 Raid 어레이의 성능이 저하되었거나 재구성되었는지 알지 못하며, 데이터가 손상되었는지 확인할 수 없으며, 디스크에 데이터를 효율적으로 배치할수 없기 때문에 장애를 예방하거나 신속하게 복구할 수 없습니다. 또한 레이드카드가 ZFS와 간섭을 일으켜 성능이 저하되거나 데이터가 파괴될 수 있습니다.
만약 레이드 카드를 사용해야만 한다면 HBA 레이드 카드를 사용하되 하드웨어 Raid 기능을 끄고 사용해야만 합니다.
마찬가지로 esxi 등의 가상화 시스템 위에 FreeNAS와 같은 ZFS시스템을 설치한다면 디스크를 esxi를 통해 할당하는 것이 아닌, 디스크 컨트롤러를 통째로 ZFS 시스템에 패스스루로 연결해야만 합니다.
디스크의 여유 용량
Copy-On-Write 의 특성상 pool의 용량이 가득 차게 되면 성능이 떨어집니다. 70%이하를 사용했을 때 최적의 성능을 발휘하며, 특정 비율 (보통 80%) 이상 사용하게 되면 ZFS는 속도 지향적 접근 방식에서 공간 절약 방식으로 전환되며 작업 공간을 보존하는데 주력하기 때문에 성능이 급격히 떨어집니다.
중복 제거
앞서 중복 제거는 함부로 사용해서는 안된다 하였습니다. 그 이유는 높은 하드웨어, 특히 많은 양의 램을 요구하기 때문입니다.
1Tb의 공간을 중복 제거 하기 위해서는 5Gb의 램을 사용해야 합니다. 만약 램이 부족할 경우 급격한 성능 저하부터 커널 패닉까지 다양한 문제가 발생할 수 있습니다. 그리고 모든 블록을 검사하고 비교해야 하기 때문에 CPU에 큰 부하가 걸립니다.
또한 중복 제거된 데이터는 중복 제거 이전으로 되돌릴 수 없습니다. 만약 중복 제거를 한 dataset을 중복 제거 이전으로 되돌리고 싶다면 데이터를 백업한 후, dataset 을 지우고 다시 dataset을 만들어 복구하는 방법밖에는 없습니다.
대부분의 경우, 중복 제거를 사용하기보다는 압축을 사용하는 것이 훨씬 바람직합니다.
L2ARC 의 크기
L2ARC는 너무 크게 설정하면 안됩니다. 그 이유는 L2ARC의 체크섬 등은 램에 저장되는데 램에 비해 L2ARC가 너무 클 경우 램이 부족해 스왑이 발생해 성능이 떨어질 수 있기 때문입니다. 일반적으로 소규모 개인 NAS 수준에서는 그다지 사용할 일이 없습니다.
추가 설명
ZFS의 개념과 용어, 기능과 주의점을 설명했습니다. 몇가지 추가 설명이 필요한 것이 있어 추가 서술합니다.
ECC 메모리
과거 ZFS는 ECC메모리를 필수로 요구한다는 이야기가 포럼에 돌았던 적이 있습니다. 요지는 scrub 작업 시 메모리 오류가 발생할 경우 데이터가 손상이 된다는 것이였습니다. 과연 이 얘기는 사실일까요? 그렇다면 반드시 ECC를 사용해야만 할까요?
결론부터 말하자면 아닙니다.
메모리 오류로 scrub of death 문제가 발생할수 있다고 하는데, 이는 사실이 아니며 메모리 오류로 인한 문제는 ECC 메모리를 사용하지 않는 모든 파일 시스템과 프로그램에서 발생합니다. 하지만 그 때문에 데이터가 손상되고 컴퓨터가 파괴되지는 않습니다. ZFS는 다른 파일 시스템보다 특별히 더 ECC메모리를 요구하지는 않습니다.
하지만 ZFS를 사용하는 이유 중 하나가 데이터 무결성이라는 것을 감안하였을 때 ECC 메모리는 좋은 선택입니다.
ECC 메모리는 선택입니다. 쓰면 좋지만, 그렇지 않아도 상관없습니다.
ARC
위에서 서술한 ARC 크기 규칙 (1Tb 의 저장 공간 = 1Gb 의 ARC) 는 개인 레벨에서는 딱히 지키지 않아도 된다고 하였습니다. 이유는 대역폭 때문입니다. 보통 개인 서버를 구성한다면 1Gbps 이더넷 포트를 1~2개 사용할 것이고, 그렇다면 최대 대역폭은 1~2Gbps 일 것입니다. 이걸 기가바이트로 환산하면 128~256Mb/s 이고, 각종 오버헤드를 감안하면 100~200Mb/s 정도의 속도가 나올 것입니다. 그런데 요즘 나오는 하드 디스크의 RW 속도는 120Mb/s 이상이고, 당연히 레이드를 구성하면 더 빠른 RW 속도를 낼 수 있습니다. 궂이 캐시를 사용하지 않더라도 클라이언트 측에서는 네트워크의 최대 대역폭을 사용하고 있는 셈입니다. 부하가 큰 환경이 아니라면, 그러니깐 ZFS의 능력을 최대한 발휘해야 할 상황이 아니라면 ARC크기 규칙을 반드시 지킬 필요는 없습니다.
필자의 경우는 ARC 크기를 3Gb~4Gb 로 제한하여 사용하고 있습니다. ARC를 완전히 끄는 것은 성능에 부정적인 영향을 끼칠 수 있기 때문입니다. ARC 크기를 제한하는 방법은 ‘기본 환경 구성하기’ 에서 다룹니다.