Docker Storage 이해

Ops 2018.10.15 14:15

2018.10.15 덧붙임

컨테이너 안에서 파일을 저장하려면 data volume을 이용하는 것이 좋다 (강력히 권장. data volume 사용이 애매하면 mount volume도 권장).

  • 컨테이너 안에서의 파일 I/O는 storage driver에 의해 처리되며, 이는 일반 file I/O보다 큰 오버헤드를 감수해야 한다 (CoW 처리 때문)
  • 하지만, data volume 을 이용한 (컨테이너 안에서의) 파일 I/O는 storage driver를 우회하여 처리되며, host 머신의 file I/O와 동일한 속도로 처리된다
  • data volume (또는 mount volume)을 이용하려면 docker run 명령으로 컨테이너를 실행할 때, -v 옵션으로 볼륨을 지정하면 된다



2016.12.16 덧붙임

  • 도커는 원래 Ubuntu에서 개발, Ubuntu의 파일 스토리지 시스템은 AUFS
  • Red Hat 계열 배포판 (RHEL, CentOS, ...)에는 AUFS가 존재하지 않음
  • Red Hat 계열 리눅스를 위해, 도커는 Device Mapper를 2번째 Storage Backend로 수용함
  • Red Hat 계열 리눅스에 도커를 설치하면, Device Mapper가 도커의 Storage Backend로 동작 (loop-lvm)
  • 만약, 도커를 상용 수준으로 운영하려면, Device Mapper를 loop-lvm(디폴트)가 아닌 direct-lvm으로 설정/운영해야 함
  • loopback device (loop-lvm)는 상용 서비스를 처리하기엔 성능이 너무 안 좋음 (https://forums.docker.com/t/loopback-storage-devices/22007/2)



2016.01.29 원글

Q: 도커를 쓸 때 궁금했다
- 도커허브에서 가져온 도커 이미지는 어디에 저장되는 걸까?
- 도커 컨테이너 안에 write 하는 데이터는 어디에 저장되는 걸까?

A: 알고보니, <도커 스토리지>에 저장됐다
- <도커 이미지>는 layer 구조를 갖는다
- <도커 컨테이너>의 데이터는 CoW (Copy On Write) 정책에 따라 저장된다
+ RHEL/ CentOS/ Fedora 에서는 <도커 스토리지> 설정 작업이 필요하다 (Device Mappr)
  - 디폴트 스토리지는 loopback 장치
  - 안정적이지 않음
- Ubuntu는 도커 패키지 설치후 도커 스토리지 설정 없이 그냥 써도 좋다 (AUFS)

도커 스토리지 설정 스크립트 (@RHEL/ CentOS/ Fedora)
0. su
  $ su
1. volume이 정상적으로 준비되어 있는지 확인
  # fdisk -l
  - 사용하지 않는 /dev/vdc 장치 존재 확인
2. docker-storage-setup 설정 파일 수정
  # cat <<EOF > /etc/sysconfig/docker-storage-setup DEVS=/dev/vdc VG=docker-vg EOF
3. docker-storage-setup 명령 실행
  # docker-storage-setup
  ...
  Physical volume "/dev/vdc1" successfully created
  Volume group "docker-vg" successfully created
  Rounding up size to full physical extent 16.00 MiB
  Logical volume "docker-poolmeta" created.
  Logical volume "docker-pool" created.
  ...

Ref
- (추천!) Understand images, containers, and storage drivers
  https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
- Docker and the Device Mapper storage driver
  https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/
- Comprehensive Overview of Storage Scalability in Docker
  http://developerblog.redhat.com/2014/09/30/overview-storage-scalability-docker/

(이상)

Posted by ingee
TAG docker

댓글을 달아 주세요

Permissioned Blockchain 합의 알고리즘의 종류


Permissioned Lottery based Consensus

  • 리더를 추첨, 리더가 블록을 생성
  • 사례: PoET (Proof of Elapsed Time), PoW
  • 장점: node 개수가 대규모일 때 적합
  • 단점: fork가 일어날 수 있음, 따라서 finality 확정까지 긴 시간 소요


Permissioned Voting based Consensus

  • 투표에 의한 합의
  • 사례: RBFT (Redundant BFT), PBFT (Practical BFT)
  • 장점: 빠른 finality 확정
  • 단점: node 수가 늘어날수록 합의 시간이 길어짐, 즉 scalability와 speed 사이의 trade-off 존재



합의 알고리즘 관련 용어

  • Safety : 같은 TXs를 처리하면 모든 node가 같은 결과를 내야 한다 (같은 블록체인을 만들어야 한다)
  • Liveness : 살아있는 node는 시간이 흐르면 결국 모든 TXs를 수신해야 한다


Ref.


Posted by ingee

댓글을 달아 주세요

도커 "WARNING: bridge-nf-call-iptables is disabled" 워닝 없애기


현상

docker info 명령을 실행했을 때 "bridge-nf-call-iptables is disabled" 워닝이 뜨는 경우가 있다.
$ docker info
...
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

의미

  • CentOS 같은 리눅스 배포판은 net.bridge.bridge-no-call-iptables 값이 디폴트 0 (zero)다
  • 이는 bridge 네트워크를 통해 송수신되는 패킷이 iptables 설정을 우회한다는 의미다
  • 컨테이너의 네트워크 패킷이 호스트머신의 iptables 설정에 따라 제어되도록 하는 것이 바람직하며 이를 위해서는 이 값을 1로 설정해야 한다

해법

$ sudo vi /etc/sysctl.conf ...다음 내용 추가... net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1

$ sudo sysctl -p


Ref


Posted by ingee
TAG docker

댓글을 달아 주세요

  1. 먹튀 2018.10.10 04:43  댓글주소  수정/삭제  댓글쓰기

    잘보고 갑니다 ^^

개요

블록체인 ID 관련 막연한 궁금증이 있었음.

  Q: 블록체인 위에 ID 정보를 저장해도 좋은가 (그러면 모든 개인 정보가 공개될텐데)?

조사를 통해 얻은 답은 다음과 같음.

  A: public 데이터(on-chain data)와 private 데이터(off-chain data)를 구분해서 관리한다.


ID 관련 개념 3가지

- claim: identity 정보. ex) "내 이름은 OO이고, 생일은 OO이다."

- proof: claim의 진위 증빙. ex) 실세계에서는 여권, ...

- attestation: 제3자에 의한 claim 진위 증빙. ex) 대학교의 학위증명, 회사의 재직증명, ...


Sovrin 사례 연구

배경 (문제인식)

  • 온라인 세계의 ID/PSWD 체계가 서비스별로 Silo 되어 있음
  • ID 데이터가 많은 Silo에 복제되어 있음 (유출 위험 증가)
  • 블록체인이 Self-Sovereign ID 실현의 돌파구가 됨 (Center Authority의 도움 없이 ID와 Key 생성)

비전: Identity for All (사람/조직/사물을 위한 ID)

  • ID 데이터가 유출되지 않는 방식 (Security)
  • ID owner가 ID 데이터를 누가/왜 사용하는지 통제할 수 있는 방식 (Control)
  • ID 사용이 특정 서비스 사업자에 구속되지 않는 방식 (Portability)

개발팀

  • Sovrin 재단 (비영리 재단)
  • 오픈소스 프로젝트 (Contributor 20명 안쪽)

Sovrin의 ID 데이터 운영 방식

  1. public claim 데이터
    . on-ledger 데이터 (Sovrin Ledger에 기록/공개)
    . 개인 식별이 가능한 데이터는 저장하지 않음
  2. prviate claim 데이터
    . off-ledger 데이터
      - Identity Graph: 이름, 주소 등의 개인 정보
      - Relationship Graph: 주소록, SNS 등의 네트워크 정보
      - Reputation Graph: ID owner에 대한 평판 정보
      - Data Graph: 사진, 파일 등 기타 정보
    . 사용자 SW (Sovrin Client)에 원본 데이터 저장/관리
    . 사업자 SW (Sovrin Agent)에 사본 데이터 저장/관리 (private container)

Sovrin 소프트웨어 구성

  1. Sovrin Ledger (블록체인)
    • Plenum 합의 알고리즘 (PBFT의 변형) 사용
    • public permissioned ledger (누구나 이용할 수 있지만, 권한이 부여된 관리자들만 운영에 참여)
  2. Sovrin Agent (사업자 SW, 메일 서버에 해당)
    • Sovrin Ledger의 Client로 동작
    • Sovrin Client (사용자 SW)에게 안정적인 p2p end-point 제공
    • ID owner의 private claim을 저장 (하지만, 데이터에 대한 통제권은 ID owner에게 있음)
  3. Sovrin Client (사업자 SW, 메일 클라이언트에 해당)
    • 사용자 기기(PC/Mobile) 위에서 동작 (한 사용자가 여러개의 Client 운용 가능)
    • ID owner의 keychain 저장
    • ID owner의 private claim 데이터 저장
    • Sovrin Agent의 도움으로 여러개 Client들의 data sync 수행

Ref.

(이상)


Posted by ingee

댓글을 달아 주세요

개요


Sidechain 기술이 해결하려는 문제

  • 비트코인의 기술적 한계 (느린 처리 속도, 스마트컨트랙트 미지원 등) 해소 필요
  • 하지만 문제 해소를 위해 별도의 블록체인을 새로 만들 경우, 다음과 같은 문제가 있음
    • 작업/노력의 중복 문제 : 비트코인과 비슷한 코드를 중복 작성/관리해야 함
    • 코인의 유동성 확보 문제 : 신규 블록체인의 참여자 부족으로 인해 신규 코인의 가치가 안정되지 않음

Sidechain의 문제 해결 방식: Pegged Sidechain을 제안

  • 비트코인과 asset 교환이 가능한 블록체인 (pegged sidechain)을 제안함 (관련 기술 규격을 백서에 제시함)
  • 효과
    • 비트코인과 연동함으로써 충분한 코인 유동성을 확보할 수 있음
    • 사이드체인의 기술적/경제적 결함이 해당 사이드체인 내부로 격리/제한됨 (혁신적 시도가 가능)

관련 용어

  • two-way peg : Sidechain들 사이에서 고정/유동 비율에 따라 코인을 교환하는 메커니즘
  • pegged sidechain : asset을 (two-way peg 메카니즘에 따라) 교환할 수 있는 블록체인


관련 솔루션

Posted by ingee

댓글을 달아 주세요