::: Dragon's Tail :::

Symantec 에서 Veritas Volume Manager 를 매우 주요하게 사용하고 있다는건

왠만한 사람들은 다들 알고 있는 얘기일 것이다.

요즘 Filesystem I/O test 를 하면서 dd 만큼 간편하고, Iozone 이나 Bonnie++

만큼 상세한 설정이 가능한 Test 툴이 없을까 고민하던차에,

Symantec 민 모 과장님께서 Netbackup 의 I/O Test 를 좀 해서 결과를 보내달라는

요청을 받게 된다... 

volume manger 의 Bench marking 툴을 이용해서 말이다!!! 두둥!!!!

그것은 다름아닌 vxbench 라는 툴이다..

이것은 Vertas 의 패키지로써, RedHat 과 Suse 의 RPM 패키지 형식으로

제공되며 패키지명은 VRTSspt-5.6 라고 한다.

/opt 에 설치가 되며 여기서 제공하는 도구들은 Veritas Volume (vxFS) 의

Optimazing ( Reclaim ) 도구와 Meta data 정리 도구, 그리고 vxBench 등을 제공한다.

소개는 여기까지만 하고 한번 내용을 살펴보도록 하자.

간단하다.



다음과 같이 Redhat 과 Suse 를 지원하는 바이너리 파일이 설치되어 있다.

help Output 을 확인 해 보자.


봐라 IOzone 등이 갖고 있는 기능을 다 갖고 있으면서도 오히려 더 짧고 직관적인

옵션을 통해 많은 테스트를 할 수 있도록 되어 있다고 생각되지 아니하지 않을수가 없지 않은가!

실제로 테스트가 불가능한 옵션 조합이나, 환경일 경우엔 벤치마킹을 할 수 없는

환경 및 대상이라는 메시지를 뿌려주기도 한다!
(예를 들어 Direct 옵션을 줬는데 디바이스명을 주지않고 파일명을 준다던가..)

이걸 통해 나오는 결과치의 모습을 보자.


간단하다 이건 마치 dd 만 친것과도 같은 심플한 결과치!

이걸 이용해 간단하게 엑셀로 BtrFS vs XFS vs EXT4 에대한 그래프를 만들어 보았다.

테스트 조건은 1G 파일을 bzise 만 달리하여 500번의 Write 를 수행한 결과이다.

아래는 응답시간(처리시간)에 대한 그래프이다.

아래는 Chunk Size 를 512k 로 주었을 때이다 ( 작은파일 )

4번째 시퀀스에선 약간 Disk Spindown 현상이 발생했긴 한데, 무시하자 귀찮다..

일단 Josef Bacik 이라는 RedHat 에 근무하는 개발자가 작성한 기사에 있는

성능그래프이다.

아래는 512k 의 작은 파일을 16개의 Thread 테스트를 한 그래프이다.

좀 더 자세하게 살펴보자. 아래부터는 내가 각 파일시스템마다 직접 내 랩탑에서

Bonnie++ 로 테스트한 결과이다.

Default 로 Chunk Size 는 8k 이며, 8G 의 파일을 1024*100 번 수행하였다.

- BtrFS

- XFS

- Ext4

확실히 쓰기면에선 전반적으로 BtrFS 가 떨어짐을 알 수 있었으나, (Sequential Output)

Random Create 쪽에선 XFS 보다 훨씬 뛰어난 성능을 보여주고 있다.

아직까진 BtrFS 의 성능부분이 이슈가 되고있긴 하지만, 일단 작은 파일들의

Access 나 Random Seek 부분에서 뛰어난 성능을 보여주고 있음을 알 수 있다.

일단 이것 테스트만해도 몇시간이나 걸렸으니 스냅샷기능을 제공하는

ZFS 와의 비교는 다음으로 미뤄야 겠다.

1. Intro

BtrFS 는 Ohad Rodeh 의 B-Tree 자료구조를 바탕으로 만들어진 파일시스템이다.

Ohad Rodeh 라는 아저씨는 원래 IBM 에서 근무하고 있다가, B-Tree 자료구조의

단점을 극복한뒤 Linux File and Storage Workshop 2007 에서

새로운 Btree 구조를 발표 하고 오라클로 옮겨간다음에

그쪽에 있던 여러 파일시스템개발자들이랑

죽이 맞아 열심히 개발하게 된 것인다....
(암튼 유명하다...)

이것은 리눅스에서 보다 낳은 효율적인 스토리지 관리와 무결성을

보장하기위해 개발되어 졌다.

이녀석은 Raid 기능, 스냅샷, 데이타 압축, 암호화 기능 같은

고급 기능들을 내장하도록 설계되어 졌고, Checksum 을 통해

모든 메타데이타들과 데이타들을 확인 할 수 있고 또는 선택 할 수 있게 만들어졌단다.

이번 포스팅에서는 사실 그냥 간단하게 BtrFS 가 갖고 있는 기능들과,

그것들이 앞으로의 미래에 어떤 영향을 주게 될건지에 대한 소개정도만 할 예정이다.

원래 오래전부터 스토리지에 대한 관리부분은 리눅스에서 지원되지 않고 있었다.

고작 전통적인 mdadm 이나 dmraid 를 이용해 소프트웨어 레이드를 구성하는정도뿐..

그나마 LVM 이 도입되면서부터 일반적인 스토리지풀에서부터 가능한 논리적 디스크그룹으로

나누어 하나의 스토리지 풀에서 기본적인 매니지먼트가 가능하게 되었다.

그러나 이방법은 스토리지에 대한 설정이 변경이 필요 할 경우 복잡한 과정을

겪어야 한다는 단점이 존재했다.

예를들어, Home 디렉토리에 공간을 추가하기위해 논리디스크를 추가하려고 하면,

우선적으로 디스크 초기화(pvcreate) 를 하고, LVM Volume 그룹에 디스크를 추가 한 후,

논리볼륨을 extend 한 뒤, 파일시스템의 resizing 을 해주어야만 최종적인 확장이 가능하다.

BtrFS 의 목적은 이 모든 과정들을 수정하는 것에 있다.

BtrFS 의 경우 확장을 요구할 경우엔 매우 간단하게 한줄의 명령어로  이루어 진다.

비슷한 예로 스냅샷에 대해서도 얘기 할 수 있다.

LVM 을 사용하면, 볼륨그룹에서부터 남은 공간이 얼마나 있는지 확인이 필요하고,

가득 찬 상태라면 스냅샷을 생성한 볼륨등이 deactive 되어 접근 할 수 없게

되어버리지만, BtrFS 의 경우 남은 공간에 제약은 여전하지만,

간단하게 df 를 통해 남은 공간을 확인 하기만 하면 되고, Snapshot 을 찍는데

들어가는 용량 비용은 물론 시간또한 거의 소모되지 않는다.


2. B-Tree 에 대해서.

BrtFS 는 여러개의 B-Tree 로 메타데이타를 분할한다.

B-Tree 는 하나 또는 그 이상의 노드나 가지들로 구성되어 있고,

정보는 각 트리에 원본 키값과 함께 저장되어 진다.

노드들은 최소한의 키를 갖게되며, 다음 하위 레벨에서 노드 또는 Leaf 에

디스크위치를 저장하고, 실제 데이타는 또 다른 각 잎들에 저장되게 된다.

뭐 대략적으로 B-Tree 에 대해서 특징들만 설명하자면,

연결된 노드들과 각 노드들이 갖고있는 leaf 레벨에서 연결정보와

최소한의 데이타만 보유 한뒤 연결점들을 통해 인접한 Data 에 대한

빠른 접근을 가능하도록 하는게 특징이라고 할 수 있다.

쉽게 말해서 인접한 트리들과 인접한 정보들을 나무의 나뭇잎과 같이

가지들로 잘 연결시켜 놓았기때문에, 작은 파일들에 대한 검색에 대해서

매우 빠른 결과와 잇점을 가져 갈 수 있다는 얘기!!!

자세한건 자료구조쪽에대해서 따로 살펴보라 오래되서 생각잘 안난다 ㅡ,.ㅡ

자 그럼 왜 BtrFS 라는 이름을 갖고 있게 된건지 알 수 있을것이다.

말그대로 B-tree File System 이라는 것이다.

외국에서 이걸 부를때 Butter (버터) FS 라고 부르면 된다고 정의되어있다!!!

즉, BtrFS 로 생성되는 파일시스템은 다음과 같은

여러가지의 B-Tree 알고리즘의 조합된 구조들로 구성된다.



이렇게 파일시스템에서 필요로하는 모든 구조체(?) 들을

B-Tree 알고리즘으로 관리하겠다는 얘기!!

그리고 이렇게 다양한 B-Tree 알고리즘의 집함으로 인해

유연성을 확보 할 수 있게 된것이라는 말씀...


3. Snapshot ??

BtrFS 의 스냅샷은 매우 간단하다.

BtrFS 의 스냅샷은 snapshotted 이라는 따위 이름의 일반적 디렉토리 아래

그냥 디렉토리처럼 위치한채, 일반 디렉토리들처럼 자유롭게 이동 및 탐색이 가능하다.

기본적으로 모든 스냅샷은 쓰기가능하도록 되어있는데, 읽기만 가능하도록 할 수도 있다.

이 스냅샷은 매우 유용하고 뛰어난 활용이 가능한데,

예를들어 단순히 백업 후 바로 완료된 백업들을 지우고자 할때는

읽기전용 스냅샷으로 보관을 하여 일반적으로 사용 할 수 있고,

시스템을 업데이트할때 오류가 발생될 가능성이 있으므로 쓰기가능 스냅샷을 찍은뒤,

오류가 생겨 시스템이 정상동작 하지 않을때,

단순히 일반 파일시스템처럼 쓰기가능 스냅샷을 이용해 부팅하여 시스템을 복원 할 수 있다.

스냅샷을 만드는 방법또한 매우 쉽다.



이라고 해주면 간단하게 스냅샷이 만들어진다.

물론 subvolume 으로 디렉토리를 선언해 줘야 하는 부분이 있지만 간단하지 않나?



게다가 위와같이 이미 난 수십개의 스냅샷을 찍은 상태였는데도

실제적인 용량에 변화는 거의 없었다.

말 그대로 스냅샷이기때문이고, 각기 다른버젼(내용)의 스냅샷도 충분히 가능하다.

실제 원본에 대한 변화된 메타데이타를 위주로 갖고 있기때문인데, 매우 유용한 기능이다 역시.

근데 약간 IBrix  6.0 의 스냅샷과도 느낌이 매우 비슷하다....


4. Future Proof

Btrfs 는 64비트 파일시스템이다. 이녀석은 2의 64승이 되는 수의

Inodes 까지 핸들링 가능하다는것이고,

이것은 단순히 하나의 파일시스템 트리당 가능한 수이므로,

subvolume을 여러개 생성할 경우 그 이상의 Inode 들을 생성 할 수 있다는 것이다.

여기서 바로 작은 파일에 강하기 위해 태어난 녀석임을 알 수 있어진다.

서브볼륨들 역시 2의 64 승까지 생성이 가능하므로

파일의 아이노드 수는 무제한이라고 볼 수 있다.
(재밌게도 df -i 를 해보면 0 으로 나온다 ㅋ. )

이점이야말로 Btrfs 가 얼마나 미래지향적으로 개발되었는지를 알려 주는 항목이다.

이점을 이용하여 BtrFS 는 8 Exabytes 까지 확장이 가능하다.

즉 스토리지를 ScaleOut 하여 리눅스자체에서도 무리없이 관리 될 수 있도록 해준다는 얘기!!!


5. Extra Features

BtrFS 는 일반적인 파일시스템과 동일한 모양의 Directory 트리 들을 보여주고 있다.

하지만 기존의 Ext 파일시스템에서들의 Directory Re-optimizing 이 필요 없다.

B-Tree 의 서브볼륨에서 관리되어지고 있기때문에

구지 인덱싱을 다시할 필요가 없다는 것이다 쉽게말해..

또한 Btrfs 역시 일반적인 Filesystem 들과 동일하게 Chunk 단위로 할당한다.

다만, BtrFS 의 Chunk 스케일은 그것들과는 비교되지 않게 대인배스럽다.

무려 1G 의 Chunk 와 256 M 의 메타데이타를 기본적인 Chunk 단위로

사용하고 있기때문이고, 이것은 각 하드웨어 및 소프트웨어 Raid 들의 특성에도

맞추어 지기 위한 것이라고 한다. (사실 이부분은 좀 어려웠다...)

아무튼 이렇게 메타데이터와 DataChunk 를 나눠서 관리한다는

특성은 매우 대단한 점중 하나인데,

여러개의 스토리지 디바이스들이 하나로 묶여 있을때

각 디스크들에 데이타 Balancing 을 할 수도 있고,

특정 디스크에 필요한 데이타를 몰아 넣을 수도 있다는 것은

서비스 종류에 따라 매우 큰 유용성을 가져다 줄 수 있기때문이다.

위에서 btrfs filesystem df 를 한 모습을 보면 알 수 있다 ㅋ

이밖에도 여러가지 최신의 파일시스템들이 필요로 하는 기능들을

리눅스 커널차원에서 지원하고 있는데,
(Checksumming, Compress 등 )

이런 부분이 왜 필요로 하는지는 추후로 Big Data 를 위한 No SQL 관련된

부분들을 설명 할때 다시 정리하거나,

따로 각 부분들을 설명 후 컨버젼시하게 따로 작성하던가 해야 할 것 같다.
( 꼬리에 꼬리를 무는경우가 많아서 ㅋ )

추가적으로 BtrFS 의 강점중 하나는 SSD 핸들링에 관한 부분이다.

BtrFS 또한 TRIM 을 지원하고(기본은 off), B-tree 의 강력한 인덱싱을 이용하여

빠른 Seek time 을 가능 하도록 한다고 한다.

요즘 빅데이타의 대항마라기보다는 대항하는 방편으로 Data 의 하드웨어적

구조방식을 개선하는 연구도 활발한 편인데,

메타데이타등 주요 키인덱싱에 필요한 부분들을 SSD 로 선택해 사용하고,

일반 SATA 나 SAS 디스크들을 동시에 한 장비에서 사용하면서 데이타를

동일한 또는 다른 파일시스템들에 계층적으로 저장하는 방식으로 빠르고 안정되며,

대용량의 데이타를 저장 및 제공하는 방식들에 대해서

매우 영향을 미치는 파일시스템이라고 볼 수 있다는거~