 Print-friendly Version
ZFS - Sun의 최신 파일 시스템(파트 2: 관리의 간소화와 차후 개발)파트 1: 저장소의 무결성, 안전성 및 확장성 Amy Rich, 2006년 9월
목차 : 소개ZFS - Sun의 최신 파일 시스템(파트 1:저장소의 무결성, 안전성 및 확장성) 라는 이 2부 시리즈의 첫 기사에서는 Sun의 획기적인 새 파일 시스템의 개요를 소개하고, 데이터의 무결성, 안전성 모델과 그 방대한 확장성에 대해서도 설명했습니다. 이번 기사에서는 실제 사용 데모와 다음 릴리스에 계획된 자극적인 새 기능 몇 가지를 포함시켜 관리의 용이성에 초점을 맞추겠습니다. ZFS는 무결성과 신뢰성이 뛰어나고 성능도 우수하며 더불어 안전성도 뛰어나지만, 관리의 용이함은 어떨까요? 시스템 관리자로서 우리는 파일 시스템을 이것저것 조절하며 극한까지 성능을 끌어낼 필요가 있는 입장에 서 있습니다. 어쩌면 2번째의 미러 부팅 가능 디스크를 작성하지 않은 채 VxVM를 설정하는 어려운 방법을 찾아냈을지도 모릅니다. 올바른 비밀 주문을 알아야 하는 게 아니라, 적절한 작업을 수행하는 파일 시스템이나 볼륨 관리자가 있다는 것이 근사하지 않겠습니까? 사용자는 운이 좋습니다. ZFS 엔지니어가 사용자를 고려하여 개발했습니다. 객체 기반 저장소ZFS는 객체 기반 저장소에 관한 모든 것을 포함하고 있습니다. 볼륨 관리자의 저장소 풀을 구축하는 기본 블록은 zpool - configures ZFS storage pools zpool create [-fn] [-R root] [-M mountpoint] pool vdev... zpool add [-fn] pool vdev... zpool list [-H] [-o field[,fi] [pool] ... zpool status [-xv] [pool] ... zpool destroy [-f] pool zpool iostat [-v] [pool] ... [interval [count]] zpool attach [-f] pool device new_device zpool detach pool device zpool replace [-f] pool device [new_device] zpool scrub [-s] pool ... zpool offline pool device ... zpool online pool device ... zpool export [-f] pool zpool import [-d dir] zpool import [-d dir] [-f] [-o options] [-R root] pool | id [newpool] zpool import [-d dir] [-f] [-a] 이제 실례를 이용해 스스로 해 봅시다. 먼저 2개의 슬라이스를 미러링하여 # zpool create testpool mirror c0t0d0s5 c0t1d0s5
# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
testpool 7.94G 164K 7.94G 0% ONLINE -
# zpool status
pool: testpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
testpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s5 ONLINE 0 0 0
c0t1d0s5 ONLINE 0 0 0
저장소 할당이 끝났으므로 파일 시스템을 만들 수 있습니다. ZFS의 파일 시스템은 계층형이며, 그로 인해 관리 제어가 유용합니다. 파일 시스템마다 설정할 수 있는 것은 사이즈, 예약(데이터 집합과 그 자손에 대해 보증되는 최소 용량), 할당, 압축 선택, 백업 및 스냅샷입니다. 예를 들어 홈 디렉토리 서버에 누구라도 자신의 파일 시스템을 얻을 수 있고, 그곳에서는 합계 사용 용량을 1TB까지 제한하여 압축을 유용하게 활용할 수 있습니다. 게다가 특정 VIP 사용자 (또는 응용 프로그램)가 항상 적어도 1GB를 이용할 수 있도록 하여 매시간마다 (크론을 통해) 스냅샷을 만들 수 있습니다. 중요도가 낮은 사용자는 할당을 제한하거나 하루에 1번만 스냅샷을 만들 수 있습니다. 다음으로 zfs create filesystem zfs create [-s] [-b blocksize] -V size volume zfs destroy [-rRf] filesystem|volume|snapshot zfs clone snapshot filesystem|volume zfs rename filesystem|volume|snapshot filesystem|volume|snapshot zfs snapshot filesystem@name|volume@name zfs rollback [-rRf] snapshot zfs list [-rH] [-o property[,property]...] [ -t type[,type]...][filesystem|volume|snapshot] ... zfs set property=value filesystem|volume... zfs get [-rHp] [-o field[,field]...] [-s source[,source]...]all | property[,property]... filesystem|volume|snapshot... zfs inherit [-r] property filesystem|volume... zfs mount zfs mount [-o options] [-O] -a zfs mount [-o options] [-O] filesystem zfs unmount [-f] -a zfs unmount [-f] [filesystem|mountpoint] zfs share -a zfs share filesystem zfs unshare [-f] -a zfs unshare [-f] [filesystem|mountpoint] zfs backup [-i snapshot] snapshot zfs restore [-vn ] filesystem|volume|snapshot zfs restore [-vn ] -d filesystem
# zfs create testpool/testfs # zfs list NAME USED AVAIL REFER MOUNTPOINT testpool 268K 7.88G 99K /testpool testpool/testfs 98.5K 7.88G 98.5K /testpool/testfs # zfs create testpool/testfs2 # zfs list NAME USED AVAIL REFER MOUNTPOINT testpool 376K 7.88G 99.5K /testpool testpool/testfs 98.5K 7.88G 98.5K /testpool/testfs testpool/testfs2 98.5K 7.88G 98.5K /testpool/testfs2 # df -k Filesystem 1k-blocks Used Available Use% Mounted on /dev/md/dsk/d0 8262869 751774 7428467 10% / swap 11800800 784 11800016 1% /etc/svc/volatile /dev/md/dsk/d30 8262869 23616 8156625 1% /var swap 11800016 0 11800016 0% /tmp swap 11800040 24 11800016 1% /var/run testpool 8257771 100 8257672 1% /testpool testpool/testfs 8257770 99 8257672 1% /testpool/testfs testpool/testfs2 8257770 99 8257672 1% /testpool/testfs2 이번에도 하나의 간단한 명령만 사용할 뿐입니다. 각 ZFS 파일 시스템은 풀 내의 모든 리소스에 액세스할 수 있다는 것을 알았을 것입니다. # zfs set mountpoint=/devel/testfs testpool/testfs # zfs create testpool/testfs/dir1 # zfs create testpool/testfs/dir2 # zfs create testpool/testfs/dir3 # df -k Filesystem 1k-blocks Used Available Use% Mounted on /dev/md/dsk/d0 8262869 751774 7428467 10% / swap 11800800 784 11800016 1% /etc/svc/volatile /dev/md/dsk/d30 8262869 23616 8156625 1% /var swap 11800016 0 11800016 0% /tmp swap 11800040 24 11800016 1% /var/run testpool 8257771 100 8257672 1% /testpool testpool/testfs2 8257770 99 8257672 1% /testpool/testfs2 testpool/testfs 16515535 99 16515437 1% /devel/testfs testpool/testfs/dir1 16515214 99 16515115 1% /devel/testfs/dir1 testpool/testfs/dir2 16515214 99 16515115 1% /devel/testfs/dir2 testpool/testfs/dir3 16515214 99 16515115 1% /devel/testfs/dir3 ZFS는 자동적으로 파일 시스템에 몇 가지 속성을 설정하는 예를 다음에 나타냅니다. # zfs set sharenfs=rw testpool/testfs# zfs compression=on testpool/testfs# zfs set quota=10g testpool/testfs/dir1(논리적으로 용량을 제한) # zfs set reservation=20g testpool/testfs/dir2(논리적으로 용량을 사전 할당) 그럼 풀의 용량이 부족해 더 추가하고 싶을 경우엔 어떻게 할까요. # zpool add testpool c0t0d0s6 c0t1d0s6 invalid vdev specification use '-f' to override the following errors: mismatched replication level: pool uses 2-way mirror and new vdev uses 1-way disk ZFS는 똑똑합니다. ZFS는 전에 사용하던 장치가 미러화된 것을 인식하고, 미러화되지 않은 저장소를 추가하려 하는 사실을 파악했습니다. 만약 이것이 정말로 하려고 한 것이라면 위와 같이 # zpool add testpool mirror c0t0d0s6 c0t1d0s6 # zfs list NAME USED AVAIL REFER MOUNTPOINT testpool 396K 15.8G 99.5K /testpool testpool/testfs 98.5K 15.8G 98.5K /testpool/testfs testpool/testfs2 98.5K 15.8G 98.5K /testpool/testfs2 여기에서도 동적 메타데이터 때문에, 새로운 공간을 사용하기 전에 풀이 그 사이즈를 조정하거나 미러가 재동기하는 것을 기다릴 필요는 없습니다. 이 시점에서 # zpool status
pool: testpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
testpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s5 ONLINE 0 0 0
c0t1d0s5 ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s6 ONLINE 0 0 0
c0t1d0s6 ONLINE 0 0 0
RAID-Z지금까지 미러화된 저장소만을 봐왔습니다. ZFS는 RAID-Z로 불리는 다른 타입의 RAID를 실행하고 있으며, 이것은 RAID-5와 비슷하지만 RAID-5 쓰기 홀이라 불리는 RAID-5의 문제를 해결하기 위해서 가변 스트라이프폭을 사용하고 있습니다. RAID-5에서 쓰기는 2개 이상의 독립한 장치에 대해 실행되고 패리티 블록은 각 스트라이프의 구성요소로서 기록됩니다. 이러한 쓰기는 불가분은 아니기 때문에 데이터와 패리티의 트랜잭션 중에 전원 장애가 발생하면 데이터가 파괴될 가능성이 있습니다. 패리티 지역 로깅 (더티 지역 로깅과 같은 것으로, 패리티 디스크만을 대상으로 한다)이나 배터리 백업 NVRAM을 사용하여 이 문제를 다루는 공급업체도 있습니다. NVRAM를 사용한 해결책에서는 데이터가 NVRAM에 기록된 후에 데이터와 패리티가 디스크에 기록되고 마지막으로 NVRAM가 릴리스됩니다. NVRAM는 고가인 데다 병목 현상이 되는 일도 가끔 있습니다. 또한 NVRAM에 저장된 데이터는 3 일 간의 작동 중지 시간 후에 소실됩니다. 장기간에 이르는 장애 복구 상황에서는 이러한 데이터 소실은 용인할 수 없습니다. RAID-5와는 달리 RAID-Z의 모든 쓰기는 스트라이프 전체의 쓰기이며, 이것은 모든 디스크에 대해 쓰기가 행해지는 것을 의미합니다. 읽기·수정·쓰기의 오버헤드도, RAID-5 쓰기 홀도 없으며, 하드웨어에 NVRAM도 필요 없습니다. 스트레이트 미러화나 RAID-Z를 사용하는 시기를 결정하려면 Roch Bourbonnais의 「When to (and not to) use RAID-Z 」블로그 항목을 참조하십시오. 파일 시스템 스냅샷과 복제데이터로 가득한 파일 시스템을 몇 개 가진 경우, 사용자 (또는 시스템 관리자)가 잘못해 무엇인가를 변경 또는 삭제해 버려서 데이터를 복원하고 싶은 경우, 무슨 일이 발생할까요? 백업 테이프나 디스크를 사용하는 것은 시간이 걸릴뿐더러, 사용자가 스스로 쉽게 할 수 있는 것이 아닙니다. 다행히 ZFS에는 스냅샷 기능 (다른 저장소 공급업체가 제공하고 있는 것과 같음)이 구비되어 있으며, 더 좋은 소식은 변경 시 복제 구조 때문에 실질적인 오버헤드가 없다는 것입니다. 실제로 스냅샷을 생성하는 것이 옛 데이터를 포함한 블록을 해제하는 것보다 빠른 경우가 있습니다. ZFS 바탕에서는 Network Appliance사의 실행과 같이 변경된 데이터만이 추적됩니다. 보유할 수 있는 스냅샷 수는 저장소 용량에 따라 제한될 뿐입니다. 스냅샷을 간단히 봅시다. # cd /testpool/testfs2 # ls -al .zfs/snapshot total 0 dr-xr-xr-x 2 root root 2 Jun 29 17:18 . dr-xr-xr-x 3 root root 3 Jun 29 17:18 .. # cp /bin/sh /bin/tcsh /bin/ksh . # zfs snapshot testpool/testfs2@snap1 # ls -al .zfs/snapshot/snap1/ total 786 drwxr-xr-x 2 root sys 5 Jun 29 17:17 . dr-xr-xr-x 3 root root 3 Jun 29 17:19 .. -r-xr-xr-x 1 root other 238332 Jun 29 17:17 ksh -r-xr-xr-x 1 root other 113160 Jun 29 17:17 sh -r-xr-xr-x 1 root other 364176 Jun 29 17:17 tcsh # zfs list testpool/testfs2@snap1 NAME USED AVAIL REFER MOUNTPOINT testpool/testfs2@snap1 0 - 882K -
# rm ksh # ls -al total 514 drwxr-xr-x 2 root sys 4 Jun 29 17:24 . drwxr-xr-x 4 root sys 4 May 22 10:48 .. dr-xr-xr-x 3 root root 3 Jun 29 17:25 .zfs -r-xr-xr-x 1 root other 113160 Jun 29 17:17 sh -r-xr-xr-x 1 root other 364176 Jun 29 17:17 tcsh # cp .zfs/snapshot/snap1/ksh . # ls -al total 787 drwxr-xr-x 2 root sys 5 Jun 29 17:26 . drwxr-xr-x 4 root sys 4 May 22 10:48 .. dr-xr-xr-x 3 root root 3 Jun 29 17:27 .zfs -r-xr-xr-x 1 root other 238332 Jun 29 17:26 ksh -r-xr-xr-x 1 root other 113160 Jun 29 17:17 sh -r-xr-xr-x 1 root other 364176 Jun 29 17:17 tcsh 이와는 별도로, 특정 스냅샷과 일치시키기 위해 파일 시스템 전체의 롤백을 실행해 보겠습니다. # rm ksh # cp /bin/bash . # ls -al total 515 drwxr-xr-x 2 root sys 5 Jun 29 17:28 . drwxr-xr-x 4 root sys 4 May 22 10:48 .. dr-xr-xr-x 3 root root 3 Jun 29 17:28 .zfs -r-xr-xr-x 1 root other 737148 Jun 29 17:28 bash -r-xr-xr-x 1 root other 113160 Jun 29 17:17 sh -r-xr-xr-x 1 root other 364176 Jun 29 17:17 tcsh # ls -al .zfs/snapshot/snap1/ total 786 drwxr-xr-x 2 root sys 5 Jun 29 17:19 . dr-xr-xr-x 3 root root 3 Jun 29 17:28 .. -r-xr-xr-x 1 root other 238332 Jun 29 17:19 ksh -r-xr-xr-x 1 root other 113160 Jun 29 17:17 sh -r-xr-xr-x 1 root other 364176 Jun 29 17:17 tcsh # cd / # zfs rollback testpool/testfs2@snap1 # ls -al /testpool/testfs2/ total 787 drwxr-xr-x 2 root sys 5 Jun 29 17:19 . drwxr-xr-x 4 root sys 4 Jun 29 17:29 .. dr-xr-xr-x 3 root root 3 Jun 29 17:29 .zfs -r-xr-xr-x 1 root other 238332 Jun 29 17:19 ksh -r-xr-xr-x 1 root other 113160 Jun 29 17:17 sh -r-xr-xr-x 1 root other 364176 Jun 29 17:17 tcsh 스냅샷이 더 이상 필요치 않다면 # zfs destroy testpool/testfs2@snap1 # ls -al testpool/testfs2/.zfs/snapshot/ total 0 dr-xr-xr-x 2 root root 2 Jun 29 17:31 . dr-xr-xr-x 3 root root 3 Jun 29 17:31 .. 힌트를 말하자면 대개의 경우 날짜로 스냅샷에 이름을 붙이면 간단히 추적을 행할 때 유용합니다. 스냅샷과 비슷한 또 다른 유용한 기능은 복제입니다. 스냅샷과는 달리 복제 안의 파일은 변경이나 쓰기가 가능합니다. 거의 똑같지만 전혀 같지 않은 데이터 집합을 가진 경우 이것이 무척 유용합니다. 일례로 디스크 없는 클라이언트를 부팅하는 서버를 들 수 있습니다. 다음 예에서는 최초의 디스크 없는 클라이언트에 대해 파일 시스템을 설정하여 스냅샷을 생성하고 스냅샷의 복제를 만든 후 복제한 파일 중 1개를 변경합니다. # zfs create testpool/diskless/nevada( testpool/diskless/nevada에 부팅 가능 파일 시스템을 생성)# zfs create testpool/diskless/sb2500# zfs snapshot testpool/diskless/nevada@snap1# zfs clone testpool/diskless/nevada@snap1 \ testpool/diskless/sb2500/nevada# vi /testpool/diskless/sb2500/nevada/etc/hosts(호스트 이름을 sb2500로 변경하여 저장) 자동 엔디언 적응UFS와 마찬가지로 ZFS는 SPARC와 x64 하드웨어 모두를 지원합니다. UFS와는 달리 포맷이나 엔디언 문제를 걱정할 필요가 없으며, 어떤 구조에서 데이터 디스크를 삭제하고 다른 구조에 추가할 수 있습니다. 데이터 디스크를 SPARC 프로세서로 실행하는 시스템에서 삭제하고 x64 박스에 접속하는 것은 현재 완전히 투과적으로 행해집니다. Sun에서는 이것을 자동 엔디언 적응이라고 부르고 있습니다. 블록이 디스크에서 읽힐 때 ZFS는 엔디언을 확인합니다. 엔디언이 현재 구조와 일치하면 아무것도 변경되지 않습니다. 일치하지 않으면 ZFS는 데이터를 표시하기 전에 파일을 바이트 스왑한 다음 고유의 원시 엔디언으로 블록을 다시 씁니다. 원시가 아닌 아닌 블록 액세스는 다소 오버헤드가 생기지만, 이 블록이 새로운 시스템의 원시 엔디언에서 기록되는 것보다 낮은 빈도로밖에 일어나지 않습니다. 이 엔디언 변환은 ZFS의 메타데이터 블록에만 적용되고 사용자 데이터에는 적용되지 않는 것에 주의하십시오. 데이터 디스크를 어떤 시스템에서 다른 시스템으로 옮기는 경우 우선 물리 미디어의 모든 풀을 내보내고 디스크를 분리하고 그것을 새 시스템에 붙인 후에 풀을 가져옵니다.
내보내기 중, 사이즈, 할당, 예약, NFS 내보내기 가능 등의 파일 시스템 메타데이터는 모두 저장되고 디스크와 풀은 논리적으로 시스템에서 삭제됩니다. 새로운 시스템에 데이터를 가져올 때 특정 풀을 지정하는 것도 위와 같이 ZFS의 차후 개발지금까지 본 것처럼 시간과 비용을 절약하기 위한 많은 기능이 이미 ZFS에 들어 있습니다. 그러나 물론 프로젝트는 종료되지 않았습니다. 더욱 훌륭한 기능이 실현되려 하고 있습니다. 최근의 ZFS 토픽 중 하나는부팅 가능 ZFS로 이 하위 프로젝트는 현재 OpenSolaris에서 진행 중입니다. 현재 모험심이 풍부한 기술자들은 ZFS Mountroot에 대한 Tabriz Leman의 블로그 항목의 지시에 따라 UFS shim을 사용하여 x64 상의 ZFS 루트 파일 시스템에 부팅할 수 있습니다. GRUB을 부트 로더로 이용하는 것을 SPARC OBP에 전함으로써 SPARC 기술에 근거해 실행하는 시스템에 곧바로 ZFS의 부팅 가능성을 추가하는 것에 대해 Sun은 이야기를 나누어 왔습니다. ZFS 부팅은 zfs-discuss 메일링 리스트에 있는 Jeff Bonwick의 메시지에서도 논의되고 있습니다. 「[zfs-discuss] Re: Re: 부팅 가능 ZFS와 라이브 업그레이드」 여러 사람이 파일 시스템을 쉽게 백업하기 위해 ZFS 스냅샷을 사용해 왔지만, 앞으로는 스냅샷과 실제로 시판되고 있는 백업 소프트웨어가 한층 더 긴밀히 통합될 것입니다. 스냅샷 동작 방법에 관한 코드 수준 논의에 대해서는 스냅샷에 관한 Matthew Ahrens의 블로그 항목을 참조하십시오. Eric Schrock의 부팅 가능 ZFS와 라이브 업그레이드에 관한 zfs-discuss의 투고에 의하면, ZFS 복제를 사용한 라이브 업그레이드를 지원할 계획이 있습니다. 이것이 실현되기 위해서는 인스톨과 업그레이드 툴이 우선 변경되고 ZFS는 또한 네트워크 및 물리 미디어의 안전성에 대해서도 다루고 있습니다. OpenSolaris의 ZFS의 디스크상 암호화 지원 프로젝트에서는 ZFS에 대한 디스크상 암호화와 복호화 및 키 관리 지원을 제공하는 대응이 진행 중입니다. Darren Moffat는 opensolaris.org 를 향한ZFS 암호화 프로젝트 초안에서, 계획되어 있는 실행의 다양한 국면에 대해 자세히 말하고 있습니다. 목표는 신뢰할 수 없는 경로를 거쳐 SAN에서 제공된 데이터를 보호하고, 물리적인 저장소 도난에서 데이터를 보호하며, 안전한 삭제 메커니즘을 제공하는 것입니다. 한 번 키를 잃으면 그 데이터를 검색할 방법이 없기 때문에, ZFS의 암호화된 파일 시스템 키를 파괴하는 것은 안전한 삭제 방법으로 기능합니다. 실현이 코앞에 다가온 그 외의 안전성 기능 중 하나로, DOD 준거의 안전한 삭제가 있습니다. 이 시나리오에서는 블록이 해제되자마자 여러 차례 덮어쓰기 됩니다. 이러한 대응에 관한 최신 정보를 얻으려면 opensolaris.org 웹사이트에 접속하여 zfs-discuss 또는 zfs-code 메일링 리스트에 참가해주십시오. 관련 정보
여기서 다룬 모든 기술 매뉴얼 내의 코드 (글, FAQ, 샘플을 포함)는 특별한 사용권 제공이 없는 한 이 사용권하에 제공되고 있습니다. |
 BigAdmin SubscriptionsBigAdmin Areas
BigAdmin Sun Center
BigAdmin Topics | ||||
 | |