Docker storage

다루고자 하는 것
● AUFS (Advanced multi layered Unification FileSystem)
● AUFS와 Docker
● OveylayFS 등 다른 대안

AUFS
● 리눅스 파일 시스템의 union mount를 구현하기 위해서 시작한 프로젝트
● 2006년 Junjiro Okajima가 개발을 시작했으며 UnionFS를 완전히 새로 만듦
● 안정성과 성능을 향상시키는 이외 writable branch balancing와 같은 새로운
기능도 포함하고 있음
● 주류 리눅스로의 통합이 거부됨
○ 코드는 빽빽하고 읽기 어려우며 주석이 안 되어 있다는 이유로 비판을 받음 (대신
OverlayFS가 리눅스 커널에 통합)
● Docker Image Layer의 기본 Filesystem으로 이용되고 있고 이로 인해 많은
곳에서 AUFS를 이용하고 있음

Union Mount
● 여러 개의 폴더를 동시에 특정 폴더에 Mount하는 동작

Mount
# mount -t aufs -o br=/layer_rw=rw:/layer_01=ro+wh:/layer_02=ro+wh:/layer_03=ro+wh none /mnt
br(Branch)에 Union Mount를
위한 폴더를 나열함
/layer_rw는 Root Branch
/layer_rw 폴더는 RW Branch
RO Branch
/mnt 폴더에 Branch
들이 Union Mount 됨Root 뿐만 아니라 이
폴더의 Whiteout
파일도 참조하겠다는
옵션
*Whiteout - AUFS에서는 파일의 삭제를 나타내기 위한 파일

Branch
● AUFS에서는 스택을 이루는 각각의 스택을 브랜치(branch)라고 부름
● 스택을 이루는 폴더는 하나의 마운트 포인터로 묶일 수 있어야 하므로 반드시
같은 리눅스 호스트에 존재해야 함

Read, Write
● Read
○ 동일한 경로에 동일한 파일 이름이 있는
경우 AUFS Mount가 된 폴더 내에서는
오직 Branch의 가장 마지막에 있는
폴더의 파일만 볼 수 있음
● Write
○ COW(Copy on Write)방식을 이용함
○ /mnt 폴더에서 파일을 쓰는 경우 써진
파일은 AUFS의 RW Branch 폴더에
그대로 저장됨

Remove File
● RW Branch에 .wh.{filename}
Whiteout 파일을 생성하여 Mount가
된 폴더 내에서는 파일이
안보이지만 원본은 유지됨
● RO Branch 폴더 안에 있는
Whiteout 파일의 역할도 나타내고
있음

Remove All Files in Folder
● .wh..wh..opq라는 특수한 Whiteout
파일을 이용함
○ Branch의 특정 폴더 내 .wh..wh..opq
파일이 있으면 하위 Branch의 해당 폴더
내 모든 파일을 폴더 내에서 볼 수 없음
● 다시 dir 폴더를 생성하는 경우
layer_rw Branch의 /dir 폴더 안
.wh..wh..opq 파일 생성을 통해
처리함

Renaming Directories 문제
● 폴더에 대해 rename(2)를 호출하는 것은 AUFS에 대해 완벽하게 지원되지는
않음
○ 원래 위치와 목적지 위치가 같은 AUFS 레이어에 있더라도 (심지어 아무런 자식 파일을 갖지
않아도) EXDEV(cross-device link not permitted)를 반환함
○ 애플리케이션은 EXDEV에 대한 Copy and Unlink 으로 대처할 수 있도록 설계해야 함

AUFS와 Docker
● AUFS는 도커를 위한 좋은 기능을 제공함
○ 빠른 컨테이너 시작 시간
○ 효율적인 스토리지 사용
○ 효율적인 메모리 사용

성능
● AUFS는 여러 개의 컨테이너 간 이미지를 효과적으로 공유함
○ 곧 빠른 컨테이너 시작 시간과 최소한의 저장공간을 사용하게 함
○ 이미지와 컨테이너 간 파일을 공유하는 기본적인 원리 - 시스템 페이지 캐시
● 첫 쓰기 작업에 대해 적지 않은 지연(Latency)이 발생함
○ 컨테이너가 맨 처음 어떤 파일에 쓰기를 시작하면 그 파일은 컨테이너 레이어에 위치되어야
하며 복사해야 함
○ 이런 파일이 이미지의 매우 하단 레이어에 있고 그 파일이 매우 클 때 이 지연은 더 커지고
복잡해(compounded)짐
● 성능 최적화
○ SSD를 사용하라 (응…?)
○ Data Volume은 예측 가능하고 최상의 성능을 제공함 - AUFS를 우회하며 thin provisioning과
CoW(Copy-on-Write)에 의한 어떠한 잠재적 오버헤드를 발생시키지 않기 때문임

Docker Image Layer (Concept)
# mount -t aufs -o
br=/container_rw=rw:/ubuntu_base01=ro+wh:/ubuntu_base02=ro+wh:/ubuntu_base03=ro+wh
none /container_root

Docker Image Layer
● 이미지를 구성하는 스택 정보 - /var/lib/docker/aufs/layers
● 각 스택이 저장하고 있는 실제 데이터 - /var/lib/docker/aufs/diff

OverlayFS
● UnionFS 계열
● AUFS와의 차이점
○ AUFS 보다 단순한 디자인
○ 리눅스 커널 3.18부터 정식으로 지원
○ 좀 더 빠름
● 최근 인기 상승 중이나 나온지 얼마 되지 않아 안정성이 떨어진다는 점이
문제임
○ 현장에서 사용 할 때는 주의해야 함

OverlayFS의 구조
● 2 Layers
○ 여러 개의 layer가 스택을 이루는 AUFS와는 달리 단지 2개의 layer만 가지고 있음
■ lowerdir - 읽기 전용의 image layer
■ upperdir - container layer. Image layer로부터 만들어지며 변경되는 정보가 여기에
저장됨
● Multi-Layer Image 구성 불가
○ 각 image layer마다 /var/lib/docker/overlay 폴더 밑에 자신만의 폴더를 가지는 것으로 이
문제를 해결함

기타 Docker 지원 Storage Driver
● 기본적으로 CoW를 지원하면 됨
● Device mapper
○ loop-lvm
○ direct-lvm
● CoW 지원 FS
○ zfs
○ btrfs

참고자료
1. https://www.joinc.co.kr/w/man/12/docker/aufs
2. https://www.joinc.co.kr/w/man/12/docker/storage
3. https://ssup2.github.io/theory_analysis/Union_Mount_AUFS_Docker_Image_
Layer/
4. http://blog.naver.com/PostView.nhn?blogId=alice_k106&logNo=22083943630
7&parentCategoryNo=&categoryNo=7&viewDate=&isShowPopularPosts=true
&from=search

Docker storage

More Related Content

Similar to Docker storage

Docker storage