 Print-friendly Version
ZFS - Sun 의 최신 파일 시스템(파트 1: 저장소의 무결성, 안전성 및 확장성)파트 2: 관리의 간소화와 차후 개발Amy Rich, 2006년 8월
목차 : ZFS의 개요Solaris 10 06/06 운영 체제에 새로 추가된 ZFS는 이전의 UNIX 파일 시스템을 완전히 재설계한 혁신적인 제품입니다. Sun의 기술자와 오픈 소스 커뮤니티의 멤버는 현재 시장의 최선 사례 중에서 몇 가지(Network Appliance 의 스냅샷, VERITAS 객체 기반 저장소 관리, 트랜잭션, 체크섬 등)를 추려내 각 아이디어와 전문 지식을 제공함으로써 파일 시스템을 설계하기 위한 새롭고 능률적이며 결합력이 있는 접근 방법을 개발했습니다. 아직 라이프사이클의 초기임에도 불구하고 ZFS는 다른 UNIX 공급업체와 오픈 소스 신봉자가 자신들의 고유한 운영 체제에 그것을 이식할 계획을 미리 암시할 정도로 큰 영향을 주고 있습니다(OpenSolaris 사이트의「Porting ZFS to other platforms」를 참조). ZFS를 이용하여 Sun은 다른 UNIX 파일 시스템의 고민거리였던 무결성, 안전성, 확장성, 그리고 관리의 어려움이라는 중요한 문제를 다루고 있습니다. 여기에서는 2개의 파트로 나누어 ZFS 동작의 무대 뒤편과 ZFS를 기업의 시간과 경비 절약으로 연결하는 방법에 대해 고찰합니다. 파트 1에서는 데이터의 무결성과 안전성 모델, 그리고 ZFS의 확장성에 관해 설명하겠습니다. 파트 2 에서는 관리의 간소화와 ZFS의 차후 개발에 대하여 다루겠습니다. ZFS 데이터의 무결성과 안전성파일 시스템의 가장 중요한 구성요소는 데이터의 무결성과 안전성입니다. 디스크의 정보가 비트 손상, 숨겨진 파손, 인위적인 또는 우연한 변조를 겪지 않는 것은 매우 중요합니다. 지금까지 파일 시스템은 이런 난제를 극복하고 신뢰성 있는 정확한 데이터를 제공하기 위한 여러 가지 문제를 안고 있었습니다. 이전 릴리스 UFS 등 옛 기술로 구축된 파일 시스템은 사용 중인 데이터를 변경할 때 블록을 덮어쓰기합니다. 쓰기 중에 전원 장애가 발생하면 쓰던 데이터는 파괴되고, 파일 시스템은 중요한 데이터에 대한 블록 포인터를 잃을 가능성이 있습니다. 이 문제에 대처하기 위해 신뢰성을 위해 사람들은 어떤 종류의 볼륨 관리 소프트웨어를 사용하여 디스크 또는 파일 시스템을 미러링하였습니다. 정전이 발생하여 미러링된 양쪽이 일치하지 않게 되면 의심스런 블록이 아주 조금만 있어도 미러의 한쪽은 다른 한쪽과 다시 동기화합니다. 재동기화 중에는 입출력 성능이 저하될 뿐 아니라, 시스템은 파괴되지 않은 복사 데이터를 항상 정확하게 예측할 수 있는 것은 아닙니다. 틀린 미러를 신뢰하여 선택하거나 틀린 데이터로 올바른 데이터를 덮어쓰기하기도 합니다. 성능 문제에 대처하기 위해 볼륨 관리자 중에는 더티 영역 로깅(DRL)으로 알려져 있는 기능을 도입한 것도 있습니다. 이 경우 정전이 발생한 시점에 데이터 쓰기를 행하던 영역만 재동기화할 필요가 있습니다. 이 작업은 성능 문제를 경감시켜 주지만 어느 미러가 올바른 데이터인지 탐지하는 문제에는 대처할 수 없습니다. ZFS에서는 트랜잭션 기반 변경 시 복제를 행하고, 파일 시스템 내에서 사용 중인 각 블록의 체크섬을 항상 계산함으로써 이 문제에 대처하고 있습니다. 트랜잭션 기반 변경 시 복제 조작 ZFS는 파일 시스템과 볼륨 관리자를 조합한 것이며, 저장소 풀의 가상화 때문에 파일 시스템 수준의 명령은 배후의 물리 디스크 개념을 필요로 하지 않습니다. 모든 고수준 대화가 데이터 관리 장치(DMU)를 통해 발생하고, DMU 개념은 메모리 관리 장치(MMU)와 유사하며 RAM 대신에 대상이 디스크 뿐입니다. DMU 를 통해 넘어온 모든 트랜잭션은 불가분이므로 데이터가 일치하지 않는 상태에 처할 일은 결코 없습니다. 트랜잭션 기반 파일 시스템이라는 것 이외에 ZFS는 변경 시 복제 조작만을 실행합니다. 이것은 디스크의 사용 중인 데이터를 포함하는 블록은 결코 변경되지 않는 것을 의미합니다. 변경된 정보는 대체 블록에 쓰이며, 사용 중인 데이터에 대한 블록 포인터는 쓰기 트랜잭션 완료 후에 이동될 뿐입니다. 이것은 「uberblock」으로 불리는 최상위 블록까지 파일 시스템 블록 구조 전체에서 행해집니다. 그림 1에 보이는 것처럼 변경된 데이터를 쓰기 위해 트랜잭션은 사용되지 않은 블록을 선택한 다음, 앞서 말한 블록 포인트로 위치를 변경합니다.
그림 1: 변경 시 복제 트랜잭션 변경 시 복제 중에 시스템 전원 이상이 발생할 경우, 「올바른」 데이터를 가리키는 포인터는 쓰기가 모두 완료될 때까지는 이동되지 않기 때문에 파손이 일어나지 않습니다. (주의 : 이동되는 것은 데이터에 대한 포인터 뿐입니다.) 이로 인해 파일 시스템 저널링 또는 로깅이 불필요해지므로 시스템이 예기치 않게 재부팅했을 때 종단 간 체크섬 뜻하지 않은 데이터 파괴를 막기 위해 ZFS는 메모리 기반 종단 간 체크섬을 제공합니다. 체크섬을 행하는 대부분의 파일 시스템은 블록 그 자체와 함께 체크섬이 저장되는 일관성 있는 블록을 사용하고 있기 때문에 비트 손상을 막을 뿐입니다. 이 경우 정당성을 검증하기 위한 외부적인 검사는 행해지지 않습니다. 이 형식의 체크섬에서는 다음과 같은 것은 파악할 수 없습니다.
ZFS에서는 체크섬은 블록 안이 아닌 블록에 대한 포인터 근처에 저장되며 uberblock까지 행해집니다. uberblock 만은 자기 타당성 검사를 실시하는 SHA-256을 가지고 있습니다. 모든 블록 체크섬은 서버 메모리 내에서 행해지므로 앞에서 말한 잘못된 지시에 의한 읽기나 쓰기, 패리티 오류, 실체가 없는 쓰기 등을 포함하는 트리 전체의 모든 오류를 파악할 수 있습니다. 이전에는 CPU에 부하가 걸려 시스템을 다운시키는 일도 있었지만 최근에는 처리 중에 디스크 트랜잭션을 체크할 수 있을 정도로 CPU 기술과 속도가 향상되고 있습니다. ZFS가 이러한 문제를 잡아낼 뿐 아니라 미러화된 구성 또는 RAID-Z 구성에서도 데이터는 자가 치유를 행합니다. (이 시리즈의 2번째 글에서 RAID-Z에 대해 더욱 자세히 다룰 예정입니다.) 자가 치유를 소개할 때 자주 사용되는 Sun 데모 중 하나는 다음의 dd if=/dev/urandom of=/dev/dsk/c0t1d0s5 bs=1024 count=100000 이것은 한쪽 미러에 가비지 데이터를 쓰지만, 그 블록이 액세스되면 ZFS는 체크섬을 실행하여 그 데이터가 잘못된 것을 인식합니다. 그 후 데이터 파괴로 인한 혼란에 빠지지 않은 채, ZFS는 다른 쪽 복제 데이터에 체크섬을 실행하여 그것이 올바르다고 판단하고, 파괴된 미러에 있는 잘못된 블록의 「재동기화」를 실행합니다. RAID-Z 구성에서 ZFS는 각 디스크의 블록을 차례로 체크하여 일치할 때까지 패리티 체크섬을 비교합니다. 일치하면 ZFS는 올바른 데이터 블록이라고 판단하여 다른 모든 잘못된 디스크를 수정합니다. 재동기화 처리는 사용자에게 완전히 투명하기 때문에 사용자는 문제가 발생한 것을 인식조차 하지 못합니다. ZFS는 항상 스크러빙이라는 처리를 통해 백그라운드에서 데이터가 파괴되었는지 여부를 체크합니다. 디스크 스크러빙에 사용되는 파일 시스템 코드는 재동기화, 미러 접속, 디스크 교환에 사용되는 것과 같은 코드로, 프로세스 전체를 확실히 통합시킵니다. 관리자는 #zpool scrub testpool
#zpool status
pool: testpool
state: ONLINE
scrub: scrub completed with 0 errors on Thu Jun 29 12:47:15 2006
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
미러의 파괴된 부분에 대해 앞에서 말한 #zpool scrub testpool
#zpool status
pool: testpool
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool online' or replace the device with 'zpool replace'.
다음을 참조하십시오. http://www.sun.com/msg/ZFS-8000-9P
scrub: scrub completed with 0 errors on Thu Jun 29 12:51:29 2006
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 5 2.50K repaired
mirror ONLINE 0 0 0
c0t0d0s6 ONLINE 0 0 0
c0t1d0s6 ONLINE 0 0 0
출력이 여기서 보고하는 내용은 다음과 같습니다.
출력은 다음 정보도 더불어 제공하고 있습니다.
상세한 설명은「ZFS 미러 재동기화에 관한 Jeff Bonwick의 blog entry」를 참조하십시오. ZFS 안전성으로 인한 또 하나의 이점은 다음과 같습니다. 완전한 허가 및 거부 어휘와 계승을 포함한 NFSv4/NT 형식의 ACL을 사용합니다. 서로 다른 17가지 속성에 근거한 액세스 제어는 매우 세밀하게 되어 있습니다. ZFS의 확장성데이터의 안전성과 무결성이 매우 중요함과 동시에, 파일 시스템은 적절히 기능하고 시간의 시련을 견딜 필요가 있으며, 그렇지 않으면 널리 사용되지 않을 것입니다. ZFS 설계자는 128비트 구조를 사용하여 모든 메타 데이터를 동적으로 함으로써 현재의 파일 시스템이 안고 있는 한계를 해소하거나 대폭 감소시켰습니다. 또한 ZFS는 성능을 향상하기 위해 데이터 파이프라인, 동적 블록 사이즈, 지능형 미리 읽기, 동적 스트라이핑 및 내장형 압축을 실행하고 있습니다. 128비트 구조 업계의 최근 동향을 보면 디스크 드라이브 용량은 9개월부터 1년마다 약 2배가 되고 있습니다. 이 동향이 계속된다면 앞으로 10년에서 15년 정도 안에 파일 시스템은 64비트 주소 지정 능력이 필요해질 것입니다. 64비트 요건으로 계획하는 대신 ZFS의 설계자들은 장기적으로 생각하여 128비트 파일 시스템을 실현했습니다. 이것은 ZFS가 현재의 64비트 시스템보다 160억 배 이상의 용량을 제공할 수 있다는 것을 의미합니다. ZFS의 최고 설계자 Jeff Bonwick는 「ZFS:the last word in file systems」에서 「128비트 파일 시스템을 실행함으로써 지구 기반 저장소의 양적인 한계를 넘을 것이다. 바다라도 끓어오르지 않는 한 128비트 저장소 풀을 채우는 건 불가능할 것이다.」라고 기술하고 있습니다. Jeff는 또한 「128-bit storage」에 관련된 자신의 블로그 항목에서 이 글 뒤에 수학에 대해서도 논하고 있습니다. 우리는 시장에 적용할만한 이런 종류의 에너지를 낳는 기술을 아직 가지고 있지 않기 때문에 당분간은 안전할 것이다. 동적 메타데이터 128비트라는 것과 더불어 ZFS의 메타데이터는 100% 동적입니다. 때문에 새 저장소 풀과 파일 시스템은 매우 빠르게 작성됩니다. 디스크 쓰기의 1 ~ 2%만이 메타데이터이며, 이로 인해 초기의 오버헤드는 대폭으로 삭감됩니다. 예를 들어 정적이지 않은 i 노드가 있다면 그 유일한 제약은 저장소 풀 디스크에 들어가는 i 노드의 수입니다. 128비트 구조는 또한 파일, 디렉토리 등의 수에 실질적인 제한이 없다는 것을 의미합니다. 논리상의 제한은 있지만 그 크기를 상상할 수 있다면 매우 놀랄 것입니다.
파일 시스템 성능 ZFS의 기본 설계로 인해 예전 파일 시스템과 비교해서 수많은 성능 확장 기능이 제공되고 있습니다. 우선 ZFS는 CPU 파이프라인 개념과 비슷한 파이프라인 접속의 입출력 엔진을 사용하고 있습니다. 이 파이프라인은 입출력의 상호의존성을 바탕으로 동작하며, 상대적인 우선 순위와 최종 기한에 근거하여 정렬할 수 있습니다. 이 파이프라인은 기록 게시판, 우선 순위, 최종 기한 예약, 순서 변경 실시 및 입출력 집계를 제공합니다. 또한 ZFS는 액세스 패턴이 선형인지 알고리즘적인지를 인식하여 근처 블록을 추측해 미리 읽는 지능형 미리 읽기 알고리즘을 실행하고 있습니다. 가능할 때는 언제든 속도를 올릴 수 있도록 ZFS는 병행처리를 적용하고 있습니다. 이 파일 시스템은 병렬된 고정 속도 디렉토리 처리뿐 아니라 같은 파일에 대한 병렬의 읽기와 쓰기를 보조하며, 그 잠금 방식은 가변적이고 빠릅니다. 게다가 트랜잭션 내의 모든 처리는 임의의 순서대로 실행할 수 있으므로 DMU 배치는 디스크 동작을 최적화하도록 읽기 및 쓰기를 행합니다. 트랜잭션은 변경 시 복제이기 때문에 디스크를 랜덤으로 액세스하는 것이 아니라, 새로운 데이터에 대해 연속된 블록을 선택할 수 있습니다. 이로 인해 디스크는 원판과 같거나 그에 가까운 속도로 동작할 수 있습니다. 또한 ZFS 는 최적 성능을 달성하기 위해 블록 사이즈 (512바이트에서 128KB)를 작업 부하에 자동적으로 적합화합니다. ZFS는 사용 가능한 모든 장치 사이에서 데이터를 동적으로 스트라이프화합니다. 다른 디스크나 조각을 스트라이프에 추가할 경우 ZFS는 자동적으로 새로운 공간을 만들고 새로운 스페이스를 살리기 위해 쓰기 스트라이프의 균형을 다시 잡습니다. 오류 때문에 장치가 기능 저하 모드에 빠질 경우 ZFS는 가능한 한 그 장치에 대한 쓰기를 행하지 않게 하고, 대신 다른 장치들에 부하를 분산시킵니다. 마지막으로, ZFS는 파일 시스템별로 내장형 데이터 압축을 제공합니다. 압축은 디스크 소비 공간을 삭감할 뿐만 아니라, 입출력의 필요 횟수를 2배에서 3배나 감소시킬 수 있습니다. 때문에 작업 부하가 CPU 바운드가 아닌 I/O 바운드이면, 압축을 활용함으로써 실제로 몇 개의 작업 부하 처리 속도가 높아집니다. ZFS 벤치마킹에 관한 정보는 다음 페이지를 참조하십시오.
다음 글에서는 더욱 실천적인 ZFS 사용, 저장소 풀과 파일 시스템 작성, 파일 시스템 파라미터 설정, 데이터 스냅샷과 복제에 대해 다룰 예정입니다. 그리고 ZFS 개발에서 실현이 코앞에 다가온 흥미진진한 몇 가지 기능을 소개하겠습니다. 관련 정보
여기서 다룬 모든 기술 매뉴얼 내의 코드 (글, FAQ, 샘플을 포함)는 특별한 사용권 제공이 없는 한 이 사용권 하에 제공되고 있습니다. |
 BigAdmin SubscriptionsBigAdmin Areas
BigAdmin Sun Center
BigAdmin Topics | ||||
 | |
