도커는 데이터를 persistent 하게 저장하기 위해서 데이터 볼륨을 만든다. 실제 애플리케이션에서 만들어지는 데이터의 대부분은 데이터 볼륨에 저장이 된다. 애플리케이션이 만드는 로그나 데이터베이스의 데이터파일, 유저가 업로드한 파일등등이 모두 여기에 해당한다.
컨테이너 볼륨은 읽기 전용으로, 보통 수백메가 내외의 최소한의 파일들만을 포함한다. 로컬 호스트에서 문제가 생기더라도 다른 호스트에서 동일한 이미지로 컨테이너를 올리면 된다. 따라서 로컬 스토리지에서 볼륨을 관리해도 별 문제가 없다.
하지만 도커 데이터 볼륨은 아래의 특징들 때문에 로컬 스토리지에서 관리하기가 쉽지 않다.
대량의 읽기와 쓰기가 발생 할 확률이 높다. 로컬 스토리지로는 대량의 I/O를 처리 하기가 쉽지 않다.
데이터에 대한 리플리카나 패리티연산을 이용한 복구가 가능해야 한다.
복구가 이루어지는 동안 시스템 중단이 최소화 해야 한다.
원격에 Storage Node를 만들어서 컨테이너와 데이터 볼륨을 분리하는게 깔끔하겠다.
가정
kvm으로 인스턴스를 띄울 수 있다. kvm에 익숙하지 않다면 virtualbox로 테스트 해도 된다.
/dev/loop0 디바이스로 마운트 된 걸 확인 할 수 있다.
iSCSI라고 해도 달라질건 없다. 원격에 있는 볼륨을 마운트 한 후, 도커 볼륨으로 제공하면 된다.
iSCSI를 이용한 데이터 볼륨 제공
그래서 데이터 볼륨은 별도의 Storage Node(SNODE)를 이용해서 제공하기로 했다.
데이터 볼륨은 물리적으로 분리돼 있으며, storage network로 호스트와 연결돼 있다. 컨테이너가 볼륨을 요구하면, iSCSI를 이용해서 볼륨을 할당 받아서 컨테이너에 넘겨주는 방식이다.
데이터 볼륨 컨테이너를 만들면 컨테이너 ID를 반환한다. /var/lib/docker/containers/<container_id>/config.json에서 볼륨의 위치를 확인 할 수 있다.
# docker run -it --volumes-from myvolume ubuntu /bin/bash
# ls
bin dev home lib64 mnt opt root sbin sys usr
boot etc lib media myvolume proc run srv tmp var
myvolume를 확인 할 수 있다.
클라우드 인프라에서의 스토리지 서비스 구성
SNODE의 대역폭은 48G이라고 가정하자.
CNODE의 NIC이 1G다. 가용성을 위해서 MPIO로 NIC을 묶는 다면, 하나의 CNODE는 2G의 대역폭을 가진다. 대략 20개의 CNODE를 구성하면 되겠다. 풀랙 기준 20 * 2U 하면 40U로 8U가 남는다. 스위치 포트의 갯수(50 포트)와 랙 크기를 감안하면 20개 정도가 적당하지 싶다.
20대의 CNODE의 총 대역폭은 40G다.
스위치간 단일 포트의 대역폭 10G다. 두 대의 스위치를 사용했으니 총 20G다. 이렇게 해서는 CNODE와 SNODE의 대역폭을 다 채우지 못한다. LACP로 스위치간 포트를 묶어서 대역폭을 확보한다.
난 스토리지/네트워크 장비 전문가는 아니다. 일단 풍월로 들은 정보로 대략 구성을 해봤다. 신뢰하지는 말자.
정리
도커 볼륨 컨테이너를 만들고, 이 컨테이너의 볼륨을 iSCSI에 마운트 하는 것으로 원격 스토리지의 볼륨을 가져다 사용할 수 있다.
볼륨 서비스가 불리됨으로, AWS의 EBS와 같은 유연한 볼륨 서비스를 만들 수 있다.
호스트와 상관없이 컨테이너를 실행해도 동일한 볼륨 서비스를 받을 수 있다.
호스트(혹은 컨테이너가)가 맛이 가더라도, 다른 호스트에서 컨테이너를 띄우는 것으로 빠르게 컨테이너를 복구 할 수 있다.
Contents
클라우드에서의 도커 데이터 볼륨 관리
가정
로컬 호스트에서의 데이터 볼륨 제공
iSCSI를 이용한 데이터 볼륨 제공
테스트 환경
SNODE 만들기
도커를 올리기 위한 kvm 인스턴스 실행
iSCSI 볼륨을 도커 데이터 볼륨으로 올리기
클라우드 인프라에서의 스토리지 서비스 구성
정리
Recent Posts
Archive Posts
Tags